V okolju SRE/DevOps inženirjev ne bo nikogar presenetilo, da se nekega dne pojavi odjemalec (ali nadzorni sistem) in sporoči, da je »vse izgubljeno«: stran ne deluje, plačila ne potekajo, življenje propada. ... Ne glede na to, kako zelo bi radi pomagali v takšni situaciji, je to lahko zelo težko storiti brez preprostega in razumljivega orodja. Pogosto se težava skriva v sami kodi aplikacije, le lokalizirati jo morate.
In v žalosti in v veselju ...
Tako se je zgodilo, da smo se že dolgo in globoko zaljubili v New Relic. Bil je in ostaja odlično orodje za spremljanje delovanja aplikacij, omogoča pa tudi instrumentiranje arhitekture mikrostoritve (z uporabo njenega agenta) in še veliko, veliko več. In vse bi lahko bilo super, če ne bi bilo sprememb v cenovni politiki storitve: it stroškovno zrasla 3+ krat. Poleg tega pridobitev poskusnega računa od lani zahteva komunikacijo z osebnim upraviteljem, kar oteži predstavitev produkta potencialni stranki.
Običajna situacija: New Relic ni potreben na "trajni osnovi", spomnijo se ga šele v trenutku, ko se začnejo težave. Vendar morate še vedno redno plačevati (140 USD na strežnik na mesec), v infrastrukturi v oblaku, ki se samodejno spreminja, pa so vsote precej velike. Čeprav obstaja možnost Pay-As-You-Go, boste za omogočanje New Relic morali znova zagnati aplikacijo, kar lahko privede do izgube problematične situacije, zaradi katere je bila zagnana. Pred kratkim je New Relic predstavil nov tarifni načrt - , - ki je na prvi pogled videti kot razumna alternativa Professional ... vendar se je ob natančnejšem pregledu izkazalo, da nekatere pomembne funkcije manjkajo (predvsem nima Ključne transakcije, Navzkrižno sledenje aplikacij, Porazdeljeno sledenje).
Posledično smo začeli razmišljati o iskanju cenejše alternative in naša izbira je padla na dve storitvi: Datadog in Atatus. Zakaj na njih?
O tekmecih
Naj takoj povem, da so na trgu tudi druge rešitve. Razmišljali smo celo o odprtokodnih možnostih, vendar vsak odjemalec nima prostih zmogljivosti za gostovanje samohostovanih rešitev ... - poleg tega bodo zahtevale dodatno vzdrževanje. Par, ki smo ga izbrali, se je izkazal za najbližjega naše potrebe:
- vgrajena in razvita podpora za aplikacije PHP (nabor naših strank je zelo raznolik, vendar je to očitno vodilno v kontekstu iskanja alternative New Relic);
- dostopni stroški (manj kot 100 USD na mesec na gostitelja);
- avtomatski instrumenti;
- integracija s Kubernetesom;
- Podobnost z vmesnikom New Relic je opazen plus (ker so naši inženirji tega navajeni).
Zato smo v začetni fazi izbire izločili več drugih priljubljenih rešitev, zlasti:
- Tideways, AppDynamics in Dynatrace - za stroške;
- Stackify je v Ruski federaciji blokiran in prikazuje premalo podatkov.
Nadaljevanje članka je strukturirano tako, da bodo najprej na kratko predstavljene obravnavane rešitve, nato pa bom spregovoril o naši tipični interakciji z New Relic in izkušnjah/vtisih iz izvajanja podobnih operacij v drugih storitvah.
Predstavitev izbranih tekmovalcev
na , verjetno že vsi slišali? Ta storitev se je začela razvijati pred več kot 10 leti, leta 2008. Aktivno ga uporabljamo od leta 2012 in nismo imeli težav z integracijo res velikega števila aplikacij v PHP, Ruby in Python, izkušnje pa imamo tudi z integracijo s C# in Go. Avtorji storitve imajo rešitve za spremljanje aplikacij, infrastrukture, sledenje infrastrukturam mikrostoritev, ustvarjene priročne aplikacije za uporabniške naprave in še veliko več.
Vendar agent New Relic deluje na lastniških protokolih in ne podpira OpenTracing. Napredna instrumentacija zahteva urejanje posebej za New Relic. Nazadnje, podpora za Kubernetes je še vedno poskusna.
Svoj razvoj je začel leta 2010 je videti opazno bolj zanimiv kot New Relic prav v smislu uporabe v okoljih Kubernetes. Zlasti podpira integracijo z NGINX Ingress, zbiranje dnevnikov, statsd in OpenTracing protokola, ki omogoča sledenje uporabniški zahtevi od trenutka, ko je povezana, do dokončanja, kot tudi iskanje dnevnikov za to zahtevo (tako na strani spletnega strežnika kot in na potrošniku).
Pri uporabi Datadoga smo naleteli na to, da je včasih nepravilno zgradil zemljevid mikrostoritve in na nekatere tehnične pomanjkljivosti. Na primer, napačno je identificiral vrsto storitve (Django je zamenjal za storitev predpomnjenja) in povzročil 500 napak v aplikaciji PHP, ki uporablja priljubljeno knjižnico Predis.
— najmlajši inštrument; storitev je bila uvedena leta 2014. Njegov marketinški proračun je očitno slabši od naštetih konkurentov, omembe so veliko manj pogoste. Vendar pa je samo orodje zelo podobno New Relic, ne le po svojih zmogljivostih (APM, spremljanje brskalnika itd.), ampak tudi po videzu.
Pomembna pomanjkljivost je, da podpira samo Node.js in PHP. Po drugi strani pa je implementiran opazno bolje kot Datadog. Za razliko od slednjega Atatus ne zahteva, da bi aplikacije spreminjale ali dodajale dodatne oznake kodi.
Kako delamo z New Relic
Zdaj pa ugotovimo, kako na splošno uporabljamo New Relic. Recimo, da imamo problem, ki potrebuje rešitev:
To je enostavno videti na grafu brizg - Analizirajmo. V New Relic so spletne transakcije takoj izbrane za spletno aplikacijo, vse komponente so prikazane v grafu uspešnosti, na voljo so plošče za stopnjo napak, stopnjo zahtev ... Najpomembneje je, da se neposredno iz teh plošč lahko premikate med različnimi dele aplikacije (na primer, klik na MySQL vodi do razdelka baze podatkov).
Ker v obravnavanem primeru vidimo porast aktivnosti PHP, kliknite ta grafikon in samodejno pojdite na Transakcije:
Seznam transakcij, ki so v bistvu krmilniki iz modela MVC, je že razvrščen po Največ časa, kar je zelo priročno: takoj vidimo, kaj aplikacija počne. Tukaj so primeri dolgih poizvedb, ki jih New Relic samodejno zbira. S preklopom razvrščanja je enostavno najti:
- najbolj obremenjen krmilnik aplikacij;
- najpogosteje zahtevan krmilnik;
- najpočasnejši od krmilnikov.
Poleg tega lahko vsako transakcijo razširite in vidite, kaj je aplikacija počela v času, ko je bila koda izvedena:
Končno aplikacija shrani primere sledi dolgih zahtev (tistih, ki trajajo več kot 2 sekundi). Tukaj je plošča za dolgo transakcijo:
Vidi se, da dve metodi vzameta veliko časa, hkrati pa se prikaže tudi čas, ko je bila zahteva izvedena, njen URI in domena. Zelo pogosto to pomaga najti zahtevo v dnevnikih. Grem na Podrobnosti sledi, lahko vidite, od kod so klicane te metode:
In Poizvedbe po bazi podatkov — ovrednoti poizvedbe v baze podatkov, ki so bile izvedene med izvajanjem aplikacije:
Oboroženi s tem znanjem lahko ocenimo, zakaj se aplikacija upočasnjuje, in sodelujemo z razvijalcem, da pripravimo strategijo za rešitev težave. V resnici New Relic ne daje vedno jasne slike, vendar pomaga izbrati vektor preiskave:
- dolgo
PDO::Constructnas je pripeljal do nenavadnega delovanja pgpoll; - nestabilnost skozi čas
Memcache::Getpredlagal, da je bil virtualni stroj nepravilno konfiguriran; - sumljivo podaljšan čas za obdelavo predloge je povzročil ugnezdeno zanko, ki preverja prisotnost 500 avatarjev v objektni shrambi;
- in tako naprej…
Zgodi se tudi, da namesto izvajanja kode na glavnem zaslonu raste nekaj, kar je povezano z zunanjim pomnilnikom podatkov - in ni pomembno, kaj bo: Redis ali PostgreSQL - vsi so skriti v zavihku Baze podatkov.
Izberete lahko določeno osnovo za raziskovanje in razvrščanje poizvedb – podobno, kot je to storjeno v Transakcijah. Če odprete zavihek zahteve, lahko vidite, kolikokrat se ta zahteva pojavi v vsakem od krmilnikov aplikacij, in tudi ocenite, kako pogosto se kliče. Je zelo udobno:
Zavihek vsebuje podobne podatke Zunanje storitve, ki skriva zahteve do zunanjih storitev HTTP, kot je dostop do shrambe objektov, pošiljanje dogodkov stražarju ali podobno. Zavihek je vsebinsko popolnoma podoben Bazam podatkov:
Konkurenti: priložnosti in vtisi
Zdaj je najbolj zanimivo primerjati zmogljivosti New Relic s tem, kar ponujajo konkurenti. Na žalost nismo mogli preizkusiti vseh treh orodij na eni različici ene aplikacije, ki se izvaja v proizvodnji. Vendar smo skušali primerjati situacije/konfiguracije, ki so bile čim bolj enake.
1.Datadog
Datadog nas pozdravi s ploščo s steno storitev:
Poskuša razbiti aplikacije na komponente/mikrostoritve, zato bomo v primeru aplikacije Django videli 2 povezavi s PostgreSQL (defaultdb и postgres), kot tudi zelena, Redis. Delo z Datadogom zahteva minimalno znanje o načelih MVC: razumeti morate, od kod na splošno prihajajo zahteve uporabnikov. To običajno pomaga zemljevid storitev:
Mimogrede, nekaj podobnega je v New Relic:
... in njihov zemljevid je po mojem mnenju preprostejši in preglednejši: ne prikazuje komponent ene aplikacije (kar bi ga naredilo preveč podrobnega, kot v primeru Datadoga), ampak samo določene storitve ali mikrostoritve.
Vrnimo se k Datadogu: iz storitvenega zemljevida lahko vidimo, da uporabniške zahteve prihajajo v Django. Pojdimo na storitev Django in končno poglejmo, kaj smo pričakovali:
Na žalost tukaj privzeto ni grafa Čas spletne transakcije, podobno tistemu, kar vidimo na glavni plošči New Relic. Vendar ga je mogoče konfigurirati namesto urnika % porabljenega časa. Dovolj je, da ga preklopite na Povprečni čas na zahtevo glede na vrsto... in zdaj nas gleda znani graf!
Zakaj je Datadog izbral drugo lestvico, je za nas skrivnost. Druga frustrirajoča stvar je, da si sistem ne zapomni izbire uporabnika (za razliko od obeh konkurentov), zato je edina rešitev ustvarjanje panelov po meri.
Vendar sem bil zadovoljen z možnostjo v Datadogu, da preklopim s teh grafov na metrike povezanih strežnikov, preberem dnevnike in ocenim obremenitev upravljavcev spletnega strežnika (Gunicorn). Vse je skoraj tako kot v New Relic ... in še malo več (hlodi)!
Pod grafi so transakcije, ki so popolnoma podobne New Relic:
V Datadogu se transakcije kličejo virov. Krmilnike lahko razvrstite po številu zahtevkov, po povprečnem odzivnem času in po največ porabljenem času za izbrano časovno obdobje.
Vir lahko razširite in vidite vse, kar smo že opazili v New Relic:
Obstajajo statistični podatki o viru, splošen seznam internih klicev in primeri zahtev, ki jih je mogoče razvrstiti po odzivni kodi ... Mimogrede, našim inženirjem je bilo to razvrščanje zelo všeč.
Vsak primer vira v Datadogu je mogoče odpreti in preučiti:
Predstavljeni so parametri zahteve, povzetek časa, porabljenega za vsako komponento, in slapni grafikon, ki prikazuje zaporedje klicev. Preklopite lahko tudi na drevesni pogled grafikona slapa:
Najbolj zanimiv pa je ogled obremenitve gostitelja, na katerem je bila zahteva izvedena, in ogled dnevnikov zahtev.
Odlična integracija!
Morda se sprašujete, kje so zavihki Baze podatkov и Zunanje storitve, kot v New Relic. Tukaj jih ni: ker Datadog razgradi aplikacijo na komponente, bo upoštevan PostgreSQL ločeno storitev, in namesto zunanjih storitev je vredno iskati aws.storage (podobno bo za vsako drugo zunanjo storitev, do katere ima aplikacija dostop).
Tukaj je primer z postgres:
V bistvu je vse, kar smo želeli:
Vidite lahko, iz katere »storitve« je prišla zahteva.
Ne bi bilo odveč, če vas spomnim, da se Datadog popolnoma integrira z NGINX Ingress in vam omogoča izvajanje sledenja od konca do konca od trenutka, ko zahteva prispe v gručo, prav tako pa vam omogoča prejemanje metrik statsd, zbiranje dnevnikov in metrik gostitelja .
Velik plus Datadoga je njegova cena se oblikuje iz spremljanja infrastrukture, APM, Log Management in Synthetics test, tj. Svoj načrt lahko izberete prilagodljivo.
2.Atatus
Ekipa Atatus trdi, da je njihova storitev "enaka kot New Relic, vendar boljša." Poglejmo, ali je res tako.
Glavna plošča je sicer videti podobna, vendar ni bilo mogoče določiti Redis in memcached, uporabljena v aplikaciji.
APM privzeto izbere vse transakcije, čeprav so običajno potrebne samo spletne transakcije. Tako kot pri Datadogu ni možnosti za navigacijo do želene storitve z glavne plošče. Poleg tega so transakcije navedene po napakah, kar se za APM ne zdi preveč logično.
V transakcijah Atatus je vse čim bolj podobno New Relic. Slaba stran je, da dinamika za vsak krmilnik ni takoj vidna. Iskati ga morate v tabeli krmilnika, razvrstiti po Največ časa:
V zavihku je na voljo običajni seznam krmilnikov Razišči:
Na nek način ta tabela spominja na Datadog in mi je bolj všeč kot podobna v New Relic.
Vsako transakcijo lahko razširite in vidite, kaj je aplikacija počela:
Tudi plošča bolj spominja na Datadog: obstaja število zahtev, splošna slika klicev. Na zgornji plošči je zavihek z napakami Napake HTTP in primeri počasnih poizvedb Sledi seje:
Če greste na transakcijo, lahko vidite primer sledenja, dobite lahko seznam zahtev za bazo podatkov in pogledate glave zahtev. Vse je podobno New Relic:
Na splošno je Atatus zadovoljen s podrobnimi sledmi - brez tipičnega lepljenja klicev New Relic v blok opomnikov:
Manjka pa mu filter, ki bi (kot New Relic) prekinil ultra hitre zahteve (<5 ms). Po drugi strani mi je bil všeč prikaz končnega odgovora transakcije (uspeh ali napaka).
Panel Baze podatkov vam bo pomagal preučiti zahteve do zunanjih baz podatkov, ki jih naredi aplikacija. Naj vas spomnim, da je Atatus našel samo PostgreSQL in MySQL, čeprav sta pri projektu vključena tudi Redis in memcached.
Zahtevki so razvrščeni po običajnih kriterijih: pogostost odziva, povprečni odzivni čas ipd. Rad bi omenil tudi zavihek z najpočasnejšimi poizvedbami - zelo je priročen. Poleg tega so podatki v tem zavihku za PostgreSQL sovpadali s podatki iz razširitve - odličen rezultat!
Zavihek Zunanje zahteve popolnoma enaka bazam podatkov.
Ugotovitve
Obe predstavljeni orodji sta se v vlogi APM dobro obnesli. Vsak od njih lahko ponudi zahtevani minimum. Naše vtise lahko na kratko povzamemo takole:
Podatkovni pes
Profesionalci:
- udoben tarifni razpored (APM stane 31 USD na gostitelja);
- dobro deloval s Pythonom;
- Možnost integracije z OpenTracing
- integracija s Kubernetesom;
- integracija z NGINX Ingress.
Cons:
- edini APM, ki je povzročil nedosegljivost aplikacije zaradi napake modula (predis);
- šibka PHP auto-instrumentacija;
- delno čudna definicija storitev in njihovega namena.
Atatus
Profesionalci:
- globoka instrumentacija PHP;
- uporabniški vmesnik podoben New Relic.
Cons:
- ne deluje na starejših operacijskih sistemih (Ubuntu 12.05, CentOS 5);
- šibka avto-instrumentacija;
- podpora za samo dva jezika (Node.js in PHP);
- Počasen vmesnik.
Glede na Atatusovo ceno 69 USD na mesec na strežnik bi raje uporabili Datadog, ki se dobro integrira z našimi potrebami (spletne aplikacije v K8s) in ima veliko uporabnih funkcij.
PS
Preberite tudi na našem blogu:
- «»;
- «»;
- «".
Vir: www.habr.com