Analisi dei log Elasticsearch comuni per una risoluzione efficace dei problemi
Elasticsearch è un motore di ricerca e analisi distribuito e potente, ma la sua complessità implica che quando le cose vanno male, diagnosticare la causa principale può essere difficile. Lo strumento più importante in assoluto per una risoluzione efficace dei problemi è il file di log di Elasticsearch. Questi log fungono da diario operativo del sistema, registrando ogni cosa, dalle sequenze di avvio riuscite e la manutenzione ordinaria del cluster a guasti critici come interruzioni del circuito di memoria (memory circuit breaker) o fallimenti nell'allocazione degli shard.
Padroneggiare l'arte di leggere e interpretare questi log è essenziale per mantenere un cluster sano e performante. Questa guida fornisce un approccio completo per comprendere la struttura dei log di Elasticsearch, identificare i messaggi critici e utilizzare l'analisi dei log per individuare e risolvere rapidamente i problemi operativi comuni, inclusi problemi di salute del cluster, vincoli di risorse e colli di bottiglia delle prestazioni.
1. Comprendere la struttura dei log di Elasticsearch
Elasticsearch utilizza il framework Apache Log4j 2 per il logging. Per impostazione predefinita, i log vengono scritti su file, spesso in formato JSON per una più facile analisi da parte delle macchine, sebbene il testo semplice sia anche comune a seconda della configurazione.
Posizione predefinita dei log
I file di log principali si trovano tipicamente nelle seguenti posizioni, a seconda del metodo di installazione (ad esempio, pacchetto RPM/DEB, Docker o file ZIP):
| Tipo di installazione | Percorso tipico del log |
|---|---|
| RPM/DEB (Linux) | /var/log/elasticsearch/ |
| Docker | Output standard del container (stdout/stderr) |
| ZIP/Tarball | $ES_HOME/logs/ |
Anatomia di una voce di log
Ogni voce di log, specialmente in formato JSON, contiene diversi campi chiave fondamentali per il contesto:
@timestamp: Quando si è verificato l'evento.level: La gravità dell'evento (ad esempio,INFO,WARN,ERROR).component: La specifica classe o servizio di Elasticsearch che ha generato il messaggio (ad esempio,o.e.c.c.ClusterService,o.e.n.Node). Questo aiuta a circoscrivere il sottosistema responsabile.cluster.uuid: Identifica il cluster a cui appartiene il log.node.name: Identifica il nodo che ha generato il log.message: La descrizione dell'evento.
{
"@timestamp": "2024-01-15T10:30:00.123Z",
"level": "WARN",
"component": "o.e.c.r.a.DiskThresholdMonitor",
"cluster.uuid": "abcde12345",
"node.name": "es-node-01",
"message": "high disk watermark [90%] exceeded on [es-node-01]"
}
2. Dare priorità alla risoluzione dei problemi con i livelli di log
Interpretare il campo level è il modo più rapido per dare priorità ai problemi. In generale, dovresti filtrare i log per concentrarti prima sui messaggi WARN ed ERROR.
| Livello | Descrizione | Priorità di azione |
|---|---|---|
| ERROR | Guasti critici che portano a interruzioni del servizio o perdita di dati (ad esempio, spegnimento del nodo, grave fallimento dello shard). | Immediata |
| WARN | Potenziali problemi o stati che richiedono monitoraggio (ad esempio, impostazioni deprecate, spazio su disco insufficiente, circuit breaker che si avvicina ai limiti). | Alta |
| INFO | Messaggi operativi generali (ad esempio, avvio del nodo, creazione dell'indice, allocazione dello shard completata). | Bassa/Monitoraggio |
| DEBUG/TRACE | Logging molto dettagliato utilizzato solo durante la diagnostica approfondita o lo sviluppo. | N/A (A meno che non si stia attivamente eseguendo il debug) |
Migliore Pratica: Evita di eseguire un cluster di produzione con il logging impostato su
DEBUGoTRACE, poiché ciò può consumare rapidamente spazio su disco e introdurre overhead di prestazioni.
3. Risoluzione dei problemi di scenari comuni tramite i log
I log di Elasticsearch forniscono indicatori diretti per vari tipi di guasti. Ecco i modelli di log critici da tenere d'occhio in diversi scenari.
3.1. Avvio del cluster e problemi di salute
Se un nodo non riesce a unirsi al cluster o il cluster rimane rosso/giallo, cerca i log generati durante la sequenza di avvio.
A. Errori nei controlli di bootstrap
Elasticsearch esegue controlli di bootstrap obbligatori all'avvio (ad esempio, garantendo memoria adeguata, descrittori di file e memoria virtuale). Se questi falliscono, il nodo si spegnerà immediatamente.
Modello di log: Cerca i messaggi bootstrap checks failed.
[2024-01-15T10:00:00,123][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] bootstrap checks failed
[2024-01-15T10:00:00,124][ERROR][o.e.b.BootstrapCheck$Bootstrap] [es-node-01] max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]
B. Errori di binding di rete e discovery
Problemi in cui i nodi non riescono a effettuare il binding alle porte richieste o non riescono a trovare altri membri del cluster.
Modello di log: Cerca BindException o Discovery failure.
3.2. Gestione delle risorse (Memoria e JVM)
I problemi relativi alla memoria si manifestano spesso come cali di prestazioni intermittenti o instabilità del nodo. I log sono cruciali per monitorare la salute della JVM.
A. Eccezioni del Circuit Breaker
Il circuit breaker previene l'esaurimento delle risorse interrompendo le operazioni che superano i limiti di memoria configurati. Quando scatta, le operazioni falliscono rapidamente, ma il nodo rimane stabile.
Modello di log: Cerca CircuitBreakerException o Data too large.
[2024-01-15T11:45:20,500][WARN][o.e.c.c.CircuitBreakerService] [es-node-02] \nCircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [123456789b], which is larger than the limit of [100.0/500mb]
B. Problemi di Garbage Collection (GC) della JVM
Sebbene i log dettagliati della GC siano spesso separati, il log principale di Elasticsearch a volte segnala attività GC elevata o lunghe pause GC (eventi stop-the-world).
Modello di log: Cerca riferimenti a GC, specialmente se compaiono messaggi WARN o ERROR riguardanti lunghe pause.
3.3. Errori di indexing e sharding
Gli errori di indexing o i dati corrotti spesso innescano eventi di fallimento dello shard.
A. Allocazione e fallimento dello Shard
Quando uno shard non riesce ad allocarsi, o un nodo rileva un problema di corruzione con una copia locale dello shard, ciò viene registrato.
Modello di log: Cerca shard failed o failed to recovery.
[2024-01-15T12:05:10,999][ERROR][o.e.i.e.Engine] [es-node-03] [my_index][2] fatal error in engine loop
java.io.IOException: Corrupt index files, checksum mismatch
B. Watermark del disco
Elasticsearch monitora lo spazio su disco e impedisce le scritture quando vengono raggiunti determinati watermark, il che può causare errori di indexing.
Modello di log: Cerca gli avvisi DiskThresholdMonitor, che tipicamente indicano un utilizzo dell'85% (low) o del 90% (high).
4. Ottimizzazione delle prestazioni con i log lenti (Slow Logs)
Per l'analisi delle prestazioni, in particolare query lente o operazioni di indexing, i log principali del cluster sono spesso insufficienti. Elasticsearch utilizza Slow Logs specializzati.
Gli Slow Logs tracciano le operazioni che superano le soglie di tempo predefinite. Devono essere configurati esplicitamente, staticamente in elasticsearch.yml o dinamicamente tramite l'API di Indices Settings.
Configurazione delle soglie dinamiche degli Slow Log
È possibile impostare soglie diverse per le fasi di indexing e di ricerca. L'esempio seguente imposta una soglia WARN di 1 secondo per le query di ricerca su un indice specifico.
PUT /my_index/_settings
{
"index.search.slowlog.threshold.query.warn": "1s",
"index.search.slowlog.threshold.query.info": "500ms",
"index.indexing.slowlog.threshold.index.warn": "1s"
}
Interpretazione delle voci degli Slow Log
Gli slow log forniscono informazioni dettagliate sull'esecuzione della query, inclusi l'indice/shard specifico, il tempo impiegato e il contenuto della query stessa. Ciò consente agli utenti di individuare query inefficienti o aggregazioni complesse.
Metriche chiave da cercare:
took: Tempo totale impiegato per l'operazione.source: Il testo completo della query o dell'operazione di indexing.id: L'ID del contesto di ricerca.
5. Migliori Pratiche per l'Analisi dei Log
Una risoluzione efficace dei problemi si basa su qualcosa di più del semplice sapere dove guardare; richiede un approccio sistematico.
A. Centralizza i tuoi log
In un ambiente distribuito, setacciare manualmente i log su dozzine di nodi non è pratico. Utilizza strumenti di logging centralizzati come Logstash, Filebeat o servizi di logging specializzati per aggregare i log in un singolo indice Elasticsearch (spesso denominato 'cluster di logging'). Ciò ti consente di cercare, filtrare e correlare gli eventi su tutti i nodi contemporaneamente.
B. Correlare gli eventi tra i nodi
Cerca eventi correlati utilizzando i campi @timestamp e cluster.uuid. Un fallimento dello shard su node-A potrebbe essere registrato come un ERROR su quel nodo, ma il gestore del cluster in esecuzione su node-B registrerà un INFO o WARN sul successivo tentativo di riallocare lo shard.
C. Fai attenzione ai pattern ripetitivi
Se vedi lo stesso messaggio di avviso o di errore ripetersi rapidamente (una 'tempesta di log'), ciò indica spesso un loop di fallimento continuo e ad alta intensità di risorse, come un processo che tenta ripetutamente di effettuare il binding a una porta non disponibile o uno scatto continuo del circuit breaker dovuto a un sovraccarico prolungato. Questi pattern richiedono un'indagine immediata.
D. Non ignorare i messaggi WARN
Gli avvisi agiscono spesso come indicatori precoci di futuri guasti catastrofici. Ad esempio, i messaggi WARN ripetuti su impostazioni deprecate o basso utilizzo della memoria dovrebbero essere affrontati in modo proattivo prima che degenerino in interruzioni a livello di ERROR.
Conclusione
I log di Elasticsearch sono una risorsa inestimabile, che fornisce il contesto essenziale necessario per andare oltre le correzioni sintomatiche e diagnosticare la causa principale dell'instabilità del cluster o delle scarse prestazioni. Comprendendo la struttura standard dei log, dando priorità ai messaggi in base alla gravità e sfruttando in modo specifico gli slow log per l'ottimizzazione delle prestazioni, gli amministratori possono ridurre significativamente i tempi di inattività e mantenere una solida salute del cluster.