Remote Logging — co to je, nástroje sběru a způsoby vzdálené analýzy logů

Co je Remote Logging

Remote Logging je proces sběru logů ze vzdálených zařízení a jejich odesílání na centrální server pro analýzu. V kontextu mobilního vývoje zahrnuje remote logging nejen crash reporty (crash reporting), ale také vlastní události, breadcrumbs, metriky výkonu a uživatelské scénáře.

Hlavní rozdíl mezi remote logging a crash reporting je proaktivita. Crash reporting shromažďuje pouze data o pádech aplikace, které již nastaly. Remote logging shromažďuje sekvenci událostí před pádem: jaké obrazovky uživatel otevíral, jaké požadavky odesílal, jaká data zadával. To umožňuje reprodukovat scénář chyby bez komunikace s uživatelem.

Apple poskytuje vestavěný mechanismus vzdáleného sběru logů přes .logarchive, ale pro produkční aplikace se téměř vždy používají služby třetích stran. Android SDK obsahuje Logcat, který je vzdáleně přístupný přes ADB, ale ne pro zařízení koncových uživatelů bez režimu ladění.

Architektura vzdáleného sběru logů

Architektura remote logging se skládá ze tří komponent: klientského SDK na zařízení, které shromažďuje a ukládá do vyrovnávací paměti logy, protokolu pro přenos dat a serveru pro ukládání a vizualizaci.

Klientské SDK ukládá do bufferu logy v paměti RAM a periodicky je odesílá na server v dávkách (batches). Pokud je zařízení offline, logy jsou uloženy v lokálním souboru a odeslány při příštím připojení k síti. Velikost bufferu a interval odesílání jsou konfigurovatelné: typické hodnoty jsou 50 událostí nebo 30 sekund.

Transportní protokoly

HTTPS REST — nejrozšířenější protokol pro remote logging. SDK serializuje logy do JSON a odesílá je POST požadavky na endpoint serveru. gRPC — alternativa s binární serializací (Protocol Buffers), která je o 30–40% kompaktnější než JSON a rychlejší na mobilních zařízeních s nestabilním připojením. WebSocket se používá pro logování v reálném čase při ladění, ale zřídka v produkci kvůli spotřebě energie.

Firebase Crashlytics: sběr crashů a logů

Firebase Crashlytics — bezplatná služba Google pro sběr crash reportů a vlastních logů. Je vestavěna do Firebase SDK a nevyžaduje samostatný server. Crashlytics automaticky shromažďuje stack trace, stav zařízení, verzi operačního systému a otevřené obrazovky v okamžiku pádu.

Vlastní logy v Crashlytics se přidávají prostřednictvím metody log() — nejsou odesílány na server okamžitě, ale jsou uloženy v kruhovém bufferu a připojeny k příštímu crash reportu. To je klíčový rozdíl oproti Sentry, kde je každý log samostatnou událostí. Maximální objem vlastních logů v Crashlytics je 64 KB na jeden crash.

// Firebase Crashlytics — vlastní logy na Androidu
import com.google.firebase.crashlytics.FirebaseCrashlytics

class CheckoutViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance()
            .log("Payment started: amount=$amount")
        try {
            process(amount)
        } catch (e: Exception) {
            FirebaseCrashlytics.getInstance()
                .recordException(e)
        }
    }
}

Firebase Crashlytics podporuje setUserIdentifier pro propojení crashů s konkrétními uživateli. To pomáhá určit, zda je chyba hromadná nebo postihuje pouze jednoho uživatele. setCustomKey přidává libovolné klíče ke každému reportu — verzi A/B testu, region, tarifní plán.

Sentry: breadcrumbs a kontext uživatele

Sentry — platforma pro monitorování chyb, která ukládá nejen crash reporty, ale také všechny vlastní události (breadcrumbs) jako nezávislé záznamy. Na rozdíl od Crashlytics umožňuje Sentry prohlížet sekvenci událostí před chybou v chronologickém pořadí — breadcrumbs jsou viditelné v rozhraní bez nutnosti rekonstrukce z crash logu.

Automatické breadcrumbs v Sentry

SDK Sentry automaticky shromažďuje breadcrumbs pro systémové události: změny životního cyklu UIViewController (viewDidLoad, viewWillAppear), doteky, kliknutí na tlačítka, HTTP požadavky přes URLSession. Všechny tyto události se zobrazují na časové ose chyby spolu s vlastními breadcrumbs. Pro Android se podobně shromažďují životní cykly Activity a Fragment, události onClick a síťové požadavky přes OkHttp.

SDK Sentry pro iOS a Android automaticky shromažďuje breadcrumbs událostí UI: doteky, navigace, životní cyklus. Vývojář může přidávat vlastní breadcrumbs pomocí addBreadcrumb() s určením typu, kategorie a úrovně. Sentry podporuje distributed tracing: logger propojuje breadcrumbs na klientovi s požadavky na backendu prostřednictvím trace ID.

import Sentry

func trackCartEvent(action: String, itemId: String) {
    let crumb = Breadcrumb()
    crumb.level = .info
    crumb.category = "cart"
    crumb.message = "Cart \(action): \(itemId)"
    crumb.data = ["action": action, "item_id": itemId]
    SentrySDK.addBreadcrumb(crumb)
}

Logcat a vzdálený přístup přes ADB

Logcat — standardní systém logování Androidu, přístupný přes Android Debug Bridge (ADB). Logcat shromažďuje všechny systémové a aplikační zprávy, rozdělené podle úrovní (V, D, I, W, E, F) a značek. Vzdálený přístup k Logcatu funguje přes ADB přes USB nebo Wi-Fi, ale pouze pro zařízení v režimu ladění — produkční aplikace na zařízeních bez USB připojení nejsou přístupné.

Pro vzdálené logování v produkci na Androidu se používají alternativy: Logcat sám o sobě neumí odesílat logy na server. Jeho rolí je lokální diagnostika. Existují však wrappery (Timber, LogcatLive), které přeposílají zprávy do Firebase nebo Sentry a zachovávají známé API Log.d / Log.e. Timber umožňuje přepínat handlery bez změny kódu aplikace — debug strom zapisuje do Logcatu, release strom odesílá na server s batchováním a kompresí.

Batching a optimalizace přenosu

Batching — seskupování několika logů do jednoho HTTP požadavku pro úsporu přenosu a baterie. Místo 50 samostatných POST požadavků odesílá SDK jeden JSON pole. Typické strategie: odesílání podle plánu (každých 30 sekund), podle počtu (každých 50 událostí) nebo podle události (pouze při kritické chybě).

Pro aplikace s miliony uživatelů může objem logů dosahovat terabajtů denně. Batching snižuje počet požadavků 10–50krát a snižuje zatížení serveru. Sentry používá kompresi gzip na transportní úrovni, což dále snižuje objem dat o 60–70%.

// Jednoduchá implementace batchingu na Androidu
class LogBatcher {
    private val buffer = mutableListOf<LogEvent>()
    private val maxSize = 50
    private val intervalMs = 30_000L

    fun append(event: LogEvent) {
        buffer.add(event)
        if (buffer.size >= maxSize) flush()
    }

    suspend fun flush() {
        val batch = buffer.toList()
        buffer.clear()
        sendToServer(batch)
    }
}

Komprese a deduplikace

gzip — standardní metoda komprese pro HTTP přenos logů. SDK Sentry a Crashlytics automaticky komprimují tělo požadavku před odesláním. Deduplikace — odstraňování opakujících se zpráv na straně klienta: pokud je stejná událost zachycena 100krát za sekundu, SDK ji odešle jednou s polem count = 100.

Typické chyby vzdáleného logování

Nejčastější chybou je logování citlivých údajů. Remote logging SDK přenáší data na server, a pokud vývojář omylem zaloguje heslo, token nebo e-mail uživatele, tato data skončí v cloudové infrastruktuře. Vždy používejte filtrování PII (Osobní identifikovatelné informace) na úrovni SDK: Sentry má vestavěný beforeSend-hook pro čištění dat před odesláním.

Druhým častým problémem je nadměrné logování. Pokud je každý pohyb prstu odesílán na server, objem dat exponenciálně roste a náklady na server také. Stanovte rozpočet na logy: ne více než 1–5 událostí na uživatele za minutu v produkci. Debug logy odesílejte pouze s příznakem, který se zapíná pro konkrétní zařízení.

Třetí chybou je ignorování offline scénáře. Pokud SDK ztrácí logy při nedostatku sítě a neobnovuje je při opětovném připojení, remote logging je pro uživatele s nestabilním připojením k ničemu. Všechna SDK (Firebase, Sentry) automaticky ukládají logy do mezipaměti v lokálním souboru a odesílají je při objevení sítě, ale toto nastavení je třeba zkontrolovat.