Triagem de logs
Encontre incidentes relevantes- !Exaustão de memória / evento OOM — 1 linha(s) correspondente(s).
- △Falha de autenticação ou acesso — 1 linha(s) correspondente(s).
- △Falha de serviço ou timeout — 2 linha(s) correspondente(s).
Introdução
A Triagem de logs varre linhas de journal ou syslog coladas e conta correspondências em quatro categorias de alto sinal: exaustão de memória (OOM), travamentos e sinais de integridade de dados, falhas de autenticação e falhas ou timeouts genéricos de serviço.
Logs são ruidosos por natureza. O trabalho da ferramenta é reduzir o ruído às poucas linhas que geralmente merecem resposta a incidentes, para que você vá direto ao contexto relevante.
Objetivo
- Contar kills OOM e eventos out-of-memory, que indicam pressão de memória.
- Contar sinais de travamento, segfault, panic e corrupção, que indicam problemas de estabilidade ou integridade.
- Contar falhas de autenticação, que podem indicar força bruta ou configuração incorreta.
- Contar falhas de serviço e timeouts, a causa cotidiana de sistemas degradados.
Entradas
- Um colar de saída do journal (journalctl -n 500 --no-pager), linhas de syslog ou logs de aplicação.
- Uma linha de log por linha colada; qualquer formato de timestamp é aceito, pois a correspondência é baseada em palavras-chave.
Como funciona
Cada linha colada é testada contra quatro grupos de expressões regulares, em ordem: palavras-chave OOM (out of memory, oom, killed process), palavras-chave de travamento (segfault, panic, corrupt), palavras-chave de autenticação (failed password, authentication failure, denied) e palavras-chave de falha (failed, error, timeout).
Cada correspondência incrementa o contador do seu grupo. Uma linha pode contar em mais de um grupo, como um humano faria ao ler o log.
Grupos sem correspondências são omitidos do resultado, então um log tranquilo produz um único resultado limpo.
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 (java) Aug 22 14:06:14 node1 sshd[9201]: Failed password for invalid user admin Aug 22 14:07:02 node1 systemd[1]: backup.service: Failed with result 'exit-code'
Saída esperada
Alto: Exaustão de memória / evento OOM — 1 linha correspondente. Aviso: Falha de autenticação ou acesso — 1 linha correspondente. Aviso: Falha de serviço ou timeout — 1 linha correspondente.
Interpretando a saída
- Eventos OOM apontam para pressão de memória: verifique limites de cgroup, swap e o processo morto.
- Falhas de autenticação merecem olhar quem está tentando e com que frequência; tentativas repetidas com usuários inválidos costumam indicar varredura ou força bruta.
- Falhas de serviço (Failed with result 'exit-code') são melhor investigadas com journalctl -u <unit> -e para ver o código de saída e as linhas ao redor.
Riscos
- A correspondência por palavras-chave produz falsos positivos e perde contexto — uma linha que diz "no errors found" contém a palavra error e será contada.
- Trate as contagens como triagem, não como prova de um incidente.
- A ferramenta nunca lê seus logs do disco; ela só vê o que você cola, que é o design de privacidade de todo o site.
Limitações
- Ela não analisa timestamps, não correlaciona eventos entre hosts nem detecta sequências.
- Os grupos regex são deliberadamente simples; padrões personalizados não são suportados.
- É um auxílio de triagem, não um SIEM.
Referências oficiais
FAQ
Por que uma linha de aparência inocente é sinalizada como erro?
Porque a correspondência é baseada em palavras-chave. Uma linha como "no error found" contém o token error. Se isso incomoda, reduza o colar às linhas que importam.
O que devo fazer após um evento OOM?
Identifique o processo morto, verifique seu limite de memória e a pressão de memória do host, depois decida se deve aumentar limites, reduzir concorrência ou adicionar memória.
Isso pode substituir meu monitoramento?
Não. É um auxílio manual para colagens. Monitoramento contínuo, alertas e correlação exigem uma stack de logging de verdade.