Sentry, nebo Datadog: chyba v kódu není celý provozní incident

Pokud tým nejčastěji opravuje výjimky a regresní chyby v aplikaci, dává větší smysl Sentry. Když incident začíná růstem latence, zatížením hostitele nebo souvislostí mezi metrikami, logy a trasami, nabízí širší záběr Datadog. Toto rozdělení práce popisuje také srovnání Toolradar.

Obě služby lze provozovat společně: vývojáři řeší aplikační chyby v Sentry, SRE sleduje stav služby a infrastruktury v Datadogu. Taková volba dává smysl, jen pokud má každý nástroj vlastní úlohu. Stejný span nebo aplikační log odeslaný do obou systémů využívá dvě oddělené placené kapacity.

Jeden incident od výjimky k provozu

V podmíněném příkladu po nasazení nové verze část požadavků selhává a zbytek výrazně zpomalí. Vývojář se nejprve ptá, která výjimka vznikla, v jaké verzi a kudy vedla cesta k chybě. Sentry podobné události sdružuje do problémů, připojuje zásobník volání a kontext požadavku. To zkracuje cestu k opravě, pokud je příčina v aplikačním kódu.

SRE u stejného incidentu potřebuje vědět, zda se změnila odezva služby, zatížení hostitele nebo chování závislé služby. Datadog spojuje infrastrukturní metriky, APM trasy a logy; umožňuje tak sledovat příznak napříč prostředím, v němž aplikace běží. Jestli aplikace pouze čeká na přetíženou databázi a nezachytí vlastní výjimku, seznam chyb ukáže jen část problému.

Hranice přitom není ostrá. Sentry umí i trasování a aplikační logy, Datadog nabízí Error Tracking. Rozdíl se projeví ve výchozí otázce: je třeba přiřadit konkrétní chybu k opravě, nebo vysvětlit degradaci celé služby včetně hostitelů a závislostí? Při nákupu proto nestačí porovnat zaškrtané funkce; rozhoduje, který pohled tým během incidentu skutečně otevře jako první.

Rozhoduje první signál a odpovědnost týmu

Pro tým vývojářů, který po nasazení třídí nové chyby a přiřazuje je vlastníkům kódu, je přirozeným pracovním objektem problém v Sentry. Menší firma bez samostatné role SRE může touto cestou pokrýt nejčastější aplikační závady, jestli má stav hostitelů zajištěný jinde. Samotná diagnostika výjimek však nevysvětlí příčinu každého pomalého požadavku ani výpadek infrastruktury.

Datadog je vhodnější tam, kde pohotovostní služba odpovídá za kapacitu, latenci a návaznost více služeb. Jeho širší sběr vyžaduje promyšlené označování služeb, výběr logů pro indexaci a pravidla upozornění. Pro malý tým je to také provozní práce: bez vlastníka konfigurace mohou dva různé signály vyvolat dvě upozornění na tutéž závadu.

Rozhodovací větev pro kombinaci je užší: vývojář potřebuje detail chyby v Sentry a SRE zároveň potřebuje metriky hostitelů nebo logy mimo aplikaci. Pokud jeden člověk řeší oba druhy incidentů a většina z nich začíná výjimkou, druhý nástroj nemusí přinést úměrnou hodnotu. Naopak opakované zpomalení bez aplikační chyby ukazuje, že samotné Sentry nechává důležitý příznak mimo hlavní pracovní postup.

Vlastní automatizace nad problémy v Sentry má ještě jiné omezení než měsíční kvótu událostí. Pravidla Sentry API omezují frekvenci i počet současných požadavků podle volajícího a koncového bodu. Pravidelný skript, který API intenzivně dotazuje, tedy nelze plánovat podle ceny za zachycené chyby.

Modelový účet pro pět hostitelů

Představme si podmíněný měsíční provoz na pěti hostitelích: 40 tisíc aplikačních chyb, čtyři miliony trasovacích spanů a čtyři gigabajty aplikačních logů odeslaných do Sentry. Do Datadogu směřuje deset gigabajtů logů a indexuje se jeden milion logových událostí. Nejde o měření skutečné firmy. Model počítá s ročním závazkem a bez dalších placených modulů či překročení zahrnuté kapacity APM.

Rozpis tarifu Sentry Team uvádí měsíční ekvivalent 26 dolarů při ročním účtování a zahrnutý objem 50 tisíc chyb, pět milionů spanů a pět gigabajtů logů. Podmíněná spotřeba se do těchto objemů vejde. Základ Sentry v modelu proto činí 26 dolarů měsíčně, pokud nevzniknou jiné příplatky.

Datadog má jinou jednotku. Oficiální ceník Datadogu uvádí při ročním účtování Infrastructure Pro za 15 dolarů na hostitele měsíčně, APM za 31 dolarů na hostitele, příjem logů za 0,10 dolaru na gigabajt a indexaci s patnáctidenním uchováním za 1,70 dolaru na milion událostí. Sazby za hostitele platí pro oba moduly odděleně; cena za logy má zvlášť objem příjmu a počet indexovaných událostí.

Pro pět hostitelů tak infrastruktura vychází na 75 dolarů a APM na dalších 155 dolarů měsíčně. Deset gigabajtů přijatých logů přidá jeden dolar a milion indexovaných událostí 1,70 dolaru. Podmíněný účet Datadogu je 232,70 dolaru; s tarifem Sentry Team jde o 258,70 dolaru měsíčně v přepočtu ročního závazku, před daněmi a případnými příplatky. Není to cena za totožný výsledek: Datadog v ní pokrývá i infrastrukturu, kterou samotný plán Sentry v tomto srovnání nepokrývá.

Samotné vstupní sazby 26 dolarů za plán a 15 dolarů za hostitele proto nelze postavit vedle sebe jako ceny stejného monitoringu. Pokud počet hostitelů stoupne, roste hostitelská část účtu; pokud přibudou logy nebo chybové události, mění se jiná položka. Odhad rozpočtu musí vycházet z datových proudů, které se tým skutečně rozhodne sbírat a uchovávat.

Která data se při souběhu platí dvakrát

Nejjasnější překryv vzniká při trasování. Jestli aplikace posílá tytéž spany do Sentry i Datadogu, spotřebovává zahrnutý nebo přikoupený objem v Sentry a současně využívá APM v Datadogu. U logů může stejná aplikační událost zaplnit kvótu Sentry a zároveň vytvořit náklad za příjem či indexaci v Datadogu. Samotné zobrazení podobné chyby v obou nástrojích ovšem ještě neznamená dvě stejné fakturační položky; záleží na cestě dat a zapnutých produktech.

U kombinace lze proto rozdělit odpovědnost po signálech: chyby a nezbytný kontext ponechat v Sentry, infrastrukturní metriky, provozní logy a případně APM trasy soustředit v Datadogu. Když oba systémy dostávají totožné trasy, je užitečné určit, jakou odlišnou otázku každý z nich zodpoví. Jinak se vedle kapacity platí i práce s duplicitními upozorněními a hledání souvislosti mezi dvěma záznamy téhož incidentu.

Rozpočet ovlivňuje také chování po vyčerpání kvóty. Pravidla průběžného účtování Sentry umožňují u placené organizace pokračovat v příjmu událostí nad zahrnutý objem, pokud je tato možnost povolená; spotřeba se účtuje po skončení cyklu. Modelový součet proto popisuje základ při zadaném objemu, nikoli strop budoucí faktury. Právě hranice sběru a pravidla pro překročení rozhodují, zda je souběh obou služeb pro tým dlouhodobě únosný.

Přečtěte si také:

• CrewAI, nebo AutoGen: serverless provoz obrací zdánlivě snadnou volbu
• Lokální LLM, nebo cloud: levnější volbu mění vytížení
• Riverside, nebo StreamYard: rozhoduje záznam, ne počet hostů