🥇Not New Relic sol: una ullada a Datadog i Atatus

En l'entorn dels enginyers de SRE/DevOps, no sorprendrà a ningú que un dia aparegui un client (o un sistema de monitoratge) i informi que “tot està perdut”: el lloc no funciona, els pagaments no passen, la vida decau. ... Per molt que t'agradaria ajudar en una situació així, pot ser molt difícil fer-ho sense una eina senzilla i entenedora. Sovint, el problema s'amaga al codi de la pròpia aplicació, només cal localitzar-lo.

I amb pena i alegria...

Va passar que ens hem enamorat molt i profundament de New Relic. Va ser i continua sent una excel·lent eina per supervisar el rendiment de l'aplicació, i també us permet instrumentar l'arquitectura del microservei (utilitzant el seu agent) i molt, molt més. I tot hauria estat genial si no hagués estat pels canvis en la política de preus del servei: això cost des de l'any 2013 va créixer més de 3 vegades. A més, des de l'any passat, l'obtenció d'un compte de prova requereix una comunicació amb un gestor personal, fet que dificulta la presentació del producte a un client potencial.

La situació habitual: New Relic no és necessària de manera "permanent" només la recorden en el moment en què comencen els problemes. Però encara heu de pagar regularment (140 USD per servidor al mes), i en una infraestructura de núvol que s'escala automàticament, les sumes sumen bastant grans. Tot i que hi ha una opció de pagament per ús, l'habilitació de New Relic requerirà que reinicieu l'aplicació, cosa que pot provocar la pèrdua de la situació problemàtica per a la qual es va iniciar tot. No fa gaire, New Relic va presentar un nou pla tarifari: Essencials, - que a primera vista sembla una alternativa raonable a Professional... però després d'un examen més detingut va resultar que falten algunes funcions importants (en particular, no té Transaccions clau, Seguiment d'aplicacions creuades, Traçat distribuït).

Com a resultat, vam començar a pensar a buscar una alternativa més barata i la nostra elecció va recaure en dos serveis: Datadog i Atatus. Per què sobre ells?

Sobre els competidors

Permeteu-me dir de seguida que hi ha altres solucions al mercat. Fins i tot hem considerat opcions de codi obert, però no tots els clients tenen capacitat lliure per allotjar solucions autoallotjades... - a més, requeriran un manteniment addicional. La parella que vam triar va resultar ser la més propera les nostres necessitats:

suport integrat i desenvolupat per a aplicacions PHP (la pila dels nostres clients és molt diversa, però aquest és un clar líder en el context de la recerca d'una alternativa a New Relic);
cost assequible (menys de 100 USD al mes per host);
instrumentació automàtica;
integració amb Kubernetes;
La similitud amb la interfície New Relic és un avantatge notable (perquè els nostres enginyers hi estan acostumats).

Per tant, en l'etapa de selecció inicial, vam eliminar diverses altres solucions populars, i en particular:

Tideways, AppDynamics i Dynatrace - per cost;
Stackify està bloquejat a la Federació Russa i mostra massa poques dades.

La resta de l'article està estructurat de manera que primer es presentaran breument les solucions en qüestió, després parlaré de la nostra interacció típica amb New Relic i de l'experiència/impressions de realitzar operacions similars en altres serveis.

Presentació dels concursants seleccionats

Про Nova relíquia, probablement tothom ho ha sentit? Aquest servei va començar el seu desenvolupament fa més de 10 anys, l'any 2008. L'utilitzem activament des del 2012 i no hem tingut problemes per integrar un nombre molt gran d'aplicacions en PHP, Ruby i Python, i també hem tingut experiència en la integració amb C# i Go. Els autors del servei tenen solucions per supervisar aplicacions, infraestructures, rastrejar infraestructures de microserveis, crear aplicacions convenients per als dispositius dels usuaris i molt més.

Tanmateix, l'agent New Relic s'executa amb protocols propietaris i no admet OpenTracing. La instrumentació avançada requereix edicions específicament per a New Relic. Finalment, el suport de Kubernetes encara és experimental.

Va començar el seu desenvolupament l'any 2010 datadog sembla notablement més interessant que New Relic precisament pel que fa a l'ús als entorns Kubernetes. En particular, admet la integració amb els protocols NGINX Ingress, recopilació de registres, statsd i OpenTracing, que us permeten fer un seguiment d'una sol·licitud d'usuari des del moment en què es connecta fins a la finalització, així com trobar els registres d'aquesta sol·licitud (ambdós al costat del servidor web). i del consumidor).

Quan utilitzem Datadog, hem trobat que de vegades creava el mapa del microservei de manera incorrecta i algunes deficiències tècniques. Per exemple, va identificar malament el tipus de servei (confondre Django amb un servei de memòria cau) i va provocar 500 errors en una aplicació PHP utilitzant la popular biblioteca Predis.

Atatus — l'instrument més jove; el servei es va posar en marxa l'any 2014. El seu pressupost de màrqueting és clarament inferior al dels competidors llistats, les mencions són molt menys freqüents. Tanmateix, l'eina en si és molt semblant a New Relic, no només en les seves capacitats (APM, monitorització del navegador, etc.), sinó també en aparença.

Un inconvenient important és que només és compatible amb Node.js i PHP. D'altra banda, s'implementa notablement millor que Datadog. A diferència d'aquest últim, Atatus no requereix que les aplicacions facin modificacions o afegeixin etiquetes addicionals al codi.

Com treballem amb New Relic

Ara anem a esbrinar com utilitzem generalment New Relic. Suposem que tenim un problema que necessita solució:

És fàcil de veure al gràfic esquitxada - Analitzem-ho. A New Relic, les transaccions web es seleccionen immediatament per a una aplicació web, tots els components s'indiquen al gràfic de rendiment, hi ha panells de percentatge d'error, percentatge de sol·licitud... El més important és que directament des d'aquests panells es pot moure entre diferents panells. parts de l'aplicació (per exemple, fer clic a MySQL conduirà a la secció de la base de dades).

Atès que en l'exemple en qüestió veiem un augment de l'activitat PHP, feu clic a aquest gràfic i aneu automàticament a Transaccions:

La llista de transaccions, que són essencialment controladors del model MVC, ja està ordenada per La majoria de temps, que és molt convenient: de seguida veiem què fa l'aplicació. Aquests són exemples de consultes llargues que New Relic recull automàticament. En canviar l'ordenació, és fàcil trobar:

el controlador d'aplicacions més carregat;
controlador més sol·licitat;
el més lent dels controladors.

A més, podeu ampliar cada transacció i veure què feia l'aplicació en el moment en què es va executar el codi:

Finalment, l'aplicació emmagatzema exemples de rastres de peticions llargues (aquelles que triguen més de 2 segons). Aquí teniu el panell per a una transacció llarga:

Es pot veure que dos mètodes triguen molt de temps i, al mateix temps, també es mostra el temps en què s'ha executat la sol·licitud, el seu URI i el seu domini. Molt sovint això ajuda a trobar la sol·licitud als registres. Anar a Traça detalls, podeu veure d'on es criden aquests mètodes:

I en Consultes de bases de dades — avaluar les consultes a bases de dades que es van executar mentre l'aplicació s'executava:

Amb aquest coneixement, podem avaluar per què l'aplicació s'està alentint i treballar amb el desenvolupador per elaborar una estratègia per resoldre el problema. En realitat, New Relic no sempre dóna una imatge clara, però ajuda a triar el vector d'investigació:

llarg PDO::Construct ens va portar a l'estrany funcionament de pgpoll;
inestabilitat al llarg del temps Memcache::Get va suggerir que la màquina virtual estava configurada incorrectament;
un temps sospitosament augmentat per al processament de plantilles va provocar un bucle imbricat que verificava la presència de 500 avatars a l'emmagatzematge d'objectes;
etcètera…

També passa que en comptes d'executar codi, alguna cosa relacionada amb l'emmagatzematge de dades extern creix a la pantalla principal -i no importa quina sigui: Redis o PostgreSQL-, tots estan amagats a la pestanya. Bases de dades.

Podeu seleccionar una base específica per a la recerca i ordenar les consultes, de manera similar a com es fa a Transaccions. I en anar a la pestanya de sol·licitud, podeu veure quantes vegades es produeix aquesta sol·licitud a cadascun dels controladors d'aplicació, i també estimar amb quina freqüència es truca. És molt còmode:

La pestanya conté dades similars Serveis Externs, que amaga les sol·licituds a serveis HTTP externs, com ara accedir a l'emmagatzematge d'objectes, enviar esdeveniments al sentinella o similars. El contingut de la pestanya és completament semblant a Bases de dades:

Competidors: oportunitats i impressions

Ara el més interessant és comparar les capacitats de New Relic amb les que ofereixen els competidors. Malauradament, no hem pogut provar les tres eines en una versió d'una aplicació que s'executa en producció. Tanmateix, hem intentat comparar situacions/configuracions que fossin el més idèntiques possibles.

1.Datadog

Datadog ens rep amb un plafó amb un mur de serveis:

Intenta dividir les aplicacions en components/microserveis, de manera que a l'aplicació Django d'exemple veurem 2 connexions a PostgreSQL (defaultdb и postgres), així com Api, Redis. Treballar amb Datadog requereix que tingueu un coneixement mínim dels principis de MVC: heu d'entendre d'on provenen generalment les sol·licituds dels usuaris. Això normalment ajuda mapa de serveis:

Per cert, hi ha alguna cosa semblant a New Relic:

... i el seu mapa, al meu entendre, es fa més senzill i clar: no mostra els components d'una aplicació (cosa que la faria massa detallada, com en el cas de Datadog), sinó només serveis o microserveis específics.

Tornem a Datadog: des del mapa de serveis podem veure que les peticions dels usuaris arriben a Django. Anem al servei Django i per fi veiem què esperàvem:

Malauradament, aquí no hi ha cap gràfic per defecte Temps de transacció web, semblant al que veiem al panell principal New Relic. Tanmateix, es pot configurar en lloc de l'horari % del temps dedicat. N'hi ha prou amb canviar-lo Temps mitjà per sol·licitud per tipus... i ara el gràfic conegut ens mira!

Per què Datadog va triar un gràfic diferent és un misteri per a nosaltres. Una altra cosa frustrant és que el sistema no recorda l'elecció de l'usuari (a diferència dels dos competidors), i per tant l'única solució és crear panells personalitzats.

Però em va satisfer la capacitat de Datadog per canviar d'aquests gràfics a les mètriques dels servidors relacionats, llegir els registres i avaluar la càrrega dels gestors del servidor web (Gunicorn). Tot és gairebé igual que a New Relic... i fins i tot una mica més (logs)!

A sota dels gràfics hi ha transaccions completament similars a New Relic:

A Datadog, les transaccions s'anomenen recursos. Podeu ordenar els controladors pel nombre de sol·licituds, pel temps de resposta mitjà i pel temps màxim dedicat durant un període de temps seleccionat.

Podeu ampliar el recurs i veure tot el que ja hem observat a New Relic:

Hi ha estadístiques sobre el recurs, una llista generalitzada de trucades internes i exemples de peticions que es poden ordenar per codi de resposta... Per cert, als nostres enginyers els va agradar molt aquesta classificació.

Qualsevol recurs d'exemple a Datadog es pot obrir i estudiar:

Es presenten els paràmetres de la sol·licitud, un gràfic resum del temps dedicat a cada component i un gràfic en cascada que mostra la seqüència de trucades. També podeu canviar a una vista en arbre del gràfic de la cascada:

I el més interessant és veure la càrrega de l'amfitrió en què s'ha executat la sol·licitud i veure els registres de sol·licitud.

Gran integració!

Potser us preguntareu on són les pestanyes Bases de dades и Serveis Externs, com a New Relic. Aquí no n'hi ha cap: com que Datadog descompon l'aplicació en components, es tindrà en compte PostgreSQL un servei a part, i en comptes de Serveis Externs val la pena buscar aws.storage (Serà similar per a tots els altres serveis externs als quals pugui accedir l'aplicació).

Aquí teniu un exemple amb postgres:

Bàsicament hi ha tot el que volíem:

Podeu veure de quin "servei" prové la sol·licitud.

No estaria bé recordar-vos que Datadog s'integra perfectament amb NGINX Ingress i us permet realitzar un traçament d'extrem a extrem des del moment en què arriba una sol·licitud al clúster, i també us permet rebre mètriques d'estadístiques, recopilar registres i mètriques d'amfitrió. .

Un gran avantatge de Datadog és el seu preu es plega des de la vigilància d'infraestructura, APM, gestió de registres i prova sintètica, és a dir. Podeu triar el vostre pla de manera flexible.

2.Estat

L'equip d'Atatus afirma que el seu servei és "el mateix que New Relic, però millor". A veure si això és realment cert.

El tauler principal sembla semblant, però no va ser possible determinar el Redis i el memcached utilitzats a l'aplicació.

APM selecciona totes les transaccions de manera predeterminada, encara que normalment només es necessiten transaccions web. Com a Datadog, no hi ha manera de navegar fins al servei desitjat des del tauler principal. A més, les transaccions s'enumeren després dels errors, cosa que no sembla gaire lògic per a APM.

A les transaccions Atatus, tot és el més semblant possible a New Relic. L'inconvenient és que la dinàmica de cada controlador no és immediatament visible. L'has de buscar a la taula del controlador, ordenant per Més temps consumit:

La llista habitual de controladors està disponible a la pestanya explorar:

D'alguna manera, aquesta taula recorda a Datadog i m'agrada més que la semblant de New Relic.

Podeu ampliar cada transacció i veure què feia l'aplicació:

El panell també recorda més a Datadog: hi ha una sèrie de peticions, una imatge general de les trucades. El tauler superior proporciona una pestanya d'error Errors HTTP i exemples de consultes lentes Traces de sessió:

Si aneu a una transacció, podeu veure un exemple de traça, podeu obtenir una llista de sol·licituds a la base de dades i mirar les capçaleres de la sol·licitud. Tot és semblant a New Relic:

En general, Atatus està satisfet amb les traces detallades, sense el típic enganxament de trucades New Relic en un bloc de recordatoris:

Tanmateix, no té un filtre que (com New Relic) tallar les sol·licituds ultra ràpides (<5 ms). D'altra banda, em va agradar la visualització de la resposta final de la transacció (èxit o error).

Tauler Bases de dades l'ajudarà a estudiar les peticions a bases de dades externes que fa l'aplicació. Permeteu-me que us recordi que Atatus només va trobar PostgreSQL i MySQL, tot i que Redis i memcached també estan implicats en el projecte.

Les sol·licituds s'ordenen segons els criteris habituals: freqüència de resposta, temps mitjà de resposta, etc. També m'agradaria esmentar la pestanya amb les consultes més lentes: és molt convenient. A més, les dades d'aquesta pestanya per a PostgreSQL coincidien amb les dades de l'extensió pg_stat_statements - Excel·lent resultat!

Pestanya Sol·licituds externes totalment idèntic a les bases de dades.

Troballes

Les dues eines presentades van funcionar bé en el paper d'APM. Qualsevol d'ells pot oferir el mínim requerit. Les nostres impressions es poden resumir breument de la següent manera:

datadog

Pros:

programa de tarifes convenient (APM costa 31 USD per host);
va funcionar bé amb Python;
Possibilitat d'integració amb OpenTracing
integració amb Kubernetes;
integració amb NGINX Ingress.

Contres:

l'únic APM que va provocar que l'aplicació no estigui disponible a causa d'un error de mòdul (predis);
instrumentació automàtica PHP feble;
una definició en part estranya dels serveis i la seva finalitat.

Atatus