Sentry ali Datadog: isti incident lahko ustvari dva različna računa

|Avtor: Uredništvo QUASA|6 min branja| 1
Sentry ali Datadog: isti incident lahko ustvari dva različna računa

Za odpravljanje napak v kodi je Sentry bližja izbira; za povezovanje aplikacijskih težav s stanjem infrastrukture, sledmi in dnevniki je primernejši Datadog. Primerjava Better Stack opisuje prav to razliko v obsegu in navaja, da nekatere ekipe uporabljajo obe orodji. Izbira je zato odvisna od podatkov, ki jih ekipa potrebuje za razlago incidenta.

Različen obseg spremeni tudi račun. Pri Sentryju je pomembno, koliko aplikacijskih podatkov je sprejetih v okviru izbranih kvot. Pri Datadogu se lahko ločeno seštejejo gostitelji, vneseni dnevniki ter indeksirani dnevniki in razponi. En incident lahko sproži vse te vrste porabe, vendar iz števila napak samega ni mogoče izračunati enakega stroška za obe orodji.

Kaj ekipa plačuje in kaj lahko izgubi

Sentry preiskavo usmeri v aplikacijo: napako, povezano sled in okoliščine izvajanja. Njegova dokumentacija o zavrženih dogodkih loči sprejete podatke od filtriranih, omejenih zaradi hitrosti, neveljavnih in zavrženih pri odjemalcu; med vrstami podatkov navaja tudi napake, dnevnike in razpone. Če ekipa zmanjša količino s filtriranjem ali vzorčenjem, izpuščenega posameznega dogodka pozneje ne more pregledati v Sentryju. Tudi polna kvota ali omejitev hitrosti lahko pomeni vrzel v gradivu za preiskavo.

Datadogov javni cenik za obračun po dejanski porabi navaja 18 USD mesečno na gostitelja Infrastructure Pro in 36 USD na gostitelja APM. Vnos dnevnikov stane 0,10 USD na GB, indeksiranje milijona dnevniških dogodkov s 15-dnevno hrambo pa 2,55 USD; enaka cena velja za milijon dodatnih indeksiranih razponov s takšno hrambo. To so cene različnih postavk, zato dnevnik, ki je bil vnesen, še ni nujno tudi indeksiran in dolgoročno iskljiv.

Datadogove vključene količine pri APM obsegajo milijon indeksiranih razponov in 150 GB vnesenih razponov na gostitelja mesečno. Pri mesečnem obračunu po dejanski porabi se gostitelji merijo po 99. percentilu urnih meritev. Spodnji pogojni izračuni predpostavljajo, da isti gostitelji uporabljajo Infrastructure Pro in APM, da vnos razponov ostane znotraj vključene količine ter da ni drugih modulov, davkov ali pogodbenih prilagoditev.

Majhna spletna aplikacija: koliko stanejo stalni gostitelji?

V prvem pogojnem primeru aplikacija ves mesec teče na dveh gostiteljih. Ustvari 10 GB vnesenih dnevnikov, milijon indeksiranih dnevniških dogodkov in največ dva milijona indeksiranih razponov. Po navedenih cenah za obračun po dejanski porabi gostitelja staneta 2 × (18 + 36) = 108 USD na mesec. Dnevniki dodajo 1 USD za vnos in 2,55 USD za indeksiranje, zato je okvirni seštevek 111,55 USD. Predpostavljeni razponi ostanejo v vključeni količini APM.

Za Sentry bi ista ekipa namesto gostiteljev ocenila sprejete napake, razpone in druge vključene kategorije. Če bi aplikacija pogojno ustvarila 3.000 sprejetih napak in 200.000 sprejetih razponov, teh številk ni pošteno pretvoriti v znesek brez izbire Sentryjevega paketa in kvot. Filtriranje ponavljajočega se šuma bi zmanjšalo obseg shranjenih podatkov, hkrati pa bi odstranilo posamezne pojavitve, ki bi jih razvijalec morda potreboval za primerjavo zahtevkov.

Razlika v tem primeru nastane, še preden se število napak poveča: Datadogovi spremljani gostitelji ustvarijo osnovno postavko, Sentryjeva poraba pa je vezana na sprejete aplikacijske podatke. Če ekipa pri incidentu potrebuje predvsem sled izjeme in povezavo s kodo, je to pomembnejša primerjava od gole cene gostitelja. Če mora preveriti tudi stanje okolja, je infrastrukturni podatek del potrebnega obsega.

Samodejno skaliranje: kaj se zgodi ob kratki konici?

Drugi pogojni primer ima štiri gostitelje v običajnih urah in osem gostiteljev v desetini ur meseca. Konica traja dovolj dolgo, da tudi po izločitvi najvišjega odstotka urnih meritev ostane vrednost osem. Pri predpostavljenem obračunu po dejanski porabi je zato okvirna postavka za Infrastructure Pro in APM 8 × (18 + 36) = 432 USD na mesec. Če bi bili aktivni samo štirje gostitelji, bi bila ob istih predpostavkah 216 USD.

Pri Sentryju dodatni gostitelji sami po sebi ne povečajo števila sprejetih napak. Če več instanc obdela več zahtevkov in s tem ustvari več napak ali razponov, pa se lahko poraba poveča tudi tam. Zato je treba ločiti rast infrastrukture od rasti telemetrije: promet lahko ostane skoraj enak, število spremljanih gostiteljev pa se spremeni; ob resnični prometni konici se lahko spremenita oba podatka.

Strošek je mogoče omejiti z manj zbranimi razponi, toda vzorčenje pomeni, da nekaterih sledi ne bo za poznejšo preiskavo. Pri infrastrukturnem nadzoru je podoben kompromis izključitev dela gostiteljev: račun se zmanjša, pregled nad okoljem prav med konico pa postane ožji. V obeh primerih je pomembno, katero vrzel bi ekipa ob naslednjem incidentu še sprejela.

Več storitev: kdaj se prišteje telemetrija?

Tretji pogojni primer zajema 12 gostiteljev, 60 GB vnesenih dnevnikov, 20 milijonov indeksiranih dnevniških dogodkov in 20 milijonov indeksiranih razponov. Gostitelji za Infrastructure Pro in APM pomenijo 12 × 54 = 648 USD na mesec. Vnos dnevnikov doda 6 USD, njihovo indeksiranje 51 USD. Od razponov jih je 12 milijonov vključenih v APM; dodatnih osem milijonov stane 20,40 USD. Okvirni seštevek je tako 725,40 USD na mesec.

Če bi ekipa indeksirala samo vključenih 12 milijonov razponov, bi se ta seštevek znižal na 705 USD. Prihranek ne pomeni, da je izginil ves strošek sledenja: gostitelji ostanejo na računu, vnos razponov pa je ločena količina, za katero primer predpostavlja, da ostane znotraj vključene meje. Manj indeksiranih razponov pomeni predvsem manj sledi, ki jih bo mogoče po incidentu iskati skozi izbrano obdobje hrambe.

Podobno lahko ekipa omeji indeksiranje dnevnikov in še vedno plačuje njihov vnos. Če med izpuščenimi zapisi ostane sporočilo, potrebno za rekonstrukcijo odpovedi ene od storitev, nižja indeksna postavka pomeni slabši poznejši pregled. Pri Sentryju bi za isto večstoritveno aplikacijo potrebovala ločeno oceno sprejetih napak in razponov; število Datadogovih gostiteljev za tak izračun ni nadomestna mera.

Katera primerjava vodi do uporabne izbire?

Razvojna ekipa, ki mora predvsem povezati napako s kodo in sledjo izvajanja, naj strošek Sentryja presoja glede na količino sprejetih podatkov in kvote paketa. Operativna ekipa, ki mora pojasniti tudi stanje gostiteljev ter poiskati dnevnike in sledi med storitvami, potrebuje seštevek Datadogovih postavk po gostiteljih, vnosu in indeksiranju. Kadar sta obe vrsti pregleda nujni, je uporaba obeh orodij smiselna možnost, vendar pomeni tudi dva ločena obračunska modela.

Odločilno vprašanje pri vseh treh scenarijih je, kateri podatek mora ostati dostopen po koncu incidenta. Sprejet dogodek, spremljan gostitelj in indeksiran razpon niso primerljive enote. Nižji predvideni račun je uporaben podatek šele skupaj z jasnim odgovorom, katere napake, sledi ali dnevniki bodo zaradi izbranih omejitev izpuščeni.

Preberite tudi:

Deli:

Naročite se na naše e-novice

Najnovejše novice o Web3, UI in kriptovalutah neposredno v vaš e-poštni predal.

0