Názor k článku
Systemd v roce 2022 povyrostlo na 1,7 miliónu řádků kódu od Jan Hrach - > Za prvé jste při tom porovnání rychlosti...

  • Článek je starý, nové názory již nelze přidávat.
  • 29. 12. 2022 22:13

    Jan Hrach
    Stříbrný podporovatel

    > Za prvé jste při tom porovnání rychlosti porovnával jablka s hruškama

    Otevřu log, zmáčknu End, čekám. (inb4 "tak používejte journalctl -n 500 a když pak zjistíte že chcete víc historie tak si to pusťte znova" -- ve skutečnosti jsem se z diskuze dozvěděl že mám dávat journalctl -r, uvidím v praxi, jestli mě bude mást že je nejnovější nahoře)

    > za druhé je při čtení logů rozdíl v rychlosti v řádech desítek milisekund absolutně nezajímavý

    Sekund.

    > Formát journald je podle mne určený pro sběr logů, ne pro jejich archivaci. To, co vám chybí, podle má být vlastností nástrojů pro zpracování a archivaci logů.

    OK, ale než bude, tak prostě nemůžu journal rozumně používat.

    Jinak popíšu k čemu jsme aktuálně dokonvergovali: máme aplikace v Pythonu. Používáme nějaký logger (nevím jaký, řeší kolega, já jenom vím že se to naimportuje a pak můžu dělat logger.warnin­g("bleble")), který to posílá na (lokálně běžící) logovací server, který to zapisuje do texťáků pojmenovaných podle služeb a sám si je rotuje. A současně zprávy s nejvyšší důležitostí přeposílá na centrální server, který nám pak píše maily a na Slacku. Logů je řádově 10 MB za hodinu (například logujeme veškerou komunikaci s hardwarem po sériáku, aby to pak šlo debugovat), to jsme usoudili že journal nezvládne + popsané problémy s exportem a archivací (například jsme jedno zařízení zničili, poslali na opravu, a oni se za dva měsíce ptají co přesně jsme tomu dělali potřebujeme umět vyexportovat několik hodin logů a uchovat; samozřejmě z journalu bych si je mohl vypsat textově, ale to je můžu mít textově rovnou).

    Do journalu jsou přesměrované stderry těch pythoních programů, takže se tam logují jednak stavy unit (restart, exit code) a jednak když to udělá něco co ten logging nezaloguje (ten logger chytá i neošetřené výjimky, ale pokud to umře nějak kreativně tak se to vypíše na stderr + na stderr píšou Cčkové knihovny co ten Python používá). A pak je tam nějaké hlídátko journalu které z toho taky dělá zprávy které se nám pak posílají (přečte z journalu řádek, podle regexpů a kolikrát se to za poslední hodinu opakovalo zjistí důležitost a zahodí/pošle/pošle urgentně).

    Tím jsme dost vyřešili ten problém že se do journalu nesmí moc logovat protože pak je velkej a pomalej. Jediné co se mi teď stalo je že se jedna z těch služeb každých 5 sekund restartovala (jak má nastaveno) protože nebylo připojené HW zařízení co bylo potřeba a tak to vždycky hned skončilo, a tohle přes noc udělalo desetitisíce řádek (systemd hlášky o restartování + stderr hlášky při startu) a pak to zase bylo pomalý. Tohle se samozřejmě musí vyřešit tím že se víc poladí takové ty "restart timeout" a "burst" aby to třeba zkusilo 3x a pak až za 5 minut. Škoda že to tam teď furt je (nechci odrotovat celý journal kdybychom potřebovali něco ještě ladit a selektivně tu jednu unitu smazat nejde) a ještě nějaký ten týden bude…