Fargate-Protokollierung - Amazon EKS

Fargate-Protokollierung

Amazon EKS auf Fargate bietet einen integrierten Log-Router basierend auf Fluent Bit. Dies bedeutet, dass Sie einen Fluent Bit-Container nicht explizit als Sidecar ausführen. Amazon übernimmt die Ausführung für Sie. Alles, was Sie tun müssen, ist den Log-Router zu konfigurieren. Die Konfiguration erfolgt über ein dediziertes ConfigMap, das die folgenden Kriterien erfüllen muss:

  • Benannte aws-logging

  • Erstellt in einem dedizierten Namespace namens aws-observability

Sobald Sie die ConfigMap erstellt haben, erkennt Amazon EKS auf Fargate sie automatisch und konfiguriert den Protokollrouter damit. Fargate verwendet eine Version von AWS für Fluent Bit, eine Upstream-kompatible Distribution von Fluent Bit, die von AWS verwaltet wird. Weitere Informationen finden Sie unter AWS für Fluent Bit auf GitHub.

Mit dem Log-Router können Sie die Bandbreite der Dienste von AWS für Protokoll-Analysen und -Speicherung nutzen. Sie können Protokolle von Fargate direkt an Amazon CloudWatch, Amazon OpenSearch Service streamen. Sie können Protokolle auch über Amazon Kinesis Data Firehose an Ziele wie Amazon S3, Amazon Kinesis Data Streams und Partnerwerkzeuge streamen.

Voraussetzungen

Router-Konfiguration protokollieren

So konfigurieren Sie den Protokollrouter

Ersetzen Sie in den folgenden Schritten jede example-value durch Ihre eigenen Werte.

  1. Erstellen Sie einen dedizierten Kubernetes-Namespace mit dem Namen aws-observability.

    1. Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen aws-observability-namespace.yaml auf Ihrem Computer. Der Wert für name muss aws-observability sein und das Label aws-observability: enabled ist erforderlich.

      kind: Namespace apiVersion: v1 metadata: name: aws-observability labels: aws-observability: enabled
    2. Erstellen Sie den Namespace.

      kubectl apply -f aws-observability-namespace.yaml
  2. Erstellen Sie ein ConfigMap mit einem Fluent Conf-Datenwert, um Container-Logs an ein Ziel zu versenden. Fluent Conf ist Fluent Bit, eine schnelle und leichte Konfigurationssprache für den Protokollprozessor, die verwendet wird, um Containerprotokolle an ein Protokollziel Ihrer Wahl weiterzuleiten. Weitere Informationen finden Sie unter Configuration File (Konfigurationsdatei) in der Fluent Bit-Dokumentation.

    Wichtig

    In einer typischen Fluent Conf sind die Hauptabschnitte Service, Input, Filter und Output enthalten. Der Fargate-Protokoll-Router akzeptiert jedoch nur:

    • Die Abschnitte Filter und Output und verwaltet die Abschnitte Service und Input selbst.

    • Ein Parser-Abschnitt.

    Wenn Sie einen anderen Abschnitt als Filter, Output, und Parser angeben, werden die Abschnitte abgelehnt.

    Berücksichtigen Sie beim Erstellen des ConfigMap, die folgenden Regeln, die Fargate verwendet, um Felder zu validieren:

    • [FILTER], [OUTPUT], und [PARSER] sollen unter jedem entsprechenden Schlüssel angegeben werden. [FILTER] muss beispielsweise unter filters.conf liegen. Sie können ein oder mehrere [FILTER] in der filters.conf haben. Die Abschnitte [OUTPUT] und [PARSER] sollten sich auch unter den entsprechenden Schlüssel befinden. Durch die Angabe mehrerer [OUTPUT]-Abschnitte können Sie Ihre Protokolle gleichzeitig an verschiedene Ziele weiterleiten.

    • Fargate validiert die erforderlichen Schlüssel für jeden Abschnitt. Name und matchsind für jedes [FILTER] und [OUTPUT] erforderlich. Name und format werden jeweils für jeden [PARSER] benötigt. Bei den Schlüssel wird nicht zwischen Groß- und Kleinschreibung unterschieden.

    • Umgebungsvariablen wie ${ENV_VAR} sind im ConfigMap nicht erlaubt.

    • Die Einrückung muss für die Direktive oder das Schlüssel-Wert-Paar innerhalb von filters.conf, output.conf und parsers.conf gleich sein. Schlüssel-Wert-Paare müssen stärker eingerückt werden als Direktiven.

    • Fargate validiert gegen die folgenden unterstützten Filter: grep, parser, record_modifier, rewrite_tag, throttle, nest, modify, und kubernetes.

    • Fargate validiert mit der folgenden unterstützten Ausgabe: es, firehose, kinesis_firehose, cloudwatch, cloudwatch_logs, und kinesis.

    • Mindestens ein unterstütztes Output-Plugin muss im ConfigMap bereitgestellt werden, um die Protokollierung zu ermöglichen. Filter und Parser sind nicht erforderlich, um die Protokollierung zu aktivieren.

    Sie können Fluent Bit auch auf Amazon EC2 mit der gewünschten Konfiguration ausführen, um alle Probleme zu beheben, die sich aus der Validierung ergeben. Erstellen Sie Ihr ConfigMap mit einem der folgenden Beispiele.

    Wichtig

    Die Amazon-EKS-Fargate-Protokollierung unterstützt keine dynamische Konfiguration von ConfigMaps. Alle Änderungen an ConfigMaps werden nur auf neue Pods angewendet. Änderungen werden nicht auf vorhandene Pods angewendet.

    Erstellen Sie anhand des Beispiels ein ConfigMap für Ihr gewünschtes Protokollziel.

    CloudWatch

    So erstellen Sie eine ConfigMap für CloudWatch

    Bei der Verwendung von CloudWatch haben Sie zwei Ausgabeoptionen:

    Das folgende Beispiel zeigt Ihnen, wie Sie das cloudwatch_logs-Plug-in verwenden, um Protokolle an CloudWatch zu senden.

    1. Speichern Sie den folgenden Inhalt in einer Datei namens aws-logging-cloudwatch-configmap.yaml. Ersetzen Sie region-code durch die AWS-Region, in der sich Ihr Cluster befindet. Die Parameter unter [OUTPUT] sind erforderlich.

      kind: ConfigMap apiVersion: v1 metadata: name: aws-logging namespace: aws-observability data: output.conf: | [OUTPUT] Name cloudwatch_logs Match * region region-code log_group_name fluent-bit-cloudwatch log_stream_prefix from-fluent-bit- auto_create_group true log_key log parsers.conf: | [PARSER] Name crio Format Regex Regex ^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<logtag>P|F) (?<log>.*)$ Time_Key time Time_Format %Y-%m-%dT%H:%M:%S.%L%z filters.conf: | [FILTER] Name parser Match * Key_name log Parser crio
    2. Wenden Sie das Manifest auf Ihren Cluster an.

      kubectl apply -f aws-logging-cloudwatch-configmap.yaml
    3. Laden Sie die CloudWatch IAM-Richtlinie auf Ihren Computer herunter. Sie können die Richtlinie auch auf GitHub anzeigen.

      curl -o permissions.json https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/cloudwatchlogs/permissions.json
    Amazon OpenSearch Service

    Eine ConfigMap für Amazon OpenSearch Service erstellen

    Wenn Sie Protokolle an Amazon OpenSearch Service senden möchten, können Sie die es-Ausgabe verwenden, ein in C geschriebenes Plugin. Das folgende Beispiel zeigt Ihnen, wie Sie das Plugin verwenden, um Protokolle an OpenSearch zu senden.

    1. Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen aws-logging-opensearch-configmap.yaml. Ersetzen Sie jede example-value durch Ihre eigenen Werte.

      kind: ConfigMap apiVersion: v1 metadata: name: aws-logging namespace: aws-observability data: output.conf: | [OUTPUT] Name es Match * Host search-example-gjxdcilagiprbglqn42jsty66y.region-code.es.amazonaws.com Port 443 Index example Type example_type AWS_Auth On AWS_Region region-code tls On
    2. Wenden Sie das Manifest auf Ihren Cluster an.

      kubectl apply -f aws-logging-opensearch-configmap.yaml
    3. Laden Sie die OpenSearch-IAM-Richtlinie auf Ihren Computer herunter. Sie können die Richtlinie auch auf GitHub anzeigen.

      curl -o permissions.json https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/amazon-elasticsearch/permissions.json

      Stellen Sie sicher, dass die Zugriffssteuerung von OpenSearch Dashboards richtig konfiguriert ist. Dem all_access role in OpenSearch-Dashboards muss die Fargate-Pod-Ausführungsrolle und die IAM-Rolle zugeordnet sein. Das gleiche Mapping muss für die security_manager-Rolle durchgeführt werden. Sie können die vorherigen Zuordnungen hinzufügen, indem Sie Menu, dann Security, dann Roles und dann die entsprechenden Rollen auswählen. Weitere Informationen finden Sie unter Wie behebe ich Probleme mit CloudWatch Logs, damit es an meine Amazon-ES-Domäne gestreamt wird?.

    Kinesis Data Firehose

    So erstellen Sie eine ConfigMap für Kinesis Data Firehose

    Beim Senden von Protokollen an Kinesis Data Firehose gibt es zwei Ausgabeoptionen:

    Das folgende Beispiel zeigt Ihnen, wie Sie das kinesis_firehose-Plugin verwenden, um Protokolle an Kinesis Data Firehose zu senden.

    1. Speichern Sie den folgenden Inhalt in einer Datei namens aws-logging-firehose-configmap.yaml. Ersetzen Sie region-code durch die AWS-Region, in der sich Ihr Cluster befindet.

      kind: ConfigMap apiVersion: v1 metadata: name: aws-logging namespace: aws-observability data: output.conf: | [OUTPUT] Name kinesis_firehose Match * region region-code delivery_stream my-stream-firehose
    2. Wenden Sie das Manifest auf Ihren Cluster an.

      kubectl apply -f aws-logging-firehose-configmap.yaml
    3. Laden Sie die Kinesis-Data-Firehose-IAM-Richtlinie auf Ihren Computer herunter. Sie können die Richtlinie auch auf GitHub anzeigen.

      curl -o permissions.json https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/kinesis-firehose/permissions.json
  3. Erstellen Sie eine IAM-Richtlinie aus der Richtliniendatei, die Sie in einem vorherigen Schritt heruntergeladen haben.

    aws iam create-policy --policy-name eks-fargate-logging-policy --policy-document file://permissions.json
  4. Hängen Sie die IAM-Richtlinie an die Pod-Ausführungsrolle an, die für Ihr Fargate-Profil angegeben ist, mit dem folgenden Befehl. Ersetzen Sie 111122223333 durch Ihre Konto-ID. Ersetzen Sie AmazonEKSFargatePodExecutionRole durch Ihre Pod-Ausführungsrolle (weitere Informationen finden Sie unter Erstellen einer Fargate-pod-Ausführungsrolle). Wenn sich Ihr Cluster in den AWS-Regionen AWS GovCloud (USA Ost) oder AWS GovCloud (USA West) befindet, ersetzen Sie arn:aws: durch arn:aws-us-gov:.

    aws iam attach-role-policy \ --policy-arn arn:aws:iam::111122223333:policy/eks-fargate-logging-policy \ --role-name AmazonEKSFargatePodExecutionRole

Kubernetes-Filter-Support

Diese Funktion erfordert die folgende minimale Kubernetes-Version und Plattformebene oder höher.

Kubernetes-Version Plattformebene
1.22 und höher eks.1
1.21 eks.3
1.20 eks.3
1.19 eks.7
1.18 eks.9

Der Fluent Bit-Kubernetes-Filter ermöglicht es Ihnen, Kubernetes-Metadaten zu Ihren Protokolldateien hinzuzufügen. Weitere Informationen über den Filter finden Sie unter Kubernetes in der Fluent Bit-Dokumentation. Sie können einen Filter unter Verwendung des Endpunkts des API-Servers anwenden.

filters.conf: | [FILTER] Name kubernetes Match kube.* Merge_Log On Buffer_Size 0 Kube_Meta_Cache_TTL 300s
Wichtig
  • Kube_URL,Kube_CA_File,Kube_Token_Command, und Kube_Token_File sind Konfigurationsparameter im Dienstbesitz und dürfen nicht angegeben werden. Amazon-EKS-Fargate füllt diese Werte aus.

  • Kube_Meta_Cache_TTL ist die Zeit, in der Fluent Bit wartet, bis es mit dem API-Server für die neuesten Metadaten kommuniziert. Wenn Kube_Meta_Cache_TTL nicht angegeben wird, dann hängt Amazon-EKS-Fargate einen Standardwert von 30 Minuten an, um die Belastung des API-Servers zu verringern.

Fluent Bit-Prozessprotokolle an Ihr Konto senden

Sie können Fluent Bit-Prozessprotokolle mit der folgenden ConfigMap an Amazon CloudWatch senden. Ersetzen Sie region-code durch die AWS-Region, in der sich Ihr Cluster befindet.

kind: ConfigMap apiVersion: v1 metadata: name: aws-logging namespace: aws-observability labels: data: # Configuration files: server, input, filters and output # ====================================================== flb_log_cw: "true" #ships fluent-bit process logs to CloudWatch output.conf: | [OUTPUT] Name cloudwatch Match kube.* region region-code log_group_name fluent-bit-cloudwatch log_stream_prefix from-fluent-bit- auto_create_group true

Die Protokolle befinden sich in der AWS-Region, in der sich der Cluster unter CloudWatch befindet. Der Name der Protokollgruppe lautet my-cluster-fluent-bit-logs und der Name des Fluent Bit-Logstreams lautet fluent-bit-podname-pod-namespace.

Anmerkung
  • Die Prozessprotokolle werden nur ausgeliefert, wenn der Fluent Bit-Prozess erfolgreich gestartet wird. Wenn beim Starten von Fluent Bit ein Fehler auftritt, werden die Prozessprotokolle verpasst. Sie können nur Prozessprotokolle an CloudWatch senden.

  • Um Fehler beim Senden von Prozessprotokollen an Ihr Konto zu beheben, können Sie die vorherige ConfigMap verwenden, um die Prozessprotokolle abzurufen. Dass Fluent Bit nicht gestartet werden kann, liegt normalerweise daran, dass Ihre ConfigMap beim Starten nicht von Fluent Bit analysiert oder akzeptiert wird.

Testanwendung

  1. Stellen Sie einen Beispiel-Pod bereit.

    1. Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen sample-app.yaml auf Ihrem Computer.

      apiVersion: apps/v1 kind: Deployment metadata: name: sample-app namespace: same-namespace-as-your-fargate-profile spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - name: http containerPort: 80
    2. Wenden Sie das Manifest auf den Cluster an.

      kubectl apply -f sample-app.yaml
  2. Zeigen Sie die NGINX-Protokolle mit den Zielen an, die Sie im ConfigMap.

Größenüberlegungen

Wir empfehlen Ihnen, für den Protokoll-Router bis zu 50 MB Speicher einzuplanen. Wenn Sie erwarten, dass Ihre Anwendung Protokolle mit sehr hohem Durchsatz generiert, sollten Sie bis zu 100 MB einplanen.

Fehlerbehebung

Um zu überprüfen, ob die Protokollierungsfunktion aus irgendeinem Grund aktiviert oder deaktiviert ist, z. B. ein ungültiges ConfigMap, und warum es ungültig ist, überprüfen Sie Ihre Pod-Ereignisse mit kubectl describe pod pod_name. Die Ausgabe kann Pod-Ereignisse enthalten, die klarstellen, ob die Protokollierung aktiviert ist oder nicht, wie die folgende Beispielausgabe.

... Annotations: CapacityProvisioned: 0.25vCPU 0.5GB Logging: LoggingDisabled: LOGGING_CONFIGMAP_NOT_FOUND kubernetes.io/psp: eks.privileged ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning LoggingDisabled <unknown> fargate-scheduler Disabled logging because aws-logging configmap was not found. configmap "aws-logging" not found

Die Pod-Ereignisse sind kurzlebig mit einem Zeitraum, der von den Einstellungen abhängt. Sie können die Anmerkungen eines Pods auch mit kubectl describe pod pod-name anzeigen. In der Pod-Anmerkung finden Sie Informationen darüber, ob die Protokollierungsfunktion aktiviert oder deaktiviert ist, und den Grund.