Nel contesto della gestione delle infrastrutture cloud-native, la raccolta, l’analisi e la visualizzazione dei log rappresentano attività fondamentali per garantire il monitoraggio efficace e continuo delle applicazioni. Questo articolo descrive un problema reale nella gestione dei log applicativi di tipo analytics, con particolare riferimento a un limite non documentato nella dimensione delle richieste verso OpenSearch, che ha causato la mancata visualizzazione e analisi dei dati su Grafana.
Il Contesto
L’ambiente in esame è costituito da una pipeline di log management progettata per raccogliere e analizzare log di tipo analytics, ovvero dati relativi all’andamento delle applicazioni, alla durata e all’esito delle operazioni significative.
L’architettura implementata è la seguente:
- Fluent Bit come client di raccolta log installato sulle VM applicative, che invia i log grezzi a un nodo centralizzatore.
- Fluentd deployato come Deployment su un cluster EKS (Elastic Kubernetes Service) di AWS, funge da accentratore, si occupa del parsing dei log e li inoltra a un motore di ricerca.
- OpenSearch, utilizzato come motore per la memorizzazione e indicizzazione dei log.
- Grafana, utilizzato per la visualizzazione delle metriche e dashboard con OpenSearch come fonte dati.
Il Problema. Cosa succede quando chunk_limit_size supera i 10 MiB in OpenSearch
Durante l’utilizzo ordinario dell’infrastruttura, è stata rilevata l’assenza di dati in alcune dashboard di Grafana. L’analisi preliminare ha indicato un problema di mancata ingestion dei dati in OpenSearch da parte di alcune origini log.
Nei log di Fluentd compariva l’errore
Dopo aver escluso problemi di rete, dall’ispezione del file system dei pod Fluentd, si è scoperto che Fluentd stava tentando di inviare chunk (blocchi di eventi) di dimensioni elevate, anche superiori ai 200 MB, rivelando un potenziale conflitto legato alla dimensione delle richieste. Il buffer di Fluentd, infatti, è stato configurato per scrivere temporaneamente, prima dell’invio, i dati su file in modo da gestire picchi di carico o interruzioni temporanee. Tuttavia, in nessuno dei plugin di output era configurato un limite esplicito alla dimensione dei chunk.
Gli Obiettivi
Ci siamo posti due obiettivi principali:
- ripristinare la completa visibilità dei log analytics su tutte le dashboard di Grafana;
- garantire che i log inviati da Fluentd siano sempre accettati da OpenSearch.
La Soluzione
Il troubleshooting si è diviso principalmente in due fasi.
Ripristino immediato
Nella prima fase, è stato ripristinato rapidamente il servizio, ovviando alla mancata visualizzazione dei grafici su Grafana. Nella seconda abbiamo trovato una soluzione definitiva.
- Ripristino immediato - I chunk “pesanti” sono stati temporaneamente spostati in un’altra directory per sbloccare il buffer di output. Questo ha permesso il ripristino dell’invio dei log da parte degli output bloccati.
Analisi approfondita e tuning definitivo
- Analisi dei limiti OpenSearch specifici per la taglia dell’istanza: è stato verificato che AWS OpenSearch impone un limite non modificabile di 10 MiB per ogni richiesta HTTP.
- Allineamento dei parametri in Fluentd: il parametro chunk_limit_size nel plugin output verso OpenSearch, è stato impostato a 9 MiB, in modo da restare sotto soglia e garantire compatibilità con il limite del motore di ricerca.
- Monitoraggio e validazione: sono stati condotti test di invio log con il nuovo parametro per verificare la corretta ricezione, indicizzazione e visualizzazione su Grafana.
- Audit del comportamento silenzioso: è stata attivata una maggiore verbosità nei log di Fluentd per intercettare tempestivamente eventuali errori HTTP in fase di invio a OpenSearch.
I Risultati
- Ripristinata la completa ricezione e indicizzazione dei log per tutte le origini.
- Dashboard Grafana nuovamente aggiornate con dati analytics in tempo quasi reale.
- Nessun impatto significativo sulle performance è stato rilevato in seguito alla riduzione della dimensione dei chunk.
- Migliorata l’osservabilità del sistema in caso di futuri errori di ingestione, grazie a una configurazione più accurata del logging di Fluentd.
Le Raccomandazioni Conclusive
Questo caso evidenzia l’importanza di non dare per scontati i limiti impliciti delle piattaforme gestite come OpenSearch su AWS. Dall’analisi del caso sono dunque emerse alcune buone pratiche di riferimento.
- Verificare sempre le impostazioni di compatibilità tra client di logging e motore di storage, soprattutto per quanto riguarda limiti di dimensioni o timeout.
- Non affidarsi ai parametri di default, specialmente in ambienti in cui si gestiscono volumi significativi di dati.
- Monitorare proattivamente i log di errore di Fluentd, configurando alert o notifiche in caso di errori.
- Documentare i limiti impliciti dei componenti utilizzati nella pipeline per facilitare la manutenzione futura.
- Effettuare periodici stress test per validare il comportamento dell’infrastruttura in condizioni reali.
Ti è piaciuto quanto hai letto? Iscriviti a MISPECIAL, la nostra newsletter, per ricevere altri interessanti contenuti.
Iscriviti a MISPECIAL
