Analisi log
Individua incidenti rilevanti- !Esaurimento memoria / evento OOM — 1 righe corrispondenti.
- △Errore di autenticazione o accesso — 1 righe corrispondenti.
- △Errore di servizio o timeout — 2 righe corrispondenti.
Introduzione
L'analisi log scansiona le righe journal o syslog incollate e conta le corrispondenze in quattro categorie ad alto segnale: esaurimento memoria (OOM), crash e segnali di integrità dati, errori di autenticazione ed errori o timeout generici di servizio.
I log sono rumorosi per natura. Il compito dello strumento è ridurre il rumore alle poche righe che di solito meritano una risposta a incidenti, così puoi passare direttamente al contesto rilevante.
Obiettivo
- Contare kill OOM ed eventi out-of-memory, che indicano pressione sulla memoria.
- Contare segnali di crash, segfault, panic e corruzione, che indicano problemi di stabilità o integrità.
- Contare errori di autenticazione, che possono indicare brute force o configurazione errata.
- Contare errori di servizio e timeout, la causa quotidiana dei sistemi degradati.
Input
- Un incolla di output journal (journalctl -n 500 --no-pager), righe syslog o log applicativi.
- Una riga di log per riga incollata; qualsiasi formato di timestamp è accettato poiché il match è basato su parole chiave.
Come funziona
Ogni riga incollata viene testata contro quattro gruppi di espressioni regolari in ordine: parole chiave OOM (out of memory, oom, killed process), parole chiave di crash (segfault, panic, corrupt), parole chiave di autenticazione (failed password, authentication failure, denied) e parole chiave di errore (failed, error, timeout).
Ogni corrispondenza incrementa il contatore del suo gruppo. Una riga può contare in più gruppi, come farebbe un umano leggendo il log.
I gruppi senza corrispondenze vengono omessi dal risultato, così un log tranquillo produce un singolo risultato pulito.
Esempio testabile
Prova — l'analisi gira localmente nel tuo browser.
Esempio
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'
Output atteso
Alto: Esaurimento memoria / evento OOM — 1 riga corrispondente. Avviso: Errore di autenticazione o accesso — 1 riga corrispondente. Avviso: Errore di servizio o timeout — 1 riga corrispondente.
Leggere l'output
- Gli eventi OOM puntano alla pressione sulla memoria: controlla i limiti cgroup, lo swap e il processo ucciso.
- Gli errori di autenticazione meritano uno sguardo su chi prova e con quale frequenza; tentativi ripetuti con utenti non validi spesso indicano scansioni o brute force.
- Gli errori di servizio (Failed with result 'exit-code') si indagano meglio con journalctl -u <unit> -e per vedere il codice di uscita e le righe circostanti.
Rischi
- Il match per parole chiave produce falsi positivi e perde contesto — una riga che dice "no errors found" contiene la parola error e verrà contata.
- Tratta i conteggi come triage, non come prova di un incidente.
- Lo strumento non legge mai i tuoi log dal disco; vede solo ciò che incolli, ed è il design di privacy di tutto il sito.
Limiti
- Non analizza timestamp, non correla eventi tra host e non rileva sequenze.
- I gruppi regex sono volutamente semplici; i pattern personalizzati non sono supportati.
- È un aiuto al triage, non un SIEM.
Riferimenti ufficiali
FAQ
Perché una riga dall'aspetto innocuo viene segnalata come errore?
Perché il match è basato su parole chiave. Una riga come "no error found" contiene il token error. Se ti disturba, riduci l'incolla alle righe che contano.
Cosa fare dopo un evento OOM?
Identifica il processo ucciso, controlla il suo limite di memoria e la pressione di memoria dell'host, poi decidi se alzare i limiti, ridurre la concorrenza o aggiungere memoria.
Può sostituire il mio monitoraggio?
No. È un aiuto manuale per gli incollati. Monitoraggio continuo, alerting e correlazione richiedono uno stack di logging vero.