Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Beobachtbarkeit
Einführung
Observability-Tools helfen Ihnen dabei, Ihre Workloads effizient zu erkennen, zu beheben und zu untersuchen. Die Kosten für Telemetriedaten steigen natürlich mit zunehmender Nutzung von EKS. Manchmal kann es schwierig sein, Ihre betrieblichen Anforderungen in Einklang zu bringen und zu messen, was für Ihr Unternehmen wichtig ist, und die Kosten für die Beobachtbarkeit unter Kontrolle zu halten. Dieser Leitfaden konzentriert sich auf Strategien zur Kostenoptimierung für die drei Säulen der Beobachtbarkeit: Logs, Metriken und Traces. Jede dieser bewährten Methoden kann unabhängig voneinander angewendet werden, um den Optimierungszielen Ihres Unternehmens gerecht zu werden.
Protokollierung
Die Protokollierung spielt eine wichtige Rolle bei der Überwachung und Fehlerbehebung der Anwendungen in Ihrem Cluster. Es gibt verschiedene Strategien, mit denen die Protokollierungskosten optimiert werden können. Zu den im Folgenden aufgeführten Best-Practice-Strategien gehören die Überprüfung Ihrer Richtlinien zur Aufbewahrung von Protokollen, um detaillierte Kontrollen darüber zu implementieren, wie lange Protokolldaten aufbewahrt werden, das Senden von Protokolldaten je nach Wichtigkeit an verschiedene Speicheroptionen und die Verwendung von Protokollfiltern, um die Arten der gespeicherten Protokollnachrichten einzugrenzen. Eine effiziente Verwaltung der Protokolltelemetrie kann zu Kosteneinsparungen für Ihre Umgebungen führen.
EKS-Steuerebene
Optimieren Sie Ihre Steuerebenenprotokolle
Die Kubernetes-Steuerebene besteht aus einer Reihe von Komponenten
Aktivieren Sie beispielsweise in Clustern, die nicht zur Produktion gehören, bestimmte Protokolltypen, z. B. die API-Serverprotokolle, selektiv nur zur Analyse und deaktivieren Sie sie anschließend. Aber für Produktionscluster, bei denen Sie Ereignisse möglicherweise nicht reproduzieren können und für die Lösung von Problemen mehr Protokollinformationen erforderlich sind, können Sie alle Protokolltypen aktivieren. Weitere Einzelheiten zur Implementierung der Kostenoptimierung auf Kontrollebene finden Sie in diesem Blogbeitrag
Protokolle auf S3 streamen
Eine weitere bewährte Methode zur Kostenoptimierung ist das Streamen von Protokollen der Kontrollebene über CloudWatch Logs-Abonnements nach S3. Durch die Nutzung von CloudWatch Logs-Abonnements können Sie Protokolle selektiv an S3 weiterleiten, was eine kostengünstigere Langzeitspeicherung ermöglicht als die unbefristete Aufbewahrung von Protokollen. CloudWatch Für Produktionscluster können Sie beispielsweise eine kritische Protokollgruppe erstellen und Abonnements nutzen, um diese Protokolle nach 15 Tagen an S3 zu streamen. Auf diese Weise können Sie schnell auf die zu analysierenden Protokolle zugreifen, sparen aber auch Kosten, indem Sie die Protokolle in einen kostengünstigeren Speicher verschieben.
Wichtig
Seit dem 5.9.2023 werden EKS-Logs in Amazon Logs als verkaufte Logs eingestuft. CloudWatch Vended Logs sind spezifische AWS-Serviceprotokolle, die nativ von AWS-Services im Namen des Kunden veröffentlicht werden und zu Mengenrabatten erhältlich sind. Bitte besuchen Sie die Seite mit den CloudWatch Amazon-Preisen
EKS-Datenebene
Aufbewahrung von Protokollen
CloudWatchDie Standard-Aufbewahrungsrichtlinie von Amazon sieht vor, dass Protokolle auf unbestimmte Zeit aufbewahrt werden und niemals ablaufen, wodurch Speicherkosten anfallen, die für Ihre AWS-Region gelten. Um die Speicherkosten zu reduzieren, können Sie die Aufbewahrungsrichtlinie für jede Protokollgruppe an Ihre Workload-Anforderungen anpassen.
In einer Entwicklungsumgebung ist eine lange Aufbewahrungsfrist möglicherweise nicht erforderlich. In einer Produktionsumgebung können Sie jedoch eine längere Aufbewahrungsrichtlinie festlegen, um die Anforderungen an Problembehandlung, Compliance und Kapazitätsplanung zu erfüllen. Wenn Sie beispielsweise in der Hauptsaison an Feiertagen eine E-Commerce-Anwendung ausführen, das System stärker ausgelastet ist und Probleme auftreten können, die möglicherweise nicht sofort erkennbar sind, sollten Sie eine längere Protokollspeicherung für eine detaillierte Fehlerbehebung und Analyse nach dem Ereignis einrichten.
Sie können Ihre Aufbewahrungszeiträume in der CloudWatch AWS-Konsole oder AWS-API mit einer Dauer von 1 Tag bis 10 Jahren konfigurieren, basierend auf jeder Protokollgruppe. Durch eine flexible Aufbewahrungsfrist können Sie Kosten für die Speicherung von Protokollen sparen und gleichzeitig wichtige Protokolle verwalten.
Optionen zum Speichern von Protokollen
Die Speicherung ist ein großer Kostenfaktor für die Beobachtbarkeit. Daher ist es wichtig, Ihre Strategie zur Speicherung von Protokollen zu optimieren. Ihre Strategien sollten auf Ihre Workload-Anforderungen abgestimmt sein und gleichzeitig Leistung und Skalierbarkeit beibehalten. Eine Strategie zur Senkung der Kosten für das Speichern von Protokollen besteht darin, die AWS S3-Buckets und die verschiedenen Speicherstufen zu nutzen.
Leiten Sie Protokolle direkt an S3 weiter
Erwägen Sie, weniger kritische Protokolle, z. B. Entwicklungsumgebungen, direkt an S3 statt an Cloudwatch weiterzuleiten. Dies kann sich unmittelbar auf die Kosten für die Protokollspeicherung auswirken. Eine Option besteht darin, die Protokolle mithilfe von Fluentbit direkt an S3 weiterzuleiten. Sie definieren dies in dem [OUTPUT] Abschnitt, dem Ziel, FluentBit an das Container-Logs zur Aufbewahrung übertragen werden. Weitere Konfigurationsparameter finden Sie hier
[OUTPUT]
Name eks_to_s3
Match application.*
bucket $S3_BUCKET name
region us-east-2
store_dir /var/log/fluentbit
total_file_size 30M
upload_timeout 3m
Logs CloudWatch nur zur kurzfristigen Analyse weiterleiten
Für kritischere Protokolle, z. B. Produktionsumgebungen, in denen Sie möglicherweise eine sofortige Analyse der Daten durchführen müssen, sollten Sie die Protokolle weiterleiten an CloudWatch. Sie definieren dies in dem [OUTPUT] Abschnitt, dem Ziel, an das FluentBit Container-Protokolle zur Aufbewahrung übertragen werden. Weitere Konfigurationsparameter finden Sie hier
[OUTPUT]
Name eks_to_cloudwatch_logs
Match application.*
region us-east-2
log_group_name fluent-bit-cloudwatch
log_stream_prefix from-fluent-bit-
auto_create_group On
Dies wird sich jedoch nicht sofort auf Ihre Kosteneinsparungen auswirken. Um zusätzliche Einsparungen zu erzielen, müssen Sie diese Protokolle nach Amazon S3 exportieren.
Export nach Amazon S3 von CloudWatch
Für die langfristige Speicherung von CloudWatch Amazon-Protokollen empfehlen wir, Ihre Amazon CloudWatch EKS-Protokolle nach Amazon Simple Storage Service (Amazon S3) zu exportieren. Sie können die Protokolle an den Amazon S3 S3-Bucket weiterleiten, indem Sie eine Exportaufgabe über die Konsole oder die API erstellen. Nachdem Sie dies getan haben, bietet Amazon S3 viele Optionen zur weiteren Kostensenkung. Sie können Ihre eigenen Amazon S3 Lifecycle-Regeln definieren, um Ihre Protokolle in eine Speicherklasse zu verschieben, die Ihren Anforderungen entspricht, oder die Amazon S3 S3-Speicherklasse Intelligent-Tiering
Reduzieren Sie die Protokollebenen
Üben Sie die selektive Protokollierung für Ihre Anwendung. Sowohl Ihre Anwendungen als auch Ihre Knoten geben standardmäßig Protokolle aus. Passen Sie für Ihre Anwendungsprotokolle die Protokollebenen an die Wichtigkeit der Arbeitslast und der Umgebung an. Die unten stehende Java-Anwendung gibt beispielsweise INFO Protokolle aus. Dies ist die typische Standardanwendungskonfiguration, die je nach Code zu einer großen Menge an Protokolldaten führen kann.
import org.apache.log4j.*; public class LogClass { private static org.apache.log4j.Logger log = Logger.getLogger(LogClass.class); public static void main(String[] args) { log.setLevel(Level.INFO); log.debug("This is a DEBUG message, check this out!"); log.info("This is an INFO message, nothing to see here!"); log.warn("This is a WARN message, investigate this!"); log.error("This is an ERROR message, check this out!"); log.fatal("This is a FATAL message, investigate this!"); } }
Ändern Sie in einer Entwicklungsumgebung Ihre Protokollebene aufDEBUG, da dies Ihnen helfen kann, Probleme zu debuggen oder catch Probleme zu erkennen, bevor sie produktiv werden.
log.setLevel(Level.DEBUG);
In einer Produktionsumgebung sollten Sie erwägen, Ihre Protokollebene auf ERROR oder FATAL zu ändern. Dadurch wird das Protokoll nur dann ausgegeben, wenn Ihre Anwendung Fehler aufweist. Dadurch wird die Protokollausgabe reduziert und Sie können sich auf wichtige Daten zum Status Ihrer Anwendung konzentrieren.
log.setLevel(Level.ERROR);
Sie können die Protokollebenen verschiedener Kubernetes-Komponenten fein abstimmen. Wenn Sie beispielsweise Bottlerocketkubelet
[settings.kubernetes] log-level = "2" image-gc-high-threshold-percent = "85" image-gc-low-threshold-percent = "80"
In einer Entwicklungsumgebung können Sie die Protokollebene auf einen höheren Wert als 2 setzen, um zusätzliche Ereignisse anzuzeigen. Dies ist ideal für das Debuggen. In einer Produktionsumgebung können Sie die Stufe auf 0 setzen, um nur kritische Ereignisse anzuzeigen.
Nutzen Sie Filter
Wenn Sie eine standardmäßige EKS-Fluentbit-Konfiguration verwenden, um Container-Logs an Cloudwatch zu senden, werden ALLE mit Kubernetes-Metadaten angereicherten Anwendungscontainer-Logs FluentBit erfasst und an Cloudwatch gesendet, wie im Konfigurationsblock unten gezeigt. [INPUT]
[INPUT]
Name tail
Tag application.*
Exclude_Path /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*, /var/log/containers/aws-node*, /var/log/containers/kube-proxy*
Path /var/log/containers/*.log
Docker_Mode On
Docker_Mode_Flush 5
Docker_Mode_Parser container_firstline
Parser docker
DB /var/fluent-bit/state/flb_container.db
Mem_Buf_Limit 50MB
Skip_Long_Lines On
Refresh_Interval 10
Rotate_Wait 30
storage.type filesystem
Read_from_Head ${READ_FROM_HEAD}
Im obigen [INPUT] Abschnitt werden alle Container-Logs aufgenommen. Dadurch kann eine große Datenmenge generiert werden, die möglicherweise nicht erforderlich ist. Durch das Herausfiltern dieser Daten kann die Menge der gesendeten Protokolldaten reduziert und CloudWatch somit Ihre Kosten gesenkt werden. Sie können einen Filter auf Ihre Protokolle anwenden, bevor sie ausgegeben werden CloudWatch. Fluentbit definiert dies im [FILTER] Abschnitt. Wenn Sie beispielsweise die Kubernetes-Metadaten herausfiltern, damit sie nicht an Protokollereignisse angehängt werden, können Sie Ihr Protokollvolumen reduzieren.
[FILTER]
Name nest
Match application.*
Operation lift
Nested_under kubernetes
Add_prefix Kube.
[FILTER]
Name modify
Match application.*
Remove Kube.<Metadata_1>
Remove Kube.<Metadata_2>
Remove Kube.<Metadata_3>
[FILTER]
Name nest
Match application.*
Operation nest
Wildcard Kube.*
Nested_under kubernetes
Remove_prefix Kube.
Metriken
Metriken
Überwachen Sie, worauf es ankommt, und sammeln Sie nur das, was Sie benötigen
Die erste Strategie zur Kostensenkung besteht darin, die Anzahl der gesammelten Kennzahlen zu reduzieren und damit die Aufbewahrungskosten zu senken.
-
Gehen Sie zunächst von Ihren und/oder den Anforderungen Ihrer Stakeholder aus, um die wichtigsten Kennzahlen
zu ermitteln. Erfolgskennzahlen sind für jeden anders! Wissen Sie, wie gut aussieht, und messen Sie es. -
Erwägen Sie, sich eingehend mit den Workloads, die Sie unterstützen, zu befassen und deren Key Performance Indicators (KPIs), auch bekannt als „Goldene Signale“, zu identifizieren. Diese sollten den Anforderungen der Unternehmen und der Interessengruppen entsprechen. Die Berechnung SLIs und SLAs Verwendung von Amazon CloudWatch und Metric Math ist entscheidend für die Verwaltung der Servicezuverlässigkeit. SLOs Folgen Sie den in diesem Leitfaden
beschriebenen bewährten Methoden, um die Leistung Ihrer EKS-Umgebung effektiv zu überwachen und aufrechtzuerhalten. -
Fahren Sie dann mit den verschiedenen Ebenen der Infrastruktur fort, um EKS-Cluster, Knoten und zusätzliche Infrastrukturkennzahlen miteinander zu verbinden und mit Ihrer Arbeitslast KPIs zu korrelieren
. Speichern Sie Ihre Geschäfts- und Betriebskennzahlen in einem System, in dem Sie sie miteinander korrelieren und Schlussfolgerungen auf der Grundlage der beobachteten Auswirkungen auf beide ziehen können. -
EKS stellt Metriken aus der Kontrollebene, dem Cluster kube-state-metrics, den Pods und den Knoten zur Verfügung. Die Relevanz all dieser Metriken hängt von Ihren Anforderungen ab. Es ist jedoch wahrscheinlich, dass Sie nicht jede einzelne Metrik auf den verschiedenen Ebenen benötigen. Sie können diesen Leitfaden zu den wichtigsten EKS-Metriken
als Grundlage für die Überwachung des allgemeinen Zustands eines EKS-Clusters und Ihrer Workloads verwenden.
Hier ist ein Beispiel für eine Prometheus-Scrape-Konfiguration, in der wir die verwenden, relabel_config um nur Kubelet-Metriken beizubehalten und metric_relabel_config alle Container-Metriken zu löschen.
kubernetes_sd_configs: - role: endpoints namespaces: names: - kube-system bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true relabel_configs: - source_labels: [__meta_kubernetes_service_label_k8s_app] regex: kubelet action: keep metric_relabel_configs: - source_labels: [__name__] regex: container_(network_tcp_usage_total|network_udp_usage_total|tasks_state|cpu_load_average_10s) action: drop
Reduzieren Sie gegebenenfalls die Kardinalität
Kardinalität bezieht sich auf die Einzigartigkeit der Datenwerte in Kombination mit ihren Dimensionen (z. B. Prometheus-Bezeichnungen) für einen bestimmten Metriksatz. Metriken mit hoher Kardinalität haben viele Dimensionen, und jede Kombination von Dimensionsmetriken weist eine höhere Eindeutigkeit auf. Eine höhere Kardinalität führt zu einer größeren Größe und einem größeren Speicherbedarf für metrische Telemetriedaten, was die Kosten erhöht.
Im Beispiel mit hoher Kardinalität unten sehen wir, dass die Metrik Latenz Dimensionen, RequestID, CustomerID und Service hat und dass jede Dimension viele eindeutige Werte hat. Die Kardinalität ist das Maß für die Kombination der Anzahl möglicher Werte pro Dimension. In Prometheus wird jeder Satz einzigartiger Dimensionen/Labels als neue Metrik betrachtet, daher bedeutet eine hohe Kardinalität mehr Metriken.
In EKS-Umgebungen mit vielen Metriken und Dimensionen/Labels pro Metrik (Cluster, Namespace, Service, Pod, Container usw.) nimmt die Kardinalität tendenziell zu. Um die Kosten zu optimieren, sollten Sie die Kardinalität der von Ihnen gesammelten Kennzahlen sorgfältig berücksichtigen. Wenn Sie beispielsweise eine bestimmte Metrik für die Visualisierung auf Clusterebene aggregieren, können Sie zusätzliche Labels löschen, die sich auf einer niedrigeren Ebene befinden, z. B. das Namespace-Label.
Um Metriken mit hoher Kardinalität in Prometheus zu identifizieren, können Sie die folgende PROMQL-Abfrage ausführen, um zu ermitteln, welche Scrape-Ziele die höchste Anzahl von Metriken haben (Kardinalität):
topk_max(5, max_over_time(scrape_samples_scraped[1h]))
und die folgende PROMQL-Abfrage kann Ihnen dabei helfen, festzustellen, welche Scrape-Ziele die höchsten Abwanderungsraten (wie viele neue Metrikreihen wurden in einem bestimmten Scrape erstellt) aufweisen:
topk_max(5, max_over_time(scrape_series_added[1h]))
Wenn Sie Grafana verwenden, können Sie das Mimirtool von Grafana Lab verwenden, um Ihre Grafana-Dashboards und Prometheus-Regeln zu analysieren, um ungenutzte Metriken mit hoher Kardinalität zu identifizieren. Folgen Sie dieser Anleitung zurmimirtool analyze prometheus Befehle mimirtool analyze und, um aktive Metriken zu identifizieren, auf die in Ihren Dashboards nicht verwiesen wird.
Beachten Sie die Granularität der Metriken
Das Sammeln von Metriken mit einer höheren Granularität, z. B. jede Sekunde im Vergleich zu jeder Minute, kann einen großen Einfluss darauf haben, wie viel Telemetrie gesammelt und gespeichert wird, was die Kosten erhöht. Legen Sie sinnvolle Intervalle für die Erfassung oder Erfassung von Metriken fest, die zwischen ausreichender Granularität zur Erkennung vorübergehender Probleme und ausreichend niedrig sind, um kostengünstig zu sein. Verringern Sie die Granularität von Kennzahlen, die für die Kapazitätsplanung und die Analyse größerer Zeitfenster verwendet werden.
Wichtig
Das globale Prometheus-Scrape-Intervall ist auf 15 Sekunden festgelegt. Dieses Scrape-Intervall kann verlängert werden, was zu einer Verringerung der Menge der in Prometheus gesammelten metrischen Daten führt.
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: my-collector-amp
...
config: |
extensions:
sigv4auth:
region: "+++<YOUR_AWS_REGION>+++" service: "aps"+++</YOUR_AWS_REGION>+++
receivers:
#
# Scrape configuration for the Prometheus Receiver
# This is the same configuration used when Prometheus is installed using the community Helm chart
#
prometheus:
config:
global: scrape_interval: 15s
scrape_timeout: 10s
Nachverfolgung
Die Hauptkosten im Zusammenhang mit der Rückverfolgung sind auf die Generierung von Trace-Speichern zurückzuführen. Bei der Rückverfolgung geht es darum, genügend Daten zu sammeln, um Leistungsaspekte zu diagnostizieren und zu verstehen. Da die Kosten für Röntgen-Traces jedoch auf Daten basieren, die an X-Ray weitergeleitet werden, reduziert das Löschen von Spuren nach der Weiterleitung Ihre Kosten nicht. Lassen Sie uns untersuchen, wie Sie Ihre Kosten für die Rückverfolgung senken und gleichzeitig die Daten verwalten können, damit Sie eine ordnungsgemäße Analyse durchführen können.
Wenden Sie Stichprobenregeln an
Die Röntgenabtastrate ist standardmäßig konservativ. Definieren Sie Stichprobenregeln, mit denen Sie die Menge der gesammelten Daten steuern können. Dies verbessert die Leistungseffizienz und senkt gleichzeitig die Kosten. Indem Sie die Samplingrate verringern, können Sie Traces aus der Anfrage nur für das sammeln, was Ihre Workloads benötigen, und gleichzeitig eine niedrigere Kostenstruktur beibehalten.
Sie haben beispielsweise eine Java-Anwendung, mit der Sie die Traces aller Anfragen für eine problematische Route debuggen möchten.
Konfigurieren Sie über das SDK, um Sampling-Regeln aus einem JSON-Dokument zu laden
{ "version": 2, "rules": [ { "description": "debug-eks", "host": "*", "http_method": "PUT", "url_path": "/history/*", "fixed_target": 0, "rate": 1, "service_type": "debug-eks" } ], "default": { "fixed_target": 1, "rate": 0.1 } }
Über die Konsole
Wenden Sie Tail Sampling mit AWS Distro for OpenTelemetry (ADOT) an
Mit ADOT Tail Sampling können Sie das Volumen der im Service aufgenommenen Spuren kontrollieren. Mit Tail Sampling können Sie die Sampling-Richtlinien jedoch erst definieren, nachdem alle Zeiträume der Anfrage abgeschlossen wurden, und nicht zu Beginn. Dadurch wird die Menge der übertragenen Rohdaten weiter begrenzt CloudWatch, wodurch die Kosten gesenkt werden.
Wenn Sie beispielsweise 1% der Zugriffe auf eine Landingpage und 10% der Anfragen auf eine Zahlungsseite auswerten, kann dies dazu führen, dass Sie über einen Zeitraum von 30 Minuten 300 Traces haben. Mit einer ADOT Tail Sampling-Regel, die bestimmte Fehler filtert, könnten Ihnen 200 Traces übrig bleiben, was die Anzahl der gespeicherten Traces verringert.
processors:
groupbytrace:
wait_duration: 10s
num_traces: 300
tail_sampling:
decision_wait: 1s # This value should be smaller than wait_duration
policies:
- ..... # Applicable policies**
batch/tracesampling:
timeout: 0s # No need to wait more since this will happen in previous processors
send_batch_max_size: 8196 # This will still allow us to limit the size of the batches sent to subsequent exporters
service:
pipelines:
traces/tailsampling:
receivers: [otlp]
processors: [groupbytrace, tail_sampling, batch/tracesampling]
exporters: [awsxray]
Nutzen Sie die Amazon S3 S3-Speicheroptionen
Sie sollten den AWS S3-Bucket und seine verschiedenen Speicherklassen nutzen, um die Traces zu speichern. Exportieren Sie Traces nach S3, bevor die Aufbewahrungsfrist abläuft. Verwenden Sie die Amazon S3 S3-Lebenszyklusregeln, um die Trace-Daten in die Speicherklasse zu verschieben, die Ihren Anforderungen entspricht.
Wenn Sie beispielsweise Traces haben, die 90 Tage alt sind, kann Amazon S3 Intelligent-Tiering
Zusätzliche Ressourcen:
