V prostredí SRE/DevOps inžinierov nikoho neprekvapí, že sa jedného dňa objaví klient (alebo monitorovací systém) a hlási, že „všetko je stratené“: stránka nefunguje, platby neprechádzajú, život chátra ... Bez ohľadu na to, ako veľmi by ste chceli v takejto situácii pomôcť, môže byť veľmi ťažké to urobiť bez jednoduchého a zrozumiteľného nástroja. Problém je často skrytý v samotnom kóde aplikácie, stačí ho lokalizovať.
A v smútku aj v radosti...
Stalo sa, že sme sa dlho a hlboko zamilovali do New Relic. Bol a zostáva vynikajúcim nástrojom na monitorovanie výkonu aplikácií a tiež vám umožňuje inštruovať architektúru mikroslužieb (pomocou jej agenta) a oveľa, oveľa viac. A všetko mohlo byť skvelé, keby nebolo zmien v cenovej politike služby: to stať narástol 3+ krát. Navyše od minulého roka si získanie skúšobného účtu vyžaduje komunikáciu s osobným manažérom, čo sťažuje prezentáciu produktu potenciálnemu zákazníkovi.
Zvyčajná situácia: New Relic nie je potrebný „natrvalo“, spomenú si naň až v momente, keď začnú problémy. Stále však musíte platiť pravidelne (140 USD za server mesačne) a v automaticky škálovateľnej cloudovej infraštruktúre sú sumy dosť vysoké. Hoci existuje možnosť Pay-As-You-Go, aktivácia New Relic bude vyžadovať reštart aplikácie, čo môže viesť k strate problémovej situácie, pre ktorú to bolo celé spustené. Nedávno spoločnosť New Relic predstavila nový tarifný plán - , - čo na prvý pohľad vyzerá ako rozumná alternatíva k Professional... no pri bližšom skúmaní sa ukázalo, že niektoré dôležité funkcie chýbajú (najmä nemá Kľúčové transakcie, Cross Application Tracing, Distribuované sledovanie).
V dôsledku toho sme začali uvažovať o hľadaní lacnejšej alternatívy a naša voľba padla na dve služby: Datadog a Atatus. Prečo na nich?
O konkurentoch
Hneď poviem, že na trhu sú aj iné riešenia. Zvažovali sme dokonca aj možnosti Open Source, no nie každý klient má voľnú kapacitu na hosťovanie riešení s vlastným hosťovaním... – navyše budú vyžadovať ďalšiu údržbu. Ukázalo sa, že dvojica, ktorú sme vybrali, bola najbližšia naše potreby:
- vstavaná a vyvinutá podpora pre PHP aplikácie (zásobník našich klientov je veľmi rôznorodý, ale toto je jasný líder v kontexte hľadania alternatívy k New Relic);
- prijateľné náklady (menej ako 100 USD mesačne na hostiteľa);
- automatické prístrojové vybavenie;
- integrácia s Kubernetes;
- Podobnosť s rozhraním New Relic je citeľným plusom (pretože naši inžinieri sú na to zvyknutí).
Preto sme v počiatočnej fáze výberu vylúčili niekoľko ďalších populárnych riešení, a to najmä:
- Tideways, AppDynamics a Dynatrace – za cenu;
- Stackify je v Ruskej federácii blokovaný a zobrazuje príliš málo údajov.
Zvyšok článku je štruktúrovaný tak, že najprv budú stručne predstavené príslušné riešenia, potom budem hovoriť o našej typickej interakcii s New Relic a skúsenostiach/dojmoch z vykonávania podobných operácií v iných službách.
Prezentácia vybraných súťažiacich
o , asi každý počul? Táto služba sa začala rozvíjať pred viac ako 10 rokmi, v roku 2008. Aktívne ho používame od roku 2012 a bez problémov sme integrovali naozaj veľké množstvo aplikácií v PHP, Ruby a Pythone a máme skúsenosti aj s integráciou s C# a Go. Autori služby majú riešenia na monitorovanie aplikácií, infraštruktúry, sledovanie infraštruktúr mikroslužieb, vytvorili pohodlné aplikácie pre používateľské zariadenia a mnoho ďalšieho.
Agent New Relic však beží na proprietárnych protokoloch a nepodporuje OpenTracing. Pokročilá inštrumentácia vyžaduje úpravy špeciálne pre New Relic. Napokon, podpora Kubernetes je stále experimentálna.
Jeho vývoj sa začal v roku 2010 vyzerá výrazne zaujímavejšie ako New Relic práve z hľadiska použitia v prostrediach Kubernetes. Podporuje najmä integráciu s NGINX Ingress, zhromažďovanie protokolov, protokoly statsd a OpenTracing, čo vám umožňuje sledovať požiadavku používateľa od momentu pripojenia až po dokončenie, ako aj nájsť protokoly pre túto požiadavku (obe na strane webového servera a na spotrebiteľovi).
Pri používaní Datadogu sme sa stretli s tým, že niekedy nesprávne zostavil mapu mikroslužieb a s niektorými technickými nedostatkami. Napríklad nesprávne identifikoval typ služby (pomýlil si Django so službou ukladania do vyrovnávacej pamäte) a spôsobil 500 chýb v aplikácii PHP využívajúcej populárnu knižnicu Predis.
— najmladší nástroj; služba bola spustená v roku 2014. Jeho marketingový rozpočet je jednoznačne nižší ako uvedený konkurenti, zmienky sú oveľa menej časté. Samotný nástroj je však veľmi podobný New Relic, a to nielen svojimi možnosťami (APM, Browser monitoring atď.), ale aj vzhľadom.
Významnou nevýhodou je, že podporuje iba Node.js a PHP. Na druhej strane je implementovaný výrazne lepšie ako Datadog. Na rozdiel od posledne menovaného Atatus nevyžaduje, aby aplikácie vykonávali úpravy alebo pridávali do kódu ďalšie štítky.
Ako pracujeme s New Relic
Teraz poďme zistiť, ako vo všeobecnosti používame New Relic. Povedzme, že máme problém, ktorý potrebuje riešenie:
Na grafe je to dobre vidieť kaluž - Poďme to analyzovať. V New Relic sú webové transakcie okamžite vybrané pre webovú aplikáciu, všetky komponenty sú uvedené v grafe výkonnosti, sú tam panely chybovosti, miery požiadaviek... Najdôležitejšie je, že priamo z týchto panelov sa môžete pohybovať medzi rôznymi časti aplikácie (napríklad kliknutím na MySQL sa dostanete do sekcie databázy).
Keďže v uvažovanom príklade vidíme prudký nárast aktivity PHPkliknite na tento graf a automaticky prejdite na Transakcie:
Zoznam transakcií, ktoré sú v podstate kontrolórmi z modelu MVC, je už zoradený podľa Najviac časovo náročné, čo je veľmi pohodlné: okamžite vidíme, čo aplikácia robí. Tu sú príklady dlhých dopytov, ktoré New Relic automaticky zhromažďuje. Prepnutím triedenia je ľahké nájsť:
- najviac zaťažený aplikačný ovládač;
- najčastejšie žiadaný ovládač;
- najpomalší z ovládačov.
Okrem toho môžete rozbaliť každú transakciu a zistiť, čo aplikácia robila v čase spustenia kódu:
Nakoniec aplikácia ukladá príklady stôp dlhých požiadaviek (tých, ktoré trvajú viac ako 2 sekundy). Tu je panel pre dlhú transakciu:
Je vidieť, že dve metódy zaberú veľa času a zároveň sa zobrazuje aj čas, kedy bola požiadavka vykonaná, jej URI a doména. Veľmi často to pomáha nájsť požiadavku v protokoloch. Chystáte sa Podrobnosti sledovania, môžete vidieť, odkiaľ sa tieto metódy volajú:
A v Databázové dotazy — vyhodnotiť dotazy do databáz, ktoré boli spustené počas behu aplikácie:
Vyzbrojení týmito znalosťami môžeme vyhodnotiť, prečo sa aplikácia spomaľuje, a spolupracovať s vývojárom na stratégii riešenia problému. V skutočnosti New Relic nie vždy poskytuje jasný obraz, ale pomáha pri výbere vektora vyšetrovania:
- dlho
PDO::Constructnás priviedol k zvláštnemu fungovaniu pgpoll; - nestabilita v priebehu času
Memcache::Getnavrhol, že virtuálny počítač bol nakonfigurovaný nesprávne; - podozrivo zvýšený čas na spracovanie šablóny viedol k vnorenej slučke kontrolujúcej prítomnosť 500 avatarov v úložisku objektov;
- atď…
Stáva sa tiež, že namiesto spustenia kódu na hlavnej obrazovke rastie niečo súvisiace s externým ukladaním údajov - a nezáleží na tom, čo to bude: Redis alebo PostgreSQL - všetky sú skryté na karte Databáza.
Môžete si vybrať konkrétnu bázu pre prieskum a triediť dopyty – podobne ako v Transakciách. A keď prejdete na kartu žiadosti, môžete vidieť, koľkokrát sa táto požiadavka vyskytuje v každom z ovládačov aplikácie, a tiež odhadnúť, ako často je volaná. Je to veľmi pohodlné:
Karta obsahuje podobné údaje Externé služby, ktorý skrýva požiadavky na externé HTTP služby, ako je prístup k úložisku objektov, odosielanie udalostí na strážcu a podobne. Obsah záložky je úplne podobný Databázam:
Konkurenti: príležitosti a dojmy
Teraz je najzaujímavejšie porovnať možnosti New Relic s tým, čo ponúkajú konkurenti. Bohužiaľ sa nám nepodarilo otestovať všetky tri nástroje na jednej verzii jednej aplikácie spustenej v produkcii. Snažili sme sa však porovnať situácie/konfigurácie, ktoré boli čo najviac identické.
1.Dátový pes
Datadog nás víta panelom so stenou služieb:
Snaží sa rozdeliť aplikácie na komponenty/mikroslužby, takže v príklade aplikácie Django uvidíme 2 pripojenia k PostgreSQL (defaultdb и postgres), ako aj Zeler, Redis. Práca s Datadogom vyžaduje, aby ste mali minimálne znalosti o princípoch MVC: musíte pochopiť, odkiaľ vo všeobecnosti prichádzajú požiadavky používateľov. To zvyčajne pomáha mapa služieb:
Mimochodom, niečo podobné je aj v New Relic:
... a ich mapa je podľa mňa jednoduchšia a prehľadnejšia: nezobrazuje komponenty jednej aplikácie (čím by bola príliš podrobná, ako v prípade Datadogu), ale len konkrétne služby či mikroslužby.
Vráťme sa k Datadogu: z mapy služieb vidíme, že požiadavky používateľov prichádzajú do Djanga. Poďme na službu Django a konečne uvidíme, čo sme očakávali:
Žiaľ, predvolene tu nie je žiadny graf Čas webovej transakcie, podobne ako to vidíme na hlavnom paneli New Relic. Môže sa však nakonfigurovať namiesto plánu % stráveného času. Stačí ho prepnúť na Priemerný čas na žiadosť podľa typu... a teraz sa na nás pozerá známy graf!
Prečo si Datadog vybral iný graf, je pre nás záhadou. Ďalšou frustrujúcou vecou je, že systém si nepamätá výber používateľa (na rozdiel od oboch konkurentov), a preto je jediným riešením vytváranie vlastných panelov.
Potešila ma však možnosť v Datadogu prepínať z týchto grafov na metriky príbuzných serverov, čítať logy a vyhodnocovať záťaž na obsluhu webservera (Gunicorn). Všetko je takmer rovnaké ako v New Relic... a ešte o niečo viac (polená)!
Pod grafmi sú transakcie úplne podobné New Relic:
V Datadog sú transakcie tzv zdrojov. Ovládače môžete zoradiť podľa počtu požiadaviek, priemerného času odozvy a maximálneho času stráveného počas zvoleného časového obdobia.
Môžete rozšíriť zdroj a vidieť všetko, čo sme už pozorovali v New Relic:
K dispozícii sú štatistiky o zdroji, zovšeobecnený zoznam interných hovorov a príklady požiadaviek, ktoré možno triediť podľa kódu odpovede... Mimochodom, toto triedenie sa našim inžinierom veľmi páčilo.
Akýkoľvek príklad zdroja v Datadog je možné otvoriť a preštudovať:
Zobrazia sa parametre požiadavky, súhrnná tabuľka času stráveného na každom komponente a vodopádový graf zobrazujúci postupnosť volaní. Môžete tiež prepnúť na stromové zobrazenie grafu vodopádu:
A najzaujímavejšie je zobrazenie zaťaženia hostiteľa, na ktorom bola požiadavka vykonaná, a zobrazenie denníkov požiadaviek.
Skvelá integrácia!
Možno sa čudujete, kde sú záložky Databáza и Externé služby, ako v New Relic. Žiadne tu nie sú: keďže Datadog rozkladá aplikáciu na komponenty, bude sa brať do úvahy PostgreSQL samostatná službaa namiesto Externých služieb sa oplatí hľadať aws.storage (podobné to bude pri každej ďalšej externej službe, ku ktorej má aplikácia prístup).
Tu je príklad s postgres:
V podstate je tam všetko, čo sme chceli:
Môžete vidieť, z ktorej „služby“ žiadosť pochádza.
Nebolo by na škodu vám pripomenúť, že Datadog sa dokonale integruje s NGINX Ingress a umožňuje vám vykonávať úplné sledovanie od okamihu, keď do klastra dorazí požiadavka, a tiež vám umožňuje prijímať metriky statsd, zhromažďovať protokoly a metriky hostiteľa. .
Obrovským plusom Datadogu je jeho cena rozvíja z monitoringu infraštruktúry, APM, Log Management a Synthetics test, t.j. Svoj plán si môžete vybrať flexibilne.
2.Atatus
Tím Atatus tvrdí, že ich služba je „rovnaká ako New Relic, ale lepšia“. Pozrime sa, či je to naozaj tak.
Hlavný panel vyzerá podobne, ale nebolo možné určiť Redis a memcached použité v aplikácii.
APM štandardne vyberá všetky transakcie, hoci zvyčajne sú potrebné iba webové transakcie. Rovnako ako Datadog, neexistuje spôsob, ako prejsť na požadovanú službu z hlavného panela. Okrem toho sú transakcie uvedené po chybách, čo sa pre APM nezdá príliš logické.
V transakciách Atatus je všetko čo najviac podobné New Relic. Nevýhodou je, že dynamika pre každý ovládač nie je okamžite viditeľná. Musíte ho hľadať v tabuľke ovládačov zoradených podľa Najviac spotrebovaného času:
Zvyčajný zoznam ovládačov je dostupný na karte preskúmať:
V niektorých ohľadoch tento stôl pripomína Datadog a páči sa mi viac ako podobný v New Relic.
Každú transakciu môžete rozbaliť a zistiť, čo aplikácia robila:
Panel tiež viac pripomína Datadog: existuje množstvo požiadaviek, všeobecný obraz hovorov. Horný panel obsahuje kartu s chybou Zlyhania HTTP a príklady pomalých dopytov Stopy relácie:
Ak prejdete na transakciu, môžete vidieť príklad sledovania, môžete získať zoznam požiadaviek do databázy a pozrieť sa na hlavičky požiadaviek. Všetko je podobné New Relic:
Vo všeobecnosti Atatus potešil podrobnými stopami - bez typického lepenia hovorov New Relic do bloku pripomienky:
Chýba mu však filter, ktorý by (ako New Relic) odrezal ultrarýchle požiadavky (<5 ms). Na druhej strane sa mi páčilo zobrazenie konečnej odozvy transakcie (úspech alebo chyba).
panel Databáza vám pomôže študovať požiadavky na externé databázy, ktoré aplikácia robí. Pripomeniem, že Atatus našiel iba PostgreSQL a MySQL, hoci do projektu sú zapojené aj Redis a memcached.
Žiadosti sa triedia podľa zvyčajných kritérií: frekvencia odozvy, priemerný čas odozvy atď. Chcel by som tiež spomenúť kartu s najpomalšími dopytmi - je to veľmi pohodlné. Okrem toho sa údaje na tejto karte pre PostgreSQL zhodovali s údajmi z rozšírenia - výborný výsledok!
vložiť Externé požiadavky úplne identické s databázami.
Závery
Oba prezentované nástroje fungovali v úlohe APM dobre. Ktorýkoľvek z nich môže ponúknuť požadované minimum. Naše dojmy možno stručne zhrnúť takto:
datadog
Pros:
- pohodlný tarifný plán (APM stojí 31 USD na hostiteľa);
- dobre fungoval s Pythonom;
- Možnosť integrácie s OpenTracingom
- integrácia s Kubernetes;
- integrácia s NGINX Ingress.
Nevýhody:
- jediný APM, ktorý spôsobil, že sa aplikácia stala nedostupnou v dôsledku chyby modulu (predis);
- slabá PHP autoinštrumentácia;
- čiastočne zvláštna definícia služieb a ich účel.
Atatus
Pros:
- hlboké nástroje PHP;
- používateľské rozhranie podobné New Relic.
Nevýhody:
- nefunguje na starších operačných systémoch (Ubuntu 12.05, CentOS 5);
- slabá autoinštrumentácia;
- podpora iba dvoch jazykov (Node.js a PHP);
- Pomalé rozhranie.
Vzhľadom na cenu spoločnosti Atatus 69 USD mesačne za server by sme radšej použili Datadog, ktorý sa dobre integruje s našimi potrebami (webové aplikácie v K8s) a má veľa užitočných funkcií.
PS
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «".
Zdroj: hab.com