Configurazione dei log di Amazon ECS per un throughput elevato - Amazon Elastic Container Service

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Configurazione dei log di Amazon ECS per un throughput elevato

Per scenari con elevata velocità di trasmissione dei log, consigliamo di utilizzare il driver di registro con and. awsfirelens FireLens Fluent Bit Fluent Bitè un processore di log leggero, efficiente in termini di risorse e in grado di gestire milioni di record di log. Tuttavia, per ottenere prestazioni ottimali su larga scala è necessario ottimizzarne la configurazione.

Questa sezione illustra le tecniche di Fluent Bit ottimizzazione avanzate per gestire un elevato throughput di log, mantenendo al contempo la stabilità del sistema e garantendo l'assenza di perdita di dati.

Per informazioni su come utilizzare i file di configurazione personalizzati con FireLens, vedereUtilizzo di un file di configurazione personalizzato. Per ulteriori esempi, consulta gli FireLens esempi di Amazon ECS su GitHub.

Nota

Alcune opzioni di configurazione in questa sezione, come workers ethreaded, richiedono AWS la Fluent Bit versione 3 o successiva. Per informazioni sulle versioni disponibili, vedere le versioni AWS di Fluent Bit.

Usa il buffering del filesystem

Per impostazione predefinita, Fluent Bit memorizza nel buffer tutti i dati in memoria. Quando i dati vengono inseriti più velocemente di quanto possano essere scaricati in uscita, il buffer si riempie. Una volta pieno, il plugin di input si interrompe finché non diventa disponibile spazio nel buffer, il che può causare una contropressione e rallentare l'applicazione.

Per scenari con throughput elevato, consigliamo di utilizzare il buffering del file system. Per ulteriori informazioni su come Fluent Bit gestire il buffering e lo storage, consulta Buffering and Storage nella documentazione. Fluent Bit

Il buffering del file system offre i seguenti vantaggi:

  • Maggiore capacità del buffer: lo spazio su disco è in genere più abbondante della memoria.

  • Persistenza: i dati memorizzati nel buffer sopravvivono ai riavvii. Fluent Bit

  • Degrado graduale: in caso di errori di output, i dati si accumulano sul disco anziché causare l'esaurimento della memoria.

Per abilitare il buffering del file system, fornite un file di configurazione personalizzato. Fluent Bit L'esempio seguente mostra la configurazione consigliata:

[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

Parametri di configurazione chiave:

storage.path

La directory in cui Fluent Bit memorizza i blocchi bufferizzati sul disco.

storage.backlog.flush_on_shutdown

Se abilitata, Fluent Bit tenta di riportare tutti i blocchi del file system backlog verso le rispettive destinazioni durante l'arresto. Ciò aiuta a garantire la consegna dei dati prima delle interruzioni, ma può aumentare i tempi di spegnimento. Fluent Bit

storage.max_chunks_up

Il numero di blocchi che rimangono in memoria. L'impostazione predefinita è 128 blocchi, che possono consumare più di 500 MB di memoria perché ogni blocco può utilizzare fino a 4-5 MB. In ambienti con limiti di memoria, riduci questo valore. Ad esempio, se hai a disposizione 50 MB per il buffering, impostalo su 8-10 blocchi.

storage.type filesystem

Abilita l'archiviazione del filesystem per il plug-in di input. Nonostante il nome, Fluent Bit viene utilizzato mmap per mappare blocchi sia sulla memoria che sul disco, garantendo la persistenza senza compromettere le prestazioni.

threaded true

Esegue l'input nel proprio thread, separato dal ciclo Fluent Bit di eventi principale. Ciò impedisce che gli input lenti blocchino l'intera pipeline.

Ottimizza la configurazione dell'output

Problemi di rete, interruzioni del servizio e limitazione della destinazione possono impedire la consegna dei log. Una corretta configurazione dell'output garantisce la resilienza senza perdita di dati.

Quando un flusso di uscita fallisce, è Fluent Bit possibile riprovare l'operazione. I seguenti parametri controllano il comportamento dei tentativi di ripetizione:

retry_limit

Numero massimo di tentativi prima di eliminare i record. Il valore di default è 1. Per gli ambienti di produzione, ne consigliamo 15 o più, che coprono diversi minuti di interruzione con backoff esponenziale.

scheduler.base

Il numero minimo di secondi tra un tentativo e l'altro. Consigliamo 10 secondi.

scheduler.cap

Il numero massimo di secondi tra un tentativo e l'altro quando si utilizza il backoff esponenziale. Consigliamo 60 secondi.

workers

Il numero di thread per l'elaborazione parallela dell'output. Più operatori consentono lavaggi simultanei, migliorando la produttività quando si elaborano più blocchi.

Il Grace parametro nella [SERVICE] sezione imposta il tempo di Fluent Bit attesa durante l'arresto per cancellare i dati memorizzati nel buffer. Il Grace periodo deve essere coordinato con quello del contenitore. stopTimeout Assicurarsi che stopTimeout superi il Grace periodo di tempo necessario per consentire il Fluent Bit completamento del lavaggio prima del ricevimento. SIGKILL Ad esempio, se Grace è 120 secondi, impostato su stopTimeout 150 secondi.

L'esempio seguente mostra una Fluent Bit configurazione completa con tutte le impostazioni consigliate per scenari con throughput elevato:

[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

Utilizzate la registrazione a più destinazioni per garantire l'affidabilità

L'invio di registri a più destinazioni elimina i singoli punti di errore. Ad esempio, se CloudWatch Logs subisce un'interruzione, i log continuano a raggiungere Amazon S3.

La registrazione multidestinazione offre i seguenti vantaggi. Il plug-in di output Amazon S3 supporta anche opzioni di compressione come gzip e il formato Parquet, che possono ridurre i costi di archiviazione. Per ulteriori informazioni, consulta la sezione Compressione S3 nella documentazione. Fluent Bit

La registrazione multidestinazione può offrire i seguenti vantaggi:

  • Ridondanza: se una destinazione fallisce, i log raggiungono comunque l'altra.

  • Ripristino: ricostruisci le lacune in un sistema rispetto all'altro.

  • Durabilità: archivia i log in Amazon S3 per la conservazione a lungo termine.

  • Ottimizzazione dei costi: conserva i log recenti in un servizio di query veloce come CloudWatch Logs con conservazione più breve, mentre archivia tutti i log su uno storage Amazon S3 a basso costo per una conservazione a lungo termine.

La seguente Fluent Bit configurazione invia i log sia a Logs che ad CloudWatch 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

Entrambi gli output utilizzano lo stesso Match * schema, quindi tutti i record vengono inviati a entrambe le destinazioni in modo indipendente. Durante un'interruzione di servizio di una destinazione, i log continuano a fluire verso l'altra, mentre nel buffer del filesystem si accumulano gli scarichi non riusciti per riprovare in un secondo momento.

Usa la registrazione basata su file con il plugin tail input

Per scenari ad alta velocità in cui la perdita di log è un problema fondamentale, puoi utilizzare un approccio alternativo: fare in modo che l'applicazione scriva i log sui file su disco e configuri Fluent Bit per leggerli utilizzando il plug-in di input. tail Questo approccio aggira completamente il livello dei driver di registrazione Docker.

La registrazione basata su file con il plugin tail offre i seguenti vantaggi:

  • Tracciamento degli offset: il plug-in tail può memorizzare gli offset dei file in un file di database (utilizzando l'DBopzione), garantendo la durabilità durante i riavvii. Fluent Bit Questo aiuta a prevenire la perdita di log durante il riavvio del contenitore.

  • Buffering a livello di input: è possibile configurare i limiti del buffer di memoria direttamente sul plug-in di input utilizzando, in questo modoMem_Buf_Limit, un controllo più granulare sull'utilizzo della memoria.

  • Evita il sovraccarico di Docker: i log passano direttamente dal file all'altro senza passare attraverso i buffer di registro di Docker. Fluent Bit

Per utilizzare questo approccio, l'applicazione deve scrivere i log nei file anziché. stdout Sia il contenitore dell'applicazione che il Fluent Bit contenitore montano un volume condiviso in cui sono archiviati i file di registro.

L'esempio seguente mostra una configurazione di input di tipo tail con le migliori pratiche:

[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

Quando usi il plugin tail input, considera quanto segue:

  • Implementate la rotazione dei log per i log delle applicazioni per prevenire l'esaurimento del disco. Monitora le metriche di volume sottostanti per valutare le prestazioni.

  • Prendi in considerazione impostazioni come Ignore_OlderRead_from_Head, e parser multilinea in base al formato del registro.

Per ulteriori informazioni, consulta Tail nella Fluent Bit documentazione. Per le migliori pratiche, consulta Tail config with best practice nella guida AWS per la Fluent Bit risoluzione dei problemi.

Accedi direttamente a FireLens

Quando il driver di log awsfirelens è specificato in una definizione di attività, l'agente Amazon ECS inserisce le seguenti variabili di ambiente nel container:

FLUENT_HOST

L'indirizzo IP assegnato al FireLens contenitore.

Nota

Se utilizzi EC2 con la modalità di bridge rete, la variabile di FLUENT_HOST ambiente nel contenitore dell'applicazione può diventare imprecisa dopo il riavvio del contenitore del FireLens log router (il contenitore con l'firelensConfigurationoggetto nella definizione del contenitore). Questo perché FLUENT_HOST è un indirizzo IP dinamico e può cambiare dopo un riavvio. La registrazione diretta dal container dell'applicazione all'indirizzo IP FLUENT_HOST può iniziare a fallire dopo la modifica dell'indirizzo. Per ulteriori informazioni sul riavvio di singoli container, consultare Riavviare singoli container nelle attività Amazon ECS con policy di riavvio dei container.

FLUENT_PORT

La porta su cui il protocollo Fluent Forward è in ascolto.

Puoi utilizzare queste variabili di ambiente per accedere direttamente al Fluent Bit log router dal codice dell'applicazione utilizzando il protocollo Fluent Forward, anziché scrivere su. stdout Questo approccio aggira il livello dei driver di registrazione Docker, che offre i seguenti vantaggi:

  • Latenza inferiore: i log vanno direttamente a Docker Fluent Bit senza passare attraverso l'infrastruttura di registrazione.

  • Registrazione strutturata: invia dati di log strutturati in modo nativo senza sovraccarico di codifica JSON.

  • Controllo migliore: l'applicazione può implementare la propria logica di buffering e gestione degli errori.

Le seguenti librerie di logger Fluent supportano il protocollo Fluent Forward e possono essere utilizzate per inviare i log direttamente a: Fluent Bit

Configura il limite del buffer Docker

Quando si crea una definizione di attività, è possibile specificare il numero di righe di registro memorizzate nel buffer in memoria specificando il valore in. log-driver-buffer-limit Questo controlla il buffer tra Docker e. Fluent Bit Per ulteriori informazioni, consulta la pagina Driver di registro di Fluentd nella documentazione Docker.

Utilizza questa opzione in caso di velocità di trasmissione effettiva elevata, perché Docker potrebbe esaurire la memoria buffer e scartare i messaggi buffer in modo da poter aggiungere nuovi messaggi.

Considerate quanto segue quando utilizzate questa opzione:

  • Questa opzione è supportata nei tipi EC2 e Fargate con versione della piattaforma 1.4.0 o successiva.

  • L'opzione è valida solo quando logDriver è impostato su awsfirelens.

  • Il limite di buffer di default è 1048576 righe di log.

  • Il limite del buffer deve essere maggiore o uguale a 0 e inferiore a 536870912 righe di log.

  • La quantità massima di memoria utilizzata per questo buffer è il prodotto della dimensione di ogni riga di log e della dimensione del buffer. Ad esempio, se le righe di registro dell'applicazione sono in media 2 KB, un limite di buffer di 4096 utilizzerebbe al massimo 8 MiB. La quantità totale di memoria allocata a livello di attività deve essere superiore a quella allocata per tutti i container oltre al driver di log del buffer di memoria.

La seguente definizione di attività mostra come configurare: 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 } ] }