Ne samo New Relic: ​​pogled na Datadog i Atatus

U okruženju SRE/DevOps inženjera nikoga neće iznenaditi da se jednog dana pojavi klijent (ili sustav za nadzor) i javi da je “sve izgubljeno”: stranica ne radi, plaćanja ne idu, život propada ... Bez obzira koliko biste željeli pomoći u takvoj situaciji, učiniti to bez jednostavnog i razumljivog alata može biti vrlo teško. Često se problem krije u kodu same aplikacije, samo ga trebate lokalizirati.

I u tuzi i u radosti…

Tako se dogodilo da smo se dugo i duboko zaljubili u New Relic. Bio je i ostao izvrstan alat za praćenje izvedbe aplikacija, a također vam omogućuje instrumentalizaciju arhitekture mikroservisa (pomoću njegovog agenta) i još mnogo, mnogo više. I sve je moglo biti sjajno da nije bilo promjena u cjenovnoj politici usluge: it koštati od 2013 godine narastao 3+ puta. Osim toga, od prošle godine dobivanje probnog računa zahtijeva komunikaciju s osobnim menadžerom, što otežava predstavljanje proizvoda potencijalnom kupcu.

Uobičajena situacija: New Relic nije potreban na "stalnoj osnovi", oni ga se sjete samo u trenutku kada počnu problemi. Ali i dalje morate redovito plaćati (140 USD po poslužitelju mjesečno), a u infrastrukturi oblaka koja se automatski skalira iznosi su prilično veliki. Iako postoji Pay-As-You-Go opcija, uključivanje New Relic-a zahtijevat će ponovno pokretanje aplikacije, što može dovesti do gubitka problematične situacije zbog koje je sve pokrenuto. Nedavno je New Relic predstavio novi tarifni plan - Osnove, - koji na prvi pogled izgleda kao razumna alternativa za Professional... ali nakon detaljnijeg ispitivanja pokazalo se da nedostaju neke važne funkcije (konkretno, nema Ključne transakcije, Praćenje više aplikacija, Distribuirano praćenje).

Kao rezultat toga, počeli smo razmišljati o traženju jeftinije alternative, a naš izbor je pao na dvije usluge: Datadog i Atatus. Zašto na njih?

O konkurentima

Odmah da kažem da na tržištu postoje i druga rješenja. Razmotrili smo čak i opcije otvorenog koda, ali nema svaki klijent slobodan kapacitet za hosting samostalno hostiranih rješenja... - osim toga, zahtijevat će dodatno održavanje. Par koji smo odabrali pokazao se najbližim naše potrebe:

• ugrađena i razvijena podrška za PHP aplikacije (skup naših klijenata je vrlo raznolik, ali ovo je jasan lider u kontekstu traženja alternative za New Relic);
• pristupačna cijena (manje od 100 USD mjesečno po domaćinu);
• automatska instrumentacija;
• integracija s Kubernetesom;
• Sličnost sa New Relic sučeljem je primjetan plus (jer su naši inženjeri na to navikli).

Stoga smo u početnoj fazi odabira eliminirali nekoliko drugih popularnih rješenja, a posebno:

• Tideways, AppDynamics i Dynatrace - za cijenu;
• Stackify je blokiran u Ruskoj Federaciji i prikazuje premalo podataka.

Ostatak članka strukturiran je na način da će najprije biti ukratko predstavljena rješenja o kojima je riječ, nakon čega ću govoriti o našoj tipičnoj interakciji s New Relic-om i iskustvima/dojmovima iz izvođenja sličnih operacija u drugim servisima.

Predstavljanje odabranih natjecatelja

na Novi Relic, vjerojatno su svi čuli? Ova usluga započela je svoj razvoj prije više od 10 godina, 2008. godine. Aktivno ga koristimo od 2012. godine i bez problema smo integrirali zaista velik broj aplikacija u PHP-u, Rubyju i Pythonu, a imali smo iskustva i s integracijom s C# i Go. Autori servisa imaju rješenja za praćenje aplikacija, infrastrukture, praćenje mikroservisnih infrastruktura, kreirane prikladne aplikacije za korisničke uređaje i još mnogo toga.

Međutim, New Relic agent radi na vlasničkim protokolima i ne podržava OpenTracing. Napredna instrumentacija zahtijeva uređivanja posebno za New Relic. Konačno, podrška za Kubernetes još uvijek je eksperimentalna.

Svoj razvoj započeo je 2010 Psa podataka izgleda osjetno zanimljivije od New Relic-a upravo u smislu korištenja u Kubernetes okruženjima. Konkretno, podržava integraciju s NGINX Ingressom, prikupljanje dnevnika, statsd i OpenTracing protokole, što vam omogućuje praćenje korisničkog zahtjeva od trenutka povezivanja do završetka, kao i pronalaženje zapisa za ovaj zahtjev (oba na strani web poslužitelja i na potrošačevoj).

Pri korištenju Datadoga naišli smo na to da je ponekad krivo izradio mapu mikroservisa i neke tehničke nedostatke. Na primjer, pogrešno je identificirao vrstu usluge (zamijenivši Django za uslugu predmemoriranja) i izazvao 500 pogrešaka u PHP aplikaciji koja koristi popularnu biblioteku Predis.

Atatus — najmlađi instrument; usluga je pokrenuta 2014. Njegov marketinški proračun očito je inferioran u odnosu na navedene konkurente, spominjanja su mnogo rjeđa. Međutim, sam alat vrlo je sličan New Relic-u, ne samo po svojim mogućnostima (APM, nadzor preglednika itd.), već i po izgledu.

Značajan nedostatak je što podržava samo Node.js i PHP. S druge strane, implementiran je osjetno bolje od Datadoga. Za razliku od potonjeg, Atatus ne zahtijeva aplikacije za izmjene ili dodavanje dodatnih oznaka kodu.

Kako radimo s New Relic

Sada pogledajmo kako općenito koristimo New Relic. Recimo da imamo problem koji treba rješenje:

Lako je vidjeti na grafikonu uprskati - Idemo to analizirati. U New Relic-u, web transakcije se odmah odabiru za web aplikaciju, sve komponente su naznačene u grafikonu performansi, postoje paneli stope grešaka, stope zahtjeva... Ono što je najvažnije je da se izravno iz ovih panela možete kretati između različitih dijelovi aplikacije (na primjer, klik na MySQL vodi do odjeljka baze podataka).

Budući da u primjeru koji razmatramo vidimo porast aktivnosti PHP, kliknite na ovaj grafikon i automatski idite na Transakcije:

Popis transakcija, koje su u biti kontroleri iz MVC modela, već je sortiran po Oduzima najviše vremena, što je vrlo zgodno: odmah vidimo što aplikacija radi. Evo primjera dugih upita koje New Relic automatski prikuplja. Promjenom razvrstavanja lako je pronaći:

• najopterećeniji aplikacijski kontroler;
• najčešće traženi kontroler;
• najsporiji od kontrolora.

Osim toga, možete proširiti svaku transakciju i vidjeti što je aplikacija radila u vrijeme kada je kôd izvršen:

Na kraju, aplikacija pohranjuje primjere tragova dugih zahtjeva (onih koji traju više od 2 sekunde). Evo ploče za dugu transakciju:

Vidi se da dvije metode oduzimaju dosta vremena, a ujedno se prikazuje i vrijeme kada je zahtjev izvršen, njegov URI i domena. Vrlo često to pomaže pronaći zahtjev u zapisima. Idem Detalji traga, možete vidjeti odakle se ove metode pozivaju:

I u Upiti u bazi podataka — procijeniti upite prema bazama podataka koji su izvršeni dok je aplikacija radila:

Naoružani ovim znanjem, možemo procijeniti zašto aplikacija usporava i raditi s programerom na osmišljavanju strategije za rješavanje problema. U stvarnosti New Relic ne daje uvijek jasnu sliku, ali pomaže u odabiru vektora istraživanja:

• dugo PDO::Construct doveli su nas do čudnog funkcioniranja pgpolla;
• nestabilnost tijekom vremena Memcache::Get sugerirao da je virtualni stroj pogrešno konfiguriran;
• sumnjivo povećano vrijeme obrade predloška dovelo je do ugniježđene petlje koja provjerava prisutnost 500 avatara u pohrani objekta;
• i tako dalje…

Također se događa da umjesto izvršavanja koda, na glavnom ekranu raste nešto vezano uz vanjsku pohranu podataka - i nije važno što će to biti: Redis ili PostgreSQL - svi su skriveni u kartici Baze podataka.

Možete odabrati određenu bazu za istraživanje i sortirati upite - slično kao što se to radi u Transakcijama. A ako odete na karticu zahtjeva, možete vidjeti koliko se puta ovaj zahtjev pojavljuje u svakom od aplikacijskih kontrolera, te također procijeniti koliko se često poziva. Vrlo je ugodno:

Kartica sadrži slične podatke Vanjske usluge, koji skriva zahtjeve vanjskim HTTP uslugama, kao što je pristup pohrani objekata, slanje događaja stražaru ili slično. Kartica je sadržajem potpuno slična Bazama podataka:

Konkurenti: prilike i dojmovi

Sada je najzanimljivije usporediti mogućnosti New Relic-a s onim što nude konkurenti. Nažalost, nismo bili u mogućnosti testirati sva tri alata na jednoj verziji jedne aplikacije koja se izvodi u produkciji. Ipak, nastojali smo usporediti situacije/konfiguracije koje su bile što identičnije moguće.

1.Datadog

Datadog nas dočekuje s panelom sa zidom usluga:

Pokušava rastaviti aplikacije na komponente/mikroservise, tako da ćemo u primjeru Django aplikacije vidjeti 2 veze na PostgreSQL (defaultdb и postgres), kao i Celer, Redis. Rad s Datadogom zahtijeva minimalno znanje o MVC principima: morate razumjeti odakle zahtjevi korisnika općenito dolaze. Ovo obično pomaže karta usluga:

Usput, postoji nešto slično u New Relic:

... a njihova mapa je, po mom mišljenju, napravljena jednostavnije i preglednije: ne prikazuje komponente jedne aplikacije (što bi je činilo pretjerano detaljnom, kao u slučaju Datadoga), već samo određene usluge ili mikroservise.

Vratimo se Datadogu: iz mape servisa vidimo da korisnički zahtjevi dolaze Djangu. Idemo na Django servis i konačno vidimo što smo očekivali:

Nažalost, ovdje nema grafa prema zadanim postavkama Vrijeme web transakcije, slično onome što vidimo na glavnoj ploči New Relic. Međutim, može se konfigurirati umjesto rasporeda % utrošenog vremena. Dovoljno ga je prebaciti na Prosječno vrijeme po zahtjevu prema vrsti... a sada poznati grafikon gleda u nas!

Za nas je misterij zašto je Datadog odabrao drugačiji grafikon. Još jedna frustrirajuća stvar je što sustav ne pamti izbor korisnika (za razliku od oba konkurenta), pa je stoga jedino rješenje kreiranje prilagođenih panela.

Ali bio sam zadovoljan sposobnošću u Datadogu prebacivanja s ovih grafikona na metriku povezanih poslužitelja, čitanja zapisa i procjene opterećenja rukovatelja web poslužitelja (Gunicorn). Sve je gotovo isto kao u New Relic-u... pa čak i malo više (logovi)!

Ispod grafikona su transakcije potpuno slične New Relic:

U Datadogu se transakcije pozivaju resursi. Kontrolere možete sortirati prema broju zahtjeva, prema prosječnom vremenu odgovora i prema maksimalnom vremenu utrošenom za odabrano vremensko razdoblje.

Možete proširiti resurs i vidjeti sve što smo već vidjeli u New Relic:

Postoje statistike o resursu, generalizirani popis internih poziva i primjeri zahtjeva koji se mogu sortirati prema kodu odgovora... Usput, našim se inženjerima jako svidjelo ovo sortiranje.

Bilo koji primjer izvora u Datadogu može se otvoriti i proučavati:

Prikazani su parametri zahtjeva, sumarni grafikon vremena utrošenog na svaku komponentu i vodopadni grafikon koji prikazuje redoslijed poziva. Također se možete prebaciti na prikaz stabla grafikona vodopada:

A najzanimljivije je pregled opterećenja hosta na kojem je zahtjev izvršen i pregled logova zahtjeva.

Odlična integracija!

Možda se pitate gdje su kartice Baze podataka и Vanjske usluge, kao u New Relic. Ovdje ih nema: budući da Datadog rastavlja aplikaciju na komponente, razmotrit ćemo PostgreSQL zasebna usluga, a umjesto vanjskih usluga vrijedi ga potražiti aws.storage (bit će slično za svaku drugu vanjsku uslugu kojoj aplikacija može pristupiti).

Evo primjera s postgres:

Uglavnom postoji sve što smo htjeli:

Možete vidjeti od koje je "usluge" zahtjev došao.

Ne bi bilo naodmet podsjetiti vas da se Datadog savršeno integrira s NGINX Ingressom i omogućuje vam praćenje end-to-end od trenutka kada zahtjev stigne u klaster, a također vam omogućuje primanje statsd metrike, prikupljanje zapisa i metriku hosta .

Ogroman plus Datadoga je njegova cijena poprima oblik od praćenja infrastrukture, APM-a, upravljanja zapisima i sintetičkog testa, tj. Svoj plan možete odabrati fleksibilno.

2.Atatus

Atatus tim tvrdi da je njihova usluga "ista kao New Relic, ali bolja." Da vidimo je li to stvarno tako.

Glavna ploča doista izgleda slično, ali nije bilo moguće odrediti koji se Redis i memcached koriste u aplikaciji.

APM prema zadanim postavkama odabire sve transakcije, iako su obično potrebne samo web transakcije. Poput Datadoga, ne postoji način navigacije do željene usluge s glavnog panela. Štoviše, transakcije su navedene nakon pogrešaka, što se ne čini baš logičnim za APM.

U Atatus transakcijama sve je što sličnije New Relic-u. Loša strana je što dinamika za svaki kontroler nije odmah vidljiva. Morate ga potražiti u tablici kontrolera, sortirajući po Najviše vremena:

Uobičajeni popis kontrolera dostupan je u kartici Istražiti:

Na neki način ova tablica podsjeća na Datadog i više mi se sviđa od slične u New Relic.

Svaku transakciju možete proširiti i vidjeti što je aplikacija radila:

Ploča također više podsjeća na Datadog: postoji niz zahtjeva, opća slika poziva. Gornja ploča nudi karticu pogreške HTTP greške i primjeri sporih upita Tragovi sesije:

Ako odete na transakciju, možete vidjeti primjer praćenja, možete dobiti popis zahtjeva prema bazi podataka i pogledati zaglavlja zahtjeva. Sve je slično New Relic-u:

Općenito, Atatus je zadovoljan detaljnim tragovima - bez tipičnog New Relic lijepljenja poziva u blok podsjetnika:

Međutim, nedostaje mu filter koji bi (kao New Relic) odrezao ultra brze zahtjeve (<5ms). S druge strane, svidio mi se prikaz konačnog odgovora transakcije (uspjeh ili greška).

Панель Baze podataka pomoći će vam u proučavanju zahtjeva prema vanjskim bazama podataka koje aplikacija postavlja. Da vas podsjetim da je Atatus pronašao samo PostgreSQL i MySQL, iako su Redis i memcached također uključeni u projekt.

Zahtjevi su razvrstani prema uobičajenim kriterijima: učestalost odgovora, prosječno vrijeme odgovora i tako dalje. Također bih želio spomenuti karticu s najsporijim upitima - vrlo je zgodna. Štoviše, podaci u ovoj kartici za PostgreSQL podudaraju se s podacima iz proširenja pg_stat_izjave - odličan rezultat!

Tab Vanjski zahtjevi potpuno identičan bazama podataka.

Zaključci

Oba predstavljena alata dobro su se pokazala u ulozi APM-a. Svaki od njih može ponuditi potrebni minimum. Naše dojmove možemo ukratko sažeti na sljedeći način:

Psa podataka

Pros:

• prikladan tarifni raspored (APM košta 31 USD po hostu);
• dobro radio s Pythonom;
• Mogućnost integracije s OpenTracingom
• integracija s Kubernetesom;
• integracija s NGINX Ingressom.

Cons:

• jedini APM zbog kojeg je aplikacija postala nedostupna zbog greške modula (predis);
• slaba PHP auto-instrumentacija;
• dijelom čudna definicija usluga i njihove namjene.

Atatus

Pros:

• duboka PHP instrumentacija;
• korisničko sučelje slično New Relic.

Cons:

• ne radi na starijim operativnim sustavima (Ubuntu 12.05, CentOS 5);
• slaba auto-instrumentacija;
• podrška za samo dva jezika (Node.js i PHP);
• Sporo sučelje.

S obzirom na Atatusovu cijenu od 69 USD mjesečno po poslužitelju, radije bismo koristili Datadog, koji se dobro integrira s našim potrebama (web aplikacije u K8s) i ima mnogo korisnih značajki.

PS

Pročitajte i na našem blogu:

• «Alati za programere aplikacija koje rade na Kubernetesu»;
• «kubectl-debug dodatak za otklanjanje pogrešaka u Kubernetes podovima»;
• «Mikroservisi: Veličina je bitna, čak i ako imate Kubernetes".

Izvor: www.habr.com