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 unterEine benutzerdefinierte Konfigurationsdatei verwenden. Weitere Beispiele finden Sie unter Amazon FireLens ECS-Beispiele unter GitHub.

Chunks verstehen

Fluent Bitverarbeitet 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 und Was ist ein 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

[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 Buffering Only 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 Speicherung. Fluent Bit

Die Pufferung von Dateisystemen bietet die folgenden Vorteile:

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:

Weitere Informationen finden Sie unter Dateisystem-Pufferung in der Fluent Bit Dokumentation und Dateisystem- und Speicherpufferung im AWS Beispiel-Repository. 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:

Um den Spitzendurchsatz zu beobachten und geeignete Puffergrößen auszuwählen, verwenden Sie die Messdurchsatzprobe. FireLens

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 + 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:

Weitere Hinweise zu Datenvolumen finden Sie unterSpeicheroptionen für Amazon-ECS-Aufgaben.

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:

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

Weitere Informationen finden Sie in der Dokumentation unter Wartezeit für Wiederholungsversuche konfigurieren und Netzwerk. Fluent Bit

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.

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

Bewährte Methoden zur Minimierung von Datenverlusten

Beachten Sie die folgenden bewährten Methoden zur Minimierung von Datenverlusten:

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.

Die Protokollierung mehrerer Ziele kann die folgenden Vorteile bieten:

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:

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:

Weitere Informationen finden Sie in der Dokumentation unter Tail. Fluent Bit Bewährte Methoden finden Sie unter Tail-Konfiguration mit bewährten Methoden 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:

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:

Die folgenden Fluent-Logger-Bibliotheken unterstützen das Fluent Forward-Protokoll und können verwendet werden, um Protokolle direkt an zu senden: Fluent Bit

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 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:

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
        }
    ]
}