Monitorování výkonu — co to je, metriky a sběr dat

Co je monitorování výkonu

Monitorování výkonu je praxe kvantitativního hodnocení chování aplikace prostřednictvím sběru metrik doby provádění, využití paměti, snímkové frekvence a spotřeby energie. Na rozdíl od hlášení crashů, které zaznamenává pouze fatální selhání, monitorování výkonu sleduje postupnou degradaci: aplikace funguje, ale pomaleji, než by měla.

Podle Google (2024) 53 % uživatelů zavře aplikaci, pokud se načítá déle než 3 sekundy. Každá další sekunda zpoždění snižuje konverzi v průměru o 20 % napříč kategoriemi. To dělá z monitorování výkonu nejen technickou praxi, ale obchodní nutnost pro mobilní produkty.

Moderní monitorování výkonu pokrývá čtyři úrovně: klientská část (iOS, Android), síť (API požadavky, WebSocket), backendové služby a infrastruktura. V mobilním vývoji je důraz kladen na klientské metriky, protože většina problémů s výkonem vzniká právě na zařízení uživatele.

Klíčové metriky mobilní aplikace

Pro úplné monitorování je třeba sledovat pět skupin metrik, z nichž každá odpovídá za svůj aspekt uživatelského zážitku. FPS (frames per second) ukazuje plynulost animací a rolování — hodnota pod 30 snímků za sekundu je okem vnímána jako zpomalení.

Časové metriky

Doba studeného startu aplikace — od okamžiku klepnutí na ikonu do plné připravenosti rozhraní. Doba teplého startu — návrat z pozadí. Doba odezvy na akci uživatele (tap-to-response). Doba spuštění se pro Android měří přes ActivityManager, pro iOS — přes dyld a premain čas. Podle Firebase Performance je medián doby studeného startu pro top 100 aplikací 1,8 sekundy.

Metriky paměti a CPU

Spotřeba operační paměti by neměla překročit 80 % dostupného objemu na zařízení, jinak systém začne aplikaci uvolňovat z pozadí. Paměťová stopa je sledována prostřednictvím Xcode Instruments (iOS) a Android Profiler. Úniky paměti jsou detekovány růstem spotřeby při opakovaných operacích — například při přechodu mezi obrazovkami.

Síťové metriky

Doba provedení HTTP požadavku, velikost odpovědi, frekvence time-outů a chyb. Síťová latence je obzvláště kritická pro mobilní aplikace pracující v podmínkách nestabilního připojení (3G, metro, výtah, roaming). Doporučuje se sledovat dobu odezvy p95 — právě ta ukazuje zkušenost nej„těžších“ uživatelů s nejhoršími síťovými podmínkami.

Real User Monitoring a Synthetic Monitoring

Real User Monitoring (RUM) sbírá data z reálných zařízení uživatelů v produkčním prostředí. Tato metoda ukazuje skutečná zpoždění, která uživatelé zažívají, s ohledem na jejich zařízení, verze OS, síť a geolokaci. RUM poskytuje nejpřesnější obraz výkonu, ale závisí na tom, kteří uživatelé se dostali do vzorku.

Synthetic Monitoring naproti tomu provádí předem definované scénáře na testovacích zařízeních v kontrolovaných podmínkách. Umožňuje odhalit regresi dříve, než se dostane k uživatelům, a reprodukovat problémy ve stejném prostředí. Firebase Test Lab a BrowserStack poskytují syntetické testy na reálných zařízeních bez ručního spouštění.

Optimální strategií je kombinace obou přístupů: syntetické testy zachycují regrese ve fázi CI a RUM poskytuje skutečný obraz v produkci. Podle Datadog (2024) týmy používající obě metody odhalují o 35 % více problémů s výkonem dříve, než se stanou incidenty.

Nastavení Firebase Performance Monitoring

Firebase Performance Monitoring je bezplatný nástroj od Google pro sběr metrik výkonu na iOS a Android. Automaticky měří dobu spuštění aplikace, HTTP požadavky a vykreslování obrazovek bez nutnosti psát kód. Pro instalaci stačí přidat SDK do projektu a aktivovat modul Performance v konzoli Firebase.

Automatický sběr metrik

Po připojení SDK Firebase Performance automaticky vytváří trace pro každý HTTP požadavek přes URLSession (iOS) nebo OkHttp (Android). Vykreslování obrazovky je měřeno pro UIViewController a Activity, zaznamenávající čas od onCreate/viewDidLoad do dokončení prvního vykreslení. Všechny metriky jsou agregovány v konzoli Firebase s rozdělením podle verzí aplikace, zařízení a zemí.

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // provedení platby
        trace.stop()
    }
}

Kód vytváří vlastní trace pro platební scénář s atributem částky. Prostřednictvím tohoto trace v konzoli Firebase lze vidět medián a p95 doby provádění platby, seskupené podle verzí aplikace a zařízení.

HTTP monitorování

Firebase automaticky zachycuje síťové požadavky a zaznamenává URL, kód odpovědi, velikost payloadu a dobu provádění. Pro OkHttp na Androidu funguje automatická instrumentace bez dodatečné konfigurace. Požadavky na síť jsou zobrazeny v konzoli s seskupením podle endpointů, což umožňuje rychle odhalit zpomalení konkrétního API.

Vlastní trace pro business logiku

Standardní metriky pokrývají obecný výkon, ale pro diagnostiku obchodních procesů je vyžadována instrumentace konkrétních scénářů. Vlastní trace umožňují měřit dobu provádění autentizace, načítání zpravodajského kanálu, zpracování obrázku nebo synchronizace dat.

Každý vlastní trace by měl mít smysluplný název ve formátu „scénář-akce” a obsahovat atributy pro filtrování. Například trace „image-upload” s atributy „file_size” a „compression_quality” umožní odhalit závislost doby načítání na velikosti obrázku. Doporučuje se nevytvářet více než 20 vlastních trace na jednu obrazovku — nadměrná instrumentace vytváří šum a komplikuje analýzu.

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // načítání obrázku
    trace?.stop()
}

Příklad v Swift vytváří trace pro načítání obrázku s atributy velikosti souboru a úrovně komprese. V konzoli Firebase se tyto atributy stávají poli pro seskupování a filtrování metrik.

Prahy spouštění a alerting

Sběr metrik bez systému upozornění je zbytečný. Alerting by měl informovat tým o překročení povolených mezí metrik, přičemž prahy spouštění se dělí na tři úrovně: varování (warning), kritické (critical) a havarijní (outage). Každá úroveň určuje kanál upozornění: warning — na Slack kanál týmu, critical — do PagerDuty službu konajícímu inženýrovi, outage — hromadné rozeslání všem zainteresovaným stranám.

Pro mobilní metriky se doporučuje používat dynamické prahy založené na percentilech: p95 doba studeného startu přesahuje 4 sekundy — kritický alert. Statické prahy (např. CPU > 90 %) fungují hůře, protože nezohledňují normální kolísání zátěže v závislosti na denní době a dni v týdnu. Firebase Performance podporuje konfiguraci alertů přes Firebase Console s odesláním do Slack, PagerDuty a e-mailem s možností eskalace v případě nepotvrzení.

Podle Incident Management Survey (2024) týmy, které konfigurují alerty na základě percentilů místo průměrných hodnot, propásnou o 45 % méně incidentů. Průměrná hodnota (average) vyhlazuje výkyvy — p95 garantovaně ukazuje nejhorší scénář pro uživatele bez ohledu na denní dobu a sezónní kolísání zátěže.