Inom SRE-/DevOps-ingenjörernas vÀrld Àr det ingen överraskning nÀr en kund (eller ett övervakningssystem) plötsligt meddelar att "allt Àr förlorat": webbplatsen fungerar inte, betalningar gÄr inte igenom, livet - Àr meningslöst... Hur gÀrna man Àn skulle vilja hjÀlpa i en sÄdan situation, Àr det mycket svÄrt att göra det utan ett enkelt och förstÄeligt verktyg. Ofta döljer problemet sig i koden av sjÀlva applikationen - man behöver bara lokalisera det.
I sorg och i glÀdje...
Det har blivit sÄ att vi har Àlskat New Relic mycket lÀnge. Det var och förblir ett utmÀrkt verktyg för övervakning av applikationsprestanda, och lÄter ocksÄ instrumentera mikrotjÀnstarkitektur (genom sin agent) och mycket mer. Allt kunde ha varit fantastiskt om det inte vore för förÀndringarna i företagets prispolitik: dess kostnaden har ökat med mer Àn 3 gÄnger. Dessutom, frÄn och med förra Äret krÀvs det kommunikation med en personlig chef för att fÄ ett testkonto, vilket komplicerar presentationen av produkten för potentiella kunder.
En vanlig situation: New Relic behövs inte "pĂ„ en permanent basis", man minns det bara nĂ€r problemen börjar. Men man mĂ„ste Ă€ndĂ„ betala regelbundet (140 USD per server per mĂ„nad), och i en automatiskt skalande molninfrastruktur blir summorna betydande. Ăven om det finns möjlighet för "Pay-As-You-Go", krĂ€ver det att New Relic aktiveras efter omstart av applikationen, vilket kan leda till att den problematiska situationen försvinner, vilket var hela syftet. Inte sĂ„ lĂ€nge sedan introducerade New Relic en ny prispunkt - , - som vid första anblick verkar vara ett rimligt alternativ till Professional... men vid en noggrann granskning visade det sig att vissa viktiga funktioner saknas (i synnerhet Ă€r det inte inkluderat Nyckeltransaktioner, KorsapplikationsspĂ„rning, Distribuerad spĂ„rning).
Som ett resultat började vi fundera pÄ att leta efter ett billigare alternativ, och vÄrt val föll pÄ tvÄ tjÀnster, Datadog och Atatus. Varför just dem?
Om konkurrenterna
Jag ska genast klargöra att det finns andra lösningar pÄ marknaden. Vi övervÀgde till och med Open Source-alternativ, men inte alla kunder har resurser för att implementera lösningar i kategorin self-hosted... - dessutom krÀver de ytterligare underhÄll. Den duo vi valde visade sig vara mest i linje med vÄra behov:
- inbyggt och utvecklat stöd för PHP-applikationer (teknikstacken hos vÄra kunder Àr mycket varierad, men detta Àr en tydlig ledare nÀr det gÀller att söka alternativ till New Relic);
- prisvÀrd kostnad (mindre Àn 100 USD per mÄnad för hosting);
- automatisk instrumentering;
- integration med Kubernetes;
- likheten med New Relics grĂ€nssnitt â en mĂ€rkbar fördel (eftersom vĂ„ra ingenjörer Ă€r vana vid det).
DÀrför vid det första urvalet uteslöt vi flera andra populÀra lösningar, bland annat:
- Tideways, AppDynamics och Dynatrace â pĂ„ grund av kostnaden;
- Stackify â blockerad i Ryssland och visar för lite data.
Den följande artikeln Àr uppbyggd sÄ att de övervÀgda lösningarna först presenteras kort, och sedan berÀttar jag om vÄrt typiska samarbete med New Relic och erfarenheter/intryck av att utföra liknande operationer i andra tjÀnster.
Presentation av utvalda konkurrenter
Om , har nog alla hört talas om? Denna tjÀnst började sin utveckling för mer Àn 10 Är sedan, 2008. Vi har aktivt anvÀnt den sedan 2012 och har inte haft nÄgra problem med att integrera ett verkligt stort antal applikationer pÄ PHP, Ruby och Python, och vi har ocksÄ erfarenhet av integration med C# och Go. Författarna till tjÀnsten har lösningar för övervakning av applikationer, infrastruktur, spÄrning av mikroservice-infrastrukturer, har skapat anvÀndarvÀnliga applikationer för kundens enheter och mycket mer.
Men agenten New Relic arbetar med proprietÀra protokoll, och det finns inget stöd för OpenTracing. För avancerad instrumentering krÀvs speciella justeringar för New Relic. Slutligen har stödet för Kubernetes fortfarande experimentell status.
Startade sin utveckling 2010 ser betydligt mer intressant ut Àn New Relic just nÀr det gÀller anvÀndning i Kubernetes-miljöer. Specifikt stöder det integration med NGINX Ingress, logginsamling, protokollen statsd och OpenTracing, vilket gör att man kan spÄra anvÀndarförfrÄgan frÄn den tidpunkt den ansluter till dess att den avslutas, samt hitta loggar för denna förfrÄgan (bÄde pÄ webbserverns sida och pÄ konsumenternas sida).
Vid anvÀndning av Datadog stötte vi pÄ att den ibland byggde mikroservicekartan felaktigt och visade vissa tekniska brister. Till exempel identifierade den fel typ av tjÀnst (uppfattade Django som en cachetjÀnst) och orsakade 500-fel i en PHP-applikation som anvÀnde det populÀra biblioteket Predis.
â det yngsta verktyget; tjĂ€nsten startades 2014. Dess marknadsföringsbudget stĂ„r tydligt tillbaka jĂ€mfört med de nĂ€mnda konkurrenterna, och omnĂ€mnanden förekommer betydligt mer sĂ€llan. ĂndĂ„ liknar verktyget i sig New Relic, inte bara i funktioner (APM, Browser monitoring etc.), utan ocksĂ„ i utseendet.
En betydande nackdel Àr stödet för endast Node.js och PHP. à andra sidan Àr det genomfört avsevÀrt bÀttre Àn Datadog. Till skillnad frÄn det sistnÀmnda krÀver Atatus inga modifieringar av applikationerna eller tillÀgg av extra etiketter i koden.
Hur vi arbetar med New Relic
LÄt oss nu gÄ igenom hur vi vanligtvis anvÀnder New Relic. LÄt sÀga att vi har ett problem som behöver lösas:
Det Ă€r lĂ€tt att se pĂ„ grafen en spik â lĂ„t oss analysera den. I New Relic Ă€r webbtransaktioner direkt valda för webbapplikationen, och i prestandagrafen anges alla komponenter, inklusive panels för fel- och begĂ€rningshastighet⊠Det viktigaste Ă€r att vi kan navigera mellan olika delar av applikationen direkt frĂ„n dessa paneler (till exempel, ett klick pĂ„ MySQL leder till databassidan).
Eftersom vi i det hÀr exemplet ser en ökning av aktiviteten PHP, lÄt oss klicka pÄ denna graf och automatiskt gÄ till Transaktioner:
Listan över transaktioner, som i grunden Àr kontrollerare frÄn MVC-modellen, Àr redan sorterad efter Den mest tidskrÀvande, vilket Àr mycket bekvÀmt: vi ser direkt vad applikationen sysslar med. HÀr finns ocksÄ exempel pÄ lÄnga begÀrningar som automatiskt samlas in av New Relic. Genom att vÀxla sorteringen Àr det lÀtt att hitta:
- den mest belastade kontrollern i applikationen;
- den mest efterfrÄgade kontrollern;
- den lÄngsammaste av kontrollerna.
Dessutom kan man expandera varje transaktion och se vad applikationen sysslade med under kodens körning:
Slutligen sparas exempel pÄ spÄr för lÄnga begÀrningar (som tar mer Àn 2 sekunder) i applikationen. HÀr Àr panelen för en lÄng transaktion:
Det syns att tvÄ metoder tar mycket tid, och samtidigt visas tiden för nÀr begÀran utfördes, dess URI och domÀn. Det hjÀlper ofta att hitta begÀran i loggarna. Genom att gÄ till SpÄr detaljer, kan man se varifrÄn dessa metoder anropas:
Och i DatabasfrĂ„gor â bedöma frĂ„gor till databaserna som kördes under applikationens drift:
Med dessa kunskaper kan vi bedöma orsaken till applikationens försening och tillsammans med utvecklaren arbeta fram en strategi för att lösa problemet. I verkligheten ger New Relic inte alltid en tydlig översikt, men det hjÀlper till att vÀlja riktningen för undersökningen:
- lÄng
PDO::Constructledde oss till ett mÀrkligt fungerande pgpoll; - instabilitet över tid
Memcache::Getindikerade en felaktig konfiguration av den virtuella maskinen; - den misstÀnkt förlÀngda tiden för att bearbeta mallen ledde till en inbÀddad cykel med kontroll av förekomsten av 500 avatarer i objektlagringen;
- och sĂ„ vidareâŠ
Det kan ocksĂ„ hĂ€nda att istĂ€llet för att köra kod pĂ„ huvudskĂ€rmen vĂ€xer nĂ„got relaterat till extern datalagring â och spelar ingen roll vad det handlar om: Redis eller PostgreSQL, â de döljer sig alla under fliken Databases.
Du kan vĂ€lja en specifik databas för undersökning och filtrera förfrĂ„gningar â pĂ„ samma sĂ€tt som görs i Transactions. Genom att gĂ„ till fliken förfrĂ„gningar kan du se hur ofta denna förfrĂ„gan förekommer i varje controller i applikationen samt uppskatta hur ofta den anropas. Detta Ă€r mycket bekvĂ€mt:
Liknande data finns under fliken External Services, som döljer förfrÄgningar till externa HTTP-tjÀnster, sÄsom anrop till objektlagring, skickande av hÀndelser till Sentry eller liknande. InnehÄllet i fliken Àr helt analogt med Databases:
Konkurrenter: Möjligheter och intryck
Nu kommer det intressanta â vi jĂ€mför New Relics möjligheter med vad konkurrenterna erbjuder. TyvĂ€rr har vi inte kunnat testa alla tre verktyg pĂ„ en version av en produktionsapplikation. ĂndĂ„ har vi försökt jĂ€mföra sĂ„ identiska situationer/konfigurationer som möjligt.
1. Datadog
Datadog möter oss med en panel med en vÀgg av tjÀnster:
Det försöker dela upp applikationer i komponenter/mikrotjÀnster, sÄ för det givna exemplet med Django-applikationen kommer vi att se 2 anslutningar till PostgreSQL (defaultdb och postgres), samt Celery, Redis. Att arbeta med Datadog krÀver att du har minimala kunskaper om MVC-principer: du mÄste förstÄ vart begÀrningar frÄn anvÀndare överhuvudtaget gÄr. Vanligtvis hjÀlper en tjÀnstkarta:
Förresten finns nÄgot liknande Àven i New Relic:
⊠vilket gör att deras karta, enligt min mening, Àr enklare och tydligare: den visar inte komponenterna i en applikation (vilket skulle göra den alltför detaljerad, som i fallet med Datadog), utan endast specifika tjÀnster eller mikrotjÀnster.
LÄt oss ÄtervÀnda till Datadog: frÄn tjÀnstekartan syns det att anvÀndarförfrÄgningar kommer in i Django. Vi gÄr till Django-tjÀnsten och ser Àntligen det vi förvÀntade oss:
TyvÀrr finns det ingen graf hÀr som standard Web transaction time, liknande den vi ser pÄ huvudpanelen i New Relic. Men det gÄr att stÀlla in det pÄ grafens plats % of Time spent. Det rÀcker med att vÀxla till Avg time per request by Type⊠och dÀr stÄr den bekanta grafen framför oss!
Varför Datadog valde en annan graf Àr en gÄta för oss. Dessutom blev vi besvikna över att systemet inte kommer ihÄg anvÀndarens val (till skillnad frÄn bÄda konkurrenterna), och dÀrför Àr den enda lösningen att skapa anvÀndarpaneler.
Men det glÀdjer oss att Datadog erbjuder att gÄ frÄn dessa grafer till mÀtningar av relaterade servrar, lÀsa loggar och utvÀrdera belastningen pÄ webbserverns hanterare (Gunicorn). NÀstan precis som i New Relic⊠och till och med lite mer (loggar)!
Nedanför graferna finns transaktioner, helt analogt med New Relic:
I Datadog kallas transaktioner resurser. Du kan sortera kontroller efter antal förfrÄgningar, genomsnittlig svarstid och maximal tidsÄtgÄng under vald tidsperiod.
En resurs kan utökas för att se allt som vi redan har observerat i New Relic:
Det finns bÄde statistik över resursen och en sammanfattande lista över interna anrop och exempel pÄ förfrÄgningar som kan sorteras efter svarskod⊠Förresten, den hÀr sorteringen gillades mycket av vÄra ingenjörer.
Varje exempel pÄ en resurs i Datadog kan öppnas och studeras:
Parametrarna för förfrÄgan presenteras, ett sammanfattande diagram över den tid som lagts ner pÄ varje komponent och ett vattenfallsdiagram dÀr anropens sekvens syns. Det finns ocksÄ möjlighet att vÀxla till en trÀdvy av vattenfallsdiagrammet:
Och det mest intressanta - att se belastningen pÄ den vÀrd dÀr förfrÄgan exekverades, samt att se loggarna för förfrÄgan.
UtmÀrkt integration!
Det kan uppstÄ en frÄga om var flikarna Databases och External Services, som i New Relic. HÀr finns de inte: eftersom Datadog analyserar applikationen pÄ komponentnivÄ, kommer PostgreSQL att betraktas som en separat tjÀnst, och istÀllet för External Services fÄr man leta efter aws.storage (likas gÀller för varje annan extern tjÀnst som applikationen kan anropa).
HÀr Àr ett exempel med postgres:
I grund och botten finns allt som vi ville ha:
Det Àr tydligt vilket "tjÀnst" som begÀran kom ifrÄn.
Det Àr vÀrt att pÄminna om att Datadog integreras utmÀrkt med NGINX Ingress och möjliggör end-to-end spÄrning frÄn det att begÀran kommer in i klustret, samt att ta emot statsd-mÀtningar, samla loggar och vÀrdmÀtningar.
En stor fördel med Datadog Àr att dess pris bestÄr av infrastrukturövervakning, APM, logghantering och syntetiska tester, sÄ att man flexibelt kan vÀlja plan.
2. Atatus
Atatus-teamet hÀvdar att deras tjÀnst Àr "som New Relic, men bÀttre". LÄt oss se om det verkligen Àr sÄ.
Titelpanelen ser verkligen liknande ut, men det var inte möjligt att identifiera Redis och memcached som anvÀndes i applikationen.
APM vÀljer som standard alla transaktioner, Àven om man oftast endast behöver Web. Precis som i Datadog finns det ingen möjlighet att gÄ till den nödvÀndiga tjÀnsten frÄn huvudpanelen. Dessutom finns transaktionerna i listan efter felen, vilket inte verkar sÀrskilt logiskt för APM.
Transaktionerna i Atatus liknar helt och hÄllet New Relic. Nackdelen Àr att dynamiken för varje kontroller inte syns direkt. Den mÄste hittas i kontrollerlistan genom att sortera efter Mest förbrukad tid:
Den bekanta listan med kontroller finns tillgÀnglig under fliken Utforska:
Denna tabell pÄminner nÄgot om Datadog och Àr mer tilltalande Àn den motsvarande i New Relic.
Varje transaktion kan expanderas för att se vad applikationen sysselsatte sig med:
Panelen liknar ocksĂ„ mer Datadog: det finns antal begĂ€rningar, en allmĂ€n översikt över anrop. Ăver panelen erbjuder en flik med felen HTTP-fel och exempel pĂ„ lĂ„ngsamma begĂ€rningar SessionsspĂ„rningar:
Om man gÄr in i en transaktion kan man se ett exempel pÄ spÄrning, fÄ en lista över begÀrningar till databasen och se begÀrans rubriker. Allt liknar New Relic:
Generellt sett imponerade Atatus med detaljerade spĂ„rningar â utan de typiska hopslagna anropen i reminder-blocket frĂ„n New Relic:
Men hĂ€r saknas en filter som skulle (som i New Relic) sortera bort super-snabba begĂ€rningar (<5ms). Ă
andra sidan gillades visningen av det slutliga svaret frÄn transaktionen (lyckad eller fel).
Panel Databases kommer att hjÀlpa till att studera begÀrningar till externa databaser som applikationen gör. Jag pÄminner om att Atatus endast hittade PostgreSQL och MySQL, Àven om projektet ocksÄ anvÀnder Redis och memcached.
FrĂ„gor sorteras efter vanliga kriterier: frekvens, genomsnittlig svarstid och sĂ„ vidare. Det Ă€r sĂ€rskilt vĂ€rt att nĂ€mna fliken med de lĂ„ngsammaste frĂ„gorna â det Ă€r vĂ€ldigt praktiskt. Dessutom stĂ€mmer datan i denna flik för PostgreSQL överens med datan frĂ„n tillĂ€gget â ett utmĂ€rkt resultat!
Fliken Extern FörfrÄgningar Àr helt identisk med Databaser.
Slutsatser
BÄda de presenterade verktygen har visat sig vara bra APM-verktyg. Vardera av dem kan erbjuda det nödvÀndiga minimumet. Sammanfattningsvis kan vÄra intryck uttryckas sÄ hÀr:
Datadog
Fördelar:
- en praktisk prisstruktur (APM kostar 31 USD per vÀrd);
- visade sig fungera bra med Python;
- möjlighet till integration med OpenTracing
- integration med Kubernetes;
- integration med NGINX Ingress.
Nackdelar:
- den enda APM:n som orsakade otillgÀnglighet av applikationen pÄ grund av ett modulfel (predis);
- svag auto-instrumentering för PHP;
- delvis underligt definierande av tjÀnster och deras syften.
Atatus
Fördelar:
- djupgÄende instrumentering för PHP;
- liknande anvÀndargrÀnssnitt som New Relic.
Nackdelar:
- fungerar inte pÄ gamla operativsystem (Ubuntu 12.05, CentOS 5);
- svag auto-instrumentering;
- stöd för endast tvÄ programmeringssprÄk (Node.js och PHP);
- lÄngsam funktionalitet.
Med tanke pÄ Atatus pris pÄ 69 USD per mÄnad och server, skulle vi snarare anvÀnda Datadog, som passar vÄra behov utmÀrkt (webbapplikationer i K8s) och har mÄnga anvÀndbara funktioner.
P.S.
LÀs Àven i vÄr blogg:
- «»;
- «»;
- «».
KĂ€lla: habr.com
