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 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 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 Chunks und unter Was ist ein 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

[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 in der Fluent Bit Dokumentation und Memory Buffering Only 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. Fluent Bit

Die Pufferung von Dateisystemen bietet die folgenden Vorteile:

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:

Weitere Informationen finden Sie unter Dateisystempufferung in der Fluent Bit Dokumentation und Dateisystem- und Speicherpufferung 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:

Um den Spitzendurchsatz zu beobachten und die geeigneten Puffergrößen auszuwählen, verwenden Sie das Messdurchsatzmuster. FireLens

Verwenden Sie die Formel, Beispielberechnungen und Benchmarks, um eine geeignete Landebahn auszuwählenstorage.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:

Weitere Informationen zu Datenvolumes finden Sie unterSpeicheroptionen für Amazon-ECS-Aufgaben.

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:

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

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 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 erhaltenSIGKILL. 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.

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

Bewährte Methoden zur Minimierung von Datenverlusten

Beachten Sie die folgenden bewährten Methoden, um Datenverluste zu minimieren:

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 S3-Komprimierung.

Multi-destination Die Protokollierung 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 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:

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:

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

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

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