Újdonságok a systemd-ben - 2015-ös kiadás

Linux

A systemd alapvető összetevője (lesz) a nagyobb Linux disztribúcióknak (is). A fenti videóban Lennart Poettering áttekintést ad a systemd jelenlegi és jövő évi újdonságairól.

( dap | 2015. 03. 11., sze – 18:53 )

Most kezdem nézni; tojásdobálás lesz?

Csak éppen ha a paraszt a kezébe kapja az előadás elején a nyomtatott prezit lefűzve, akkor nem azzal lesz lefoglalva egész előadás alatt h. odafigyelés helyett őrült gyorsíró módjára próbálja lekaparni a számára lényeges gondolatokat, hanem tud kényelmesen kommentelni adott dia alá azt a pár kulcsszót-kulcsmondatot, ami szükséges ahhoz h. vissza tudjon emlékezni a lényegre.

Persze mint mindent, lehet ezt is gagyi amatőr módon csinálni, meg profin is. Nem azt jelenti, h. ha van prezi akkor profi a előadás, ha meg nincs prezi akkor csak gagyi lehet, de prezi mindig kell, ha olyan dolgok hangzanak el amiket utána fel szeretne használni a nézőközönség a napi munkájában. Kivéve ha valami kötetlen beszélgetős estről van szó. Ez olyan volt?

--
WP8.x kritika: http://goo.gl/udShvC

Van olyan eloadas amihez teljesen feleslegesek a diak. Nem tudom, ez olyan-e, nem neztem meg. De jopar eloadast vegigultem, es megtobbet vegighallgattam, ahol nem volt dia, es semmi gond nem volt vele. Megtobb olyat ultem vegig, ahol volt ugyan dia, de zavarobb volt, mintha nem lett volna (hello egyetemi eloadasok 90%-a! :P).

Dia nelkul egyebkent sokkal nehezebb eloadast tartani, es tobb keszulest igenyel, ha az ember jol akarja csinalni.

(Hozzateszem, szerintem Lennart nem jo eloado, diakkal vagy anelkul.)

--
|8]

( answ | 2015. 03. 11., sze – 23:55 )

Meddig kell még Linux a systemd-hez? :)

( Celtic v | 2015. 03. 12., cs – 07:31 )

Ki allhat a systemd mogott? Mit akarnak elrejteni a systemd botrannyal?
Ezert tart itt a Linux :(

--
http://www.micros~1
Rekurzió: lásd rekurzió.

( Hiena v | 2015. 03. 12., cs – 09:44 )

Kérek vissza egy órát az életemből.

Pár megjegyzés:
Nagyjából folytatódik a bloatosodás és mindent integráljunk egybe szemlélet. Remekül mutatja a rendszer tervezettségét, hogy a nspawn, ami egy tesztelésre létrehozott konténer volt, immáron egy docker-el versenyző konténer rendszerré fúvódott fel és jövőben mindent integráljunk konténerbe fejlesztés várható.
Immáron van tűzfal is a systemd-ben, és itt van a networkd is. Igen és csináltak hozzá saját dhcpd libraryt is.
Igen, már az ntp-re sincs szühségünk! Itt van helyette a timesyncd, ami egy integrált ntp kliens.
machined: "ohhh, volt valami zone koncepció a Solarisban. Csináljuk meg a retardált változatát!"
consoled: immáron nagyfelbontású képernyőket is kezel!
auditálás: az journald loggolja az összes /etc/passwd felé menő rendszerhívást. Gondolom a NSA felé menő sajátjai kivételével... Ha már journald, akkor annak itt van a journald remote verziója. Mert egy operációs rendszer nem létezhet távolról lekérdezhető loggolásról és erre a http a legalkalmasabb.
resolvd: mert a névfeloldásra is rá kellett tenni a mancsukat. (Ezt olyan faszán megcsinálták, hogy sérülékenység van benne DNS cache poisoningra.)

És a kedvencem: integrálni akarják a gummiboot UEFI bootloadert.

Volt még sok egyéb is, de csak azt erősítette meg, hogy 1-2 éven belül migrálni kell valamilyen más operációs rendszerre, mert így, systemd-vel hosszútávon halott lesz a Linux. Egy ilyen nagyságú, integráltságú és ily mértékű függőségeket tartalmazó rendszer egy kártyavár lesz hosszútávon.

Pár megjegyzés az előadásra és annak színvonalára:
Lennart hozzáállása igen jól mutatja az egóját és nagyfokú tiszteletlenség a hallgatóság felé. Egy órás, slideok nélküli előadás esetében esély sincs arra, hogy nemlineárisan vissza lehessen nézni azt, ergo rákényszeríti a hallgatóságot, hogy az órát töltsék vele. Az előadásmódjának a másik előnye, hogy nem lehet számon kérni.

Bónusz kérdés: Jól láttam, hogy Lennart lábai előtt Kay Sievers ücsörgött? A figurának a testtartása egy az egyben olyan, hogy már csak egy a nyakától Lennart kezébe menő póráz hiányzott a képből.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Valljuk be Linust nem nagyon erdekli mit csinalnak a Linux kernellel. O/OK csak a kernellel foglalkoznak. Neha van velemenye, de ennyi.
Szoval lesz olyan Linux disztribucio, ami ezt a szornyet ki fogja kerulni. Aki meg a systemd bloatware-t akarja az azt is megkaphatja. Ha szerencsenk van, akkor ez a dilettans bagazs ir maganak sajat oprendszert es bekenhagyja a disztribuciokat. :D

Felreertes ne essek. Nem az a baj, hogy legyen normalis szerviz kezeles, normalis feledatutemezo (mert valljuk be a cron nagyon bena, dependenciak, statuszok es minden nelkul), stb. De ezeket nem kell egy eszkozbe belerakni. Illetve lehet, csak en nem szeretnem. :D

Meg nem is szimpi a srac...na :D

> Szoval lesz olyan Linux disztribucio, ami ezt a szornyet ki fogja kerulni.

En csak azt latom, hogy mindegyik nagy ezt hasznalja *mar*:
- fedora, rhel 7+, centos
- ubuntu, debian
- arch, gentoo

Egy nagyobb distribuciot se tudok, amelyik direkt kikerulte volna a systemd-t.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Meg nem. De ez nem tarthato igy. Szerintem hasznaljak most egyes elemeit, de pl. ugyanugy ott van a syslog es nem a journal-t hasznalja egy csomo disztro. Es igy tovabb. De majd az ido eldonti. Ahogy jott, ugy mehet is a levesbe, ha kicsit mar tul sok lesz. :D
Vagy nem, de ez engem nem erdekel. Akkor csinalok sajat disztribet. :D
Vagy BSD-s leszek. :D
Vagy win34-es. :D

A systemd-t szolgaltatasok inditasara meg hasznalnam (modjaval), a cron/at-ra mar nem, a logolasra plane nem. De tenyleg arrol van szo, hogy ha nem tetszik akkor valaszthatom mast es kesz. Az uzemeltetest mondjuk remaloma teszi, de akkor majd atmegyek pm-nek vagy architectnek, vagy PHP programozo leszek. :D

Ennyi.

A gond ezzel az, hogy teljesen kezelhető use case, amit írtál. :)

A "logolásra plána nem" talán az egyetlen, amivel gondban lehetsz, mert azt nem lehet kikapcsolni, de simán tud syslog-ba továbbítani.

Lennart-ék szvsz. masszívan elcseszték, hogy az összes extra projektet behozták a systemd "brand" alá, systemd-extras vagy valami hasonlóval kellett volna elnevezniük (a timed-t, a networkd-t, a logind-t és az összes többi ernyő-projektet).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Gentoo-n nem default, es nem is lesz egy jodarabig. Benne van a csomaglistaban, de te dontod el akarod-e vagy sem.

Csak nehany distro ahol kikerulheto a systemd hasznalata.

Crux, Void Linux, Funtoo, LFS, Gentoo, Slackware, regebbi Debianok.

Gentoo-n az udev is elkerulheto ha valaki erre is rigolyas.

Mert egy operációs rendszer nem létezhet távolról lekérdezhető loggolásról és erre a http a legalkalmasabb.
Mert a syslog régi és nem szabványos, és ezt mindenhol leváltó új remote logging protokoll megtervezésére Lennart Poettering a legalkalmasabb.
(* http://tools.ietf.org/html/rfc5424)

Amúgy észrevettétek, hogy ezzel így surranópályán teljesült a "httpd is lesz a systemd-ben" baljóslat?!
---
Régóta vágyok én, az androidok mezonkincsére már!

Ha ugy gondolod, hogy a syslog szabvanyos, es kezelheto, akkor felelmetesen naiv vagy. A syslog-nal *barmi* jobb. (Mellesleg rfc5424 kb sehol sem default, de ha meg az is lenne, sokra nem mesz vele, mert a syslog()-ot hasznalo programok nem azok, amik nem hasznalnak syslogot, azok meg plane.)

Egy microhttpd mar kb a journal eleje ota ott csucsul a forrasban, az a journald-remote alapja, kb.

--
|8]

Pedig de. A "regi" syslog egy elbaszott, nem szabvanyos es hasznalhatatlan valami. Az RFC5424 egy fokkal jobb, de azt meg kb semmi sem tamogatja ertelmesen, de ha tamogatna is, akkor is borzalmas hasznalni. Egy TCP-n atkuldott JSON kb minden tekintetben tobbet ad neked, mint az RFC5424.

--
|8]

Yep, es N szoftver ezt N kulonfele modon formazza be a logolando parametereket. Megha mind syslogon is menne, abban van timestamp, host, facility/prio (ami edeskeves), es utana szabad szoveges resz. A log erdemi resze ebben a reszben van, ami rettento mod kulonbozo tud lenni.

Igy bar lehet, hogy egy programon belul konzisztens es feldolgozhato a log, programok kozott mar sokkal problemasabb a helyzet. Nincs egyseges forma => formazatlan.

Ami syslogon atmegy, abbol az esetek 99%-ban ki kell meg banyaszni - app-specifikus modon -, hogy mi is tortent. Ezt ertem formazatlansag alatt.

--
|8]

És hogyan formáznád egyformára egy webszerver "az oldal nem található", egy robotrepülőgép "nyomásszenzor tápfeszültség kritikusan zajos" és mondjuk egy storage "Seek Time Performance hiba" üzenetét?
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

De ez nem a syslog problemaja. A syslog - mint logging megoldas es mint protokoll - nagyon szepen megoldja azt a feladatot, amit neki meg kell oldania. Amirol itt valojaban beszelunk azonban az, hogy senki nem jott meg elo egy olyan strukturalt logging protokollal, ami olyan szeleskoru tamogatottsagot kapott volna, mint a syslog. Talan azert, mert a strukturalasra sem fejlesztoi sem logfogyasztoi oldalon nincs valodi, szeleskoru igeny. Ha lenne, akkor szulettek volna jobb megoldasok az informatika 30-40 eve alatt.

Nezd meg a Windowsos vonalat. Ott van az Eventlog, 2008 ota szep, strukturalt logolasi forma, a kutya nem hasznalja. Az appok tobbsege meg mindig a Windows Application logot szorja tele a fassagaival. Meg az internal MS appok tobbsege is. Pontosan miert is kellene strukturalni a logot, ha senkinek sincs igenye erre?
--
Blog | @hron84
Üzemeltető macik

A syslog problemaja az, hogy bar at tudja vinni a strukturalt adatot (semmi nem gatol meg abban, hogy pl JSON-t rakjal a szoveg reszbe, a'la CEE), nem hatekony. Nem fejtem most itt ki, hogy miert, mert van jobb dolgom is.

Hogy van-e igeny vagy sem: Greylog, LogStash, Kibana, es tarsaik. Mind-mind arra epitenek, hogy a strukturalatlan, ilyen-olyan, kesze-kusza logjaidbol valami ertelmeset, jobban strukturaltat es prezentalhatot epitsenek. A BalaBit egyes termekei is ezt celozzak meg. Egyiknek sem megy olyan rosszul, es igeny az bizony van ra. A gond az, es ezert halt el jopar probalkozas is, hogy nem lehet olyan semat talalni, ami mindenkinek jo. Megprobalt ezt a CEE is - beletort a bicskajuk. Megprobalta a Lumberjack is, az is elhalt. Megprobalta a maga modjan a Greylog es a LogStash + Kibana paros is, de ok is csak arra jutottak, hogy ha van valami strukturalt formad, akkor azzal mar lehet kezdeni valamit - altalanos nincs, es nem is lesz. Eddig viszont legalabb mar eljutottunk.

Igeny van ra, legalabbis fogyasztoi oldalon. Csak egyreszt ott van egy hatalmas adag legacy, amivel valamit kezdeni kell, igy nem lehet megszabadulni a regi logokat feldolgozo eszkozoktol. Ha pedig azok mar ott vannak eleve, akkor miert is szivassuk a fejlesztoket azzal, hogy ertelmesebb logokat kopessunk ki a programjaikbol? Megoldja majd a machine learning! A feldolgozasban ugyis tobb penz van. Masreszt ott van az, hogy a fejlesztonek nem erdeke a felhasznalo altal hasznalhato logok eloallitasa. Vajmi keves haszna van belole, akkor pedig minek?

EventLogrol nem tudok sokat, keveset dolgoztam vele - szerencsere. Nekem az remlik belole, hogy csoppet korulmenyes volt hasznalni, es mellesleg durvan lassu volt. Ez nem segiti elo a hasznalatat.

--
|8]

Amirol Te beszeltel itt az elobb, az sokkal inkabb egy event korrelacio, mint maga a loggolas.
Es termeszetesen egy korrelaciot segit a strukturalt adat, de igazabol lenyegtelen, ha megfelelo az eventcorrelator (mondjuk eregexp alapon IS kepes korrelalni).

A syslog feladata, hogy naplozasi feluletet nyujtson annak akinek kell. Raadasul ezt kivaloan elvegzi. A kesobbi keiegeszitesek, amikkel figyelheto mar a kuldo program, stb, stb. meg jobban kezelhetove teszik. A tobbi nem a syslog feladata. az event korrelacio nem a syslog feladata, a riasztas nem a syslog feladata, a riasztasra reagalni sem a syslog feladata, a riportok elkeszitese sem a syslog feladata.
Az hogy ki hogyan ir bele (milyen formatumban, milyen sorrendben a szabad szoveges mezokben) kb. mindegy. Nem dolga az ertelmezes.

A systemd-sek pont ugy gondoljak, hogy a systemd dolga minden.

De ez filozofiai kerdes. En jobban szeretem az epitokoveket egymasra epitve, mint egy dunsztosuveget tele uveggolyokkal, amibol nem tudsz kivenni semmit anelkul, hogy az uveget es vele a tobbi golyot is szet ne tord. Mig a lego szeru kockakat szetszeded es ujbol osszerakod, csereled, stb.

A korellacio sokkal hatekonyabban mukodik, ha ertelmes adatokkal tud dolgozni. Ez valoban nem a syslogd feladata, de a syslog, mint transport formatum, nem kedvez a feldolgozasnak. Ennyi.

Nem mindegy, hogy milyenek az epitokoveid: passzentos lego kockak, vagy a parton gyurt iszapkupac. Mindkettobol, mindkettore lehet varat epiteni.

--
|8]

Felreerted. Elvben nem azert kellene logolni, hogy a logolas utjan esemenyeket lojunk fel. A "valaki probalkozik az SSH porton" nem (csak) a logba kellene kerulnie, hanem a logtol egy teljesen fuggetlen eventnek kellene elsulnie erre, amire specifikusan lehet raugrani. A log arra valo, hogy a mult esemenyei rogzitesre keruljenek, nem pedig esemenytovabbito felulet.

A gond az, hogy a legtobb fejleszto azt gondolja, hogy ha tortenik egy problema, es lelogolja, azzal generalt egy esemenyt is, es reszerol a munkanak itt vege. Hogy azt a logot fel kell parzolni ahhoz, hogy valodi esemeny lehessen belole, az ot hidegen hagyja.

Kicsit olyan ez, mintha a grafikus feluleten torteno gombnyomasrol nem esemeny lovodne fel, hanem csak bekerulne valami logba, aztan akit erdekel, az majd olvasgatja a logot es lereagalja a gombnyomast. Vagy nem.

Jelenleg a logolast rosszul hasznaljak, es a greylog meg a logstash probalnak valami ertelmeset kihozni a jelenlegi okoszisztemabol, de ez nem jelenti azt, hogy a logolasnak feltetlen strukturaltnak kellene lennie. Azt jelenti, hogy nem mindent logolassal kellene elintezni.
--
Blog | @hron84
Üzemeltető macik

A Nagy Mestert ugysem gyozne meg semmi, mit e gyarlo halando igaznak gondol, mert O tudja a Sajat Egy Es Serthetetlen Igazat. A Te idodet kivantam megkimelni azzal, hogy ily trivialitasokat, melyek a Te Bolcsesseged apro morzsaihoz sem merhetoek, nem irom le, se nem rombolom embertarsaim elmejet tovabb, mert megerintett, es megvilagositott, mit nekem mondtal.

--
|8]

Az xmlre is pont ezt szokták mondani, aztán meg tudjuk...

Egyébként (ezt a feljebbire is) az a baj, hogy azzal, hogy azt mondod, hogy legyen json, még nem mondtál semmit, pont ugyanott vagy vele, ahol a part szakad, van egy random struktúrájú jsonod egy random formátumú free text mező helyett. A különbség, hogy amit eddig grep|cut|awk|sed segítségével pecázott ki mindenki app sepecifikusan, azt aztán majd a jqval próbálhatod app specifikusan kibányászni. Sokkal előrrébb nem leszünk tőle (sőt, a grep|cut|awk|sed kb mindenhol ott van, meg tudják is az emberek használni, a jsont meg a webhuszár programozókon kívül kb mindenki leszarja. Ja, és logsort még mindig könnyebb szemre olvasni.

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.

Mint emlitettem valahol fentebb, a JSON nem az Egy Igaz Megoldas. Az egy formatum, amiben a strukturalt adatot atviszed. Ennyi, es nem tobb. Strukturalt adatatvitelre hatekonyabb, mint az RFC5424. Es mivel adatatviteli formarol beszelunk, netto nem erdekel, hogy ki ert hozza es ki nem, mert a "vegfelhasznalo" nem kozvetlenul ezzel fog dolgozni, idealis esetben.

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.

--
|8]

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?

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]

Ez már eléggé elment az eredeti mondandómtól, de az nem baj :) Először kicsit részleteiben:

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.

Tudom, láttam már ilyet is.

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

Minden tiszteletem mellett, én meg számos olyan usecaset látok, ahol meg igenis bőven elégséges a log (és általában már úgyis ott vagyunk a gépen, a franc se akar a központira mászkálni) Elismerem, ezek nem feltétlen level 3 problémák. (Bár dolgoztam én olyannal, ami ugyan rettentő fos xml hányadék logokat gyártott, ellenben oda tudtam állni a friss level 2 kolléga mellé, aztán megmutatni benne, hogy hol a baj).

Illetve, ha nem ismered valaminek a működését, akkor az ügyesen parseolt log sem fog sokat segíteni.

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)

Értem én, de speciel igen, ez egy sarkított példa, amire a log elég szar eszköz eleve.

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.

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

--

All in all: szerintem még mindig benne vagy egy kicsit a dobozodban.
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.

Másrészt: te benne laksz a nagy, egy helyről üzemeltetett infrastruktúrák dobozában. És ez a világnak csak egy szelete. Tök jó, ha az embernek van értelmesen összerakott log infrastruktúrája, aminek a végén egy központi tool amiből össze lehet szedni a dolgokat. De a világ nem csak ilyen, van ahol ez nincsen meg (pl mert te külső support vagy, aki nem fér hozzá). És annak viszont igenis van értéke, hogy random software loggolása nem csak akkor jó, ha ez megvan, hanem lehet használni a /var/log alatti turkálással is, uniformice. És itt kanyarodnék vissza oda, hogy olvasson jsont szemmel akinek két annyja van.

é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]

Kicsit rövidítek, mert szerintem kb egyetértünk...

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.

Na jó, csak most vagy az van, hogy
- már az appban is jsonban keletkezik a log, akkor nyilván mi fog a /var/log alá kerülni? Hát persze, hogy json. Mint ahogy javas izéknél a exeception kimenete, corbánál a rusnya xmlek, stb. És akkor majd jól olvashatjuk azt szemmel.
- Ha meg "tradicionális fromában" keletkeznek akkor ugyanúgy jsont kell belőle csinálni. Akkor a parzolgatást nem úszod meg, de felhasználó szempontból valóban mindegy, hogy ezt hol csinálod meg, még a nodeon, mert transportra már jobb a json, vagy majd a központban.

Azert egy aprobb kulonbseg van: json-t syslog-ra alakitani nemileg egyszerubb, mint viszont. Mondjuk en olyan ember vagyok, hogy http logot sem szivesen olvasok szemmel, java exceptiont meg plane, az N uzenetbe tordelt postfix logot pedig igyekszem elkerulni. Szoval JSON nelkul is pont eleg szar a helyzet, ha az embernek szemmel kell olvasnia a kulonbozo szutykokat.

Magyarul kis rendszeren is siman osszekorellalom a dolgokat ahogy azt nagyobb rendszeren is teszem, mert ujjban van a rutin, es az ember az ismert eszkozoket hasznalja. Foleg ha azok hatekonyak. :)

--
|8]

Azert egy aprobb kulonbseg van: json-t syslog-ra alakitani nemileg egyszerubb, mint viszont.

Valóban egyszerűbb, és neked legyen igazad, de szerintem ha a jsonon jönne be, akkor egy csomó minden nem alakítaná, néznénk jsont. Illetve a freetext helyén levő struktúrált datát schema hiányában ugye nem is annyira triviális.

Mondjuk en olyan ember vagyok, hogy http logot sem szivesen olvasok szemmel, java exceptiont meg plane, az N uzenetbe tordelt postfix logot pedig igyekszem elkerulni. Szoval JSON nelkul is pont eleg szar a helyzet, ha az embernek szemmel kell olvasnia a kulonbozo szutykokat.

Senki sem szeret, és valóban elég szar a helyzet, és te ide még kileakelnéd a jsont is :) Egyébként a többsoros postfix pont viszonylag triviálisan szűrhető a benne levő id alapján.

Magyarul kis rendszeren is siman osszekorellalom a dolgokat ahogy azt nagyobb rendszeren is teszem, mert ujjban van a rutin, es az ember az ismert eszkozoket hasznalja. Foleg ha azok hatekonyak. :)

Ez nagyszerű, de erre még mindig nem mindenkinek van meg a lehetősége.

Szép és jó ez az elméleti vita a strukturált és strukturálatlan log formátumokról, de mi lenne, ha visszatérnénk konkrétan a _journald-féle_ megoldásra...
Értem én a syslog nyűgjeit, de azért valljuk be, Lennart kreált helyette jópár másikat. Kezdeném mondjuk a 3-féle különböző timestamp, valamint a _CURSOR, _SYSTEMD_SESSION és hasonló, széleskörű alkalmazhatóságot elősegítő mezőkkel...
---
Régóta vágyok én, az androidok mezonkincsére már!

Halkan megjegyeznem, hogy Algernon a BalaBit-nel a syslog-ng egyik fejlesztoje, szerintem egesz jo ralatasa van a teruletre, nem mellesleg nala valodi ugyfeligenyek jelentkeznek. En is dolgoztam a BB-nel, valamint volt szerencsem sok tizezer eszkozt kiszolgalo log infrastrukturat osszerakni, irdatlan mennyisegu felteteles feldolgozassal olyan mennyisegu bejovo loggal, amibe egy mezei regexp engine belerokkanna. Biztos, hogy mi lakunk dobozban, vagy pedig neked nagy kisse az arcod? A kerdesedre valaszolva: nezz ra pl. a syslog-ng value-pair kezelesere. A bejovo log strukturaja (ill. inkabb strukturalatlansaga) eleve adott, ehhez hozza lehet/kell igazitani a parsereket (pl. patterndb, akar programonkent eltero szabalyokkal), es onnantol mar kulcs-ertek parjaink vannak, amit tovabbithatunk pl. jsonnal, igy a struktura megmarad, nem kell ujra a nullarol kezdeni a feldolgozast. Sokan csak erre az atalakitasra hasznaljak a syslog-ng-t, ugyanis piszok gyorsan teszi a dolgat.

Ez most azt jelenti, hogy o tevedhetetlen? O egy velemenyt kepvisel. Masok meg mast. Ennyi.
Tisztelem ot, de en pl massal foglalkozom igy masok fontosak. Mashogy kozelitjuk meg a kerdest.

Es pont ez itt a lenyeg. Ne felejtsuk el mirol szol ez az egesz szal.

"A systemd feljlesztoi ugy erzik, csak is az o megoldasuk az egy es udvozito!!!"

Na ez az amiert itt ennyit pofazunk :D

Ok igy oldjak meg a problemajukat, de te megoldhatod mashogy, ha akarod. Ennyi. Eddig is lehetett rsyslog-ot vagy syslog-ng-t hasznalni a systemd mellett, ahogy ez mar szerepelt a hozzaszolasok kozott. Az itteni nagy felzudulas mar-mar indexes magassagokba (vagy melysegekbe) jutott, maradjunk inkabb a tenyeknel, ne pedig szubjektiv es/vagy megalapozatlan velemenyeken porogjunk.

FYI, systemd-ben van jelenleg egy HTTP+JSON alapu transport, de levlistan mar ott van az RFC5424 syslog transport is, ami bar meg nem kerult be, nem latom, hogy miert ne kerulhetne (de ki fog derulni, mi lesz a sorsa). Illetve ott van meg az rsync is, bar az nem real-time.

Tovabba tovabbra is tamogatott a tradicionalis syslog-nak forwardolas, illetve mind rsyslog, mind syslog-ng tud journalbol olvasni kozvetlenul, es innentol ugy tovabbitod a logokat, es oda, ahogy jol esik.

Nem *annyira* fafeju okrok azok, mint ahogy nehanyan azt gondoljak.

--
|8], a Tevedhetetlen

Véletlen tudom ki ő. (Sőt, véletlen használunk BB cuccokat, több félét is, és bár nem a logosok, de hugyoztak szegények vért páran a valódi ügyfél igényeimen ;) (és eléggé faszán megoldották.)

Ettől még igen, dobozban laktok, a nagyméretű enterspájz cuccok dobozában (ahol egyébként többnyire én is, ettől még látom, hogy a dobjuk ki a syslogot, és legyen helyette json fáj kicsit helyenként.)

Az, hogy te az előparzolás után min tolod keresztül, azért különbözik attól, hogy hogyan keletkezzen a loggolandó nodeon.

A transport formatum helyett legyen JSON. Nem tennek le fileba JSON-t en sem, mert mint tobbszor egyetertettem, olvassa azt akinek ket anyja van. Arra valo a gyujto alkalmazas, hogy megfelelo helyen, es formaban tarolja a logokat. Ha konnyebben feldolgozhato formaban erkezik be, hatekonyabban tudja vegezni a munkajat. Tarold le lokalisan tradicionalis syslog-szeru formatumban, ha az tetszik - megteheted. Eddig is a syslogd vegezte ezt, ezutan is az fogja. Ezutan is vegzett nemi elomunkat, ezutan is fog.

Effektive semmi erdemleges nem valtozik azzal, hogy jsont - vagy barmi mast - hasznal az ember atviteli formanak.

--
|8]

Probaljuk ujra, epp raerek. A bejovo syslog uzenet (altalaban mezei ASCII karakterkeszletu szoveg, hopp, ez mar magaban szivas) hogy erkezhet? Legyen mondjuk /dev/log, AF_UNIX (ismertebb neven unix domain socket). Ha ez pechunkre SOCK_STREAM, akkor rab*szas esete forog fenn, mert gozunk sincs, hol van az uzenet vege (LF, NUL, ?), pufferelni es talalgatni kell. Ugyanez tortenik AF_INET[6]+SOCK_STREAM kapcsan (kozismertebb neven TCP). Hogy is nez ki az uzenet? Van fejlec. Ebben mi van? Egy prioritas es egy idopont (milyen formatumban is? Idozona? Evszam?). Kuldo gep neve? Programnev (amit amugy barki barmire allithat)? Opcionalisak. Annak idejen nem kellettek. A kulonfele implementaciok hegesztettek hozza ezeket az adatokat. Mekkora az uzenet maximalis merete? Tradicionalisan 1k, de altalaban 64k-ig emelheto, mert ennyi meg belefer egy UDP csomagba. Az 1k-s okolszabaly ellenere volt olyan syslog implementacio, amelyik alapbol 2k-ra novelte a rovidebb uzeneteket. Mi a bejovo uzenet facility-je? Ha 0-t lat, a libc beallitja 1-re (USER). Hopp, a kernel epp a 0-t hasznalja. Nosza, kezeljuk specialisan a kernel logokat (ez akkor macera, ha szeretnel logokat ujra bekuldeni feldolgozasra, direktben ra kell connect-elni a /dev/log-ra). Folytassam? Ugye felesleges lenne?

Nincs olyan, hogy a syslog transzport onmagaban strukturat ad, a strukturalas elotte tortenik meg a parser oldalan - en legalabbis nem lattam meg pl. a libc-ben nativ syslog proto tamogatast. Ha a bejovo adat tovabbra is freetext, akkor mindegy, hogy a /var/log ala irja ezeket a syslog daemon, vagy a halozaton kuldene at, ugyanaz a katyvasz az eredmeny itt is, ott is - marad az elofeldolgozas, amit altalaban jobb a kuldo oldalon megtenni, mint kozpontilag. Amugy keresd meg mondjuk par tucat GB-nyi logban az osszetartozo sorokat, sok sikert hozza...

Komolyabb biztonsagu helyeken meg az uzemeltetes is ki van zarva a gepekrol, csak ideiglenes hozzaferest engedelyeznek az adatgazdak, azt is felugyelet mellett. Alltam en mar kollegak hata mogott, es diktaltam nekik a parancsokat, mert a vezetes szerint igy volt celszeru szetvalasztani az eltero (operations vs engineering) feladatkorokkel jaro jogosultsagokat.

Egyebkent mondta valaki is, hogy nem maradnak hozzaferhetoek a lokalisan generalt logok? Miert lennenek ezek barmilyen mas formatumra konvertalva? Ez csak eroforrast emesztene fel, feleslegesen. Tudtommal csak arrol volt szo, hogy a remote transport lesz HTTP-alapu. Ebbe belefer az erkezo logok ack-ja (ami komoly hianyossaga az RFC szintjen letezo syslog protoknak), tomorites, ... Miert is kene valami ujat, nativ protokollt feltalalnia a systemd fejlesztoinek, amit a kutya se tamogat meg, es jo esellyel nem is fog? Nem kellene oket hulyenek nezni meg akkor sem, ha sokak szerint nem a KISS elv menten dolgoznak. Aki jobban ismeri, mirol is szol a systemd, annak altalaban joval arnyaltabb a velemenye.

Kihagytam valamit?

Folytassam? Ugye felesleges lenne?

Ezeknek a jelentős részét a json önmagban pont nem oldja meg (opcionális, hülyeségre állítható mezők, timestamp (amire egyébként van rfc, még ha olyan is), stb. A többi meg parseolás, értem én, hogy azt kényelmesebb rábízni a már kész HTTPre, mert ott van length mező, hurrá.

De egyébként én még mindig csak az ellen emeltem fel a szavam, hogy a json mindenben jobb, mert olvasni pont szarabb. És ha végigverődik az egész infrastruktúrán (az apptól kezdve), akkor előbb utóbb jsont leszek kénytelen olvasni, mert valaki valahol nem fogja lekezelni. Ha meg a sylog eddigi mezői maradnak kb, és e helyett lesz json, a freetext meg marad, ahogy eddig, azzal a parseolgatás ott tart, mint most.

De igen, önmagában mint transport proto, tőlem. (És hiába látod bele, hogy azt mondtam, hogy fújj systemd, szar az egész, ezt nem mondtam.)

Ok írhattam volna rfc3164-et is, a jelenleg futó implementációkat az jobban fedi.
Én pontosan tudom, hogy a syslog nem egy hibátlan protokoll, és bőven lehetne rajta javítani. És azt is tudom, hogy Lennart Poettering lenne az utolsó ember a földön akire rábíznám.

Amúgy meg nem egy nagy wasist feltalálni egy random n+1-edik logging protokollt, ami valamilyen szempontból jobb a syslognál. Mégse teszem, mint ahogy rajtam kívül kb egymillió szoftverfejlesztő sem teszi. Vajon miért?
---
Régóta vágyok én, az androidok mezonkincsére már!

Na ezt fejtsd ki bővebben! Szerinted mégis mi a retek indokolja, hogy http transport kerüljön egy logging protokoll alá? Ja igen tudom, http is the new tcp.
Azért kíváncsi lennék pl a teljesítményére, összehasonlítva az elavult szar sysloggal. Bár a journald-vel eddig szerzett tapasztalataim alapján nagyjából borítékolható minimum 1-2 nagyságrendnyi romlás.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ugyanarrol a syslogrol beszelunk? Arrol, ami nem is halozatra lett tervezve (peldaul hianyzik belole a hostname, mint olyan), kesobb hozzaraktak egy atomgagyi UDP-n tovabbitast, csak epp semmifele visszacsatolas nincs benne, hogy a tuloldalon van-e egyaltalan valaki es ha igen, megkapta-e a logot? Lattam en mar karon varjut, azaz 514-es UDP porton mas programot uldogelni, mikozben a kliensen mindenki azt hitte, szepen mennek a logok... Ugyanigy TCP-t hasznalva sincs visszacsatolas, stb. Az implementaciok probaljak neha tobb, neha kevesebb sikerrel megoldani mindazt, ami a protokollbol hianyzik (lasd peldaul az rsyslog RELP-jet). Amugy tudsz jobb transportot a HTTP-nel?

Ha olvastad feljebb, láthatod, hogy én is tisztában vagyok a syslog hiányosságaival. Mégis, ha van tetszőleges random eszközöm (Cisco, IBM, HP, Dell akármi), a management modulon beállítom a syslog szervert, a másik oldalon fellövök egy rsyslog-ot, és működik jönnek a logok.
Persze, hogy lehetne jobban is, de ha ehhez bárki hozzányúl akkor ez felborul. (Insert mandatory xkcd here) Ehhez egy óriási ipari konszenzus kellene, hogy elfogadjanak egy jobb alternatívát. Nem fog megtörténni.

Ugyanaz, mint az SNMP. Égetnivaló őskövület az is, és számolatlan alternatívát próbáltak már rá csinálni. De ha alarmot akarok kapni egy eszközből, akkor mégis előbb-utóbb az a vége, hogy az SNMP trap fog működni, a csilli-villi WS-Man, CIM-XML, illetve a saját proprietary interfészekkel pedig csak a szívás van.

Az a baj, hogy ha Lennart elkezdi feltalálni a saját syslogját (és sajnos nincs "ha", mert megtette), akkor mások is elkezdik a saját megoldásukat fejleszteni. Nyilván nem fognak beállni Lennart megoldás mögé, mert az szar. Lennart minden megoldása szar, mert nem lát tovább saját magánál, és borzasztóan nem vevő mások requirementjeire és amúgy bármiféle kritikára.

Mi a probléma a Lennart-féle HTTP-alapú loglással? Csak úgy kapásból:

1. specifikáció hiánya - én tűvé tettem a netet, hogy megtaláljam, hogy pontosan milyen header/url paraméterek, milyen session kezelés van, milyen metódusokat használ, mi a jelentésük stb. szóval úgy általában a "protokoll" leírását. Van egy json-os journal reprezentáció, állítólag ez megy át body-ban. Ha tényleg ennyi az egész, akkor simán elment volna TCP felett is, HTTP nélkül. De gyanítom, hogy nem ilyen egyszerű a helyzet, csak csesztek egy normális specifikációt írni hozzá. Gondolom "úgyis változik még az" és egyébként is ha tudni akarod hogy működik "use the source".

2. autentikáció (hiánya) - nem utal semmi arra, hogy lenne autentikáció támogatás benne. A man oldalon nincs is említve user/password/key bármi paraméter. Szerver oldalon van egy cert és ennyi. Kölcsönös autentikációt azért a syslog-ng is tudta. Ráadásul a HTTP kifejezetten problémás terület, mert mindenki imádja feltalálni a saját HTTP-feletti autentikációs protokollját. Kész öröm kliens írásakor mindig szórakozni a custom authentication header-ökben a különféle hash-ek implementálásával.

3. használati esetek - tkp ez mire is való? Alkalmas egyáltalán arra, hogy egy távoli (stateless) eszköz logokat küldjön egy log szerverre? Vagy csak frontend a journalctl-el logok böngészgetésére? (És ha mégis alkalmas, akkor hogyan? A log szervernek kell GET-tel polloznia? Vagy a távoli gép POST-ol a log szerverre? Esetleg valami server-push megoldással? Semmi nyomát nem látom a dokumentációban.) HTTP felett sajnos kifejezetten nehéz kezelni az event jellegű dolgokat, a logolás pedig alapvetően ilyen. Az eddigi tapasztalatok alapján Lennartnak nem igazán szokott szempont lenni, hogy a megoldásai a systemd ökoszisztémán kívüli dolgokkal hogyan fognak együttműködni.

4. teljesítmény - a sok string parsolás miatt gyaníthatóan nem lesz túl gyors. Azért én láttam már log szerverre üzemszerűen 200-300Mbit-en beömlő logokat, ott azért nem egészen mindegy mekkora overheaddel jár. Mondjuk nem sok jóra számítok az alapján, hogy a journald esetén sikerült majdnem 3 nagyságrendet rontani az egyszerű logfájlokban keresés sebességéhez képest. (És ez nem túlzás, vagy légbőlkapott érték, érdemes kimérni, a sima grephez képest kb 300x lassabb).

5. security - kíváncsi vagyok, hogy a Lennart-féle from scratch http szerver mennyire lett biztonságosra megírva, illetve egyáltalán mennyire komplett a protokoll implementációja. A DNS-t is annyira jól sikerült megírnia. Tudom, nézzem meg a forrást...

---
Régóta vágyok én, az androidok mezonkincsére már!

A syslog api (ha ezalatt a csak lokalisan mukodo openlog/syslog/closelog libc fv-eket, ill. a strukturalatlan uzeneteket ertjuk) ugy ahogy van, egy elavult szutyok. Vert kell izzadni egy rendes logrendszer kialakitasahoz. Volt szerencsem tobb tizezer gep syslog-ng konfiguraciojat kezben tartani, komoly buvesztudast igenyelt. Ennel szinte barmi csak jobb lehet, akar formatumrol, akar transportrol van szo.

Nem kell meggyőznöd, tudom, hogy szopás. Amit mondani akartam az épp az, hogy a sokmillió szoftverfejlesztő nem azért nem talál ki jobbat, mert a syslog jó, hanem azért, mert fingjuk nincs az egészről, és még a lokális libc függvények használatát (igen, azt értettem alatta) is úgy kell kiverni belőlük.

Hogy ebben mekkora faszsagok vannak. Egy csomo nem myth, hanem fact, csak szerintuk azert mitosz, mert ok mashogy gondoljak. :D
Bravo :D

A kedvencem az volt, hogy "mert a rendszergazdak gyors bootot akarnak." Hat vazze egy sima init is tized annyi ido alatt jon fel, mint a HP/DELL/IBM bios check. :D
Arrol meg ne is beszeljunk, hogy kb a virtualizacio es felho idejeben mit szamit a boot ido. Es ez szerintuk egy MYTH. Nyehehehehe. Konnyesre rohogtem magam a sok onigazolason. :D

Akiknek ennyi pontban kell onigazolast gyartaniuk, mert a termekuk nem magaert beszel, azoknak el kellene gondolkodniuk egy kicsit, melyen magukba szallni. :D

Ok. Foglak téged, meg a súlyoddal azonos súlyú, és a szerveid számával megegyező, nem szimbiotikus fajokat tartalmazó koralltelepet. Mi történik ha kiveszem mondjuk a májadat, és kiveszek egy fajt a koralltelepből?

A monolitikusság lehet bináris szintű és lehet rendszer szintű. Ez utóbbi azt jelenti, hogy a komponensek mennyire függenek egymástól és mennyire képesek meglenni egymás nélkül.
A systemd-nek igen kemény függőségei vannak, és a benne implementált extra szolgáltatások is hasonlóképp függenek egymástól. Lennart célja, a nagy egységesítés, az alapvető linuxos szolgáltatások tagoltságának, diverzitásának a megszüntetése, ami hosszútávon a Linux ökoszisztéma esetében a post elején felvetett gondolatkísérletemmel azonos eredményhez vezet. Láttuk pár esetben, hogy a diverzitás hiánya, hova vezet.

http://judecnelson.blogspot.ie/2014/09/systemd-biggest-fallacies.html
"Now, a piece of software is monolithic if its components (if it has any at all) are tightly coupled--that is, components logically depend on one another to the point where using them in different contexts requires re-implementing the missing ones."
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( Gyuszk v | 2015. 03. 13., p – 22:31 )

Mivel nem vagyok rendszerepito csak felhasznalo, igy szamomra out of the scope ez a vita ami a systemd korul zajlik. A valasztott disztribuciom (arch) eddig szimpatikus donteseket hozott, ha ugy latjak hogy ki kell dobni a systemd -et akkor majd ugy lesz.

--
arch,debian,openelec,android

( asd | 2015. 03. 26., cs – 10:33 )

mostanaban mindenki elfelejti a stabil kod alapszabalyat: Keep It Simple and Stupid

Na ez pont nem a systemd.