🥇 Ikke nyt relikvie alene: et kig på Datadog og Atatus

I miljøet af SRE/DevOps-ingeniører vil det ikke overraske nogen, at der en dag dukker en klient (eller et overvågningssystem) op og rapporterer, at "alt er tabt": siden fungerer ikke, betalinger går ikke igennem, livet forfalder ... Uanset hvor meget du gerne vil hjælpe i sådan en situation, kan det være meget svært at gøre dette uden et enkelt og forståeligt værktøj. Ofte er problemet skjult i selve applikationskoden; du skal bare lokalisere den.

Og i sorg og glæde...

Det skete så, at vi længe og dybt er blevet forelsket i New Relic. Det var og forbliver et fremragende værktøj til at overvåge applikationsydelse, og giver dig også mulighed for at instrumentere mikroservicearkitekturen (ved hjælp af dens agent) og meget, meget mere. Og alt kunne have været fantastisk, hvis det ikke var for ændringer i tjenestens prispolitik: det koste fra 2013 år voksede 3+ gange. Derudover kræver det siden sidste år at få en prøvekonto kommunikation med en personlig leder, hvilket gør det svært at præsentere produktet for en potentiel kunde.

Den sædvanlige situation: New Relic er ikke nødvendig på en "permanent basis"; de husker det kun i det øjeblik, hvor problemerne begynder. Men du skal stadig betale regelmæssigt (140 USD pr. server pr. måned), og i en automatisk skalering af cloud-infrastruktur er beløbene temmelig store. Selvom der er en Pay-As-You-Go-mulighed, vil aktivering af New Relic kræve, at du genstarter programmet, hvilket kan føre til tab af den problematiske situation, som det hele blev startet for. For ikke længe siden introducerede New Relic en ny takstplan - Essentials, - hvilket ved første øjekast ligner et rimeligt alternativ til Professional... men ved nærmere undersøgelse viste det sig, at der mangler nogle vigtige funktioner (især har den ikke Nøgletransaktioner, Cross Application Tracing, Distribueret sporing).

Som følge heraf begyndte vi at overveje at lede efter et billigere alternativ, og vores valg faldt på to tjenester: Datadog og Atatus. Hvorfor på dem?

Om konkurrenter

Lad mig sige med det samme, at der er andre løsninger på markedet. Vi overvejede endda Open Source-muligheder, men ikke alle klienter har ledig kapacitet til at hoste selv-hostede løsninger... - derudover vil de kræve yderligere vedligeholdelse. Det par, vi valgte, viste sig at være tættest på vores behov:

indbygget og udviklet support til PHP-applikationer (vores kunders stak er meget forskelligartet, men dette er en klar leder i forbindelse med at søge efter et alternativ til New Relic);
overkommelige omkostninger (mindre end 100 USD pr. måned pr. vært);
automatisk instrumentering;
integration med Kubernetes;
Ligheden med New Relic-grænsefladen er et mærkbart plus (fordi vores ingeniører er vant til det).

Derfor eliminerede vi i den indledende udvælgelsesfase flere andre populære løsninger, og især:

Tideways, AppDynamics og Dynatrace - for omkostninger;
Stackify er blokeret i Den Russiske Føderation og viser for få data.

Resten af artiklen er opbygget sådan, at de pågældende løsninger først kort præsenteres, hvorefter jeg vil fortælle om vores typiske interaktion med New Relic og erfaringer/indtryk fra at udføre lignende operationer i andre services.

Præsentation af udvalgte konkurrenter

Про New Relic, sikkert alle har hørt? Denne service begyndte sin udvikling for mere end 10 år siden, i 2008. Vi har brugt det aktivt siden 2012 og har ikke haft problemer med at integrere rigtig mange applikationer i PHP, Ruby og Python, og vi har også haft erfaring med at integrere med C# og Go. Forfatterne af tjenesten har løsninger til overvågning af applikationer, infrastruktur, sporing af mikroserviceinfrastrukturer, skabt praktiske applikationer til brugerenheder og meget mere.

New Relic-agenten kører dog på proprietære protokoller og understøtter ikke OpenTracing. Avanceret instrumentering kræver redigeringer specifikt til New Relic. Endelig er Kubernetes support stadig eksperimentel.

Startede sin udvikling i 2010 Datahund ser mærkbart mere interessant ud end New Relic netop med hensyn til brug i Kubernetes-miljøer. Det understøtter især integration med NGINX Ingress, logindsamling, statsd og OpenTracing-protokoller, som giver dig mulighed for at spore en brugeranmodning fra det øjeblik, den er forbundet til færdiggørelse, samt finde logfiler for denne anmodning (begge på webserversiden og på forbrugerens).

Når vi brugte Datadog, stødte vi på, at den nogle gange byggede mikroservicekortet forkert, og nogle tekniske mangler. For eksempel fejlidentificerede den tjenestetypen (forvekslede Django med en cachingtjeneste) og forårsagede 500 fejl i en PHP-applikation ved hjælp af det populære Predis-bibliotek.

Atatus — det yngste instrument; tjenesten blev lanceret i 2014. Dets marketingbudget er klart ringere end de anførte konkurrenter, omtaler er meget mindre almindelige. Selve værktøjet minder dog meget om New Relic, ikke kun i dets muligheder (APM, browserovervågning osv.), men også i udseende.

En væsentlig ulempe er, at den kun understøtter Node.js og PHP. Til gengæld er den implementeret mærkbart bedre end Datadog. I modsætning til sidstnævnte kræver Atatus ikke applikationer for at foretage ændringer eller tilføje yderligere etiketter til koden.

Sådan arbejder vi med New Relic

Lad os nu finde ud af, hvordan vi generelt bruger New Relic. Lad os sige, at vi har et problem, der kræver en løsning:

Det er nemt at se på grafen plaske - Lad os analysere det. I New Relic vælges webtransaktioner med det samme for en webapplikation, alle komponenter er angivet i præstationsgrafen, der er paneler med fejlrate, anmodningsrate... Det vigtigste er, at du direkte fra disse paneler kan flytte mellem forskellige dele af applikationen (for eksempel vil et klik på MySQL føre til databasesektionen).

Da vi i det undersøgte eksempel ser en stigning i aktiviteten PHP, klik på dette diagram og gå automatisk til Transaktioner:

Listen over transaktioner, som i det væsentlige er controllere fra MVC-modellen, er allerede sorteret efter Mest tidskrævende, hvilket er meget praktisk: vi ser straks, hvad applikationen gør. Her er eksempler på lange forespørgsler, der automatisk indsamles af New Relic. Ved at skifte sortering er det nemt at finde:

den mest indlæste applikationscontroller;
hyppigst efterspurgt controller;
den langsomste af controllerne.

Derudover kan du udvide hver transaktion og se, hvad applikationen lavede på det tidspunkt, hvor koden blev eksekveret:

Endelig gemmer applikationen eksempler på spor af lange anmodninger (dem, der tager mere end 2 sekunder). Her er panelet til en lang transaktion:

Det kan ses, at to metoder tager meget tid, og samtidig vises tidspunktet, hvor anmodningen blev eksekveret, dens URI og domæne. Meget ofte hjælper dette med at finde anmodningen i loggene. Går til Spor detaljer, kan du se, hvor disse metoder kaldes fra:

Og i Databasespørgsmål — evaluere forespørgsler til databaser, der blev udført, mens applikationen kørte:

Bevæbnet med denne viden kan vi vurdere, hvorfor applikationen er langsommere, og arbejde sammen med udvikleren om at komme med en strategi til at løse problemet. I virkeligheden giver New Relic ikke altid et klart billede, men det hjælper med at vælge undersøgelsesvektoren:

lang PDO::Construct førte os til pgpolls mærkelige funktion;
ustabilitet over tid Memcache::Get foreslog, at den virtuelle maskine var konfigureret forkert;
en mistænkeligt øget tid til skabelonbehandling førte til en indlejret løkke, der kontrollerer tilstedeværelsen af 500 avatarer i objektlageret;
og så videre…

Det sker også, at i stedet for at udføre kode, vokser noget relateret til ekstern datalagring på hovedskærmen - og det er lige meget, hvad det bliver: Redis eller PostgreSQL - de er alle skjult i fanen Databaser.

Du kan vælge en specifik base for research og sortere forespørgsler - svarende til hvordan det gøres i Transaktioner. Og ved at gå til anmodningsfanen kan du se, hvor mange gange denne anmodning forekommer i hver af applikationscontrollerne, og også estimere, hvor ofte den kaldes. Det er meget behageligt:

Fanen indeholder lignende data Eksterne tjenester, som skjuler anmodninger til eksterne HTTP-tjenester, såsom adgang til objektlager, afsendelse af hændelser til vagtpost eller lignende. Indholdet af fanen ligner fuldstændigt Databaser:

Konkurrenter: muligheder og indtryk

Nu er det mest interessante at sammenligne New Relics muligheder med, hvad konkurrenterne tilbyder. Desværre var vi ikke i stand til at teste alle tre værktøjer på én version af en applikation, der kører i produktion. Vi forsøgte dog at sammenligne situationer/konfigurationer, der var så identiske som muligt.

1. Datahund

Datadog hilser os velkommen med et panel med en væg af tjenester:

Den forsøger at opdele applikationer i komponenter/mikrotjenester, så i eksemplet Django applikation vil vi se 2 forbindelser til PostgreSQL (defaultdb и postgres), samt Selleri, Redis. At arbejde med Datadog kræver, at du har minimal viden om MVC-principper: du skal forstå, hvor brugeranmodninger generelt kommer fra. Dette hjælper normalt tjenester kort:

Forresten er der noget lignende i New Relic:

... og deres kort er efter min mening gjort enklere og klarere: det viser ikke komponenterne i én applikation (hvilket ville gøre det alt for detaljeret, som i tilfældet med Datadog), men kun specifikke tjenester eller mikrotjenester.

Lad os vende tilbage til Datadog: Fra servicekortet kan vi se, at brugeranmodninger kommer til Django. Lad os gå til Django-tjenesten og endelig se, hvad vi forventede:

Desværre er der ingen graf her som standard Webtransaktionstid, svarende til det, vi ser på hovedpanelet New Relic. Det kan dog konfigureres i stedet for tidsplanen % af brugt tid. Det er nok at skifte til Gennemsnitlig tid pr. anmodning efter type... og nu kigger den velkendte graf på os!

Hvorfor Datadog valgte et andet diagram er et mysterium for os. En anden frustrerende ting er, at systemet ikke husker brugerens valg (i modsætning til begge konkurrenter), og derfor er den eneste løsning at skabe brugerdefinerede paneler.

Men jeg var tilfreds med evnen i Datadog til at skifte fra disse grafer til metrics for relaterede servere, læse logfilerne og evaluere belastningen på webserverhandlerne (Gunicorn). Alt er næsten det samme som i New Relic... og endda lidt mere (logfiler)!

Nedenfor graferne er transaktioner, der ligner New Relic:

I Datadog kaldes transaktioner ressourcer. Du kan sortere controllere efter antallet af anmodninger, efter gennemsnitlig svartid og efter den maksimale tid brugt i en valgt tidsperiode.

Du kan udvide ressourcen og se alt, hvad vi allerede har observeret i New Relic:

Der er statistik over ressourcen, en generaliseret liste over interne opkald og eksempler på anmodninger, der kan sorteres efter svarkode... Vores ingeniører kunne i øvrigt rigtig godt lide denne sortering.

Enhver eksempelressource i Datadog kan åbnes og studeres:

Anmodningsparametre, et oversigtsdiagram over den tid brugt på hver komponent og et vandfaldsdiagram, der viser rækkefølgen af opkald, præsenteres. Du kan også skifte til en trævisning af vandfaldsdiagrammet:

Og det mest interessante er at se belastningen af værten, som anmodningen blev udført på, og se anmodningsloggene.

Fantastisk integration!

Du kan undre dig over, hvor fanerne er Databaser и Eksterne tjenester, som i New Relic. Der er ingen her: da Datadog dekomponerer applikationen i komponenter, vil PostgreSQL blive overvejet en separat service, og i stedet for eksterne tjenester er det værd at lede efter aws.storage (det vil være det samme for alle andre eksterne tjenester, som applikationen kan få adgang til).

Her er et eksempel med postgres:

Grundlæggende er der alt, hvad vi ønskede:

Du kan se, hvilken "tjeneste" anmodningen kom fra.

Det ville ikke være forkert at minde dig om, at Datadog integrerer perfekt med NGINX Ingress og giver dig mulighed for at udføre ende-til-ende-sporing fra det øjeblik, en anmodning ankommer i klyngen, og giver dig også mulighed for at modtage statistiske målinger, indsamle logfiler og værtsmålinger .

Et stort plus ved Datadog er, at dens pris folder op fra infrastrukturovervågning, APM, Log Management og Synthetics test, dvs. Du kan vælge din plan fleksibelt.

2. Atatus

Atatus-teamet hævder, at deres service er "den samme som New Relic, men bedre." Lad os se, om det virkelig er sådan.

Hovedpanelet ser ens ud, men det var ikke muligt at bestemme Redis og memcached brugt i applikationen.

APM vælger alle transaktioner som standard, selvom der typisk kun er behov for webtransaktioner. Ligesom Datadog er der ingen måde at navigere til den ønskede tjeneste fra hovedpanelet. Desuden er transaktioner listet efter fejl, hvilket ikke virker særlig logisk for APM.

I Atatus-transaktioner ligner alt som muligt New Relic. Ulempen er, at dynamikken for hver controller ikke umiddelbart er synlig. Du skal kigge efter det i controller-tabellen, sortere efter Mest tidsforbrug:

Den sædvanlige liste over controllere er tilgængelig i fanen Prøv:

På nogle måder minder denne tabel om Datadog, og jeg kan bedre lide den end den tilsvarende i New Relic.

Du kan udvide hver transaktion og se, hvad applikationen gjorde:

Panelet minder også mere om Datadog: Der er en række anmodninger, et generelt billede af opkald. Det øverste panel indeholder en fejlfane HTTP-fejl og eksempler på langsomme forespørgsler Sessionsspor:

Hvis du går til en transaktion, kan du se et eksempel på en sporing, du kan få en liste over anmodninger til databasen og se på anmodningshovederne. Alt ligner New Relic:

Generelt var Atatus tilfreds med detaljerede spor - uden den typiske New Relic limning af opkald i en påmindelsesblok:

Det mangler dog et filter, der (som New Relic) ville afskære ultrahurtige anmodninger (<5ms). På den anden side kunne jeg godt lide visningen af det endelige transaktionssvar (succes eller fejl).

panel Databaser vil hjælpe dig med at studere anmodningerne til eksterne databaser, som applikationen fremsætter. Lad mig minde dig om, at Atatus kun fandt PostgreSQL og MySQL, selvom Redis og memcached også er involveret i projektet.

Forespørgsler sorteres efter de sædvanlige kriterier: svarfrekvens, gennemsnitlig svartid og så videre. Jeg vil også gerne nævne fanen med de langsomste forespørgsler - det er meget praktisk. Desuden faldt dataene i denne fane til PostgreSQL sammen med dataene fra udvidelsen pg_stat_statements - fremragende resultat!

Tab Eksterne anmodninger fuldstændig identisk med databaser.

Fund

Begge præsenterede værktøjer klarede sig godt i rollen som APM. Enhver af dem kan tilbyde det nødvendige minimum. Vores indtryk kan kort opsummeres som følger:

Datahund

Teknikere:

praktisk takstplan (APM koster 31 USD pr. vært);
fungerede godt med Python;
Mulighed for integration med OpenTracing
integration med Kubernetes;
integration med NGINX Ingress.

Ulemper:

den eneste APM, der fik applikationen til at blive utilgængelig på grund af en modulfejl (predis);
svag PHP auto-instrumentering;
delvis mærkelig definition af tjenester og deres formål.

Atatus