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.
# Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner
Sie können Amazon ECS verwenden FireLens , um Aufgabendefinitionsparameter zu verwenden, um Protokolle zur Protokollspeicherung und Analyse an ein AWS Service- oder AWS Partner Network (APN-) Ziel weiterzuleiten. The AWS Partner Network ist eine globale Partnergemeinschaft, die Programme, Fachwissen und Ressourcen nutzt, um Kundenangebote aufzubauen, zu vermarkten und zu verkaufen. Weitere Informationen finden Sie unter [AWS Partner](https://aws.amazon.com/partners/work-with-partners/). FireLens arbeitet mit [Fluentd](https://www.fluentd.org/) und [Fluent Bit](https://fluentbit.io/). Wir stellen AWS für das Fluent Bit-Image bereit oder Sie können Ihr eigenes Fluentd- oder Fluent Bit-Image verwenden.
Standardmäßig konfiguriert Amazon ECS die Container-Abhängigkeit so, dass der Firelens-Container vor jedem Container gestartet wird, der ihn verwendet. Der Firelens-Container stoppt auch, nachdem alle Container, die ihn verwenden, angehalten sind.
Um diese Funktion nutzen zu können, müssen Sie eine IAM-Rolle für Ihre Aufgaben erstellen, die für die Nutzung aller AWS Dienste erforderlich sind, die für die Aufgaben erforderlich sind. Wenn ein Container beispielsweise Protokolle an Firehose weiterleitet, erfordert die Aufgabe die Berechtigung zum Aufrufen der `firehose:PutRecordBatch`-API. Informationen finden Sie im Abschnitt [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) im *IAM-Benutzerhandbuch*.
Unter den folgenden Bedingungen kann für Ihre Aufgabe auch die Amazon-ECS-Aufgabenausführungsrolle erforderlich sein. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Aufgabenausführung](task_execution_IAM_role.md).
+ Wenn Ihre Aufgabe auf Fargate gehostet wird und Sie Container-Images aus Amazon ECR abrufen oder sensible Daten aus AWS Secrets Manager Ihrer Protokollkonfiguration referenzieren, müssen Sie die IAM-Rolle für die Aufgabenausführung angeben.
+ Wenn Sie eine benutzerdefinierte Konfigurationsdatei verwenden, die in Amazon S3 gehostet wird, muss Ihre IAM-Rolle für die Aufgabenausführung die `s3:GetObject`-Berechtigung enthalten.
Beachten Sie bei der Verwendung FireLens für Amazon ECS Folgendes:
+ Wir empfehlen, dass Sie dem Protokoll `my_service_` den Namen des Protokoll-Containers hinzufügen, damit Sie die Container-Namen in der Konsole leicht unterscheiden können.
+ Amazon ECS fügt standardmäßig eine Start-Abhängigkeit zwischen den Anwendungs-Containern und dem FireLens-Container hinzu. Wenn Sie eine Container-Reihenfolge zwischen den Anwendungscontainern und dem FireLens-Container angeben, wird die standardmäßige Reihenfolge der Startcontainer außer Kraft gesetzt.
+ FireLens für Amazon ECS wird für Aufgaben unterstützt, die sowohl auf AWS Fargate unter Linux als auch auf Amazon EC2 unter Linux gehostet werden. Windows-Container unterstützen FireLens nicht.
Informationen zur Konfiguration der zentralen Protokollierung für Windows-Container finden Sie unter [Zentralisierte Protokollierung für Windows-Container auf Amazon ECS mit Fluent Bit](https://aws.amazon.com/blogs/containers/centralized-logging-for-windows-containers-on-amazon-ecs-using-fluent-bit/).
+ Sie können CloudFormation Vorlagen zur Konfiguration FireLens für Amazon ECS verwenden. Weitere Informationen finden Sie [AWS::ECS::TaskDefinition FirelensConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-firelensconfiguration.html)im *AWS CloudFormation Benutzerhandbuch*
+ FireLensüberwacht den Port. Um also sicherzustellen`24224`, dass der FireLens Log Router außerhalb der Aufgabe nicht erreichbar ist, dürfen Sie keinen eingehenden Verkehr über den Port `24224` in der Sicherheitsgruppe zulassen, die Ihre Aufgabe verwendet. Für Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, ist dies die der Aufgabe zugeordnete Sicherheitsgruppe. Für Aufgaben, die den `host`-Netzwerkmodus verwenden, ist dies die Sicherheitsgruppe, die der Amazon-EC2-Instance zugeordnet ist, die die Aufgabe hostet. Für Aufgaben, die den `bridge`-Netzwerkmodus verwenden, erstellen Sie keine Portzuordnungen, die Port `24224` verwenden.
+ Bei Aufgaben, die den `bridge` Netzwerkmodus verwenden, muss der Container mit der FireLens Konfiguration vor allen Anwendungscontainern, die darauf angewiesen sind, gestartet werden. Um die Startreihenfolge Ihrer Container zu steuern, verwenden Sie Abhängigkeitsbedingungen in der Aufgabendefinition. Weitere Informationen finden Sie unter [Container-Abhängigkeit](task_definition_parameters.md#container_definition_dependson).
**Anmerkung**
Wenn Sie Parameter für Abhängigkeitsbedingungen in Containerdefinitionen mit einer FireLens Konfiguration verwenden, stellen Sie sicher, dass für jeden Container eine `START` `HEALTHY` Oder-Bedingung erforderlich ist.
+ FireLensFügt standardmäßig den Namen der Cluster- und Aufgabendefinition sowie den Amazon-Ressourcennamen (ARN) des Clusters als Metadatenschlüssel zu Ihren stdout/stderr Container-Logs hinzu. Nachfolgend ist ein Beispiel für das Metadatenformat.
```
"ecs_cluster": "cluster-name",
"ecs_task_arn": "arn:aws:ecs:region:111122223333:task/cluster-name/f2ad7dba413f45ddb4EXAMPLE",
"ecs_task_definition": "task-def-name:revision",
```
Wenn Sie die Metadaten nicht in Ihren Protokollen haben möchten, setzen Sie `enable-ecs-log-metadata` zu `false` im `firelensConfiguration`-Abschnitt der Aufgabendefinition.
```
"firelensConfiguration":{
"type":"fluentbit",
"options":{
"enable-ecs-log-metadata":"false",
"config-file-type":"file",
"config-file-value":"/extra.conf"
}
```
Sie können den FireLens Container so konfigurieren, dass er als Benutzer ausgeführt wird, der kein Root-Benutzer ist. Berücksichtigen Sie dabei Folgendes:
+ Um den FireLens Container so zu konfigurieren, dass er als Nicht-Root-Benutzer ausgeführt wird, müssen Sie den Benutzer in einem der folgenden Formate angeben:
+ `uid`
+ `uid:gid`
+ `uid:group`
Weitere Informationen zur Angabe eines Benutzers in einer Container-Definition finden Sie [ContainerDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html)in der *Amazon Elastic Container Service API-Referenz*.
Der FireLens Container empfängt Anwendungsprotokolle über einen UNIX Socket. Der Amazon ECS-Agent verwendet den`uid`, um dem FireLens Container den Besitz des Socket-Verzeichnisses zuzuweisen.
+ Die Konfiguration des FireLens Containers für die Ausführung als Nicht-Root-Benutzer wird in der Amazon ECS-Agent-Version `1.96.0` und höher sowie in der Amazon ECS-optimierten AMI-Version `v20250716` und höher unterstützt.
+ Wenn Sie einen Benutzer für den FireLens Container angeben, muss dieser eindeutig sein und `uid` darf nicht für andere Prozesse verwendet werden, die zu anderen Containern in der Aufgabe oder der Container-Instance gehören.
Informationen zur Verwendung mehrerer Konfigurationsdateien mit Amazon ECS, einschließlich Dateien, die Sie hosten, oder Dateien in Amazon S3, finden Sie unter [Init-Prozess für Fluent Bit in ECS, Unterstützung für mehrfache Konfigurationen](https://github.com/aws/aws-for-fluent-bit/tree/mainline/use_cases/init-process-for-fluent-bit).
Informationen zu Beispielkonfigurationen finden Sie unter[Beispiel einer Amazon-ECS-Aufgabendefinition: Protokolle an FireLens weiterleiten](firelens-taskdef.md).
Weitere Informationen zur Konfiguration von Protokollen für hohen Durchsatz finden Sie unter[Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz](firelens-docker-buffer-limit.md).
# Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz
Für Szenarien mit hohem Protokolldurchsatz empfehlen wir, den `awsfirelens` Protokolltreiber mit FireLens und zu verwenden. Fluent Bit Fluent Bitist ein leichter Protokollprozessor, der effizient mit Ressourcen umgeht und Millionen von Protokolldatensätzen verarbeiten kann. Um eine optimale Leistung im großen Maßstab zu erreichen, ist jedoch eine Anpassung der Konfiguration erforderlich.
In diesem Abschnitt werden fortgeschrittene Fluent Bit Optimierungstechniken für den Umgang mit hohem Protokolldurchsatz bei gleichzeitiger Wahrung der Systemstabilität und Vermeidung von Datenverlusten behandelt.
Hinweise zur Verwendung von benutzerdefinierten Konfigurationsdateien mit FireLens finden Sie unter[Eine benutzerdefinierte Konfigurationsdatei verwenden](firelens-taskdef.md#firelens-taskdef-customconfig). Weitere Beispiele finden Sie unter [Amazon FireLens ECS-Beispiele](https://github.com/aws-samples/amazon-ecs-firelens-examples) unter GitHub.
**Anmerkung**
Einige Konfigurationsoptionen in diesem Abschnitt, wie z. B. `workers` und`threaded`, sind AWS für Fluent Bit Version 3 oder höher erforderlich. Informationen zu verfügbaren Versionen finden Sie unter [AWS Fluent Bit-Versionen](https://github.com/aws/aws-for-fluent-bit/releases).
## Chunks verstehen
Fluent Bit*verarbeitet Daten in Einheiten, die als Chunks bezeichnet werden.* Wenn ein INPUT-Plugin Daten empfängt, erstellt die Engine einen Block, der im Speicher oder im Dateisystem gespeichert wird, bevor er an OUTPUT-Ziele gesendet wird.
Das Pufferverhalten hängt von der `storage.type` Einstellung in Ihren INPUT-Abschnitten ab. Fluent BitVerwendet standardmäßig die Speicherpufferung. Bei Hochdurchsatz- oder Produktionsszenarien bietet die Dateisystempufferung eine bessere Stabilität.
[Weitere Informationen finden Sie in der Fluent Bit Dokumentation unter [Chunks](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks) und Was ist ein Chunk?](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk) im Repository AWS für Fluent Bit Beispiele.
## Speicherpufferung (Standard)
Fluent BitVerwendet standardmäßig Speicherpufferung ()`storage.type memory`. Mit dem `Mem_Buf_Limit` Parameter können Sie die Speichernutzung pro INPUT-Plugin einschränken.
Das folgende Beispiel zeigt eine speichergepufferte Eingabekonfiguration:
```
[INPUT]
Name tcp
Tag ApplicationLogs
Port 5170
storage.type memory
Mem_Buf_Limit 5MB
```
**Wichtig**
Wenn `Mem_Buf_Limit` der Wert für ein Plugin überschritten wird, wird die Eingabe Fluent Bit unterbrochen und neue Datensätze gehen verloren. Dies kann zu Gegendruck führen und Ihre Anwendung verlangsamen. Die folgende Warnung wird in den Fluent Bit Protokollen angezeigt:
```
[input] tcp.1 paused (mem buf overlimit)
```
Die Speicherpufferung eignet sich für einfache Anwendungsfälle mit geringem bis moderatem Protokolldurchsatz. Verwenden Sie für Szenarien mit hohem Durchsatz oder Produktionsszenarien, in denen Datenverlust ein Problem darstellt, stattdessen die Dateisystempufferung.
Weitere Informationen finden Sie unter [Buffering and Memory in der Fluent Bit Dokumentation und Memory](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) [Buffering Only](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-1-memory-buffering-only-default-or-storagetype-memory) im Repository for examples. AWS Fluent Bit
## Pufferung von Dateisystemen
Für Szenarien mit hohem Durchsatz empfehlen wir die Verwendung der Dateisystempufferung. Weitere Informationen zur Fluent Bit Verwaltung von Pufferung und Speicherung finden Sie in der Dokumentation unter [Pufferung und](https://docs.fluentbit.io/manual/administration/buffering-and-storage) Speicherung. Fluent Bit
Die Pufferung von Dateisystemen bietet die folgenden Vorteile:
+ **Größere Pufferkapazität** — Festplattenspeicher ist in der Regel umfangreicher als Arbeitsspeicher.
+ **Persistenz** — Gepufferte Daten Fluent Bit überstehen Neustarts.
+ **Graduelle Verschlechterung** — Bei Ausgabeausfällen sammeln sich Daten auf der Festplatte an, anstatt zu einer Speichererschöpfung zu führen.
Um die Dateisystempufferung zu aktivieren, stellen Sie eine benutzerdefinierte Konfigurationsdatei bereit. Fluent Bit Das folgende Beispiel zeigt die empfohlene Konfiguration:
```
[SERVICE]
# Flush logs every 1 second
Flush 1
# Wait 120 seconds during shutdown to flush remaining logs
Grace 120
# Directory for filesystem buffering
storage.path /var/log/flb-storage/
# Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
storage.max_chunks_up 32
# Flush backlog chunks to destinations during shutdown (prevents log loss)
storage.backlog.flush_on_shutdown On
[INPUT]
Name forward
unix_path /var/run/fluent.sock
# Run input in separate thread to prevent blocking
threaded true
# Enable filesystem buffering for persistence
storage.type filesystem
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
# Use multiple workers for parallel processing
workers 2
# Retry failed flushes up to 15 times
retry_limit 15
# Maximum disk space for buffered data for this output
storage.total_limit_size 10G
```
Die wichtigsten Konfigurationsparameter:
`storage.path`
Das Verzeichnis, in dem gepufferte Chunks auf der Festplatte Fluent Bit gespeichert werden.
`storage.backlog.flush_on_shutdown`
Wenn diese Option aktiviert ist, wird Fluent Bit versucht, beim Herunterfahren alle Backlog-Dateisystem-Chunks an ihre Ziele zu leeren. Dies trägt dazu bei, die Datenzustellung zu gewährleisten, bevor sie Fluent Bit unterbrochen wird, kann jedoch die Zeit für das Herunterfahren verlängern.
`storage.max_chunks_up`
Die Anzahl der Chunks, die im Speicher verbleiben. Die Standardeinstellung ist 128 Chunks, was mehr als 500 MB Speicher beanspruchen kann, da jeder Chunk bis zu 4—5 MB belegen kann. In Umgebungen mit eingeschränktem Speicher sollten Sie diesen Wert verringern. Wenn Sie beispielsweise 50 MB für die Pufferung zur Verfügung haben, legen Sie diesen Wert auf 8—10 Blöcke fest.
`storage.type filesystem`
Aktiviert den Dateisystemspeicher für das Eingabe-Plugin. Wird trotz des Namens Fluent Bit verwendet, `mmap` um Chunks sowohl dem Arbeitsspeicher als auch der Festplatte zuzuordnen, wodurch Persistenz ohne Leistungseinbußen gewährleistet wird.
`storage.total_limit_size`
Der maximale Festplattenspeicher für gepufferte Daten für ein bestimmtes OUTPUT-Plugin. Wenn dieses Limit erreicht ist, werden die ältesten Datensätze für diese Ausgabe gelöscht. Weitere Informationen zur Größenbestimmung finden Sie unter[`storage.total_limit_size` verstehen](#firelens-storage-sizing).
`threaded true`
Führt die Eingabe in einem eigenen Thread aus, getrennt von Fluent Bit der Hauptereignisschleife. Dadurch wird verhindert, dass langsame Eingaben die gesamte Pipeline blockieren.
Weitere Informationen finden Sie unter [Dateisystem-Pufferung](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) in der Fluent Bit Dokumentation und [Dateisystem- und Speicherpufferung im AWS Beispiel-Repository](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem). Fluent Bit
## `storage.total_limit_size` verstehen
Der `storage.total_limit_size` Parameter jedes OUTPUT-Plug-ins steuert den maximalen Speicherplatz für gepufferte Daten für diese Ausgabe. Wenn dieses Limit erreicht ist, werden die ältesten Datensätze für diese Ausgabe gelöscht, um Platz für neue Daten zu schaffen. Wenn der Festplattenspeicher vollständig erschöpft ist, können Datensätze Fluent Bit nicht in die Warteschlange gestellt werden und sie gehen verloren.
Verwenden Sie die folgende Formel, um den entsprechenden Wert auf der `storage.total_limit_size` Grundlage Ihrer Protokollrate und des gewünschten Wiederherstellungsfensters zu berechnen:
```
If log rate is in KB/s, convert to MB/s first:
log_rate (MB/s) = log_rate (KB/s) / 1000
storage.total_limit_size (GB) = log_rate (MB/s) × duration (hours) × 3600 (seconds/hour) / 1000 (MB to GB)
```
Die folgende Tabelle zeigt Beispielberechnungen für gängige Protokollraten und Wiederherstellungsfenster:
| Protokollierungsrate | 1 Stunde | 6 Stunden | 12 Stunden | 24 Stunden |
| --- | --- | --- | --- | --- |
| 0,25 MB/s | 0,9 GB | 5,4 GB | 10,8 GB | 21,6 GB |
| 0,5 MB/s | 1,8 GB | 10,8 GB | 21,6 GB | 43,2 GB |
| 1 MB/s | 3,6 GB | 21,6 GB | 43,2 GB | 86,4 GB |
| 5 MB/s | 18 GB | 108 GB | 216 GB | 432 GB |
| 10 MB/s | 36 GB | 216 GB | 432 GB | 864 GB |
Um den Spitzendurchsatz zu beobachten und geeignete Puffergrößen auszuwählen, verwenden Sie die [Messdurchsatzprobe. FireLens ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput)
Verwenden Sie die Formel, die Beispielberechnungen und das Benchmarking, um eine geeignete Lösung auszuwählen, die bei einem `storage.total_limit_size` Ausfall die Startbahn für eine optimale Wiederherstellung bietet.
## Speicheranforderungen für Amazon ECS-Aufgaben
Summieren Sie alle `storage.total_limit_size` Werte der OUTPUT-Abschnitte und fügen Sie Puffer für Overhead hinzu. Diese Summe bestimmt den Speicherplatz, der in Ihrer Amazon ECS-Aufgabendefinition benötigt wird. Zum Beispiel 3 Ausgänge × jeweils 10 GB = 30 GB \$1 Puffer (5—10 GB) = insgesamt 35—40 GB erforderlich. Wenn die Summe den verfügbaren Speicherplatz übersteigt, Fluent Bit können Datensätze möglicherweise nicht in die Warteschlange gestellt werden und sie gehen verloren.
Die folgenden Speicheroptionen sind verfügbar:
Bind-Mounts (kurzlebiger Speicher)
+ Für AWS Fargate ist die Standardeinstellung 20 GB flüchtiger Speicher (max. 200 GB). Konfigurieren Sie die Verwendung `ephemeralStorage` in der Aufgabendefinition. Weitere Informationen finden Sie unter [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html) im *AWS CloudFormation -Benutzerhandbuch*.
+ Für EC2 ist die Standardeinstellung 30 GB, wenn das Amazon ECS-optimierte AMI verwendet wird (gemeinsam vom Betriebssystem und Docker genutzt). Erhöhen Sie den Wert, indem Sie die Größe des Root-Volumes ändern.
Amazon-EBS-Volumes
+ Bietet hochverfügbaren, langlebigen und leistungsstarken Blockspeicher.
+ Erfordert die Volume-Konfiguration und das Verweisen auf `storage.path` (Standard:`/var/log/flb-storage/`) `mountPoint` in der Aufgabendefinition.
+ Weitere Informationen finden Sie unter [Die Volume-Konfiguration auf die Startzeit in einer Amazon-ECS-Aufgabendefinition verschieben](specify-ebs-config.md).
Amazon EFS-Volumes
+ Bietet einfachen, skalierbaren Dateispeicher.
+ Erfordert die Volume-Konfiguration und das Verweisen auf `storage.path` (Standard:`/var/log/flb-storage/`) `mountPoint` in der Aufgabendefinition.
+ Weitere Informationen finden Sie unter [Ein Amazon-EFS-Dateisystems in einer Amazon-ECS-Aufgabendefinition angeben](specify-efs-config.md).
Weitere Hinweise zu Datenvolumen finden Sie unter[Speicheroptionen für Amazon-ECS-Aufgaben](using_data_volumes.md).
## Optimieren Sie die Ausgabekonfiguration
Netzwerkprobleme, Dienstausfälle und Drosselung von Zielen können die Übermittlung von Protokollen verhindern. Die richtige Ausgangskonfiguration gewährleistet Ausfallsicherheit ohne Datenverlust.
Wenn ein Output-Flush fehlschlägt, Fluent Bit kann der Vorgang erneut versucht werden. Die folgenden Parameter steuern das Verhalten bei Wiederholungsversuchen:
`retry_limit`
Die maximale Anzahl von Wiederholungen nach dem ersten Versuch vor dem Löschen von Datensätzen. Der Standardwert ist 1. `retry_limit 3`Bedeutet beispielsweise insgesamt 4 Versuche (1 erster Versuch \$1 3 Wiederholungen). Für Produktionsumgebungen empfehlen wir 15 oder mehr, was einen Ausfall von mehreren Minuten mit exponentiellem Backoff abdeckt.
Auf `no_limits` oder `False` für unendliche Wiederholungsversuche setzen:
+ Bei der Speicherpufferung führen unendliche Wiederholungen dazu, dass das Eingabe-Plugin pausiert, wenn die Speichergrenzen erreicht sind.
+ Bei der Dateisystempufferung werden die ältesten Datensätze gelöscht, wenn sie erreicht sind. `storage.total_limit_size`
Wenn alle Wiederholungsversuche ausgeschöpft sind (1 anfänglich \$1 `retry_limit` Wiederholungen), werden die Datensätze gelöscht. AWS Plugins mit `auto_retry_requests true` (Standard) bieten vor Fluent Bit dem Wiederholungsmechanismus eine zusätzliche Wiederholungsebene. Weitere Informationen finden Sie in der Dokumentation unter [Konfigurieren von Wiederholungen](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries). Fluent Bit
`retry_limit 3`Mit den Standardeinstellungen bietet (, `scheduler.base 5``scheduler.cap 2000`,`net.connect_timeout 10s`) beispielsweise etwa 70 Sekunden Wartezeit im Scheduler (10 s \$1 20 s \$1 40 s), 40 Sekunden Timeouts für Netzwerkverbindungen (4 Versuche × 10 s) sowie AWS Plugin-Wiederholungen — insgesamt etwa 2—10 Minuten, abhängig von den Netzwerkbedingungen und den TCP-Timeouts des Betriebssystems.
`scheduler.base`
Die Basissekunden zwischen Wiederholungen (Standard: 5). Wir empfehlen 10 Sekunden.
`scheduler.cap`
Die maximale Anzahl von Sekunden zwischen Wiederholungen (Standard: 2000). Wir empfehlen 60 Sekunden.
Bei der Wartezeit zwischen Wiederholungen wird ein exponentieller Backoff mit Jitter verwendet:
```
wait_time = random(base, min(base × 2^retry_number, cap))
```
Zum Beispiel mit und: `scheduler.base 10` `scheduler.cap 60`
+ Erster Versuch: zufällige Wartezeit zwischen 10 und 20 Sekunden
+ Zweiter Wiederholungsversuch: zufällige Wartezeit zwischen 10—40 Sekunden
+ Dritter Wiederholungsversuch und später: zufällige Wartezeit zwischen 10—60 Sekunden (begrenzt)
[Weitere Informationen finden Sie in der Dokumentation unter [Wartezeit für Wiederholungsversuche konfigurieren und Netzwerk](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry).](https://docs.fluentbit.io/manual/administration/networking) Fluent Bit
`workers`
Die Anzahl der Threads für die parallel Ausgangsverarbeitung. Mehrere Worker ermöglichen gleichzeitige Löschvorgänge, wodurch der Durchsatz bei der Verarbeitung vieler Blöcke verbessert wird.
`auto_retry_requests`
Eine AWS Plugin-spezifische Einstellung, die vor dem integrierten Wiederholungsmechanismus eine zusätzliche Wiederholungsebene bietet. Fluent Bit Der Standardwert ist `true`. Wenn diese Option aktiviert ist, wiederholt das AWS Ausgabe-Plug-In intern fehlgeschlagene Anfragen erneut, bevor die Anfrage als fehlgeschlagener Flush betrachtet wird und von der Konfiguration abhängt. `retry_limit`
Der `Grace` Parameter in `[SERVICE]` diesem Abschnitt legt fest, wie lange es dauert, bis die gepufferten Fluent Bit Daten geleert werden, wenn das System heruntergefahren wird. Der `Grace` Zeitraum muss mit dem des Containers abgestimmt werden. `stopTimeout` Stellen Sie sicher, dass der `Grace` Zeitraum `stopTimeout` überschritten wird, Fluent Bit damit der Spülvorgang vor dem Empfang `SIGKILL` abgeschlossen werden kann. Wenn der Wert beispielsweise 120 Sekunden `Grace` beträgt, stellen Sie ihn `stopTimeout` auf 150 Sekunden ein.
Das folgende Beispiel zeigt eine vollständige Fluent Bit Konfiguration mit allen empfohlenen Einstellungen für Szenarien mit hohem Durchsatz:
```
[SERVICE]
# Flush logs every 1 second
Flush 1
# Wait 120 seconds during shutdown to flush remaining logs
Grace 120
# Directory for filesystem buffering
storage.path /var/log/flb-storage/
# Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
storage.max_chunks_up 32
# Flush backlog chunks to destinations during shutdown (prevents log loss)
storage.backlog.flush_on_shutdown On
# Minimum seconds between retries
scheduler.base 10
# Maximum seconds between retries (exponential backoff cap)
scheduler.cap 60
[INPUT]
Name forward
unix_path /var/run/fluent.sock
# Run input in separate thread to prevent blocking
threaded true
# Enable filesystem buffering for persistence
storage.type filesystem
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
# Use multiple workers for parallel processing
workers 2
# Retry failed flushes up to 15 times
retry_limit 15
# Maximum disk space for buffered data for this output
storage.total_limit_size 10G
```
## Datenverlustszenarien verstehen
Bei längeren Ausfällen oder Problemen mit Ausgabezielen können Datensätze verloren gehen. Bei den Konfigurationsempfehlungen in diesem Handbuch handelt es sich um Methoden zur Minimierung von Datenverlusten, es kann jedoch nicht garantiert werden, dass bei längeren Ausfällen kein Datenverlust auftritt. Das Verständnis dieser Szenarien hilft Ihnen bei der KonfigurationFluent Bit, um die Ausfallsicherheit zu maximieren.
Datensätze können auf zwei Arten verloren gehen: Die ältesten Datensätze werden gelöscht, wenn der Speicher voll ist, oder die neuesten Datensätze werden zurückgewiesen, wenn das System keine weiteren Daten akzeptieren kann.
### Die ältesten Datensätze wurden gelöscht
Die ältesten gepufferten Datensätze werden gelöscht, wenn die Wiederholungsversuche erschöpft sind oder wenn sie `storage.total_limit_size` voll sind und Platz für neue Daten geschaffen werden muss.
Das Limit für Wiederholungsversuche wurde überschritten
Tritt auf, nachdem AWS das Plugin erneut versucht hat (wenn`auto_retry_requests true`) plus einem ersten Fluent Bit Versuch plus `retry_limit` Wiederholungen. Um dies zu vermeiden, legen Sie `retry_limit no_limits` pro OUTPUT-Plugin eine unendliche Anzahl von Wiederholungsversuchen fest:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
retry_limit no_limits
auto_retry_requests true
```
Unendliche Wiederholungsversuche verhindern, dass Datensätze gelöscht werden, weil die Wiederholungsversuche erschöpft sind, können aber dazu führen, dass sie voll werden. `storage.total_limit_size`
Speicherlimit erreicht (Dateisystem-Pufferung)
Tritt auf, wenn das Ausgabeziel länger nicht verfügbar ist, als Ihr konfigurierter Puffer speichern `storage.total_limit_size` kann. Ein Puffer von 10 GB bei einer MB/s Protokollrate von 1 bietet beispielsweise eine Pufferung von etwa 2,7 Stunden. Um dies zu vermeiden, erhöhen Sie die Anzahl `storage.total_limit_size` pro OUTPUT-Plugin und stellen Sie ausreichend Amazon ECS-Aufgabenspeicher bereit:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
storage.total_limit_size 10G
```
### Die neuesten Datensätze wurden zurückgewiesen
Die neuesten Datensätze werden gelöscht, wenn der Festplattenspeicher erschöpft ist oder wenn die Eingabe aufgrund von unterbrochen wird. `Mem_Buf_Limit`
Festplattenspeicher erschöpft (Dateisystem-Pufferung)
Tritt auf, wenn der Festplattenspeicher vollständig erschöpft ist. Fluent Bitkann neue Datensätze nicht in die Warteschlange stellen und sie gehen verloren. Um dies zu vermeiden, summieren Sie alle `storage.total_limit_size` Werte und stellen Sie einen angemessenen Amazon ECS-Aufgabenspeicher bereit. Weitere Informationen finden Sie unter [Speicheranforderungen für Amazon ECS-Aufgaben](#firelens-storage-task-requirements).
Speicherlimit erreicht (Speicherpufferung)
Tritt auf, wenn das Ausgabeziel nicht verfügbar ist und der Speicherpuffer voll ist. Pausierte Eingabe-Plugins akzeptieren keine neuen Datensätze mehr. Zur Minderung, zur Erhöhung der Widerstandsfähigkeit oder `storage.type filesystem` zur Erhöhung der Widerstandsfähigkeit verwenden. `Mem_Buf_Limit`
### Bewährte Methoden zur Minimierung von Datenverlusten
Beachten Sie die folgenden bewährten Methoden zur Minimierung von Datenverlusten:
+ **Dateisystem-Pufferung verwenden — Diese** Option sorgt `storage.type filesystem` für eine bessere Ausfallsicherheit bei Ausfällen.
+ **Speicher angemessen dimensionieren** — Die Berechnung `storage.total_limit_size` basiert auf der Protokollrate und dem gewünschten Wiederherstellungsfenster.
+ Stellen **Sie eine angemessene Festplatte** bereit — Stellen Sie sicher, dass die Amazon ECS-Aufgabe über ausreichend kurzlebigen Speicher, Amazon EBS oder Amazon EFS verfügt.
+ **Wiederholungsverhalten konfigurieren — Ausgewogen zwischen `retry_limit` (löscht Datensätze nach anstrengenden Wiederholungsversuchen**) und `no_limits` (Wiederholungen auf unbestimmte Zeit, können aber Speicherplatz füllen).
## Verwenden Sie aus Gründen der Zuverlässigkeit die Protokollierung für mehrere Ziele
Durch das Senden von Protokollen an mehrere Ziele werden einzelne Fehlerquellen vermieden. Wenn CloudWatch Logs beispielsweise ausfällt, erreichen die Protokolle immer noch Amazon S3.
Die Protokollierung mehrerer Ziele bietet die folgenden Vorteile. Das Amazon S3 S3-Ausgabe-Plugin unterstützt auch Komprimierungsoptionen wie Gzip und Parquet-Format, wodurch die Speicherkosten gesenkt werden können. Weitere Informationen finden Sie in der Fluent Bit Dokumentation unter [S3-Komprimierung](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression).
Die Protokollierung mehrerer Ziele kann die folgenden Vorteile bieten:
+ **Redundanz** — Wenn ein Ziel ausfällt, erreichen die Protokolle immer noch das andere.
+ **Wiederherstellung** — Rekonstruieren Sie Lücken in einem System vom anderen.
+ **Haltbarkeit** — Archivieren Sie Protokolle zur langfristigen Aufbewahrung in Amazon S3.
+ **Kostenoptimierung** — Bewahren Sie aktuelle Protokolle in einem schnellen Abfrageservice wie CloudWatch Logs mit kürzerer Aufbewahrung auf und archivieren Sie gleichzeitig alle Protokolle zur langfristigen Aufbewahrung auf kostengünstigerem Amazon S3 S3-Speicher.
Die folgende Fluent Bit Konfiguration sendet CloudWatch Protokolle sowohl an Logs als auch an Amazon S3:
```
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
workers 2
retry_limit 15
[OUTPUT]
Name s3
Match *
bucket my-logs-bucket
region us-west-2
total_file_size 100M
s3_key_format /fluent-bit-logs/$(ecs_task_id)/%Y%m%d/%H/%M/$UUID
upload_timeout 10m
# Maximum disk space for buffered data for this output
storage.total_limit_size 5G
```
Beide Ausgaben verwenden dasselbe `Match *` Muster, sodass alle Datensätze unabhängig voneinander an beide Ziele gesendet werden. Während eines Ausfalls eines Ziels fließen die Protokolle weiter zum anderen, während sich fehlgeschlagene Leerungen im Dateisystempuffer ansammeln, sodass sie es später erneut versuchen können.
## Verwenden Sie die dateibasierte Protokollierung mit dem Tail-Input-Plugin
Für Szenarien mit hohem Durchsatz, in denen der Verlust von Protokollen ein kritisches Problem darstellt, können Sie einen alternativen Ansatz verwenden: Lassen Sie Ihre Anwendung Protokolle in Dateien auf der Festplatte schreiben und konfigurieren Sie sie so, dass sie mithilfe des Fluent Bit `tail` Eingabe-Plug-ins gelesen werden. Bei diesem Ansatz wird die Treiberschicht für die Docker-Protokollierung vollständig umgangen.
Die dateibasierte Protokollierung mit dem Tail-Plugin bietet die folgenden Vorteile:
+ **Offset-Tracking** — Das Tail-Plugin kann Datei-Offsets in einer Datenbankdatei speichern (mit der `DB` Option) und sorgt so für Stabilität bei Neustarts. Fluent Bit Dies trägt dazu bei, den Verlust von Protokollen bei Container-Neustarts zu verhindern.
+ **Pufferung auf Eingabeebene** — Sie können die Speicherpuffergrenzen direkt im Eingabe-Plugin konfigurieren`Mem_Buf_Limit`, sodass Sie die Speichernutzung genauer steuern können.
+ **Vermeidet Docker-Overhead** — Protokolle werden direkt von Datei zu Datei übertragen, Fluent Bit ohne die Protokollpuffer von Docker zu durchlaufen.
Um diesen Ansatz zu verwenden, muss Ihre Anwendung Protokolle statt in Dateien schreiben. `stdout` Sowohl der Anwendungscontainer als auch der Fluent Bit Container mounten ein gemeinsam genutztes Volume, auf dem die Protokolldateien gespeichert werden.
Das folgende Beispiel zeigt eine Konfiguration mit Tail-Eingaben mit bewährten Methoden:
```
[INPUT]
Name tail
# File path or glob pattern to tail
Path /var/log/app.log
# Database file for storing file offsets (enables resuming after restart)
DB /var/log/flb_tail.db
# when true, controls that only fluent-bit will access the database (improves performance)
DB.locking true
# Skip long lines instead of skipping the entire file
Skip_Long_Lines On
# How often (in seconds) to check for new files matching the glob pattern
Refresh_Interval 10
# Extra seconds to monitor a file after rotation to account for pending flush
Rotate_Wait 30
# Maximum size of the buffer for a single line
Buffer_Max_Size 10MB
# Initial allocation size for reading file data
Buffer_Chunk_Size 1MB
# Maximum memory buffer size (tail pauses when full)
Mem_Buf_Limit 75MB
```
Beachten Sie bei der Verwendung des Tail-Input-Plug-ins Folgendes:
+ Implementieren Sie die Protokollrotation für Ihre Anwendungsprotokolle, um eine Überlastung der Festplatte zu verhindern. Überwachen Sie die zugrunde liegenden Volumenmetriken, um die Leistung zu messen.
+ Erwägen Sie Einstellungen wie `Ignore_Older``Read_from_Head`, und mehrzeilige Parser, die auf Ihrem Protokollformat basieren.
Weitere Informationen finden Sie in der Dokumentation unter [Tail](https://docs.fluentbit.io/manual/pipeline/inputs/tail). Fluent Bit Bewährte Methoden finden Sie unter [Tail-Konfiguration mit bewährten Methoden](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) im Leitfaden AWS zur Fluent Bit Fehlerbehebung.
## Loggen Sie sich direkt ein bei FireLens
Wenn der `awsfirelens`-Protokolltreiber in einer Aufgabendefinition angegeben wird, injiziert der Amazon ECS Container-Agent die folgenden Umgebungsvariablen in den Container:
`FLUENT_HOST`
Die IP-Adresse, die dem FireLens Container zugewiesen ist.
Wenn Sie EC2 im `bridge` Netzwerkmodus verwenden, kann die `FLUENT_HOST` Umgebungsvariable in Ihrem Anwendungscontainer nach einem Neustart des FireLens Log-Router-Containers (des Containers mit dem `firelensConfiguration` Objekt in seiner Containerdefinition) ungenau werden. Das liegt daran, dass `FLUENT_HOST` eine dynamische IP-Adresse ist, die sich nach einem Neustart ändern kann. Die direkte Protokollierung vom Anwendungs-Container zur `FLUENT_HOST` IP-Adresse kann nach einer Adressänderung fehlschlagen. Weitere Informationen zum Neustart einzelner Container finden Sie unter [Einzelne Container in Amazon-ECS-Aufgaben mit Richtlinien für den Container-Neustart neu starten](container-restart-policy.md).
`FLUENT_PORT`
Der Port, über den das Fluent Forward-Protokoll kommuniziert.
Sie können diese Umgebungsvariablen verwenden, um sich direkt von Ihrem Anwendungscode aus mit dem Fluent Forward-Protokoll Fluent Bit beim Log Router anzumelden, anstatt in diesen zu schreiben. `stdout` Bei diesem Ansatz wird die Treiberschicht für die Docker-Protokollierung umgangen, was die folgenden Vorteile bietet:
+ **Geringere Latenz** — Protokolle werden direkt an die Protokollierungsinfrastruktur von Docker weitergeleitet, Fluent Bit ohne sie zu passieren.
+ **Strukturierte Protokollierung** — Senden Sie strukturierte Protokolldaten nativ ohne zusätzlichen Aufwand für die JSON-Codierung.
+ **Bessere Kontrolle** — Ihre Anwendung kann ihre eigene Pufferungs- und Fehlerbehandlungslogik implementieren.
Die folgenden Fluent-Logger-Bibliotheken unterstützen das Fluent Forward-Protokoll und können verwendet werden, um Protokolle direkt an zu senden: Fluent Bit
+ **Go** – [fluent-logger-golang](https://github.com/fluent/fluent-logger-golang)
+ **Python** – [fluent-logger-python](https://github.com/fluent/fluent-logger-python)
+ **Java** – [fluent-logger-java](https://github.com/fluent/fluent-logger-java)
+ **Node.js** – [fluent-logger-node](https://github.com/fluent/fluent-logger-node)
+ **Ruby** – [fluent-logger-ruby](https://github.com/fluent/fluent-logger-ruby)
## Konfigurieren Sie das Docker-Pufferlimit
Wenn Sie eine Aufgabendefinition erstellen, können Sie die Anzahl der Protokollzeilen angeben, die im Speicher gepuffert werden, indem Sie den Wert in angeben. `log-driver-buffer-limit` Dies steuert den Puffer zwischen Docker und. Fluent Bit Weitere Informationen finden Sie unter [Fluentd-Protokollierungstreiber](https://docs.docker.com/engine/logging/drivers/fluentd/) in der Docker-Dokumentation.
Verwenden Sie diese Option bei hohem Durchsatz, da Docker möglicherweise der Pufferspeicher ausgeht und Puffermeldungen verworfen werden, damit neue Nachrichten hinzugefügt werden können.
Beachten Sie bei der Verwendung dieser Option Folgendes:
+ Diese Option wird in EC2 und Fargate mit Plattformversion `1.4.0` oder höher unterstützt.
+ Die Option ist nur gültig, wenn `logDriver` auf `awsfirelens` gesetzt ist.
+ Das Standard-Pufferlimit ist `1048576` Protokollzeilen.
+ Das Pufferlimit muss größer oder gleich `0` und kleiner als `536870912`-Protokollzeilen sein.
+ Die maximale Menge an Arbeitsspeicher, die für diesen Puffer verwendet wird, ist die Summe der Größe jeder Protokollzeile und der Größe des Puffers. Wenn die Protokollzeilen der Anwendung beispielsweise im Durchschnitt `2` KiB betragen, würde ein Pufferlimit von 4096 höchstens `8` MiB verbrauchen. Die Gesamtmenge des auf Aufgabenebene zugewiesenen Arbeitsspeichers muss zusätzlich zum Arbeitsspeicher-Puffer des Protokolltreibers größer sein als die für alle Container zugewiesene Menge an Arbeitsspeicher.
Die folgende Aufgabendefinition zeigt, wie die Konfiguration erfolgt: `log-driver-buffer-limit`
```
{
"containerDefinitions": [
{
"name": "my_service_log_router",
"image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
"cpu": 0,
"memoryReservation": 51,
"essential": true,
"firelensConfiguration": {
"type": "fluentbit"
}
},
{
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:latest",
"name": "app",
"logConfiguration": {
"logDriver": "awsfirelens",
"options": {
"Name": "firehose",
"region": "us-west-2",
"delivery_stream": "my-stream",
"log-driver-buffer-limit": "52428800"
}
},
"dependsOn": [
{
"containerName": "my_service_log_router",
"condition": "START"
}
],
"memoryReservation": 100
}
]
}
```
# AWS für Fluent Bit Bild-Repositorys für Amazon ECS
AWS bietet ein Fluent Bit Image mit Plugins für CloudWatch Logs und Firehose. Es wird empfohlen, Fluent Bit als Protokoll-Router zu verwenden, da es eine geringere Ressourcenauslastung aufweist als Fluentd. Weitere Informationen finden Sie unter [CloudWatch Logs for Fluent Bit](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) und [Amazon Kinesis Firehose for](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit) Fluent Bit.
Das **AWS for Fluent Bit-Bild** ist auf Amazon ECR sowohl in der Amazon ECR Public Gallery als auch in einem Amazon ECR-Repository für hohe Verfügbarkeit verfügbar.
## Öffentliche Galerie Amazon ECR
Das Fluent Bit Bild AWS für ist in der Amazon ECR Public Gallery verfügbar. Dies ist der empfohlene Ort, um das Fluent Bit Bild AWS für herunterzuladen, da es sich um ein öffentliches Repository handelt, das von allen AWS-Regionen genutzt werden kann. Weitere Informationen finden Sie in der [aws-for-fluent-bit](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit)Amazon ECR Public Gallery.
### Linux
Das AWS Fluent Bit For-Bild in der Amazon ECR Public Gallery unterstützt das Amazon Linux-Betriebssystem mit der `ARM64` `x86-64` OR-Architektur.
Sie können das AWS Fluent Bit For-Bild aus der Amazon ECR Public Gallery abrufen, indem Sie die Repository-URL mit dem gewünschten Image-Tag angeben. Die verfügbaren Image-Tags finden Sie in der Registerkarte **Image-Tags** auf der Amazon ECR Public Gallery.
Nachfolgend finden Sie die für die Docker-CLI zu verwendende Syntax.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```
Mit diesem Docker-CLI-Befehl können Sie beispielsweise das neueste Image der „3.x“ -Familie AWS für Fluent Bit Releases abrufen.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```
**Anmerkung**
Nicht authentifizierte Pulls sind zulässig, haben jedoch eine niedrigere Rate als authentifizierte Pulls. Verwenden Sie den folgenden Befehl, um sich vor dem Abrufen mit Ihrem AWS Konto zu authentifizieren.
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
#### AWS für 3.0.0 Fluent Bit
Zusätzlich zu den vorhandenen Fluent Bit Versionen AWS `2.x` für Fluent Bit unterstützt AWS for eine neue Hauptversion`3.x`. Die neue Hauptversion beinhaltet das Upgrade von Images von Amazon Linux 2 auf Amazon Linux 2023 und Fluent Bit Version `1.9.10` auf`4.1.1`. Weitere Informationen finden Sie im [AWSFluent BitFor-Repository](https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md) unterGitHub.
Die folgenden Beispiele zeigen aktualisierte Tags AWS für Fluent Bit `3.x` Bilder:
Sie können Multiarchitektur-Tags AWS für das Fluent Bit FOR-Bild verwenden.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:3
```
### Windows
Das Fluent Bit Bild AWS for in der Amazon ECR Public Gallery unterstützt die `AMD64` Architektur mit den folgenden Betriebssystemen:
+ Windows Server 2022 Voll
+ Windows Server 2022 Kern
+ Windows Server 2019 Voll
+ Windows Server 2019 Kern
Windows-Container, die sich auf AWS Fargate befinden, werden nicht unterstützt FireLens.
Sie können das AWS Fluent Bit For-Bild aus der Amazon ECR Public Gallery abrufen, indem Sie die Repository-URL mit dem gewünschten Image-Tag angeben. Die verfügbaren Image-Tags finden Sie in der Registerkarte **Image-Tags** auf der Amazon ECR Public Gallery.
Nachfolgend finden Sie die für die Docker-CLI zu verwendende Syntax.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:tag
```
Mit diesem Docker-CLI-Befehl können Sie beispielsweise den neuesten Stable AWS for Fluent Bit Image abrufen.
```
docker pull public.ecr.aws/aws-observability/aws-for-fluent-bit:windowsservercore-stable
```
**Anmerkung**
Nicht authentifizierte Pulls sind zulässig, haben jedoch eine niedrigere Rate als authentifizierte Pulls. Verwenden Sie den folgenden Befehl, um sich vor dem Abrufen mit Ihrem AWS Konto zu authentifizieren.
```
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws
```
## Amazon ECR
Das AWS for Fluent Bit-Bild ist auf Amazon ECR für hohe Verfügbarkeit verfügbar. Die folgenden Befehle können verwendet werden, um ein Bild abzurufen URIs und die Verfügbarkeit eines Bilds für ein bestimmtes Bild festzulegen. AWS-Region
### Linux
Der neueste stabile Bild-URI AWS für Fluent Bit kann mit dem folgenden Befehl abgerufen werden.
```
aws ssm get-parameters \
--names /aws/service/aws-for-fluent-bit/stable \
--region us-east-1
```
Alle Versionen des AWS for Fluent Bit-Images können mit dem folgenden Befehl aufgelistet werden, um den Systems Manager Parameter Store-Parameter abzufragen.
```
aws ssm get-parameters-by-path \
--path /aws/service/aws-for-fluent-bit \
--region us-east-1
```
Das neueste stabile Bild AWS für Fluent Bit kann in einer CloudFormation Vorlage referenziert werden, indem auf den Namen des Systems Manager Manager-Parameterspeichers verwiesen wird. Im Folgenden wird ein Beispiel gezeigt:
```
Parameters:
FireLensImage:
Description: Fluent Bit image for the FireLens Container
Type: AWS::SSM::Parameter::Value
Default: /aws/service/aws-for-fluent-bit/stable
```
**Anmerkung**
Wenn der Befehl fehlschlägt oder keine Ausgabe erfolgt, ist das Bild in der Datei, AWS-Region in der der Befehl aufgerufen wurde, nicht verfügbar.
### Windows
Die neueste stabile Bild-URI AWS für Fluent Bit kann mit dem folgenden Befehl abgerufen werden.
```
aws ssm get-parameters \
--names /aws/service/aws-for-fluent-bit/windowsservercore-stable \
--region us-east-1
```
Alle Versionen des AWS for Fluent Bit-Images können mit dem folgenden Befehl aufgelistet werden, um den Systems Manager Parameter Store-Parameter abzufragen.
```
aws ssm get-parameters-by-path \
--path /aws/service/aws-for-fluent-bit/windowsservercore \
--region us-east-1
```
Das neueste stabile Bild AWS für Fluent Bit kann in einer CloudFormation Vorlage referenziert werden, indem auf den Namen des Systems Manager Manager-Parameterspeichers verwiesen wird. Im Folgenden wird ein Beispiel gezeigt:
```
Parameters:
FireLensImage:
Description: Fluent Bit image for the FireLens Container
Type: AWS::SSM::Parameter::Value
Default: /aws/service/aws-for-fluent-bit/windowsservercore-stable
```
# Beispiel einer Amazon-ECS-Aufgabendefinition: Protokolle an FireLens weiterleiten
Um ein benutzerdefiniertes Protokoll-Routing mit FireLens zu verwenden, müssen Sie Folgendes in der Aufgabendefinition angeben:
+ Ein Protokoll-Router-Container, der eine FireLens-Konfiguration enthält. Wir empfehlen, dass der Container als `essential` markiert wird.
+ Ein oder mehrere Anwendungscontainer, die eine Protokollkonfiguration enthalten, die den `awsfirelens`-Protokolltreiber angibt.
+ Ein Aufgaben-IAM-Rollen-Amazon-Ressourcenname (ARN), der die Berechtigungen enthält, die für die Aufgabe zum Weiterleiten der Protokolle erforderlich sind.
Beim Erstellen einer neuen Aufgabendefinition mithilfe von gibt es einen FireLens Integrationsbereich AWS-Managementkonsole, der das Hinzufügen eines Protokoll-Router-Containers erleichtert. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
Amazon ECS konvertiert die Protokollkonfiguration und generiert die Fluentd- oder Fluent Bit-Ausgabekonfiguration. Die Ausgabekonfiguration ist in dem Protokoll-Routing-Container unter `/fluent-bit/etc/fluent-bit.conf` für Fluent Bit und `/fluentd/etc/fluent.conf` für Fluentd eingebaut.
**Wichtig**
FireLens überwacht Port `24224`. Um sicherzustellen, dass der FireLens Log Router außerhalb der Aufgabe nicht erreichbar ist, dürfen Sie daher keinen eingehenden Datenverkehr über den Port `24224` in der Sicherheitsgruppe zulassen, die Ihre Aufgabe verwendet. Für Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden, ist dies die der Aufgabe zugeordnete Sicherheitsgruppe. Für Aufgaben, die den `host`-Netzwerkmodus verwenden, ist dies die Sicherheitsgruppe, die der Amazon-EC2-Instance zugeordnet ist, die die Aufgabe hostet. Für Aufgaben, die den `bridge`-Netzwerkmodus verwenden, erstellen Sie keine Portzuordnungen, die Port `24224` verwenden.
In den Protokolleinträgen werden standardmäßig zusätzliche Felder von Amazon ECS hinzugefügt, mit denen die Quelle der Protokolle identifiziert werden kann.
+ `ecs_cluster` – Der Name des Clusters, zu dem die Aufgabe gehört.
+ `ecs_task_arn` – Der vollständige Amazon-Ressourcenname (ARN) der Aufgabe, zu der der Container gehört.
+ `ecs_task_definition` – Der Name und die Revision der Aufgabendefinition, die die Aufgabe verwendet.
+ `ec2_instance_id` – Die Amazon-EC2-Instance-ID, auf der der Container gehostet wird. Dieses Feld ist nur für Aufgaben mit dem Starttyp EC2 gültig.
Sie können `enable-ecs-log-metadata` auf `false` setzen, wenn Sie die Metadaten nicht benötigen.
Das folgende Beispiel für eine Aufgabendefinition definiert einen Log Router-Container, der Fluent Bit verwendet, um seine Protokolle an Logs CloudWatch weiterzuleiten. Außerdem wird ein Anwendungs-Container definiert, der eine Protokollkonfiguration verwendet, um Protokolle an Amazon Data Firehose weiterzuleiten, und legt den zum Puffern von Ereignissen verwendeten Arbeitsspeicher auf 2 MiB fest.
**Anmerkung**
Weitere Beispielaufgabendefinitionen finden Sie unter [Amazon FireLens ECS-Beispiele](https://github.com/aws-samples/amazon-ecs-firelens-examples) unter GitHub.
```
{
"family": "firelens-example-firehose",
"taskRoleArn": "arn:aws:iam::123456789012:role/ecs_task_iam_role",
"containerDefinitions": [
{
"name": "log_router",
"image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
"cpu": 0,
"memoryReservation": 51,
"portMappings": [],
"essential": true,
"environment": [],
"mountPoints": [],
"volumesFrom": [],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/ecs-aws-firelens-sidecar-container",
"mode": "non-blocking",
"awslogs-create-group": "true",
"max-buffer-size": "25m",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "firelens"
},
"secretOptions": []
},
"systemControls": [],
"firelensConfiguration": {
"type": "fluentbit"
}
},
{
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:latest",
"name": "app",
"logConfiguration": {
"logDriver": "awsfirelens",
"options": {
"Name": "firehose",
"region": "us-west-2",
"delivery_stream": "my-stream",
"log-driver-buffer-limit": "1048576"
}
},
"memoryReservation": 100
}
]
}
```
Die Schlüsselwertpaare, die als Optionen im `logConfiguration`-Objekt angegeben werden, werden verwendet, um die Fluentd- oder Fluent Bit-Ausgabekonfiguration zu generieren. Im Folgenden finden Sie ein Codebeispiel aus einer Fluent Bit-Ausgabedefinition.
```
[OUTPUT]
Name firehose
Match app-firelens*
region us-west-2
delivery_stream my-stream
```
**Anmerkung**
FireLens verwaltet die `match` Konfiguration. Die `match`-Konfiguration ist in der Aufgabendefinition nicht festgelegt.
## Eine benutzerdefinierte Konfigurationsdatei verwenden
Sie können eine benutzerdefinierte Konfigurationsdatei angeben Das Konfigurationsdateiformat ist das native Format für den verwendeten Protokoll-Router. Weitere Informationen finden Sie unter [Syntax der Fluentd-Konfigurationsdatei](https://docs.fluentd.org/configuration/config-file) und [YAML-Konfiguration](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/yaml).
In Ihrer benutzerdefinierten Konfigurationsdatei sollten Sie für Aufgaben, die den `bridge`- oder `awsvpc`-Netzwerkmodus verwenden, keine Fluentd- oder Fluent-Bit-Weiterleitungseingabe über TCP festlegen, da FireLens diese zur Eingabekonfiguration hinzufügt.
Ihre FireLens-Konfiguration muss die folgenden Optionen enthalten, um eine benutzerdefinierte Konfigurationsdatei anzugeben:
`config-file-type`
Den Quellspeicherort der benutzerdefinierten Konfigurationsdatei. Die verfügbaren Optionen sind `s3` oder `file`.
Aufgaben, die auf gehostet werden, unterstützen AWS Fargate nur den `file` Konfigurationsdateityp. Sie können jedoch Konfigurationsdateien verwenden, die in Amazon S3 auf AWS Fargate gehostet werden, indem Sie den AWS for Fluent Bit init-Container verwenden. Weitere Informationen finden Sie unter [Init-Prozess für Fluent Bit auf ECS, Unterstützung mehrerer Konfigurationen auf](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub
`config-file-value`
Die Quelle für die benutzerdefinierte Konfigurationsdatei. Wenn der `s3`-Konfigurationsdateityp verwendet wird, ist der Wert der Konfigurationsdatei der vollständige ARN des Amazon S3-Buckets und der Datei. Wenn der `file`-Konfigurationsdateityp verwendet wird, ist der Wert der Konfigurationsdatei der vollständige Pfad der Konfigurationsdatei, die entweder im Container-Image oder auf einem Volume vorhanden ist, das im Container bereitgestellt wird.
Wenn Sie eine benutzerdefinierte Konfigurationsdatei verwenden, müssen Sie einen anderen Pfad als den von FireLens verwendeten angeben. Amazon ECS behält den `/fluent-bit/etc/fluent-bit.conf`-Dateipfad für Fluent Bit und `/fluentd/etc/fluent.conf` für Fluentd.
Das folgende Beispiel zeigt die Syntax, die erforderlich ist, wenn eine benutzerdefinierte Konfiguration angegeben wird.
**Wichtig**
Um eine benutzerdefinierte Konfigurationsdatei anzugeben, die in Amazon S3 gehostet wird, stellen Sie sicher, dass Sie eine IAM-Aufgabenausführungsrolle mit den entsprechenden Berechtigungen erstellt haben.
Im Folgenden wird die Syntax gezeigt, die für die Angabe einer benutzerdefinierten Konfiguration erforderlich ist.
```
{
"containerDefinitions": [
{
"essential": true,
"image": "906394416424.dkr.ecr.us-west-2.amazonaws.com/aws-for-fluent-bit:3",
"name": "log_router",
"firelensConfiguration": {
"type": "fluentbit",
"options": {
"config-file-type": "s3 | file",
"config-file-value": "arn:aws:s3:::amzn-s3-demo-bucket/fluent.conf | filepath"
}
}
}
]
}
```
**Anmerkung**
Aufgaben, die auf gehostet werden, unterstützen AWS Fargate nur den `file` Konfigurationsdateityp. Sie können jedoch Konfigurationsdateien verwenden, die in Amazon S3 auf AWS Fargate gehostet werden, indem Sie den AWS for Fluent Bit init-Container verwenden. Weitere Informationen finden Sie unter [Init-Prozess für Fluent Bit auf ECS, Unterstützung mehrerer Konfigurationen auf](https://github.com/aws/aws-for-fluent-bit/blob/mainline/use_cases/init-process-for-fluent-bit/README.md). GitHub