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 ad alta velocità di log, consigliamo di utilizzare il driver di log con e. `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 la stabilità del sistema e garantendo l'assenza di perdite di dati.
Per informazioni su come utilizzare i file di configurazione personalizzati con FireLens, vedere[Utilizzo di un file di configurazione personalizzato](firelens-taskdef.md#firelens-taskdef-customconfig). Per ulteriori esempi, consulta gli FireLens esempi di [ Amazon ECS ](https://github.com/aws-samples/amazon-ecs-firelens-examples) su GitHub.
**Nota**
Alcune opzioni di configurazione in questa sezione, come `workers` e`threaded`, richiedono AWS la Fluent Bit versione 3 o successiva. Per informazioni sulle versioni disponibili, consulta la sezione dedicata alle versioni [AWS](https://github.com/aws/aws-for-fluent-bit/releases) di Fluent Bit.
## Comprensione dei blocchi
Fluent Bitelabora i dati in unità chiamate * blocchi. * Quando un plugin INPUT riceve dati, il motore crea un blocco che viene archiviato in memoria o nel filesystem prima di essere inviato alle destinazioni OUTPUT.
Il comportamento di buffering dipende dall'`storage.type`impostazione nelle sezioni INPUT. Per impostazione predefinita, Fluent Bit utilizza il buffering della memoria. Per scenari di produzione o ad alta produttività, il buffering del file system offre una migliore resilienza.
Per ulteriori informazioni, consulta [ Chunks nella documentazione e What is a Chunk](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks)? Fluent Bit [https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk)nel repository AWS for examplesFluent Bit.
## Buffering della memoria (impostazione predefinita)
Per impostazione predefinita, Fluent Bit utilizza il buffering di memoria ()`storage.type memory`. È possibile limitare l'utilizzo della memoria per plug-in INPUT utilizzando il `Mem_Buf_Limit` parametro.
L'esempio seguente mostra una configurazione di input con buffer di memoria:
```
[INPUT]
Name tcp
Tag ApplicationLogs
Port 5170
storage.type memory
Mem_Buf_Limit 5MB
```
**Importante**
Quando `Mem_Buf_Limit` viene superato il limite di un plugin, Fluent Bit sospende l'input e i nuovi record vengono persi. Ciò può causare una contropressione e rallentare l'applicazione. Nei Fluent Bit log viene visualizzato il seguente avviso:
```
[input] tcp.1 paused (mem buf overlimit)
```
Il buffering della memoria è adatto per casi d'uso semplici con un throughput di log da basso a moderato. Per scenari di produzione o ad alto rendimento in cui la perdita di dati è un problema, utilizzate invece il buffering del file system.
Per ulteriori informazioni, vedere [ Buffering and Memory ](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) nella Fluent Bit documentazione e [ Memory Buffering Only nel repository for examples. ](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) AWS Fluent Bit
## Buffering del file system
Per scenari ad alto rendimento, consigliamo di utilizzare il buffering del file system. Per ulteriori informazioni su come Fluent Bit gestire il buffering e l'archiviazione, consulta [ Buffering and Storage nella documentazione. ](https://docs.fluentbit.io/manual/administration/buffering-and-storage) Fluent Bit
Il buffering del file system offre i seguenti vantaggi:
+ **Maggiore capacità di 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, fornisci 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 vengono Fluent Bit archiviati i blocchi bufferizzati sul disco.
`storage.backlog.flush_on_shutdown`
Se abilitata, Fluent Bit tenta di riportare a destinazione tutti i blocchi del file system arretrati durante l'arresto. Questo aiuta a garantire la consegna dei dati prima Fluent Bit delle interruzioni, ma può aumentare i tempi di arresto.
`storage.max_chunks_up`
Il numero di blocchi che rimangono in memoria. L'impostazione predefinita è 128 blocchi, che possono consumare oltre 500 MB di memoria perché ogni blocco può utilizzare fino a 4-5 MB. In ambienti con limiti di memoria, abbassate questo valore. Ad esempio, se hai 50 MB disponibili per il buffering, impostali su 8-10 blocchi.
`storage.type filesystem`
Abilita l'archiviazione del file system per il plug-in di input. Nonostante il nome, consente di Fluent Bit mappare `mmap` i blocchi sia sulla memoria che sul disco, garantendo persistenza senza sacrificare le prestazioni.
`storage.total_limit_size`
Lo spazio su disco massimo per i dati memorizzati nel buffer per uno specifico plug-in OUTPUT. Quando viene raggiunto questo limite, i record più vecchi relativi a quell'output vengono eliminati. Per ulteriori informazioni sul dimensionamento, vedere[`Informazioni su storage.total_limit_size`](#firelens-storage-sizing).
`threaded true`
Esegue l'input in un thread separato dal ciclo Fluent Bit di eventi principale. Ciò impedisce che gli input lenti blocchino l'intera pipeline.
Per ulteriori informazioni, vedere [ Filesystem Buffering ](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) nella Fluent Bit documentazione e [ Filesystem and Memory Buffering nel repository for examples. ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem) AWS Fluent Bit
## `Informazioni su storage.total_limit_size`
Il `storage.total_limit_size` parametro di ogni plug-in OUTPUT controlla lo spazio su disco massimo per i dati memorizzati nel buffer per quell'output. Quando viene raggiunto questo limite, i record più vecchi relativi a quell'output vengono eliminati per fare spazio a nuovi dati. Quando lo spazio su disco è completamente esaurito, i record Fluent Bit non vengono messi in coda e questi vengono persi.
Utilizzate la seguente formula per calcolare il valore appropriato in `storage.total_limit_size` base alla frequenza di registrazione e alla finestra di ripristino desiderata:
```
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)
```
La tabella seguente mostra esempi di calcolo per le frequenze di registro e le finestre di ripristino comuni:
| Frequenza di log | 1 ora | 6 ore | 12 ore | 24 ore |
| --- | --- | --- | --- | --- |
| 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 |
Per osservare il picco di produttività e scegliere le dimensioni appropriate del buffer, utilizzate il campione di misurazione della [ produttività. FireLens ](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput)
Usa la formula, gli esempi di calcolo e il benchmarking per scegliere una soluzione adatta `storage.total_limit_size` che fornisca la pista per il ripristino al meglio durante un'interruzione.
## Requisiti di archiviazione delle attività di Amazon ECS
Somma tutti i `storage.total_limit_size` valori nelle sezioni OUTPUT e aggiungi un buffer per il sovraccarico. Questo totale determina lo spazio di archiviazione necessario nella definizione delle attività di Amazon ECS. Ad esempio, sono necessari 3 uscite × 10 GB ciascuna = 30 GB \+ buffer (5-10 GB) = 35-40 GB in totale. Se il totale supera lo spazio di archiviazione disponibile, Fluent Bit potrebbe non riuscire a mettere in coda i record e questi andranno persi.
Sono disponibili le seguenti opzioni di archiviazione:
Bind Mounts (archiviazione temporanea)
+ Per AWS Fargate, l'impostazione predefinita è 20 GB di memoria temporanea (max 200 GB). Configura utilizzando `ephemeralStorage` nella definizione dell'attività. Per ulteriori informazioni, consulta [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html) nella *Guida per l'utente di AWS CloudFormation *.
+ Per EC2, l'impostazione predefinita è 30 GB quando si utilizza l'Amazon ECS-optimized AMI (condivisa tra il sistema operativo e Docker). Aumenta modificando la dimensione del volume principale.
Volumi Amazon EBS
+ Fornisce uno storage a blocchi ad alta disponibilità, durevole e ad alte prestazioni.
+ Richiede la configurazione del volume e `mountPoint` nella definizione dell'attività che punta a `storage.path` (impostazione predefinita:`/var/log/flb-storage/`).
+ Per ulteriori informazioni, consulta [Rimanda la configurazione del volume all'ora di avvio nella definizione di un'attività di Amazon ECS](specify-ebs-config.md).
Volumi Amazon EFS
+ Fornisce uno storage di file semplice e scalabile.
+ Richiede la configurazione del volume e `mountPoint` nella definizione dell'attività il puntamento a `storage.path` (impostazione predefinita:`/var/log/flb-storage/`).
+ Per ulteriori informazioni, consulta [Specificare di un file system Amazon EFS nella definizione di un'attività Amazon ECS](specify-efs-config.md).
Per ulteriori informazioni sui volumi di dati, vedere[Opzioni di archiviazione per le attività di Amazon ECS](using_data_volumes.md).
## Ottimizza la configurazione dell'output
Problemi di rete, interruzioni del servizio e limitazione delle destinazioni possono impedire la consegna dei log. Una corretta configurazione di output garantisce la resilienza senza perdita di dati.
Quando uno svuotamento dell'uscita fallisce, Fluent Bit può riprovare l'operazione. I seguenti parametri controllano il comportamento dei tentativi:
`retry_limit`
Il numero massimo di tentativi dopo il tentativo iniziale prima di eliminare i record. Il valore di default è 1. Ad esempio, `retry_limit 3` indica 4 tentativi totali (1 iniziale \+ 3 tentativi). Per gli ambienti di produzione, ne consigliamo 15 o più, che coprono diversi minuti di interruzione con un backoff esponenziale.
Imposta su `no_limits` o `False` per tentativi infiniti:
+ Con il buffering della memoria, i tentativi infiniti causano la pausa del plug-in di input quando vengono raggiunti i limiti di memoria.
+ Con il buffering del file system, i record più vecchi vengono eliminati quando vengono raggiunti. `storage.total_limit_size`
Dopo aver esaurito tutti i tentativi di nuovo tentativo (1 tentativo iniziale \+ `retry_limit` tentativi), i record vengono eliminati. AWS i plugin con `auto_retry_requests true` (impostazione predefinita) forniscono un livello di riprova aggiuntivo prima del meccanismo di riprova. Fluent Bit Per ulteriori informazioni, consulta [ Configurare i tentativi ](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries) nella documentazione. Fluent Bit
Ad esempio, `retry_limit 3` con le impostazioni predefinite (`scheduler.base 5`,`scheduler.cap 2000`,`net.connect_timeout 10s`) fornisce circa 70 secondi di tempo di attesa dello scheduler (10s \+ 20s \+ 40s), 40 secondi di timeout della connessione di rete (4 tentativi × 10 s), oltre a tentativi di ripristino del AWS plug-in, per un totale di circa 2-10 minuti a seconda delle condizioni della rete e dei timeout TCP del sistema operativo.
`scheduler.base`
I secondi base tra i tentativi (impostazione predefinita: 5). Consigliamo 10 secondi.
`scheduler.cap`
Il numero massimo di secondi tra i tentativi (impostazione predefinita: 2000). Consigliamo 60 secondi.
Il tempo di attesa tra i tentativi utilizza il backoff esponenziale con jitter:
```
wait_time = random(base, min(base × 2^retry_number, cap))
```
Ad esempio, con e: `scheduler.base 10` `scheduler.cap 60`
+ Primo tentativo: attesa casuale tra 10 e 20 secondi
+ Secondo tentativo: attesa casuale compresa tra 10 e 40 secondi
+ Terzo tentativo e successivo: attesa casuale compresa tra 10 e 60 secondi (limitata)
Per ulteriori informazioni, consulta [ Configurazione del tempo di attesa per il nuovo tentativo ](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry) e [ Connessione in rete nella documentazione. ](https://docs.fluentbit.io/manual/administration/networking) Fluent Bit
`workers`
Il numero di thread per l'elaborazione parallela dell'output. Più worker consentono svuotamenti simultanei, migliorando la produttività durante l'elaborazione di molti blocchi.
`auto_retry_requests`
Un'impostazione AWS specifica del plugin che fornisce un livello di riprova aggiuntivo prima del meccanismo di riprova integrato. Fluent Bit Il valore predefinito è `true`. Se abilitato, il plug-in AWS di output riprova internamente le richieste non riuscite prima che la richiesta venga considerata un flush non riuscito e soggetta alla configurazione. `retry_limit`
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` Accertarsi che `stopTimeout` superi il `Grace` periodo previsto Fluent Bit per consentire il completo risciacquo prima della ricezione. `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 gli scenari ad alta produttività:
```
[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
```
## Comprensione degli scenari di perdita di dati
I record possono andare persi in caso di interruzioni prolungate o problemi con le destinazioni di output. I consigli di configurazione contenuti in questa guida rappresentano gli approcci più efficaci per ridurre al minimo la perdita di dati, ma non possono garantire l'azzeramento delle perdite in caso di guasti prolungati. La comprensione di questi scenari ti aiuta a configurare Fluent Bit per massimizzare la resilienza.
I record possono essere persi in due modi: i record più vecchi vengono eliminati quando lo spazio di archiviazione si esaurisce, oppure i record più recenti vengono rifiutati quando il sistema non può accettare più dati.
### I record più vecchi vengono eliminati
I record memorizzati nel buffer più vecchi vengono eliminati quando i tentativi di nuovo tentativo sono esauriti o quando si `storage.total_limit_size` riempiono ed è necessario fare spazio per nuovi dati.
È stato superato il limite di tentativi
Si verifica dopo i tentativi (if`auto_retry_requests true`) del AWS plugin più 1 Fluent Bit tentativo iniziale più i tentativi. `retry_limit` Per attenuare il problema, impostate ogni plugin OUTPUT `retry_limit no_limits` per un numero infinito di tentativi:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
retry_limit no_limits
auto_retry_requests true
```
I tentativi infiniti impediscono la perdita dei record a causa dell'esaurimento dei tentativi, ma possono causare il riempimento. `storage.total_limit_size`
Limite di archiviazione raggiunto (buffering del file system)
Si verifica quando la destinazione di output non è disponibile per un periodo superiore al buffer CAN configurato. `storage.total_limit_size` Ad esempio, un buffer da 10 GB a 1 velocità di MB/s log fornisce circa 2,7 ore di buffering. Per mitigare il problema, aumentate il numero di plugin OUTPUT e fornite uno storage adeguato `storage.total_limit_size` per le attività di Amazon ECS:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
storage.total_limit_size 10G
```
### Record più recenti rifiutati
I record più recenti vengono eliminati quando lo spazio su disco è esaurito o quando l'input viene sospeso a causa di. `Mem_Buf_Limit`
Spazio su disco esaurito (buffering del file system)
Si verifica quando lo spazio su disco è completamente esaurito. Fluent Bitnon riesce a mettere in coda i nuovi record e questi vengono persi. Per mitigare il problema, somma tutti i `storage.total_limit_size` valori e fornisci uno storage adeguato per le attività di Amazon ECS. Per ulteriori informazioni, consulta [Requisiti di archiviazione delle attività di Amazon ECS](#firelens-storage-task-requirements).
Limite di memoria raggiunto (buffering di memoria)
Si verifica quando la destinazione di output non è disponibile e il buffer di memoria si riempie. I plugin di input in pausa smettono di accettare nuovi record. Per attenuare, usalo `storage.type filesystem` per migliorare la resilienza o aumentarlo. `Mem_Buf_Limit`
### Le migliori pratiche per ridurre al minimo la perdita di dati
Prendi in considerazione le seguenti best practice per ridurre al minimo la perdita di dati:
+ **Usa il buffering del file system**: impostato `storage.type filesystem` per una migliore resilienza durante le interruzioni.
+ **Dimensiona lo spazio di archiviazione in modo appropriato**: calcola in `storage.total_limit_size` base alla frequenza di registrazione e alla finestra di ripristino desiderata.
+ **Fornisci un disco adeguato**: assicurati che l'attività Amazon ECS disponga di spazio di archiviazione temporaneo sufficiente, Amazon EBS o Amazon EFS.
+ **Configura il comportamento dei tentativi**: equilibrio tra `retry_limit` (elimina i record dopo aver esaurito i tentativi) e (riprova a tempo indeterminato ma può occupare lo spazio di `no_limits` archiviazione).
## Usa la registrazione multidestinazione per garantire l'affidabilità
L'invio di log a più destinazioni elimina singoli punti di errore. Ad esempio, se CloudWatch Logs subisce un'interruzione, i log raggiungono comunque Amazon S3.
Multi-destination la registrazione offre i seguenti vantaggi. Il plug-in di output di 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 compressione [ S3 ](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression) nella documentazione. Fluent Bit
Multi-destination la registrazione può offrire i seguenti vantaggi:
+ **Ridondanza**: se una destinazione fallisce, i log continuano a raggiungere l'altra.
+ **Ripristino**: ricostruisci le lacune in un sistema rispetto all'altro.
+ **Durata**: archivia i log in Amazon S3 per la conservazione a lungo termine.
+ **Ottimizzazione dei costi**: conserva i log recenti in un servizio di interrogazione veloce come CloudWatch Logs con conservazione più breve, mentre archivia tutti i log su uno storage Amazon S3 a basso costo per la conservazione a lungo termine.
La seguente Fluent Bit configurazione invia i CloudWatch log sia a Logs che ad 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 *` modello, quindi tutti i record vengono inviati a entrambe le destinazioni in modo indipendente. In caso di interruzione di una destinazione, i log continuano a fluire verso l'altra mentre gli svuotamenti non riusciti si accumulano nel buffer del filesystem per riprovarli in un secondo momento.
## Usa la registrazione basata su file con il plugin tail input
Per gli scenari ad alto rendimento in cui la perdita dei log è un problema critico, puoi utilizzare un approccio alternativo: chiedi all'applicazione di scrivere i log sui file su disco e configurarli Fluent Bit per leggerli utilizzando il plug-in di input. `tail` Questo approccio ignora completamente il livello del driver di registrazione Docker.
File-based la registrazione 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'`DB`opzione), garantendo una durata tra i riavvii. Fluent Bit Questo aiuta a prevenire la perdita di log durante il riavvio del contenitore.
+ **Input-level buffering**: è possibile configurare i limiti del buffer di memoria direttamente sul plug-in di input utilizzando`Mem_Buf_Limit`, fornendo un controllo più granulare sull'utilizzo della memoria.
+ **Evita il sovraccarico di Docker**: i log vanno direttamente dal file all'altro Fluent Bit senza passare attraverso i buffer di log di Docker.
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 vengono archiviati i file di registro.
L'esempio seguente mostra una configurazione di input di coda 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 usate il plugin tail input, considerate quanto segue:
+ Implementa la rotazione dei log per i log delle tue applicazioni per prevenire l'esaurimento del disco. Monitora le metriche di volume sottostanti per valutare le prestazioni.
+ Prendi in considerazione impostazioni come `Ignore_Older``Read_from_Head`, e parser multilinea in base al formato del registro.
Per maggiori informazioni, vedi [ Tail ](https://docs.fluentbit.io/manual/pipeline/inputs/tail) nella Fluent Bit documentazione. Per le migliori pratiche, consulta [ la configurazione di Tail con le migliori pratiche ](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) nella Fluent Bit guida AWS alla 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.
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 router di FireLens log (il contenitore con l'`firelensConfiguration`oggetto nella sua definizione di 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](container-restart-policy.md).
`FLUENT_PORT`
La porta su cui il protocollo Fluent Forward è in ascolto.
È possibile utilizzare queste variabili di ambiente per accedere direttamente al router di Fluent Bit log dal codice dell'applicazione utilizzando il protocollo Fluent Forward, anziché scriverlo. `stdout` Questo approccio ignora il livello del driver di registrazione Docker, che offre i seguenti vantaggi:
+ **Latenza inferiore**: i log vengono inviati direttamente Fluent Bit senza passare attraverso l'infrastruttura di registrazione di Docker.
+ **Registrazione strutturata**: invia i dati di registro strutturati in modo nativo senza sovraccaricare la codifica JSON.
+ **Migliore controllo**: 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
+ **Vai — fluent-logger-golang ** [https://github.com/fluent/fluent-logger-golang](https://github.com/fluent/fluent-logger-golang)
+ **Python ** — [ fluent-logger-python ](https://github.com/fluent/fluent-logger-python)
+ **Java ** — [ fluent-logger-java ](https://github.com/fluent/fluent-logger-java)
+ **Node.js**[— nodo fluent-logger ](https://github.com/fluent/fluent-logger-node)
+ **Ruby — ** [ fluent-logger-ruby ](https://github.com/fluent/fluent-logger-ruby)
## Configura il limite del buffer Docker
Quando si crea una definizione di attività, è possibile specificare il numero di righe di log che vengono memorizzate nel buffer 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](https://docs.docker.com/engine/logging/drivers/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.
Considera quanto segue quando usi 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` KiB, 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
}
]
}
```