🥇Niet alleen met New Relic: een blik op Datadog en Atatus

In de SRE-/DevOps-wereld is het niet verrassend dat er op een gegeven moment een klant (of een monitoringsysteem) opduikt en meldt dat "alles verloren is": de site werkt niet, betalingen komen niet door, het leven is zinloos... Hoezeer we ook willen helpen in zo'n situatie, het kan erg moeilijk zijn zonder een eenvoudige en duidelijke tool. Vaak ligt het probleem verborgen in de code van de applicatie zelf — het is gewoon een kwestie van het lokaliseren ervan.

In vreugde en verdriet...

Het is zo gegroeid dat we New Relic al een behoorlijke tijd zeer waarderen. Het was en blijft een uitstekend middel voor het monitoren van de applicatieprestaties, en stelt ons in staat om microservices-architectuur te instrumenteren (met behulp van zijn agent) en nog veel meer. En alles zou geweldig kunnen zijn, als het niet was voor de veranderingen in het prijsbeleid van de service: zijn prijs sinds 2013 is meer dan 3 keer gestegen. Bovendien is het sinds vorig jaar nodig om contact op te nemen met een persoonlijke manager voor het verkrijgen van een trial-account, wat de presentatie van het product aan potentiële klanten bemoeilijkt.

Een gangbare situatie: New Relic is niet nodig op 'permanente basis', je denkt er pas aan als er problemen ontstaan. Maar je moet toch regelmatig betalen (140 USD per server per maand), en in een automatisch schalende cloudinfrastructuur lopen de kosten behoorlijk op. Hoewel er een 'Pay-As-You-Go'-optie is, vereist het inschakelen van New Relic een herstart van de applicatie, wat kan leiden tot het verliezen van de probleem situatie waarvoor alles in gang werd gezet. Niet zo lang geleden heeft New Relic een nieuw tariefplan geïntroduceerd — Essentials, — dat op het eerste gezicht een redelijke alternatieve lijkt voor Professional… maar bij nadere inspectie bleek dat enkele belangrijke functies ontbreken (met name ontbreken de) Key Transactions, Cross Application Tracing, Distributed Tracing).

Als gevolg hiervan gingen we op zoek naar goedkopere alternatieven, en viel onze keuze op twee diensten: Datadog en Atatus. Waarom precies deze?

Over de concurrentie

Ik wil er meteen bij zeggen dat er ook andere oplossingen op de markt zijn. We hebben zelfs open source opties overwogen, maar niet elke klant heeft de vrije middelen om oplossingen in de categorie self-hosted te implementeren… — bovendien vereisen ze extra onderhoud. Het paar dat wij hebben gekozen bleek het dichtst bij onze behoeften te staan:

Geïntegreerde en uitgebreide ondersteuning voor PHP-toepassingen (de stapel van onze klanten is zeer divers, maar dit is een duidelijke leider in de context van het zoeken naar alternatieven voor New Relic);
Betaalbare kosten (minder dan 100 USD per maand voor hosting);
Automatische instrumentatie;
Integratie met Kubernetes;
Gelijkenis met de interface van New Relic — een merkbaar pluspunt (omdat onze ingenieurs eraan gewend zijn).

Daarom hebben we tijdens de eerste selectie verschillende andere populaire oplossingen afgewezen, met name:

Tideways, AppDynamics en Dynatrace — vanwege de kosten;
Stackify — geblokkeerd in Rusland en toont te weinig gegevens.

Het verdere artikel is zo opgebouwd dat eerst de beschikbare oplossingen kort worden gepresenteerd, waarna ik ons typische interactie met New Relic en onze ervaringen/impressies van het uitvoeren van soortgelijke operaties in andere diensten zal bespreken.

Voorstelling van de geselecteerde concurrenten

Over New Relic, misschien heeft iedereen ervan gehoord? Deze service begon zijn ontwikkeling meer dan 10 jaar geleden, in 2008. We maken er actief gebruik van sinds 2012 en hebben geen problemen ondervonden met de integratie van een echt groot aantal toepassingen in PHP, Ruby en Python, en we hebben ook ervaring met integratie met C# en Go. De auteurs van de service hebben oplossingen voor het monitoren van toepassingen, infrastructuren, het traceren van microservice-infrastructuren, er zijn handige applicaties voor gebruikersapparaten en nog veel meer.

Echter, de agent van New Relic werkt met propriëtaire protocollen, er is geen ondersteuning voor OpenTracing. Voor uitgebreide instrumentatie is het nodig om speciaal voor New Relic aanpassingen te doen. Ten slotte heeft de ondersteuning voor Kubernetes momenteel een experimentele status.

Gesteund vanaf 2010, Datadog ziet er duidelijk interessanter uit dan New Relic, vooral als het gaat om gebruik in Kubernetes-omgevingen. Het ondersteunt bijvoorbeeld integratie met NGINX Ingress, het verzamelen van logs, statsd- en OpenTracing-protocollen, wat het mogelijk maakt om een gebruikersaanroep van het moment van verbinding tot het einde van de verwerking te volgen en ook logs voor deze aanroep te vinden (zowel aan de kant van de webserver als aan de kant van de consumenten).

Bij het gebruik van Datadog stuitten we op het feit dat het soms de kaart van microservices verkeerd opbouwde en enkele technische tekortkomingen had. Bijvoorbeeld, het identificeerde de servicetype verkeerd (zag Django als een cache-service) en veroorzaakte 500-fouten in de PHP-toepassing die gebruikmaakte van de populaire bibliotheek Predis.

Atatus — de jongste tool; de service werd gelanceerd in 2014. Het marketingbudget is duidelijk lager dan dat van de genoemde concurrenten, en vermeldingen komen veel minder vaak voor. Desondanks lijkt de tool zelf sterk op New Relic, niet alleen qua mogelijkheden (APM, Browser monitoring, enz.), maar ook qua uiterlijk.

Een significant nadeel is echter de ondersteuning alleen voor Node.js en PHP. Aan de andere kant is deze ondersteuning merkbaar beter uitgevoerd dan die van Datadog. In tegenstelling tot het laatste vereist Atatus geen aanpassingen in de applicaties en het instellen van extra labels in de code.

Hoe wij werken met New Relic

Laten we nu bekijken hoe we New Relic doorgaans gebruiken. Stel dat we een probleem hebben dat opgelost moet worden:

Op de grafiek is het gemakkelijk te zien een piek — laten we deze analyseren. In New Relic zijn voor de webapplicatie onmiddellijk de webtransacties geselecteerd, de prestatiegrafiek geeft alle componenten weer, en er zijn panels voor error-rate, request-rate… Wat belangrijk is, is dat je rechtstreeks vanuit deze panelen kunt navigeren tussen verschillende delen van de applicatie (bijvoorbeeld, een klik op MySQL leidt naar het databankgedeelte).

Aangezien we in het besproken voorbeeld een piek in activiteit zien PHP, klikken we op deze grafiek en gaan automatisch naar Transacties:

De lijst met transacties, die in wezen controllers zijn uit het MVC-model, is al gesorteerd op Meest tijdrovend, wat erg handig is: we zien meteen waar de applicatie mee bezig is. Hier zijn ook voorbeelden van lange verzoeken die automatisch door New Relic worden verzameld. Door de sortering te veranderen, kunnen we gemakkelijk vinden:

de meest belaste controller van de applicatie;
de meest gevraagde controller;
de langzaamste controller.

Bovendien kun je elke transactie uitbreiden en zien waar de applicatie mee bezig was op het moment dat de code uitvoerde:

Ten slotte worden in de applicatie voorbeelden van lange verzoeken (die langer dan 2 seconden duren) opgeslagen. Hier is het paneel voor een lange transactie:

Het is duidelijk dat twee methoden veel tijd in beslag nemen, en daarnaast wordt ook weergegeven wanneer het verzoek is uitgevoerd, zijn URI en domein. Dit helpt zeer vaak bij het vinden van verzoeken in de logs. Door naar Trace details, kun je zien waar deze methoden worden aangeroepen:

En bij Database queries — evalueer de databaseverzoeken die tijdens de werking van de applicatie zijn uitgevoerd:

Met deze kennis kunnen we de oorzaak van de vertraging van de applicatie beoordelen en samen met de ontwikkelaar een strategie ontwikkelen om het probleem op te lossen. In de praktijk geeft New Relic niet altijd een duidelijk beeld, maar het helpt ons de richting van het onderzoek te kiezen:

langdurig PDO::Construct leidde ons tot een vreemde werking van pgpoll;
tijdinstabiliteit Memcache::Get duidde op een onjuiste configuratie van de virtuele machine;
een verdacht lange verwerkingstijd van de sjabloon leidde tot een geneste lus die controleerde op 500 avatars in de objectopslag;
enzovoort…

Het komt ook voor dat in plaats van de hoofdschermcode iets dat met externe gegevensopslag te maken heeft toeneemt — en het maakt niet uit of het Redis of PostgreSQL is, ze verbergen zich allemaal onder de tab Databases.

Je kunt een specifieke database kiezen om te onderzoeken en de aanvragen te sorteren — vergelijkbaar met hoe het in Transactions wordt gedaan. En door naar de aanvraagtab te gaan, kun je zien hoe vaak deze aanvraag voorkomt in elk van de controllers van de applicatie en ook beoordelen hoe vaak deze wordt aangeroepen. Dit is zeer handig:

Vergelijkbare gegevens bevatten de tab External Services, die de aanvragen aan externe HTTP-diensten verbergt, zoals een verzoek aan de objectopslag, het verzenden van gebeurtenissen naar Sentry of iets dergelijks. Inhoudelijk is de tab volledig vergelijkbaar met Databases:

Concurrenten: mogelijkheden en indrukken

Nu komt het interessante deel — laten we de mogelijkheden van New Relic vergelijken met wat de concurrenten aanbieden. Helaas konden we alle drie de tools niet testen op dezelfde versie van een werkende production-applicatie. Desondanks hebben we ons best gedaan om zoveel mogelijk identieke situaties/configuraties te vergelijken.

1. Datadog

Datadog verwelkomt ons met een dashboard met een wand van services:

Het probeert applicaties op te splitsen in componenten/microservices, dus voor de in het voorbeeld gegeven Django-applicatie zullen we 2 verbindingen met PostgreSQL zien (defaultdb en postgres), evenals Celery, Redis. Werken met Datadog vereist minimale kennis van de MVC-principes: je moet begrijpen waar de gebruikersverzoeken überhaupt binnenkomen. Gewoonlijk helpt een servicemap:

bij dit, wat vergelijkbaar is met wat er in New Relic is:

… en naar mijn mening is hun kaart eenvoudiger en duidelijker gemaakt: het toont niet de componenten van één applicatie (wat het te gedetailleerd zou maken, zoals in het geval van Datadog), maar alleen specifieke diensten of microservices.

Laten we teruggaan naar Datadog: uit de dienstenkaarten blijkt dat gebruikersverzoeken binnenkomen in Django. Laten we naar de Django-service gaan en eindelijk zien wat we verwachtten:

Helaas is er standaard hier geen grafiek Webtransactietijd, vergelijkbaar met wat we op het hoofdscherm van New Relic zien. Maar het kan ter plaatse worden ingesteld op de grafiek % van de beste tijd besteed. Het is voldoende om het om te schakelen naar Gemiddelde tijd per verzoek per type… en daar is de bekende grafiek weer!

Waarom er in Datadog voor een andere grafiek is gekozen, blijft voor ons een raadsel. Het was ook teleurstellend dat het systeem de keuze van de gebruiker niet onthoudt (in tegenstelling tot beide concurrenten), waardoor alleen het creëren van gebruikerspanelen helpt.

Maar we waren blij met de mogelijkheid in Datadog om van deze grafieken naar de statistieken van verbonden servers over te schakelen, de logs te lezen en de belasting van de webserververwerkers (Gunicorn) te evalueren. Het is bijna hetzelfde als in New Relic… en zelfs iets meer (logs)!

Onder de grafieken bevinden zich de transacties, die volledig vergelijkbaar zijn met New Relic:

In Datadog worden transacties resourcesgenoemd. Je kunt controllers sorteren op het aantal verzoeken, de gemiddelde responstijd, de maximale tijd die is besteed in de gekozen periode.

Een resource kan worden uitgeklapt en je kunt alles zien wat we al in New Relic hebben waargenomen:

Er zijn statistieken voor de resource, een samenvattende lijst van interne oproepen en voorbeeldverzoeken die kunnen worden gesorteerd op de responscode… Trouwens, deze sorteermogelijkheid viel onze ingenieurs erg in de smaak.

Elk resourcevoorbeeld in Datadog kan worden geopend en bestudeerd:

De parametereisen zijn weergegeven, een samenvattende grafiek van de tijd die aan elk van de componenten is besteed en een watervaldiagram waarin de volgorde van oproepen zichtbaar is. Ook is er de mogelijkheid om over te schakelen naar de hiërarchische weergave van het watervaldiagram:

En het meest interessante is het bekijken van de belasting van de host waarop het verzoek is uitgevoerd, en het bekijken van de verzoeklogs.

Geweldige integratie!

Er kan een vraag opkomen over de tabs Databases en External Services, zoals in New Relic. Hier zijn ze er niet: omdat Datadog de applicatie in componenten onderverdeelt, zal PostgreSQL worden beschouwd als een aparte service, en in plaats van Externe Diensten moet je zoeken naar aws.storage (dezelfde geldt voor elk ander extern service waar de applicatie contact mee kan maken).

Hier is een voorbeeld van postgres:

In feite is alles zoals we wilden:

Het is zichtbaar uit welke ‘service’ het verzoek afkomstig is.

Het is een goede herinnering dat Datadog uitstekend integreert met NGINX Ingress en end-to-end tracing mogelijk maakt vanaf het moment dat een verzoek het cluster binnenkomt, en het laat toe statsd-metrics te verzamelen, logs en hostmetrics te verzamelen.

Een groot voordeel van Datadog is dat de prijs bestaat uit infrastructuurmonitoring, APM, Log Management en Synthetics test, wat betekent dat je flexibel een plan kunt kiezen.

2. Atatus

Het Atatus-team beweert dat hun service ‘net zo is als New Relic, maar beter’. Laten we kijken of dat echt zo is.

De hoofdpaneel ziet er inderdaad vergelijkbaar uit, maar het lukte niet om de gebruikte Redis en memcached in de applicatie te identificeren.

APM selecteert standaard alle transacties, hoewel meestal alleen webtransacties nodig zijn. Net als bij Datadog is er geen mogelijkheid om van de hoofdpaneel naar de gewenste service te schakelen. Bovendien staan transacties op de lijst na fouten, wat voor APM niet erg logisch lijkt.

In de transacties lijkt Atatus sterk op New Relic. Een nadeel is dat de dynamiek voor elk van de controllers niet direct zichtbaar is. Je moet deze in de tabel met controllers zoeken, sorterend op Meest Verbruikte Tijd:

De voor ons vertrouwde lijst met controllers is beschikbaar op het tabblad Verkennen:

Op de een of andere manier lijkt deze tabel op Datadog en bevalt beter dan de vergelijkbare in New Relic.

Elke transactie kan worden uitgevouwen en je kunt zien waar de applicatie mee bezig was:

Het paneel doet ook meer denken aan Datadog: er zijn het aantal verzoeken, het algemene beeld van de oproepen. De bovenste panel biedt een tabblad met fouten HTTP Fouten en voorbeelden van langzame verzoeken Sessietraces:

Als je naar de transactie gaat, zie je een voorbeeld van de trace, je kunt een lijst met databaseverzoeken krijgen en de headers van de verzoeken bekijken. Alles is vergelijkbaar met New Relic:

Atatus heeft ons echt verrast met gedetailleerde traces — zonder de typische samenvoegingen van oproepen in het reminder-blok van New Relic:

Echter, hier ontbreekt het filter dat (zoals in New Relic) de extreem snelle verzoeken (<5ms) uitsluit. Aan de andere kant vond ik het fijn dat de uiteindelijke respons van de transactie (succesvol of fout) zichtbaar was.

Het paneel Databases zal helpen bij het onderzoeken van de verzoeken aan externe databases die de applicatie maakt. Ter herinnering, Atatus vond alleen PostgreSQL en MySQL, hoewel in het project ook Redis en memcached worden gebruikt.

Verzoeken worden gesorteerd op gebruikelijke criteria: frequentie van activatie, gemiddelde responstijd, enzovoorts. We willen speciaal de tab met de traagste verzoeken benadrukken — dit is zeer handig. Bovendien kwamen de gegevens in deze tab voor PostgreSQL overeen met de gegevens van de extensie. pg_stat_statements — een uitstekend resultaat!

Het tabblad Externe Verzoeken is volledig identiek aan Databases.

Conclusies

Beide gepresenteerde tools hebben zich goed bewezen als APM. Elke tool biedt het noodzakelijke minimum. Onze indrukken kunnen kort samengevat worden als:

Datadog

Voordelen:

handig prijsmodel (APM kost 31 USD per host);
werkte uitstekend met Python;
mogelijkheid tot integratie met OpenTracing
Integratie met Kubernetes;
integratie met NGINX Ingress.

Nadelen:

de enige APM die de onbeschikbaarheid van de applicatie veroorzaakte door een modulefout (predis);
zwakke auto-instrumentatie voor PHP;
enigszins vreemde definitie van services en hun doeleinden.

Atatus

Voordelen:

diepe instrumentatie voor PHP;
vergelijkbaar met de gebruikersinterface van New Relic.

Nadelen:

werkt niet op oudere besturingssystemen (Ubuntu 12.05, CentOS 5);
zwakke auto-instrumentatie;
ondersteunt slechts twee programmeertalen (Node.js en PHP);
trage werking van de interface.

Gegeven de prijs van Atatus van 69 USD per maand per server, zouden we eerder Datadog gebruiken, dat uitstekend integreert met onze behoeften (webapplicaties in K8s) en veel nuttige functies heeft.