🥇Nie nuwe oorblyfsel alleen nie: 'n blik op Datadog en Atatus

In die omgewing van SRE-/DevOps-ingenieurs sal jy niemand verbaas dat daar eendag 'n kliënt (of 'n moniteringstelsel) verskyn en rapporteer dat "alles verlore is": die webwerf werk nie, betalings gaan nie deur nie, die lewe verval... Maak nie saak hoeveel jy in so 'n situasie wil help nie, dit kan baie moeilik wees om dit te doen sonder 'n eenvoudige en verstaanbare hulpmiddel. Dikwels is die probleem versteek in die kode van die toepassing self - jy hoef dit net te lokaliseer.

En in droefheid en in blydskap...

Dit het so gebeur dat ons vir 'n baie lang tyd baie lief is vir New Relic. Dit was en bly 'n wonderlike hulpmiddel om die werkverrigting van 'n toepassing te monitor, en stel jou ook in staat om 'n mikrodiensargitektuur te instrumenteer (met die agent daarvan) en nog baie meer. En alles kan wonderlik wees as dit nie vir veranderinge in die prysbeleid van die diens was nie: sy kos vanaf 2013 jaar verhoog met 3+ keer. Boonop vereis om 'n proefrekening sedert verlede jaar kommunikasie met 'n persoonlike bestuurder, wat dit moeilik maak om die produk aan 'n potensiële kliënt voor te stel.

Gewone situasie: Nuwe Oorblyfsel word nie op 'n "permanente basis" benodig nie, dit word eers onthou op die oomblik toe die probleme begin het. Maar u moet steeds gereeld betaal (140 USD per bediener per maand), en in 'n wolkinfrastruktuur wat outomaties skaal, is die bedrae taamlik groot. Alhoewel daar 'n "Pay-As-You-Go"-opsie is, sal die aktivering van New Relic vereis dat jy die toepassing herbegin, wat kan lei tot die verlies van die problematiese situasie waarvoor alles begin is. Nie so lank gelede nie het New Relic 'n nuwe tariefplan bekendgestel - Essentials, - wat met die eerste oogopslag na 'n redelike alternatief vir Professioneel lyk ... maar by nadere ondersoek het dit geblyk dat 'n paar belangrike funksies ontbreek (dit doen veral nie Sleuteltransaksies, Kruistoepassingsopsporing, Verspreide opsporing).

Gevolglik het ons daaraan gedink om 'n goedkoper alternatief te vind, en ons keuse het geval op die twee dienste Datadog en Atatus. Hoekom op hulle?

Oor mededingers

Maak dadelik 'n bespreking dat daar ander oplossings op die mark is. Ons het selfs oopbron-opsies oorweeg, maar nie elke kliënt het vrye kapasiteit om oplossings van die kategorie wat self aangebied word te huisves nie ... - boonop sal dit bykomende instandhouding vereis. Die paartjie wat ons gekies het was die naaste aan ons behoeftes:

ingeboude en gevorderde ondersteuning vir PHP-toepassings (die stapel van ons kliënte is baie uiteenlopend, maar dit is 'n duidelike leier in die konteks van die vind van 'n alternatief vir New Relic);
bekostigbare koste (minder as 100 USD per maand per gasheer);
outomatiese instrumentasie;
integrasie met Kubernetes;
die ooreenkoms met die New Relic-koppelvlak is 'n merkbare pluspunt (omdat ons ingenieurs daaraan gewoond is).

Daarom het ons in die stadium van primêre seleksie verskeie ander gewilde oplossings uitgewis, en veral:

Tideways, AppDynamics en Dynatrace - vir die koste;
Stackify is in die Russiese Federasie geblokkeer en wys te min data.

Die volgende artikel is so gestruktureer dat die oplossings wat oorweeg is eers kortliks aangebied sal word, waarna ek sal praat oor ons tipiese interaksie met New Relic en ervaring / indrukke van die uitvoering van soortgelyke bewerkings in ander dienste.

Aanbieding van geselekteerde mededingers

op nuwe Relicseker deur almal gehoor? Hierdie diens het meer as 10 jaar gelede, in 2008, begin ontwikkel. Ons gebruik dit aktief sedert 2012 en het geen probleme gehad om 'n baie groot aantal toepassings in PHP, Ruby en Python te integreer nie, en ons het ook ondervinding gehad met integrasie met C # en Go. Die skrywers van die diens het oplossings vir die monitering van toepassings, infrastruktuur, opsporing van mikrodiens-infrastruktuur, gerieflike toepassings vir gebruikerstoestelle is geskep, en nog baie meer.

Die New Relic-agent gebruik egter eie protokolle en ondersteun nie OpenTracing nie. Gevorderde instrumentasie vereis redigering spesifiek vir New Relic. Ten slotte, Kubernetes-ondersteuning is steeds eksperimenteel.

In 2010 bekendgestel Datahond lyk merkbaar interessanter as New Relic net in terme van toepassing in Kubernetes-omgewings. Dit ondersteun veral integrasie met NGINX Ingress, logboekversameling, statsd en OpenTracing-protokolle, wat jou toelaat om 'n gebruikerversoek na te spoor vanaf die oomblik dat dit aan die einde van werk gekoppel word, en ook logs vir hierdie versoek vind (beide aan die webbedienerkant en aan die verbruiker se kant).

Toe ons Datadog gebruik, het ons die feit teëgekom dat dit soms 'n mikrodienskaart verkeerd gebou het, en 'n paar tegniese tekortkominge. Dit het byvoorbeeld die tipe diens verkeerd bepaal (het Django vir 'n kasdiens geneem) en het 500 foute in 'n PHP-toepassing veroorsaak deur die gewilde Predis-biblioteek te gebruik.

Atatus - die jongste instrument; diens wat in 2014 bekendgestel is. Sy bemarkingsbegroting is duidelik minderwaardig as die gelyste mededingers, vermeldings is baie skaarser. Nietemin, die instrument self is baie soortgelyk aan New Relic, nie net in terme van kenmerke (APM, blaaiermonitering, ens.), maar ook in voorkoms.

'n Beduidende nadeel is dat dit slegs Node.js en PHP ondersteun. Aan die ander kant word dit merkbaar beter geïmplementeer as dié van Datadog. Anders as laasgenoemde, vereis Atatus nie toepassings om te verbeter en bykomende etikette in die kode te plaas nie.

Hoe ons met New Relic werk

Kom ons kyk nou hoe ons New Relic in die algemeen gebruik. Kom ons sê ons het 'n probleem wat opgelos moet word:

Dit is maklik om op die grafiek te sien splash - kom ons ontleed dit. In New Relic word webtransaksies onmiddellik vir 'n webtoepassing gekies, alle komponente word in die prestasiegrafiek aangedui, daar is foutkoers-, versoekkoerspanele ... Die belangrikste is dat jy direk vanaf hierdie panele tussen verskillende dele van die toepassing kan navigeer (byvoorbeeld, deur op MySQL te klik, sal jy na die databasisafdeling lei).

Aangesien ons in hierdie voorbeeld 'n toename in aktiwiteit sien PHP, klik op hierdie grafiek en gaan outomaties na Transaksies:

Die lys transaksies wat in wese beheerders van die MVC-model is, is reeds volgens gesorteer Mees tydrowend, wat baie gerieflik is: ons sien dadelik wat die toepassing doen. Daar is ook voorbeelde van lang versoeke wat outomaties deur New Relic ingesamel word. Deur sortering oor te skakel, is dit maklik om te vind:

die mees gelaaide toepassingsbeheerder;
die beheerder wat die meeste versoek word;
die stadigste van die beheerders.

Daarbenewens kan jy elke transaksie uitbrei en sien wat die toepassing gedoen het toe die kode uitgevoer is:

Laastens stoor die toepassing voorbeelde van spore van lang versoeke (wat meer as 2 sekondes verwerk). Hier is die paneel vir die lang transaksie:

Dit kan gesien word dat twee metodes baie tyd neem, en terselfdertyd word die tyd wanneer die versoek uitgevoer is, die URI en domein daarvan ook gewys. Baie dikwels help dit om die versoek in die logs te vind. Gaan na spoor besonderhede, kan jy sien waar hierdie metodes vandaan geroep word:

En in Databasis navrae - om navrae na databasisse te evalueer wat uitgevoer is op die tydstip waarop die toepassing geloop het:

Gewapen met hierdie kennis kan ons die oorsaak van die verlangsaming van die toepassing evalueer en saam met die ontwikkelaar 'n strategie ontwikkel om die probleem op te los. In werklikheid gee New Relic nie altyd 'n duidelike prentjie nie, maar dit help om die rigting van die ondersoek te kies:

lank PDO::Construct het ons gelei na die vreemde funksionering van pgpoll;
onstabiliteit oor tyd Memcache::Get gevra oor die verkeerde konfigurasie van die virtuele masjien;
Verdagte verhoogde tyd vir die verwerking van die sjabloon het gelei tot 'n geneste lus met 'n tjek vir die teenwoordigheid van 500 avatars in die voorwerpberging;
en so aan…

Dit gebeur ook dat in plaas daarvan om kode op die hoofskerm uit te voer, iets wat verband hou met eksterne databerging groei - en dit maak nie saak wat dit sal wees nie: Redis of PostgreSQL - hulle is almal versteek in die oortjie Databases.

Jy kan 'n spesifieke basis vir navorsing kies en versoeke sorteer - soortgelyk aan hoe dit in Transaksies gedoen word. En deur na die versoekoortjie te gaan, kan jy sien hoeveel hierdie versoek in elk van die toepassingsbeheerders voorkom, asook evalueer hoe gereeld dit geroep word. Dit is baie gemaklik:

Soortgelyke data bevat die oortjie Eksterne Dienste, wat versoeke na eksterne HTTP-dienste versteek, soos toegang tot objekberging, die stuur van gebeure na die wag, of dies meer. In sy inhoud is die oortjie heeltemal soortgelyk aan databasisse:

Mededingers: geleenthede en indrukke

Nou is die interessantste ding om die vermoëns van New Relic te vergelyk met wat mededingers bied. Ongelukkig kon ons nie al drie gereedskap op dieselfde weergawe van 'n enkele produksietoepassing toets nie. Nietemin het ons probeer om die mees identiese situasies / konfigurasies te vergelyk.

1.Datadog

Datadog groet ons met 'n paneel met 'n muur van dienste:

Dit probeer om toepassings in komponente / mikrodienste op te breek, so in die voorbeeld Django-toepassing sal ons 2 verbindings na PostgreSQL (defaultdb и postgres), sowel as Seldery, Redis. Om met Datadog te werk, vereis dat jy minimale kennis van MVC-beginsels het: jy moet verstaan waar gebruikersversoeke oor die algemeen vandaan kom. Dit help gewoonlik diens kaart:

Terloops, daar is iets soortgelyks in New Relic:

... en hul kaart word na my mening eenvoudiger en duideliker gemaak: dit vertoon nie die komponente van 'n enkele toepassing nie (wat dit onnodig gedetailleerd sou maak, soos in die geval van Datadog), maar slegs spesifieke dienste of mikrodienste.

Terug na Datadog, jy kan op die dienskaart sien dat gebruikersversoeke na Django kom. Kom ons gaan na die Django-diens en kyk uiteindelik wat ons verwag het:

Ongelukkig is daar by verstek geen grafiek nie. Web transaksie tyd, soortgelyk aan wat ons op die hoofpaneel van New Relic sien. Dit kan egter in die plek van die grafiek gekonfigureer word % van tyd spandeer. Dit is genoeg om dit oor te skakel Gemiddelde tyd per versoek volgens tipe... en nou kyk die bekende grafiek na ons!

Hoekom Datadog 'n ander grafiek gekies het, is vir ons 'n raaisel. Dit was ook frustrerend dat die stelsel nie die gebruiker se keuse onthou nie (anders as albei mededingers), en daarom bespaar slegs die skep van pasgemaakte panele.

Maar ek was tevrede met die geleentheid in Datadog om van hierdie grafieke na die statistieke van gekoppelde bedieners oor te skakel, die logs te lees en die las van die webbedienerhanteerders (Gunicorn) te evalueer. Alles is amper soos in New Relic ... en selfs 'n bietjie meer (logs)!

Onder die kaarte is transaksies wat heeltemal soortgelyk is aan New Relic:

In Datadog word transaksies genoem hulpbronne. U kan die beheerders sorteer volgens die aantal versoeke, volgens die gemiddelde reaksietyd, volgens die maksimum verloop van tyd vir die geselekteerde tydperk.

Die hulpbron kan uitgebrei word en jy kan alles sien wat ons reeds in New Relic waargeneem het:

Daar is hulpbronstatistieke, 'n algemene lys van interne oproepe, en voorbeelde van versoeke wat volgens reaksiekode gesorteer kan word ... Terloops, ons ingenieurs het baie van hierdie sortering gehou.

Enige voorbeeldhulpbron in Datadog kan oopgemaak en ondersoek word:

Navraagparameters word aangebied, 'n opsommingskaart van die tyd wat aan elk van die komponente bestee word, en 'n watervalkaart wat die volgorde van oproepe toon. Dit is ook moontlik om oor te skakel na 'n boomaansig van 'n watervalkaart:

En die interessantste ding is om die vrag van die gasheer te sien waarop die versoek uitgevoer is, en om die versoeklogboeke te bekyk.

Goeie integrasie!

Jy wonder dalk waar die oortjies is Databases и Eksterne Dienste, soos in New Relic. Hulle is nie hier nie: aangesien Datadog die toepassing in komponente uitmekaar haal, sal PostgreSQL oorweeg word aparte diens, en in plaas van Eksterne Dienste moet jy soek aws.storage (Dit sal dieselfde wees vir elke ander eksterne diens waartoe die toepassing toegang het).

En hier is 'n voorbeeld met postgres:

Trouens, daar is alles wat ons wou hê:

Jy kan sien van watter "diens" die versoek gekom het.

Dit sal nie oorbodig wees om te onthou dat Datadog perfek integreer met NGINX Ingress en jou in staat stel om end-tot-end-nasporing uit te voer vanaf die oomblik dat 'n versoek in die cluster aankom nie, en laat jou ook toe om statistieke te ontvang, logs en gasheerstatistieke te versamel.

'N Groot pluspunt van Datadog is dat die prys daarvan ontwikkel van infrastruktuurmonitering, APM, Log Management en Sintetiese toets, m.a.w. U kan die plan buigsaam kies.

2.Atatus

Die Atatus-span beweer dat hul diens "dieselfde as New Relic, maar beter is." Kom ons kyk of dit werklik die geval is.

Die titelbalk lyk inderdaad soortgelyk, maar dit was nie moontlik om die Redis en memcached wat in die toepassing gebruik is, te bepaal nie.

APM kies alle transaksies by verstek, hoewel slegs Web. Soos in Datadog, is daar geen manier om vanaf die hoofpaneel na die gewenste diens te gaan nie. Boonop is transaksies in die lys na foute, wat nie baie logies vir APM lyk nie.

In transaksies is Atatus baie soortgelyk aan New Relic. Minus - jy kan nie dadelik die dinamika vir elk van die beheerders sien nie. Jy moet dit in die kontroleerdabel soek, sorteer volgens Mees Tyd Verbruik:

Die lys van beheerders wat aan ons bekend is, is beskikbaar in die oortjie Verken:

Op sommige maniere lyk hierdie tabel soos Datadog en ek hou meer daarvan as die soortgelyke een in New Relic.

U kan elke transaksie uitbrei en sien wat die toepassing gedoen het:

Die paneel is ook meer soos Datadog: daar is 'n aantal versoeke, 'n algemene prentjie van oproepe. Die boonste balk bied 'n oortjie met foute HTTP-mislukkings en voorbeelde van stadige navrae Sessiespore:

As jy in 'n transaksie gaan, kan jy 'n voorbeeld van 'n spoor sien, jy kan 'n lys van versoeke na die databasis kry en die versoekopskrifte sien. Alles is soortgelyk aan New Relic:

In die algemeen was Atatus tevrede met gedetailleerde spore - sonder om oproepe in 'n herinneringblok tipies van New Relic vas te plak:

Dit kort egter 'n filter wat (soos in New Relic) ultravinnige versoeke (<5ms) afsny. Aan die ander kant het ek gehou van die vertoning van die finale transaksiereaksie (suksesvol of fout).

Paneel Databases sal help om die versoeke aan eksterne databasisse wat die toepassing rig, te bestudeer. Laat ek u daaraan herinner dat Atatus slegs PostgreSQL en MySQL gevind het, hoewel Redis en memcached ook by die projek betrokke is.

Versoeke word gesorteer volgens die gewone kriteria: reaksiefrekwensie, gemiddelde reaksietyd, ensovoorts. Afsonderlik wil ek let op die oortjie met die stadigste versoeke - dit is baie gerieflik. Boonop stem die data in hierdie oortjie vir PostgreSQL ooreen met die data van die uitbreiding pg_stat_statements - uitstekende resultaat!

Tab Eksterne versoeke heeltemal identies aan databasisse.

Bevindinge

Albei aangebied gereedskap het goed gevaar in die rol van APM. Enigeen van hulle kan die nodige minimum bied. Ons kan ons indrukke kortliks soos volg opsom:

Datahond

Pros:

gerieflike tariefskaal (APM kos 31 USD per gasheer);
goed presteer met Python;
moontlikheid van integrasie met OpenTracing
integrasie met Kubernetes;
integrasie met NGINX Ingress.

Nadele:

die enigste APM wat veroorsaak het dat die toepassing onbeskikbaar was as gevolg van 'n module (predis) fout;
swak PHP outo-instrumentasie;
'n ietwat vreemde definisie van dienste en hul doel.

Atatus