Padroneggia strumenti e best practice DevOps - DevOps Knowledge Hub Padroneggia strumenti e best practice DevOps - DevOps Knowledge Hub

Analisi Comune dei Log di Elasticsearch per una Risoluzione Efficace dei Problemi

Utilizza l'analisi dei log di Elasticsearch per diagnosticare più rapidamente problemi di salute del cluster, disco, memoria, recupero shard e query lente.

Analisi dei Log di Elasticsearch per una Risoluzione Efficace dei Problemi

L'analisi dei log di Elasticsearch è solitamente il modo più veloce per spiegare un cluster rosso, una richiesta di indicizzazione fallita o una lamentela per una ricerca lenta. Quando un cluster ha più nodi, i log ti dicono quale nodo ha visto il primo fallimento, quale componente ha reagito e se il problema riguarda disco, memoria, discovery, sicurezza o recupero shard.

Questa guida ti mostra come leggere i log di Elasticsearch senza inseguire rumore di fondo. Imparerai dove risiedono solitamente i log, quali campi sono importanti, cosa significano i messaggi di errore comuni e quando passare dal log principale del server ai log lenti o alle API di allocazione.

Comprendere la Struttura dei Log di Elasticsearch

Elasticsearch utilizza Log4j 2 per la registrazione. Le installazioni tramite pacchetto solitamente scrivono i file di log in /var/log/elasticsearch/. Le distribuzioni containerizzate spesso inviano i log all'output standard, dove il runtime del container o l'agente di logging li raccolgono. A seconda della versione e del file log4j2.properties, potresti vedere log in testo semplice, log JSON o entrambi.

Tipo di Installazione Percorso Tipico dei Log
Pacchetto Linux RPM/DEB /var/log/elasticsearch/
Docker Output standard del container
ZIP o tarball $ES_HOME/logs/

I file comuni includono il log principale del server, i log di deprecazione, i log lenti e talvolta i log di audit se il controllo di sicurezza è abilitato.

Le voci di log JSON solitamente includono campi come questi:

  • @timestamp: Quando si è verificato l'evento.
  • level: La gravità, come INFO, WARN o ERROR.
  • component: La classe o il sottosistema di Elasticsearch che ha registrato il messaggio.
  • cluster.uuid: L'identificatore del cluster.
  • node.name: Il nodo che ha generato la riga di log.
  • message: Il testo dell'evento leggibile dall'uomo.
{
  "@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]"
}

Dare Priorità ai Messaggi in Base al Livello di Log

Filtra prima per WARN e ERROR, poi allarga la ricerca intorno allo stesso timestamp. Le righe prima del primo ERROR spesso spiegano la causa meglio del tracciato dello stack finale.

Livello Cosa Significa Solitamente Prima Azione
ERROR Una richiesta, shard, nodo o sottosistema è fallito. Investigare immediatamente.
WARN Elasticsearch ha rilevato una condizione rischiosa. Controllare prima che diventi un'interruzione del servizio.
INFO Attività del ciclo di vita normale. Usare per contesto intorno a warning ed errori.
DEBUG / TRACE Dettaglio diagnostico approfondito. Abilitare brevemente solo quando necessario.

Evita di lasciare i nodi di produzione a DEBUG o TRACE. La registrazione verbosa può consumare rapidamente spazio su disco e aggiungere overhead evitabile.

Risoluzione dei Problemi con Pattern di Log Comuni

I log di Elasticsearch raramente dicono "la causa principale è X" in una frase chiara e pulita. Cerca un pattern: il primo avviso, il nome del componente, l'indice o shard interessato e il messaggio ripetuto che segue.

Fallimenti dei Controlli di Bootstrap

Elasticsearch esegue controlli di bootstrap in configurazioni di rete simili alla produzione. Questi controlli individuano impostazioni host non sicure come limiti bassi di file descriptor, limiti bassi di memoria virtuale o problemi di blocco della memoria. Se un controllo richiesto fallisce, il nodo si rifiuta di avviarsi.

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

Correggi l'impostazione host, riavvia il nodo e conferma che il log di avvio raggiunga il punto in cui il nodo si unisce al cluster.

Fallimenti di Binding di Rete e Discovery

Se il nodo si avvia ma non si unisce al cluster, cerca BindException, master not discovered, discovery e cluster.initial_master_nodes. Un BindException di solito indica un conflitto di indirizzo o porta. I messaggi di discovery spesso puntano a seed host errati, porta di trasporto 9300 bloccata, nomi di cluster non corrispondenti o impostazioni di sicurezza che impediscono ai nodi di fidarsi l'uno dell'altro.

Eccezioni del Circuit Breaker

I circuit breaker fermano le richieste che utilizzerebbero troppa memoria. La richiesta fallita restituisce un errore, ma il nodo dovrebbe rimanere attivo.

Cerca CircuitBreakingException o Data too large:

[2024-01-15T11:45:20,500][WARN][o.e.c.c.CircuitBreakerService] [es-node-02]
CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [123456789b], which is larger than the limit of [500mb]

Le cause comuni includono aggregazioni di grandi dimensioni, richieste che restituiscono troppi campi, indicizzazione bulk pesante o fielddata caricato per campi di testo. Identifica il pattern della richiesta, quindi riduci la dimensione della richiesta, correggi i mapping o aggiungi capacità.

Avvisi di Garbage Collection

Il log principale di Elasticsearch può segnalare lunghe pause di garbage collection della JVM. Cerca gc, JvmGcMonitorService e overhead. Alcuni avvisi durante un picco di carico possono essere normali. Avvisi ripetuti abbinati a una latenza di ricerca crescente di solito significano che l'heap è sotto pressione.

Recupero e Corruzione degli Shard

Quando uno shard non riesce ad allocarsi o un nodo rileva una copia locale dello shard danneggiata, Elasticsearch registra l'indice e il numero dello shard.

Cerca shard failed, failed shard, failed to recover o il nome dell'indice interessato:

[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

Se il messaggio menziona la corruzione, non eliminare i file manualmente. Conserva i log, verifica se esiste una buona replica e utilizza gli strumenti di recupero e le API di Elasticsearch invece di modificare direttamente il percorso dei dati.

Soglie del Disco

Elasticsearch modifica il comportamento di allocazione degli shard quando i nodi superano le soglie del disco. Cerca DiskThresholdMonitor, low disk watermark, high disk watermark o flood-stage disk watermark. I valori predefiniti possono variare in base alla versione e alla configurazione, quindi conferma le impostazioni del tuo cluster prima di agire:

GET /_cluster/settings?include_defaults=true&filter_path=**.disk.watermark*

Se un indice diventa di sola lettura dopo un evento di flood-stage, libera prima spazio su disco. Quindi rimuovi il blocco solo dopo che il nodo è sceso in sicurezza al di sotto della soglia:

PUT /my-index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

Utilizzare i Log Lenti per Problemi di Performance

Per ricerche lente o operazioni di indicizzazione, il log principale del server è spesso troppo generico. I log lenti tengono traccia delle operazioni che superano le soglie configurate. Configurali per indice con l'API delle impostazioni dell'indice.

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

I log lenti mostrano l'indice, lo shard, il tempo trascorso e la fonte della richiesta quando configurati per includerla. Usali per individuare query costose ripetute, intervalli di date ampi, ricerche con molti caratteri jolly e aggregazioni su campi che non sono mappati per un'aggregazione efficiente.

Un Flusso di Lavoro Pratico per la Revisione

Inizia dal sintomo visibile all'utente e procedi a ritroso:

  1. Controlla la salute del cluster e l'indice interessato.
  2. Cerca nei log WARN ed ERROR intorno all'ora dell'incidente.
  3. Confronta i log tra i nodi usando node.name e cluster.uuid.
  4. Segui il primo avviso ripetuto, non solo l'eccezione finale.
  5. Usa poi un'API mirata: spiegazione dell'allocazione per shard non assegnati, log lenti per richieste lente e statistiche del nodo per la pressione sulle risorse.

Ad esempio, se Kibana mostra un indice rosso, trova prima lo shard non assegnato, poi cerca nei log quel numero di indice e shard. Se i log menzionano soglie del disco, correggi la pressione sul disco prima di reindirizzare qualsiasi cosa. Se menzionano un nodo mancante, recupera quel nodo o ripristina da uno snapshot prima di considerare comandi di allocazione rischiosi.

Conclusione

Inizia ogni incidente di Elasticsearch trovando il primo avviso o errore rilevante, non il tracciato dello stack finale più rumoroso. Usa i log principali per problemi di nodo, discovery, disco, memoria e shard. Usa i log lenti quando il cluster è sano ma specifiche ricerche o carichi di lavoro di indicizzazione sono lenti.