Vlákno názorů k článku
Systemd v roce 2022 povyrostlo na 1,7 miliónu řádků kódu od Josef Pavlik - Teda to je naprosta silenost, vzdyt uz je...

Pointa bola, že na čase nezáleží, ale na dátume - náležitosť faktúry nie je čas vystavenia, ale dátum vystavenia. A aby sa takýto problém vyskytol s dátumom, to už treba trošinku väčšie skoky.

Okrem toho každý normálny systém neprideľuje číslo faktúre pri generovaní, ale pri zaúčtovaní. Keď sa vygeneruje/vyt­vorí/čokoľvek, tak je to draft, ktorý je možné opravovať alebo zmazať až kým ju účtovník (alebo áno, aj automat) nezaúčtuje. Až potom dostane číslo z číselného radu a až potom sa posiela zákazníkovi.

Zakon o ucetnictvi (alespon v CR) vyzaduje okamzik vyhotoveni dokladu a pokud neni shodny tak i okamzik uskutecneni ucetniho pripadu. Firme, ktera vydava 1 fakturu denne muze stacit jenom datum, firma ktera vydava 10 faktur denne pro stejneho odberatele a kde castka muze byt stejna bude potrebovat vyssi presnost identifikace okamziku.

29. 12. 2022, 11:50 editováno autorem komentáře

Za prvé, pokud se čísla faktur přidělují chronologicky, záleží na tom, s jakou přesností datum a čas ukládáte – když to ukládáte s přesností na sekundy, musí ta chronologie sedět na sekundy.

Za druhé, když se jedna faktura vystaví 29. 12. 2022 v 0:00:00,370 a následující faktura se vystaví 28. 12. 2022 ve 23:59:59,976, je to rozdíl méně než půl sekundy, takže žádný „trochu větší skok“, a přesto vám nebude sedět chronologie ani při počítání ve dnech.

To, že vy byste udělal přidělování čísel nějakým způsobem, neznamená, že jiné jsou špatné. V původním komentáři nebyla řeč o čísle faktury, ale objednávky – a klidně to může být udělané tak, že už čísla objednávek jsou generovaná chronologicky, a číslo faktury je pak číslo objednávky. Navíc v tom vašem způsobu byste si nijak nepomohl, pořád je tam okamžik, kdy se automaticky přiděluje číslo a pokud dojde ke skokové změně času, může dojít k porušení chronologie.

Cislo faktury ale vubec nemusi byt chronologicke. Klidne muzu mit v lednu fakturu cislo 100 a v unoru cislo 5, stat po me chce aby byli faktury jedinecne. Dokonce na fakture nemusi byt ani cislo faktury, zakon zadnou takovou povinnost neuklada. Naopak tam musi byt okamzik vyhotoveni ucetniho dokladu a pokud neni shodny tak i okamzik ucetniho pripadu (tohle spolu s dalsimi udaji zajistuje jedinecnost).

ale ukládá, je požadováno v Zákonu o DPH, každá faktura musí mít své číslo a to je součástí kontrolního hlášení, nedokážu si představit firmu, která není plátcem. Zákon o Účetnictví ale číslování dokladů nechává na účetní jednotce, která se si to účtové směrnici stanovuje sama.

Ratbatcat: Zákon o DPH vyžaduje, aby faktura měla jednoznačný identifikátor. Zákon o účetnictví obecně vyžaduje, aby vedení účetnictví bylo průkazné. Což se v době papírových knih nejsnáze vyřešilo chronologickým číslováním. No a dodnes se v administrativě spousta věcí dělá stejně, jako za císaře pána, akorát se ty výstupy generují na počítači^*). Účetní i kontroloři jsou na to chronologické číslování zvyklí a bylo by marné pokoušet se jim vysvětlit, že jednou zapsaný záznam v databázi se opravdu sám od sebe jen tak neztratí, a že naopak zajistit nepřetržité číslování je dost komplikované a výrazně to celý systém zpomaluje.

*) Například obálky s doručenkou mají stále předtištěné kolonky, aby se to dobře vyplňovalo rukou nebo na psacím stroji. Takže se do toho dneska musíte trefovat tiskem a musíte uživateli umožnit milimetrové posuny tisku, protože různé tiskárny tisknou různě. To samé třeba blankety na vysvědčení. V obou případech by bylo daleko jednodušší (a výsledek by vypadal lépe) tisknout to vše, včetně šablony – jenže v praxi se jen psaní rukou nahradilo tiskem na počítači a už nikdo neřešil, jestli by se to s počítačem nedalo dělat celkově lépe.

U těch vysvědčení je to komplikovanější. Jsou na speciálním papíře s vodoznaky a jinými ochranými prvky. Proto tisk do kolonek. Papír dodá stát.

U těch vysvědčení je to komplikovanější. Jsou na speciálním papíře s vodoznaky a jinými ochranými prvky. Proto tisk do kolonek. Papír dodá stát.
Ne, u vysvědčení je to jednoduché. Vysvědčení je na speciálním papíře s vodoznaky a ochrannými prvky. Pak se na ten papír zbytečně vytisknou kolonky, do kterých se pak musí na školách tiskem trefovat. Kdyby tam ty kolonky předtištěné nebyly a tiskly se až současně s údaji, bylo by to mnohem jednodušší – a ničemu by to nevadilo, protože ty předtištěné kolonky nemají žádný vztah k tomu podkladovému papíru.

Vysvedceni je hlavne cislovany tiskopis. Ale delaji se i "bianco" tiskopisy splnujici potrebne nalezitosti, kde zadne kolonky nejsou (SEVT 49 999 9).

Ten papir na vysvedceni jde koupit i bez sablony/kolonek, tedy ciste jen s vodoznakem na pozadi.

Ten papir na vysvedceni jde koupit i bez sablony/kolonek, tedy ciste jen s vodoznakem na pozadi.
Tak to je pokrok.

Ono to ale uz slo takto koupit minimalne v roce 2014. Aspon tehdy jsem to resil a nebyl to vubec zadny problem.

Já jsem to řešil koncem minulého století, je fajn, že se to od té doby posunulo alespoň někde.

Jenze timesyncd je samostatny daemon. Stejne tak jako dalsi komponenty systemd. Zousel jste si nekdy vylistovat bezici procesy? ;-) Skoro to vypada... ze ne :D

Však to je samostatný daemon a robí jednu vec.

To je ako nadávať na coreutils, pretože ich súčasťou je sha256sum.

ja.
Však to je [timesyncd] samostatný daemon a robí jednu vec.
To je ako nadávať na coreutils, pretože ich súčasťou je sha256sum

to je trochu zavadejici ;-)

jmeno timesyncd binarky je systemd-timesyncd, jeji velikost je pouhych 55kB,
a vyuziva sdilenou knihovnu libsystemd-shared-XYZ.so, jeji velikost je 2.7MB (ubuntu, v249)

k3dAR: Ostatní jednoúčelové aplikace v unixovém stylu snad nepoužívají sdílené knihovny? Naopak by to byla chyba, kdyby sdílené knihovny nepoužívaly, protože by to bylo porušení právě toho principu, že aplikace má dělat jenom jednu věc. Protože by musela implementovat i ty věci, které jsou implementované v té sdílené knihovně.

je rozdil kdyz aplikace pouzije 3rd knihovnu, nebo vlastni, v tom druhem pripade totiz je pak jak sem psal zavadejici psat o "timesyncd" ze [v podstate] se systemd nema nic spolecneho ;-)

V čem je ten rozdíl? Navíc nikdo netvrdil, že systemd-timesincd nemá nic společného se systemd. Důležité je, že to je samostatná aplikace, kterou můžete a nemusíte používat. Klidně můžete používat na synchronizaci času cokoli jiného a systemd vám v tom nebude nijak bránit. To je to podstatné.

Prosim vas, a kolik veci pouziva treba takovou libwireshark.so ;-) Ja jen ze ta ma 110M...

Kdyz uz teda delate takovy nesmysl a pomerujete velikosti knihoven, kolik veci zavisi na libc6? :D Mimoto v lib najdete i mnohem vetsi knihovny, kdyz se podivate pozorne :P

goto 1108953

goto 1108955. Ano, najdete hafo knihoven, kterou v realu pouziva jen jedna vec. Ale co to ma byt za argument? ;-)

> Ano, najdete hafo knihoven, kterou v realu pouziva jen jedna vec.

A tipnul bych že libsystemd-<sstrong>shared používá víc než jedna věc. Nevím co tím chce k3dAR říct -- i kdyby to bylo jenom pro timesyncd, tak 2.7 MB mi přijde pro program který implementuje síťový protokol a různé funkce pro nastavování hodin docela v pohodě.

Jenže to musí ten binární log mít specifikovaný přesný formát, který bude implementovaný i v tom parseru. A nesmí ho zkoušet interpretovat někdo způsobem „to je textový formát, vidím, co tam je, nepotřebuju číst specifikaci“. Ta „výhoda“ textového logu, že je možné jej číst čímkoli/kdykoli je dost pochybná. Zejména, když si uvědomíte, že se textové logy často komprimují, takže ta výhoda padá.

ano i ten binarni log musi mit specifikovany presny format ;-)

pokud vystup co leze do binarniho logu lze nasledne z binarniho logu dostat v pozadovanych formatech/castech, stejny vstup ukladany do textoveho logu by to umel logicky take, jen by misto parser na vstupu byl parser na vystupu...

midnight commander otevre gz rovnou, pripadne: zcat tvuj.log.gz | cokoliv

pokud budes chtit psat ze cokoliv nemuze byt treba gui textovy editor, tak ano pred otevrenim v nem se proste log kdekoliv dekomprimuje ;-)

A to je velmi efektivni, ze? :-) Zvlast u velkych logfiles...

ano i ten binarni log musi mit specifikovany presny format ;-)
Nikoli. Binární log musí mít přesně specifikovaný formát. Textový ho právě přesně specifikovaný mít nemusí (což je u textových logů většina případů), což pak právě způsobuje problémy při jejich parsování.

midnight commander otevre gz rovnou, pripadne: zcat tvuj.log.gz | cokoliv
journalctl zase otevře rovnou binární formát journald… Nějak nevidím rozdíl mezi dekompresí a exportem z journald.

textovej log je komprimovanej az po rotacich >2 v poradi, aktualni a predchozi neni komprimovan...

ten textovy log ktery by nesel z textu parsovat, se do journallogu tedy nedostane? protoze pokud dostane, tak se musi parsovat pred ulozenim do binarniho formatu, takze stejne tak by sel ukladat upravenej do textoveho formatu...

textovej log je komprimovanej az po rotacich >2 v poradi, aktualni a predchozi neni komprimovan...
To, že vy to tak máte nastavené, neznamená, že je to tak všude.

ten textovy log ktery by nesel z textu parsovat, se do journallogu tedy nedostane? protoze pokud dostane, tak se musi parsovat pred ulozenim do binarniho formatu, takze stejne tak by sel ukladat upravenej do textoveho formatu...
Vy do journald ukládáte něco tak, že to zapisujete do textového logu a z něj to parsujete?

Problém textových logů je v tom, že obvykle nemají pevně definovaný formát, takže při jejich parsování o některé záznamy přijdete nebo budou chybně rozparsované. Textový log často rozbijete jenom tím, že zalogujete konec řádku.

To zalezi na nastaveni (externiho nastroje). Aneb komprimovany muze (nemusi) byt uz pri prvni rotaci. A taky nemusi byt komprimovany vubec (treba na CentOSu ve vychozim stavu). Proste si to dela kazdej jak chce ;-) Neexistuje unifikovane reseni.

Filip Jirsák: Ano, takto na papíře vypadají binární logy skvěle. Osobně by se mi taky líbila možnost textové, ale s určeným formátem prvních několika sloupců a escapovanými \n ve zprávách - já konkrétně teču z toho defaultního formátu času "Dec 29 19:08:51" - bez timezone, neseřaditelné… Ono tohle se dá v podstatě udělat pomocí pár řádků konfigurace rsyslogu a logrotate, jen to není default.

Nicméně v realitě jsme do rukou dostali journal, který je desetkrát pomalejší, ale za to zabírá třikrát víc místa na disku i v paměti, neumí základní věci typu nastavit pro různé unity různé retentions nebo přetékající log promazat, téměř neexistuje tooling pro věci jako "vyexportuj journal pro unity X, Y, Z mezi časy A a B pro pozdější analýzu", a ještě je tu pachuť ohledně recovery logů při selhání hardwaru a nutnost řešení konzistence při zálohování.

Naopak, z pohledu konzistence je journald lepsi - zvlaste pokud si clovek zapne sealing. S textakem jen tezko nekdo uhlida, ze logy nekdo v ramci zametani stop po svych preslapech treba nepoeditoval... ale mozna prave to "potrebujete"? :D

Ono tam tech informaci je podstatne vic, defaultne journalctl emuluje vystup klasickeho logu (aka short), ktery je ocesany... ale parametrem -o z nej jde vymamit extenzivnejsi vystupy ( verbose), nebo klidne treba v json formatu, nebo vystup s jinym formatem data/casu, nativne prepnout z lokalni timezone do utc... as-build to umi to i reverse sort - tzn. nejnovejsi udalosti nahore, snadno se da dostat k logu z predhoziho bootu ( -b -1), kdyz se neco zvrtne... samo/nativne si to umi resit rotaci/data retention po definovany cas a nemusim spolehat na nejaky externi tool a cron, co ho pusti (nebo taky ne).

Cim vic clovek cte tuhle diskuzi, tim vic se utvrzuje v nazoru, ze lidi dokumentaci fakt moc nectou... ale hlavne ze maji nazor, ze je vsecho spatne :-)

> Naopak, z pohledu konzistence je journald lepsi

Z pohledu detekce poškození ano, z pohledu čitelnosti logů těsně před selháním systému (kdy logy potřebuju nejvíc) mi nezbývá než doufat, a když vidím „kvalitu“ zbytku journald tak nejsem moc přesvědčen…

> Cim vic clovek cte tuhle diskuzi, tim vic se utvrzuje v nazoru, ze lidi dokumentaci fakt moc nectou...

To je pravda, ale když to neumí základní funkčnost, tak k čemu mi je že to umí json a nastavovat formát času?

To rotování je taky takové sporné -- když se něco zblázní a začne logovat (máme teda ratelimit, jak v journald, tak v rsyslogu), tak u journald všechny logy odrotují, u rsyslogu dojde místo a předchozí logy jsou zachovány… Já bych preferoval to druhé, ale samozřejmě se musí nějak zařídit, aby místo došlo tak, aby nehavarovaly služby protože není místo ve /var/spool atd.

Kdyz dojde k padu systemu, tak i textove logy byvaji vesmes nakopnute. A fakt pomerne casto je to tak, ze v textaku je pasaz, kde je spousta znaku 0x00 :D Ve finale to jako bonus rozhodi mnohe ty "parsery textu", kdyz na tohle narazi...
A pomoci journalctl --verify muzu instantne overit, jestli je v logach nejaky vami popsany problem....
Rotace je nastavitelna podle toho, co kazdemu vyhovuje. Jinak viz man journald.conf a informace u parametru SyncIntervalSec (vc. toho co to dela u zprav s kritictejsi prioritou).

No vždyť jsem to psal, že pasáže nul vídám. A co se zvládlo zapsat předtím, to normálně vidím. Řekne mi journal „sorry poslední zápisová transakce se nedokončila, nezobrazím, bye“?

Sync podle priorit je pěkná myšlenka.

Nikoliv, vysledny stav bude stejny - neco v tom logu bude, neco ne. Nevim, z ceho jste (asi) dovodil, ze nepujde precist cely log jen proto, ze je binarni... proste tam jen budou chybet ty informace, co uz se nestihly korektne zapsat. A jako bonus mam nastroj, co mi to poskozeni logu primo indikuje - nemusim na to prichazet metodou pokus-omyl.

> Nevim, z ceho jste (asi) dovodil, ze nepujde precist cely log jen proto, ze je binarni...

Nemyslel jsem že nepůjde přečíst celý log, to už se snad umí řešit (žurnálování jako v databázi), ale že pro přečtení posledních položek asi nestačí když se zapíšou, ale musí se zapsat a pak se ještě musí někde nastavit nějaká struktura, že jsou tam zapsané. Ale třeba je ten formát opravdu nějaký mazaný a bude to fungovat.

No mimo jine to resi i to, ze kdyz se nejake naruseni detekuje, tak se okamzite stavajici soubor odrotuje a zacne se s cistym souborem.

Nicméně v realitě jsme do rukou dostali journal, který je desetkrát pomalejší
Za prvé jste při tom porovnání rychlosti porovnával jablka s hruškama, za druhé je při čtení logů rozdíl v rychlosti v řádech desítek milisekund absolutně nezajímavý.

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ů. A znáte to – každý nástroj by měl dělat jednu věc, a tu má dělat dobře.

> 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…

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)
Tak si to zkuste srovnat třeba s případem, kdy budete muset mezi textovými logy nejprve najít nějaký starší soubor. Nebo budete potřebovat data z více souborů. Nebo z více služeb.

Sekund.
OK, tu jedničku jsem přehlédl, rozdíl je tedy jedna sekunda. Když ovšem nebudeme počítat dobu, jak dlouho jste hledal ten správný soubor s textovým logem…

OK, ale než bude, tak prostě nemůžu journal rozumně používat.
Vždyť můžete používat to, co používáte doteď. Data z journald přece můžete vyexportovat i v textovém formátu.

Jinak popíšu k čemu jsme aktuálně dokonvergovali: máme aplikace v Pythonu.
Podle mne na tohle je lepší ELK nebo něco podobného (dají se do toho sbírat i logy z journald). journald vnímám jako základní jednoduché logování v systému, na aplikační logy vlastní aplikace bych to nepoužil.

No ehm... pokud to mate tak, ze to restartujete kazdych 5 sekund i kdyz tam ten device pripojeny ani neni (a instantne to spadne), tak to mate spis sami blbe vymyslene. A to ale neni chyba systemd...

journald je hlavně sběr logů a nikoliv jejich archivace, ač tu také nějak umí.

Tvůj popis ukazuje, že vlastně nemáš problém s journald, ale s návrhem aplikace, zkus se zaměřit spíše na tohle, ušetříš si spousty energie běháním proti zdi. To nemyslím nijak zle, ale občas je dobré se zastavit a podívat se, jestli ty problémy neřešíš zbytečně.

Souhlasím že logovat systémově provoz po sériáku je blbost, na druhou stranu různé SOHO mailservery co jsem viděl a adminoval (ne že jsem to tak nastavil, ale už to tak bylo i od jiných) strkaly skrze syslog do mail.log pro každý mail třeba 15 řádků, takže ty objemy nejsou zas _tak_ astronomické. (na druhou stranu webservery už si typicky řeší access.log po vlastní ose a netlačí to přes syslog)

A jak to mám teda archivovat? Koketoval jsem s tím že to budu forwardovat do rsyslogu, v unitě nastavím SyslogIdentifier a podle toho to budu rozhazovat do normálních texťáků, ale nakonec mi to přišlo jako moc velký opruz na to abych to řešil (a raději jsem se věnoval omezení aby se do journalu nelogovaly zbytečné věci).

máme servery, kde journald ukládá 100MB/s logů.

Obecně udržovat a archivovat logy na stanici nebývá z dnešního pohledu útoků a rizik nejlepší volba. Rejpání se v logách přímo přes journald je opět takové spíše na ruční debugování v UAT než pro produkce.

Na standalone stanicí, které někde u klientů něco dělají, používáme třeba exporter do sqlite, nad logy je pak nějaká analytika a alerting, přímo na stanici. Dobře dnes může sloužit třeba i loki.

Journald je pro čtení a vyhledávání logů takový dost hloupý, nemá indexy a čte to sekvenčně ze společných datových souborů. Chceš-li ho optimalizovat pro rychlost dotazování, tak oddělit služby do vlastních souborů je dobrý začátek. To, že ale umí prokázat úplnost logů a při jejich exportu je možné pokračovat od poslední exportované zprávy je velká výhoda proti rsyslogu.

proc by ta vyhoda odpadala? uz jste nekdy pouzil pipe v linuxu? bezne pracuju s komprimovanymi textovymi logy a zadny problem jsem s tim nikdy nemel. naopak to shledavam jako velikou vyhodu mit je v textove podobe a presun k logum binarnim je dle meho veliky fail.

(btw. @Danny to nebyl "hejt", ale normalni otazka, na kterou jsem cekal normalni odpoved - ta vase me nepresvedcila).

predstavte si situaci, kdy vam "crashne" disk/ssd prave s logy. je jednodussi dolovat textova data nebo binarni?

Textovy format vam velmi snadno rozhodim proste tim, ze poslu oddelovac tam, kde ho ten vas parser nebude cekat.

To je podle „neviditelného odkazu“ (vlevo od nicku) reakce na váš vlastní komentář? Pokud to mělo být na mě, tak říkám, že rsyslog by měl \n, \r a spol. escapovat. (mezery/taby oddělovače nejsou, protože důležité jsou první dva sloupce - čas a jméno zdroje - pak je mezera a pak už může být mezer kolik chce).

Tak to asi neco delate blbe ;-)

danny@enterprise:~$ du -s /var/log/journal
351864  /var/log/journal
danny@enterprise:~$ journalctl | wc -c
2828168

Čili 352 MB logů na disku obsahuje 2.8 MB textového výstupu? Tak to máte výrazně horší skóre než já, mně 64 MB logů na disku obsahuje 20 MB textového výstupu.

Mimochodem:

# time journalctl -u transmit_api.service | wc -l
119667

real    0m1.183s
user    0m0.877s
sys 0m0.150s

# time zcat /var/log/syslog.2.gz | wc -l
299219

real    0m0.143s
user    0m0.133s
sys 0m0.020s

🤡🤡🤡

Mimochodem2 (náhodou jsem na to narazil při ověřování argumentů v jiném komentáři):

/var/log/journal/915b7493f84f42eabb5d51eba95f2985 # cat system.journal | wc -c
58720256
/var/log/journal/915b7493f84f42eabb5d51eba95f2985 # cat system.journal | xz -9 | wc -c
4217472

Tak tolik asi k té komprimovanosti. Analýza pomocí

hexdump -ve '1/1 "%02X " "\n"' system.journal | sort | uniq -c | sort -rn

ukáže, že 58% bajtů v tom souboru jsou binární nuly. Velmi letmé prolistování hexdumpem pak ukáže, že bohužel jsou ty nuly rozprostřené v menších blocích přes celý soubor, takže udělat soubor sparse (cp --sparse=always) ho zmenší jenom o čtvrtinu.

Kdyz on si nejake misto pre-alokuje dopredu. Ono se to muze hodit... treba k tomu, ze vam to zaloguje udalosti, i kdyz neco "okolo" zaplacne cely filesystem.

To mě taky napadlo, a proto jsem to pak ještě zkusil i na „odrotované“ soubory. A… ne. Jako ten poměr je trochu lepší, ale furt je >10x. Což mi přijde úplně bizarní, čekal bych, že to archivní soubory během odrotování zkomprimuje (jako to dělá logrotate). Prej to jde zapnout, jenom to není default, tak to zkusím.

ad 1) escapování má vždy dvě strany, při uložení nechceme rozbít formát dat, při čtení nechceme interpretovat něco, co nám může udělat paseku. A jak prosímtě escapuješ do textového logu? Vždyť to nemá žádná pravidla. journald umí vracet strukturovaný výstup (json např.), kde již je vše řádně escapované.

ad 2) ty nuly tam jsou uloženy dopředu jako prostor, kam se zapisují další logy. Hard reset je tvůj častý případ? Journald primárně data drží v paměti a v pravidelných intervalech syncuje na disk. Pokud chceš dobře fungovat s hard resety, asi bych zvolil úplně jinou technologii na zápis logů. Ano, můžeš si počítat vlastní checksum, ale tady se bavíme o univerzální logovací službě.

ad 3) v jaké konfiguraci? Výchozí nastavení v distribucích je tak trochu hodně univerzální a o nic moc se nesnaží, výhoda journald je jeho dokumentace a možnost přízpůsobení.

Zkoumat logy přímo na serveru je něco, co se spusty let v mém vesmíru nedělá, logy sbíráme a replikujeme na centrální server, snažíme se prokazatelně sesbírat a přenést všechny (to journald umí pěkně), poté se indexují a dělají nad tím další operace. Jde o to, že přístup na produkční servery pod rootem má málokdo, dělat si tam nějaký streaming logů do konzole je pro mě tak trochu mimo.

Podle toho, co tady píšeš, tak máš nějaké malé přenosné linux stanice, ty mají připojený nějaký HW, s kterými komunikují a to logují. To vysvětluje ty časté hard resety, na to journald zrovna není přeborník a klidně použij něco jiného, těžko víme jak to máš, začal jsi univerzální kritikou, tu jsme se snažili mírnit, teď to vypadá, že v tvém konkrétním případě journald není vhodný, skvělé si to uvědomit a najít vhodnější řešení.

1) Omezení, že logovací systém nedokáže uložit newlines a řídící znaky mi přijde jako něco, s čím dokážu v pohodě žít. A pak už není potřeba escapovat při zobrazení. Do textového logu bych escapoval třeba tak, že bych "\" nahradil za "\\" a newline nahradil za "\n" (stejně tak \r a spol.).

Schválně jsem si zkusil do syslogu poslat newline pomocí logger "něco s newline" (doufám že to nedělá escape už na klientovi) a zalogovalo to místo ní "#012". To není úplně optimální, protože když tam pošlu doslova "#012", tak to pak nejde odlišit od newline (správně by to mělo třeba ještě escapovat křížek), ale na druhou stranu myslím že lidi by neměli do logů posílat newlines a tohle zařídí že se to nerozbije, holt za cenu nejednoznačnosti.

2) Jo, tak nějak jsem si to myslel, že to alokuje filesystém třeba po stránkách. Hard reset je můj častý případ v tom, že je to ze způsobů ukončení systému ten běžný (výpadek elektřiny, zátuh (to se mi děje na notebooku občas bohužel)). Ale jen výjimečně potřebuju logy co byly těsně před tím (to pokud by to bylo tím způsobeno - většinou je to ale nesouvisející externí příčinou).

Checksum jsem dával jenom jako příklad že to nevyžaduje binární logy a šlo by to implementovat i nad textovými.

3) Výchozí v Debianu. Tobě to funguje?

Nj, já jsem byl předtím SOHO admin kde to bylo heterogenní a bylo toho málo, a teď jsme v živelné fázi startupu, tak se to dělá takhle (a taky je těch strojů pár). Logy přeposíláme jenom s velkou severity za účelem alertování.

SOHO adminování byly takové ty běžné webservery, mailservery a tak; a teď mám radary :) což je průmyslové PCčko, ke kterému je připojené bladeRF a hromada sériáků přes které se to různě ovládá a měří. Aktuálně to provozujeme tak že se tam nasshčkujeme a čteme logy (případně si soubory odpovídající času kdy se něco rozbilo zkopírujeme). A taky to tak, no, vyvíjím, protože dost věcí se blbě dělá na stole. A pak to má lokální influx+grafanu, do které se sbírají metriky po sekundách, a do globální grafany se posílají minutové agregace - pro bližší zkoumání některých problémů jsou potřeba ta sekundová data. To dělám tak že si protuneluju po SSH port 3000 a připojím se na tu grafanu lokálním prohlížečem :).

TL;DR nejak to bastlime, ale poradne a systemove spravne reseni nevyhovuje tomu nasemu bastleni :-) Tak ho hejtime...

TL;DR journald se nehodí na mnoho use-cases na které byl syslog super, tak ho hejtíme.

TL;DR journald se nehodí na mnoho use-cases na které byl syslog super, tak ho hejtíme.
Přesnější by bylo, že se na to nehodil ani syslog, akorát že jste to neřešil. Například to „escapování“, ze kterého nejde zrekonstruovat, co přesně bylo zalogováno, je podle mne vážný problém. O kvalitách syslogu svědčí i to, kolik aplikací se mu vyhýbalo a řešilo logování po svém.

Z jinych mist teto diskuze je patrne, ze spis mate blbe vymysleny sve "aplikace". Viz treba ty restarty unity co pet sekund, kdyz nema pripojeny zarizeni. A pak fnukate, ze vam to zablesi zurnal.

"Omezení, že logovací systém nedokáže uložit newlines a řídící znaky mi přijde jako něco, s čím dokážu v pohodě žít."

A pak si tam zkus poslat něco, co obsahuje vstup od uživatele.

A pak si tam zkus poslat něco, co obsahuje vstup od uživatele.

Ano, to je totiž většinou nezpracovatelné, neuložitelné a nečitelné.

...a potřebuješ to.

A jak si to pak zobrazuješ? Dokážu si to představit v nějakém GUI, ale v textovém terminálu to stejně budeš muset ukazovat nějak escapovaně. A i v tom GUI bude IMHO dost zásadní ty řídící znaky nějak zobrazit (a neinterpretovat, například když tam je \r, tak nechceš přepsat obsah předchozího řádku), protože na to koukáš asi z důvodu, že vstup od uživatele vyvolal nějakou chybu a v tom budou řídící znaky hrát roli. (jediné co tam může být OK je newline)

Furt si nedokážu představit use-case kdy by mi vadilo že to escapoval už syslog než to zapsal do souboru (a kdybych to jó potřeboval tak to můžu odescapovat).

ad 1) to #012 dělá rsyslog, https://www.rsyslog.com/doc/v7-stable/configuration/input_directives/rsconf1_escapecontrolcharactersonreceive.hm a to je přesně ono, nikde není řečeno jak má probíhat escapování do texťáku a každý si to dělá jinak.

ad 2) a chceš si logy řešit sám nebo řešíš, kterou službu na ně použít? Z těch linuxových vím pouze o journald, který dělá kontrolu integrity, ostatní nikoliv. Pokud chceš psát vlastní logování, klidně, ale pak nemáme o čem diskutovat.

ad 3) journald v debianu potřebuje trochu lásky a konfigurace, jako spousta věcí tam, bohužel, dobře připravené distribuce linuxu začínají být nedostatkové zboží a pokud potřebuješ od journald jiné chování, změn si to, to je na linuxu skvělé, dá se tam upravit cokoliv.

Nj. to vypadá jako celkem šílený návrh systému, ale co občas naděláš, že? To vypadá, že s logy máte zbytečně moc ruční práce, to se nedivím, že vás trápí pomalost journald při čtení.

> Nj. to vypadá jako celkem šílený návrh systému, ale co občas naděláš, že?

Nadělat s tím můžu cokoli, protože to donedávna byla one-man show a teď je nás pár a můžu vymýšlet celkem libovolné změny. Spíš nevím jak to udělat líp. Spíš jde o to že jsem měl plné ruce práce s tím udělat funkční radar způsobem který jsem si vymyslel a zjistit jestli z toho lze odstartovat startup a nebyla kapacita na to zkoumat a vyrábět nějaké „fullstack věci“, a fakt jsem ocenil že „počítače“ („SDRka“, „arduína“, …) „prostě fungujou“ a nemusím to řešit.

> To vypadá, že s logy máte zbytečně moc ruční práce, to se nedivím, že vás trápí pomalost journald při čtení.

Stejně tak nevím jak ten vývoj a především teda debugování dělat jinak - něco se pokazilo, tak čtu logy, snažím se zjistit co se kde stalo, a typicky to odhalím. Resp. tohle je způsob jakým věci dělám (odjakživa, tj. 10+ let) a jsem s tím úspěšný, což samozřejmě neznamená že by to nešlo ještě lépe.

AFAIK je možné mít těch číselných řad paralelně víc. A je to tak konstruované kvůli (o něco) lepší průkaznosti účetnictví. Ale poněkud nepříjemné to je.

S tím podvržením nevím, jak to myslíte? Že bych byl domluvený s dodavatelem, že číslo faktury bude mít nějaký "checksum" a podvodník by nejspíš nevygeneroval validní?

Jinak počty ani čísla faktur nejsou osobní údaje, takže UOOÚ s tím nemá co dělat.

Nikoliv, nic mi nebrani mit v cisle faktury treba i mesic... kdy se zmenou mesice se rada zdanlive "prerusi". Do cisla muzu zakomponovat dalsi veci, treba i to, kdo fakturu vystavil. Dulezite je umet ten system cislovani pripadne kontrole popsat.

Zákon o účetnictví skutečně číselnou řadu mezi povinnými náležitostmi faktury neuvádí. Je to nicméně zavedený mechanismus integrity účetnictví a když ho nebudete při kontrole finančním úřadem mít, můžou pojmout podezření, že krátíte daně a udělat hloubkovou kontrolu, což nechcete. V době papírového účetnictví to asi mělo smysl, nicméně dnes se dá ta integrita účetních záznamů držet a prokázat i jinými způsoby.

U faktury ne, ale u účetního deníku už ano:

https://www.zakonyprolidi.cz/cs/1991-563?text=z%C3%A1kon%20o%20%C3%BA%C4%8Detnictv%C3%AD#p13

Účetní jednotky účtují, pokud tento zákon nestanoví jinak:

a) v deníku (denících), v němž účetní zápisy uspořádají z hlediska časového (chronologicky) a jímž prokazují zaúčtování všech účetních případů v účetním období,

Faktura je jen "formát přenosu dat", ale její číslo evidujete třeba v deníku vydaných faktur. Teoreticky by asi mohlo být náhodné, ale FÚ by se nejspíš zeptal, jak z toho pozná, že jste něco nevyřadil.

Zakon o ucetnictvi vyzaduje jednoznacnou identifikaci dokladu, jak toho dosahnete je na vas. Faktura vubec nemusi mit cislo. A vyrazeni z ucetnictvi muzete mit osetreno formou predpisu. Pokud urednice FU bude namitat ze je to nedostatecne, odkazte se na zakon o ucetnictvi a pani to pochopi. A ano, zazil jsem i hloubkovou kontrolu kdy jsme dostali pokutu 5000 za nejaky smesny prohresek ale dalsi 3 roky byl klid, takze za tech par dne prace a par tisic to stalo.

Chronologický zápis v seznamu ovšem nevyžaduje chronologické číslování, pokud si zvlášť evidujete datum a čas. Akorát se vám pak může stát, že v tom chronologickém výpisu budou čísla faktur prohozená (bude tam zapsaná nejprve faktura s vyšším číslem a pak až s nižším), což bude přitahovat pozornost kontrolorů – proto se tomu i dnes snaží software vyhnout, i když to odpovídá době, kdy se účetnictví psalo perem do skutečných papírových knih, a dnes to vše jenom komplikuje.

Ono by asi šlo to číslo faktury generovat jako hash údajů z faktury (a zkontrolovat jedinečnost) - pak by to bylo nejen jednoznačné, ale taky by šlo snadno zkontrolovat, že s tím dodatečně někdo nehejbal.
Ovšem obávám se, že by to bylo trochu mimo toleranci ouředníků.

Účelem nepřetržitého číslování bylo to, aby se na nějaký doklad nezapomnělo. To hash nezajistí. Také je potřeba počítat s tím, že může docházet k chybám, takže je možné vystavit opravný doklad – to, aby doklad s přiřazeným číslem byl neměnný tedy není nijak zajímavé.

Účetní systémy nedělám, takže možná mi něco uniká, ale proč prostě nepoužít autogenerovaný primární klíč z tabulky invoice?

Dobrý den, mohu poprosit o popis jiného způsobu prokázání, že mnou vystavené faktury za dané období jsou všechny v případě, že nebude použita variace na vzestupnou řadu? Řekněme že mám v systému řádově 1000 různých dokladovych řad a potřebuji peovest kontrolu zda mám všechny. Předem děkuju za popis. S přáním hezkých vánočních svátků