În rândul inginerilor SRE/DevOps, nu mai surprinde pe nimeni că apare un client (sau un sistem de monitorizare) care anunță că „totul s-a dus”: site-ul nu funcționează, plățile nu trec, viața este în van... Oricât de mult ne-ar plăcea să ajutăm în astfel de situații, este foarte greu să facem acest lucru fără un instrument simplu și clar. De cele mai multe ori, problema este ascunsă în codul aplicației în sine – tot ce trebuie să facem este să o localizăm.
Și la bine, și la rău...
S-a întâmplat că de ceva vreme am îndrăgit foarte mult New Relic. A fost și rămâne un excelent instrument pentru monitorizarea performanței aplicației, permițând de asemenea instrumentarea arhitecturii microservicii (prin intermediul agentului său) și multe altele. Totul ar fi fost minunat dacă nu ar fi fost modificările în politica de prețuri a serviciului: acesta prețul a crescut de peste 3 ori. În plus, începând de anul trecut, pentru a obține un cont de probă este necesară comunicarea cu un manager personal, ceea ce îngreunează prezentarea produsului potențialului client.
O situație obișnuită: New Relic nu este necesar pe o „bază constantă”, este amintit doar în momentul în care apar probleme. Dar trebuie totuși să plătim regulat (140 USD pe server pe lună), iar în infrastructura cloud care se scalează automat, sumele devin destul de mari. Deși există opțiunea „Pay-As-You-Go”, activarea New Relic necesită repornirea aplicației, ceea ce poate duce la pierderea acelei situații problematice pentru care totul a fost planificat. Nu cu mult timp în urmă, New Relic a implementat un nou plan tarifar - , - care la prima vedere pare o alternativă rezonabilă la Professional... dar la o analiză detaliată s-a dovedit că lipsesc unele funcții importante (de exemplu, nu are Tranzacții Cheie, Urmarirea Între Aplicații, Urmarirea Distribuită).
Ca urmare, ne-am gândit să căutăm o alternativă mai ieftină, iar alegerea noastră s-a îndreptat spre două servicii, Datadog și Atatus. De ce tocmai acestea?
Despre concurenți
Încă de la început, trebuie să precizez că există și alte soluții pe piață. Am considerat chiar și opțiuni Open Source, dar nu fiecare client dispune de resursele necesare pentru implementarea soluțiilor self-hosted... - în plus, acestea necesită întreținere suplimentară. Perechea pe care am ales-o s-a dovedit a fi cea mai apropiată de nevoile noastre:
- suport încorporat și dezvoltat pentru aplicațiile PHP (tehnologia folosită de clienții noștri este foarte diversă, dar acesta este liderul evident în căutarea unei alternative la New Relic);
- preț accesibil (mai puțin de 100 USD pe lună pentru hosting);
- instrumentare automată;
- integrare cu Kubernetes;
- similaritate cu interfața New Relic — un avantaj notabil (deoarece inginerii noștri sunt obișnuiți cu aceasta).
Prin urmare, în etapa de selecție inițială am exclus câteva alte soluții populare, cum ar fi:
- Tideways, AppDynamics și Dynatrace — din cauza costurilor;
- Stackify — blocat în RF și arată prea puține date.
Articolul de mai departe este structurat astfel încât mai întâi vor fi prezentate pe scurt soluțiile discutate, după care voi povesti despre interacțiunea noastră tipică cu New Relic și experiența/imaginile obținute din efectuarea unor operațiuni similare în alte servicii.
Prezentarea competitorilor selectați
Despre , probabil, a auzit toată lumea? Acest serviciu a început să se dezvolte acum mai bine de 10 ani, în 2008. Noi îl folosim activ din 2012 și nu am avut probleme cu integrarea unui număr semnificativ de aplicații scrise în PHP, Ruby și Python, precum și am avut experiență în integrarea cu C# și Go. Autorii serviciului au soluții pentru monitorizarea aplicațiilor, infrastructurii, urmărirea infrastructurilor de microservicii, au creat aplicații utile pentru dispozitivele utilizatorilor și multe altele.
Cu toate acestea, agentul New Relic lucrează pe protocoale proprietare, nu are suport pentru OpenTracing. Pentru o instrumentare extinsă, trebuie să se facă modificări special pentru New Relic. În cele din urmă, suportul pentru Kubernetes are deocamdată un statut experimental.
Dezvoltându-se începând cu 2010 arată mult mai interesant decât New Relic, în special în ceea ce privește utilizarea în medii Kubernetes. În special, acesta suportă integrarea cu NGINX Ingress, colectarea logurilor, protocoalele statsd și OpenTracing, ceea ce permite urmărirea cererii utilizatorului de la conectare până la finalizarea acestuia, precum și găsirea logurilor asociate cererii (atât pe partea serverului web, cât și pe partea consumatorilor).
Atunci când am folosit Datadog, ne-am confruntat cu probleme, deoarece uneori construia incorect harta microserviciilor, având unele defecte tehnice. De exemplu, identifica greșit tipul de serviciu (a perceput Django ca un serviciu de caching) și provoca erori 500 în aplicația PHP care folosea biblioteca populară Predis.
este cel mai nou instrument; serviciul a fost lansat în 2014. Bugetul său de marketing este evident mult mai mic comparativ cu competitorii enumerați, iar mențiunile apar semnificativ mai rar. Cu toate acestea, instrumentul în sine este foarte similar cu New Relic, nu doar în ceea ce privește funcționalitățile (APM, monitorizarea browserului etc.), ci și în aspectul său.
O dezavantaj semnificativ este suportul exclusiv pentru Node.js și PHP. Pe de altă parte, acesta este implementat mult mai bine decât în cazul Datadog. Spre deosebire de acesta, Atatus nu necesită modificări ale aplicațiilor și adăugarea de etichete suplimentare în cod.
Cum lucrăm cu New Relic
Acum haideți să vedem cum folosim de obicei New Relic. Să presupunem că avem o problemă care necesită o soluție:
Pe grafic este ușor de observat o creștere — să o analizăm. În New Relic, pentru aplicația web sunt selectate imediat tranzacțiile web, iar în graficul de performanță sunt indicate toate componentele, existând panouri pentru rata de erori, rata de cereri… Ce este important — direct din aceste panouri poți naviga între diverse părți ale aplicației (de exemplu, un clic pe MySQL te va duce la secțiunea bazelor de date).
Având în vedere că în acest exemplu vedem o creștere a activității PHP, să facem clic pe acest grafic și vom trece automat în Transactions:
Lista tranzacțiilor, care sunt de fapt controlere din modelul MVC, este deja sortată după Cele mai consumatoare de timp, ceea ce este foarte convenabil: vedem imediat ce face aplicația. De asemenea, aici există exemple de cereri lungi, care sunt colectate automat de New Relic. Schimbând sortarea, este ușor să găsești:
- cel mai solicitat controller al aplicației;
- cel mai frecvent solicitat controller;
- cel mai lent dintre controlere.
În plus, fiecare tranzacție poate fi extinsă pentru a vedea ce a făcut aplicația în momentul executării codului:
În final, aplicația păstrează exemple de trace-uri pentru cererile lungi (care durează mai mult de 2 secunde). Iată panoul pentru o tranzacție lungă:
Se observă că două metode necesită mult timp, iar împreună cu acestea se afișează și timpul în care a fost executat cererea, URI și domeniul. Foarte des, acest lucru ajută la găsirea cererii în loguri. Trecând la Detalii de urmărire, se poate vedea de unde sunt apelate aceste metode:
Iar în Interogări de baze de date — se poate evalua cererile către bazele de date care au fost executate în momentul funcționării aplicației:
Învățând aceste informații, putem evalua cauza încetinirii aplicației și, împreună cu dezvoltatorul, putem elabora o strategie de soluționare a problemei. În realitate, New Relic nu oferă întotdeauna o imagine clară, totuși ajută la alegerea direcției anchetei:
- întârziată
PDO::Constructne-a condus la o funcționare ciudată a pgpoll; - instabilitate în timp
Memcache::Geta sugerat o configurare incorectă a mașinii virtuale; - un timp de procesare suspect de crescut al șablonului a condus la un ciclu înnodat cu verificarea existenței a 500 de avataruri în stocarea obiectelor;
- și așa mai departe…
De asemenea, se întâmplă ca, în loc să se execute codul pe ecranul principal, să crească ceva legat de stocarea externă a datelor — și nu contează ce va fi: Redis sau PostgreSQL, — toate acestea se ascund sub fila Baze de date.
Se poate selecta o bază specifică pentru cercetare și se poate face o sortare a cererilor — similar cu modul în care se face în Transactions. Iar mergând la fila cererii, se poate vedea cât de frecvent apare această cerere în fiecare dintre controlerele aplicației, precum și evalua cât de des este apelată. Este foarte convenabil:
Datele similare le conține fila Servicii externe, care ascunde în sine cererile către servicii HTTP externe, cum ar fi apelul către stocarea de obiecte, trimiterea de evenimente în sentry sau ceva similar. În ceea ce privește conținutul, fila este complet analogică cu Databases:
Concurenții: posibilități și impresii
Acum, partea cea mai interesantă — să comparăm funcțiile New Relic cu cele oferite de concurenți. Din păcate, nu am reușit să testăm toate cele trei instrumente pe aceeași versiune a unei aplicații în producție. Cu toate acestea, am încercat să comparăm situații/configurări cât mai identice.
1. Datadog
Datadog ne întâmpină cu un panou cu o wall of services:
Încearcă să descompună aplicațiile în componente/microservicii, așa că pentru aplicația Django prezentată ca exemplu vom vedea 2 conexiuni la PostgreSQL (defaultdb și postgres), precum și Celery, Redis. Lucrul cu Datadog necesită de la dvs. cunoștințe de bază despre principiile MVC: trebuie să înțelegeți unde ajung, de fapt, cererile utilizatorilor. De obicei, acest lucru este ajutat de harta serviciilor:
Apropo, ceva similar există și în New Relic:
… iar harta lor, din punctul meu de vedere, este realizată mai simplu și mai clar: aceasta afișează nu componentele unei aplicații (ceea ce ar face-o excesiv de detaliată, așa cum este cazul cu Datadog), ci doar servicii sau microservicii specifice.
Să ne întoarcem la Datadog: din harta serviciilor se vede că cererile utilizatorilor ajung în Django. Să trecem în serviciul Django și vom vedea în sfârșit ceea ce așteptam:
Din păcate, în mod implicit, aici nu este un grafic Web transaction time, similar cu cel pe care îl vedem pe panoul principal al New Relic. Totuși, acesta poate fi configurat în locul graficului % of Time spent. Este suficient să-l comutați în Avg time per request by Type… și iată că deja un grafic cunoscut se uită la noi!
De ce în Datadog s-a dat prioritate altui grafic – pentru noi rămâne un mister. Decepționant a fost și faptul că sistemul nu memorează alegerea utilizatorului (spre deosebire de ambele competitoare), astfel că — doar crearea de panouri personalizate ne salvează.
Dar a fost plăcut să avem posibilitatea în Datadog să trecem de la aceste grafice la metricile serverelor asociate, să citim jurnalele și să evaluăm încărcarea gestionarelor web (Gunicorn). Totul este aproape ca în New Relic… și chiar puțin mai mult (jurnale)!
Sub grafice se află tranzacțiile, complet analogice cu New Relic:
În Datadog, tranzacțiile se numesc resurse. Puteți sorta controlerele după numărul de cereri, după timpul mediu de răspuns, după timpul maxim consumat într-o perioadă de timp selectată.
O resursă poate fi desfășurată și puteți vedea tot ceea ce am observat deja în New Relic:
Există și statistici despre resursă, și o listă sumarizată a apelurilor interne, și exemple de cereri, care pot fi sortate după codul de răspuns… Apropo, această sortare le-a plăcut foarte mult inginerilor noștri.
Orice exemplu de resursă în Datadog poate fi desfășurat și studiat:
Sunt reprezentate parametrii cererii, un grafic sumar pe timpul consumat pentru fiecare dintre componente și un grafic cascada, în care se poate vedea secvența apelurilor. De asemenea, este disponibilă comutarea la o vedere pe arbori pentru graficul cascada:
Și cel mai interesant este că poți vizualiza încărcarea gazdei pe care a fost efectuată cererea și vizualiza jurnalele cererii.
Integrare excelentă!
Posibil să apară întrebarea unde sunt tab-urile Baze de date și Servicii externe, ca în New Relic. Aici nu sunt: deoarece Datadog descompune aplicația în componente, PostgreSQL va fi considerat un serviciu separat, iar în loc de Servicii Externe caută aws.storage (la fel va fi și pentru orice alt serviciu extern la care aplicația poate face apel).
Iată un exemplu cu postgres:
Practically, avem tot ceea ce ne-am dorit:
Se vede din ce "serviciu" a venit cererea.
Nu strică să reamintim că Datadog se integrează excelent cu NGINX Ingress și permite urmărirea de la cererea inițială în cluster, precum și permite acceptarea metricelor statsd, colectarea jurnalele și metricelor gazdelor.
Un mare avantaj al Datadog este că prețul său se compune din monitorizarea infrastructurii, APM, Managementul Jurnalele și teste Synthetics, adică poți alege flexibil un plan.
2. Atatus
Echipa Atatus susține că serviciul lor este "la fel ca New Relic, dar mai bun". Să vedem dacă este adevărat.
Panoul principal arată într-adevăr similar, dar nu s-a reușit identificarea Redis și memcached folosite în aplicație.
APM alege în mod implicit toate tranzacțiile, deși, de obicei, sunt necesare doar cele Web. La fel ca în Datadog, nu există posibilitatea de a trece la serviciul dorit din panoul principal. Mai mult, tranzacțiile sunt listate după erori, ceea ce nu este foarte logic pentru APM.
În tranzacții, Atatus este foarte similar cu New Relic. Dezavantajul este că nu se vede imediat dinamica pentru fiecare dintre controlere. Trebuie căutată în tabelul controlerelor, sortând după Cel mai mult timp consumat:
Lista familiară de controlere este disponibilă în tab-ul Explore:
Această tabelă amintește oarecum de Datadog și este mai plăcută decât cea similară din New Relic.
Fiecare tranzacție poate fi desfășurată și poți vedea în ce a fost ocupată aplicația:
Panoul seamănă mai degrabă cu Datadog: există numărul de cereri, imaginea generală a apelurilor. Panoul superior oferă un tab cu erori Eșecuri HTTP și exemple de cereri lente Urmăriri de sesiune:
Dacă treci în tranzacție, se vede un exemplu de urmărire, poți obține o listă de cereri către baza de date și poți vedea anteturile cererii. Totul este similar cu New Relic:
În general, Atatus a impresionat cu detaliile urmării - fără tipicele lipiri de apeluri în blocul de reamintire:
Totuși, aici lipsește un filtru care, precum în New Relic, să elimine cererile ultra-rapide (<5ms). Pe de altă parte, afișarea răspunsului final al tranzacției (fie că a fost un succes sau o eroare) a fost pe placul meu.
Panoul Baze de date va ajuta la explorarea cererilor către bazele de date externe, pe care le face aplicația. Reiterez, Atatus a găsit doar PostgreSQL și MySQL, deși proiectul folosește și Redis și memcached.
Cererea este sortată după criterii familiare: frecvența de activare, timpul mediu de răspuns și așa mai departe. Este de remarcat tab-ul cu cele mai lente cereri — este foarte convenabil. Mai mult, datele în această tab coincidesc cu cele de la extensie pentru PostgreSQL. — rezultat excelent!
Tab-ul Cereri externe este complet identic cu Baze de date.
Conclusions
Ambele instrumente prezentate s-au comportat bine în rolul de APM. Oricare dintre ele poate oferi minimum necesar. Impresia noastră generală poate fi rezumată astfel:
Datadog
Pro:
- o rețea tarifară convenabilă (APM costă 31 USD pe gazdă);
- s-a comportat excelent cu Python;
- posibilitatea integrării cu OpenTracing
- integrare cu Kubernetes;
- integrările cu NGINX Ingress.
Dezavantaje:
- singurul APM care a cauzat inaccesibilitatea aplicației din cauza unei erori de modul (predis);
- auto-instrumentare PHP slabă;
- o definiție oarecum ciudată a serviciilor și funcțiilor lor.
Atatus
Pro:
- instrumentare profundă PHP;
- interfață utilizator similară cu New Relic.
Dezavantaje:
- nu funcționează pe sisteme de operare vechi (Ubuntu 12.05, CentOS 5);
- auto-instrumentare slabă;
- sprijină doar două limbaje de programare (Node.js și PHP);
- funcționare lentă a interfeței.
Având în vedere prețul Atatus de 69 USD pe lună pentru server, am prefera să folosim Datadog, care se integrează excelent în funcție de nevoile noastre (aplicații web în K8s) și are o mulțime de funcții utile.
P.S.
Citiți și în blogul nostru:
- «»;
- «»;
- «».
Sursa: habr.com
