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

Verwenden Sie die Dateisystempufferung

Fluent BitPuffert standardmäßig alle Daten im Speicher. Wenn Daten schneller aufgenommen werden, als sie in die Ausgaben übertragen werden können, füllt sich der Puffer. Sobald der Speicher voll ist, pausiert das Eingabe-Plugin, bis Pufferspeicher verfügbar ist. Dies kann zu Gegendruck führen und Ihre Anwendung verlangsamen.

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:

Optimieren Sie die Ausgangskonfiguration

Netzwerkprobleme, Dienstausfälle und die 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 beim erneuten Versuch:

Der Grace Parameter in [SERVICE] diesem Abschnitt legt die Fluent Bit Wartezeit beim Herunterfahren fest, bis die gepufferten Daten geleert werden. 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

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.

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