🥇Jo vetëm me New Relic: një pamje në Datadog dhe Atatus

Në mesin e inxhinierëve SRE/DevOps, askush nuk do të befasohej se një klient (ose sistem monitorimi) një herë do të informojë se "gjithçka ka shkuar keq": faqja nuk funksionon, pagesat nuk kalojnë, jeta është e kotë... Sa do që dëshirojmë të ndihmojmë në një situatë të tillë, ta bëjmë këtë pa një mjet të thjeshtë e të kuptueshëm është shumë e vështirë. Shpesh problemi është i fshehur në kodin e vetë aplikacionit — thjesht duhet ta lokalizoni atë.

Në mëngjes e në mbrëmje…

Kështu ndodhi që ne e dashurojmë New Relic prej kaq shumë kohësh. Ai ka qenë dhe mbetet një mjet i shkëlqyer për monitorimin e performancës së aplikacionit, si dhe lejon instrumentimin e arkitekturës mikroshërbimore (me anë të agjentit të tij) dhe shumë e shumë më tepër. Dhe gjithçka do të ishte e shkëlqyer, nëse nuk do të ishin ndryshimet në politikën e çmimeve të shërbimit: çmimi nga viti 2013 ka rritur më shumë se 3 herë. Për më tepër, që nga viti i kaluar për të marrë një llogari për provë kërkohet komunikimi me një menaxher personal, që e vështirëson prezantimin e produktit për klientët potencialë.

Një situatë e zakonshme: New Relic nuk nevojitet në "bazë të përhershme", për të, kujtohen vetëm në atë moment kur fillojnë problemet. Por gjithsesi duhet paguar rregullisht (140 USD për server në muaj), dhe në infrastrukturën cloud që automatikisht shkallon, shumat bëhen të mëdhaja. Edhe pse ka mundësi "Pay-As-You-Go", por për të aktivizuar New Relic nevojitet rivendosja e aplikacionit, që mund të çojë në humbjen e atij problemi, për të cilin u nisa gjithçka. Jo shumë kohë më parë, New Relic prezantoi një plan të ri çmimi — Essentials, — i cili në shikim të parë duket si një alternativë e arsyeshme për Professional… por pas shqyrtimit të detajuar doli se disa funksione të rëndësishme mungonin (në veçanti, ai nuk përmban Transaksionet Kyçe, Marrëveshje ndër-aplikative, Gjetja e shpërndarë).

Si rezultat, ne filluam të mendojmë për kërkimin e një alternative më të lirë, dhe zgjedhja jonë ra mbi dy shërbime Datadog dhe Atatus. Pse pikërisht ato?

Për konkurentët

Të them të drejtën, në treg ekzistojnë edhe zgjidhje të tjera. Ne madje shqyrtuam mundësi Open Source, por jo të gjithë klientët kanë kapacitete të lira për të akomoduar zgjidhjet e kategorisë së vetë-hostuar… — për më tepër, ato do të kërkonin mbështetje të mëtejshme. Çifti që kemi zgjedhur doli të ishte më i afërt me nevojat tona:

mbështetje e integruar dhe e zhvilluar për aplikacionet PHP (stoku i klientëve tanë është shumë i ndryshëm, por ky është lider i qartë në kontekstin e kërkimit të alternativave për New Relic);
çmimi i arsyeshëm (më pak se 100 USD në muaj për host);
instrumentim automatik;
integrimi me Kubernetes;
ngjashmëria me ndërfaqen e New Relic — një plus i dukshëm (pasi inxhinierët tanë janë mësuar me të).

Prandaj, në fazën e përzgjedhjes fillestare, ne përjashtuam disa zgjidhje të njohura, në veçanti:

Tideways, AppDynamics dhe Dynatrace — për çmimin;
Stackify — i bllokuar në RF dhe tregon shumë pak të dhëna.

Artikulli i mëtejmë është ndërtuar në mënyrë të tillë, që fillimisht do të paraqiten shkurtimisht zgjidhjet e shqyrtuara, e më pas do të flas për ndërveprimin tonë tipik me New Relic dhe përvojën / përshtypjet nga realizimi i operacioneve të ngjashme në shërbime të tjera.

Prezantimi i konkurrentëve të përzgjedhur

Për New Relic, ndoshta, ka dëgjuar çdo kush? Ky shërbim filloi zhvillimin e tij më shumë se 10 vjet më parë, në vitin 2008. Ne e përdorim atë aktivisht që nga viti 2012 dhe nuk kemi përjetuar probleme me integrimin e një numri të vërtetë të aplikacioneve në gjuhët PHP, Ruby dhe Python, gjithashtu kemi pasur përvojë integrimi me C# dhe Go. Autorët e shërbimit kanë zgjidhje për monitorimin e aplikacioneve, infrastrukturës, gjurmimin e infrastrukturave të mikroshërbimeve, janë krijuar aplikacione praktike për pajisjet e përdoruesve dhe shumë më tepër.

Megjithatë, agjenti New Relic punon me protokolle pronësore, nuk ka mbështetje për OpenTracing. Për instrumentimin e avancuar kërkohen ndryshime të veçanta për New Relic. Së fundmi, mbështetja për Kubernetes aktualisht ka status eksperimental.

Duke filluar zhvillimin e tij në vitin 2010 Datadog shfaqet dukshëm më interesante se New Relic në aspektin e aplikimeve në mjedise Kubernetes. Në veçanti, ai mbështet integrimin me NGINX Ingress, mbledhjen e log-eve, protokollet statsd dhe OpenTracing, gjë që lejon ndjekjen e kërkesës së përdoruesit nga momenti i lidhjes deri në përfundimin e punës, si dhe gjetjen e log-eve për këtë kërkesë (si nga ana e serverit të uebit ashtu edhe nga ana e konsumatorëve).

При përdorimin e Datadog, ne u përballëm me faktin se ai ndonjëherë ndreqte gabimisht hartën e mikroshërbimeve dhe disa defekte teknike. Për shembull, ai nuk e përcaktonte saktë llojin e shërbimit (e perceptoi Django si një shërbim të caches) dhe shkaktonte gabime 500 në aplikacionin PHP që përdorte bibliotekën e njohur Predis.

Atatus është mjeti më i ri; shërbimi është nisur në vitin 2014. Buxheti i tij marketing është dukshëm më i vogël se ai i konkurentëve të përmendur, përmendjet e tij paraqiten shumë më rarë. Megjithatë, mjeti vetë është shumë i ngjashëm me New Relic, jo vetëm në mundësitë (APM, monitorimi i shfletuesit, etj.), por edhe në pamjen e tij.

Një disavantazh i rëndësishëm është mbështetja vetëm për Node.js dhe PHP. Nga ana tjetër, ajo është realizuar dukshëm më mirë se te Datadog. Në ndryshim nga i fundit, Atatus nuk kërkon që aplikacionet të bëjnë ndryshime dhe të vendosin etiketa shtesë në kod.

Si punojmë me New Relic

Tani do të kuptojmë se si ne zakonisht përdorim New Relic. Le të themi që kemi një problem që kërkon zgjidhje:

Në grafik është lehtë të vëresh një shpërthim të analizojmë atë. Në New Relic për aplikacionin web, menjëherë janë zgjedhur transaksionet web, në grafikun e performancës janë të treguara të gjitha komponentët, janë të pranishme panelet e error-rate, request-rate... Çfarë është kryesore — direkt nga këto panele mund të kalosh midis pjesëve të ndryshme të aplikacionit (p.sh., klikimi në MySQL do të të çojë në seksionin e bazave të të dhënave).

Duke qenë se në shembullin e shqyrtuar ne shohim një shpërthim aktiviteti PHP, le të klikojmë në këtë grafik dhe automatikisht kalojmë në Transaksionet:

Lista e transaksioneve, të cilat për thelb janë kontrollet nga modeli MVC, tashmë janë renditur sipas Më shumë kohën që konsumon, gjë që është shumë e përshtatshme: ne menjëherë shohim atë me të cilën merret aplikacioni. Këtu gjithashtu ka shembuj të kërkesave të gjata, të cilat grumbullohen automatikisht nga New Relic. Duke ndryshuar renditjen, është lehtë të gjesh:

kontrollori më i ngarkuar i aplikacionit;
kontrollori më shpesh i kërkuar;
kontrollori më i ngadaltë.

Përveç kësaj, është e mundur të hapësh çdo transaksion dhe të shohësh se çfarë ka bërë aplikacioni gjatë ekzekutimit të kodit:

Në fund, në aplikacion ruhen shembuj të gjurmëve të kërkesave të gjata (të cilat ekzekutohen për më shumë se 2 sekonda). Këtu është paneli për një transaksion të gjatë:

Është e qartë se dy metodat e mbajnë shumë kohë, dhe përveç kësaj tregohet edhe koha kur është bërë kërkesa, URI i saj dhe domeni. Shumë shpesh kjo ndihmon të gjejmë kërkesën në log. Duke shkuar në Detajet e gjurmimit, mund të shikojmë se nga kanë ardhur këto metoda:

Dhe në Kërkesat ndaj bazës së të dhënave — vlerësoni kërkesat ndaj bazave të të dhënave që u ekzekutuan në momentin e funksionimit të aplikacionit:

Me këto njohuri, ne mund të vlerësojmë shkakun e ngadalësimit të aplikacionit dhe së bashku me zhvilluesin të hartojmë një strategji për të zgjidhur problemin. Në të vërtetë, New Relic nuk gjithmonë ofron një pamje të qartë, megjithatë ndihmon në zgjedhjen e drejtimit të hetimit:

e gjatë PDO::Construct na çoi në një funksionim të çuditshëm të pgpoll;
pamundësi në kohë Memcache::Get na sugjeroi për një konfigurim të papërshtatshëm të makinës virtuale;
një rritje e dyshimtë e kohës për përpunimin e modelit solli në një cikël të ndërlidhur me kontrollin e pranisë së 500 avatarëve në depot objekt;
dhe kështu me radhë…

Ndodhin gjithashtu raste ku në vend të ekzekutimit të kodit në ekranin kryesor rritet diçka e lidhur me ruajtjen e të dhënave nga jashtë — dhe nuk ka rëndësi se çfarë do të jetë kjo: Redis ose PostgreSQL, — të gjitha ato fshihen në skedën Databases.

Mund të zgjidhni një bazë specifike për hetim dhe të bëni renditjen e kërkesave — ashtu siç bëhet në Transactions. Dhe duke kaluar në skedën e kërkesës, mund të shihni sa herë shfaqet kjo kërkesë në secilin nga kontrollet e aplikacionit, si dhe të vlerësoni sa shpesh ajo thirret. Kjo është shumë e dobishme:

Të dhëna të ngjashme përmban skeda Shërbimet e Jashtme, e cila fshin brenda kërkesat ndaj shërbimeve HTTP nga jashtë, të tilla si thirrja në depot e objekteve, dërgimi i ngjarjeve në Sentry ose diçka e tillë. Në përmbajtjen e saj, skeda është plotësisht e ngjashme me Databases:

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

Tani pjesa më interesante — le të krahasojmë mundësitë e New Relic me ato që ofrojnë konkurrentët. Fatkeqësisht, nuk arritëm të testojmë të tre instrumentet në një version të një aplikacioni që funksionon në prodhim. Megjithatë, përpiqemi të krahasojmë situatat/konfigurimet më identike.

1. Datadog

Datadog na pret me një panel që ka një mur shërbimesh:

Ai tenton të ndajë aplikacionet në komponentë/mikroshërbime, prandaj në aplikacionin Django të dhënë si shembull do të shohim 2 lidhje me PostgreSQL (defaultdb dhe postgres), si gjithashtu Celery, Redis. Puna me Datadog kërkon nga ju njohuri minimale të parimeve MVC: duhet të kuptoni se ku arrijnë kërkesat e përdoruesve. Zakonisht kjo ndihmohet harta e shërbimeve:

A, për të vërtetë, ka diçka të ngjashme edhe në New Relic:

… ndonëse harta e tyre, sipas mendimit tim, është e bërë më thjeshtë dhe më qartë: ajo tregon vetëm shërbimet ose mikroshërbimet specifike (çka do ta bënte atë tepër të detajuar siç është rasti me Datadog).

Të kthehemi te Datadog: nga harta e shërbimeve duket se kërkesat e përdoruesve arrijnë në Django. Të kalojmë te shërbimi Django dhe më në fund të shohim atë që prisnim:

Fatkeqësisht, për default këtu nuk ka grafik Koha e transaksionit Web, ekuivalent me atë që shohim në panelin kryesor të New Relic. Megjithatë, mund të konfigurohet në vendin e grafikëve % e kohës së kaluar. Mjafton ta kalosh atë në Koha mesatare për kërkesë sipas Llojit… dhe ja, tani na shikon një grafik i njohur!

Pse Datadog zgjodhi një grafik tjetër — për ne është një mister. Na shqetësoi gjithashtu se sistemi nuk e ruan zgjedhjen e përdoruesit (ndryshe nga të dy konkurrentët), kështu që — shpëtimi është krijimi i paneleve përdoruese.

Ndërsa na gëzoi mundësia në Datadog për të kaluar nga këta grafika në metrikat e serverëve të lidhur, të lexojmë logjet dhe të vlerësojmë ngarkesën e trajtuesve të serverëve web (Gunicorn). Të gjitha janë pothuajse si në New Relic… dhe madje disa më shumë (logjet)!

Poshtë grafikëve ndodhen transaksionet, plotësisht analoge me New Relic:

Në Datadog, transaksionet quhen burime. Mund të renditen kontrolluesit sipas numrit të kërkesave, sipas kohës mesatare të përgjigjes, sipas kohës maksimale të harxhuar për periudhën e zgjedhur.

Burimi mund të shtrihet dhe të shihni të gjitha ato që kemi parë tashmë në New Relic:

Në dispozicion janë statistikat për burimin, një listë e përmbledhur e thirrjeve të brendshme dhe shembuj të kërkesave, të cilat mund të renditen sipas kodit të përgjigjes… Në këtë drejtim, kjo renditje u pëlqeu shumë inxhinierëve tanë.

Çdo shembull burimi në Datadog mund të jetë i hapur dhe i studiuar:

Janë paraqitur parametrat e kërkesës, një diagram përmbledhës mbi kohën e kaluar për secilin nga komponentët dhe një diagram-fall, në të cilin shikohet rendi i thirrjeve. Gjithashtu është e disponueshme kalimi në pamjen me degëzuese të diagramit-fall:

Dhe gjëja më interesante është se mund të shihni ngarkesën e hostit, mbi të cilin u ekzekutua kërkesa, si dhe logët e kërkesës.

Integrim i shkëlqyeshëm!

Mund të lindë pyetja, ku janë tabulatet Databases dhe Shërbimet e Jashtme, si në New Relic. Këtu nuk i kemi: pasi Datadog analizon aplikacionin në komponentë, PostgreSQL do të konsiderohet si një shërbim të veçantë, dhe në vend të Shërbimeve të Jashtme duhet të kërkoni aws.storage (po njësoj do të jetë edhe për çdo shërbim tjetër të jashtëm me të cilin aplikacioni mund të lidhet).

Ja një shembull nga postgres:

Në thelb, ka gjithçka që dëshironim:

Shikohet se nga cili "shërbim" erdhi kërkesa.

Nuk do të ishte e tepërt të kujtojmë se Datadog integrohet shkëlqyeshëm me NGINX Ingress dhe lejon gjurmimin e plotë nga momenti i mbërritjes së kërkesës në klaster, si dhe lejon marrjen e metrikave statsd, grumbullimin e logëve dhe metrikave të hostëve.

Një përparësi e madhe e Datadog është se çmimi i tij përbëhet nga monitorimi i infrastrukturës, APM, Menaxhimi i Logëve dhe Testet Synthetics, dmth. mund të zgjidhni planin në mënyrë fleksible.

2. Atatus

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

Paneli kryesor duket vërtet i ngjashëm, por nuk arritëm të përcaktojmë përdorimin e Redis dhe memcached në aplikacion.

APM përzgjedh të gjitha transaksionet nga e drejta, ndonëse zakonisht nevojiten vetëm ato Web. Ashtu si në Datadog, nuk ka mundësi të kalosh në shërbimin e nevojshëm nga paneli kryesor. Akoma më shumë, transaksionet ndodhen në listë pas gabimeve, gjë që nuk duket shumë logjike për APM.

Në transaksionet e Atatus është maksimalisht e ngjashme me New Relic. Pika negative është se nuk shikohet menjëherë dinamika për çdo një nga kontrolluesit. Ajo duhet të kërkohet në tabelën e kontrolluesve, duke u renditur sipas Most Time Consumed:

Lista e njohur e kontrolluesve është e disponueshme në skedën Explore:

Kjo tavëll na kujton diku Datadog dhe na pëlqen më shumë se ajo e ngjashme në New Relic.

Çdo transaksion mund të shfaqet dhe të shikohet se çfarë ka bërë aplikacioni:

Paneli gjithashtu i ngjan më shumë Datadog: ka numrin e kërkesave, pamjen e përgjithshme të thirrjeve. Paneli i sipërm ofron skedën me gabime HTTP Failures dhe shembuj të kërkesave të ngadalta Session Traces:

Nëse kaloni në transaksion, do të shihni një shembull trace, mund të merrni listën e kërkesave në bazë të të dhënave dhe të shihni titujt e kërkesës. Gjithçka është si në New Relic:

Në tërësi, Atatus na kënaq me detajet e gjurmimeve — pa ngjashmërinë tipike për New Relic të thirrjeve të ngjitura në bllokun kujtesë:

Megjithatë, këtu mungon një filtrimi që do të priste kërkesat super të shpejta (<5ms) (si në New Relic). Nga ana tjetër, shfaqja e përgjigjes përfundimtare të transaksionit (sukses ose gabim) ishte e këndshme.

Paneli Databases do të ndihmojë në studimin e kërkesave ndaj bazave të dhënash të jashtme që bën aplikacioni. Përkujtoj që Atatus gjeti vetëm PostgreSQL dhe MySQL, ndonëse në projekt janë përdorur edhe Redis dhe memcached.

Kërkesat renditen sipas kritereve të njohura: frekuenca e ndodhjes, koha mesatare e përgjigjes dhe kështu me radhë. Veçanërisht dua të theksoj tabin me kërkesat më të ngadalta — është shumë e përshtatshme. Për më tepër, të dhënat në këtë tab me PostgreSQL përputhen me të dhënat nga zgjerimi pg_stat_statements — një rezultat i shkëlqyer!

Tabi Kërkesat Eksterne është plotësisht identike me Databases.

Përfundimet

Të dy mjetet e paraqitura kanë treguar performancë të mirë si APM. Çdo një prej tyre mund të ofrojë minimumin e nevojshëm. Të përmbledhim shkurtimisht përshtypjet tona:

Datadog

Avantazhet:

një dërrasë tarifore komode (APM kushton 31 USD për host);
treguar njohuri të shkëlqyer me Python;
mundësia e integrimit me OpenTracing
integrimi me Kubernetes;
integrimi me NGINX Ingress.

Disavantazhet:

APM i vetëm që shkaktoi mungesë funksionaliteti të aplikacionit për shkak të një gabimi në modul (predis);
auto-instrumentimi i dobët PHP;
pjesërisht definimi i çuditshëm i shërbimeve dhe qëllimeve të tyre.

Atatus

Avantazhet:

instrumentimi i thellë PHP;
një ndërfaqe e ngjashme me New Relic.

Disavantazhet:

nuk funksionon në sistemet operative të vjetra (Ubuntu 12.05, CentOS 5);
auto-instrumentimi i dobët;
mbështetje për vetëm dy gjuhë programuese (Node.js dhe PHP);
funksionimi i ngadalshëm i ndërfaqes.

Duke marrë parasysh çmimin e Atatus prej 69 USD në muaj për serverin, ne do të preferonim të përdornim Datadog, i cili integrohet shkëlqyer me nevojat tona (aplikacione në K8s) dhe ka shumë funksione të dobishme.