Analisador de logs de validador
Encontre padrões de falha em logs de nodesIPs, hostnames, caminhos e tokens são mascarados nos trechos.
Introdução
O analisador de logs de validador examina logs de nodes ou validadores colados e relata padrões de falha conhecidos: eventos out-of-memory, discos cheios, slots e atestações perdidos, chaves de validador duplicadas, risco de slashing, deriva de relógio, número baixo de peers, timeouts, falhas de conexão, corrupção de banco de dados, snapshots incompatíveis e reinicializações repetidas.
Cada detecção mostra severidade, categoria, número de ocorrências, primeira e última linha, um trecho mascarado, a causa provável, verificações recomendadas e um nível de confiança. A análise roda inteiramente no navegador: os logs não são enviados nem persistidos.
Objetivo
- Detectar os padrões de falha que mais derrubam ou penalizam um node validator.
- Agrupar ocorrências por padrão com contagem, primeira e última linha e trecho mascarado.
- Separar regras Linux compartilhadas de regras de consenso específicas de cada chain.
- Mascarar endereços IPv4/IPv6, hostnames, caminhos, tokens e possíveis segredos, e nunca repetir material semelhante a seed ou chave privada por inteiro.
Entradas
- Uma colagem de saída de journald, syslog, node ou validador, ou um arquivo .log/.txt.
- A entrada é limitada a 2 MB e 20 000 linhas; entradas maiores são truncadas com um aviso.
- Nada é enviado; os dados podem ser apagados com um clique.
Como funciona
Cada linha é comparada com um conjunto de padrões Linux compartilhados (OOM, disco cheio, erros de I/O, deriva de relógio, falhas de autenticação, conexões recusadas, timeouts, conflitos de porta, corrupção de banco de dados, loops de reinicialização) e padrões de validador/consenso (slots perdidos, atestações perdidas, falhas de votação, chaves de validador duplicadas, indicadores de slashing, discrepâncias de snapshot e versão).
As ocorrências são contadas por padrão, com primeira e última linha; um trecho curto da primeira ocorrência é mantido e mascarado.
Linhas com aparência de seed phrase ou chave privada nunca são repetidas: produzem um achado ocultado de alta severidade.
Marcadores de início repetidos produzem um achado de loop de reinicialização; linhas de erro recorrentes que não correspondem a nenhum padrão conhecido produzem um achado de erro desconhecido.
As detecções são ordenadas por severidade e exibidas com causa, verificações recomendadas e confiança.
Exemplo testável
Experimente — a análise roda localmente no seu navegador.
Exemplo
Aug 22 14:06:11 node1 kernel: Out of memory: Killed process 8492 (geth) Aug 22 14:07:02 node1 geth[8492]: ERROR[08-22|14:07:02] Failed to write block err="no space left on device" Aug 22 14:08:40 node1 geth[8492]: WARN[08-22|14:08:40] Missed slot slot=512344
Saída esperada
ALTO OOM killer · 1 ocorrência · linha 1 ALTO Disco cheio · 1 ocorrência · linha 2 AVISO Slot perdido · 1 ocorrência · linha 3 Causa provável: pressão de memória + disco cheio → o node parou e perdeu um slot.
Interpretando a saída
- Achados altos (OOM, disco cheio, corrupção de banco de dados, risco de slashing, validador duplicado) exigem ação antes que o node volte a ser confiável.
- Um slot ou atestação perdida é um aviso: uma vez é ruído, um padrão é um problema.
- O trecho mascarado preserva o contexto para busca, protegendo IPs, caminhos e tokens.
- Um resultado limpo significa que nenhum padrão conhecido correspondeu — não é prova de que o node está saudável.
Riscos
- Um node morto por OOM no meio da sincronização pode corromper o banco de dados e forçar uma re-sincronização.
- Chaves de validador duplicadas e indicadores de slashing são os achados mais perigosos: aja imediatamente e pare o processo afetado.
- Logs podem conter segredos. A ferramenta os mascara, mas não cole logs com chaves reais em lugar nenhum.
Limitações
- A correspondência de padrões é heurística; falsos positivos e lacunas são possíveis.
- Analisa apenas a janela colada — não vê eventos anteriores ou posteriores a ela.
- É um auxílio de triagem, não um sistema de monitoramento.
Referências oficiais
FAQ
Para onde vão meus dados de log?
Para lugar nenhum. A análise roda localmente no seu navegador. Não existe endpoint de upload, os dados não são persistidos e a URL nunca contém conteúdo de log. Use o botão de limpar para apagar a área de texto.
O que devo fazer se encontrar um indicador de slashing?
Pare imediatamente o processo do validador, não o reinicie com as mesmas chaves até entender a causa e consulte a documentação de slashing da chain. Esta ferramenta apenas detecta padrões; a decisão é sua.
Por que IPs e caminhos são substituídos por <ip>/<path>?
Logs são sensíveis. O mascaramento permite buscar e compartilhar trechos sem expor detalhes da sua infraestrutura nem eventuais credenciais presentes nas linhas.