logbányászat manuálisan
Hátha itt valaki... :)
Adott egy k.nagy logfile (~3millió sor)
Szeretném kiválogatni belőle az ismétlődő sorokat, hogy ha ránézek a logra, azokkal ne kelljen foglalkoznom.
Elvi elképzelésem van, de a mennyiség miatt attól tartok, előbb török fel brute force-szal egy sha256-os hash-sel kódolt jelszót, mint amennyi idő alatt ebből eredmény lesz. :)
Elképzelés 1: cat journal.txt | sort | uniq -c | sort -n - az eredményből a 3-nál több ismétlődést tartalmazó sorok mehetnek a szűrőbe, ezek jó eséllyel rendszeresen előfordulnak. Aha... csak az a baj, hogy a sorok többségében van process id, eszköznév, valami random sorszám, epoch time stb.
Manuálisan kb. 700ezerre sikerült redukálni a sorok számát, a többi mind olyan, hogy valami lényegtelen változót tartalmaz.
Például (kiragadott példa, totál más eltérések vannak más típusú soroknál):
freshclam[998]: daily.cld updated (version: 24258, sigs: 1836466, f-level: 63, builder: neo)
freshclam[998]: daily.cld updated (version: 24259, sigs: 1836842, f-level: 63, builder: neo)
Itt pl. az a két verziószámféleség tér el, de előfordulhat a freshclam melletti pid változása is.
Innen jön az
Elképzelés 2:
Szavakra bontom a sorokat, eldobálom belőle a szeparátorokat és így hasonlítom össze őket... aham... persze... de milyen sorokat? Minden sort a többi három millióval? Hány hétig futna? :D
Hogy lehetne ezt kulturáltan megoldani?
Sortolni annyira nem tudom, mert mi legyen a kulcs, mikor fogalmam sincs, hol van a sorokban olyan változó, amit nyugodtan eldobhatok?
(most ez így hirtelen felindulásból íródott, könnyen lehet, hogy reggelre rájövök, mit hagytam figyelmen kívül. :) )
-----------------
Update: a fentiek előzménye, hogy a routerem logjait is őrizgetem, néha ellenőrzöm. Sokáig az egészet átnéztem, de túl sok volt benne a "zaj", erre született ez a megoldás:
unusual_log_entries.sh
Ehhez sikerült összegyűjteni a rendszeresen megjelenő sorokat, mivel viszonylag kevés volt belőlük: kern-patterns.txt
Valami ilyesmit szerettem volna "nagyban", hogy bármilyen loghoz tudjak generálni ilyen listát. De úgy fest, az adatmennyiség miatt ez elég esélytelen. Főleg, hogy pl. a tűzfal bejegyzések, az audit bejegyzések... hát nem könnyítik meg a dolgot. :)
■ Adott egy k.nagy logfile (~3millió sor)
Szeretném kiválogatni belőle az ismétlődő sorokat, hogy ha ránézek a logra, azokkal ne kelljen foglalkoznom.
Elvi elképzelésem van, de a mennyiség miatt attól tartok, előbb török fel brute force-szal egy sha256-os hash-sel kódolt jelszót, mint amennyi idő alatt ebből eredmény lesz. :)
Elképzelés 1: cat journal.txt | sort | uniq -c | sort -n - az eredményből a 3-nál több ismétlődést tartalmazó sorok mehetnek a szűrőbe, ezek jó eséllyel rendszeresen előfordulnak. Aha... csak az a baj, hogy a sorok többségében van process id, eszköznév, valami random sorszám, epoch time stb.
Manuálisan kb. 700ezerre sikerült redukálni a sorok számát, a többi mind olyan, hogy valami lényegtelen változót tartalmaz.
Például (kiragadott példa, totál más eltérések vannak más típusú soroknál):
freshclam[998]: daily.cld updated (version: 24258, sigs: 1836466, f-level: 63, builder: neo)
freshclam[998]: daily.cld updated (version: 24259, sigs: 1836842, f-level: 63, builder: neo)
Itt pl. az a két verziószámféleség tér el, de előfordulhat a freshclam melletti pid változása is.
Innen jön az
Elképzelés 2:
Szavakra bontom a sorokat, eldobálom belőle a szeparátorokat és így hasonlítom össze őket... aham... persze... de milyen sorokat? Minden sort a többi három millióval? Hány hétig futna? :D
Hogy lehetne ezt kulturáltan megoldani?
Sortolni annyira nem tudom, mert mi legyen a kulcs, mikor fogalmam sincs, hol van a sorokban olyan változó, amit nyugodtan eldobhatok?
(most ez így hirtelen felindulásból íródott, könnyen lehet, hogy reggelre rájövök, mit hagytam figyelmen kívül. :) )
-----------------
Update: a fentiek előzménye, hogy a routerem logjait is őrizgetem, néha ellenőrzöm. Sokáig az egészet átnéztem, de túl sok volt benne a "zaj", erre született ez a megoldás:
unusual_log_entries.sh
Ehhez sikerült összegyűjteni a rendszeresen megjelenő sorokat, mivel viszonylag kevés volt belőlük: kern-patterns.txt
Valami ilyesmit szerettem volna "nagyban", hogy bármilyen loghoz tudjak generálni ilyen listát. De úgy fest, az adatmennyiség miatt ez elég esélytelen. Főleg, hogy pl. a tűzfal bejegyzések, az audit bejegyzések... hát nem könnyítik meg a dolgot. :)
Ha túl sokféle minta van a
Valószínűleg nem lesz meg az eredmény, mire kitöltöd a söröd :) Esetleg lehet fix hosszúságú substringre számolni.
Igy hirtelen kétféle
A másik megközelítés, hogy indexeled az előforduló szavak szerint a sorokat, aztán felállítasz egy kritériumot, hogy hány százalék szó egyezésnél tekinted azonos mintájúnak a sorokat.
Esetleg a kettőt valahogy lehetne kombinálni, hogy karakterek helyett szavak szekvenciáiban keressen mintát az algoritmusod. Ez talán még működhet is ekkora adatmennyiséggel is, ha a fentihez hasonló az összes minta, és nem ilyen rövid random dolgokról van szó zéró angol szóval.
freshclam[998]: daily.cld updated (version: 24258, sigs: 1836466, f-level: 63, builder: neo)
=>
[freshclam,daily,cld,updated,version,sigs,f-level,builder,neo]
=>
[1,2,3,4,5,6,7,8,9]
Amennyire én tudom data miningnál mindig az első lépés, hogy előkészíted az adatot, és csak azután ereszted rá az algoritmusodat. Azért így is melós lesz, mire eltalálod a megfelelő beállításokat a pattern mining-hoz, de szerintem megoldható elég jó eredménnyel tűrhető sebességgel.
Kettőtök válaszából valahogy
Ha van valami poetteringes... pardon systemd-s linuxod, elég kilistázni a journalctl kimenetét és látni fogod, mennyi angol szó van bennük (sok esetben csak nulla, pár rövidítéssel :) )
Ja, ami kimaradt a nyitóból: mindez csak arra kellene, hogy generáljak egy fájlt, amiből a "grep -v -f ..." tud dolgozni. :) Magyarán miután megvannak nagyjából az egyező sorok, akkor megtalálni és megfelelő regex-re cserélni bennük a változó mezőket.
Szóval ahhoz már megvan a tehetségem, hogy kilátástalan feladatokat találjak magamnak. :D
Mondjuk a routerem logjához egész hamar összedobtam kézzel, pár sort | uniq | grep meg minimális perl varázslattal.
Ugyanezt akartam egy
Hehh... ez jó... tudnám,
Teljesen elfelejtettem amit itt javasoltál.
Pozitívum, hogy magamtól is valami olyasmire jutottam, hogy felállítok egy dictionary-t. Kulcs: az előforduló szavak, érték: a szavak előfordulásának darabszáma.
Utána végigolvasom újra a fájlt és soronként megnézem, hogy a sorban lévő egyes szavak előfordulása hány százaléka az összesnek, majd a sor szavainak százalékos értékeiből számolok egy átlagot. De ez így hülyeség, ahogy utólag végiggondoltam. Az így kiszámolt átlag nem mond semmit.
Na, még rááldozok egy napot, aztán hagyom a fenébe az egészet.
Szerintem nem akarj erre
Igazából az a gond ezekkel, hogy mondatokra lettek kitalálva, nem logokra, így ha csak egy csomó krix-krax a logod minimális szókészlettel, akkor nem fognak működni, és muszáj kombinálni őket valami mással, vagy a szimbólumokat a szavakkal egyenrangúnak kezelni. Ha viszont sok a szó benne, akkor csont nélkül lehet használni valamelyik implementáció shingling-nél vagy fingerprinting-nél githubról. Ami nekem tetszett az még az inverted index. Sok olyan szöveg feldolgozó algoritmus van egyébként, ami a szavak gyakoriságát vagy előfordulási helyét nézi, és az alapján indexeket készít, aztán ezeken az indexeken dolgozik utána, nem az eredeti szövegeken. Ahogy már előzőleg is írtam, a munka nagy része data mining-nál, hogy megtisztítsd az adatot, megfelelő struktúrált formába alakítsd, aztán csak utána az utolsó lépés, hogy a megfelelő algoritmust futtatod rajta. Ahogy nézem amúgy erre a problémára rengeteg féle megközelítés működhet kisebb-nagyobb sikerrel.
Úgy tűnik, tényleg szereted a mission impossible feladatokat :-D
A "hány hétig futna" nem feltétlenül probléma, ha pl. csak havonta egyszer kell.. :)
- Van egy csomó olyan adat egy egy sorban, ami mindegyikben meg van adva.
- Ezek között még jó sok logika is lenne, ami alapján szűrni kéne, ráadásul pontosan.
Emiatt (és mert eléggé "db-agyú" vagyok) én valószínű onnan közelítenék a megoldáshoz, hogy milyen egyszerű olvasóval tudom a sorokat feldolgozni, és egyúttal beszórni egy db-be...
Utána aztán úgy query-zem, ahogy akarom.
Nyilván ehhez kell egy db is, és a 3 (később több) milla rekord sem kevés, mégis azt gondolom, hogy ez a kis feldolgozó a pármillió INSERT-tel együtt max 1-2 óra alatt lefutna, és onnantól már lehet is játszani a jobbnál-jobb lekérdezésekkel.
Valójában elég lenne egyszer
De már alakul az elképzelésem, csak még a gyakorlatban is ki kell próbálnom - ezt megírni viszont eltart egy darabig.
Ez (is) tolt engem db felé
A "feldolgozó" nem foglalkozna (ötletem szerint) szűréssel, csak kiválogatná soronként a releváns adatokat külön oszlopokba.
NoSQL-t nem ismerek egyet sem,
Használj pgsql-t, hátha
Az nem RDBMS? ;) Persze
Persze lehet, hogy én tudom rosszul, és mégis alkalmas lehet ilyesmire, de akkor nagyon hiányosak az ismereteim.
Ezeket folyamatosan
Nem a pármillió sor a gond,
Ezen egy sql akkor sem segít, ha tudnám, hogyan kellene kivitelezni.
Pont azért kellene valami
Ekkora file analizálásánál
De szerintem a duplikátumok szűrésére a Levenshtein távolságot tényleg érdemes megnézni, az elég jó közelítést kéne adjon, amit már tovább lehet szűrni manuálisan. És nincs bonyolult algoritmusa sem. Már ha feltesszük, hogy jellemzően ismétlődő logüzenetek vannak változókkal, amiben hosszabb a fix rész, mint a változó. Mivel a logüzenetek emberi olvasásra vannak szánva, szerintem ez egy korrekt feltételezés.
Már ha feltesszük, hogy
Kérdés, hogy mit tekintünk ismétlődésnek. Az a baj ezekkel a logokkal és a stacktrace-el is, amit én próbáltam pattern mining-al parsolni régebben, hogy többféle minta is rájuk illik, sokszor akár 3-4 is attól függően, hogy mennyire általánosra vesszük a dolgot.
Kerítettem gyorsan egy példa logot:
03/22 08:51:02 INFO :..reg_process: return from registration rc=0
04
03/22 08:51:06 TRACE :...read_physical_netif: Home list entries returned = 7
03/22 08:51:06 INFO :...read_physical_netif: index #0, interface VLINK1 has address 129.1.1.1, ifidx 0
03/22 08:51:06 INFO :...read_physical_netif: index #1, interface TR1 has address 9.37.65.139, ifidx 1
Néhány rá illő minta a teljesség igénye nélkül:
*/* *:*:* * :..*: * *
03/22 08:51:* * :..*: * *
03/22 08:51:* * :*..re*: * *
4/5
03/22 08:51:* INFO :..*: * *
3/5
03/22 08:51:* * :...read_physical_netif: * *
2/5
03/22 08:51:* INFO :..reg_process: * *
Még ha ember is nézi, akkor is nehéz eldönteni, hogy mi számítson mintának és mi fix résznek, mekkora gyakoriság után tudunk valamit mintának nevezni, mennyire kell annak specifikusnak lenni. Szóval itt valami egyensúlyt kellene megtalálni az általános minta és a specifikus minta között, amire nekem eddig nem nagyon sikerült megoldást találni. A stack trace-nél annyi szerencsém volt, hogy tudom hány változót tartalmaz jó eséllyel a trace és ha generálok valami rögzített scenario alapján trace-t, pl eval-ból, akkor tudom azt is, hogy ezek a változók legalább részben mit fognak tartalmazni, ami elég info a megfelelő minta megtalálásához. Ha jól értettem itt nem csak duplikáció keresés a cél, hanem minta keresés és parsolás is.
No igen, ez meg a másik
Memóriában még bőven elfér az
Valójában fogalmam sincs, miért nem tudom elengedni a témát már hosszú ideje. Sokadszor futok neki, mindig ott akad el, hogy a matek tudásom kevés ahhoz, hogy a szükséges algoritmusok leírását megértsem, de ezt a tényt egy-két nap után elfelejtem és mindig újra kezdem. Szóval szerintem lépjünk tovább, hagyjuk ezt az egészet... :(
Jó, de mi a baj azzal, ha
Az, hogy ez a laptopom. És
Cloud bérlés most egyáltalán nem fér bele a lehetőségeimbe.
És milyen?
Annyi, hogy addig ne kapcsold ki / altasd, és minél többet legyen töltőn.
Itt lehet válogatni ha linuxot szeretnél. :)
Nálam kvm van, meg tudnám