🥇Jo vetëm relike e re: një vështrim në Datadog dhe Atatus

Në mjedisin e inxhinierëve SRE/DevOps, nuk do të habisë askënd që një ditë të shfaqet një klient (ose një sistem monitorimi) dhe të raportojë se "gjithçka ka humbur": faqja nuk funksionon, pagesat nuk kalojnë, jeta po kalbet. ... Pa marrë parasysh se sa shumë dëshironi të ndihmoni në një situatë të tillë, mund të jetë shumë e vështirë ta bëni këtë pa një mjet të thjeshtë dhe të kuptueshëm. Shpesh problemi fshihet në kodin e vetë aplikacionit; ju vetëm duhet ta lokalizoni atë.

Dhe në pikëllim dhe në gëzim…

Kështu ndodhi që ne kemi rënë në dashuri prej kohësh dhe thellë me New Relic. Ishte dhe mbetet një mjet i shkëlqyeshëm për monitorimin e performancës së aplikacionit, dhe gjithashtu ju lejon të instrumentoni arkitekturën e mikroshërbimit (duke përdorur agjentin e tij) dhe shumë, shumë më tepër. Dhe gjithçka mund të kishte qenë e mrekullueshme nëse nuk do të kishte ndryshime në politikën e çmimeve të shërbimit: ajo kosto nga viti 2013 u rrit 3+ herë. Përveç kësaj, që nga viti i kaluar, marrja e një llogarie provë kërkon komunikim me një menaxher personal, gjë që e bën të vështirë prezantimin e produktit te një klient potencial.

Situata e zakonshme: Relike e re nuk është e nevojshme në "bazë të përhershme"; ata e kujtojnë atë vetëm në momentin kur fillojnë problemet. Por ju ende duhet të paguani rregullisht (140 USD për server në muaj), dhe në një infrastrukturë cloud që shkallëzohet automatikisht shumat bëhen mjaft të mëdha. Megjithëse ekziston një opsion Pay-As-You-Go, aktivizimi i New Relic do t'ju kërkojë të rinisni aplikacionin, gjë që mund të çojë në humbjen e situatës problematike për të cilën filloi gjithçka. Jo shumë kohë më parë, New Relic prezantoi një plan të ri tarifor - Essentials, - e cila në pamje të parë duket si një alternativë e arsyeshme për Profesionale... por pas ekzaminimit më të afërt rezultoi se disa funksione të rëndësishme mungojnë (në veçanti, nuk ka Transaksionet kryesore, Gjurmimi i Kryqit të Aplikimit, Gjurmimi i Shpërndarë).

Si rezultat, ne filluam të mendonim për të kërkuar një alternativë më të lirë dhe zgjedhja jonë ra në dy shërbime: Datadog dhe Atatus. Pse mbi to?

Rreth konkurrentëve

Më lejoni të them menjëherë se ka zgjidhje të tjera në treg. Ne kemi konsideruar edhe opsionet me burim të hapur, por jo çdo klient ka kapacitet të lirë për të pritur zgjidhje të vetë-strehuara... - përveç kësaj, ato do të kërkojnë mirëmbajtje shtesë. Çifti që zgjodhëm doli të ishte më i afërti nevojat tona:

mbështetje e integruar dhe e zhvilluar për aplikacionet PHP (staku i klientëve tanë është shumë i larmishëm, por ky është një lider i qartë në kontekstin e kërkimit të një alternative për New Relic);
kosto e përballueshme (më pak se 100 USD në muaj për host);
instrumente automatike;
integrimi me Kubernetes;
Ngjashmëria me ndërfaqen New Relic është një plus i dukshëm (sepse inxhinierët tanë janë mësuar me të).

Prandaj, në fazën fillestare të përzgjedhjes, ne eliminuam disa zgjidhje të tjera të njohura, dhe në veçanti:

Tideways, AppDynamics dhe Dynatrace - për kosto;
Stackify është i bllokuar në Federatën Ruse dhe tregon shumë pak të dhëna.

Pjesa tjetër e artikullit është e strukturuar në atë mënyrë që fillimisht do të prezantohen shkurtimisht zgjidhjet në fjalë, pas së cilës do të flas për ndërveprimin tonë tipik me New Relic dhe përvojën/mbresat nga kryerja e operacioneve të ngjashme në shërbime të tjera.

Prezantimi i konkurrentëve të përzgjedhur

në Relikt i ri, ndoshta të gjithë kanë dëgjuar? Ky shërbim filloi zhvillimin e tij më shumë se 10 vjet më parë, në vitin 2008. Ne e kemi përdorur në mënyrë aktive që nga viti 2012 dhe nuk kemi pasur probleme me integrimin e një numri vërtet të madh aplikacionesh në PHP, Ruby dhe Python, dhe gjithashtu kemi pasur përvojë në integrimin me C# dhe Go. Autorët e shërbimit kanë zgjidhje për monitorimin e aplikacioneve, infrastrukturën, gjurmimin e infrastrukturave të mikroshërbimeve, krijimin e aplikacioneve të përshtatshme për pajisjet e përdoruesve dhe shumë më tepër.

Sidoqoftë, agjenti New Relic funksionon në protokolle të pronarit dhe nuk mbështet OpenTracing. Instrumentimi i avancuar kërkon modifikime posaçërisht për New Relic. Më në fund, mbështetja e Kubernetes është ende eksperimentale.

Filloi zhvillimin e tij në vitin 2010 qen i të dhënave duket dukshëm më interesante se New Relic pikërisht për sa i përket përdorimit në mjediset Kubernetes. Në veçanti, ai mbështet integrimin me protokollet NGINX Ingress, mbledhjen e regjistrave, statsd dhe OpenTracing, i cili ju lejon të gjurmoni një kërkesë të përdoruesit që nga momenti kur është lidhur deri në përfundim, si dhe të gjeni regjistrat për këtë kërkesë (si në anën e serverit të uebit dhe tek konsumatori).

Gjatë përdorimit të Datadog, kemi hasur që ndonjëherë e ka ndërtuar gabimisht hartën e mikroservisit dhe disa mangësi teknike. Për shembull, ai e identifikoi gabim llojin e shërbimit (duke ngatërruar Django për një shërbim memorie) dhe shkaktoi 500 gabime në një aplikacion PHP duke përdorur bibliotekën e njohur Predis.

Atatus - instrumenti më i ri; shërbimi u lançua në vitin 2014. Buxheti i tij i marketingut është qartësisht inferior ndaj konkurrentëve të listuar, përmendjet janë shumë më pak të zakonshme. Sidoqoftë, vetë mjeti është shumë i ngjashëm me New Relic, jo vetëm në aftësitë e tij (APM, monitorimi i shfletuesit, etj.), por edhe në pamje.

Një pengesë e rëndësishme është se ai mbështet vetëm Node.js dhe PHP. Nga ana tjetër, ai zbatohet dukshëm më mirë se Datadog. Ndryshe nga kjo e fundit, Atatus nuk kërkon që aplikacionet të bëjnë modifikime ose të shtojnë etiketa shtesë në kod.

Si punojmë me New Relic

Tani le të kuptojmë se si e përdorim në përgjithësi New Relic. Le të themi se kemi një problem që kërkon zgjidhje:

Është e lehtë të shihet në grafik spërkatje - Le ta analizojmë. Në New Relic, transaksionet në ueb zgjidhen menjëherë për një aplikacion në internet, të gjithë komponentët tregohen në grafikun e performancës, ka panele të shkallës së gabimit, shkallës së kërkesës... Ajo që është më e rëndësishmja është që direkt nga këto panele mund të lëvizni ndërmjet të ndryshëm. pjesë të aplikacionit (për shembull, klikimi në MySQL do të çojë në seksionin e bazës së të dhënave).

Meqenëse në shembullin në shqyrtim shohim një rritje të aktivitetit PHP, klikoni në këtë grafik dhe shkoni automatikisht te Transaksionet:

Lista e transaksioneve, të cilat në thelb janë kontrollues nga modeli MVC, tashmë është renditur sipas Konsumon më shumë kohë, i cili është shumë i përshtatshëm: ne menjëherë shohim se çfarë bën aplikacioni. Këtu janë shembuj të pyetjeve të gjata që mblidhen automatikisht nga New Relic. Duke ndërruar renditjen, është e lehtë të gjesh:

kontrolluesi më i ngarkuar i aplikacionit;
kontrollues i kërkuar më shpesh;
më i ngadalshëm nga kontrollorët.

Përveç kësaj, ju mund të zgjeroni çdo transaksion dhe të shihni se çfarë po bënte aplikacioni në kohën kur u ekzekutua kodi:

Së fundi, aplikacioni ruan shembuj të gjurmëve të kërkesave të gjata (ato që zgjasin më shumë se 2 sekonda). Këtu është paneli për një transaksion të gjatë:

Mund të shihet se dy metoda kërkojnë shumë kohë, dhe në të njëjtën kohë shfaqet koha kur është ekzekutuar kërkesa, URI dhe domeni i saj. Shumë shpesh kjo ndihmon për të gjetur kërkesën në regjistrat. Duke shkuar në Gjurmë detaje, mund të shihni se nga thirren këto metoda:

Dhe në Pyetjet e bazës së të dhënave — vlerësoni pyetjet në bazat e të dhënave që u ekzekutuan gjatë ekzekutimit të aplikacionit:

Të armatosur me këtë njohuri, ne mund të vlerësojmë pse aplikacioni po ngadalësohet dhe të punojmë me zhvilluesin për të krijuar një strategji për të zgjidhur problemin. Në realitet, New Relic nuk jep gjithmonë një pamje të qartë, por ndihmon në zgjedhjen e vektorit të hetimit:

gjatë PDO::Construct na çoi në funksionimin e çuditshëm të pgpoll;
paqëndrueshmëri me kalimin e kohës Memcache::Get sugjeroi që makina virtuale ishte konfiguruar gabimisht;
një kohë e rritur në mënyrë të dyshimtë për përpunimin e shabllonit çoi në një lak të ndërthurur që kontrollonte praninë e 500 avatarëve në ruajtjen e objektit;
e kështu me radhë…

Ndodh gjithashtu që në vend të ekzekutimit të kodit, diçka që lidhet me ruajtjen e të dhënave të jashtme rritet në ekranin kryesor - dhe nuk ka rëndësi se çfarë do të jetë: Redis ose PostgreSQL - të gjitha janë të fshehura në skedë Bazat e të dhënave.

Ju mund të zgjidhni një bazë specifike për kërkime dhe të renditni pyetjet - e ngjashme me mënyrën se si bëhet në Transaksionet. Dhe duke shkuar te skeda e kërkesës, mund të shihni se sa herë ndodh kjo kërkesë në secilin nga kontrollorët e aplikacionit, dhe gjithashtu të vlerësoni se sa shpesh thirret. Është shumë komode:

Skeda përmban të dhëna të ngjashme Shërbimet e Jashtme, i cili fsheh kërkesat për shërbimet e jashtme HTTP, të tilla si qasja në ruajtjen e objekteve, dërgimi i ngjarjeve te rojtari ose të ngjashme. Përmbajtja e skedës është plotësisht e ngjashme me Bazat e të Dhënave:

Konkurrentët: mundësitë dhe përshtypjet

Tani gjëja më interesante është të krahasoni aftësitë e New Relic me ato që ofrojnë konkurrentët. Fatkeqësisht, ne nuk ishim në gjendje të testonim të tre mjetet në një version të një aplikacioni që funksionon në prodhim. Megjithatë, ne u përpoqëm të krahasonim situata/konfigurime që ishin sa më identike të ishte e mundur.

1.Datadog

Datadog na përshëndet me një panel me një mur shërbimesh:

Ai përpiqet të ndajë aplikacionet në komponentë/mikroshërbime, kështu që në shembullin e aplikacionit Django do të shohim 2 lidhje me PostgreSQL (defaultdb и postgres), si dhe Selino, Redis. Puna me Datadog kërkon që ju të keni njohuri minimale të parimeve MVC: ju duhet të kuptoni se nga vijnë përgjithësisht kërkesat e përdoruesve. Kjo zakonisht ndihmon harta e shërbimeve:

Nga rruga, ka diçka të ngjashme në New Relic:

... dhe harta e tyre, për mendimin tim, është bërë më e thjeshtë dhe më e qartë: nuk shfaq përbërësit e një aplikacioni (që do ta bënte atë tepër të detajuar, si në rastin e Datadog), por vetëm shërbime ose mikroshërbime specifike.

Le të kthehemi te Datadog: nga harta e shërbimit mund të shohim që kërkesat e përdoruesve vijnë në Django. Le të shkojmë te shërbimi Django dhe më në fund të shohim se çfarë prisnim:

Fatkeqësisht, nuk ka grafik këtu si parazgjedhje Koha e transaksionit në internet, e ngjashme me atë që shohim në panelin kryesor New Relic. Megjithatë, mund të konfigurohet në vend të orarit % e kohës së shpenzuar. Mjafton ta kaloni atë në Koha mesatare për kërkesë sipas llojit... dhe tani grafiku i njohur po na shikon!

Pse Datadog zgjodhi një tabelë tjetër është një mister për ne. Një tjetër gjë frustruese është se sistemi nuk mban mend zgjedhjen e përdoruesit (ndryshe nga të dy konkurrentët), dhe për këtë arsye zgjidhja e vetme është krijimi i paneleve me porosi.

Por unë isha i kënaqur me aftësinë në Datadog për të kaluar nga këto grafikë në metrikat e serverëve të lidhur, të lexoja regjistrat dhe të vlerësoja ngarkesën në mbajtësit e serverëve të uebit (Gunicorn). Gjithçka është pothuajse e njëjtë si në New Relic... dhe madje pak më shumë (logs)!

Më poshtë grafikët janë transaksionet krejtësisht të ngjashme me New Relic:

Në Datadog, transaksionet quhen resursami. Ju mund t'i renditni kontrollorët sipas numrit të kërkesave, sipas kohës mesatare të përgjigjes dhe sipas kohës maksimale të shpenzuar për një periudhë të zgjedhur kohore.

Ju mund të zgjeroni burimin dhe të shihni gjithçka që kemi vërejtur tashmë në New Relic:

Ka statistika mbi burimin, një listë të përgjithësuar të thirrjeve të brendshme dhe shembuj kërkesash që mund të renditen sipas kodit të përgjigjes... Nga rruga, inxhinierëve tanë u pëlqeu shumë kjo renditje.

Çdo burim shembull në Datadog mund të hapet dhe studiohet:

Paraqiten parametrat e kërkesës, një tabelë përmbledhëse e kohës së shpenzuar për secilin komponent dhe një tabelë ujëvare që tregon sekuencën e thirrjeve. Ju gjithashtu mund të kaloni në një pamje peme të grafikut të ujëvarës:

Dhe gjëja më interesante është shikimi i ngarkesës së hostit në të cilin është ekzekutuar kërkesa dhe shikimi i regjistrave të kërkesave.

Integrim i madh!

Ju mund të pyesni veten se ku janë skedat Bazat e të dhënave и Shërbimet e Jashtme, si në Relike e Re. Nuk ka asnjë këtu: meqenëse Datadog e zbërthen aplikacionin në komponentë, PostgreSQL do të konsiderohet një shërbim më vete, dhe në vend të Shërbimeve të Jashtme ia vlen të kërkoni aws.storage (do të jetë e ngjashme për çdo shërbim tjetër të jashtëm që aplikacioni mund të aksesojë).

Ja një shembull me postgres:

Në thelb ka gjithçka që donim:

Ju mund të shihni se nga cili "shërbim" erdhi kërkesa.

Nuk do të ishte gabim t'ju kujtojmë se Datadog integrohet në mënyrë të përsosur me NGINX Ingress dhe ju lejon të kryeni gjurmimin nga fundi në fund që nga momenti kur një kërkesë arrin në grup, dhe gjithashtu ju lejon të merrni metrika statsd, të mbledhni regjistrat dhe metrikat e hostit. .

Një plus i madh i Datadog është çmimi i tij po merr formë nga monitorimi i infrastrukturës, APM, Log Management dhe testi Synthetics, d.m.th. Ju mund të zgjidhni planin tuaj në mënyrë fleksibël.

2.Atatus

Ekipi Atatus pretendon se shërbimi i tyre është "i njëjtë me New Relic, por më i mirë". Le të shohim nëse është vërtet kështu.

Paneli kryesor duket i ngjashëm, por nuk ishte e mundur të përcaktohej Redis dhe memcached-i i përdorur në aplikacion.

APM zgjedh të gjitha transaksionet si parazgjedhje, megjithëse zakonisht nevojiten vetëm transaksione në ueb. Ashtu si Datadog, nuk ka asnjë mënyrë për të lundruar në shërbimin e dëshiruar nga paneli kryesor. Për më tepër, transaksionet renditen pas gabimeve, gjë që nuk duket shumë logjike për APM.

Në transaksionet Atatus, gjithçka është sa më e ngjashme me New Relic. Ana negative është se dinamika për çdo kontrollues nuk është menjëherë e dukshme. Ju duhet ta kërkoni atë në tabelën e kontrolluesit, duke u renditur sipas Koha më e konsumuar:

Lista e zakonshme e kontrollorëve është e disponueshme në skedën Shiko më shumë:

Në një farë mënyre, kjo tabelë të kujton Datadog dhe më pëlqen më shumë se e ngjashme në New Relic.

Ju mund të zgjeroni çdo transaksion dhe të shihni se çfarë po bënte aplikacioni:

Paneli gjithashtu të kujton më shumë Datadog: ka një numër kërkesash, një pamje të përgjithshme të thirrjeve. Paneli i sipërm ofron një skedë gabimi Dështimet e HTTP dhe shembuj të pyetjeve të ngadalta Gjurmët e sesionit:

Nëse shkoni në një transaksion, mund të shihni një shembull të një gjurmimi, mund të merrni një listë kërkesash në bazën e të dhënave dhe të shikoni titujt e kërkesës. Gjithçka është e ngjashme me New Relic:

Në përgjithësi, Atatus i kënaqur me gjurmët e detajuara - pa ngjitjen tipike Relike të Re të thirrjeve në një bllok kujtues:

Megjithatë, i mungon një filtër që (si New Relic) do të ndërpresë kërkesat ultra të shpejta (<5 ms). Nga ana tjetër, më pëlqeu shfaqja e përgjigjes përfundimtare të transaksionit (sukses ose gabim).

Panel Bazat e të dhënave do t'ju ndihmojë të studioni kërkesat për bazat e të dhënave të jashtme që aplikacioni bën. Më lejoni t'ju kujtoj se Atatus gjeti vetëm PostgreSQL dhe MySQL, megjithëse Redis dhe memcached gjithashtu janë të përfshirë në projekt.

Kërkesat renditen sipas kritereve të zakonshme: shpeshtësia e përgjigjes, koha mesatare e përgjigjes, etj. Do të doja të përmendja gjithashtu skedën me pyetjet më të ngadalta - është shumë i përshtatshëm. Për më tepër, të dhënat në këtë skedë për PostgreSQL përkonin me të dhënat nga zgjerimi pg_stat_statements - rezultat i shkëlqyer!

Skedë Kërkesat e jashtme plotësisht identike me bazat e të dhënave.

Gjetjet

Të dy mjetet e paraqitura performuan mirë në rolin e APM. Secili prej tyre mund të ofrojë minimumin e kërkuar. Përshtypjet tona mund të përmblidhen shkurtimisht si më poshtë:

qen i të dhënave

Pro:

orar i përshtatshëm tarifor (APM kushton 31 USD për host);
ka punuar mirë me Python;
Mundësia e integrimit me OpenTracing
integrimi me Kubernetes;
integrimi me NGINX Ingress.

Cons:

i vetmi APM që bëri që aplikacioni të bëhej i padisponueshëm për shkak të një gabimi të modulit (predis);
auto-instrumentim i dobët PHP;
përkufizimi pjesërisht i çuditshëm i shërbimeve dhe qëllimit të tyre.

Atatus