Proč se chyby „schovávají“ pod povrchem

Pokud se vám v dashboardu zobrazuje jen málo chyb, pravděpodobně koučujete špatné metriky. Většina vývojářů spadne do pasti – sledují jen výjimky, které se vyhazují, a zapomínají monitorovat nevyvolané hlášky. Znáte ten pocit, když vám server vrací 200 OK a ve skutečnosti se vám rozplývá logika?

Základní metriky, které nesmí chybět

Nejprve si napište: “Počítám nevyvolané chyby”. To nejsou jen 0‑ky, ale i „silently dropped“ požadavky. Očima analytika to vypadá jako stín, který se mihá mezi řádky. Zapomeňte na čisté počty – sledujte poměr chyb k úspěšným voláním, sledujte časová okna, sledujte variabilitu. Měřítka jako “error‑rate per endpoint” vs “total requests per minute” vám otevřou oči.

Nástroje a techniky, které vám dají pravdu

Grafana + Prometheus? Jo, funguje. Ale jen pokud si na Prometheus přihodíte scrape‑target, který exportuje metriky typu app_errors_total i app_requests_total. A nezapomeňte na APM (např. New Relic, Datadog). Ty vám ukážou stacktrace i tzv. “silent drops”. Tady klíčová věc: nastavit alerty na “error‑rate > 1 %”. Pokud se vám to nelíbí, přečtěte si, jak se to dělá na strategiesazenitenis.com.

Kontrola v reálném čase

Zapněte si live tailing. Není to jen „logování“, je to radar na letecký provoz. Když uvidíte, že se v posledních minutách vyskytuje vzestup “null reference” bez stacktrace, víte, že něco uniká.

Praktický postup krok za krokem

1. Přidejte globální middleware, který zachytí každou výjimku i každé neúspěšné volání. 2. Exportujte metriky do Promethea. 3. V Grafaně vytvořte panely: “error‑rate per service”, “silent drops per minute”. 4. Nastavte alarmy. 5. Pravidelně prověřujte dashboard a odstraňujte false‑positivy.

Udělejte to během jedné sprintové smyčky. Není čas na debaty. Zjistíte, že většina „nevynucených“ chyb je jen špatně nastavený logger. Poslední krok: každé ráno spustit skript, který vypíše top‑5 endpointů s nejvyšším podílem nevyvolaných chyb. To je vaše nová realita.