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.
# Konfiguration von Amazon-ECS-Protokollen für hohen Durchsatz
Für Szenarien mit hohem Protokolldurchsatz empfehlen wir, den `awsfirelens` Protokolltreiber zusammen mit FireLens und zu verwenden. Fluent Bit Fluent Bitist ein schlanker Protokollprozessor, der effizient mit Ressourcen umgeht und Millionen von Protokolldatensätzen verarbeiten kann. Um jedoch eine optimale Leistung im großen Maßstab zu erzielen, muss die Konfiguration angepasst werden.
In diesem Abschnitt werden fortgeschrittene Fluent Bit Optimierungstechniken zur Bewältigung eines hohen Protokolldurchsatzes bei gleichzeitiger Aufrechterhaltung der Systemstabilität und zur Vermeidung von Datenverlusten behandelt.
Hinweise zur Verwendung benutzerdefinierter 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 Bitverarbeitet Daten in Einheiten, die als Chunks bezeichnet werden*. * Wenn ein INPUT-Plugin Daten empfängt, erstellt die Engine einen Chunk, 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 Speicherpufferung. In Szenarien mit hohem Durchsatz oder in Produktionsszenarien sorgt die Dateisystempufferung für eine bessere Stabilität.
Weitere Informationen finden Sie [ in der Fluent Bit Dokumentation unter ](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks) Chunks und [ unter 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 Memory Buffering ()`storage.type memory`. Sie können die Speichernutzung pro INPUT-Plugin mithilfe des `Mem_Buf_Limit` Parameters 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, Fluent Bit pausiert die Eingabe und neue Datensätze gehen verloren. Das kann zu Gegendruck führen und deine Anwendung verlangsamen. Die folgende Warnung erscheint in den Fluent Bit Protokollen:
```
[input] tcp.1 paused (mem buf overlimit)
```
Die Speicherpufferung eignet sich für einfache Anwendungsfälle mit niedrigem bis moderatem Protokolldurchsatz. Verwenden Sie stattdessen für Szenarien mit hohem Durchsatz oder Produktionsszenarien, in denen Datenverlust ein Problem darstellt, die Pufferung des Dateisystems.
Weitere Informationen finden Sie unter [ Buffering and Memory ](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) in der Fluent Bit Dokumentation und [ 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 für Beispiele. AWS Fluent Bit
## Pufferung im Dateisystem
Für Szenarien mit hohem Durchsatz empfehlen wir die Verwendung der Dateisystempufferung. Weitere Informationen zur Fluent Bit Verwaltung von Pufferung und Speicher finden Sie in der Dokumentation unter [ Pufferung und Speicherung. ](https://docs.fluentbit.io/manual/administration/buffering-and-storage) Fluent Bit
Die Pufferung von Dateisystemen bietet die folgenden Vorteile:
+ **Größere Pufferkapazität ** — Festplattenspeicher ist in der Regel reichlich vorhanden als Arbeitsspeicher.
+ **Persistenz ** — Gepufferte Daten Fluent Bit überstehen Neustarts.
+ **Graduelle Degradation ** — Bei Ausfällen der Ausgabe sammeln sich Daten auf der Festplatte an, anstatt dass der Arbeitsspeicher erschöpft wird.
Um die Pufferung des Dateisystems 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, alle Backlog-Dateisystemblöcke beim Herunterfahren an ihre Ziele zu übertragen. Dies hilft, die Datenbereitstellung vor dem Fluent Bit Stopp sicherzustellen, kann jedoch die Zeit beim Herunterfahren verlängern.
`storage.max_chunks_up`
Die Anzahl der Blöcke, die im Speicher verbleiben. Die Standardeinstellung ist 128 Chunks, was mehr als 500 MB Arbeitsspeicher beanspruchen kann, da jeder Block bis zu 4—5 MB beanspruchen kann. In Umgebungen mit eingeschränktem Arbeitsspeicher sollten Sie diesen Wert herabsetzen. Wenn Sie beispielsweise 50 MB für die Pufferung zur Verfügung haben, legen Sie diesen Wert auf 8—10 Chunks fest.
`storage.type filesystem`
Aktiviert den Dateisystemspeicher für das Eingabe-Plugin. Trotz des Namens wird es Fluent Bit verwendet, `mmap` um Chunks sowohl dem Speicher als auch der Festplatte zuzuordnen und so für Persistenz zu sorgen, ohne die Leistung zu beeinträchtigen.
`storage.total_limit_size`
Der maximale Speicherplatz für gepufferte Daten für ein bestimmtes OUTPUT-Plug-In. Wenn dieses Limit erreicht ist, werden die ältesten Datensätze für diese Ausgabe gelöscht. Weitere Hinweise zur Größenbestimmung finden Sie unter[`Grundlegendes zu storage.total_limit_size`](#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 [ Dateisystempufferung ](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) in der Fluent Bit Dokumentation und [ Dateisystem- und Speicherpufferung ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem) im Projektarchiv für Beispiele. AWS Fluent Bit
## `Grundlegendes zu storage.total_limit_size`
Der `storage.total_limit_size` Parameter in jedem OUTPUT-Plugin 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 Speicherplatz vollständig erschöpft ist, werden die Datensätze Fluent Bit nicht in die Warteschlange gestellt und sie gehen verloren.
Verwenden Sie die folgende Formel, um `storage.total_limit_size` anhand Ihrer Log-Rate und des gewünschten Wiederherstellungsfensters den entsprechenden Wert 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 Log-Raten und Wiederherstellungsfenster:
| Log-Rate | 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 die geeigneten Puffergrößen auszuwählen, verwenden Sie das [ Messdurchsatzmuster. FireLens ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput)
Verwenden Sie die Formel, Beispielberechnungen und Benchmarks, um eine geeignete Landebahn auszuwählen`storage.total_limit_size`, die bei einem Ausfall eine optimale Wiederherstellung ermöglicht.
## Anforderungen an die Speicherung von Amazon ECS-Aufgaben
Summieren Sie alle `storage.total_limit_size` Werte in den OUTPUT-Abschnitten und fügen Sie einen Puffer für den Overhead hinzu. Diese Summe bestimmt den Speicherplatz, der in Ihrer Amazon ECS-Aufgabendefinition benötigt wird. Beispiel: 3 Ausgänge × jeweils 10 GB = 30 GB \+ Puffer (5—10 GB) = insgesamt 35—40 GB erforderlich. Wenn die Gesamtmenge 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:
Bindhalterungen (kurzlebiger Speicher)
+ Für AWS Fargate ist die Standardeinstellung 20 GB kurzlebigen Speichers (maximal 200 GB). Konfiguration unter 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 beträgt die Standardeinstellung 30 GB, wenn das ECS-optimized Amazon-AMI verwendet wird (gemeinsam vom Betriebssystem und Docker). Erhöhen Sie, indem Sie die Größe des Root-Volumes ändern.
Amazon-EBS-Volumes
+ Bietet hochverfügbaren, langlebigen und leistungsstarken Blockspeicher.
+ Erfordert eine Volume-Konfiguration und zeigt `mountPoint` in der Aufgabendefinition auf `storage.path` (Standard:`/var/log/flb-storage/`).
+ 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 eine Volume-Konfiguration und zeigt `mountPoint` in der Aufgabendefinition auf `storage.path` (Standard:`/var/log/flb-storage/`).
+ Weitere Informationen finden Sie unter [Ein Amazon-EFS-Dateisystems in einer Amazon-ECS-Aufgabendefinition angeben](specify-efs-config.md).
Weitere Informationen zu Datenvolumes finden Sie unter[Speicheroptionen für Amazon-ECS-Aufgaben](using_data_volumes.md).
## Optimieren Sie die Ausgangskonfiguration
Netzwerkprobleme, Serviceausfälle und die Drosselung des Ziels können verhindern, dass Protokolle übermittelt werden. Die richtige Ausgangskonfiguration gewährleistet Ausfallsicherheit ohne Datenverlust.
Wenn eine Ausgabesteuerung fehlschlägt, Fluent Bit kann der Vorgang erneut ausgeführt werden. Die folgenden Parameter steuern das Wiederholungsverhalten:
`retry_limit`
Die maximale Anzahl von Wiederholungen nach dem ersten Versuch, bevor Datensätze gelöscht werden. Der Standardwert ist 1. `retry_limit 3`Bedeutet beispielsweise insgesamt 4 Versuche (1 erster \+ 3 Wiederholungen). Für Produktionsumgebungen empfehlen wir 15 oder mehr, was mehrere Minuten Ausfall mit exponentiellem Backoff abdeckt.
Für unendlich viele Wiederholungen auf `no_limits` oder `False` setzen:
+ Bei der Speicherpufferung führen unendliche Wiederholungen dazu, dass das Eingabe-Plugin pausiert, wenn die Speichergrenzen erreicht sind.
+ Bei der Pufferung im Dateisystem werden die ältesten Datensätze gelöscht, wenn der Wert erreicht ist. `storage.total_limit_size`
Nachdem alle Wiederholungsversuche ausgeschöpft sind (1 Anfangsversuch \+ `retry_limit` Wiederholungen), werden die Datensätze gelöscht. AWS Plugins mit `auto_retry_requests true` (Standard) bieten eine zusätzliche Wiederholungsebene vor dem Fluent Bit Wiederholungsmechanismus. Weitere Informationen finden Sie in der Dokumentation unter [ Konfigurieren von ](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries) Wiederholungen. 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 \+ 20 s \+ 40 s), 40 Sekunden Zeitüberschreitungen bei der Netzwerkverbindung (4 Versuche × 10 s) sowie AWS Plugin-Wiederholungen — insgesamt etwa 2—10 Minuten, abhängig von den Netzwerkbedingungen und TCP-Timeouts des Betriebssystems.
`scheduler.base`
Die Basissekunden zwischen Wiederholungsversuchen (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 den Wiederholungsversuchen 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—20 Sekunden
+ Zweiter Versuch: zufällige Wartezeit zwischen 10—40 Sekunden
+ Dritter Versuch und später: zufällige Wartezeit zwischen 10—60 Sekunden (begrenzt)
Weitere Informationen finden Sie in der Dokumentation unter Wartezeit für Wiederholungsversuche [ konfigurieren ](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry) und [ Netzwerk. ](https://docs.fluentbit.io/manual/administration/networking) Fluent Bit
`workers`
Die Anzahl der Threads für die parallele Ausgabeverarbeitung. Mehrere Worker ermöglichen gleichzeitige Flushes, wodurch der Durchsatz bei der Verarbeitung vieler Chunks verbessert wird.
`auto_retry_requests`
Eine AWS Plugin-spezifische Einstellung, die vor dem integrierten Wiederholungsmechanismus eine zusätzliche Wiederholungsebene bereitstellt. Fluent Bit Der Standardwert ist `true`. Wenn diese Option aktiviert ist, versucht das AWS Ausgabe-Plugin fehlgeschlagene Anfragen intern erneut, bevor die Anfrage als fehlgeschlagener Flush betrachtet wird und der Konfiguration unterliegt. `retry_limit`
Der `Grace` Parameter in `[SERVICE]` diesem Abschnitt legt fest, wie lange beim Herunterfahren Fluent Bit gewartet wird, um gepufferte Daten zu leeren. Der `Grace` Zeitraum muss mit dem des Containers abgestimmt werden. `stopTimeout` Stellen Sie sicher, dass der `Grace` Zeitraum `stopTimeout` überschritten wird, in dem die Spülung abgeschlossen istFluent Bit, bevor Sie sie erhalten`SIGKILL`. Wenn `Grace` es beispielsweise 120 Sekunden ist, stellen Sie den Wert `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
```
## Grundlegendes zu Datenverlust-Szenarien
Aufzeichnungen können bei längeren Ausfällen oder Problemen mit Ausgabezielen verloren gehen. Die Konfigurationsempfehlungen in diesem Handbuch sind nach bestem Wissen und Gewissen zur Minimierung von Datenverlusten geeignet. Bei längeren Ausfällen kann jedoch kein Verlust garantiert werden. 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 Speicherplatz voll ist, oder die neuesten Datensätze werden zurückgewiesen, wenn das System keine weiteren Daten aufnehmen kann.
### Die ältesten Datensätze wurden gelöscht
Die ältesten gepufferten Datensätze werden gelöscht, wenn die Anzahl der Wiederholungsversuche ausgeschöpft ist oder wenn `storage.total_limit_size` sie voll sind und Platz für neue Daten geschaffen werden muss.
Das Limit für Wiederholungsversuche wurde überschritten
Tritt auf, nachdem AWS das Plugin es erneut versucht hat (wenn`auto_retry_requests true`) plus einem ersten Fluent Bit Versuch plus `retry_limit` Wiederholungen. Um dem entgegenzuwirken, setze `retry_limit no_limits` pro OUTPUT-Plugin unendlich viele Wiederholungsversuche:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
retry_limit no_limits
auto_retry_requests true
```
Unendliche Wiederholungsversuche verhindern, dass Datensätze aufgrund der Erschöpfung der Wiederholungsversuche verloren gehen, können aber dazu führen, dass sie voll werden. `storage.total_limit_size`
Speicherlimit erreicht (Pufferung des Dateisystems)
Tritt auf, wenn das Ausgabeziel länger nicht verfügbar ist, als Sie es konfiguriert `storage.total_limit_size` haben. Ein 10-GB-Puffer mit einer MB/s Log-Rate von 1 ermöglicht beispielsweise eine Pufferung von etwa 2,7 Stunden. Um dem entgegenzuwirken, erhöhen Sie das Plug-in `storage.total_limit_size` pro OUTPUT und stellen Sie ausreichend Amazon ECS-Aufgabenspeicher bereit:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
storage.total_limit_size 10G
```
### Die neuesten Datensätze wurden abgelehnt
Die neuesten Datensätze werden gelöscht, wenn der Speicherplatz erschöpft ist oder wenn die Eingabe aufgrund von unterbrochen wird. `Mem_Buf_Limit`
Speicherplatz ist erschöpft (Dateisystem-Pufferung)
Tritt auf, wenn der Speicherplatz vollständig erschöpft ist. Fluent Bitneue Datensätze können nicht in die Warteschlange gestellt werden und sie gehen verloren. Um Abhilfe zu schaffen, summieren Sie alle `storage.total_limit_size` Werte und stellen Sie ausreichend Speicherplatz für Amazon ECS-Aufgaben bereit. Weitere Informationen finden Sie unter [Anforderungen an die Speicherung von 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 verwenden Sie es `storage.type filesystem` für eine bessere Widerstandsfähigkeit oder erhöhen Sie es. `Mem_Buf_Limit`
### Bewährte Methoden zur Minimierung von Datenverlusten
Beachten Sie die folgenden bewährten Methoden, um Datenverluste zu minimieren:
+ **Verwenden Sie Dateisystem-Pufferung ** — Diese Option sorgt `storage.type filesystem` für eine bessere Widerstandsfähigkeit bei Ausfällen.
+ **Speicher angemessen dimensionieren ** — Berechnet auf der `storage.total_limit_size` Grundlage der Log-Rate und des gewünschten Wiederherstellungsfensters.
+ **Bereitstellung einer ausreichenden Festplatte ** — Stellen Sie sicher, dass die Amazon ECS-Aufgabe über ausreichend temporären Speicher, Amazon EBS oder Amazon EFS verfügt.
+ **Wiederholungsverhalten konfigurieren ** — Balance zwischen `retry_limit` (löscht Datensätze nach anstrengenden Wiederholungsversuchen) und `no_limits` (wiederholt sich unbegrenzt, kann aber Speicherplatz füllen).
## Verwenden Sie aus Gründen der Zuverlässigkeit die Protokollierung mehrerer 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.
Multi-destination Die Protokollierung bietet die folgenden Vorteile. Das Amazon S3-Ausgabe-Plugin unterstützt auch Komprimierungsoptionen wie das GZIP- und Parquet-Format, wodurch die Speicherkosten gesenkt werden können. Weitere Informationen finden Sie [ in der Fluent Bit Dokumentation unter ](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression) S3-Komprimierung.
Multi-destination Die Protokollierung kann die folgenden Vorteile bieten:
+ **Redundanz ** — Wenn ein Ziel ausfällt, erreichen die Protokolle trotzdem das andere.
+ **Wiederherstellung ** — Rekonstruieren Sie die Lücken zwischen einem System und dem anderen.
+ **Haltbarkeit ** — Archivieren Sie Protokolle in Amazon S3 zur langfristigen Aufbewahrung.
+ **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 im kostengünstigen Amazon 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 laufen die Protokolle weiter zum anderen, während fehlgeschlagene Löschvorgänge sich im Dateisystempuffer ansammeln, um es später erneut zu versuchen.
## 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 sie mithilfe des Fluent Bit `tail` Eingabe-Plug-ins liest. Bei diesem Ansatz wird die Docker-Logging-Treiberschicht vollständig umgangen.
File-based Die 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), wodurch die Beständigkeit auch bei Fluent Bit Neustarts gewährleistet ist. Dies hilft, den Verlust von Logs bei Container-Neustarts zu verhindern.
+ **Input-level Pufferung ** — Sie können Speicherpuffer-Grenzwerte direkt im Eingabe-Plugin mit konfigurieren`Mem_Buf_Limit`, sodass Sie die Speichernutzung genauer kontrollieren können.
+ **Vermeidet Docker-Overhead ** — Logs werden direkt von einer Datei in eine andere übertragen, Fluent Bit ohne die Log-Puffer von Docker zu passieren.
Um diesen Ansatz zu verwenden, muss Ihre Anwendung statt in Dateien Protokolle 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 Tail-Eingabekonfiguration 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 eine Protokollrotation für Ihre Anwendungsprotokolle, um eine Überlastung der Festplatte zu verhindern. Überwachen Sie die zugrunde liegenden Volumenmetriken, um die Leistung zu messen.
+ Berücksichtigen Sie Einstellungen wie`Ignore_Older`,`Read_from_Head`, und mehrzeilige Parser, die auf Ihrem Protokollformat basieren.
Weitere Informationen finden Sie [ in der Dokumentation unter ](https://docs.fluentbit.io/manual/pipeline/inputs/tail) Tail. Fluent Bit Bewährte Methoden finden Sie unter [ Tail Config 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 Container-Definition) 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 mithilfe des Fluent Forward-Protokolls direkt von Ihrem Anwendungscode aus beim Log-Router Fluent Bit anzumelden, anstatt in das Protokoll zu schreiben. `stdout` Bei diesem Ansatz wird die Docker-Logging-Treiberschicht umgangen, was die folgenden Vorteile bietet:
+ **Niedrigere Latenz ** — Logs werden direkt dorthin übertragen, Fluent Bit ohne die Logging-Infrastruktur von Docker zu durchlaufen.
+ **Strukturiertes Logging ** — Senden Sie strukturierte Logdaten nativ ohne JSON-Codierungsaufwand.
+ **Bessere Kontrolle ** — Ihre Anwendung kann ihre eigene Puffer- und Fehlerbehandlungslogik implementieren.
Die folgenden Fluent-Logger-Bibliotheken unterstützen das Fluent Forward-Protokoll und können verwendet werden, um Protokolle direkt an folgende Adresse zu senden: Fluent Bit
+ **Go ** — fluent-logger-golang [https://github.com/fluent/fluent-logger-golang](https://github.com/fluent/fluent-logger-golang)
+ **Python ** — [ fließendes Logger-Python ](https://github.com/fluent/fluent-logger-python)
+ **Java ** — [ fließendes Logger-Java ](https://github.com/fluent/fluent-logger-java)
+ **Node.js**[— Knoten mit fließendem Logger ](https://github.com/fluent/fluent-logger-node)
+ **Rubin — ** Fluent-Logger-Rubin [https://github.com/fluent/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 durchschnittlich `2` KiB groß sind, 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
}
]
}
```