Systémové logy

Žádný provozně složitý systém neběží bezchybně — integrace selhávají, uživatelé odesílají chybně vyplněné formuláře, platební brány někdy vrací nečekané chybové kódy. Modul /log slouží k tomu, aby tyto události v čase nemizely, 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 došlo k chybě, jak často se opakuje a co přesně ji spustilo. Modul je primárně určen pro technický personál a osoby zodpovědné za provoz, ale díky AI vysvětlením je srozumitelný i netechnickým uživatelům.

Přehled logů

Hlavní tabulka zobrazuje seznam zaznamenaných událostí, seřazených od nejnovějších. Klíčovou vlastností je, že každý řádek nepředstavuje jednotlivý incident, ale otisky — unikátní otisk typu události. Pokud se tatáž chyba objevila stokrát, zabere v seznamu jeden řádek s počítadlem výskytů, nikoliv sto řádků. To udržuje přehled použitelný i v situacích, kdy systém denně generuje tisíce chybových záznamů. Jednotlivé sloupce ukazují:

• Čas posledního výskytu — kdy se událost naposledy vyskytla; u opakovaných chyb jde o aktuální čas.
• Úroveň (závažnost) — barevný štítek signalizující důležitost záznamu.
• Kód — interní kód události, ke kterému lze 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 za poslední měsíc.
• Sparkline — miniaturní graf průběhu výskytů v čase, pomáhající odlišit přetrvávající problém od nové regrese.
• Celkový počet událostí — kumulativní součet od prvního zaznamenaného výskytu.
• Komponenta — část systému, ze které událost pochází (např. emailer, payment, api, frontend). Tabulka se automaticky obnovuje každých 5 vteřin, aby administrátor viděl aktuální stav bez ručního refreshování.

ℹ️ Řádky tabulky reprezentují otisky událostí, nikoliv jednotlivé výskyty. Identické chyby jsou agregovány 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ému záznamu je přiřazena úroveň, která určuje barvu štítku a signalizuje, jak rychle je potřeba reagovat. Info (modrá) je běžná informační zpráva o standardní provozní události. Success (zelená) indikuje úspěšné dokončení významné operace — typicky slouží k potvrzení, že se spustil dlouhý dávkový proces. Warning (oranžová) je upozornění, které sice nevyžaduje okamžitou akci, ale stojí za povšimnutí. Error (červená) je chyba, která zabránila dokončení operace, a critical (tmavě červená) značí kritický problém vyžadující okamžitou pozornost — typicky výpadek integrace nebo zabezpečení.

⚠️ Události na úrovni critical a chyby s anomálním vzorcem výskytu aktivují emailové upozornění administrátorovi organizace. To zajišťuje, že vážný problém nebude přehlédnut, i když se nikdo zrovna na log nedívá.

Agregace výskytů

Bez agregace by se log při sebemenší systémové chybě zaplavil duplicitními záznamy. Systém proto každou příchozí zprávu nejprve normalizuje — odstraňuje proměnné části, jako jsou ID, časové značky a náhodné identifikátory — a z výsledku spočítá otisky. Všechny záznamy se stejným otiskem se v přehledu zobrazí jako jeden řádek, u kterého se inkrementuje počítadlo výskytů. V detailu zůstávají jednotlivé incidenty dohledatelné s jejich specifickými daty. Graf sparkline u každého řádku vizualizuje, jak se počet výskytů vyvíjel za 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 (jde o chybu, kterou někdo zjevně ignoruje nebo není kritická), nová chyba má vysoký vrchol v posledních dnech (pravděpodobně nasazená regrese) a vyřešený problém byl aktivní v minulosti, ale poslední dny jsou prázdné (chyba byla pravděpodobně opravena).

💡 Kliknutí na sparkline otevře v detailu plnohodnotný graf s časovou osou a přesnými hodnotami — užitečné pro přesné určení, kdy se regrese poprvé objevila.

Detail logu

Kliknutím na ikonu oka v řádku se otevře detail události. Záhlaví obsahuje barevnou ikonu odpovídající úrovni a název, za kterým následují metadata (komponenta, úroveň, ID, časy prvního a posledního výskytu a celkový počet) a rozšířený graf sparkline. Pokud byla událost spuštěna HTTP požadavkem, zobrazí se také URL, IP adresa a User-Agent, které pomáhají identifikovat prostředí uživatele. Detail je dále rozdělen na záložky, které oddělují různé typy kontextu. Stack trace ukazuje volání, která vedla k chybě, a je primárním nástrojem pro technické ladění. Request / response data obsahují to, co bylo přenášeno mezi prohlížečem a serverem v okamžiku události — často odhalí, že problém byl způsoben neočekávaným tělem požadavku. Context poskytuje doprovodné informace, jako je ID uživatele, ID objednávky nebo ID kalendáře, které pomáhají lokalizovat problém v rámci konkrétního obchodního případu. AI explanation pak překládá technickou chybu do lidského jazyka.

💡 AI vysvětlení je zvláště užitečné pro netechnické uživatele, kteří potřebují rychle rozhodnout, zda problém vyřeší sami, nebo jej eskalují na technickou podporu. Popisuje, co se pravděpodobně stalo, a navrhuje konkrétní nápravné kroky, vše v jazyce uživatele.

Jak jsou chyby kategorizovány

Každý nově příchozí záznam prochází několika automatickými rozhodnutími. Komponenta je určena jeho původem — chyba z odesílače e-mailů dostane emailer, chyba z platební brány payment, chyba z klientské aplikace frontend. Organizace, ke které je záznam přiřazen, je buď ta, v jejímž kontextu chyba vznikla, nebo pro systémové chyby interní technická organizace. Úroveň závažnosti je primárně určena zdrojem, ale systém ji může automaticky zvýšit pro speciální případy — zprávy obsahující „timeout“ nebo „unauthorized“ typicky stoupají výše, protože indikují infrastrukturní nebo bezpečnostní problém. Otisky pak vypočítají klíč pro agregaci z normalizované zprávy.

Ochranné mechanismy

Subsystém logování je sám o sobě kritickou komponentou a nemůže si dovolit přetížit sebe ani 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 je překročen (typicky při rozsáhlém výpadku, kdy systém generuje tisíce záznamů za minutu), další záznamy se v daném intervalu neuloží a vytvoří se jeden souhrnný záznam. Debounce pro opakované frontendové reportování zajišťuje, že cyklická chyba prohlížeče nepošle tisíc identických zpráv na server, ale jen jednu reprezentativní. Rate limit pro notifikace pak udržuje limit jedné anomálie za hodinu na organizaci pro emailová upozornění, aby schránka administrátora nebyla zahlcena — předmět takového upozornění obsahuje tag [ANOMALY] pro snadnou orientaci.

⚠️ Notifikace může být potlačena, pokud systém vyhodnotí, že její odeslání by překročilo povolený limit. Samotný log je však vždy zaznamenán a administrátor jej uvidí v přehledu — jen o něm nedostane email.

Definice kódů a zpráv

Některé události mají v systému předdefinovaný Kód — krátký identifikátor jako ORDER_CREATED nebo PAYMENT_FAILED. Tyto kódy mají standardizovaný název (zobrazený nad textem zprávy) a popis (vysvětlující, co kód znamená a jak na něj reagovat) předpřipravený ve slovníku systému. Definice jsou sdíleny napříč organizacemi, takže stejná událost je všude interpretována konzistentně a týmy si mohou vyměňovat informace odkazem na kód.

ℹ️ Pokud kód nemá definici, v detailu se zobrazí pouze syrový text zprávy. Nové kódy jsou do slovníku přidávány centrálně systémovým administrátorem s příchodem nových typů událostí.

Logování z frontendu

Klientská aplikace v prohlížeči může posílat své vlastní záznamy do logu — typicky zachycené JavaScriptové výjimky nebo anomálie, které server nevidí. Tyto záznamy jsou označeny komponentou frontend, podléhají ve výchozím nastavení debounce (aby se zabránilo příliš častému opakování v případě cyklické chyby) a úroveň si frontend určuje sám — typicky error pro zachycené výjimky. To dává administrátorovi přehled nejen o serverové straně, ale i o problémech vyskytujících se v prohlížečích zákazníků.

Kontext a životní cyklus

Logy jsou vázány na organizaci — uživatel vidí události pouze z organizace, do které je přihlášen. Kritické chyby jsou dlouhodobě archivovány, zatímco informační události jsou po určité době mazány, aby se zabránilo zbytečnému růstu objemu dat. Denní report pro administrátora obsahuje také 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á kontrola logu alespoň jednou týdně je nejlepší prevencí proti nečekaným výpadkům. Mnoho problémů se nejprve projevuje jako série varování a teprve poté jako skutečná chyba — kdo si včas všimne varování, ušetří si řešení incidentu o víkendu.