Log4j 2.17.0

Bezpečnostní chyba CVE-2021-44228 pojmenována Log4Shell v Apache Log4j 2 byla opravena v Log4j 2.15.0. Záhy se ale zjistilo, že ne zcela. Bezpečnostní chyba CVE-2021-45046 byla opravena v Log4j 2.16.0. Další bezpečnostní chyba CVE-2021-45105 byla opravena v Log4j 2.17.0.

19.12.2021 08:00 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[Když Java tak JavaScript]

Tak já raději počkám na 2.18.1...

[David]

A ani to nebude stačit.

[Jendа]

Také jste naletěli na to že dvě dávky patche na Log4j budou stačit? Už to nestačí, už je třetí. Co bude dál? Keep complying, idiots!

[xkucf03]

Příloha:

• Zeman - povinné patchování.png (688982 bytů)

I Miloš Zeman je pro povinné patchování…

[_]

Já bych neopatchované počítače odpojoval od internetu.

[trekker.dk]

Jedno očkování tam zůstalo

[alkoholik]

Kdepak, log4j i vakciny jsou naprosto bezpecne!

[Michal2]

Me dost udivuje, ze se na to prislo az po tak dlouhe dobe. Kazdemu, kdo pouzil ten jndi lookup muselo hned trknout, ze to muze byt problem. Hlavne to muselo byt jasne tem, co podporu pro to psali. Takova vec v knihovne slouzici k logovani vubec nema co delat nebo alespon ma byt defaultne vypnuta. A to je zasadni problem, hadam, ze 95+ % tech, co tu knihovnu pouzili nemeli ani nejmensiho tucha, co ta vec vlastne vsechno dela. Hele, nasel jsem na netu nejakou knihovnu na logovani. Dokumentace ma 950 stran ale na prvni je napsano, ze staci importnout a pak log.debug("neco se posralo"); a je to! To je bomba, to musim hned pouzit. Ze to ma zkomilovane 15MB? No a co.

Kazdy, kdo nasadil knihovnu s 170 tisici radky kodu kvuli logovani je u me blazen. Kdo si nevic myslel, ze v takovem bloatwaru zadna dira neni je u me naivni blazen. A kdo si mysli, ze to byla posledni je naivni^2 blazen :-p

Rad bych se mylil, ale dalsi takova tikajici bomba s RCE potencialem jsou apky nad electronem.

[xxx]

No to je tezky. Ona jakakoliv netrivialni logovaciutulita ma sva uskali. Treba takovy printk(). printk() - The Most Useful Tool is Now Showing its Age

[karelI]

To nekritické využívání knihoven mě dost děsí. Strašně se propaguje, že programátor nemá vymýšlet kolo atd. když už to někdo vyřešil před ním, ale to že to sebou taky nese problémy a rizika se nijak zvlášť neřeší. Ze zkušenosti mohu říct, že až na pár speciálních výjimek jako jsou kodeky se využití externí knihovny v čase vyplácí čím dál méně až to nakonec dojde k bodu, kdy by se víc vyplatilo napsat in-house řešení.

A věřím, že se to týká i většiny použití téhle Log4J.

[BoneFlute]

Řeší.

Obecně je lepší, když se napíše knihovna, kterou zkritizuje sto lidí, a vychytají se díky tomu na ní chyby; než když se napíše sto inhouse řešení, které budou mít všechny chyby, a nikdo je neopraví.

Nemluvě o tom, že můžeš tu knihovnu zhodnotit, vybrati jinou. Zatímco inhouse je stále stejně špatný. Budeš rád, když ti tam někdo udělá review. A to bude spíše zázrak.

[karelI]

A teď realita: někdo zjistí, že na řešenou věc existují knihovny. Vymyslí se tedy kriteria a vybere se ta nejlepší a nadšeně se začne používat. Ve skutečnosti pokrývá potřebnou funkcionalitu asi ze 60% a zároveň obsahuje asi 10x víc kódu, který řeší spoustu dalších věcí které nepotřebujeme.

Samozřejmě je nutné udělat wrapper kolem API, protože je nutno ztransformovat data na vstupu a výstupu (v horším případě při každém volání).

Časem se ukáže, že to co pokrývá je vyřešeno dost naivně, takže je nutno dělat další předzpracování dat, odbočky, ohejbáky na narovnáváky.

V průběhu času se samozřejmě náhodně objevují mystické chyby a nekorektní chování v krajních případech. Po těch letech nikdo nemá sílu to řešit s autory, je to zdlouhavé, rozbilo by to něco jiného apod.

SW projekty neběží stejnou rychlostí, takže se to postupně rozchází s požadavky na systém, vlastnostmi jazyka, kompileru apod. Je fakt pruda, když vývojáři zvládají "držet krok s dobou", ale jsou závislí na knihovně, která je X let pozadu a oni kvůli tomu musí udržovat starý kompiler, koukat na starý kód, apod.

Zkrátka, knihovny jsou super věc v raných fázích vývoje, ale časem z toho je kámen na noze, který časem občas vybouchne (čest výjimkám), což pak má dost nepříjemné důsledky pro vývoj celého projektu. Asi nejhorší na tom je, že podobné problémy jsou z povahy věci nepředvídatelné a nemají jednoduchá řešení. S vlastním kódem se i z tohoto hlediska dá pracovat líp.

[BoneFlute]

Je to jak říkáš.

Na druhé straně, jednoduchá matematika - kód inhouse je furt horší.

[karelI]

Proč by měl být horší?

[BoneFlute]

Viz co jsem psal v přechozím komentáři.

Jediný důvod, kdy má smysl psát si vlastní řešení (po pravdě ale důvod zdaleka ne vzácný) je, když po rešerši vychází, že všechna existující řešení jsou špatná. A i v takovém případě je výhodnější, když se člověk přidá k tomu nejlepšímu špatnému existujícímu řešení a snaží se ho vylepšit. Nebo něco na ten způsob.

Měl jsem také vlastní řešení ledasčeho. Ale po nějaké době jsem toho mnoho opustil, protože prostě nebylo rozumné si to udržovat, a existující řešení byly (už) dobré.

[karelI]

Na začátku samozřejmě platí to o čem mluvíš. Jenže po 15 letech vývoje to skončí ve stavu, kdy místo X potřebných řádků pro danou funkcionalitu máš 10 * X v knihovně (o kterých navíc nic moc nevíš), X/2 kolem ve wrapperech a ohejbácích a dalších X/2 pokrývající případy, které knihovna neřeší.

Ty konstanty se mohou lišit, ale já za svou praxi bohužel zažil mnohokrát ten moment, že se to překlopilo ve prospěch in-house řešení a je to moment docela mrzutý, protože v tu chvíli už se na tom nedá mnoho změnit.

A promiň, ale představa, že víc hlav vyprodukuje lepší produkt, zvlášť když je tento 10x větší než co potřebuješ, není úplně samozřejmá. Určitě je na světě pár profláklých výjimek, ale obecně bych na to nespoléhal.

[BoneFlute]

Všechna in-house řešení, která jsem viděl, byla strašná. Mnohá existující (komunitní, knihovní) která jsem viděl jsou strašná. Ta matematika je pro mě jednoduchá.

Samozřejmě se nebavím o situaci, kdy si člověk chce to řešení napsat sám protože prostě proto. Třeba jako výzvu, nebo si fakt věří, a chce komunitu trumfnout. Ale jako firemní strategii to považuji za velice nerozumné.

[j]

Hele, ja s tebou naprozdil od toho druhyho tu naprosto souhlasim, ale mas tu jeden problem. Tu knihovnu primastis a zavolas za 10 minut, kdezto vlastni print do souboru bude trvat 20 ... nekomu kdo vi co dela, a takovyho vetsinou nemas ani jednoho. Takze musis pocitat s tim, ze mas hromadu matlalu, ktery patlaj kod v go, rustu, dzave ... ale ulozit string to souboru/poslat ho na standardni vystup ... to je pro ne prace na 1/2 roku nejmin.

Taky je na tom uzasny to, ze ty si s tou knihovnou co ji jako strasne nutne potrebujes, pritahnes 20 dalsich, na kterych zavisi prave ona. Jeste zajimavejsi to zacne bejt v okamziku, kdy ty knihovny mas dve, a obe zavisej na jiny "stejny", ovsem kazda chce jinou verzi.

Jako bonus si pak muzes pricist vyvojare, ktery si ani neprectou zmeny mezi verzema. Trebas soudruzi co jakoze semo tamo (ne)vyviji deluge. Ti zvedli pouzivanou verzi torrentni knihovny, ale uz si neprecetli jak se konfiguruje.

---

Dete s tim guuglem dopice!

[MP]

Jo inhouse...

Mame ve firme par inhouse aplikaci starych 10+ let, vyvojari nemaji cas na vyvoj/upgrade do novych verzi serveru, takze...

Inhouse je nejhorsi vec (zejmena pro interni veci).

[karelI]

Připadá mi, že asi mluvíš o něčem jiném než já (použití knihoven ve vyvíjeném programu, který se prodává).

[xkucf03]

Souhlas, psal jsem něco podobného u předchozí zprávičky.

Takova vec v knihovne slouzici k logovani vubec nema co delat nebo alespon ma byt defaultne vypnuta.

Dalo by se to modularizovat. Jádro by bylo minimalistické a ostatní funkcionalita by byla volitelná a vyčleněná do modulů, které by sis nemusel ani instalovat, pokud je nepotřebuješ (výchozí stav).

[j]

Ehm ... kazdej jeden vyvojar si nainstaluje vsechny moduly, protoze proc by se jako mel zaobirat tim, ze mu neco nefunguje, protoze nejakej nema. A uzivatel pak dostane pekne balik se vsim, klidne i se stovkama MB kodu kterej nikdy nepouzije.

A nemuzu v tomhle ohledu vubec rict, ze bych se divil, zazil sem osobne milionkrat ze neco nekde pinda ze tomu "neco" chybi, neumi se to ovsem vyzveknout co. Napsat totiz 10 radku kodu navic aby se prekontrolovalo co ma a co nema a pripadne to vyblilo ... to by byla prace. Typicky z toho totiz vypadne neco na tema "doslo k neosetrene vyjimce ...".

---

Dete s tim guuglem dopice!

[Heron]

Taky jsem to nikdy nepochopil. Pokud chci vypisovat nějaké informace o běhu programu, tak to stačí tisknout na stderr. Vzhledem k tomu, že je to fd stejně jako jakýkoliv jiný soubor, tak to můžu rovnou ukládat i do souboru (pokud chci). Základní logovací infrastruktura je hotová za 10 minut. Čtyři log func: info, warning, error, debug. K tomu třeba jako nástavbu bavičky (kolega je na to ujetej, ten má vlastní logovací knihovnu s barvama).

Co přesně přinese navíc těch 15MB v log4j fakt nevím.

Dnes se systemd stačí všechno zvracet na stdout/err a je to přehledně k dispocici. I bez systemd je to přehledně k disposici.

Pokud bych náhodou potřeboval ty logy odlévat jinam, tak krom řádků print, tam bude ještě sql.execute do DB. Nebo cokoliv. Externí logování vyřešeno za 10minut. Za tu dobu bych nestihl přečíst ani dokumentaci k log4j.

[trekker.dk]

To ale jenom ukládáte informace o běhu programu k případnému pozdějšímu zkoumání, ukáže-li se, že je to potřeba. To je naprosto nedostatečné, úplně tím zanedbáváte ten entrprajs.

[Heron]

Jasně no. A co s tím máme dělat? Tisknout do novin? Ale předpokládám, že jako obvykle nám nesdělíte, co s logy děláte vy. Enterprise neznám (naučte se psát, když poučujete ostatní), používáme Voyager. Asi špatně.

[trekker.dk]

Možná bude lepší, když v klidu posnídáte a pak použijete hlavu.

[xkucf03]

Sice souhlasím, že by se to s knihovnami nemělo přehánět a když už, tak by to nemělo být monstrum, ze kterého využiješ jen pár procent funkcionality a zbytek tě buď brzdí nebo dokonce ohrožuje (viz zrovna tahle chyba)… Ale na druhou stranu to, co píšeš ty, je opačný extrém, který přináší zase jiné problémy.

Pokud to má být nějaká malá utilitka, která sem tam něco vypíše a člověk to buď sleduje v terminálu nebo se občas podívá do logu a těch pár řádků si prostuduje… tak budiž – tohle jde dělat zcela na koleně, jen s tím, že na začátek řádku hodíš datum a čas a za něj nějakou zprávu.

Ale pokud je ta aplikace jen trošku větší a těch logů je víc, tak začneš řešit různé další problémy a implementovat si všechno ručně ti přidělá zbytečně práci – to po použití nějaké knihovny vyloženě volá. Ideálně by ta základní logovací funkcionalita měla být ve standardní knihovně, součást aplikačního serveru atd. Co se týče těch funkcionalit, tak nějak v náhodném pořadí, co mne zrovna napadá:

• chceš mít různé úrovně logování
• chceš mít možnost je v konfiguraci zapínat a vypínat, ideálně i za běhu (představ si hodně zatíženou aplikaci, která by toho v ladícím režimu logovala neskutečně mnoho – tu aplikaci nechceš kvůli tomu restartovat a nechceš v téhle úrovni logovat moc dlouho)
• zrovna třeba u toho log4j je výhoda v tom, že ho spousta adminů umí konfigurovat, už to někdy viděli, a nemusí volat programátora, prostě si to logování zvládnou nastavit sami (což by u toho tvého na míru ušitého logovacího systému nezvládli, protože by ho viděli poprvé v životě – v lepším případě by existovala dokumentace, kterou by si museli nastudovat, a šlo by nastavit, co potřebují)
• ideálně potřebuješ to logování omezit na nějaký modul, třídu, balíček… opět proto, aby toho nebylo zbytečně moc (zpomalení, místo na disku, potenciální únik citlivých dat…)
• není dobré nad tím uvažovat jako nad proudem bajtů, ale jako nad posloupností zpráv – měl bys být schopný spolehlivě rozlišit, kde jedna zpráva začíná a kde končí, neměl by ti to žádný vstup/hodnota rozbít (konce řádků, uvozovky atd.) tzn. nechceš jen blít bajty na STDOUT, ale spíš někam posílat/vkládat objekty/záznamy
• i to sestavení logovací zprávy stojí nějaký výkon (provolání nějakých metod/funkcí, nakopírování hodnot z jedné části paměti do druhé, poslepování řetězců…) a tohle chceš dělat jen tehdy, pokud je příslušná úroveň logování zapnutá; týká se to i obyčejného dosazení hodnot do formátovacího řetězce – tzn. vstupem logovací funkce by neměl být jeden textový řetězec (který bys musel sestavovat vždy), ale vzor zprávy + pole parametrů, které se dosadí/vyhodnotí až v případě potřeby; líné vyhodnocování
• zprávy můžeš chtít posílat i jinam než do souboru – do syslogu, do Kafky, vkládat do databáze, obarvit ANSI sekvencemi a vypsat v terminálu atd. logovací knihovna by k tomuhle měla poskytovat abstraktní rozhraní a mělo by jít volitelně přidávat různé jeho implementace (až je budeš potřebovat, než že tam budou přibalené povinně pro všechny)
• není od věci nějak globálně filtrovat/zahvězdičkovávat citlivé údaje – typicky v případě, že se logují celé požadavky a odpovědi na vstupu/výstupu
• může to být asynchronní, aby to nebrzdilo hlavní vlákno/proces programu
• aplikace dost možná poběží ve více vláknech nebo procesech a ty chceš logovací zprávy poskládat např. do jednoho souboru, aniž by se ti náhodně prolínaly
• můžou tam být různé výhybky, rozdvojky, zálohy… např. když se nepodaří zalogovat do databáze nebo do Kafky, tak se zpráva vloží aspoň do lokálního souboru; když dojde místo na disku, tak se pokusíme logovat někam jinam atd.
• zajištění integrity logů, možná šifrování (volitelně)

Určitě by se z toho neměl stát moloch, v základu by mělo být jen to nejnutnější + abstraktní rozhraní, která může volitelně někdo implementovat a přidat svůj modul. Ale na druhou stranu nedává smysl snažit se celé logování zjednodušit na jednu funkci s jedním textovým parametrem, která před něj akorát přilepí datum a čas a vyplivne to na standardní výstup.

[Heron]

Ano a proto používám knihovní balíček golang.log. Který se umí elegantně nechat rozšířit přes interface{} nebo přes func receiver.

Jinak nemyslím si, že tohle všechno co píšeš, má dělat logger v programu. Ten by měl posílat zprávy do externí komponenty a ta řešit vše, co navrhuješ.

[Heron]

Jinak díky za tyhle dlouhý komentáře. Sice to vypadá, že spolu nesouhlasíme, ale pocházíme z různýho prostředí (asi). Vidím to teď v jobu, hromada linuxáků, ale všichni používají téměř výhradně GUI. Celkem srandovní situace, kdy po našem vývojáři chci udělat rozšíření do CLI utility a on se zeptá k čemu to potřebuju, že je k tomu GUI ekvivalent. Tak mu musím na půl stránky* popsat jak by se to dalo využít lépe a efektivněji. Je to super, on má svůj GUI svět, já naopak CLI. Nakonec teda vzniklo obojí. Když jsem kolegům vysvětlil v čem je to efektivnější, tak jsou rádi a už si navrhují další změny.

Tomu co píšeš moc nerozumím (teď prostě nemám energii a ani chuť nad tím víc přemýšlet). Ale tyhle věci imho patří do externí komponenty. To cos popsal mi spíš vychází jako práce pro message queue.

když se nepodaří zalogovat do databáze nebo do Kafky, tak se zpráva vloží aspoň do lokálního souboru

Jasně, a když se nepodaří zalogovat do souboru, protože ENOSPC tak to pošle poštovního holuba? Někde se to utnout musí. Pro moji práci už dneska bohatě stačí jen stderr a nechat to zpracovat v systemd / journald. Zas tak často do těch logů nelezu.

*) Tohle je taky super. On je v jiné zemi, česky neumí, já neumím jeho řeč a úroveň naší psané angličtiny se liší. Takže jsme si museli vypracovat slovník. Stále to někde dře ale lepší se to. Důležitá je ta iteraci, když něco někdo z nás pochopí špatně, tak se to rychle napraví (kde rychle je v tomto případě v řádech dnů).

[j]

To co pises neni vec aplikace, to je vec logdemona, tudiz to v aplikaci vubec nema co pohledavat.

Uplne stejne totiz muzu mezi ty tvoje pozadavky zaradit, ze se na to da pripojit po siti, a ty logy cist/stahovat ... a voiala, uz z toho mame rovnou server co posloucha na nejakym portu.

Pak by to taky melo kreslit grafy, a malovat obrazky vysmatych rodinek - aby ze to dalo rovnou predkladat managorum.

---

Dete s tim guuglem dopice!

[xkucf03]

To co pises neni vec aplikace, to je vec logdemona, tudiz to v aplikaci vubec nema co pohledavat.

Tak to přeji hodně štěstí při řešení např. těchto problémů mimo aplikaci:

• chceš mít možnost je v konfiguraci zapínat a vypínat, ideálně i za běhu (představ si hodně zatíženou aplikaci, která by toho v ladícím režimu logovala neskutečně mnoho – tu aplikaci nechceš kvůli tomu restartovat a nechceš v téhle úrovni logovat moc dlouho)¹
• není dobré nad tím uvažovat jako nad proudem bajtů, ale jako nad posloupností zpráv – měl bys být schopný spolehlivě rozlišit, kde jedna zpráva začíná a kde končí, neměl by ti to žádný vstup/hodnota rozbít (konce řádků, uvozovky atd.) tzn. nechceš jen blít bajty na STDOUT, ale spíš někam posílat/vkládat objekty/záznamy
• i to sestavení logovací zprávy stojí nějaký výkon (provolání nějakých metod/funkcí, nakopírování hodnot z jedné části paměti do druhé, poslepování řetězců…) a tohle chceš dělat jen tehdy, pokud je příslušná úroveň logování zapnutá; týká se to i obyčejného dosazení hodnot do formátovacího řetězce – tzn. vstupem logovací funkce by neměl být jeden textový řetězec (který bys musel sestavovat vždy), ale vzor zprávy + pole parametrů, které se dosadí/vyhodnotí až v případě potřeby; líné vyhodnocování
• může to být asynchronní, aby to nebrzdilo hlavní vlákno/proces programu
• aplikace dost možná poběží ve více vláknech nebo procesech a ty chceš logovací zprávy poskládat např. do jednoho souboru, aniž by se ti náhodně prolínaly
• …

_{[1] tady sice můžeš říct, že aplikace bude logovat vše a v logovacím démonu si vybereš jen něco a zbytek zahodíš, ale u vytíženějších aplikací nebo u ladících/trasovacích logů to takhle opravdu dělat nejde, protože je to obrovský objem dat a už jen jeho přelití z jednoho procesu do druhého přes STDIO tě stojí zbytečně moc}

[Heron]

chceš mít možnost je v konfiguraci zapínat a vypínat, ideálně i za běhu (představ si hodně zatíženou aplikaci, která by toho v ladícím režimu logovala neskutečně mnoho – tu aplikaci nechceš kvůli tomu restartovat a nechceš v téhle úrovni logovat moc dlouho)1

Tohle umí programy odjakživa, nastavit loglevel a poslat signál pro reload nastavení. Nemusí se to restartovat.

není dobré nad tím uvažovat jako nad proudem bajtů, ale jako nad posloupností zpráv – měl bys být schopný spolehlivě rozlišit, kde jedna zpráva začíná a kde končí, neměl by ti to žádný vstup/hodnota rozbít (konce řádků, uvozovky atd.) tzn. nechceš jen blít bajty na STDOUT, ale spíš někam posílat/vkládat objekty/záznamy

Souhlasím. Přesto přístup co řádek to zpráva funguje na celkem velkou oblast problémů. Proto se to taky už těch několik desítek let používá.

i to sestavení logovací zprávy stojí nějaký výkon (provolání nějakých metod/funkcí, nakopírování hodnot z jedné části paměti do druhé, poslepování řetězců…)

Kolik těch dat chceš logovat? 100GB na zprávu? Dělal jsem benchark spojování řetězců vs. string builder v golangu a nemá smysl to řešit. Všude se píše, používejte SB. No je o pár procent rychlejší, ale když mám spojit 8 stringů, tak to udělám operátorem '+'. Do milionu zpráv je to nerozeznatelné. Ano, možná kdyby někdo spojoval opravdu hodně (tisíce) opravdu velkých stringů, tak SB dává smysl. Jinak si vybrat to, co je nejelegantnější.

může to být asynchronní, aby to nebrzdilo hlavní vlákno/proces programu

No jasně. Jak jinak.

aplikace dost možná poběží ve více vláknech nebo procesech a ty chceš logovací zprávy poskládat např. do jednoho souboru, aniž by se ti náhodně prolínaly

Yop.

[xkucf03]

P.S. Jinak je ale zajímavé, jak široké rozpětí lidí/názorů tady je. Někdo přibalí k aplikaci hromadu knihoven, webový prohlížeč, Python i NodeJS zároveň atd., vyrobí neskutečný bloatware a vůbec mu to není divné nebo si v tom ještě libuje. A pak někdo jiný si představuje, jak by vše vyřešil jednou ručně psanou funkcí, přes STDOUT a ideálně to psal v céčku¹. Ani jeden z těch extrémů není dobrý.

_{[1] to se netýká jen zdejších diskutujících, obecně se stále píše hodně aplikací v céčku, i když by řešená úloha zasluhovala nějaký vyšší programovací jazyk… zřejmě proto, že jsou ti lidé zvyklí psát v céčku, umí ho a mají nějaký mentální blok používat něco vyššího/složitějšího… ale ve výsledku ta komplexita jen vybublá v kódu jejich aplikace, který museli napsat}

[dementni.lojzik]

P.S. Jinak je ale zajímavé, jak široké rozpětí lidí/názorů tady je. Někdo přibalí k aplikaci hromadu knihoven, webový prohlížeč, Python i NodeJS zároveň atd., vyrobí neskutečný bloatware a vůbec mu to není divné nebo si v tom ještě libuje. A pak někdo jiný si představuje, jak by vše vyřešil jednou ručně psanou funkcí, přes STDOUT a ideálně to psal v céčku¹. Ani jeden z těch extrémů není dobrý.

IMHO to neni moc prekvapive, protoze to zavisi asi prevazne na zkusenostech - lidi z obou dvou extremu toho asi bud moc nenaprogramovali nebo se celou dobu pohybuji v nejake specificke oblasti, kde ani jedno nevadi (bloatware nebo logavat uplne vsechno vzdy a pak to pripadne jinde fitlovat). Kazdopadne za me +1 tomu, co pises.

[Heron]

Ani jeden z těch extrémů není dobrý.

Proč si myslíš, že je to extrém? Opravdu denně pracuju se službama, které mají velmi jednoduchý log a některé z nich logují opravdu jen do stderr a stdout. Nebo postaru ještě do souboru a potom se řeší logrotate a jejich reload.

Nginx mám tak nastaven, php-fpm také, svoje programy taky (REST služby - vrstva mezi DB a klientem). Postgresql si píše deníček do vlastních souborů. Moje vlastní programy jsou cli utilitky nad nějakými daty, rest server, pokud existuje, nebo rovnou postgres. Dělá to přesně to co chci.

A pak někdo jiný si představuje

Já si to nepředstavuju, je to moje praxe posledních 15 let.

jak by vše vyřešil jednou ručně psanou funkcí, přes STDOUT a ideálně to psal v céčku

Nevím co tím "vše" myslíš. Ale pro naše účely bohatě stačí stderr/stdout. Klidně napiš z jakého prostředí vycházíš a proč tohle u tebe nestačí. Rád si to přečtu.

Banka? Nutnost auditu? Když jsem spravoval běh služby v certifikovaném prostředí, tak se logy ukládaly do DB, časové razítko, podpis. Table měla na konci provozu 90GB. Za celou dobu provozu jsem jen přidával další disky do LVM. VMko s DB mělo tuším něco jako 600GB.

Podle mého v tom lidi hledají zbytečnou vědu. Já jako admin (jsem věčně se vším nespokojenej) jsem říkal, že by se to mělo optimalizovat. Jednatel šel a koupil tehdy 4x600GB Intel DC SSD, dal to do ESX a vmko mělo luxusní běh na 2TB SSD polem (R10). Vyřešeno. Sice to vyřešil jinak, než jsem chtěl, ale usoudil že HW je levný. Běželo to bez jediného problému po celou dobu konsese / certifikace / provozu (2012-2017). Co víc potřebuješ?

[BoneFlute]

Právě jsem se po letech vrátil k C++ [1]. Protože musím. Do které kategorie patřím? :)

[1]: Nemám C/C++ rád, a od dob Rustu ho považuji za mrtvou věc.

[Xerces]

Ještě že u nás používáme verzi 1.

[xkucf03]

Pokud to nebylo myšleno ironicky: Log4j 1.x had reached end of life

On August 5, 2015 the Logging Services Project Management Committee announced that Log4j 1.x had reached end of life.

A security vulnerability, CVE-2019-17571 has been identified against Log4j 1. Log4j includes a SocketServer that accepts serialized log events and deserializes them without verifying whether the objects are allowed or not. This can provide an attack vector that can be expoited. Since Log4j 1 is no longer maintained this issue will not be fixed. Users are urged to upgrade to Log4j 2.

[Xerces]

Tak jasně že to je děravý, ale naštěstí kolem toho není takový humbuk, takže to nikdo neřeší.

[podlesh]

Hlavně SocketServer nelze použít omylem, nebo dokonce nevědomky. Je to něco co se musí explicitně spustit a nechat poslouchat na nějakém otevřeném portu... a kdo něco takového udělá, tak dostane co si zaslouží

[..$]

Ještě že u nás používáme tracing...