🥇 Ikke ny relikvie alene: en titt på Datadog og Atatus

I miljøet til SRE/DevOps-ingeniører vil det ikke overraske noen at det en dag dukker opp en klient (eller et overvåkingssystem) og rapporterer at "alt er tapt": siden fungerer ikke, betalinger går ikke gjennom, livet forfaller ... Uansett hvor mye du ønsker å hjelpe i en slik situasjon, kan det være svært vanskelig å gjøre dette uten et enkelt og forståelig verktøy. Ofte er problemet skjult i selve applikasjonskoden; du trenger bare å lokalisere den.

Og i sorg og glede...

Det har seg slik at vi lenge og dypt har forelsket oss i New Relic. Det var og forblir et utmerket verktøy for å overvåke applikasjonsytelse, og lar deg også instrumentere mikrotjenestearkitekturen (ved hjelp av agenten) og mye, mye mer. Og alt kunne vært flott hvis det ikke var for endringer i tjenestens prispolitikk: det koste fra 2013 år vokste 3+ ganger. I tillegg, siden i fjor, krever det å få en prøvekonto kommunikasjon med en personlig leder, noe som gjør det vanskelig å presentere produktet for en potensiell kunde.

Den vanlige situasjonen: Ny relikvie er ikke nødvendig på "permanent basis"; de husker det bare i det øyeblikket problemene begynner. Men du må fortsatt betale regelmessig (140 USD per server per måned), og i en automatisk skalerende skyinfrastruktur utgjør summene ganske store. Selv om det er et Pay-As-You-Go-alternativ, vil aktivering av New Relic kreve at du starter programmet på nytt, noe som kan føre til tap av den problematiske situasjonen som det hele ble startet for. For ikke lenge siden introduserte New Relic en ny tariffplan - Essentials,- som ved første øyekast ser ut som et rimelig alternativ til Professional... men ved nærmere undersøkelse viste det seg at noen viktige funksjoner mangler (spesielt har den ikke Nøkkeltransaksjoner, Kryssapplikasjonssporing, Distribuert sporing).

Som et resultat begynte vi å tenke på å se etter et billigere alternativ, og valget vårt falt på to tjenester: Datadog og Atatus. Hvorfor på dem?

Om konkurrenter

La meg si med en gang at det finnes andre løsninger på markedet. Vi vurderte til og med åpen kildekode-alternativer, men ikke alle klienter har ledig kapasitet til å være vert for selvhostede løsninger... - i tillegg vil de kreve ekstra vedlikehold. Paret vi valgte viste seg å stå nærmest våre behov:

innebygd og utviklet støtte for PHP-applikasjoner (våre klienters stabel er svært mangfoldig, men dette er en klar leder i sammenheng med å søke etter et alternativ til New Relic);
rimelig pris (mindre enn 100 USD per måned per vert);
automatisk instrumentering;
integrasjon med Kubernetes;
Likheten med New Relic-grensesnittet er et merkbart pluss (fordi ingeniørene våre er vant til det).

Derfor eliminerte vi i det første utvelgelsesstadiet flere andre populære løsninger, og spesielt:

Tideways, AppDynamics og Dynatrace - for kostnad;
Stackify er blokkert i Russland og viser for lite data.

Resten av artikkelen er bygget opp slik at de aktuelle løsningene først vil bli kort presentert, deretter vil jeg snakke om vår typiske interaksjon med New Relic og erfaringer/inntrykk fra å utføre lignende operasjoner i andre tjenester.

Presentasjon av utvalgte konkurrenter

Про New Relic, har sikkert alle hørt? Denne tjenesten begynte sin utvikling for mer enn 10 år siden, i 2008. Vi har brukt det aktivt siden 2012 og har ikke hatt problemer med å integrere et virkelig stort antall applikasjoner i PHP, Ruby og Python, og vi har også hatt erfaring med å integrere med C# og Go. Forfatterne av tjenesten har løsninger for overvåking av applikasjoner, infrastruktur, sporing av mikrotjenesteinfrastrukturer, laget praktiske applikasjoner for brukerenheter og mye mer.

New Relic-agenten kjører imidlertid på proprietære protokoller og støtter ikke OpenTracing. Avansert instrumentering krever redigeringer spesifikt for New Relic. Til slutt er Kubernetes-støtte fortsatt eksperimentell.

Startet utviklingen i 2010 Datahund ser merkbart mer interessant ut enn New Relic nettopp når det gjelder bruk i Kubernetes-miljøer. Spesielt støtter den integrasjon med NGINX Ingress, loggsamling, statsd og OpenTracing-protokoller, som lar deg spore en brukerforespørsel fra øyeblikket den er koblet til fullføring, samt finne logger for denne forespørselen (begge på nettserversiden og på forbrukerens).

Når vi brukte Datadog, oppdaget vi at den noen ganger bygde mikroservicekartet feil, og noen tekniske mangler. For eksempel feilidentifiserte den tjenestetypen (forvekslet med Django som en hurtigbuffertjeneste) og forårsaket 500 feil i en PHP-applikasjon ved å bruke det populære Predis-biblioteket.

Atatus — det yngste instrumentet; tjenesten ble lansert i 2014. Markedsføringsbudsjettet er klart dårligere enn de oppførte konkurrentene, omtaler er mye mindre vanlige. Selve verktøyet er imidlertid veldig likt New Relic, ikke bare i sine muligheter (APM, nettleserovervåking, etc.), men også i utseende.

En betydelig ulempe er at den kun støtter Node.js og PHP. På den annen side er den implementert merkbart bedre enn Datadog. I motsetning til sistnevnte, krever ikke Atatus applikasjoner for å gjøre endringer eller legge til flere etiketter til koden.

Hvordan vi jobber med New Relic

La oss nå finne ut hvordan vi generelt bruker New Relic. La oss si at vi har et problem som trenger en løsning:

Det er lett å se på grafen splash - La oss analysere det. I New Relic velges netttransaksjoner umiddelbart for en nettapplikasjon, alle komponentene er angitt i ytelsesgrafen, det er paneler med feilrate, forespørselsrate... Det som er viktigst er at du direkte fra disse panelene kan flytte mellom ulike deler av applikasjonen (for eksempel, å klikke på MySQL vil føre til databasedelen).

Siden vi i eksemplet under vurdering ser en økning i aktivitet PHP, klikk på dette diagrammet og gå automatisk til Transaksjoner:

Listen over transaksjoner, som i hovedsak er kontroller fra MVC-modellen, er allerede sortert etter Mest tidkrevende, som er veldig praktisk: vi ser umiddelbart hva applikasjonen gjør. Her er eksempler på lange søk som automatisk samles inn av New Relic. Ved å bytte sortering er det enkelt å finne:

den mest lastede applikasjonskontrolleren;
mest etterspurte kontroller;
den tregeste av kontrollerene.

I tillegg kan du utvide hver transaksjon og se hva applikasjonen gjorde på det tidspunktet koden ble utført:

Til slutt lagrer applikasjonen eksempler på spor av lange forespørsler (de som tar mer enn 2 sekunder). Her er panelet for en lang transaksjon:

Det kan ses at to metoder tar mye tid, og samtidig vises tiden da forespørselen ble utført, dens URI og domene. Svært ofte hjelper dette å finne forespørselen i loggene. Skal Spor detaljer, kan du se hvor disse metodene kalles fra:

Og i Databasespørringer - evaluere spørringer til databaser som ble utført mens applikasjonen kjørte:

Bevæpnet med denne kunnskapen kan vi vurdere hvorfor applikasjonen bremser opp og samarbeide med utvikleren for å komme opp med en strategi for å løse problemet. I virkeligheten gir New Relic ikke alltid et klart bilde, men det hjelper å velge etterforskningsvektoren:

lenge PDO::Construct førte oss til den merkelige funksjonen til pgpoll;
ustabilitet over tid Memcache::Get antydet at den virtuelle maskinen var feil konfigurert;
en mistenkelig økt tid for malbehandling førte til en nestet sløyfe som sjekket tilstedeværelsen av 500 avatarer i objektlageret;
etc…

Det hender også at i stedet for å kjøre kode, vokser noe relatert til ekstern datalagring på hovedskjermen - og det spiller ingen rolle hva det blir: Redis eller PostgreSQL - de er alle skjult i fanen databaser.

Du kan velge en spesifikk base for forskning og sortere spørringer - på samme måte som det gjøres i Transaksjoner. Og ved å gå til forespørselsfanen kan du se hvor mange ganger denne forespørselen forekommer i hver av applikasjonskontrollerne, og også anslå hvor ofte den kalles. Det er veldig behagelig:

Fanen inneholder lignende data Eksterne tjenester, som skjuler forespørsler til eksterne HTTP-tjenester, for eksempel tilgang til objektlagring, sending av hendelser til vaktpost eller lignende. Innholdet i fanen ligner fullstendig på Databaser:

Konkurrenter: muligheter og inntrykk

Nå er det mest interessante å sammenligne egenskapene til New Relic med hva konkurrentene tilbyr. Dessverre var vi ikke i stand til å teste alle tre verktøyene på én versjon av én applikasjon som kjører i produksjon. Vi prøvde imidlertid å sammenligne situasjoner/konfigurasjoner som var så identiske som mulig.

1. Datahund

Datadog hilser oss velkommen med et panel med en vegg av tjenester:

Den prøver å bryte applikasjoner inn i komponenter/mikrotjenester, så i eksempelet Django-applikasjonen vil vi se 2 koblinger til PostgreSQL (defaultdb и postgres), samt Selleri, Redis. Å jobbe med Datadog krever at du har minimal kunnskap om MVC-prinsipper: du må forstå hvor brukerforespørsler vanligvis kommer fra. Dette hjelper vanligvis tjenester kart:

Forresten, det er noe lignende i New Relic:

... og kartet deres, etter min mening, er gjort enklere og klarere: det viser ikke komponentene til en applikasjon (noe som ville gjøre det for detaljert, som i tilfellet med Datadog), men bare spesifikke tjenester eller mikrotjenester.

La oss gå tilbake til Datadog: fra tjenestekartet kan vi se at brukerforespørsler kommer til Django. La oss gå til Django-tjenesten og til slutt se hva vi forventet:

Dessverre er det ingen graf her som standard Netttransaksjonstid, lik det vi ser på hovedpanelet New Relic. Den kan imidlertid konfigureres i stedet for tidsplanen % av tid brukt. Det er nok å bytte det til Gjennomsnittlig tid per forespørsel etter type... og nå ser den kjente grafen på oss!

Hvorfor Datadog valgte et annet diagram er et mysterium for oss. En annen frustrerende ting er at systemet ikke husker brukerens valg (i motsetning til begge konkurrentene), og derfor er den eneste løsningen å lage tilpassede paneler.

Men jeg var fornøyd med muligheten i Datadog til å bytte fra disse grafene til beregningene for relaterte servere, lese loggene og evaluere belastningen på webserverbehandlerne (Gunicorn). Alt er nesten det samme som i New Relic... og enda litt til (logger)!

Under grafene er transaksjoner helt lik New Relic:

I Datadog kalles transaksjoner ressurser. Du kan sortere kontrollere etter antall forespørsler, etter gjennomsnittlig responstid og etter maksimal tid brukt i en valgt tidsperiode.

Du kan utvide ressursen og se alt vi allerede har observert i New Relic:

Det er statistikk på ressursen, en generalisert liste over interne samtaler, og eksempler på forespørsler som kan sorteres etter svarkode... Forresten, ingeniørene våre likte denne sorteringen veldig godt.

Enhver eksempelressurs i Datadog kan åpnes og studeres:

Forespørselsparametere, et oppsummeringsdiagram over tiden brukt på hver komponent og et fossefallsdiagram som viser rekkefølgen av samtaler presenteres. Du kan også bytte til en trevisning av fossediagrammet:

Og det mest interessante er å se belastningen til verten som forespørselen ble utført på og se forespørselsloggene.

Flott integrasjon!

Du lurer kanskje på hvor fanene er databaser и Eksterne tjenester, som i New Relic. Det er ingen her: siden Datadog dekomponerer applikasjonen til komponenter, vil PostgreSQL bli vurdert en egen tjeneste, og i stedet for eksterne tjenester er det verdt å se etter aws.storage (det vil være likt for alle andre eksterne tjenester som applikasjonen har tilgang til).

Her er et eksempel med postgres:

I hovedsak er det alt vi ønsket:

Du kan se hvilken "tjeneste" forespørselen kom fra.

Det ville ikke være galt å minne deg på at Datadog integrerer perfekt med NGINX Ingress og lar deg utføre ende-til-ende-sporing fra det øyeblikket en forespørsel kommer inn i klyngen, og lar deg også motta statistikkberegninger, samle logger og vertsmålinger .

Et stort pluss med Datadog er prisen utvikler fra infrastrukturovervåking, APM, Log Management og Synthetics test, dvs. Du kan velge planen din fleksibelt.

2.Atatus

Atatus-teamet hevder at tjenesten deres er "den samme som New Relic, men bedre." La oss se om det virkelig er slik.

Hovedpanelet ser likt ut, men det var ikke mulig å bestemme Redis og memcached som ble brukt i applikasjonen.

APM velger alle transaksjoner som standard, selv om det vanligvis bare trengs netttransaksjoner. Som Datadog, er det ingen måte å navigere til ønsket tjeneste fra hovedpanelet. Dessuten er transaksjoner oppført etter feil, noe som ikke virker veldig logisk for APM.

I Atatus-transaksjoner er alt mest mulig likt New Relic. Ulempen er at dynamikken for hver kontroller ikke er umiddelbart synlig. Du må se etter det i kontrolltabellen, sortert etter Mest tid brukt:

Den vanlige listen over kontrollere er tilgjengelig i fanen Utforsk:

På noen måter minner denne tabellen om Datadog og jeg liker den bedre enn den tilsvarende i New Relic.

Du kan utvide hver transaksjon og se hva applikasjonen gjorde:

Panelet minner også mer om Datadog: det er en rekke forespørsler, et generelt bilde av samtaler. Topppanelet inneholder en feilfane HTTP-feil og eksempler på trege spørringer Sesjonsspor:

Hvis du går til en transaksjon kan du se et eksempel på en sporing, du kan få en liste over forespørsler til databasen og se på forespørselshodene. Alt ligner på New Relic:

Generelt var Atatus fornøyd med detaljerte spor - uten den typiske New Relic-limingen av samtaler i en påminnelsesblokk:

Imidlertid mangler det et filter som (som New Relic) ville kuttet ultraraske forespørsler (<5ms). På den annen side likte jeg visningen av det endelige transaksjonssvaret (suksess eller feil).

panel databaser vil hjelpe deg med å studere forespørslene til eksterne databaser som applikasjonen gjør. La meg minne deg på at Atatus bare fant PostgreSQL og MySQL, selv om Redis og memcached også er involvert i prosjektet.

Forespørsler sorteres etter de vanlige kriteriene: svarfrekvens, gjennomsnittlig responstid og så videre. Jeg vil også nevne kategorien med de tregeste spørringene - det er veldig praktisk. Dessuten falt dataene i denne fanen for PostgreSQL sammen med dataene fra utvidelsen pg_stat_statements - flott resultat!

Tab Eksterne forespørsler helt identisk med databaser.

Funn

Begge presenterte verktøy fungerte godt i rollen som APM. Enhver av dem kan tilby det nødvendige minimum. Våre inntrykk kan kort oppsummeres som følger:

Datahund

Pros:

praktisk tariffplan (APM koster 31 USD per vert);
fungerte bra med Python;
Mulighet for integrasjon med OpenTracing
integrasjon med Kubernetes;
integrasjon med NGINX Ingress.

Cons:

den eneste APM-en som førte til at applikasjonen ble utilgjengelig på grunn av en modulfeil (predis);
svak PHP auto-instrumentering;
til dels merkelig definisjon av tjenester og deres formål.

Atatus