🥇Nu numai relicva nouă: o privire asupra Datadog și Atatus

În mediul inginerilor SRE/DevOps, nu va surprinde pe nimeni ca într-o zi să apară un client (sau un sistem de monitorizare) și să raporteze că „totul este pierdut”: site-ul nu funcționează, plățile nu trec, viața decade. ... Indiferent cât de mult ai dori să ajuți într-o astfel de situație, poate fi foarte dificil să faci asta fără un instrument simplu și ușor de înțeles. Adesea, problema este ascunsă în codul aplicației în sine; trebuie doar să o localizați.

Și în tristețe și în bucurie...

S-a întâmplat să ne îndrăgostim de mult și profund de New Relic. A fost și rămâne un instrument excelent pentru monitorizarea performanței aplicațiilor și, de asemenea, vă permite să instrumentați arhitectura microservicii (folosind agentul său) și multe, multe altele. Și totul ar fi putut fi grozav dacă nu ar fi fost schimbări în politica de preț a serviciului: acesta costul din anul 2013 a crescut de peste 3 ori. In plus, de anul trecut, obtinerea unui cont de proba necesita comunicarea cu un manager personal, ceea ce face dificila prezentarea produsului unui potential client.

Situația obișnuită: New Relic nu este necesară „permanent”; își amintesc de aceasta doar în momentul în care încep problemele. Dar tot trebuie să plătiți în mod regulat (140 USD pe server pe lună), iar într-o infrastructură cloud cu scalare automată, sumele se adună destul de mari. Deși există o opțiune Pay-As-You-Go, activarea New Relic va necesita repornirea aplicației, ceea ce poate duce la pierderea situației problematice pentru care a fost pornită totul. Nu cu mult timp în urmă, New Relic a introdus un nou plan tarifar - Essentials, - care la prima vedere pare o alternativă rezonabilă la Professional... dar la o examinare mai atentă s-a dovedit că lipsesc unele funcții importante (în special, nu are Tranzacții cheie, Urmărirea aplicațiilor încrucișate, Urmărire distribuită).

Drept urmare, am început să ne gândim să căutăm o alternativă mai ieftină, iar alegerea noastră a căzut pe două servicii: Datadog și Atatus. De ce pe ei?

Despre concurenți

Să spun imediat că există și alte soluții pe piață. Am luat în considerare chiar și opțiuni Open Source, dar nu fiecare client are capacitatea liberă de a găzdui soluții auto-găzduite... - în plus, vor necesita întreținere suplimentară. Cuplul ales de noi s-a dovedit a fi cel mai apropiat nevoile noastre:

suport încorporat și dezvoltat pentru aplicațiile PHP (stiva clienților noștri este foarte diversă, dar acesta este un lider clar în contextul căutării unei alternative la New Relic);
cost accesibil (mai puțin de 100 USD pe lună per gazdă);
instrumentare automată;
integrare cu Kubernetes;
Asemănarea cu interfața New Relic este un plus vizibil (pentru că inginerii noștri sunt obișnuiți cu asta).

Prin urmare, în etapa inițială de selecție, am eliminat câteva alte soluții populare, și în special:

Tideways, AppDynamics și Dynatrace - contra cost;
Stackify este blocat în Federația Rusă și arată prea puține date.

Restul articolului este astfel structurat încât soluțiile în cauză să fie mai întâi prezentate pe scurt, după care voi vorbi despre interacțiunea noastră tipică cu New Relic și despre experiența/impresiile din efectuarea de operațiuni similare în alte servicii.

Prezentarea concurenților selectați

despre noul Relic, probabil că toată lumea a auzit? Acest serviciu și-a început dezvoltarea cu mai bine de 10 ani în urmă, în 2008. Îl folosim în mod activ din 2012 și nu am avut probleme în integrarea unui număr foarte mare de aplicații în PHP, Ruby și Python și am avut, de asemenea, experiență în integrarea cu C# și Go. Autorii serviciului au soluții pentru monitorizarea aplicațiilor, a infrastructurii, a urmăririi infrastructurilor de microservicii, a creat aplicații convenabile pentru dispozitivele utilizatorului și multe altele.

Cu toate acestea, agentul New Relic rulează pe protocoale proprietare și nu acceptă OpenTracing. Instrumentele avansate necesită modificări specifice pentru New Relic. În cele din urmă, suportul Kubernetes este încă experimental.

Și-a început dezvoltarea în 2010 datadog arată mult mai interesant decât New Relic tocmai în ceea ce privește utilizarea în mediile Kubernetes. În special, acceptă integrarea cu NGINX Ingress, colectarea jurnalelor, statisticile și protocoalele OpenTracing, ceea ce vă permite să urmăriți o solicitare de utilizator din momentul în care este conectată până la finalizare, precum și să găsiți jurnalele pentru această solicitare (ambele pe partea serverului web). și pe cea a consumatorului).

Când folosim Datadog, am întâlnit că uneori a construit harta microservicii incorect și unele deficiențe tehnice. De exemplu, a identificat greșit tipul de serviciu (confundarea Django cu un serviciu de stocare în cache) și a provocat 500 de erori într-o aplicație PHP folosind populara bibliotecă Predis.

Atatus — cel mai tânăr instrument; serviciul a fost lansat în 2014. Bugetul său de marketing este net inferior concurenților listați, mențiunile sunt mult mai puțin frecvente. Cu toate acestea, instrumentul în sine este foarte asemănător cu New Relic, nu numai prin capacitățile sale (APM, monitorizarea browserului etc.), ci și prin aspect.

Un dezavantaj semnificativ este că acceptă doar Node.js și PHP. Pe de altă parte, este implementat considerabil mai bine decât Datadog. Spre deosebire de acesta din urmă, Atatus nu necesită aplicații pentru a face modificări sau pentru a adăuga etichete suplimentare la cod.

Cum lucrăm cu New Relic

Acum să ne dăm seama cum folosim în general New Relic. Să presupunem că avem o problemă care necesită o soluție:

Este ușor de văzut pe grafic stropi - Să o analizăm. În New Relic, tranzacțiile web sunt selectate imediat pentru o aplicație web, toate componentele sunt indicate în graficul de performanță, există panouri de rata de eroare, rate de solicitare... Cel mai important este că direct din aceste panouri te poți deplasa între diferite. părți ale aplicației (de exemplu, făcând clic pe MySQL va duce la secțiunea bazei de date).

Deoarece în exemplul luat în considerare vedem o creștere a activității PHP, faceți clic pe această diagramă și accesați automat Tranzacții:

Lista tranzacțiilor, care sunt în esență controlori din modelul MVC, este deja sortată după Cel mai consumator de timp, ceea ce este foarte convenabil: vedem imediat ce face aplicația. Iată exemple de interogări lungi care sunt colectate automat de New Relic. Prin comutarea sortării, este ușor de găsit:

cel mai încărcat controler de aplicație;
controlor cel mai frecvent solicitat;
cel mai lent dintre controlori.

În plus, puteți extinde fiecare tranzacție și puteți vedea ce făcea aplicația în momentul în care a fost executat codul:

În cele din urmă, aplicația stochează exemple de urme de solicitări lungi (cele care durează mai mult de 2 secunde). Iată panoul pentru o tranzacție lungă:

Se poate observa că două metode necesită mult timp și, în același timp, sunt afișate și timpul când solicitarea a fost executată, URI-ul și domeniul acesteia. Foarte des, acest lucru ajută la găsirea cererii în jurnale. Merge la Urme detalii, puteți vedea de unde sunt apelate aceste metode:

Și în Interogări baze de date — evaluați interogările către bazele de date care au fost executate în timp ce aplicația rula:

Înarmați cu aceste cunoștințe, putem evalua de ce aplicația încetinește și putem colabora cu dezvoltatorul pentru a veni cu o strategie de rezolvare a problemei. În realitate, New Relic nu oferă întotdeauna o imagine clară, dar ajută la alegerea vectorului de investigație:

lung PDO::Construct ne-a condus la funcționarea ciudată a pgpoll;
instabilitate în timp Memcache::Get a sugerat că mașina virtuală a fost configurată incorect;
un timp suspect de crescut pentru procesarea șablonului a dus la o buclă imbricată care verifică prezența a 500 de avatare în stocarea obiectelor;
etc ...

De asemenea, se întâmplă ca în loc să execute cod, ceva legat de stocarea externă a datelor să crească pe ecranul principal - și nu contează ce va fi: Redis sau PostgreSQL - toate sunt ascunse în filă Baze de date.

Puteți selecta o bază specifică pentru cercetare și sortare interogări - similar cu modul în care se face în Tranzacții. Și mergând la fila de solicitare, puteți vedea de câte ori apare această solicitare în fiecare dintre controlerele aplicației și, de asemenea, puteți estima cât de des este apelată. Este foarte confortabil:

Fila conține date similare Servicii externe, care ascunde solicitările către servicii HTTP externe, cum ar fi accesarea stocării obiectelor, trimiterea de evenimente către santinelă sau altele asemenea. Conținutul filei este complet similar cu bazele de date:

Concurenți: oportunități și impresii

Acum, cel mai interesant lucru este să compari capacitățile New Relic cu ceea ce oferă concurenții. Din păcate, nu am putut testa toate cele trei instrumente pe o singură versiune a unei aplicații care rulează în producție. Totuși, am încercat să comparăm situații/configurații cât mai identice.

1.Datadog

Datadog ne întâmpină cu un panou cu un perete de servicii:

Încearcă să spargă aplicațiile în componente/microservicii, așa că în exemplul aplicației Django vom vedea 2 conexiuni la PostgreSQL (defaultdb и postgres), precum și țelină, Redis. Lucrul cu Datadog necesită să aveți cunoștințe minime despre principiile MVC: trebuie să înțelegeți de unde provin, în general, solicitările utilizatorilor. Acest lucru ajută de obicei harta serviciilor:

Apropo, există ceva similar în New Relic:

... iar harta lor, după părerea mea, este făcută mai simplă și mai clară: nu afișează componentele unei aplicații (ceea ce ar face-o prea detaliată, ca în cazul Datadog), ci doar anumite servicii sau microservicii.

Să revenim la Datadog: din harta de servicii putem observa că solicitările utilizatorilor vin la Django. Să mergem la serviciul Django și să vedem în sfârșit la ce ne așteptam:

Din păcate, nu există nici un grafic aici în mod implicit Timpul tranzacției web, similar cu ceea ce vedem pe panoul principal New Relic. Cu toate acestea, poate fi configurat în locul programului % din timpul petrecut. Este suficient să-l comutați la Durata medie per solicitare în funcție de tip... și acum graficul familiar se uită la noi!

De ce Datadog a ales un alt grafic este un mister pentru noi. Un alt lucru frustrant este că sistemul nu își amintește alegerea utilizatorului (spre deosebire de ambii concurenți) și, prin urmare, singura soluție este crearea de panouri personalizate.

Dar am fost mulțumit de capacitatea din Datadog de a trece de la aceste grafice la valorile serverelor aferente, de a citi jurnalele și de a evalua încărcarea de pe serverele web (Gunicorn). Totul este aproape la fel ca în New Relic... și chiar puțin mai mult (busteni)!

Sub grafice sunt tranzacții complet similare cu New Relic:

În Datadog, tranzacțiile sunt numite resurse. Puteți sorta controlerele după numărul de solicitări, după timpul mediu de răspuns și după timpul maxim petrecut pentru o perioadă de timp selectată.

Puteți extinde resursa și puteți vedea tot ce am observat deja în New Relic:

Există statistici despre resursă, o listă generalizată de apeluri interne și exemple de solicitări care pot fi sortate după codul de răspuns... Apropo, inginerilor noștri le-a plăcut foarte mult această sortare.

Orice resursă exemplu în Datadog poate fi deschisă și studiată:

Sunt prezentate parametrii de solicitare, o diagramă rezumativă a timpului petrecut pe fiecare componentă și o diagramă în cascadă care arată secvența apelurilor. De asemenea, puteți comuta la o vizualizare arborescentă a diagramei cascadei:

Și cel mai interesant lucru este vizualizarea încărcării gazdei pe care a fost executată cererea și vizualizarea jurnalelor de solicitare.

Excelenta integrare!

S-ar putea să vă întrebați unde sunt filele Baze de date и Servicii externe, ca în New Relic. Nu există aici: deoarece Datadog descompune aplicația în componente, va fi luat în considerare PostgreSQL un serviciu separat, iar în loc de Servicii externe merită căutat aws.storage (va fi similar pentru orice alt serviciu extern pe care aplicația îl poate accesa).

Iată un exemplu cu postgres:

În esență, există tot ce ne-am dorit:

Puteți vedea de la ce „serviciu” provine solicitarea.

Nu ar fi greșit să vă reamintim că Datadog se integrează perfect cu NGINX Ingress și vă permite să efectuați urmărirea end-to-end din momentul în care o solicitare ajunge în cluster și, de asemenea, vă permite să primiți metrici statistice, să colectați jurnalele și valorile gazdei. .

Un mare plus al Datadog este că prețul său se dezvoltă de la monitorizarea infrastructurii, APM, managementul jurnalului și testul sintetic, i.e. Îți poți alege planul în mod flexibil.

2.Atatus

Echipa Atatus susține că serviciul lor este „la fel cu New Relic, dar mai bun”. Să vedem dacă chiar așa este.

Panoul principal arată similar, dar nu a fost posibil să se determine Redis și memcached utilizate în aplicație.

APM selectează toate tranzacțiile în mod implicit, deși de obicei sunt necesare doar tranzacții web. La fel ca Datadog, nu există nicio modalitate de a naviga la serviciul dorit din panoul principal. Mai mult, tranzacțiile sunt listate după erori, ceea ce nu pare foarte logic pentru APM.

În tranzacțiile Atatus, totul este cât mai asemănător cu New Relic. Dezavantajul este că dinamica fiecărui controler nu este vizibilă imediat. Trebuie să-l cauți în tabelul de controler, sortând după Cel mai mult timp consumat:

Lista obișnuită de controlere este disponibilă în filă Explorează:

În unele privințe, acest tabel amintește de Datadog și îmi place mai mult decât cel similar din New Relic.

Puteți extinde fiecare tranzacție și puteți vedea ce făcea aplicația:

Panoul amintește și mai mult de Datadog: există o serie de solicitări, o imagine generală a apelurilor. Panoul de sus oferă o filă de eroare Eșecuri HTTP și exemple de interogări lente Urmele sesiunii:

Dacă mergeți la o tranzacție, puteți vedea un exemplu de urmă, puteți obține o listă de solicitări către baza de date și puteți privi antetele cererii. Totul este similar cu New Relic:

În general, Atatus mulțumit de urmele detaliate - fără lipirea tipică New Relic a apelurilor într-un bloc de memento:

Cu toate acestea, îi lipsește un filtru care (precum New Relic) ar tăia cererile ultra-rapide (<5ms). Pe de altă parte, mi-a plăcut afișarea răspunsului final al tranzacției (succes sau eroare).

Панель Baze de date vă va ajuta să studiați solicitările către baze de date externe pe care aplicația le face. Permiteți-mi să vă reamintesc că Atatus a găsit doar PostgreSQL și MySQL, deși Redis și memcached sunt și ele implicate în proiect.

Solicitările sunt sortate în funcție de criteriile obișnuite: frecvența de răspuns, timpul mediu de răspuns și așa mai departe. De asemenea, aș dori să menționez fila cu cele mai lente interogări - este foarte convenabil. Mai mult, datele din această filă pentru PostgreSQL au coincis cu datele din extensie pg_stat_statements - rezultat excelent!

Tab Cereri externe complet identic cu bazele de date.

Constatări

Ambele instrumente prezentate au avut rezultate bune în rolul APM. Oricare dintre ele poate oferi minimul necesar. Impresiile noastre pot fi rezumate pe scurt după cum urmează:

datadog

Pro-uri:

orar tarifar convenabil (APM costă 31 USD per gazdă);
a funcționat bine cu Python;
Posibilitatea de integrare cu OpenTracing
integrare cu Kubernetes;
integrare cu NGINX Ingress.

Contra:

singurul APM care a făcut ca aplicația să devină indisponibilă din cauza unei erori de modul (predis);
auto-instrumentare PHP slabă;
definiție parțial ciudată a serviciilor și a scopului lor.

Atatus