Centro de Conhecimento DevOps
Centro de Conhecimento DevOps

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

Desbloqueie a solução de problemas eficiente do Elasticsearch dominando a análise de logs. Este guia detalha a estrutura dos logs do Elasticsearch, explica como priorizar problemas usando níveis de log (ERROR, WARN, INFO) e fornece exemplos práticos para diagnosticar problemas comuns. Aprenda a identificar padrões críticos relacionados a falhas de inicialização do cluster, exceções de disjuntor de memória (memory circuit breaker), problemas de alocação de shards e gargalos de desempenho usando logs lentos (slow logs) dedicados. Leitura essencial para equipes de operações e administradores que buscam uma resolução rápida para problemas complexos de sistemas distribuídos.

43 visualizações

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

O Elasticsearch é um motor de busca e análise distribuído e poderoso, mas sua complexidade significa que, quando as coisas dão errado, diagnosticar a causa raiz pode ser um desafio. A ferramenta mais importante para uma solução de problemas eficaz é o arquivo de log do Elasticsearch. Esses logs funcionam como o diário operacional do sistema, registrando tudo, desde sequências de inicialização bem-sucedidas e manutenção rotineira do cluster até falhas críticas, como disparos de disjuntores de memória ou falhas de alocação de shard.

Dominar a arte de ler e interpretar esses logs é essencial para manter um cluster saudável e com bom desempenho. Este guia oferece uma abordagem abrangente para entender a estrutura de log do Elasticsearch, identificar mensagens críticas e usar a análise de logs para identificar e resolver rapidamente problemas operacionais comuns, incluindo problemas de saúde do cluster, restrições de recursos e gargalos de desempenho.

1. Entendendo a Estrutura de Log do Elasticsearch

O Elasticsearch utiliza o framework Apache Log4j 2 para logging. Por padrão, os logs são gravados em arquivos, muitas vezes em formato JSON para facilitar a análise por máquina, embora o texto simples também seja comum, dependendo da configuração.

Localização Padrão dos Logs

Os arquivos de log principais são normalmente encontrados nos seguintes locais, dependendo do seu método de instalação (por exemplo, pacote RPM/DEB, Docker ou arquivo ZIP):

Tipo de Instalação Caminho Típico do Log
RPM/DEB (Linux) /var/log/elasticsearch/
Docker Saída padrão do contêiner (stdout/stderr)
ZIP/Tarball $ES_HOME/logs/

Anatomia de uma Entrada de Log

Cada entrada de log, especialmente no formato JSON, contém vários campos chave críticos para o contexto:

  • @timestamp: Quando o evento ocorreu.
  • level: A severidade do evento (por exemplo, INFO, WARN, ERROR).
  • component: A classe ou serviço específico do Elasticsearch que gerou a mensagem (por exemplo, o.e.c.c.ClusterService, o.e.n.Node). Isso ajuda a restringir o subsistema responsável.
  • cluster.uuid: Identifica o cluster ao qual o log pertence.
  • node.name: Identifica o nó que gerou o log.
  • message: A descrição do 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. Priorizando a Solução de Problemas com Níveis de Log

Interpretar o campo level é a maneira mais rápida de priorizar problemas. Você deve geralmente filtrar os logs para se concentrar primeiro nas mensagens WARN e ERROR.

Nível Descrição Prioridade de Ação
ERROR Falhas críticas que levam à interrupção do serviço ou perda de dados (por exemplo, desligamento de nó, falha grave de shard). Imediata
WARN Problemas ou estados potenciais que exigem monitoramento (por exemplo, configurações obsoletas, pouco espaço em disco, disjuntor se aproximando dos limites). Alta
INFO Mensagens operacionais gerais (por exemplo, inicialização do nó, criação de índice, alocação de shard concluída). Baixa/Monitoramento
DEBUG/TRACE Logging muito verboso usado apenas durante diagnósticos profundos ou desenvolvimento. N/A (A menos que esteja depurando ativamente)

Melhor Prática: Evite executar um cluster de produção com o logging definido como DEBUG ou TRACE, pois isso pode consumir rapidamente o espaço em disco e introduzir sobrecarga de desempenho.

3. Solução de Problemas de Cenários Comuns por Meio de Logs

Os logs do Elasticsearch fornecem indicadores diretos para vários tipos de falhas. Aqui estão padrões de log críticos a serem observados em diferentes cenários.

3.1. Problemas de Inicialização e Saúde do Cluster

Se um nó falhar ao ingressar no cluster ou se o cluster permanecer vermelho/amarelo, procure logs gerados durante a sequência de inicialização.

A. Falhas nas Verificações de Bootstrap

O Elasticsearch realiza verificações de bootstrap obrigatórias na inicialização (por exemplo, garantindo memória, descritores de arquivo e memória virtual adequados). Se falharem, o nó será desligado imediatamente.

Padrão de Log: Procure por mensagens 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. Falhas de Associação de Rede e Descoberta

Problemas em que os nós não conseguem se vincular às portas necessárias ou não conseguem encontrar outros membros do cluster.

Padrão de Log: Procure por BindException ou Discovery failure.

3.2. Gerenciamento de Recursos (Memória e JVM)

Problemas relacionados à memória geralmente se manifestam como quedas intermitentes de desempenho ou instabilidade do nó. Os logs são cruciais para monitorar a saúde da JVM.

A. Exceções de Disjuntor (Circuit Breaker)

O disjuntor impede o esgotamento de recursos, interrompendo operações que excedem os limites de memória configurados. Quando disparadas, as operações falham rapidamente, mas o nó permanece estável.

Padrão de Log: Procure por CircuitBreakerException ou 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. Problemas de Coleta de Lixo (GC) da JVM

Embora os logs detalhados de GC sejam frequentemente separados, o log principal do Elasticsearch às vezes relata alta atividade de GC ou longas pausas de GC (eventos stop-the-world).

Padrão de Log: Procure por referências a GC, especialmente se aparecerem mensagens WARN ou ERROR sobre longas pausas.

3.3. Falhas de Indexação e Sharding

Falhas de indexação ou dados corrompidos geralmente acionam eventos de falha de shard.

A. Alocação e Falha de Shard

Quando um shard falha ao alocar, ou um nó detecta um problema de corrupção em uma cópia local do shard, isso é registrado.

Padrão de Log: Procure por shard failed ou 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. Limiares de Disco (Disk Watermarks)

O Elasticsearch monitora o espaço em disco e impede gravações quando certos limiares são atingidos, o que pode causar falhas de indexação.

Padrão de Log: Procure por avisos de DiskThresholdMonitor, geralmente indicando uso de 85% (low) ou 90% (high).

4. Ajuste de Desempenho com Logs de Lentidão (Slow Logs)

Para análise de desempenho, especialmente consultas lentas ou operações de indexação, os logs principais do cluster são frequentemente insuficientes. O Elasticsearch utiliza Logs de Lentidão especializados.

Os Logs de Lentidão rastreiam operações que excedem os limiares de tempo predefinidos. Eles devem ser configurados explicitamente, seja estaticamente em elasticsearch.yml ou dinamicamente por meio da API de Configurações de Índice.

Configurando Limiares Dinâmicos de Slow Log

Você pode definir limiares diferentes para as fases de indexação e pesquisa. O exemplo a seguir define um limiar de WARN de 1 segundo para consultas de pesquisa em um índice específico.

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

Interpretando Entradas de Slow Log

Os logs de lentidão fornecem informações detalhadas sobre a execução da consulta, incluindo o índice/shard específico, o tempo gasto e o próprio conteúdo da consulta. Isso permite que os usuários identifiquem consultas ineficientes ou agregações complexas.

Métricas Chave a Procurar:

  • took: Tempo total gasto na operação.
  • source: O texto completo da consulta ou operação de indexação.
  • id: O ID do contexto de pesquisa.

5. Melhores Práticas para Análise de Logs

A solução de problemas eficaz depende de mais do que apenas saber onde procurar; requer uma abordagem sistemática.

A. Centralize Seus Logs

Em um ambiente distribuído, vasculhar manualmente logs em dezenas de nós é impraticável. Use ferramentas de logging centralizado como Logstash, Filebeat ou serviços de logging especializados para agregar logs em um único índice Elasticsearch (frequentemente referido como o 'cluster de logging'). Isso permite que você pesquise, filtre e correlacione eventos em todos os nós simultaneamente.

B. Correlacione Eventos Entre Nós

Procure por eventos relacionados usando os campos @timestamp e cluster.uuid. Um shard falhando em node-A pode ser registrado como um ERROR nesse nó, mas o gerenciador de cluster em execução em node-B registrará um INFO ou WARN sobre a tentativa subsequente de realocar o shard.

C. Observe Padrões Repetitivos

Se você vir a mesma mensagem de aviso ou erro repetida rapidamente (uma 'tempestade de logs'), isso geralmente indica um loop de falha contínuo e intensivo em recursos, como um processo tentando repetidamente se vincular a uma porta indisponível ou um acionamento contínuo do disjuntor devido a sobrecarga sustentada. Esses padrões exigem investigação imediata.

D. Não Ignore Mensagens WARN

Os avisos geralmente atuam como indicadores precoces de futuras falhas catastróficas. Por exemplo, mensagens WARN repetidas sobre configurações obsoletas ou baixo uso de memória devem ser abordadas proativamente antes que escalem para interrupções de nível ERROR.

Conclusão

Os logs do Elasticsearch são um recurso inestimável, fornecendo o contexto essencial necessário para ir além de correções sintomáticas e diagnosticar a causa raiz da instabilidade do cluster ou do baixo desempenho. Ao entender a estrutura de log padrão, priorizar mensagens com base na severidade e alavancar especificamente os logs de lentidão para ajuste de desempenho, os administradores podem reduzir significativamente o tempo de inatividade e manter uma saúde robusta do cluster.