teď si představ, že ten tvůj jednoduchý json line log někdo čte, je to třeba nějaká java aplikace (ELK stack např.) a útočník tam schválně pošle takový vstup, který u dané aplikace vyvolá chybu a ta tedy zaloguje logicky vstup a chybu (ať už to jsou nevalidní znaky, syntax error a problémy s escapováním nebo třeba číselné údaje v jsonu s šíleně velkým počtem míst, které java neumí použít).
Problém není jen právě na vstupu od uživatele z webu, ale právě v celém životním cyklu daných dat a ten může být nedozírný. K logům se můžeš dostat po X letech, když tam potřebuješ něco důležitého najít a na pomoc použiješ třeba PrestoDB jako chytrý filtrovací engine (ano, také používá log4j).
Otázku proč potřebuji intepretovat cokoliv v logovaných dat nechám bez odpovědi, netuším jak někoho mohlo napadnou, že to je dobrý nápad cokoliv parsovat z neznámého vstupu.
Vy chcete logovat do souboru jako LNJSON, někdo chce logovat text na standardní výstup, někdo do syslogu, někdo do Logstashe, někdo e-mailem… Je dobré k logovnaým datům přidávat kontext – čas, server, uživatele, IP adresu klienta, software klienta, identifikátor session… Je dobré rozlišovat informativní logy a logování chybových zpráv, občas se hodí pro něco zapnout podrobnější logování. Můžete si to všechno napsat sám, ale nejspíš tam nasekáte víc chyb, než když je na to specializovaná knihovna, která se používá ve více projektech.
třeba proč potřebuju, aby se vynechávky interpretovaly i v zalogovaných datech?
To by asi zajímalo víc lidí. Můj soukromý tip je, že je to důsledek toho, že si někdo myslel, že logovací framework má mít spoustu cool fíčur, a neuvědomil si, že logovací framework musí být hlavně velmi defenzivní, protože i až nastane konec světa, pořád budou přeživší zajímat logy, aby se z toho poučili.