Not New Relic Alone: ​​En titt på Datadog och Atatus

I miljön för SRE/DevOps-ingenjörer kommer det inte att förvåna någon att en dag en klient (eller ett övervakningssystem) dyker upp och rapporterar att "allt är förlorat": sajten fungerar inte, betalningar går inte igenom, livet förfaller ... Hur mycket du än skulle vilja hjälpa till i en sådan situation kan det vara väldigt svårt att göra detta utan ett enkelt och begripligt verktyg. Ofta är problemet dolt i själva applikationskoden, du behöver bara lokalisera den.

Och i sorg och glädje...

Det hände så att vi länge och djupt har blivit förälskade i New Relic. Det var och förblir ett utmärkt verktyg för att övervaka applikationsprestanda, och låter dig också instrumentera mikrotjänstarkitekturen (med hjälp av dess agent) och mycket, mycket mer. Och allt kunde ha varit bra om det inte vore för förändringar i tjänstens prispolicy: det kosta från 2013 år växte 3+ gånger. Sedan förra året kräver det dessutom att skaffa ett provkonto kommunikation med en personlig chef, vilket gör det svårt att presentera produkten för en potentiell kund.

Den vanliga situationen: New Relic behövs inte på "permanent basis", de kommer ihåg det bara i det ögonblick när problemen börjar. Men du behöver fortfarande betala regelbundet (140 USD per server och månad), och i en automatiskt skalande molninfrastruktur blir beloppen ganska stora. Även om det finns ett Pay-As-You-Go-alternativ, kräver att du aktiverar New Relic att du startar om programmet, vilket kan leda till att du förlorar den problematiska situationen för vilken det hela startades. För inte så länge sedan introducerade New Relic en ny tariffplan - Essentials, - vilket vid första anblicken ser ut som ett rimligt alternativ till Professional... men vid närmare granskning visade det sig att vissa viktiga funktioner saknas (i synnerhet har den inte Nyckeltransaktioner, Cross Application Tracing, 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 på dem?

Om konkurrenter

Låt mig säga direkt att det finns andra lösningar på marknaden. Vi övervägde till och med Open Source-alternativ, men inte alla klienter har ledig kapacitet att vara värd för lösningar som är värdar för sig själv... - dessutom kommer de att kräva ytterligare underhåll. Paret vi valde visade sig stå närmast våra behov:

• inbyggt och utvecklat stöd för PHP-applikationer (våra kunders stack är mycket varierande, men detta är en tydlig ledare i samband med att söka efter ett alternativ till New Relic);
• överkomlig kostnad (mindre än 100 USD per månad per värd);
• automatisk instrumentering;
• integration med Kubernetes;
• Likheten med New Relic-gränssnittet är ett märkbart plus (eftersom våra ingenjörer är vana vid det).

Därför eliminerade vi i det inledande urvalsstadiet flera andra populära lösningar, och i synnerhet:

• Tideways, AppDynamics och Dynatrace - för kostnad;
• Stackify är blockerad i Ryska federationen och visar för lite data.

Resten av artikeln är uppbyggd på så sätt att lösningarna i fråga först kommer att presenteras kort, varefter jag kommer att berätta om vår typiska interaktion med New Relic och erfarenheter/intryck från att utföra liknande operationer i andra tjänster.

Presentation av utvalda tävlande

Про nya Relic, har nog alla hört? Denna tjänst började utvecklas för mer än 10 år sedan, 2008. Vi har använt det aktivt sedan 2012 och har inte haft några problem med att integrera ett riktigt stort antal applikationer i PHP, Ruby och Python, och vi har även haft erfarenhet av att integrera med C# och Go. Författarna till tjänsten har lösningar för övervakning av applikationer, infrastruktur, spårning av mikrotjänstinfrastrukturer, skapade bekväma applikationer för användarenheter och mycket mer.

New Relic-agenten körs dock på proprietära protokoll och stöder inte OpenTracing. Avancerad instrumentering kräver redigeringar specifikt för New Relic. Slutligen är Kubernetes stöd fortfarande experimentellt.

Började sin utveckling 2010 datahund ser märkbart mer intressant ut än New Relic just när det gäller användning i Kubernetes-miljöer. I synnerhet stöder den integration med NGINX Ingress, logginsamling, statsd och OpenTracing-protokoll, vilket gör att du kan spåra en användarförfrågan från det ögonblick den är ansluten till slutförande, samt hitta loggar för denna begäran (båda på webbserversidan och på konsumentens).

När vi använde Datadog stötte vi på att den ibland byggde mikroservicekartan felaktigt och några tekniska brister. Till exempel felidentifierade den tjänstetypen (misstog Django för en cachningstjänst) och orsakade 500 fel i en PHP-applikation med det populära Predis-biblioteket.

Atatus — det yngsta instrumentet; tjänsten lanserades 2014. Dess marknadsföringsbudget är klart sämre än de listade konkurrenterna, omnämnanden är mycket mindre vanliga. Verktyget i sig är dock väldigt likt New Relic, inte bara i dess kapacitet (APM, webbläsarövervakning, etc.), utan också i utseende.

En betydande nackdel är att den bara stöder Node.js och PHP. Å andra sidan är det implementerat märkbart bättre än Datadog. Till skillnad från det senare kräver Atatus inga applikationer för att göra ändringar eller lägga till ytterligare etiketter till koden.

Hur vi arbetar med New Relic

Låt oss nu ta reda på hur vi i allmänhet använder New Relic. Låt oss säga att vi har ett problem som behöver en lösning:

Det är lätt att se på grafen всплеск - Låt oss analysera det. I New Relic väljs webbtransaktioner omedelbart ut för en webbapplikation, alla komponenter indikeras i prestandagrafen, det finns paneler för felfrekvens, förfrågningsfrekvens... Det viktigaste är att du direkt från dessa paneler kan flytta mellan olika delar av applikationen (om du till exempel klickar på MySQL kommer du till databassektionen).

Eftersom vi i exemplet under övervägande ser en ökning av aktiviteten PHP, klicka på det här diagrammet och gå automatiskt till Transaktioner:

Listan över transaktioner, som i huvudsak är kontroller från MVC-modellen, är redan sorterad efter Mest tidskrävande, vilket är väldigt bekvämt: vi ser omedelbart vad applikationen gör. Här är exempel på långa frågor som automatiskt samlas in av New Relic. Genom att byta sortering är det lätt att hitta:

• den mest laddade applikationsstyrenheten;
• den mest efterfrågade styrenheten;
• den långsammaste av kontrollerna.

Dessutom kan du utöka varje transaktion och se vad applikationen gjorde när koden kördes:

Slutligen lagrar applikationen exempel på spår av långa förfrågningar (de som tar mer än 2 sekunder). Här är panelen för en lång transaktion:

Det kan ses att två metoder tar mycket tid, och samtidigt visas tiden då förfrågan exekveras, dess URI och domän. Mycket ofta hjälper detta att hitta förfrågan i loggarna. Ska Spår detaljer, kan du se var dessa metoder anropas från:

Och i Databasfrågor — utvärdera frågor till databaser som kördes medan applikationen kördes:

Beväpnade med denna kunskap kan vi utvärdera varför applikationen saktar ner och arbeta tillsammans med utvecklaren för att ta fram en strategi för att lösa problemet. I verkligheten ger New Relic inte alltid en tydlig bild, men det hjälper till att välja undersökningsvektor:

• lång PDO::Construct ledde oss till pgpolls märkliga funktion;
• instabilitet över tid Memcache::Get föreslog att den virtuella maskinen var felaktigt konfigurerad;
• en misstänkt ökad tid för mallbearbetning ledde till en kapslad loop som kontrollerade närvaron av 500 avatarer i objektlagringen;
• etc…

Det händer också att istället för att exekvera kod växer något relaterat till extern datalagring på huvudskärmen - och det spelar ingen roll vad det blir: Redis eller PostgreSQL - de är alla gömda i fliken Databaser.

Du kan välja en specifik bas för forskning och sortera frågor - liknande hur det görs i Transaktioner. Och genom att gå till begäran-fliken kan du se hur många gånger denna begäran inträffar i var och en av applikationskontrollerna, och även uppskatta hur ofta den anropas. Det är väldigt bekvämt:

Fliken innehåller liknande data Externa tjänster, som döljer förfrågningar till externa HTTP-tjänster, som att komma åt objektlagring, skicka händelser till vaktpost eller liknande. Innehållet på fliken är helt likt Databaser:

Konkurrenter: möjligheter och intryck

Nu är det mest intressanta att jämföra kapaciteten hos New Relic med vad konkurrenterna erbjuder. Tyvärr kunde vi inte testa alla tre verktygen på en version av en applikation som körs i produktion. Vi försökte dock jämföra situationer/konfigurationer som var så identiska som möjligt.

1. Datahund

Datadog hälsar oss välkomna med en panel med en vägg av tjänster:

Den försöker bryta upp applikationer i komponenter/mikrotjänster, så i exemplet Django-applikationen kommer vi att se 2 anslutningar till PostgreSQL (defaultdb и postgres), samt Selleri, Redis. Att arbeta med Datadog kräver att du har minimal kunskap om MVC-principer: du måste förstå var användarförfrågningar i allmänhet kommer ifrån. Detta brukar hjälpa tjänster karta:

Förresten, det finns något liknande i New Relic:

... och deras karta, enligt min mening, görs enklare och tydligare: den visar inte komponenterna i en applikation (vilket skulle göra den alltför detaljerad, som i fallet med Datadog), utan bara specifika tjänster eller mikrotjänster.

Låt oss återgå till Datadog: från servicekartan kan vi se att användarförfrågningar kommer till Django. Låt oss gå till Django-tjänsten och äntligen se vad vi förväntade oss:

Tyvärr finns det ingen graf här som standard Webbtransaktionstid, liknande det vi ser på huvudpanelen New Relic. Det kan dock konfigureras istället för schemat % av spenderad tid. Det räcker att byta till Genomsnittlig tid per begäran per typ... och nu tittar den välbekanta grafen på oss!

Varför Datadog valde ett annat diagram är ett mysterium för oss. En annan frustrerande sak är 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 anpassade paneler.

Men jag var nöjd med förmågan i Datadog att byta från dessa grafer till mätvärden för relaterade servrar, läsa loggarna och utvärdera belastningen på webbserverhanterarna (Gunicorn). Allt är nästan detsamma som i New Relic... och till och med lite till (loggar)!

Nedanför graferna är transaktioner helt liknande New Relic:

I Datadog anropas transaktioner Resurser. Du kan sortera kontroller efter antalet förfrågningar, efter genomsnittlig svarstid och efter den maximala tiden som spenderas under en vald tidsperiod.

Du kan utöka resursen och se allt som vi redan har observerat i New Relic:

Det finns statistik om resursen, en generaliserad lista över interna samtal och exempel på förfrågningar som kan sorteras efter svarskod... Förresten, våra ingenjörer gillade verkligen denna sortering.

Vilken exempelresurs som helst i Datadog kan öppnas och studeras:

Beställningsparametrar, ett sammanfattande diagram över tiden som spenderats på varje komponent och ett vattenfallsdiagram som visar sekvensen av samtal presenteras. Du kan också växla till en trädvy av vattenfallsdiagrammet:

Och det mest intressanta är att se belastningen på den värd som begäran utfördes på och visa förfrågningsloggarna.

Bra integration!

Du kanske undrar var flikarna är Databaser и Externa tjänster, som i New Relic. Det finns inga här: eftersom Datadog bryter ned applikationen till komponenter kommer PostgreSQL att övervägas en separat tjänst, och istället för externa tjänster är det värt att leta efter aws.storage (det kommer att vara liknande för alla andra externa tjänster som applikationen kan komma åt).

Här är ett exempel med postgres:

Det finns i princip allt vi ville ha:

Du kan se vilken "tjänst" förfrågan kom från.

Det skulle inte vara fel att påminna dig om att Datadog integrerar perfekt med NGINX Ingress och låter dig utföra spårning från det ögonblick som en förfrågan kommer in i klustret, och låter dig även ta emot statistik, samla in loggar och värdmätningar .

Ett stort plus med Datadog är att dess pris tar form från infrastrukturövervakning, APM, Logghantering och Syntettest, d.v.s. Du kan välja din plan flexibelt.

2. Atatus

Atatus-teamet hävdar att deras tjänst är "samma som New Relic, men bättre." Låt oss se om det verkligen är så.

Huvudpanelen ser likadan ut, men det var inte möjligt att bestämma Redis och memcached som används i applikationen.

APM väljer alla transaktioner som standard, även om vanligtvis endast webbtransaktioner behövs. Precis som Datadog finns det inget sätt att navigera till önskad tjänst från huvudpanelen. Dessutom listas transaktioner efter fel, vilket inte verkar särskilt logiskt för APM.

I Atatus-transaktioner är allt så likt New Relic som möjligt. Nackdelen är att dynamiken för varje styrenhet inte syns direkt. Du måste leta efter det i kontrolltabellen, sortera efter Mest tid förbrukad:

Den vanliga listan över styrenheter finns på fliken Utforska:

På något sätt påminner den här tabellen om Datadog och jag gillar den bättre än den liknande i New Relic.

Du kan utöka varje transaktion och se vad applikationen gjorde:

Panelen påminner också mer om Datadog: det finns ett antal förfrågningar, en allmän bild av samtal. Den övre panelen innehåller en felflik HTTP-fel och exempel på långsamma frågor Sessionsspår:

Om du går till en transaktion kan du se ett exempel på en spårning, du kan få en lista med förfrågningar till databasen och titta på förfrågningshuvuden. Allt liknar New Relic:

I allmänhet var Atatus nöjd med detaljerade spår - utan den typiska New Relic limning av samtal i ett påminnelseblock:

Det saknar dock ett filter som (som New Relic) skulle skära av ultrasnabba förfrågningar (<5ms). Å andra sidan gillade jag visningen av det slutliga transaktionssvaret (framgång eller fel).

panel Databaser hjälper dig att studera förfrågningarna till externa databaser som applikationen gör. Låt mig påminna dig om att Atatus bara hittade PostgreSQL och MySQL, även om Redis och memcached också är involverade i projektet.

Förfrågningar sorteras enligt de vanliga kriterierna: svarsfrekvens, genomsnittlig svarstid och så vidare. Jag skulle också vilja nämna fliken med de långsammaste frågorna - det är väldigt bekvämt. Dessutom sammanföll data på den här fliken för PostgreSQL med data från tillägget pg_stat_statements - utmärkt resultat!

Flik Externa förfrågningar helt identisk med databaser.

Resultat

Båda presenterade verktyg fungerade bra i rollen som APM. Vilken som helst av dem kan erbjuda det minimum som krävs. Våra intryck kan kort sammanfattas enligt följande:

datahund

Fördelar:

• bekvämt tariffschema (APM kostar 31 USD per värd);
• fungerade bra med Python;
• Möjlighet till integration med OpenTracing
• integration med Kubernetes;
• integration med NGINX Ingress.

Nackdelar:

• den enda APM som gjorde att applikationen blev otillgänglig på grund av ett modulfel (predis);
• svag PHP-autoinstrumentering;
• delvis märklig definition av tjänster och deras syfte.

Atatus

Fördelar:

• djup PHP-instrumentering;
• användargränssnitt som liknar New Relic.

Nackdelar:

• fungerar inte på äldre operativsystem (Ubuntu 12.05, CentOS 5);
• svag auto-instrumentering;
• stöd för endast två språk (Node.js och PHP);
• Långsamt gränssnitt.

Med tanke på Atatus pris på 69 USD per månad per server så använder vi hellre Datadog som integrerar bra med våra behov (webbapplikationer i K8s) och har många användbara funktioner.

PS

Läs även på vår blogg:

• «Verktyg för utvecklare av applikationer som körs på Kubernetes";
• «kubectl-debug plugin för felsökning i Kubernetes pods";
• «Mikrotjänster: Storleken spelar roll, även om du har Kubernetes".

Källa: will.com