V prostředí inženýrů SRE/DevOps nikoho nepřekvapí, že se jednoho dne objeví klient (nebo monitorovací systém) a hlásí, že „vše je ztraceno“: web nefunguje, platby neprocházejí, život chátrá ... Bez ohledu na to, jak moc byste chtěli v takové situaci pomoci, může být velmi obtížné to udělat bez jednoduchého a srozumitelného nástroje. Problém je často skryt v samotném kódu aplikace, stačí jej lokalizovat.
A ve smutku i v radosti…
Stalo se, že jsme se dlouho a hluboce zamilovali do New Relic. Byl a zůstává vynikajícím nástrojem pro monitorování výkonu aplikací a také vám umožňuje instrumentovat architekturu mikroslužeb (pomocí jejího agenta) a mnohem, mnohem více. A všechno mohlo být skvělé, kdyby nedošlo ke změnám v cenové politice služby: to náklady vzrostl 3+krát. Od minulého roku navíc získání zkušebního účtu vyžaduje komunikaci s osobním manažerem, což ztěžuje prezentaci produktu potenciálnímu zákazníkovi.
Obvyklá situace: New Relic není potřeba „natrvalo“, vzpomene si na něj až ve chvíli, kdy začnou problémy. Stále však musíte pravidelně platit (140 USD za server měsíčně) a v automaticky škálovatelné cloudové infrastruktuře jsou sumy poměrně vysoké. Přestože existuje možnost Pay-As-You-Go, povolení New Relic bude vyžadovat restart aplikace, což může vést ke ztrátě problematické situace, kvůli které to bylo celé spuštěno. Nedávno společnost New Relic představila nový tarif - , - což na první pohled vypadá jako rozumná alternativa Professional... ale při bližším zkoumání se ukázalo, že některé důležité funkce chybí (zejména nemá Klíčové transakce, Cross Application Tracing, Distribuované sledování).
V důsledku toho jsme začali přemýšlet o hledání levnější alternativy a naše volba padla na dvě služby: Datadog a Atatus. Proč na ně?
O konkurenci
Hned říkám, že na trhu jsou i jiná řešení. Zvažovali jsme dokonce možnosti Open Source, ale ne každý klient má volnou kapacitu pro hostování self-hostovaných řešení... – navíc budou vyžadovat další údržbu. Pár, který jsme vybrali, se ukázal být nejbližší naše potřeby:
- vestavěná a vyvinutá podpora pro aplikace PHP (zásobník našich klientů je velmi rozmanitý, ale v kontextu hledání alternativy k New Relic je to jasná jednička);
- přijatelné náklady (méně než 100 USD měsíčně na hostitele);
- automatické přístrojové vybavení;
- integrace s Kubernetes;
- Podobnost s rozhraním New Relic je znatelným plusem (protože naši inženýři jsou na to zvyklí).
Proto jsme v počáteční fázi výběru eliminovali několik dalších populárních řešení, a to zejména:
- Tideways, AppDynamics a Dynatrace – za cenu;
- Stackify je v Ruské federaci blokováno a zobrazuje příliš málo dat.
Zbytek článku je strukturován tak, že dotyčná řešení budou nejprve stručně představena, poté budu hovořit o naší typické interakci s New Relic a zkušenostech/dojmech z provádění podobných operací v jiných službách.
Prezentace vybraných soutěžících
O , asi každý slyšel? Tato služba začala svůj vývoj před více než 10 lety, v roce 2008. Aktivně jej používáme od roku 2012 a bez problémů jsme integrovali opravdu velké množství aplikací v PHP, Ruby a Pythonu a máme zkušenosti i s integrací s C# a Go. Autoři služby mají řešení pro monitorování aplikací, infrastruktury, trasování infrastruktur mikroslužeb, vytvořili pohodlné aplikace pro uživatelská zařízení a mnoho dalšího.
Agent New Relic však běží na proprietárních protokolech a nepodporuje OpenTracing. Pokročilá instrumentace vyžaduje úpravy speciálně pro New Relic. A konečně, podpora Kubernetes je stále experimentální.
Jeho vývoj byl zahájen v roce 2010 vypadá znatelně zajímavěji než New Relic právě z hlediska použití v prostředích Kubernetes. Podporuje zejména integraci s NGINX Ingress, shromažďování protokolů, statsd a protokoly OpenTracing, což vám umožňuje sledovat požadavek uživatele od okamžiku jeho připojení až po dokončení a také najít protokoly pro tento požadavek (obojí na straně webového serveru a na spotřebitele).
Při používání Datadogu jsme se setkali s tím, že občas špatně postavil mapu mikroslužeb a s některými technickými nedostatky. Špatně například identifikoval typ služby (zaměnil Django za službu ukládání do mezipaměti) a způsobil 500 chyb v aplikaci PHP využívající populární knihovnu Predis.
— nejmladší nástroj; služba byla spuštěna v roce 2014. Jeho marketingový rozpočet je jasně nižší než u uvedených konkurentů, zmínky jsou mnohem méně časté. Samotný nástroj je však New Relic velmi podobný, a to nejen svými možnostmi (APM, Browser monitoring atd.), ale také vzhledem.
Významnou nevýhodou je, že podporuje pouze Node.js a PHP. Na druhou stranu je implementován znatelně lépe než Datadog. Na rozdíl od posledně jmenovaného Atatus nevyžaduje, aby aplikace prováděly úpravy nebo přidávaly do kódu další štítky.
Jak pracujeme s New Relic
Nyní pojďme zjistit, jak obecně používáme New Relic. Řekněme, že máme problém, který potřebuje řešení:
Na grafu je to dobře vidět špice - Pojďme to analyzovat. V New Relic jsou webové transakce okamžitě vybrány pro webovou aplikaci, všechny komponenty jsou uvedeny v grafu výkonu, jsou zde panely error-rate, request-rate... Co je nejdůležitější, přímo z těchto panelů se můžete pohybovat mezi různými části aplikace (například kliknutím na MySQL se dostanete do sekce databáze).
Protože v uvažovaném příkladu vidíme nárůst aktivity PHP, klikněte na tento graf a automaticky přejděte na Transakce:
Seznam transakcí, které jsou v podstatě kontroléry z modelu MVC, je již řazen podle Nejvíce časově náročné, což je velmi pohodlné: okamžitě vidíme, co aplikace dělá. Zde jsou příklady dlouhých dotazů, které New Relic automaticky shromažďuje. Přepnutím řazení je snadné najít:
- nejzatíženější aplikační řadič;
- nejčastěji žádaný ovladač;
- nejpomalejší z ovladačů.
Kromě toho můžete každou transakci rozbalit a zjistit, co aplikace dělala v době, kdy byl kód spuštěn:
Nakonec aplikace ukládá příklady tras dlouhých požadavků (ty, které trvají déle než 2 sekundy). Zde je panel pro dlouhou transakci:
Je vidět, že dvě metody zaberou spoustu času a zároveň se zobrazuje i čas, kdy byl požadavek vykonán, jeho URI a doména. Velmi často to pomůže najít požadavek v protokolech. Chystat se Podrobnosti stopy, můžete vidět, odkud jsou tyto metody volány:
A v Databázové dotazy — vyhodnoťte dotazy do databází, které byly provedeny za běhu aplikace:
Vyzbrojeni těmito znalostmi můžeme vyhodnotit, proč se aplikace zpomaluje, a ve spolupráci s vývojářem vymyslet strategii, jak problém vyřešit. Ve skutečnosti New Relic ne vždy poskytuje jasný obrázek, ale pomáhá zvolit vektor vyšetřování:
- dlouho
PDO::Constructpřivedl nás k podivnému fungování pgpoll; - nestabilita v čase
Memcache::Getnavrhl, že virtuální počítač byl nakonfigurován nesprávně; - podezřele prodloužený čas na zpracování šablony vedl k vnořené smyčce kontrolující přítomnost 500 avatarů v úložišti objektů;
- atd…
Stává se také, že místo spouštění kódu na hlavní obrazovce roste něco souvisejícího s externím úložištěm dat - a nezáleží na tom, co to bude: Redis nebo PostgreSQL - všechny jsou skryté na kartě Databáze.
Můžete si vybrat konkrétní základ pro průzkum a seřadit dotazy – podobně jako v Transakcích. A když přejdete na kartu požadavku, můžete vidět, kolikrát se tento požadavek vyskytuje v každém z řadičů aplikace, a také odhadnout, jak často je volán. Je to velmi pohodlné:
Karta obsahuje podobné údaje Externí služby, který skrývá požadavky na externí HTTP služby, jako je přístup k úložišti objektů, odesílání událostí na hlídku a podobně. Záložka je obsahově zcela podobná jako Databáze:
Konkurenti: příležitosti a dojmy
Nyní je nejzajímavější porovnat možnosti New Relic s tím, co nabízí konkurence. Bohužel se nám nepodařilo otestovat všechny tři nástroje na jedné verzi jedné aplikace běžící v produkci. Snažili jsme se však porovnat situace/konfigurace, které byly pokud možno totožné.
1.Datový pes
Datadog nás vítá panelem se stěnou služeb:
Snaží se rozdělit aplikace na komponenty/mikroslužby, takže v ukázkové aplikaci Django uvidíme 2 připojení k PostgreSQL (defaultdb и postgres), stejně jako Celer, Redis. Práce s Datadogem vyžaduje minimální znalosti principů MVC: musíte pochopit, odkud obecně pocházejí požadavky uživatelů. To obvykle pomáhá mapa služeb:
Mimochodem, něco podobného je v New Relic:
... a jejich mapa je dle mého názoru jednodušší a přehlednější: nezobrazuje součásti jedné aplikace (čímž by byla přehnaně detailní, jako v případě Datadogu), ale pouze konkrétní služby či mikroslužby.
Vraťme se k Datadogu: z mapy služeb vidíme, že požadavky uživatelů přicházejí na Django. Pojďme na službu Django a konečně uvidíme, co jsme očekávali:
Bohužel zde ve výchozím nastavení není žádný graf Čas webové transakce, podobný tomu, který vidíme na hlavním panelu New Relic. Lze jej však nakonfigurovat místo plánu % stráveného času. Stačí jej přepnout na Průměrný čas na požadavek podle typu... a teď se na nás dívá známý graf!
Proč si Datadog vybral jiný graf, je pro nás záhadou. Další frustrující věcí je, že si systém nepamatuje volbu uživatele (na rozdíl od obou konkurentů), a proto je jediným řešením vytvářet vlastní panely.
Potěšila mě ale možnost v Datadogu přepínat z těchto grafů na metriky souvisejících serverů, číst logy a vyhodnocovat vytížení obsluh webserverů (Gunicorn). Všechno je skoro stejné jako v New Relic... a ještě o něco víc (klády)!
Pod grafy jsou transakce zcela podobné New Relic:
V Datadog se transakce nazývají zdroje. Řadiče můžete seřadit podle počtu požadavků, průměrné doby odezvy a podle maximální doby strávené po zvolené časové období.
Můžete rozšířit zdroj a vidět vše, co jsme již pozorovali v New Relic:
K dispozici jsou statistiky o zdroji, zobecněný seznam interních volání a příklady požadavků, které lze třídit podle kódu odpovědi... Mimochodem, toto třídění se našim inženýrům velmi líbilo.
Jakýkoli příklad zdroje v Datadog lze otevřít a studovat:
Jsou uvedeny parametry požadavku, souhrnný graf času stráveného na každé komponentě a vodopádový graf ukazující sekvenci volání. Můžete také přepnout na stromové zobrazení vodopádového grafu:
A nejzajímavější je zobrazení zátěže hostitele, na kterém byl požadavek proveden, a zobrazení protokolů požadavků.
Skvělá integrace!
Možná se divíte, kde jsou záložky Databáze и Externí služby, jako v New Relic. Žádné zde nejsou: protože Datadog rozkládá aplikaci na komponenty, bude zvažován PostgreSQL samostatnou službua místo Externích služeb se vyplatí hledat aws.storage (podobně to bude u každé další externí služby, ke které má aplikace přístup).
Zde je příklad s postgres:
V podstatě je tam vše, co jsme chtěli:
Můžete vidět, ze které „služby“ požadavek přišel.
Nebylo by špatné vám připomenout, že Datadog se dokonale integruje s NGINX Ingress a umožňuje vám provádět úplné sledování od okamžiku, kdy do clusteru dorazí požadavek, a také vám umožňuje přijímat metriky statsd, shromažďovat protokoly a metriky hostitele. .
Obrovským plusem Datadogu je jeho cena se formuje z monitorování infrastruktury, APM, Log Management a Synthetics test, tzn. Svůj plán si můžete vybrat flexibilně.
2.Atatus
Tým Atatus tvrdí, že jejich služba je „stejná jako New Relic, ale lepší“. Podívejme se, jestli je to opravdu tak.
Hlavní panel vypadá podobně, ale nebylo možné určit použitý Redis a memcached v aplikaci.
APM ve výchozím nastavení vybírá všechny transakce, i když jsou obvykle potřeba pouze webové transakce. Stejně jako Datadog neexistuje způsob, jak přejít na požadovanou službu z hlavního panelu. Navíc jsou transakce uvedeny po chybách, což se pro APM nezdá příliš logické.
V transakcích Atatus je vše co nejvíce podobné New Relic. Nevýhodou je, že dynamika pro každý ovladač není hned vidět. Musíte to hledat v tabulce ovladačů seřazených podle Nejvíce času spotřebováno:
Obvyklý seznam ovladačů je k dispozici v záložce Prozkoumat:
V některých ohledech tento stůl připomíná Datadog a líbí se mi lépe než podobný v New Relic.
Každou transakci můžete rozbalit a zjistit, co aplikace dělala:
Panel také více připomíná Datadog: je zde řada požadavků, obecný obrázek hovorů. Horní panel obsahuje chybovou kartu Selhání HTTP a příklady pomalých dotazů Trasování relace:
Pokud přejdete na transakci, můžete vidět příklad trasování, můžete získat seznam požadavků do databáze a podívat se na hlavičky požadavků. Všechno je podobné New Relic:
Obecně Atatus potěšil detailními stopami - bez typického slepování hovorů New Relic do bloku upomínek:
Postrádá však filtr, který by (jako New Relic) odřízl ultra rychlé požadavky (<5 ms). Na druhou stranu se mi líbilo zobrazení konečné reakce transakce (úspěch nebo chyba).
Панель Databáze vám pomůže studovat požadavky na externí databáze, které aplikace dělá. Dovolte mi připomenout, že Atatus našel pouze PostgreSQL a MySQL, i když Redis a memcached jsou také zapojeny do projektu.
Požadavky jsou seřazeny podle obvyklých kritérií: frekvence odezvy, průměrná doba odezvy atd. Rád bych také zmínil kartu s nejpomalejšími dotazy - je to velmi pohodlné. Navíc data v této záložce pro PostgreSQL se shodovala s daty z rozšíření - skvělý výsledek!
Tab Externí požadavky zcela identické s databázemi.
Závěry
Oba prezentované nástroje si v roli APM vedly dobře. Kterýkoli z nich může nabídnout požadované minimum. Naše dojmy lze stručně shrnout takto:
datadog
výhody:
- pohodlný tarifní plán (APM stojí 31 USD na hostitele);
- pracoval dobře s Pythonem;
- Možnost integrace s OpenTracingem
- integrace s Kubernetes;
- integrace s NGINX Ingress.
nevýhody:
- jediný APM, který způsobil, že se aplikace stala nedostupnou kvůli chybě modulu (predis);
- slabá autoinstrumentace PHP;
- částečně podivná definice služeb a jejich účel.
Atatus
výhody:
- hluboké PHP instrumentace;
- uživatelské rozhraní podobné New Relic.
nevýhody:
- nefunguje na starších operačních systémech (Ubuntu 12.05, CentOS 5);
- slabá autoinstrumentace;
- podpora pouze dvou jazyků (Node.js a PHP);
- Pomalé rozhraní.
Vzhledem k ceně Atatuse 69 USD měsíčně za server bychom raději použili Datadog, který se dobře integruje s našimi potřebami (webové aplikace v K8s) a má mnoho užitečných funkcí.
PS
Přečtěte si také na našem blogu:
- «";
- «";
- «".
Zdroj: www.habr.com