Ověřené postupy pro logování

[hknmtt]

Ako pristupujete k logovaniu - mate nejaku zavedenu prax kedy vobec vytvorit log a podla coho sa rozhodnut o aku uroven ide (info, notice, warning, error, fatal, debug..)? Kedy je toho malo, kedy vela... skratka zavedene postupy ktore ste si rokmi praxe vytvorili.

[Reklama]

[Tomas-T]

Záleží na aplikaci, ale provozní log by měl být optimálně dostatečně podrobný, aby, když se zákazník zeptá, co se v nějakém čase, nebo s nějakou položkou dělo, tak bych mu měl být z logu schopný zpětně zrekonstruovat kdo, kdy a co provedl a jaké důsledky to mělo pro data. Upravoval jsem takhle dodatečně jednu aplikaci, aby zalogovala jakoukoliv aktivitu uživatele vedoucí ke změně dat - takže v logu je "uživatel xy v čase ab stiskl pro položku n tlačítko SCHVÁLIT" a k tomu jakýkoliv zápis do databáze včetně zapisovaných dat.
Chybový log (pokud je oddělený) by pak měl zaznamenávat jakoukoliv neplánovanou výjimku v aplikaci (ať už lokálně ošetřenou nebo odchycenou až někde na nejvyšší úrovni) + případné stavy, které sice nevyvolaly výjimku, ale z hlediska logiky k nim nemělo dojít a jsou chybou.
Užitečný je i komunikační log, pokud aplikace rozesílá nějaké zprávy uživatelům, nebo externím systémům. Zd bude obsahovat i obsah každé zprávy je na zvážení.
Nedávno jsme na přání zákazníka do několika aplikací doplňovali auditní log, pro sledování přístupu k citlivým informacím - loguje se každé zobrazení jakýchkoliv osobních informací o lidech, které by mohlo spadat pod GDPR - komu, o kom a co se zobrazilo (nelogují se samotná konkrétní data, ale třeba informace, že se někomu zobrazil telefon a  email konkrétních lidí).

[Zopper]

Souhlas s tím, co napsal Tomas-T.

U logů platí “raději více, než méně.” Jen v případě dat, která by mohla i z dálky smrdět osobním údajem, je třeba hodnoty obfuskovat ještě před zápisem. A vyplatí se mít nástroje na filtrování a prohledávání. Třeba ten Elastic + Kibana, na které tady na Rootu bývá reklama.

Jestli logy dělit do tříd podle závažnosti, a do kolika, to je už případ od případu. Detekujete ve watchdogu chyby podle objevení se libovolného error logu, nebo podle konkrétní zprávy, nebo si aplikace hlídá zdraví sama a watchdog se jen ptá nějakého health API? Kolik lidí na tom pracuje, dokážete vůbec uhlídat konzistenci těch úrovní?

[hknmtt]

...

To skor popisujes ohybanie existujucej aplikacie na kvazi event-sourcing, to nie je logovanie.

[hknmtt]

U logů platí “raději více, než méně.”

No len potom vznika problem ze clovek je zahlteny tonami "logovacieho odpadu", rozumej 99.99999999% zbitocnych dat, na ktory potom musi vytvorit samostatnu infrastrukturu aby sa dali vobec nejak pouzit a prilezitostne z nich ziskat nejake informacie.

[Reklama]

[kanoe22]

U logů platí “raději více, než méně.”

No len potom vznika problem ze clovek je zahlteny tonami "logovacieho odpadu", rozumej 99.99999999% zbitocnych dat, na ktory potom musi vytvorit samostatnu infrastrukturu aby sa dali vobec nejak pouzit a prilezitostne z nich ziskat nejake informacie.

Zas take extremy to nebyvaju a ak ano tak si treba upravit logovanie a nelogovat kazdu debug spravu ale trebars od info a vyssie.

Apropo, logovanie je o tom, ze tam proste je viac dat ako realne treba. Pretoze ked pride na lamanie chleba a treba pomocou logov nieco zistit, a ono tam neni k tomu dostatok informacii, tak ako sa to vyriesi? Pusti sa system znovu s agresivnejsim logovanim a bude sa dufat ze znovu nastane ten isty problem?
Dalsi problem s mnozstvom logov je ten, ze ked treba v nich najst problem, dopredu nikdy neviete co budu uzitocne data a co nie, cize davat logovat len nejake kriticke chyby je k nicomu, pretoze clovek nevie co tomu predchadzalo ked v logu uvidi jeden riadok, .eblo to sefe.

[hknmtt]

Zas take extremy to nebyvaju a ak ano tak si treba upravit logovanie a nelogovat kazdu debug spravu ale trebars od info a vyssie.

No ved prave o tom je tato tema.

[RDa]

Ako pristupujete k logovaniu - mate nejaku zavedenu prax kedy vobec vytvorit log a podla coho sa rozhodnut o aku uroven ide (info, notice, warning, error, fatal, debug..)? Kedy je toho malo, kedy vela... skratka zavedene postupy ktore ste si rokmi praxe vytvorili.

Tak treba v OS pro MCU mam drivery periferii psany tak, ze je tam #define neco_DEBUG tvoreno bitovou maskou z ruznych urovni ukecanosti - at uz komunikace s periferii, uroven registru, uroven operaci ktere vola "uzivatel" tohoto driveru. Takze podle toho co ladim, zapnu patricne bity, rekompiluji a pustim.

U zcela jineho druhu aplikace (skripty) loguji vsechny vstupy a vystupy a kroky z decision tree ktere vedli k danemu chovani. Jedna se tam spis o magii, aby se spravne spojili data a nezustalo nic nezatrideneho/nesparovaneho, takze v pripade pocitu selhani detekovaneho samotnou aplikaci se vytvari druhej soubor od mista kde se to uz podelalo (usetri to hledani klicoveho slova, a je taky videt ze beh neprobehl bezchybne)

A u tretiho druhu mam na vsech objektech export/dump do XML, takze behem vyvoje sleduji "vnitrni stav" spis takhle, nez bych to dohledaval v debuggeru (ten ostatne nepouzivam nikde)