Logg-triage
Finn hendelser med høy signalverdi- !Minnemangel / OOM-hendelse — 1 samsvarende linje(r).
- △Autentiserings- eller tilgangsfeil — 1 samsvarende linje(r).
- △Tjenestefeil eller tidsavbrudd — 2 samsvarende linje(r).
Innledning
Logg-triage skanner innlimte journal- eller syslog-linjer og teller treff i fire kategorier med høy signalverdi: minnemangel (OOM), krasj og dataintegritetssignaler, autentiseringsfeil og generelle tjenestefeil eller tidsavbrudd.
Logger er støyende av natur. Verktøyets oppgave er å redusere støyen til de få linjene som vanligvis fortjener en hendelsesrespons, slik at du kan hoppe rett til den relevante konteksten.
Mål
- Tell OOM-drap og minnemangel-hendelser, som indikerer minnepress.
- Tell krasj-, segfault-, panic- og korrupsjonssignaler, som indikerer stabilitets- eller integritetsproblemer.
- Tell autentiseringsfeil, som kan indikere brute force eller feilkonfigurasjon.
- Tell tjenestefeil og tidsavbrudd, den daglige årsaken til degraderte systemer.
Inndata
- Et utklipp av journal-utdata (journalctl -n 500 --no-pager), syslog-linjer eller applikasjonslogger.
- Én logglinje per linje; alle tidsstempelformater aksepteres siden matchingen er nøkkelordbasert.
Slik fungerer det
Hver innlimte linje testes mot fire regulæruttrykkgrupper i rekkefølge: OOM-nøkkelord (out of memory, oom, killed process), krasj-nøkkelord (segfault, panic, corrupt), autentiseringsnøkkelord (failed password, authentication failure, denied) og feilnøkkelord (failed, error, timeout).
Hvert treff øker telleren for gruppen sin. En enkelt linje kan telle i flere grupper, slik et menneske som leser loggen ville merket den.
Grupper uten treff utelates fra resultatet, så en rolig logg gir ett rent resultat.
Testbart eksempel
Prøv det — analysen kjører lokalt i nettleseren din.
Eksempel
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'
Forventet utdata
Høyt: Minnemangel / OOM-hendelse — 1 samsvarende linje. Advarsel: Autentiserings- eller tilgangsfeil — 1 samsvarende linje. Advarsel: Tjenestefeil eller tidsavbrudd — 1 samsvarende linje.
Les utdataene
- OOM-hendelser peker på minnepress: sjekk cgroup-grenser, swap og prosessen som ble drept.
- Autentiseringsfeil fortjener et blikk på hvem som prøver og hvor ofte; gjentatte forsøk med ugyldige brukere indikerer ofte skanning eller brute force.
- Tjenestefeil (Failed with result 'exit-code') undersøkes best med journalctl -u <enhet> -e for å se exitkoden og linjene rundt.
Risikoer
- Nøkkelordmatching gir falske positive og mister kontekst — en linje som sier "no errors found" inneholder ordet error og blir telt.
- Behandle tellingene som triage, ikke som bevis på en hendelse.
- Verktøyet leser aldri loggene dine fra disk; det ser bare det du limer inn, noe som er personvernsdesignet for hele siden.
Begrensninger
- Det tolker ikke tidsstempler, korrelerer ikke hendelser på tvers av verter eller oppdager sekvenser.
- Regex-gruppene er bevisst enkle; egendefinerte mønstre støttes ikke.
- Det er et triagehjelpemiddel, ikke en SIEM.
Offisielle referanser
FAQ
Hvorfor merkes en ren linje som en feil?
Fordi matchingen er nøkkelordbasert. En linje som "no error found" inneholder ordet error. Hvis det plager deg, begrens utklippet til linjene som betyr noe.
Hva bør jeg gjøre etter en OOM-hendelse?
Identifiser den drepte prosessen, sjekk minnegrensen og vertens minnepress, og avgjør deretter om du skal øke grensene, redusere samtidighet eller legge til minne.
Kan dette erstatte overvåkningen min?
Nei. Det er et manuelt triagehjelpemiddel for utklipp. Kontinuerlig overvåkning, varsling og korrelasjon krever en skikkelig loggingsstabel.