Análise Comum de Logs do Elasticsearch para Solução de Problemas Eficaz

A análise de logs do Elasticsearch é geralmente a maneira mais rápida de explicar um cluster vermelho, uma solicitação de indexação falha ou uma reclamação de pesquisa lenta. Quando um cluster tem vários nós, os logs informam qual nó viu a primeira falha, qual componente reagiu e se o problema é de disco, memória, descoberta, segurança ou recuperação de shards.

Este guia mostra como ler logs do Elasticsearch sem perseguir ruídos. Você aprenderá onde os logs geralmente residem, quais campos são importantes, o que significam as mensagens de falha comuns e quando alternar do log principal do servidor para logs lentos ou APIs de alocação.

Entendendo a Estrutura dos Logs do Elasticsearch

O Elasticsearch usa Log4j 2 para registro. Instalações de pacote geralmente escrevem arquivos de log em /var/log/elasticsearch/. Implantações conteinerizadas frequentemente enviam logs para a saída padrão, onde seu runtime de contêiner ou agente de registro os coleta. Dependendo da sua versão e log4j2.properties, você pode ver logs de texto simples, logs JSON ou ambos.

Tipo de Instalação	Caminho Típico do Log
Pacote Linux RPM/DEB	/var/log/elasticsearch/
Docker	Saída padrão do contêiner
ZIP ou tarball	$ES_HOME/logs/

Arquivos comuns incluem o log principal do servidor, logs de depreciação, logs lentos e, às vezes, logs de auditoria se a auditoria de segurança estiver ativada.

Entradas de log JSON geralmente incluem campos como estes:

• @timestamp: Quando o evento ocorreu.
• level: A gravidade, como INFO, WARN ou ERROR.
• component: A classe ou subsistema do Elasticsearch que registrou a mensagem.
• cluster.uuid: O identificador do cluster.
• node.name: O nó que gerou a linha de log.
• message: O texto do evento legível por humanos.

{
  "@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]"
}

Priorizando Mensagens por Nível de Log

Filtre primeiro por WARN e ERROR, depois amplie a pesquisa em torno do mesmo timestamp. As linhas antes do primeiro ERROR geralmente explicam a causa melhor do que o stack trace final.

Nível	O Que Geralmente Significa	Primeira Ação
ERROR	Uma solicitação, shard, nó ou subsistema falhou.	Investigar imediatamente.
WARN	O Elasticsearch detectou uma condição arriscada.	Verificar antes que se torne uma interrupção.
INFO	Atividade normal do ciclo de vida.	Usar para contexto em torno de avisos e erros.
DEBUG / TRACE	Detalhe diagnóstico profundo.	Ativar brevemente apenas quando necessário.

Evite deixar nós de produção em DEBUG ou TRACE. O registro verboso pode consumir disco rapidamente e adicionar sobrecarga evitável.

Solucionando Padrões Comuns de Log

Os logs do Elasticsearch raramente dizem "a causa raiz é X" em uma frase limpa. Procure por um padrão: o primeiro aviso, o nome do componente, o índice ou shard afetado e a mensagem repetida que se segue.

Falhas na Verificação de Bootstrap

O Elasticsearch realiza verificações de bootstrap em configurações de rede semelhantes às de produção. Essas verificações capturam configurações de host inseguras, como limites baixos de descritores de arquivo, limites baixos de memória virtual ou problemas de bloqueio de memória. Se uma verificação necessária falhar, o nó se recusa a iniciar.

Pesquise por 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]

Corrija a configuração do host, reinicie o nó e confirme se o log de inicialização atinge o ponto em que o nó se junta ao cluster.

Falhas de Binding de Rede e Descoberta

Se o nó iniciar mas não se juntar ao cluster, pesquise por BindException, master not discovered, discovery e cluster.initial_master_nodes. Um BindException geralmente aponta para um conflito de endereço ou porta. Mensagens de descoberta frequentemente apontam para hosts seed ruins, porta de transporte 9300 bloqueada, nomes de cluster incompatíveis ou configurações de segurança que impedem os nós de confiarem uns nos outros.

Exceções de Disjuntor (Circuit Breaker)

Os disjuntores interrompem solicitações que usariam muita memória. A solicitação falha retorna um erro, mas o nó deve permanecer ativo.

Pesquise por CircuitBreakingException ou 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]

Causas comuns incluem agregações grandes, solicitações que retornam muitos campos, indexação em massa pesada ou fielddata carregado para campos de texto. Identifique o padrão da solicitação, depois reduza o tamanho da solicitação, corrija os mapeamentos ou adicione capacidade.

Avisos de Garbage Collection (Coleta de Lixo)

O log principal do Elasticsearch pode relatar pausas longas de garbage collection da JVM. Pesquise por gc, JvmGcMonitorService e overhead. Alguns avisos durante um pico de carga podem ser normais. Avisos repetidos emparelhados com latência de pesquisa crescente geralmente significam que o heap está sob pressão.

Recuperação de Shards e Corrupção

Quando um shard falha ao ser alocado ou um nó detecta uma cópia de shard local ruim, o Elasticsearch registra o índice e o número do shard.

Pesquise por shard failed, failed shard, failed to recover ou o nome do índice afetado:

[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 a mensagem mencionar corrupção, não exclua arquivos manualmente. Preserve os logs, verifique se existe uma réplica boa e use as ferramentas de recuperação e APIs do Elasticsearch em vez de editar o caminho dos dados diretamente.

Watermarks de Disco

O Elasticsearch altera o comportamento de alocação de shards quando os nós cruzam os watermarks de disco. Pesquise por DiskThresholdMonitor, low disk watermark, high disk watermark ou flood-stage disk watermark. Os padrões podem variar por versão e configuração, então confirme as configurações do seu cluster antes de agir:

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

Se um índice se tornar somente leitura após um evento de flood-stage, primeiro libere espaço em disco. Em seguida, remova o bloqueio somente depois que o nó estiver seguramente abaixo do watermark:

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

Usando Logs Lentos para Problemas de Performance

Para pesquisas lentas ou operações de indexação, o log principal do servidor é frequentemente muito amplo. Logs lentos rastreiam operações que excedem os limites configurados. Configure-os por índice com a API de configurações do índice.

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

Os logs lentos mostram o índice, shard, tempo decorrido e origem da solicitação quando configurados para incluí-la. Use-os para detectar consultas caras repetidas, intervalos de datas amplos, pesquisas com muitos curingas e agregações em campos que não são mapeados para agregação eficiente.

Um Fluxo de Trabalho de Revisão Prático

Comece com o sintoma visível pelo usuário e trabalhe de trás para frente:

1. Verifique a saúde do cluster e o índice afetado.
2. Pesquise logs WARN e ERROR em torno do horário do incidente.
3. Compare logs entre nós usando node.name e cluster.uuid.
4. Siga o primeiro aviso repetido, não apenas a exceção final.
5. Use uma API direcionada em seguida: allocation explain para shards não atribuídos, slow logs para solicitações lentas e node stats para pressão de recursos.

Por exemplo, se o Kibana mostrar um índice vermelho, primeiro encontre o shard não atribuído, depois pesquise nos logs por esse índice e número de shard. Se os logs mencionarem watermarks de disco, corrija a pressão do disco antes de redirecionar qualquer coisa. Se mencionarem um nó faltante, recupere esse nó ou restaure de um snapshot antes de considerar comandos de alocação arriscados.

Conclusão

Comece todo incidente do Elasticsearch encontrando o primeiro aviso ou erro relevante, não o stack trace final mais ruidoso. Use os logs principais para falhas de nó, descoberta, disco, memória e shard. Use logs lentos quando o cluster estiver saudável, mas pesquisas específicas ou cargas de trabalho de indexação estiverem lentas.