🥇Nem csak a New Relic: egy pillantás a Datadogra és az Atatusra ProHoster

Az SRE/DevOps mérnökök környezetében senkit sem lep meg, ha egy nap megjelenik egy ügyfél (vagy egy felügyeleti rendszer), és azt jelenti, hogy „minden elveszett”: nem működik az oldal, nem mennek át a fizetések, hanyatlik az élet ... Bármennyire is szeretne segíteni egy ilyen helyzetben, ezt nagyon nehéz megtenni egy egyszerű és érthető eszköz nélkül. A probléma gyakran magában az alkalmazás kódjában van elrejtve; csak lokalizálnia kell.

És bánatban és örömben…

Így történt, hogy régóta és mélyen beleszerettünk az Új Ereklyébe. Kiváló eszköz volt és marad az alkalmazások teljesítményének nyomon követésére, valamint lehetővé teszi a mikroszolgáltatási architektúra (ügynöke segítségével) és még sok más eszközzel. És minden nagyszerű lehetett volna, ha nem változtatnak a szolgáltatás árpolitikájában: ez költség az 2013 évtől 3+-szorosára nőtt. Ráadásul tavaly óta a próbaszámla megszerzéséhez személyes menedzserrel kell kommunikálni, ami megnehezíti a termék bemutatását a potenciális vásárlóknak.

A szokásos helyzet: az új ereklyére nincs szükség „állandóan”, csak abban a pillanatban emlékeznek rá, amikor a problémák kezdődnek. De továbbra is rendszeresen fizetni kell (kiszolgálónként 140 USD havonta), és az automatikusan skálázódó felhő infrastruktúrában az összegek meglehetősen nagyok. Bár létezik felosztó-kirovó opció, a New Relic engedélyezéséhez újra kell indítania az alkalmazást, ami a problémás helyzet elvesztéséhez vezethet, amely miatt az egészet elindították. Nem sokkal ezelőtt a New Relic új tarifacsomagot vezetett be - Essentials, - ami első ránézésre ésszerű alternatívának tűnik a Professional... de alapos vizsgálat után kiderült, hogy néhány fontos funkció hiányzik (pláne nem rendelkezik Kulcsfontosságú tranzakciók, Cross Application Tracing, Elosztott nyomkövetés).

Ennek eredményeként elkezdtünk gondolkodni egy olcsóbb alternatíva keresésén, és két szolgáltatásra esett a választásunk: a Datadogra és az Atatusra. Miért pont rajtuk?

A versenytársakról

Hadd mondjam el azonnal, hogy vannak más megoldások is a piacon. Még a nyílt forráskódú lehetőségeket is mérlegeltük, de nem minden ügyfélnek van szabad kapacitása saját üzemeltetésű megoldások hosztolására... - ráadásul további karbantartást igényelnek. Az általunk választott pár bizonyult a legközelebbinek igényeinket:

PHP alkalmazások beépített és továbbfejlesztett támogatása (ügyfeleink stackje nagyon sokrétű, de ez egyértelműen vezető szerepet tölt be a New Relic alternatívája keresésében);
megfizethető költség (kevesebb, mint 100 USD havonta hostonként);
automatikus műszerek;
integráció a Kubernetes-szel;
A New Relic interfészhez való hasonlóság észrevehető plusz (mert mérnökeink hozzászoktak).

Ezért a kezdeti kiválasztási szakaszban számos más népszerű megoldást kiküszöböltünk, különösen:

Tideways, AppDynamics és Dynatrace – a költségekért;
A Stackify le van tiltva az Orosz Föderációban, és túl kevés adatot jelenít meg.

A cikk további része úgy van felépítve, hogy először röviden bemutatjuk a szóban forgó megoldásokat, majd a New Relicvel való tipikus interakciónkról és a más szolgáltatásokban végzett hasonló műveletek tapasztalatairól/benyomásairól beszélek.

A kiválasztott versenyzők bemutatása

Про New Relic, valószínűleg mindenki hallotta? Ez a szolgáltatás több mint 10 éve, 2008-ban kezdte meg a fejlesztését. 2012 óta használjuk aktívan, és nem okozott gondot igazán nagyszámú alkalmazás PHP, Ruby és Python integrációja, valamint van tapasztalatunk a C# és Go nyelvekkel való integrációban is. A szolgáltatás készítői megoldásokkal rendelkeznek az alkalmazások, az infrastruktúra figyelésére, a mikroszolgáltatási infrastruktúrák nyomon követésére, kényelmes alkalmazásokat készítettek felhasználói eszközökhöz és sok máshoz.

A New Relic ügynök azonban védett protokollokon fut, és nem támogatja az OpenTracing-et. A fejlett hangszereléshez kifejezetten a New Relichez szükséges szerkesztések. Végül a Kubernetes támogatása még csak kísérleti jellegű.

2010-ben kezdte meg fejlesztését adatkutya észrevehetően érdekesebbnek tűnik, mint a New Relic, pontosan a Kubernetes környezetekben való használat szempontjából. Különösen támogatja az NGINX Ingress-szel, a naplógyűjtéssel, a statsd-vel és az OpenTracing protokollokkal való integrációt, amely lehetővé teszi a felhasználói kérések nyomon követését a csatlakozás pillanatától a befejezésig, valamint a kérés naplóinak megtalálását (mindkettő a webszerver oldalon és a fogyasztóé).

A Datadog használatakor találkoztunk azzal, hogy néha rosszul építette fel a mikroszolgáltatás térképét, illetve technikai hiányosságokkal. Például rosszul azonosította a szolgáltatás típusát (összetéveszti a Django-t egy gyorsítótárazó szolgáltatással), és 500 hibát okozott egy PHP alkalmazásban a népszerű Predis könyvtár használatával.

Atátusz — a legfiatalabb hangszer; a szolgáltatás 2014-ben indult. Marketing költségvetése egyértelműen alulmúlja a felsorolt versenytársakét, az említések sokkal ritkábban fordulnak elő. Maga az eszköz azonban nem csak képességeiben (APM, Browser monitoring stb.), hanem megjelenésében is nagyon hasonlít a New Relic-re.

Jelentős hátránya, hogy csak a Node.js-t és a PHP-t támogatja. Másrészt észrevehetően jobban van megvalósítva, mint a Datadog. Ez utóbbival ellentétben az Atatusnak nincs szüksége az alkalmazásoknak a módosítások elvégzésére vagy további címkék hozzáadására a kódon.

Hogyan dolgozunk a New Relic-vel

Most nézzük meg, hogyan használjuk általában a New Relic-et. Tegyük fel, hogy van egy megoldásra szoruló problémánk:

A grafikonon jól látható всплеск - Elemezzük. A New Relicben a webes tranzakciók azonnal kiválasztásra kerülnek egy webalkalmazáshoz, minden komponens megjelenik a teljesítmény grafikonon, vannak hibaarány, kérésarány panelek... Ami a legfontosabb, hogy közvetlenül ezekről a panelekről lehet mozogni a különböző az alkalmazás egyes részeit (például a MySQL-re kattintva az adatbázis részhez vezet).

Mivel a vizsgált példában az aktivitás felfutását látjuk PHP, kattintson erre a diagramra, és automatikusan lépjen a következőre Tranzakciók:

A tranzakciók listája, amelyek lényegében az MVC modellből származó vezérlők, már rendezve vannak A legtöbb időigényes, ami nagyon kényelmes: azonnal látjuk, mit csinál az alkalmazás. Íme példák hosszú lekérdezésekre, amelyeket a New Relic automatikusan gyűjt. A rendezés váltásával könnyen megtalálhatja:

a legtöbbet terhelt alkalmazásvezérlő;
leggyakrabban kért vezérlő;
a leglassabb a vezérlők közül.

Ezenkívül kibonthatja az egyes tranzakciókat, és megnézheti, mit csinált az alkalmazás a kód végrehajtása idején:

Végül az alkalmazás példákat tárol a hosszú kérések nyomaira (azokra, amelyek több mint 2 másodpercig tartanak). Íme a panel egy hosszú tranzakcióhoz:

Látható, hogy két metódus sok időt vesz igénybe, ugyanakkor megjelenik a kérés végrehajtásának időpontja, annak URI-ja és tartománya is. Nagyon gyakran ez segít megtalálni a kérést a naplókban. Fog Nyomkövetési részletek, láthatja, honnan hívják ezeket a metódusokat:

És Adatbázis lekérdezések — az alkalmazás futása közben végrehajtott adatbázisok lekérdezésének kiértékelése:

Ezzel a tudással felvértezve ki tudjuk értékelni, miért lassul le az alkalmazás, és a fejlesztővel együttműködve stratégiát dolgozunk ki a probléma megoldására. A valóságban az Új Ereklye nem mindig ad tiszta képet, de segít a vizsgálat vektorának kiválasztásában:

hosszú PDO::Construct elvezetett minket a pgpoll furcsa működéséhez;
időbeli instabilitás Memcache::Get azt javasolta, hogy a virtuális gép helytelenül van konfigurálva;
a sablonfeldolgozás gyanúsan megnövekedett ideje egy beágyazott hurokhoz vezetett, amely 500 avatar jelenlétét ellenőrzi az objektumtárolóban;
stb…

Az is előfordul, hogy kód végrehajtása helyett valami külső adattárolással kapcsolatos dolog nő a főképernyőn - és nem mindegy, hogy mi lesz: Redis vagy PostgreSQL - ezek mind el vannak rejtve a lapon Adatbázisok.

Kiválaszthat egy adott kutatási alapot, és rendezheti a lekérdezéseket – hasonlóan ahhoz, ahogyan ez a Tranzakciókban történik. A kérés lapra lépve megtekintheti, hogy ez a kérés hányszor fordul elő az egyes alkalmazásvezérlőkben, és megbecsülheti, hogy milyen gyakran hívják meg. Nagyon kényelmes:

A lap hasonló adatokat tartalmaz Külső szolgáltatások, amely elrejti a külső HTTP-szolgáltatásokhoz intézett kéréseket, például az objektumtároláshoz való hozzáférést, az események küldését az őrszemnek vagy hasonlókat. A lap tartalma teljesen hasonló az adatbázisokhoz:

Versenytársak: lehetőségek és benyomások

Most a legérdekesebb dolog összehasonlítani a New Relic képességeit a versenytársak kínálatával. Sajnos nem tudtuk mindhárom eszközt tesztelni egy élesben futó alkalmazás egy verzióján. Megpróbáltuk azonban összehasonlítani a lehető legnagyobb mértékben azonos helyzeteket/konfigurációkat.

1. Adatlap

A Datadog szolgáltatásfallal ellátott panellel köszönt bennünket:

Megpróbálja az alkalmazásokat komponensekre/mikroszolgáltatásokra bontani, így a példa Django alkalmazásban 2 kapcsolatot fogunk látni a PostgreSQL-lel (defaultdb и postgres), valamint Celery, Redis. A Datadoggal való munkavégzés megköveteli, hogy minimális ismeretekkel rendelkezzen az MVC elveiről: meg kell értenie, hogy általában honnan származnak a felhasználói kérések. Ez általában segít szolgáltatások térképe:

Egyébként a New Relicben is van valami hasonló:

... a térképük pedig véleményem szerint egyszerűbb és áttekinthetőbb: nem egy alkalmazás összetevőit jeleníti meg (ami túlzottan részletessé tenné, mint a Datadog esetében), hanem csak konkrét szolgáltatásokat vagy mikroszolgáltatásokat.

Térjünk vissza a Datadoghoz: a szolgáltatástérképről láthatjuk, hogy felhasználói kérések érkeznek a Django-hoz. Menjünk a Django szolgáltatáshoz, és nézzük meg végre, mire számítottunk:

Sajnos itt alapértelmezés szerint nincs grafikon Webes tranzakció ideje, hasonlóan ahhoz, amit a fő New Relic panelen látunk. Az ütemezés helyett azonban konfigurálható Az eltöltött idő %-a. Elég rá váltani Átlagos idő kérésenként típus szerint... és most az ismerős grafikon néz ránk!

Számunkra rejtély, hogy a Datadog miért választott más diagramot. Egy másik frusztráló dolog, hogy a rendszer nem emlékszik a felhasználó választására (ellentétben mindkét versenytárssal), ezért az egyetlen megoldás az egyedi panelek létrehozása.

De elégedett voltam azzal, hogy a Datadog képes váltani ezekről a grafikonokról a kapcsolódó szerverek mérőszámaira, elolvasni a naplókat és értékelni a webszerver-kezelők (Gunicorn) terhelését. Minden majdnem ugyanaz, mint az Új Ereklyében... és még egy kicsit több is (naplók)!

A grafikonok alatt a New Relichez teljesen hasonló tranzakciók láthatók:

A Datadogban a tranzakciókat hívják erőforrások. A vezérlőket a kérések száma, az átlagos válaszidő és a kiválasztott időtartamra eltöltött maximális idő szerint rendezheti.

Bővítheti az erőforrást, és mindent megtekinthet, amit már megfigyeltünk az Új ereklyében:

Vannak statisztikák az erőforrásról, általánosított lista a belső hívásokról, és példák válaszkód szerint rendezhető kérésekre... Egyébként a mérnökeinknek nagyon tetszett ez a rendezés.

A Datadog bármely példaforrása megnyitható és tanulmányozható:

Megjelennek a kérési paraméterek, az egyes összetevőkre fordított idő összegző diagramja, valamint a hívások sorrendjét bemutató vízesés diagram. Átválthat a vízesés-diagram fanézetére is:

És a legérdekesebb dolog annak a gazdagépnek a terhelésének megtekintése, amelyen a kérést végrehajtották, és a kérésnaplók megtekintése.

Remek integráció!

Kíváncsi lehet, hol vannak a lapok Adatbázisok и Külső szolgáltatások, mint az Új ereklyében. Itt nincsenek ilyenek: mivel a Datadog az alkalmazást komponensekre bontja, a PostgreSQL számításba kerül külön szolgáltatás, és a Külső szolgáltatások helyett érdemes keresni aws.storage (hasonló lesz minden más külső szolgáltatásnál, amelyet az alkalmazás elérhet).

Itt van egy példa vele postgres:

Lényegében minden van, amire vágytunk:

Láthatja, melyik „szolgáltatástól” érkezett a kérés.

Nem lenne helytelen emlékeztetni, hogy a Datadog tökéletesen integrálódik az NGINX Ingress-szel, és lehetővé teszi a végpontok közötti nyomkövetést attól a pillanattól kezdve, hogy egy kérés megérkezik a fürtbe, valamint lehetővé teszi a statsd metrikák fogadását, a naplók és a gazdagép metrikák gyűjtését. .

A Datadog hatalmas előnye az ára fejlődik infrastruktúra-felügyeletből, APM-ből, Log Management és Synthetics tesztből, i.e. Rugalmasan választhat tervet.

2.Atatus

Az Atatus csapata azt állítja, hogy szolgáltatásuk „ugyanaz, mint a New Relic, de jobb”. Lássuk, tényleg így van-e.

A fő panel ugyan hasonlóan néz ki, de nem lehetett meghatározni az alkalmazásban használt Redis-t és a memcached-et.

Az APM alapértelmezés szerint az összes tranzakciót kiválasztja, bár általában csak webes tranzakciókra van szükség. A Datadoghoz hasonlóan a fő panelről sem lehet a kívánt szolgáltatáshoz navigálni. Ráadásul a tranzakciók a hibák után vannak felsorolva, ami nem tűnik túl logikusnak az APM számára.

Az Atatus tranzakciókban minden a lehető leghasonlatosabb a New Relichez. Hátránya, hogy az egyes vezérlők dinamikája nem látható azonnal. A vezérlőtáblában kell keresni, válogatva A legtöbb időigényes:

A vezérlők szokásos listája a fülön érhető el Fedezd fel:

Bizonyos szempontból ez a táblázat a Datadogra emlékeztet, és nekem jobban tetszik, mint a New Relic hasonló.

Kibonthatja az egyes tranzakciókat, és megnézheti, mit csinált az alkalmazás:

A panel is inkább a Datadogra emlékeztet: számos kérés van, általános kép a hívásokról. A felső panelen található egy hibalap HTTP hibák és példák a lassú lekérdezésekre Munkamenet nyomai:

Ha egy tranzakcióhoz megy, láthat egy példát a nyomkövetésre, megkaphatja az adatbázisba küldött kérések listáját, és megnézheti a kérés fejléceit. Minden hasonló a New Relicéhez:

Általánosságban elmondható, hogy Atatus elégedett a részletes nyomokkal – anélkül, hogy a hívásokat a tipikus új ereklye emlékeztető blokkba ragasztaná:

Hiányzik azonban egy szűrő, amely (mint a New Relic) levágná az ultragyors kéréseket (<5 ms). Viszont tetszett a tranzakció végleges válaszának (siker vagy hiba) megjelenítése.

panel Adatbázisok segít tanulmányozni az alkalmazás által a külső adatbázisokhoz intézett kéréseket. Hadd emlékeztesselek arra, hogy az Atatus csak a PostgreSQL-t és a MySQL-t találta meg, bár a Redis és a memcached is részt vesz a projektben.

A kéréseket a szokásos kritériumok szerint rendezzük: válaszadási gyakoriság, átlagos válaszidő stb. Szeretném megemlíteni a leglassabb lekérdezéseket tartalmazó lapot is - ez nagyon kényelmes. Ezenkívül a PostgreSQL ezen a lapján lévő adatok egybeestek a kiterjesztés adataival pg_stat_statements - kiváló eredmény!

Tab Külső kérések teljesen megegyezik az adatbázisokkal.

Álláspontja

Mindkét bemutatott eszköz jól teljesített az APM szerepében. Bármelyikük felajánlhatja a szükséges minimumot. Benyomásaink röviden a következőkben foglalhatók össze:

adatkutya

Előnyök:

kényelmes díjszabás (az APM 31 USD-ba kerül hostonként);
jól működött Pythonnal;
Integrációs lehetőség az OpenTracing szolgáltatással
integráció a Kubernetes-szel;
integráció az NGINX Ingress-szel.

Hátrányok:

az egyetlen APM, amely miatt az alkalmazás modulhiba miatt elérhetetlenné vált (predis);
gyenge PHP automatikus műszerezés;
részben furcsa a szolgáltatások és céljuk meghatározása.

Atátusz