ugrás a tartalomhoz

logbányászat manuálisan

mind1 valami név · Dec. 9. (V), 21.16
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. :)
 
1

Ha túl sokféle minta van a

BlaZe · Dec. 9. (V), 22.02
Ha túl sokféle minta van a fileban, akkor meg lehet próbálni a rendezett file-on egy Levenshtein távolságot számolni a szomszédokon, és valami threshold alatt egyezőnek tekinteni.

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.
2

Igy hirtelen kétféle

inf3rno · Dec. 9. (V), 22.56
Igy hirtelen kétféle megközelítés jutott eszembe. Az egyik a closed sequential pattern mining pl a BIDE+ algoritmussal. Ezzel szórakoztam pár hónapja (mondjuk csak PrefixSpan-al), és az a benyomásom, hogy a te esetedben évekig futna, ha egyesével néznénk a karaktereket.

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.
3

Kettőtök válaszából valahogy

mind1 valami név · Dec. 9. (V), 23.35
Kettőtök válaszából valahogy úgy érzem, ez bőven túl van azon a határon, amit még meg tudok valósítani. :)

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.
4

Ugyanezt akartam egy

inf3rno · Dec. 10. (H), 02.38
Ugyanezt akartam egy általános jellegű stacktrace parserrel, ami mintákat keres stacktrace-ekben, aztán csinál belőlük regex-et. Elméletileg lehetséges, gyakorlatilag baromi nehéz megvalósítani az ilyesmit, és 1 millió sor egyszerűen túl sok neki. Legalábbis a PrefixSpan-al biztosan az. A BIDE-t próbáltam megvalósítani js-ben, de ott feladtam én is. Nekem nem egyértemű, a leírásából, hogy hogyan kellene megvalósítani. Érdekes módon elkanyarodtam valami olyan irányba, ami hasonló elvekre épül, mint a BIDE, de tök más megközelítést használ a megvalósításnál. Lehet, hogy a végén sikerül összehoznom egy új algoritmust így, de egyelőre most jegelve van az a projekt. Később visszatérek rá. A te esetedben a legfejlettebb algoritmussal sem hiszem, hogy használható időn belül lefutna a dolog. És utána a minta szekvencia konvertálása regexre sem annyira triviális dolog, mint elsőre tűnik. Szóval ha nincs túl sok minta, akkor jobban jársz, ha inkább kézzel csinálod.
9

Hehh... ez jó... tudnám,

mind1 valami név · Dec. 13. (Cs), 18.28
Hehh... ez jó... tudnám, minek kérdezek. :D
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.
10

Szerintem nem akarj erre

inf3rno · Dec. 14. (P), 01.50
Szerintem nem akarj erre magad algoritmust fejleszteni. Egyszerűbb keresni valami működőt a témában: http://ethen8181.github.io/machine-learning/clustering_old/text_similarity/text_similarity.html, https://nlp.stanford.edu/IR-book/html/htmledition/near-duplicates-and-shingling-1.html, https://en.wikipedia.org/wiki/W-shingling, https://github.com/steven-s/text-shingles, https://en.wikipedia.org/wiki/Fingerprint_(computing), https://pdfs.semanticscholar.org/0325/d58461aef2a8b71ffc33e23226c37ae7d6f6.pdf, http://cs.brown.edu/courses/cs253/papers/duplicateshorttext.pdf, stb...

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.
5

Úgy tűnik, tényleg szereted a mission impossible feladatokat :-D

Pepita · Dec. 10. (H), 14.59
Azt nem írtad, hogy mindezt a mutatványt milyen gyakran akarod elvégezni, illetve mennyi erőforrást szánsz rá a vasból.
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.
6

Valójában elég lenne egyszer

mind1 valami név · Dec. 10. (H), 15.44
Valójában elég lenne egyszer futnia, hiszen csak egyszer kell legenerálni a szűrő feltételeket a normál esetben zajnak minősülő sorokra. Önmagában a 3M nem sok, de ha úgy vesszük, hogy 3M sort kell hasonlítani 3M-1 sorhoz, az... izé... kicsit sok(k) :)
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.
7

Ez (is) tolt engem db felé

Pepita · Dec. 10. (H), 16.18
3M sort kell hasonlítani 3M-1 sorhoz
Ezt lehet - szinte bármilyen - adatbázisban ügyesen optimalizálni.
A "feldolgozó" nem foglalkozna (ötletem szerint) szűréssel, csak kiválogatná soronként a releváns adatokat külön oszlopokba.
8

NoSQL-t nem ismerek egyet sem,

mind1 valami név · Dec. 10. (H), 18.48
NoSQL-t nem ismerek egyet sem, RDBMS meg erre nem jó. Illetve lehet, hogy Oracle-ben/DB2-ben van valami, ami segítene, de... megint ott tartok, hogy lemaradtam, illetve, hogy itt már kellene a főiskolai, egyetemi matek, ami tőlem már távol áll. Szóval ez a projekt is kuka. :(
11

Használj pgsql-t, hátha

inf3rno · Dec. 14. (P), 01.51
Használj pgsql-t, hátha elbírja.
12

Az nem RDBMS? ;) Persze

mind1 valami név · Dec. 14. (P), 07.36
Az nem RDBMS? ;)
Persze lehet, hogy én tudom rosszul, és mégis alkalmas lehet ilyesmire, de akkor nagyon hiányosak az ismereteim.
13

Ezeket folyamatosan

inf3rno · Dec. 14. (P), 11.18
Ezeket folyamatosan fejlesztik. Ahogy nézem SO-n, van egy pár ember, aki több millió sorral dolgozik vele.
14

Nem a pármillió sor a gond,

mind1 valami név · Dec. 14. (P), 13.48
Nem a pármillió sor a gond, hanem a pármillió hasonlítása pármillióhoz. Mondjuk azt nem tudom, miért hittem, hogy ez 3m**3m, de a 3m**2/2 is elég szép szám ;)
Ezen egy sql akkor sem segít, ha tudnám, hogyan kellene kivitelezni.
15

Pont azért kellene valami

inf3rno · Dec. 14. (P), 14.02
Pont azért kellene valami normális algoritmust használnod, ami nem stringeket hasonlítgat egymással. Az SQL azon segít, hogy hatékonyan meg tudd csinálni, és olyasmikkel ne kelljen törődni, hogy mennyi a rendelkezésre álló memória. Fájlokkal sokkal macerásabb ez az egész.
16

Ekkora file analizálásánál

BlaZe · Dec. 14. (P), 15.42
Ekkora file analizálásánál nem kéne még hatalmas memóriaigény legyen. Viszont ha valamiért úgy adódik, akkor ilyenekre inkább distributed IMDG-ket (In-Memory Data Grid, mint pl Hazelcast, Apache Ignite, Redis, Geode stb) szoktak használni, azok pont erre vannak kihegyezve. Több gépen memóriában, elasztikusan tárolják az adatokat, automatikusan párhuzamosítva, több gépen tudnak lefuttatni műveleteket az adathalmazon, így sokkal gyorsabb az ilyen feladatokban, mint egy RDBMS.

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.
17

Már ha feltesszük, hogy

inf3rno · Dec. 14. (P), 17.25
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ó.


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: attempt OS/390 registration
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:

5/5:
*/* *:*:* *   :..*: * *
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.
19

No igen, ez meg a másik

mind1 valami név · Dec. 14. (P), 17.36
No igen, ez meg a másik probléma, hogy mi a konstans és mi a változó. Pl. egy tűzfal log (iptables) több változónak látszó részt tartalmaz, mint konstanst, ugyanakkor a változó részekben is lehet olyan, amit inkább konstansként szeretném látni. (Pl. protocol-port párosítás, tcp/80 egy olyan sorban, ami a csomag eldobásáról szól, érdektelen egy szerveren, ahol nincs httpd. De a tcp/22 eldobása már izgalmas lehet)
18

Memóriában még bőven elfér az

mind1 valami név · Dec. 14. (P), 17.29
Memóriában még bőven elfér az egész. Csak amikor elkezdtem valami primitív módon feldolgozni és hasonlítgatni egyes sorokat, már akkor is nagyon sokat futott a program, ha csak kétszer nézte át a logot. Ha viszont eljutok oda, hogy az összes sort az összessel hasonlítsam, az exponenciális növekedést okozna -> napokig futna a legerősebb gépemen is.

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... :(
20

Jó, de mi a baj azzal, ha

inf3rno · Dec. 14. (P), 17.37
Jó, de mi a baj azzal, ha napokig fut? Kipróbálod egy kisebb részleten, ha elégedett vagy az algoritmussal, akkor ráereszted az egészre, aztán hagyod, hogy dolgozzon pár napig. Ha van alatta szünetmentes, akkor nem lehet vele igazán gond. Tulképp ha mented bizonyos időközönként a részeredményeket, akkor még áramszünetnél is tudod folytatni onnan, ahol abbahagytad. Esetleg ha virtuális gépen csinálod leszabályozott processzor használattal valami külön ehhez dedikált magon, akkor még használhatod is mellette a gépet. A másik lehetőség, hogy bérelsz processzor időt valamelyik computing cloud-on. Az is egy pár dollár csak.
21

Az, hogy ez a laptopom. És

mind1 valami név · Dec. 14. (P), 19.24
Az, hogy ez a laptopom. És 100% cpu használat napokon át nem tesz jót neki. A szerverem egy gyengécske celeron, azon hetekig tartana.
Cloud bérlés most egyáltalán nem fér bele a lehetőségeimbe.
22

És milyen?

Pepita · Dec. 15. (Szo), 08.23
Ha virtualizációt támogató proci van benne (mondjuk i7), és tudsz nélkülözni belőle 1 magot + 2 GB RAM-ot, akkor feldobsz egy Dockert, benne egy tetszőleges (kis) konténerrel és had matekoljon magának napokig. :)
Annyi, hogy addig ne kapcsold ki / altasd, és minél többet legyen töltőn.
Itt lehet válogatni ha linuxot szeretnél. :)
23

Nálam kvm van, meg tudnám

mind1 valami név · Dec. 15. (Szo), 08.52
Nálam kvm van, meg tudnám oldani, de ez napokig pörgetné a ventilátort, maximumon tartva a hőmérsékletét, én meg szeretnék vigyázni rá, ameddig csak lehet, mert vélhetőleg életem utolsó laptopja...