és általában már úgyis ott vagyunk a gépen, a franc se akar a központira mászkálni
Ha es amennyiben epp ott vagy. En eleve el sem megyek odaig, mert minden log megvan kozpontban, kenyelmesebb formaban, amennyiben azokra van szuksegem.
Na jó, de ha már váltunk, akkor miért pont a json, miért nem valami, amiben lehet definiálni, hogy mi fog menni, szabványosan? Mint pl snmp :) (remélem érezzük az iróniát).
Nekem aztan edes mindegy, csak ne syslog legyen. A JSON azert, mert sok esetben kenyelmes (ami az SNMP-rol nem mondhato el), es kb mindenre elerheto ami el es mozog. Felolem akar XML is lehetne, vagy BSON, vagy protocol buffers - nem erdekel, amig hatekonyan elvegzi a feladatat. A syslog protkoll nem teszi ezt.
Egyrészt: én úgy érzem, hogy transportnál a syslog struktúrálja az adatot, és a freetext mezőt kell valahogy feldolgozni, vagy valami jsont vagy hasonlót kell szétkapni annyira kicsi szelete az egész problémakörnek, hogy nagyon. Nem vagyok programozó, akár el is tudom hinni, hogy a syslogos rfck adatformátuma szar, és a json sokkal jobb (bár vannak kétségeim), de szerintem ez messze nem olyan kardinális kérdés.
Az RFC5424-ben tenyleg adott. Cserebe azt a formatumot relative kevesen hasznaljak. A tradicionalis syslogot parsolni pedig annyira nehez feladat, hogy a mai napig senki nem irt olyan syslogdt, ami out-of-the-box mukodne minden eszkozzel ami azt allitja magarol, hogy syslog-ot kop ki. Pedig megprobaltak ezt, tobben is.
Valoban nem kardinalis kerdes - en tobbek kozt ezert nem ertem, miert akadnak fenn emberek azon, hogy HTTP+JSON a transport. Rohadtul mindegy az egyszeri embernek.
És itt kanyarodnék vissza oda, hogy olvasson jsont szemmel akinek két annyja van.
Ezzel tovabbra is egyetertek. De mint mondottam volt, JSON transportra van. /var/log ala ugy rakod le a logot ahogy jol esik, nem kell jsont hasznalni. En sem tennem, pedig a transportom az JSON. Ugyanugy megtartom /var/log alatt a tradicionalis logokat, mint mas, mert barmikor leszakadhat a halo, vagy offline, izolaltan kell megnezni oket. Jo az, ha megvan. Nem mondtam, hogy nem az. Viszont borzaszto kenyelmes es hasznos, ha ennel tobb is az ember rendelkezesere all, es abban nagyon sokat segit, ha a logok ertelmesen vannak feldolgozva (netalantan ugy is vannak gyartva). Es a strukturalt logok atvitelehez a json egesz turhetoen megfelel.
A syslog azert nem, mert:
1) A tradicionalis syslog nincs korrektul definialva, raadasul nem tudod elore, hogy mennyi adat erkezik a kovetkezo uzenetben. Ez megneheziti nemileg a feldolgozast, bar ketsegtelen, hogy nem egy rettenetesen fontos tema.
2) Az RFC5424 mindenfele redundans informaciot tartalmaz (pl timestamp), amit praktikusabb lenne a JSON-be tenni. Nincsen benne semmi ACK mechanizmus (amit pl HTTP vagy valami MQTT, AMQP, satobbi eseten megkaphat az ember), cserebe van benne csomo olyan szutyok, ami az ember agyara megy (pl. a structured data megoldasa).
Es akkor meg csak a formatumrol beszeltunk, a transportrol magarol (HTTP vs syslog itt mar, nem JSON vs syslog) meg nem is.
--
|8]