Viszont szabad szovegtol elteroen, a JSON-bol legalabb ki tudom nyerni a mezo+ertek parokat, mindenfele elozetes tudas nelkul. Ezzel mar sokkal elorebb vagyok. Igy iterativan tudom az eszkozeimet boviteni, mig teljesen szabad szoveg eseten ezzel sokkal tobb melom lenne.
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.
Tovabbra sem akarom a feldolgozatlan logokat szemmel olvasni, fuggetlenul attol, milyen formatumban vannak. Abbol nem latom at az osszefuggeseket, se a trendeket, se semmi olyan informaciot, ami engem altalaban erdekel. Azert vannak ugyes programjaim, hogy a feldolgozasban, es a talalasban nekem segitsenek.
Kicsit állj lábujjhegyre, és kukucskálj ki a dobozod pereme fölött, amiben laksz :) Van egy csomó usecase, ahol az ember feldolgozatlan logsorokat akar, mert pl debuggol, nem pedig a logból készült csilivili statokat akarja nézegetni. És igen, tudom, hogy majd mindenre lesz csilivili tool, de
- egyrészt nem lesz mindenre
- 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.
Ráadásul erős a gyanúm, hogy egy csomó ilyen dolgot eleve nem a logból kéne összeszedni, amire te gondolsz, arra van a monitoring :)
És félre ne érts, ezzel nem azt mondom, hogy nem lenne jó valami faszán struktúrált data ilyenkor, de az, hogy a jsonnal lehet egyszerű adatstruktúrákat átvinni könnyen, az még lófasz. Pl nyilván minden log más mezőket szeretne a jsonodba. 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?