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

In de omgeving van SRE/DevOps-ingenieurs zal het niemand verbazen dat er op een dag een klant (of een monitoringsysteem) verschijnt en meldt dat “alles verloren is”: de site werkt niet, betalingen komen niet door, het leven is aan het vergaan ... Hoe graag je in zo'n situatie ook zou willen helpen, het kan heel moeilijk zijn om dit te doen zonder een eenvoudig en begrijpelijk hulpmiddel. Vaak zit het probleem verborgen in de applicatiecode zelf; u hoeft deze alleen maar te lokaliseren.

En in verdriet en in vreugde...

Het gebeurde zo dat we lang en diep verliefd zijn geworden op New Relic. Het was en blijft een uitstekende tool voor het monitoren van applicatieprestaties, en stelt je ook in staat om de microservice-architectuur te instrumenteren (met behulp van de agent) en nog veel, veel meer. En alles had geweldig kunnen zijn zonder veranderingen in het prijsbeleid van de dienst: het kosten van 2013 jaar groeide 3+ keer. Bovendien vereist het verkrijgen van een proefaccount sinds vorig jaar communicatie met een persoonlijke manager, wat het moeilijk maakt om het product aan een potentiële klant te presenteren.

De gebruikelijke situatie: New Relic is niet ‘permanent’ nodig; ze herinneren het zich pas op het moment dat de problemen beginnen. Maar je moet nog steeds regelmatig betalen (140 USD per server per maand), en in een automatisch schaalbare cloudinfrastructuur lopen de bedragen behoorlijk hoog op. Hoewel er een Pay-As-You-Go-optie is, vereist het inschakelen van New Relic dat u de applicatie opnieuw start, wat kan leiden tot het verlies van de problematische situatie waarvoor het allemaal is begonnen. Nog niet zo lang geleden introduceerde New Relic een nieuw tariefplan - Basisbenodigdheden, - wat op het eerste gezicht een redelijk alternatief lijkt voor Professional... maar bij nader onderzoek bleek dat een aantal belangrijke functies ontbreken (het heeft met name geen Belangrijke transacties, Cross-applicatietracering, Gedistribueerde tracering).

Hierdoor zijn we gaan nadenken over het zoeken naar een goedkoper alternatief en is onze keuze gevallen op twee diensten: Datadog en Atatus. Waarom op hen?

Over concurrenten

Laat ik meteen zeggen dat er andere oplossingen op de markt zijn. We hebben zelfs Open Source-opties overwogen, maar niet elke klant heeft vrije capaciteit om zelfgehoste oplossingen te hosten... - bovendien zullen ze extra onderhoud vergen. Het echtpaar dat we kozen bleek het dichtst bij te staan onze behoeften:

ingebouwde en ontwikkelde ondersteuning voor PHP-applicaties (de stack van onze klanten is zeer divers, maar dit is een duidelijke leider in de context van het zoeken naar een alternatief voor New Relic);
betaalbare kosten (minder dan 100 USD per maand per host);
automatische instrumentatie;
integratie met Kubernetes;
De gelijkenis met de New Relic-interface is een opvallend pluspunt (omdat onze engineers eraan gewend zijn).

Daarom hebben we in de eerste selectiefase verschillende andere populaire oplossingen geëlimineerd, en in het bijzonder:

Tideways, AppDynamics en Dynatrace – tegen kostprijs;
Stackify is geblokkeerd in de Russische Federatie en toont te weinig gegevens.

De rest van het artikel is zo opgebouwd dat de betreffende oplossingen eerst kort worden gepresenteerd, waarna ik zal praten over onze typische interactie met New Relic en ervaringen/indrukken van het uitvoeren van soortgelijke operaties in andere diensten.

Presentatie van geselecteerde concurrenten

Про New Relic, waarschijnlijk heeft iedereen het gehoord? Deze dienst begon zijn ontwikkeling meer dan 10 jaar geleden, in 2008. We gebruiken het actief sinds 2012 en hebben zonder problemen een heel groot aantal applicaties in PHP, Ruby en Python kunnen integreren, en we hebben ook ervaring met de integratie met C# en Go. De auteurs van de service hebben oplossingen voor het monitoren van applicaties, infrastructuur, het traceren van microservice-infrastructuren, het creëren van handige applicaties voor gebruikersapparaten en nog veel meer.

De New Relic-agent draait echter op eigen protocollen en ondersteunt OpenTracing niet. Geavanceerde instrumentatie vereist bewerkingen specifiek voor New Relic. Ten slotte is de ondersteuning van Kubernetes nog experimenteel.

Begon de ontwikkeling ervan in 2010 Datadog ziet er merkbaar interessanter uit dan New Relic, juist qua gebruik in Kubernetes-omgevingen. Het ondersteunt in het bijzonder de integratie met NGINX Ingress, logverzameling, statsd en OpenTracing-protocollen, waarmee u een gebruikersverzoek kunt volgen vanaf het moment dat het is verbonden tot het is voltooid, en ook logboeken voor dit verzoek kunt vinden (zowel aan de kant van de webserver en die van de consument).

Bij het gebruik van Datadog kwamen we tegen dat de microservicekaart soms verkeerd werd opgebouwd, en dat er enkele technische tekortkomingen waren. Het identificeerde bijvoorbeeld het servicetype verkeerd (waarbij Django werd aangezien voor een cachingservice) en veroorzaakte 500 fouten in een PHP-applicatie die de populaire Predis-bibliotheek gebruikte.

Atatus — het jongste instrument; de dienst werd gelanceerd in 2014. Het marketingbudget is duidelijk inferieur aan dat van de beursgenoteerde concurrenten, vermeldingen komen veel minder vaak voor. De tool zelf lijkt echter sterk op New Relic, niet alleen qua mogelijkheden (APM, browsermonitoring, enz.), maar ook qua uiterlijk.

Een belangrijk nadeel is dat het alleen Node.js en PHP ondersteunt. Aan de andere kant is het merkbaar beter geïmplementeerd dan Datadog. In tegenstelling tot laatstgenoemde vereist Atatus niet dat applicaties wijzigingen aanbrengen of extra labels aan de code toevoegen.

Hoe wij werken met New Relic

Laten we nu eens kijken hoe we New Relic over het algemeen gebruiken. Stel dat we een probleem hebben dat een oplossing nodig heeft:

Het is gemakkelijk te zien op de grafiek всплеск - Laten we het analyseren. In New Relic worden webtransacties onmiddellijk geselecteerd voor een webapplicatie, worden alle componenten aangegeven in de prestatiegrafiek, zijn er panelen met foutenpercentage en verzoekpercentages... Het belangrijkste is dat je rechtstreeks vanuit deze panelen kunt schakelen tussen verschillende delen van de applicatie (als u bijvoorbeeld op MySQL klikt, wordt u naar het databasegedeelte geleid).

Omdat we in het beschouwde voorbeeld een toename van de activiteit zien PHP, klik op dit diagram en ga automatisch naar Transacties:

De lijst met transacties, die in wezen controllers uit het MVC-model zijn, is al gesorteerd Meest tijdrovend, wat erg handig is: we zien meteen wat de applicatie doet. Hier zijn voorbeelden van lange zoekopdrachten die automatisch door New Relic worden verzameld. Door de sortering te wijzigen, kunt u eenvoudig het volgende vinden:

de meest geladen applicatiecontroller;
meest gevraagde verwerkingsverantwoordelijke;
de langzaamste van de controllers.

Bovendien kunt u elke transactie uitvouwen en zien wat de applicatie aan het doen was op het moment dat de code werd uitgevoerd:

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

Het is duidelijk dat twee methoden veel tijd in beslag nemen, en tegelijkertijd worden ook het tijdstip waarop het verzoek werd uitgevoerd, de URI en het domein weergegeven. Vaak helpt dit om het verzoek in de logboeken te vinden. Gaan naar Traceer details, kun je zien waar deze methoden vandaan worden aangeroepen:

En in Databasequery's — het evalueren van zoekopdrachten naar databases die zijn uitgevoerd terwijl de applicatie actief was:

Gewapend met deze kennis kunnen we evalueren waarom de applicatie langzamer gaat werken en samen met de ontwikkelaar een strategie bedenken om het probleem op te lossen. In werkelijkheid geeft New Relic niet altijd een duidelijk beeld, maar het helpt wel om de onderzoeksvector te kiezen:

lang PDO::Construct leidde ons naar de vreemde werking van pgpoll;
instabiliteit in de loop van de tijd Memcache::Get suggereerde dat de virtuele machine verkeerd was geconfigureerd;
een verdacht langere tijd voor sjabloonverwerking leidde tot een geneste lus die de aanwezigheid van 500 avatars in de objectopslag controleerde;
enzovoort…

Het komt ook voor dat in plaats van code uit te voeren, er iets met betrekking tot externe gegevensopslag op het hoofdscherm groeit - en het maakt niet uit wat het zal zijn: Redis of PostgreSQL - ze zijn allemaal verborgen op het tabblad databases.

U kunt een specifieke basis voor onderzoek selecteren en zoekopdrachten sorteren, vergelijkbaar met hoe u dit doet in Transacties. En door naar het tabblad Verzoeken te gaan, kunt u zien hoe vaak dit verzoek in elk van de applicatiecontrollers voorkomt, en ook schatten hoe vaak het wordt aangeroepen. Het is zeer comfortabel:

Het tabblad bevat vergelijkbare gegevens Externe dienstverlening, dat verzoeken aan externe HTTP-services verbergt, zoals toegang tot objectopslag, het verzenden van gebeurtenissen naar de schildwacht en dergelijke. De inhoud van het tabblad is volledig vergelijkbaar met Databases:

Concurrenten: kansen en indrukken

Het meest interessante is nu om de mogelijkheden van New Relic te vergelijken met wat concurrenten bieden. Helaas konden we niet alle drie de tools testen op één versie van één applicatie die in productie was. We hebben echter geprobeerd situaties/configuraties die zo identiek mogelijk waren met elkaar te vergelijken.

1. Gegevenshond

Datadog begroet ons met een paneel met een muur van diensten:

Het probeert applicaties op te splitsen in componenten/microservices, dus in de voorbeeld-Django-applicatie zien we 2 verbindingen met PostgreSQL (defaultdb и postgres), evenals Selderij, Redis. Werken met Datadog vereist dat u minimale kennis heeft van de MVC-principes: u moet begrijpen waar gebruikersverzoeken doorgaans vandaan komen. Dit helpt meestal diensten kaart:

Er zit trouwens iets soortgelijks in New Relic:

... en hun kaart is naar mijn mening eenvoudiger en duidelijker gemaakt: het geeft niet de componenten van één applicatie weer (waardoor het overdreven gedetailleerd zou worden, zoals in het geval van Datadog), maar alleen specifieke services of microservices.

Laten we terugkeren naar Datadog: uit de servicekaart kunnen we zien dat gebruikersverzoeken naar Django komen. Laten we naar de Django-service gaan en eindelijk zien wat we verwachtten:

Helaas is hier standaard geen grafiek aanwezig Webtransactietijd, vergelijkbaar met wat we zien op het hoofdpaneel van New Relic. Het kan echter worden geconfigureerd in plaats van het schema % van bestede tijd. Het is voldoende om er naar over te schakelen Gemiddelde tijd per verzoek per type... en nu kijkt de bekende grafiek naar ons!

Waarom Datadog voor een andere grafiek heeft gekozen, is ons een raadsel. Een ander frustrerend punt is dat het systeem de keuze van de gebruiker niet onthoudt (in tegenstelling tot beide concurrenten), en daarom is de enige oplossing het maken van aangepaste panelen.

Maar ik was blij met de mogelijkheid in Datadog om van deze grafieken over te schakelen naar de statistieken van gerelateerde servers, de logs te lezen en de belasting van de webserverhandlers (Gunicorn) te evalueren. Alles is bijna hetzelfde als in New Relic... en zelfs een beetje meer (logs)!

Onder de grafieken staan transacties die volledig vergelijkbaar zijn met New Relic:

In Datadog worden transacties aangeroepen bronnen. U kunt controllers sorteren op het aantal verzoeken, op de gemiddelde responstijd en op de maximale bestede tijd gedurende een geselecteerde periode.

Je kunt de bron uitbreiden en alles zien wat we al hebben waargenomen in New Relic:

Er zijn statistieken over de bron, een algemene lijst met interne oproepen en voorbeelden van verzoeken die kunnen worden gesorteerd op responscode... Trouwens, onze technici vonden deze sortering erg leuk.

Elke voorbeeldbron in Datadog kan worden geopend en bestudeerd:

Er worden aanvraagparameters, een samenvattend diagram van de tijd besteed aan elk onderdeel en een watervaldiagram weergegeven dat de volgorde van de oproepen weergeeft. U kunt ook overschakelen naar een boomstructuur 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 verzoeklogboeken.

Geweldige integratie!

Je vraagt je misschien af waar de tabbladen zijn databases и Externe dienstverlening, zoals in New Relic. Die zijn er hier niet: aangezien Datadog de applicatie in componenten opsplitst, wordt PostgreSQL overwogen een aparte dienst, en in plaats van Externe Services is het de moeite waard om naar te zoeken aws.storage (het zal vergelijkbaar zijn voor elke andere externe service waartoe de applicatie toegang heeft).

Hier is een voorbeeld met postgres:

In wezen is er alles wat we wilden:

U kunt zien van welke “dienst” het verzoek afkomstig is.

Het zou niet verkeerd zijn om u eraan te herinneren dat Datadog perfect integreert met NGINX Ingress en u in staat stelt end-to-end tracering uit te voeren vanaf het moment dat een verzoek in het cluster binnenkomt, en u ook in staat stelt statistieken te ontvangen, logs te verzamelen en statistieken te hosten. .

Een groot pluspunt van Datadog is de prijs krijgt vorm van infrastructuurmonitoring, APM, logbeheer en synthetische tests, d.w.z. Je kunt je abonnement flexibel kiezen.

2. Atatus

Het Atatus-team beweert dat hun service “hetzelfde is als New Relic, maar dan beter.” Laten we eens kijken of dit echt zo is.

Het hoofdpaneel ziet er hetzelfde uit, maar het was niet mogelijk om de Redis en memcached te bepalen die in de applicatie werden gebruikt.

APM selecteert standaard alle transacties, hoewel doorgaans alleen webtransacties nodig zijn. Net als Datadog is er geen manier om vanuit het hoofdpaneel naar de gewenste service te navigeren. Bovendien worden transacties na fouten vermeld, wat voor APM niet erg logisch lijkt.

Bij Atatus-transacties lijkt alles zoveel mogelijk op New Relic. Het nadeel is dat de dynamiek per controller niet direct zichtbaar is. Je moet ernaar zoeken in de controllertabel, sorteren op De meeste tijd verbruikt:

De gebruikelijke lijst met controllers is beschikbaar op het tabblad Ga op onderzoek uit:

In sommige opzichten doet deze tabel denken aan Datadog en ik vind hem beter dan de vergelijkbare in New Relic.

U kunt elke transactie uitvouwen en zien wat de applicatie deed:

Het panel doet ook meer denken aan Datadog: er is een aantal verzoeken, een algemeen beeld van oproepen. Het bovenste paneel bevat een fouttabblad HTTP-fouten en voorbeelden van langzame zoekopdrachten Sessiesporen:

Als u naar een transactie gaat, ziet u een voorbeeld van een tracering, kunt u een lijst met verzoeken aan de database opvragen en de verzoekheaders bekijken. Alles lijkt op New Relic:

Over het algemeen was Atatus tevreden met gedetailleerde sporen - zonder de typische New Relic-oproep in een herinneringsblok:

Het mist echter een filter dat (zoals New Relic) ultrasnelle verzoeken (<5 ms) zou afsnijden. Aan de andere kant vond ik de weergave van het uiteindelijke transactieantwoord (succes of fout) leuk.

paneel databases helpt u bij het bestuderen van de verzoeken aan externe databases die de applicatie doet. Laat me je eraan herinneren dat Atatus alleen PostgreSQL en MySQL heeft gevonden, hoewel Redis en memcached ook bij het project betrokken zijn.

Verzoeken worden gesorteerd volgens de gebruikelijke criteria: responsfrequentie, gemiddelde responstijd, enzovoort. Ik zou ook graag het tabblad met de langzaamste zoekopdrachten willen noemen - het is erg handig. Bovendien vielen de gegevens op dit tabblad voor PostgreSQL samen met de gegevens uit de extensie pg_stat_statements - uitstekend resultaat!

Tab Externe verzoeken volledig identiek aan Databases.

Bevindingen

Beide gepresenteerde tools presteerden goed in de rol van APM. Elk van hen kan het vereiste minimum bieden. Onze indrukken kunnen als volgt kort worden samengevat:

Datadog

Voors:

handig tariefschema (APM kost 31 USD per host);
werkte goed met Python;
Mogelijkheid tot integratie met OpenTracing
integratie met Kubernetes;
integratie met NGINX Ingress.

Tegens:

de enige APM die ervoor zorgde dat de applicatie niet beschikbaar was vanwege een modulefout (predis);
zwakke automatische PHP-instrumentatie;
deels vreemde definitie van diensten en hun doel.

Atatus