Žádný provozně složitější systém neběží bezchybně — integrace vypadávají, uživatelé odesílají špatně vyplněné formuláře, platební brány občas vracejí neočekávané chybové kódy. Modul /log slouží k tomu, aby tyto události nezmizely v čase, ale zůstaly dohledatelné, agregované a doplněné o kontext, který umožní problém vyřešit. Administrátor zde rychle zjistí, kdy a kde k chybě došlo, jak často se opakuje a co přesně ji vyvolalo. Modul je určen zejména technickým pracovníkům a osobám zodpovědným za provoz, ale díky AI vysvětlení je srozumitelný i pro netechnické uživatele.
Přehled logů
Hlavní tabulka zobrazuje seznam zaznamenaných událostí seřazený od nejnovějších. Klíčovou vlastností je, že každý řádek nepředstavuje jediný incident, ale fingerprint — jedinečný otisk typu události. Pokud se stejná chyba objevila stokrát, v seznamu zabere jediný řádek s počítadlem výskytů, nikoli sto řádků. Díky tomu zůstává přehled použitelný i v situacích, kdy systém generuje tisíce chybových záznamů denně.
Jednotlivé sloupce sdělují:
- Čas posledního výskytu — kdy k události došlo naposledy; u opakujících se chyb jde o aktuální čas.
- Level (závažnost) — barevný štítek označující důležitost záznamu.
- Code — interní kód události, který umožňuje přiřadit standardizovaný popis.
- Zpráva — lidsky čitelný popis události.
- Počet výskytů za 30 dní — kolikrát se tato událost objevila během posledního měsíce.
- Sparkline — miniaturní graf průběhu výskytů v čase, pomáhá odlišit stálý problém od nové regrese.
- Počet událostí celkem — kumulativní součet od prvního zaznamenaného výskytu.
- Komponenta — část systému, z níž událost pochází (například
emailer,payment,api,frontend).
Tabulka se automaticky obnovuje každých 5 sekund, aby administrátor viděl aktuální stav bez ručního obnovování.
ℹ️ Řádky tabulky představují fingerprint události, ne jednotlivý výskyt. Shodné chyby se agregují do jednoho záznamu s počítadlem, takže seznam zůstává přehledný i při stovkách výskytů stejného problému.
Úrovně závažnosti
Každý záznam má přiřazenou úroveň, která určuje barvu štítku a signalizuje, jak rychle je třeba reagovat. Info (modrá) je běžná informativní zpráva o standardní provozní události. Success (zelená) oznamuje úspěšné dokončení významné operace — typicky se používá k potvrzení, že dlouhá dávková úloha proběhla. Warning (oranžová) je upozornění, které nemusí vyžadovat okamžitou reakci, ale stojí za pozornost. Error (červená) je chyba, která zabránila dokončení operace, a critical (tmavě červená) označuje kritický problém vyžadující okamžitou pozornost — typicky výpadek integrace nebo zabezpečení.
⚠️ Události úrovně critical a chyby s anomálním vzorcem výskytů aktivují e-mailovou notifikaci správci organizace. Díky tomu závažný problém neunikne, i když se právě nikdo na log nedívá.
Agregace výskytů
Bez agregace by byl log při sebemenší systémové chybě zaplavený duplicitními záznamy. Systém proto každou příchozí zprávu nejprve normalizuje — odstraní proměnné části jako jsou ID, časová razítka a náhodné identifikátory — a z výsledku spočítá fingerprint (otisk). Všechny záznamy se stejným fingerprintem se v přehledu zobrazí jako jediný řádek, u kterého se inkrementuje počítadlo výskytů. V detailu pak zůstávají jednotlivé incidenty dohledatelné se svými specifickými daty.
Sparkline graf u každého řádku vizualizuje, jak se počet výskytů vyvíjel během posledních 30 dní. Administrátor tak na první pohled rozliší tři typické vzorce: stabilní problém má plochý graf s konstantními výskyty (je to chyba, kterou někdo zřejmě ignoruje nebo není kritická), nová chyba má vysoký peak v posledních dnech (pravděpodobně nasazená regrese) a odeznělý problém byl v minulosti aktivní, ale poslední dny jsou prázdné (chyba byla pravděpodobně opravena).
💡 Kliknutím na sparkline se v detailu otevře plnohodnotný graf s časovou osou a přesnými hodnotami — užitečné pro přesné dohledání, kdy se regrese poprvé objevila.
Detail logu
Kliknutím na ikonu oka v řádku se otevře detail události. Hlavička obsahuje barevnou ikonu odpovídající úrovni a název, následovaná metadaty (komponenta, úroveň, ID, časy prvního a posledního výskytu a celkový počet) a rozšířeným sparkline grafem. Pokud byla událost vyvolána HTTP požadavkem, zobrazí se i URL, IP adresa a User-Agent, které pomáhají identifikovat prostředí uživatele.
Detail je dále rozdělen do záložek, které oddělují různé typy kontextu. Stack trace ukazuje volání, která vedla ke vzniku chyby, a je primárním nástrojem pro technický debug. Request / response data obsahují to, co se přenášelo mezi prohlížečem a serverem v okamžiku události — často odhalí, že problém způsobilo neočekávané tělo požadavku. Kontext doplňuje doprovodné informace jako ID uživatele, ID objednávky nebo kalendáře, které pomáhají problém lokalizovat v rámci konkrétního obchodního případu. AI vysvětlení pak technickou chybu přeloží do lidské řeči.
💡 AI vysvětlení je zvlášť užitečné pro netechnické uživatele, kteří potřebují rychle rozhodnout, zda si problém mají vyřešit sami, nebo ho eskalovat na technickou podporu. Popíše, co se pravděpodobně stalo, a navrhne konkrétní kroky k nápravě, to vše v jazyce uživatele.
Jak se chyby zařazují
Každý nově příchozí záznam prochází několika automatickými rozhodnutími. Komponenta se určí podle místa vzniku — chyba z e-mailového odesílače dostane emailer, chyba z platební brány payment, chyba z klientské aplikace frontend. Organizace, ke které se záznam přiřazuje, je buď ta, v jejímž kontextu chyba vznikla, nebo u systémových chyb vnitřní technická organizace. Úroveň závažnosti primárně určuje zdroj, ale systém ji může automaticky zvýšit u speciálních případů — zprávy obsahující „timeout" nebo „unauthorized" se typicky zvednou výš, protože indikují infrastrukturní nebo bezpečnostní problém. Fingerprint pak z normalizované zprávy vypočte klíč pro agregaci.
Ochranné mechanismy
Logovací subsystém je sám o sobě kritickou součástí a nemůže si dovolit zahltit buď sám sebe, nebo e-mailovou schránku administrátora. Proto jsou v něm zabudovány tři vrstvy ochrany. Rate limiting omezuje celkový počet logů za jednotku času; pokud dojde k jeho překročení (typicky při rozsáhlé poruše, kdy systém generuje tisíce záznamů za minutu), další záznamy se v daném intervalu neukládají a vznikne jeden souhrnný záznam. Debounce pro opakované hlášení z frontendu zajistí, že cyklická chyba v prohlížeči neodešle na server tisíc identických zpráv, ale jen jednu reprezentativní. Rate limit notifikací pak u e-mailových upozornění drží hranici jedné anomálie za hodinu na organizaci, aby mailbox administrátora nebyl zahlcen — předmět takové notifikace obsahuje značku [ANOMALY] pro snadnou orientaci.
⚠️ Notifikace může být potlačena, pokud systém vyhodnotí, že by odeslání překročilo povolený limit. Samotný log je však vždy zaznamenán a administrátor ho v přehledu uvidí — pouze mu o něm nepřijde e-mail.
Code a definice zpráv
Některé události mají v systému předdefinovaný Code — krátký identifikátor jako ORDER_CREATED nebo PAYMENT_FAILED. Tyto kódy mají ve slovníku systému předem připravený standardizovaný titulek (zobrazuje se nad textem zprávy) a popis (vysvětluje, co daný kód znamená a jak na něj reagovat). Definice jsou sdílené napříč organizacemi, takže stejná událost se všude vykládá konzistentně a týmy si mohou mezi sebou vyměňovat informace odkazem na kód.
ℹ️ Pokud kód nemá definici, v detailu se zobrazí pouze surový text zprávy. Nové kódy se do slovníku doplňují centrálně administrátorem systému, jak se objevují nové typy událostí.
Zápis z frontendu
Klientská aplikace v prohlížeči může do logu odesílat vlastní záznamy — typicky zachycené JavaScript výjimky nebo anomálie, které server nevidí. Tyto záznamy jsou označeny komponentou frontend, standardně podléhají debounce (aby se neopakovaly příliš často při cyklické chybě) a úroveň si určuje frontend sám — u zachycených výjimek typicky error. Díky tomu má administrátor viditelnost nejen do serverové části, ale i do problémů, které se odehrávají v prohlížečích zákazníků.
Kontext a životní cyklus
Logy jsou vázány na organizaci — uživatel vidí pouze události té organizace, do které je přihlášen. Kritické chyby se archivují dlouhodobě, zatímco informativní události se po určité době mažou, aby zbytečně nerostl objem dat. Součástí denního reportu pro administrátora je i souhrn nejčastějších logů za posledních 24 hodin, takže i bez aktivního otevírání modulu má přehled o tom, co se v systému děje.
💡 Pravidelný pohled do logu alespoň jednou týdně je nejlepší prevencí před nečekanými výpadky. Mnoho problémů se totiž projevuje nejprve jako série varování a teprve poté jako skutečná chyba — kdo si varování všimne včas, ušetří si řešení incidentu o víkendu.