Sentry apo New Relic: 0,5 ms diferencë fsheh dy role të ndryshme

Kur incidentet zgjidhen kryesisht nga zhvilluesit që ndryshojnë kodin, Sentry është zgjedhja më e drejtpërdrejtë; kur përgjegjësia përfshin edhe hostet, Kubernetes dhe logjet, New Relic mbulon më shumë nga hetimi operacional. Në testin e agjentëve në një aplikacion Express, Sentry shtoi 0,7 ms dhe New Relic 1,2 ms në p50, një diferencë prej 0,5 ms; në p99 shtesat ishin përkatësisht 2,4 ms dhe 8,3 ms.

Diferenca e vonesës mat koston e instrumentimit në atë ngarkesë, ndërsa zgjedhja e mjetit varet nga të dhënat që i duhen personit që zgjidh incidentin. Të dy produktet mbulojnë gabime dhe gjurmë, ndaj një ekip i përzier mund të paguajë për sinjale të mbivendosura nëse nuk ndan qartë përgjegjësitë dhe volumin e telemetrisë.

Kur gabimi duhet lidhur me kodin

Sentry është veçanërisht i dobishëm kur zhvilluesi nis nga një përjashtim dhe kërkon rrugën drejt ndryshimit të mundshëm në kod. Në përshkrimin e mjeteve të diagnostikimit, Sentry rendit breadcrumbs, commit-et e dyshuara, Session Replay, monitorimin e performancës dhe gjurmimin e shpërndarë. Këto të dhëna e vendosin gabimin pranë kontekstit ku u shfaq; një commit i dyshuar mbetet pistë hetimi, jo përfundim automatik për shkakun.

Në një shërbim Express, gjurma e gabimit mund ta drejtojë zhvilluesin te funksioni ose varësia ku dështoi kërkesa. Nëse ekipi lidh projektin me historinë e ndryshimeve, ai mund të shqyrtojë edhe kodin e ndryshuar para shfaqjes së problemit. Kjo rrjedhë pune ka vlerë kur i njëjti person merr njoftimin, riprodhon gabimin dhe përgatit korrigjimin.

Sentry ka edhe gjurmim të performancës dhe logje të lidhura me diagnostikimin. Për këtë arsye, dallimi nuk është mes një mjeti që sheh vetëm gabime dhe një tjetri që sheh gjithçka. Dallimi praktik është sa larg nga kodi duhet të shkojë hetimi përpara se ekipi të gjejë shkakun.

Kur përgjegjësia shtrihet te infrastruktura

New Relic i përshtatet më shumë personit në detyrë që duhet të lidhë sjelljen e aplikacionit me gjendjen e mjedisit ku ai punon. Në platformën e New Relic përfshihen APM, gjurmimi i shpërndarë, hartat e shërbimeve, logjet, monitorimi i hosteve dhe Kubernetes, si edhe Session Replay. Platforma mbulon gjithashtu gabimet, kështu që një ekip SRE nuk ka nevojë ta trajtojë çdo përjashtim si sinjal të shkëputur nga pjesa tjetër e sistemit.

Merrni si shembull kushtor një kërkesë Express që përdor bazë të dhënash, cache dhe një shërbim të jashtëm. Gjurma mund të tregojë se në cilën varësi kaloi koha, ndërsa metrikat e hostit dhe logjet mund të tregojnë nëse ngadalësimi prek edhe kërkesa të tjera. Kjo pamje është e rëndësishme për ekipin që administron shërbimet dhe infrastrukturën, jo vetëm kodin e një aplikacioni.

Nëse metrikat e hosteve, gjendja e Kubernetes dhe logjet mblidhen tashmë në një sistem që ekipi e përdor rregullisht, mbulimi shtesë mund të ketë më pak vlerë. Në atë rast, pyetja për New Relic bëhet sa mirë i bashkon sinjalet që mungojnë, jo thjesht sa funksione rendit platforma.

Çfarë tregojnë gjurmët dhe replay

Gjurmët dhe Session Replay u përgjigjen pyetjeve të ndryshme gjatë të njëjtit incident. Një gjurmë ndjek punën e kërkesës përmes shërbimeve dhe varësive; replay rikrijon ndërveprimin e përdoruesit në aplikacionin web. Nëse një faqe dështon pas një veprimi të caktuar, replay ndihmon të kuptohet rruga e përdoruesit, ndërsa gjurma ndihmon të gjendet pika ku kërkesa u ngadalësua ose dështoi.

Një agjent i instaluar vetëm në backend-in Express nuk prodhon vetvetiu replay të sesionit në shfletues: për atë pamje duhet instrumentuar edhe pjesa përkatëse e aplikacionit web. Kjo ka pasoja për krahasimin e kostos, sepse ngjarjet e gabimeve, span-et e gjurmëve dhe sesionet e regjistruara mund të rriten me ritme të ndryshme. Një ekip që heton kryesisht gabime backend-i mund të mos ketë nevojë për të njëjtin volum replay si një ekip që riprodhon probleme të ndërfaqes.

Të dy produktet ofrojnë gjurmim dhe replay, prandaj prania e këtyre funksioneve nuk e zgjidh zgjedhjen. Për zhvilluesin ka peshë lidhja e sinjalit me gabimin dhe kodin; për SRE-në, lidhja e gjurmës me shërbimet, logjet dhe burimet ku ekzekutohen ato.

Si kthehet workload-i në faturë

Te Sentry, vlerësimi nis me vëllimin e secilës kategori të dhënash, jo me një numër të vetëm kërkesash. Shpjegimi i Sentry për kuotën Replay tregon se planet aktuale përfshijnë kategori për gabime, span-e dhe replay, si edhe se dërgimi i replay-ve mund të kufizohet përmes konfigurimit të SDK-së. Kështu, pak gabime nuk nënkuptojnë domosdoshmërisht pak span-e ose pak sesione të regjistruara.

Për një përllogaritje kushtore, numri i kërkesave të kampionuara shumëzohet me span-et mesatare për kërkesë; gabimet dhe replay-t vlerësohen veçmas sipas mënyrës si përdoret aplikacioni. Kjo e bën normën e kampionimit pjesë të vendimit financiar: ajo ndikon sa gjurmë ruhen dhe sa hollësi mbeten të disponueshme kur hetohet një incident. Numërimi i kërkesave Express, i marrë më vete, nuk jep faturën e Sentry.

Sipas çmimeve të New Relic, opsioni Original Data përfshin 100 GB ingestim falas në muaj dhe kushton 0,40 dollarë për çdo GB mbi atë kufi; llogaritja mund të përfshijë edhe përdoruesit me akses të plotë dhe funksione shtesë. Në një shembull kushtor me 250 GB të ingestuara, pjesa mbi kufirin është 150 GB dhe kostoja e saj do të ishte 60 dollarë. Kjo është vetëm kostoja e asaj pjese të të dhënave, jo fatura përfundimtare e ekipit.

Për të njëjtin workload, gabimet dhe span-et e Sentry duhen krahasuar me madhësinë në GB të gjurmëve, logjeve dhe metrikave që do të dërgoheshin në New Relic. Njësitë nuk shndërrohen drejtpërdrejt në njëra-tjetrën: dy kërkesa mund të krijojnë numër të ngjashëm span-esh, por sasi të ndryshme të dhënash nëse logjet ose atributet e tyre ndryshojnë. Kur përdoren të dy mjetet, ndarja e sinjaleve sipas ekipit shmang ruajtjen e së njëjtës pamje të incidentit në dy fatura.

Sa peshë ka overhead-i i agjentit

Matja në Express vlen si pikë krahasimi për një aplikacion me ngarkesë të përcaktuar, jo si renditje për çdo mjedis prodhimi. Testi përdori konfigurimet automatike të instrumentimit dhe përfshiu rrugë me thirrje drejt PostgreSQL, Redis dhe një shërbimi të jashtëm HTTP. Një aplikacion me rrugë të tjera, kampionim tjetër ose mënyrë tjetër eksportimi mund të ketë profil të ndryshëm vonese dhe përdorimi të burimeve.

Për një shërbim ku vonesa në skajin e shpërndarjes është kufizim i rëndësishëm, p99 meriton vëmendje krahas p50. Edhe CPU-ja dhe kujtesa kanë rëndësi nëse instancat punojnë pranë kufijve të tyre. Por një kursim i vogël në vonesën e agjentit nuk e zëvendëson pamjen e infrastrukturës kur pikërisht aty lindin incidentet; po ashtu, mbulimi më i gjerë nuk e heq nevojën për kontekst të mirë të gabimit në kod.

Zgjedhja sipas personit që zgjidh incidentin

• Zhvilluesi i aplikacionit: Sentry është pika më e natyrshme e nisjes kur puna kryesore është të lidhë gabimin me gjurmën, kontekstin e përdoruesit dhe ndryshimet e mundshme në kod. Monitorimi i infrastrukturës shtohet sipas përgjegjësive reale të ekipit.
• Ekipi SRE: New Relic ka më shumë kuptim kur i njëjti person duhet të ndjekë aplikacionin, varësitë, hostet, Kubernetes dhe logjet. Në buxhet hyjnë vëllimi i të dhënave dhe lloji i aksesit që i duhet secilit anëtar.
• Ekipi i përzier: të dy mjetet mund të justifikohen kur zhvilluesit hetojnë gabimet në kod dhe SRE-të administrojnë sinjalet operacionale. Ndarja duhet të përcaktojë cilat gjurmë, gabime dhe logje ruhen në secilin mjet; përndryshe mbivendosja e funksioneve kthehet në mbivendosje të telemetrisë së paguar.

Lexoni gjithashtu:

• Canva Pro apo Adobe Express: 24 dollarë diferencë, por AI matet ndryshe
• Supabase apo Firebase: modeli i të dhënave vendos para benchmark-ut
• Printful apo Printify: i njëjti zbritim 33%, kosto tjetër për porosi