A viilág nagy része láthatóan egész jól elvan azzal, hogy ezt megoldja egy sed kétsorossal on the fly.
A vilag egy jelentos resze sok penzt ol olyan infrastrukturaba, ahol nem kell sed ketsorossal bohockodnia, mert ertkesebb az uzemeltetok ideje ennel. Nem keves penz van a naplozo uzletagban, nem veletlenul. Egy tobb tucat - neadjisten tobb szaz, vagy ezer - gepes rendszerben rohadtul nem akarsz se sedelgetni, se greppelni, se semmi hasonlot muvelni. Nagyon gyorsan karbantarthatatlanna valik.
Kicsit állj lábujjhegyre, és kukucskálj ki a dobozod pereme fölött, amiben laksz :)
Negy evet dolgoztam naplozas teren foallasban. Szerintem eleg jol kilatok.
Van egy csomó usecase, ahol az ember feldolgozatlan logsorokat akar, mert pl debuggol,
Egy kezemen meg tudom szamolni hany olyan eset volt BalaBitnel a Level3 supporton, amikor a feldolgozatlan logsorok barmit is segitettek. Ha ezt kiterjesztem barmilyen logsorra, akkor lehet, hogy mar ket kez kell, de ez meg mindig edeskeves. Reprodukcios lepesek, core file, stb messze hasznosabb eszkoz. (Peldaul azert, mert a programok jelentos resze borzalmasan szar logolast illetoen. Ha nem ismered tovirol hegyire a mukodeset, a logolas sem fog sokat segiteni.)
nem pedig a logból készült csilivili statokat akarja nézegetni
Nem kell csilivili statokra gondolni. A feldolgozas nem azt jelenti, hogy elveszted az egyes logokat, es csak par pie-chartod marad. Kozel sem! Ha mar szepen sikerult valami ertelmes formaba verni oket (ami sokkal konnyebb, ha eleve ertelmes-kozeli formaban vannak, neadj isten, a gyarto meg doksit is ad hozza), akkor csodalatosan lehet indexelni, es keresni benne. Mert sok esetben - amikor debugolok - nem csak egy program uzenetei es allapota erdekel, hanem tobbe egyutt. Debugolhatom en, hogy miert nem erheto el a weboldal, nezhetem a php app logjait, amiben minden rendben van, ha kozben a vilag masik vegen levo nameserver lehalt. (Nyilvan sarkitott pelda, es egy monitoring rendszer ezt eleve eszreveszi, de szemleltetesnek megfelel)
másrészt meg tessék észrevenni, hogy az adminnak sokkal egyszerűbb az összes ilyen triviális eseteket ugyanazzal a néhány toollal kezelnie, mint mindegyik apphoz specifikus csodafeldolgozót használnia.
Ezzel teljesen egyetertek. Gyonyoruen el tudom intezni az osszes feladatomat egy syslog-ng + elasticsearch + kibana / sajat ES query tool felallassal. Ettol meg az adataim strukturaltak lesznek (miutan syslog-ng-vel kicsit elofeldolgoztam oket, ha kell), syslog protokollt csak addig hasznalok, amig eler syslog-ng-ig, transportra, tarolasra pedig nem. Ha egy uj programot kell beillesztenem, akkor relative gyorsan hozza tudom igazitani a logjait az altalam elvart semahoz, es maris resze a rendszernek.
Alig nehany tul, egyik sem olyan rettentoen csilivili, amde nagysagrendekkel hatekonyabb, mintha syslogon kuldenek mindenfele katyvaszt.
Van már használható, széles körben konszenzuszos schema definicó jsonhoz, amivel ezt szabványos módon le lehetne írni, hogy lehessen általánosan működő csodaappot csinálni?
Nincs, ahogy sysloghoz sincs szabvanyos, altalanosan elfogadott es betartott sema. De nincs is ra szukseg. Ugyis mindenki a sajat igenyeihez fogja igazitani az adatokat, igy a legtobb amit az ember tehet, hogy olyan formaban prezentalja az adatokat eleve, amit viszonylag konnyen es egyszeruen lehet utana alakitani tovabb. A JSON erre egy nem rossz megoldas, a syslognal biztosan jobb.
--
|8]