🥇Jo vetëm New Relic: një vështrim në Datadog dhe Atatus

Në mesin e inxhinierëve SRE-/DevOps, nuk është e habitshme që një klient (ose sistemi i monitorimit) të vijë dhe të raportojë se "gjithçka ka humbur": faqja nuk funksionon, pagesat nuk kalojnë, jeta është e kotë… Edhe pse dëshira për të ndihmuar në një situatë të tillë është e madhe, është shumë e vështirë ta bësh këtë pa një mjet të thjeshtë dhe të kuptueshëm. Shpesh problemi është i fshehur në kodin e aplikacionit vetë – thjesht duhet ta lokalizosh atë.

Në grevë dhe në gëzim…

Ka ardhur në një pikë që tashmë e duam shumë New Relic. Ai ka qënë dhe mbetet një mjet shkëlqyer për monitorimin e performancës së aplikacioneve, si dhe lejon instrumentimin e arkitekturës mikro-shërbimeve (përmes agjentit të tij) dhe shumë e shumë gjëra të tjera. Dhe gjithçka do të ishte shkëlqyer, nëse nuk do ishin ndryshimet në politikën e çmimeve të shërbimit: çmimi i tij ç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ë llogarinë trial kërkohet komunikim me menaxherin personal, gjë që e komplikon prezantimin e produktit për klientët potencialë.

Një situatë e zakonshme: New Relic nuk është i nevojshëm "në mënyrë të përhershme", për të cilin kujtohet vetëm në momentin kur fillojnë problemet. Por megjithatë, duhet të paguhet rregullisht (140 USD për server në muaj), dhe në infrastrukturën cloud që shkallëzohet automatikisht, shumat bëhen të mëdha. Edhe pse ka mundësinë "Pay-As-You-Go", për të aktivizuar New Relic nevojitet të rindezësh aplikacionin, gjë që mund të çojë në humbjen e situatës problematike, për të cilën ishte bërë gjithçka. Para pak kohësh, New Relic prezantoi një plan të ri çmimi — Themelore, — i cili në shikim të parë duket si një alternativë e arsyeshme për Professional… por me një shqyrtim të detajuar doli se disa funksione të rëndësishme mungojnë (përfshirë Transaksionet Kryesore, Kërcimi midis Aplikacioneve, Gjetja e Shpërndarë).

Si rezultat, ne menduam për të kërkuar një alternativë më të lirë dhe zgjodhëm dy shërbime, Datadog dhe Atatus. Pse pikërisht ato?

Për konkurrentët

Së pari, duhet të them se në treg ka edhe zgjidhje të tjera. Ne madje kemi shqyrtuar variante Open Source, por jo çdo klient ka kapacitet të lirë për të akomoduar zgjidhje të kategorisë self-hosted… - plus, ato kërkojnë mirëmbajtje shtesë. Çifti që zgjodhëm doli të ishte më i afërt me nevojat tona:

support të integruar dhe të zhvilluar për aplikacionet PHP (stoku te klientët tanë është shumë i larmishëm, por ky është një lider i qartë në kontekstin e kërkimit të alternativës për New Relic);
çmim të përballueshëm (më pak se 100 USD në muaj për host);
instrumentim automatik;
integtrim me Kubernetes;
ngjashmëri me ndërfaqen e New Relic – një avantazh i dukshëm (sepse inxhinierët tanë janë mësuar me të).

Prandaj, në fazën e përzgjedhjes fillestare, ne eliminuam disa zgjidhje të tjera të njohura, sidomos:

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

Artikulli në vijim është ndërtuar në mënyrë që së pari të paraqiten shkurtimisht zgjidhjet e shqyrtuara, pastaj do të flas për ndërveprimin tonë tipik me New Relic dhe përvojat/impressionet nga realizimi i operacioneve të ngjashme në shërbime të tjera.

Prezantimi i konkurrentëve të zgjedhur

Për New Relic, ndoshta e ka dëgjuar çdo njeri? Ky shërbim filloi zhvillimin e tij më shumë se 10 vjet më parë, në vitin 2008. Ne e kemi përdorur atë aktivisht që nga viti 2012 dhe nuk kemi pasur probleme me integrimin e një numri në të vërtetë të madh aplikacionesh në gjuhët PHP, Ruby dhe Python, dhe gjithashtu patëm përvojën e integrimit me C# dhe Go. Autorët e shërbimit kanë zgjidhje për monitorimin e aplikacioneve, infrastruktura, ndjekjen e mikro-shërbimeve, janë krijuar aplikacione të përshtatshme për pajisjet e përdoruesve dhe shumë gjëra të tjera.

Megjithatë, agjenti i New Relic funksionon në protokolle proprietarë, nuk ka mbështetje për OpenTracing. Për instrumentim të avancuar, duhen bërë modifikime të veçanta për New Relic. Për më tepër, mbështetja për Kubernetes ka status eksperimental.

Një subjekt që filloi zhvillimin e tij në vitin 2010 Datadog duket shumë më interesante se New Relic në aspektin e përdorimit në mjedise Kubernetes. Në veçanti, ai mbështet integimin me NGINX Ingress, mbledhjen e logeve, protokollet statsd dhe OpenTracing, që lejon ndjekjen e kërkesës nga përdoruesi që nga momenti i lidhjes deri në përfundimin e punës, si dhe gjetjen e logeve për këtë kërkesë (si në anën e serverit web ashtu edhe në anën e konsumatorëve).

Në përdorimin e Datadog ne u ballafaquan me faktin se ndonjëherë ndërlidhte gabimisht hartën e mikro-shërbimeve, dhe disa mangësi teknike. Për shembull, ai identifikoi gabim llojin e shërbimit (e përshteti Django si një shërbim të caching) dhe shkaktonte gabimet 500 në aplikacionin PHP që përdorte bibliotekën e njohur Predis.

Atatus — është mjeti më i ri; shërbimi u lançua në vitin 2014. Buxheti i tij marketing është dukshëm më i vogël se ai i konkurrentëve të listuar, përmendjet janë shumë më të pakta. Megjithatë, vetë mjeti ngjason shumë me New Relic, jo vetëm në funksionalitete (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ë zbatuar ndjeshëm më mirë se në Datadog. Në kundërshtim me këtë të fundit, Atatus nuk kërkon nga aplikacionet ndryshime apo shënime të mëtejshme në kod.

Si punojmë me New Relic

Tani le të shqyrtojmë se si ne zakonisht e përdorim New Relic. Supozoni se kemi një problem që kërkon zgjidhje:

Në grafik është e lehtë të vëresh një kulm — do ta analizojmë atë. Në New Relic për aplikacionin e webit, janë në përzgjedhje automatikisht transaksionet web, në grafikën e performancës janë shënuar të gjitha komponentët, janë të pranishme panellat e shkallës së gabimeve, shkallës së kërkesave... Çfarë është më e rëndësishme — drejtpërdrejt nga këto panella mund të kalosh midis pjesëve të ndryshme të aplikacionit (për shembull, klikimi në MySQL do të të çojë në seksionin e bazave të të dhënave).

Përsa i përket shembullit të shqyrtuar, ne shohim një kulm aktivizimi PHP, do të klikojmë në këtë grafik dhe automatikisht do të kalojmë në Transaksionet:

Lista e transaksioneve, të cilat janë në thelb kontrolerët nga modeli MVC, është e renditur tashmë sipas Më shumë koha konsumuar, që është shumë e mirë: ne menjëherë shohim se me çfarë merret aplikacioni. Po ashtu, këtu ka shembuj të kërkesave të gjata, të cilat grumbullohen automatikisht nga New Relic. Duke ndryshuar renditjen, është lehtë të gjejmë:

kontroleri më i ngarkuar i aplikacionit;
kontroleri më i kërkuar;
kontroleri më i ngadalshëm.

Gjithashtu, mund të zgjerosh çdo transaksion dhe të shohësh se çfarë po bëhej në momentin e ekzekutimit të kodit:

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

Është e dukshme se shumë kohë zënë dy metoda, dhe së bashku me këtë tregohet edhe koha kur është ekzekutuar kërkesa, URI e saj dhe domeni. Shpesh ndihmon të gjejmë kërkesën në logjet. Duke kaluar në Detajet e gjurmës, mund të shohim se nga ku thirren këto metoda:

Dhe në Kërkesat në bazat e të dhënave — vlerëso kërkesat për bazat e të dhënave që janë ekzekutuar gjatë punës së aplikacionit:

Me këto njohuri, mund të vlerësojmë shkakun e ngadalësimit të aplikacionit dhe të punojmë së bashku me zhvilluesin për të formuluar një strategji zgjidhjeje. Në realitet, New Relic nuk jep gjithmonë një panoramë të qartë, megjithatë ndihmon në zgjedhjen e drejtimit të hetimit:

i gjatë PDO::Construct na çoi në funksionimin e çuditshëm të pgpoll;
ndeshtje me kohën Memcache::Get na sugjeroi për konfigurimin e gabuar të makinës virtuale;
koha e përpunimit të modelit u rrit nga një cikël i brendshëm me kontrollin e pranisë së 500 avatarëve në magazinën objekt.
dhe kështu me radhë...

Ndonjëherë ndodh që në vend të ekzekutimit të kodit në ekranin kryesor, diçka rritet lidhur me ruajtjen e jashtme të të dhënave — dhe nuk ka rëndësi se çfarë do të jetë: Redis apo PostgreSQL, — të gjitha ato fshehen nën skedën Databases.

Mund të zgjedhësh një bazë të caktuar për të hetuar dhe të bësh renditjen e kërkesave — njësoj si ndodh në Transaksione. Dhe duke kaluar në skedën e kërkesës, mund të shohësh se sa shpesh shfaqet kjo kërkesë në çdo një nga kontrollerët e aplikacionit, si dhe të vlerësosh se sa shpesh thirret. Kjo është shumë e dobishme:

Të dhëna të ngjashme përmban skeda Shërbimet e Jashtme, e cila fsheh kërkesat për shërbimet HTTP të jashtme, siç është ndihma për objektet e ruajtjes, dërgimi i ngjarjeve në sentry ose diçka të ngjashme. Sipas përmbajtjes, kjo skedë është plotësisht e ngjashme me Bazat e të dhënave:

Konkurrentët: mundësi dhe përvoja

Tani gjëja më interesante — le të krahasojmë mundësitë e New Relic me ato që ofrojnë konkurrentët. Fatkeqësisht, ne nuk arritëm të verifikojmë të tre mjetet në të njëjtën version të një aplikacioni në prodhim. Megjithatë, ne u përpoqëm të krahasojmë situatat/konfigurimet më identike.

1. Datadog

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

Ai përpiqet t'i ndajë aplikacionet në komponentë/miqrosërvishte, prandaj në aplikacionin Django të marrë si shembull do të shohim 2 lidhje me PostgreSQL (defaultdb dhe postgres), si dhe Celery, Redis. Puna me Datadog kërkon njohuri minimale mbi principet e MVC: duhet të kuptosh se ku vijnë kërkesat e përdoruesve. Zakonisht kjo ndihmohet nga harta e shërbimeve:

Tani, një gjë e ngjashme ka dhe në New Relic:

… dhe për më tepër, harta e tyre, sipas mendimit tim, është bërë më thjesht dhe qartë: ajo paraqet jo komponentët e një aplikacioni (gjë që do ta bënte tepër të detajuar, siç ndodh në Datadog), por vetëm shërbime specifike ose mikrosërvishte.

Kthemi te Datadog: nga harta e shërbimeve, shihet qartë se kërkesat e përdoruesve vijnë në Django. Le të kalojmë në shërbimin Django dhe përfundimisht do të shohim atë që prisnim:

Fatkeqësisht, këtu nuk ka grafikë me të cilin jemi mësuar Koha e transaksionit web, i ngjashëm me atë që shohim në panelin kryesor të New Relic. Megjithatë, mund ta konfigurojmë atë për të zëvendësuar grafikën % e kohës së kaluar. Mjafton ta kalojmë në Koha mesatare për kërkesë sipas llojit… dhe tani grafikja e njohur na vështron!

Pse në Datadog u zgjodh një grafik tjetër — mbetet një mister për ne. Na shqetësoi gjithashtu fakti që sistemi nuk e mban mend zgjedhjen e përdoruesit (ndryshe nga të dy konkurentët), dhe për këtë arsye — krijimi i panelëve të personalizuar është shpëtimi i vetëm.

Megjithatë, na gëzoi mundësia në Datadog për të kaluar nga këto grafikë në metrikat e serverëve të lidhur, për të lexuar logët dhe për të vlerësuar ngarkesën e përpunuesve të web-serverit (Gunicorn). Është pothuajse si në New Relic… dhe madje disa më shumë (logët)!

Poshtë grafikëve ndodhen transaksionet, të ngjashme me ato të New Relic:

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

Burimi mund të zgjerohet dhe të shohim gjithçka që kemi parë tashmë në New Relic:

Janë të pranishme statistikat për burimin, një listë përmbledhëse të thirrjeve të brendshme dhe shembujt e kërkesave, të cilat mund të renditen sipas kodit të përgjigjes… Për të qenë të sinqertë, kjo renditje u pëlqeu shumë inxhinierëve tanë.

Çdo shembull burimi në Datadog mund të zgjerohet dhe të studiohet:

Prezentohen parametrat e kërkesës, një diagram përmbledhës për kohën e kaluar në çdo komponent dhe një diagram uji, në të cilin shikohet renditja e thirrjeve. Po ashtu është e mundur kalimi në pamjen e pemës për diagramin uji:

Dhe më e rëndësishmja — shikimi i ngarkesës së hostit, në të cilin ishte ekzekutuar kërkesa, dhe tregimi i logëve të kërkesës.

Integrim i shkëlqyer!

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

Ja një shembull me postgres:

Në thelb, është gjithçka që donim:

Shikohet nga cili "shërbim" ka ardhur kërkesa.

Nuk do të ishte e tepërt të kujtojmë se Datadog mund të integrohet shkëlqyer me NGINX Ingress dhe lejon të bëhet ndjekje e plotë që nga momenti i marrjes së kërkesës në grup, si dhe lejon marrjen e metrikave statsd, mbledhjen e logëve dhe metrikave të hosteve.

Një avantazh i madh i Datadog është se çmimi i tij përbëhet nga monitorimi i infrastrukturës, APM, menaxhimi i logëve dhe testimi i sintetikëve, dmth. mund të përzgjidhet fleksibël një plan.

2. Atatus

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

Paneli i titullit në të vërtetë duket i ngjashëm, por nuk arrita të identifikoj Redis dhe memcached që përdoren në aplikacion.

APM përzgjat automatikisht të gjitha transaksionet, megjithatë, zakonisht ne kemi nevojë vetëm për ato Web. Ashtu si në Datadog, nuk ka mundësi për të kaluar në shërbimin e nevojshëm nga paneli kryesor. Për më tepër, transaksionet janë në listë pas gabimeve, çka për APM nuk duket shumë logjike.

Në transaksionet e Atatus, gjithçka është maksimalisht e ngjashme me New Relic. Minus — menjëherë nuk shikohet dinamika për secilin nga kontrollorët. Duhet ta kërkosh atë në tabelën e kontrollorëve, duke e renditur sipas Koha më e Madhe e Konsumuar:

Lista e kontrollorëve që na është e njohur është e aksesueshme në skedën Eksploro:

Kjo tabelë ndonjëherë i ngjan Datadog dhe është më e pëlqyer se e ngjashmja në New Relic.

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

Paneli gjithashtu ngjan më shumë me Datadog: ka numrin e kërkesave, pamjen e përgjithshme të thirrjeve. Paneli i sipërm ofron një skedë me gabime Gabimet HTTP dhe shembuj të kërkesave të ngadalta Gjetjet e Sesionit:

Nëse kaloni në transaksion, shikohet një shembull i gjurmës, mund të merrni një listë kërkesash për bazën dhe të shikoni titujt e kërkesës. Gjithçka është ngjashme me New Relic:

Në të vërtetë, Atatus na befasoi me gjurmët e detajuara — pa ngjashmëritë tipike të New Relic me blloqet përmendore:

Megjithatë, këtu mungon një filtr që bllokon kërkesat super të shpejta (<5ms), ashtu si në New Relic. Nga ana tjetër, paraqitja e përgjigjes përfundimtare të transaksionit (e suksesshme apo gabim) na pëlqeu.

Panairi Databases do të ndihmojë për të studiuar kërkesat për bazat e jashtme, që aplikacioni i bën. Jua kujtoj, Atatus e identifikoi vetëm PostgreSQL dhe MySQL, megjithëse në projekt janë të angazhuar gjithashtu Redis dhe memcached.

Kërkesat renditen sipas kritereve të njohura: frekuenca e ndodhjes, koha mesatare e përgjigjes dhe kështu me radhë. Duhet përmendur veçmas ndarja me kërkesat më të ngadalta — kjo është shumë e dobishme. Më shumë se kaq, të dhënat në këtë ndarje për PostgreSQL përputhen me të dhënat nga shtesa. pg_stat_statements — rezultat i shkëlqyer!

Skeda Kërkesat e Jashtme është plotësisht identike me Databases.

Përfundimet

Të dy mjetet e paraqitura kanë dhënë një performancë të mirë si APM. Çdo njëri prej tyre mund të ofrojë minimumin e nevojshëm. Për të përmbledhur përvojat tona, mund të themi:

Datadog

Avantazhet:

një strukturë tarifore të këndshme (APM kushton 31 USD për host);
u tregua i shkëlqyer me Python;
mundësia e integrimit me OpenTracing
integtrim me Kubernetes;
integrimi me NGINX Ingress.

Disavantazhet:

APM i vetëm që shkaktoi papajisje të aplikacionit për shkak të një gabimi të modulit (predis);
auto-instrumentimi i dobët PHP;
disa herë definicion i çuditshëm i shërbimeve dhe qëllimeve të tyre.

Atatus

Avantazhet:

instrumentim të thellë PHP;
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ë programimi (Node.js dhe PHP);
puna e ngadalshme e ndërfaqes.

Duke marrë parasysh çmimin e Atatus prej 69 USD në muaj për server, ne do të preferonim të përdorim Datadog, i cili integrohet shkëlqyeshëm sipas nevojave tona (aplikacione web në K8s) dhe ka shumë funksione të dobishme.