Logování (Logging)

Příklady z praxe

1. 01

   Strukturovaný záznam s korelačním ID

   Webová služba zapisuje každý neúspěšný požadavek jako jeden řádek JSON. Pole requestId se propaguje HTTP hlavičkou do navazujících služeb, takže po incidentu lze v centrálním úložišti vyfiltrovat celou cestu jednoho volání. Bez tohoto pole by se záznamy z pěti služeb daly spojit jen podle času, což při stovkách požadavků za sekundu nefunguje.

   {
     "ts": "2024-03-11T09:14:22.318Z",
     "level": "error",
     "service": "checkout",
     "requestId": "b31f9c2a",
     "userId": 8421,
     "msg": "payment authorization failed",
     "gatewayCode": "insufficient_funds",
     "durationMs": 742
   }

2. 02

   Maskování citlivého pole při zápisu

   Tým zjistil, že se do logu dostávalo celé tělo požadavku včetně hesla. Řešením nebylo logování vypnout, ale doplnit do loggeru seznam polí, která se před zápisem nahradí zástupným textem. Kontext o tom, jaká pole požadavek obsahoval, zůstal zachovaný, hodnoty už se ale nikam neuloží.

   const REDACT = new Set(['password', 'cardNumber', 'authorization']);
   
   function safeBody(body) {
     return Object.fromEntries(
       Object.entries(body).map(([k, v]) =>
         [k, REDACT.has(k) ? '[redacted]' : v])
     );
   }
   
   logger.info({ requestId, body: safeBody(req.body) }, 'incoming request');

Časté omyly

MýtusLogovat se má radši všechno, ať to pak máme.

Ve skutečnostiNadměrné logování zdražuje úložiště, zpomaluje aplikaci a hlavně skrývá důležité záznamy v šumu. Užitečnější je logovat méně událostí, ale s bohatým kontextem a konzistentní strukturou.

MýtusNa logy stačí printf nebo console.log.

Ve skutečnostiPřímý výpis nemá úroveň závažnosti, časové razítko ani strukturu, takže se nedá filtrovat ani centrálně sbírat. Knihovna pro logování navíc řeší asynchronní zápis a maskování citlivých polí.

MýtusLogy jsou interní technická data, GDPR se jich netýká.

Ve skutečnostiJakmile záznam obsahuje IP adresu, e-mail nebo identifikátor uživatele, jde o osobní údaj se vším, co k tomu patří: právním základem, dobou uchování a povinností smazání.

Časté dotazy

Jak dlouho se mají logy uchovávat?

Doba uchování logů se odvozuje od účelu. Pro běžné ladění provozu stačí dny až týdny, protože starší záznamy už nikdo neotevře. Bezpečnostní a auditní logy se typicky drží měsíce až roky, někdy podle regulace daného oboru. Pokud záznamy obsahují osobní údaje, musí být doba uchování stanovená předem a po jejím uplynutí se data skutečně mažou. Praktické řešení je oddělit krátkodobé provozní logy od dlouhodobého auditního záznamu a nastavit jim různé retenční politiky, aby cena za úložiště nerostla bez užitku.

Jaký je rozdíl mezi logováním a monitoringem?

Logování zapisuje jednotlivé události s plným kontextem, monitoring sleduje agregované hodnoty v čase, jako je počet chyb za minutu nebo doba odezvy. Monitoring odhalí, že se něco děje, a spustí výstrahu. Log pak dodá konkrétní detail, který vysvětlí proč. V praxi se obojí staví nad stejnými daty: z logů se dají odvozovat metriky a naopak z metriky se prokliknete na související záznamy. Nasazovat jedno bez druhého vede buď k slepému provozu, nebo k horám dat, které nikdo nečte.

Kdy je vhodné použít strukturované logování místo textového?

Strukturované logování se vyplatí ve chvíli, kdy záznamy čte stroj, ne člověk. To znamená prakticky vždy, když aplikace běží ve více instancích a logy se sbírají centrálně, protože filtrovat podle pojmenovaných polí je nesrovnatelně spolehlivější než regulární výrazy nad volným textem. Textový formát dává smysl při lokálním vývoji, kde je čitelnost v terminálu důležitější než dotazovatelnost. Většina knihoven umí obojí: strukturovaný JSON na produkci a barevný čitelný výstup lokálně, aniž by se měnil kód aplikace.

Může logování zpomalit aplikaci?

Logování zpomalit aplikaci může, a v praxi to není vzácné. Synchronní zápis na disk nebo do sítě blokuje vlákno, které obsluhuje požadavek, a při vysoké zátěži se stane úzkým hrdlem. Rizikové je také skládání zpráv a serializace velkých objektů, které proběhne i tehdy, když se záznam kvůli nastavenému prahu nakonec nezapíše. Řešením je asynchronní zápis přes buffer, kontrola úrovně před sestavením zprávy, vzorkování opakujících se událostí a vyhnutí se logování uvnitř horkých smyček.

Zdroje

1. logging: Logging facility for Python(otevře se v novém okně)Python Software Foundation
2. RFC 5424: The Syslog Protocol(otevře se v novém okně)IETF, 2009
3. Logging Architecture(otevře se v novém okně)Kubernetes
4. OWASP Cheat Sheet Series: Logging(otevře se v novém okně)OWASP

Související pojmy

• MetrikaMetrika je číselně vyjádřená veličina, která popisuje stav, výkon nebo chování systému, produktu, modelu či procesu. V praxi převádí pozorování na srovnatelné hodnoty, například latenci API, konverzní poměr, chybovost klasifikátoru nebo retenci uživatelů, aby bylo možné sledovat změny a rozhodovat podle dat.
• 3-D Secure3-D Secure je protokol, který u online platby kartou ověří, že platí skutečně její držitel, typicky potvrzením v bankovní aplikaci. Při úspěšném ověření se zároveň přenáší odpovědnost za podvodnou transakci z obchodníka na vydavatele karty.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Adresa v pamětiAdresa v paměti je číslo, kterým procesor jednoznačně označuje konkrétní buňku operační paměti, obvykle jeden bajt. Program pomocí adresy říká, odkud má data načíst nebo kam je zapsat. Adresy tvoří souvislý číselný rozsah, jehož velikost určuje šířka adresní sběrnice a architektura, typicky 32 nebo 64 bitů.
• AI agentAI agent je softwarový systém, který pomocí modelu umělé inteligence vnímá zadaný kontext, plánuje další kroky a samostatně volá nástroje nebo služby k dosažení cíle. Na rozdíl od jednorázového promptu udržuje stav úlohy, vyhodnocuje výsledky akcí a může opakovat postup, dokud nesplní zadání nebo nenarazí na limit.
• AndroidAndroid je operační systém postavený nad linuxovým jádrem, který vyvíjí Google a otevřeně uvolňuje jako projekt AOSP. Android pohání převážnou většinu chytrých telefonů, dále tablety, televize, hodinky i palubní systémy aut. Aplikace se pro něj píší hlavně v Kotlinu nebo Javě a distribuují přes Google Play i alternativní obchody.
• APIAPI je smluvené rozhraní, přes které spolu dva programy komunikují, aniž by jeden musel znát vnitřní fungování druhého. Definuje, jaké operace lze volat, jaká data se posílají a co se vrátí zpět.