Structured Logging — podstata, formáty dat a princip práce v aplikacích

Co je Structured Logging

Structured Logging je metoda zápisu logů, při které každá zpráva obsahuje pojmenovaná pole s typovanými hodnotami. Místo řetězce jako User 42 logged in from device ABC vypadá strukturovaný log jako sada polí: user_id=42, event=login, device_id=ABC, timestamp=2026-07-04T10:30:00Z.

Hlavní výhoda strukturovaných logů oproti textovým — možnost programového zpracování. Parsování textových logů vyžaduje regulární výrazy a předpoklady o formátu řetězce. Strukturované logy se parsují beze ztrát: každé pole má známý typ a název, což umožňuje stavbu dotazů úrovně najdi všechny chyby autorizace za poslední hodinu pro uživatele 42 bez dalšího zpracování.

Podle údajů Honeycomb.io (2023), týmy používající structured logging v produkci detekují incidenty v průměru 4krát rychleji ve srovnání s týmy spoléhajícími se na textové logy a grep.

Formáty strukturovaných logů

Structured Logging podporuje několik formátů serializace. Výběr formátu závisí na infrastruktuře: JSON je vhodný pro integraci s Elasticsearch a cloudovými systémy, logfmt — pro konzolové prohlížení přes tail a grep, Protocol Buffers — pro vysoce výkonné systémy s omezením šířky pásma.

JSON — univerzální formát

JSON je nejrozšířenější formát pro strukturované logy. Je nativně podporován všemi systémy sběru: Logstash, Fluentd, Amazon CloudWatch, Google Cloud Logging. JSON logy se snadno čtou člověkem a parsují se jakýmkoli programovacím jazykem bez dalších knihoven. Hlavní nevýhoda — redundance: každý pár klíč-hodnota vyžaduje uvozovky a dvojtečky, což zvyšuje objem ukládaných dat o 30–50 % oproti logfmt.

Logfmt — kompaktní formát

Logfmt byl vyvinut v Heroku pro konzolovou viditelnost. Je kompaktnější než JSON, zachovává čitelnost pro člověka a snadno se ořezává přes cut a awk. Příklad: ts=2026-07-04T10:30:00Z level=error module=api status=500. Logfmt nevyžaduje escapování většiny znaků a dobře se hodí pro stdout-logování v kontejnerech.

Proč je Structured Logging potřebný v mobilním vývoji

V mobilních aplikacích Structured Logging řeší tři klíčové úkoly: hledání příčin pádů bez reprodukce na zařízení, sledování uživatelských relací a analýzu výkonu podle verzí aplikace.

Textové logy na mobilních zařízeních jsou téměř k ničemu — vývojář nemůže grepovat logy na zařízení uživatele. Strukturované logy se odesílají do cloudových systémů (Firebase, Sentry, Datadog) a tam se indexují. Lze sestavit dotaz: zobraz všechny crash na iOS 17.4, verze aplikace 3.2, v modulu checkouts — a získat přesný výběr během několika sekund.

Podle údajů Sentry (2024), aplikace používající structured breadcrumbs mají o 60 % více kontextu v každém crash reportu ve srovnání s aplikacemi logujícími pouze text chyby. To přímo ovlivňuje rychlost opravy chyby.

Nástroje pro sběr a analýzu

ELK Stack — Elasticsearch, Logstash, Kibana — zůstává standardní infrastrukturou pro práci se strukturovanými logy. Logstash přijímá logy v JSON, transformuje je a odesílá do Elasticsearch k indexaci, Kibana poskytuje vizuální rozhraní pro dotazy a dashboardy.

Pro mobilní aplikace jsou populární cloudová řešení: Firebase Crashlytics s vlastními logy, Sentry s breadcrumbs, Datadog s APM sledováním. Přijímají strukturované logy přímo z mobilního SDK a nevyžadují nasazení vlastního backendu. Firebase poskytuje bezplatný balíček pro crash reporty, Sentry přidává distributed tracing a Datadog se integruje s APM pro současné sledování výkonu požadavků na klientovi a serveru.

Grafana Loki — alternativa k Elasticsearch, optimalizovaná pro logy. Loki standardně neindexuje obsah zpráv, ale používá štítky (labels) pro filtrování. To je výrazně levnější na úložiště a rychlejší při dotazech podle pevné sady polí.

// Strukturované logování přes Swift Logger do JSON
struct StructuredLog {
    let event: String
    let attributes: [String: Any]
    let level: String

    func serialize() -> String {
        var base = "event=\(event) level=\(level)"
        for (key, value) in attributes {
            base += " \(key)=\(value)"
        }
        return base
    }
}

Nejlepší postupy Structured Logging

První pravidlo strukturovaného logování: každá zpráva musí obsahovat identifikátor požadavku nebo relace. Bez kontextu je jednotlivý log k ničemu — nelze pochopit, ke kterému uživateli nebo požadavku patří. Přidávejte correlation ID na začátku relace a přenášejte ho přes všechny vrstvy aplikace.

Druhé pravidlo: typizace polí. Číselná pole (duration_ms, status_code, retry_count) musí být předávána jako čísla, nikoli jako řetězce. Elasticsearch a podobné systémy indexují čísla a řetězce odlišně: na čísla lze aplikovat agregace (průměr, medián, percentil), na řetězce — fulltextové vyhledávání. Falešná typizace znemožňuje stavbu analytických dashboardů.

Třetí pravidlo: vyhýbejte se vnořeným objektům. JSON logy s hloubkou vnoření větší než 2 úrovně se obtížně filtrují a vizualizují. Místo {"user": {"name": "Alice", "role": "admin"}} používejte ploché klíče: user_name=Alice user_role=admin.

// Strukturované logování na Androidu přes Timber + logfmt
class StructuredTree : Timber.Tree() {
    override fun log(priority: Int, tag: String?,
                  message: String?, t: Throwable?) {
        val level = priorityToLevel(priority)
        val logfmt = "level=$level tag=$tag message=$message"
        sendToRemote(logfmt)
    }
}

Která pole jsou povinná

Minimální sada polí pro každou strukturovanou zprávu: timestamp v ISO 8601, level (debug/info/warn/error/fatal), logger (název modulu nebo třídy), message (člověkem čitelný popis události). Doplňkově: correlation_id, user_id (je-li znám), version (verze aplikace), platform (iOS/Android), environment (dev/staging/prod).

Bez correlation_id se strukturované logy mění v soubor nesourodých záznamů, které nelze spojit do jednoho uživatelského scénáře. Generujte UUID při každém spuštění aplikace a přidávejte ho do všech logů relace. V praxi musí být correlation ID přenášen přes všechny vrstvy: od UI událostí po síťové požadavky a úkoly na pozadí — jinak část logů zůstane bez kontextu a nebude se účastnit analýzy. Při end-to-end sledování umožňuje jeden UUID shromáždit úplný obrázek uživatelské cesty.

Příklady strukturovaného logování v Swift a Kotlin

Na iOS lze strukturované logování implementovat přes obálku nad os_log, která serializuje pole do formátu logfmt. Na Android — přes Timber s vlastním Tree, který převádí zprávy do JSON nebo logfmt před odesláním na server.

import OSLog

struct StructuredLogger {
    let subsystem: String
    let category: String

    func log(level: OSLogType,
              event: String,
              context: [String: Any]) {
        let oslogger = Logger(
            subsystem: subsystem,
            category: category
        )
        let fields = context.map {
            "\($0.key)=\($0.value)"
        }.joined(separator: " ")
        oslogger.log(level: level,
                     "\(event) \(fields)")
    }
}

Structured vs Unstructured: srovnání přístupů

Výběr mezi strukturovanými a textovými logy závisí na fázi projektu. V raných fázích vývoje jsou textové logy jednodušší a rychlejší — vývojář píše zprávu přímo bez dalších obálek. Jakmile ale projekt překročí hranice jednoho týmu nebo jednoho serveru, strukturované logy se stávají povinnými.