Sentry eller Datadog: feilsporing og observability-kostnad

Velg Sentry når hovedoppgaven er å finne og rette feil i egen kode. Velg Datadog når driftsteamet også trenger oversikt over verter, ytelse, logger og brukeropplevelse. Et behov som starter med én feilsporing, kan gi flere kostnadslinjer når dekningen utvides: Datadogs prisliste skiller mellom feil, infrastrukturverter, APM-verter, loggdata og nettleserøkter.

Verktøyene kan også brukes sammen. Better Stacks sammenligning beskriver Sentry som et feilsøkingsløp rundt applikasjonen og Datadog som en bredere plattform med separate produkter. Valget avhenger derfor av hvilke hendelser teamet må kunne forklare, og hvilke datatyper det vil betale for.

Måleenheten avgjør hva som vokser på regningen

Datadogs Infrastructure Pro har en publisert årsbetalt listepris fra 15 dollar per infrastrukturvert per måned. APM har en egen pris per vert som sender sporingsdata; logginntak måles i GB, indekserte logger i antall hendelser og RUM i økter. Error Tracking har dessuten en egen prislinje for feilvolum. Å starte med feilsporing innebærer dermed ikke at alle de andre modulene er nødvendige, men hver utvidelse kan innføre en ny måler.

Hos Sentry er det applikasjonsdataene som må telles. Feilhendelser og sporing bruker ulike kvoter: Sentrys forklaring av sporingskvoten sier at sporing i den gjeldende SaaS-modellen måles i transaksjoner eller spans, mens sporingsbaserte ytelsesproblemer ikke belaster feilkvoten. Replay og logger er ytterligere datatyper som må vurderes når de tas i bruk.

Det gjør en sammenligning av startpris lite nyttig alene. En overvåket vert hos Datadog og en registrert feil hos Sentry er forskjellige leveranser. Antallet brukere kan være stabilt samtidig som flere tjenester sender sporingsdata, eller en støyende feil kan øke antallet feilhendelser uten at infrastrukturen vokser.

Oppsett A: Utviklerne trenger bare kodefeil

Anta en norsk SaaS-tjeneste med én webapplikasjon på to verter. Teamet har allerede overvåking av vertene, men trenger grupperte feil, stakkspor og informasjon som hjelper utviklerne å finne den berørte kodebanen. I dette hypotetiske oppsettet sendes bare feilhendelser til Sentry. Verter, logger, spans og replays inngår ikke i Sentry-forbruket som skal anslås.

Datadog er også et mulig valg for denne avgrensede oppgaven, siden prislisten har en egen Error Tracking-linje. Beslutningen gjelder da arbeidsflyten rundt feilene og forventet feilvolum, ikke hele plattformens katalog. Dersom teamet senere må se hvilken vert som var presset, følge en treg forespørsel gjennom flere tjenester eller undersøke en nettleserøkt, endres både datagrunnlaget og kostnadsbildet.

En slik liten tjeneste viser også hvorfor antall verter ikke alene bestemmer verdien av verktøyet. To verter kan være tilstrekkelig informasjon for driftsovervåking, mens utviklerne trenger detaljer om mange ulike kodefeil. Omvendt gir mange registrerte feil ingen automatisk forklaring på kapasitetsproblemer uten signaler fra infrastrukturen.

Oppsett B: Hele tjenesten følges i Datadog

Anta i stedet to applikasjoner på tolv overvåkede verter. Fire av vertene sender APM-spor, og tjenesten sender 80 GB logger per måned. To millioner logghendelser indekseres med femten dagers lagring. I nettleseren måles 100 000 økter med RUM Measure, og Session Replay brukes for 10 000 av dem. Tallene beskriver et hypotetisk miljø, ikke en måling av en virkelig kunde.

Med de publiserte årsbetalte enhetsprisene blir den enkle regneøvelsen 180 dollar for Infrastructure Pro, 124 for APM, 8 for logginntak, 3,40 for loggindeksering, 15 for RUM Measure og 25 for Session Replay. Summen er 355,40 dollar per måned for akkurat disse valgte målerne. Replay er et tillegg til RUM i dette oppsettet; å telle bare replay-øktene ville utelate målingen av den øvrige nettlesertrafikken.

Dette er et målerkart, ikke en forventet faktura. Avtalevilkår, inkluderte volum og faktisk bruk kan endre beløpet, og andre Datadog-produkter er ikke lagt inn. Eksemplet viser likevel den sentrale kostnadsmekanismen: flere vertssignaler, spor, søkbare logger og økter løser ulike driftsoppgaver og legger til ulike prislinjer.

Oppsett C: Datadog for drift, Sentry for kode

Et tredje hypotetisk miljø har to applikasjoner på tjue verter. Driftslaget følger vertene i Datadog og sender 120 GB logger i måneden. Av disse loggene indekseres tre millioner hendelser med femten dagers lagring. Utviklerne sender feilhendelser og spans til Sentry og bruker replay for utvalgte nettleserøkter. Datadog APM og RUM er ikke tatt med.

Med de samme listeprisene gir Datadog-delen 300 dollar for vertene, 12 for logginntak og 5,10 for indeksering: 317,10 dollar per måned før eventuelle avtalevilkår og inkluderte volum. Sentry-kostnaden kommer i tillegg og avhenger av plan, antall feilhendelser, sporingsvolum og replay-bruk. Uten disse inngangsdataene finnes det ikke et forsvarlig samlet månedsbeløp.

Fordelingen kan passe når driftslaget trenger vertstilstand og søkbare logger, mens utviklerne arbeider ut fra kodefeil og tilhørende spor. Den krever også en bevisst avgrensning: en hendelse i Sentry gir ikke av seg selv et fullstendig bilde av Datadogs infrastruktursignaler. Hvis én sammenhengende undersøkelse fra nettleserøkt til vert er avgjørende, må teamet vurdere mer instrumentering og hvilke moduler som skal dekke den.

Lagringstid og planbytte påvirker samme valg

Logginntak og søkbar lagring er separate beslutninger. I Datadog-eksemplene er volumet som sendes inn, skilt fra antallet hendelser som indekseres; prisen for indeksering varierer med valgt lagringstid. Et team som trenger å søke i eldre logger, må derfor regne på den perioden det faktisk trenger, ikke bare på hvor mange GB applikasjonen produserer.

Også Sentry har grenser for hvor langt tilbake teamet kan undersøke data. Sentrys veiledning om lagring oppgir at innsendte data utløper etter 30 til 90 dager, avhengig av plan og datatype. Historikken for én type hendelse bør derfor ikke brukes som antakelse om historikken for alle de andre.

Planbytte kan endre kostnaden selv uten mer trafikk. Sentrys vilkår for oppgradering sier at et bytte fra Team til Business på månedsplan ikke forholdsberegnes, og at forbruk utover inkludert volum prises etter plannivået ved slutten av månedsperioden. For et team som oppgraderer for å få en nødvendig funksjon, kan både planprisen og prisen på periodens ekstraforbruk dermed bli relevante. Det riktige valget er tjenesten som svarer på hendelsene teamet faktisk må løse, med et datavolum og en lagringstid det kan budsjettere for.

Les også: