🥇Ekki New Relic einn: Sjá Datadog og Atatus

Í umhverfi SRE/DevOps verkfræðinga mun það ekki koma neinum á óvart að einn daginn birtist viðskiptavinur (eða eftirlitskerfi) og tilkynnir að „allt sé glatað“: síðan virkar ekki, greiðslur ganga ekki í gegn, lífið er að grotna niður ... Sama hversu mikið þú vilt hjálpa í slíkum aðstæðum, það getur verið mjög erfitt að gera þetta án einfalt og skiljanlegt tæki. Oft er vandamálið falið í forritskóðanum sjálfum; þú þarft bara að staðfæra hann.

Og í sorg og gleði...

Það gerðist svo að við höfum lengi og innilega orðið ástfangin af New Relic. Það var og er enn frábært tæki til að fylgjast með frammistöðu forrita og gerir þér einnig kleift að mæla örþjónustuarkitektúrinn (með umboðsmanni þess) og margt, margt fleira. Og allt hefði getað verið frábært ef ekki væri fyrir breytingar á verðstefnu þjónustunnar: það kostnaður frá 2013 ári stækkaði 3+ sinnum. Að auki, síðan á síðasta ári, þarf að fá prufureikning samskipti við persónulegan stjórnanda, sem gerir það erfitt að kynna vöruna fyrir hugsanlegum viðskiptavinum.

Venjulegt ástand: Ekki er þörf á nýjum fornleifum á „varanlegan hátt“; þeir muna það aðeins á því augnabliki þegar vandamál byrja. En þú þarft samt að borga reglulega (140 USD á miðlara á mánuði) og í skýjainnviði sem stækkar sjálfkrafa eru upphæðirnar frekar háar. Þrátt fyrir að það sé til staðar valmöguleiki fyrir borga eins og þú ferð, mun það að kveikja á New Relic krefjast þess að þú endurræsir forritið, sem gæti leitt til þess að þú missir vandræðaástandið sem það var byrjað fyrir. Ekki alls fyrir löngu kynnti New Relic nýja gjaldskrá - Essentials, - sem við fyrstu sýn lítur út fyrir að vera sanngjarn valkostur við Professional... en við nánari athugun kom í ljós að það vantar nokkrar mikilvægar aðgerðir (sérstaklega hefur það ekki Lykilviðskipti, Cross Application Tracing, Dreifð rakning).

Í kjölfarið fórum við að huga að ódýrari valkosti og val okkar féll á tvær þjónustur: Datadog og Atatus. Hvers vegna á þeim?

Um keppinauta

Ég segi strax að það eru aðrar lausnir á markaðnum. Við skoðuðum meira að segja valkostina fyrir opinn uppspretta, en ekki allir viðskiptavinir hafa lausa getu til að hýsa lausnir sem hýsa sjálfar... - auk þess munu þær þurfa viðbótarviðhald. Þau hjónin sem við völdum reyndust standa næst þörfum okkar:

innbyggður og þróaður stuðningur fyrir PHP forrit (stafla viðskiptavina okkar er mjög fjölbreytt, en þetta er augljós leiðtogi í samhengi við að leita að valkosti við New Relic);
hagkvæmur kostnaður (minna en 100 USD á mánuði á gestgjafa);
sjálfvirk tækjabúnaður;
samþætting við Kubernetes;
Líkindin við New Relic viðmótið er áberandi plús (vegna þess að verkfræðingar okkar eru vanir því).

Þess vegna, á fyrsta valstigi, útrýmdum við nokkrum öðrum vinsælum lausnum, og sérstaklega:

Tideways, AppDynamics og Dynatrace - fyrir kostnað;
Stackify er lokað í Rússlandi og sýnir of lítil gögn.

Afgangurinn af greininni er þannig uppbyggður að fyrst verða umræddar lausnir kynntar í stuttu máli, að því loknu mun ég tala um dæmigerð samskipti okkar við New Relic og reynslu/hrifningu af því að framkvæma svipaðar aðgerðir í annarri þjónustu.

Kynning á völdum keppendum

á Ný relik, líklega hafa allir heyrt? Þessi þjónusta hóf þróun sína fyrir meira en 10 árum síðan, árið 2008. Við höfum verið virkir að nota það síðan 2012 og höfum ekki átt í neinum vandræðum með að samþætta mjög mikinn fjölda forrita í PHP, Ruby og Python, og við höfum líka reynslu af samþættingu við C# og Go. Höfundar þjónustunnar eru með lausnir til að fylgjast með forritum, innviðum, rekja örþjónustuinnviði, búa til þægileg forrit fyrir notendatæki og margt fleira.

Hins vegar keyrir New Relic umboðsmaðurinn á sérsamskiptareglum og styður ekki OpenTracing. Háþróuð tækjabúnaður krefst breytinga sérstaklega fyrir New Relic. Að lokum, Kubernetes stuðningur er enn tilraunastarfsemi.

Hóf þróun þess árið 2010 Gagnahundur lítur áberandi áhugaverðari út en New Relic einmitt hvað varðar notkun í Kubernetes umhverfi. Sérstaklega styður það samþættingu við NGINX Ingress, annálasöfnun, statsd og OpenTracing samskiptareglur, sem gerir þér kleift að fylgjast með notendabeiðni frá því augnabliki sem hún er tengd við lokun, auk þess að finna annála fyrir þessa beiðni (bæði á vefþjóninum megin og hjá neytanda).

Þegar við notuðum Datadog komumst við að því að það byggði stundum örþjónustukortið rangt og nokkra tæknilega annmarka. Til dæmis ranggreindi það þjónustutegundina (að Django var misskilið fyrir skyndiminniþjónustu) og olli 500 villum í PHP forriti sem notaði hið vinsæla Predis bókasafn.

Atatus — yngsta hljóðfærið; þjónustan var opnuð árið 2014. Markaðsfjárhagsáætlun þess er greinilega lakari en skráðir keppinautar, umtal er mun sjaldgæfara. Hins vegar er tólið sjálft mjög líkt New Relic, ekki aðeins í getu þess (APM, vafravöktun o.s.frv.), heldur einnig í útliti.

Verulegur galli er að það styður aðeins Node.js og PHP. Aftur á móti er það útfært áberandi betur en Datadog. Ólíkt því síðarnefnda þarf Atatus ekki forrit til að gera breytingar eða bæta viðbótarmerkjum við kóðann.

Hvernig við vinnum með New Relic

Nú skulum við reikna út hvernig við notum almennt New Relic. Segjum að við séum með vandamál sem þarfnast lausnar:

Það er auðvelt að sjá það á línuritinu bylgja - Við skulum greina það. Í New Relic eru veffærslur samstundis valin fyrir vefforrit, allir íhlutir eru sýndir á frammistöðugrafinu, það eru villuhlutfall, beiðni-hlutfall spjald... Það sem skiptir mestu máli er að beint frá þessum spjöldum er hægt að fara á milli mismunandi hluta forritsins (td að smella á MySQL mun leiða til gagnagrunnshlutann).

Þar sem í dæminu sem hér er til skoðunar sjáum við aukningu í virkni PHP, smelltu á þetta graf og farðu sjálfkrafa í Viðskipti:

Listinn yfir viðskipti, sem eru í meginatriðum stýringar úr MVC líkaninu, er þegar flokkaður eftir Mest tímafrekt, sem er mjög þægilegt: við sjáum strax hvað forritið gerir. Hér eru dæmi um langar fyrirspurnir sem er sjálfkrafa safnað af New Relic. Með því að skipta um flokkun er auðvelt að finna:

forritastýringin sem er mest hlaðin;
stjórnandi sem oftast er beðið um;
hægasti stjórnandinn.

Að auki geturðu stækkað hverja færslu og séð hvað forritið var að gera á þeim tíma sem kóðinn var keyrður:

Að lokum geymir forritið dæmi um ummerki um langar beiðnir (þær sem taka meira en 2 sekúndur). Hér er spjaldið fyrir langa viðskipti:

Það má sjá að tvær aðferðir taka mikinn tíma og á sama tíma er tíminn þegar beiðnin var framkvæmd, URI hennar og lén sýnd. Mjög oft hjálpar þetta að finna beiðnina í annálunum. Fara að Rekja upplýsingar, þú getur séð hvaðan þessar aðferðir eru kallaðar:

Og í Gagnagrunnsfyrirspurnir - meta fyrirspurnir í gagnagrunna sem voru keyrðar á meðan forritið var í gangi:

Vopnuð þessari þekkingu getum við metið hvers vegna forritið hægir á sér og unnið með þróunaraðilanum að því að koma með stefnu til að leysa vandamálið. Í raun og veru gefur New Relic ekki alltaf skýra mynd, en það hjálpar til við að velja vektor rannsóknar:

Langt PDO::Construct leiddi okkur til undarlegrar virkni pgpoll;
óstöðugleiki yfir tíma Memcache::Get lagði til að sýndarvélin væri rangt stillt;
grunsamlega aukinn tími fyrir sniðmátsvinnslu leiddi til þess að hreiður lykkja athugaði tilvist 500 avatars í geymslunni fyrir hluti;
og svo framvegis…

Það gerist líka að í stað þess að keyra kóða, vex eitthvað tengt ytri gagnageymslu á aðalskjánum - og það skiptir ekki máli hvað það verður: Redis eða PostgreSQL - þau eru öll falin í flipanum Gagnagrunnar.

Þú getur valið sérstakan grunn fyrir rannsóknir og flokkað fyrirspurnir - svipað og það er gert í Viðskiptum. Og með því að fara á beiðni flipann geturðu séð hversu oft þessi beiðni kemur fram í hverjum forritastýringum og einnig metið hversu oft hún er kölluð. Það er mjög þægilegt:

Flipinn inniheldur svipuð gögn Ytri þjónustu, sem felur beiðnir til utanaðkomandi HTTP-þjónustu, svo sem aðgang að hlutageymslu, sendingu atburða til varðstöðvar eða þess háttar. Innihald flipans er algjörlega svipað og gagnasöfn:

Keppendur: tækifæri og áhrif

Nú er það áhugaverðasta að bera saman getu New Relic við það sem samkeppnisaðilar bjóða upp á. Því miður gátum við ekki prófað öll þrjú verkfærin á einni útgáfu af einu forriti sem keyrir í framleiðslu. Hins vegar reyndum við að bera saman aðstæður/stillingar sem voru eins eins og hægt var.

1. Gagnahundur

Datadog tekur á móti okkur með spjaldi með vegg af þjónustu:

Það reynir að brjóta forrit í íhluti/örþjónustur, þannig að í dæminu Django forritinu munum við sjá 2 tengingar við PostgreSQL (defaultdb и postgres), auk sellerí, Redis. Að vinna með Datadog krefst þess að þú hafir lágmarksþekkingu á MVC meginreglum: þú þarft að skilja hvaðan notendabeiðnir koma almennt. Þetta hjálpar yfirleitt þjónustukort:

Við the vegur, það er eitthvað svipað í New Relic:

... og kortið þeirra, að mínu mati, er gert einfaldara og skýrara: það sýnir ekki íhluti eins forrits (sem myndi gera það of ítarlegt, eins og í tilfelli Datadog), heldur aðeins sérstakar þjónustur eða örþjónustur.

Snúum okkur aftur að Datadog: af þjónustukortinu getum við séð að notendabeiðnir koma til Django. Förum í Django þjónustuna og sjáum loksins hverju við áttum von á:

Því miður er ekkert graf hér sjálfgefið Viðskiptatími á vefnum, svipað því sem við sjáum á aðal New Relic spjaldið. Hins vegar er hægt að stilla það í stað áætlunarinnar % af tíma sem varið er. Það er nóg að skipta yfir í Meðaltími á beiðni eftir tegund... og nú horfir kunnuglega línuritið á okkur!

Hvers vegna Datadog valdi annað kort er okkur ráðgáta. Annar pirrandi hlutur er að kerfið man ekki val notandans (ólíkt báðum keppendum), og því er eina lausnin að búa til sérsniðin spjöld.

En ég var ánægður með hæfileikann í Datadog til að skipta úr þessum línuritum yfir í mæligildi tengdra netþjóna, lesa logs og meta álagið á vefþjóna meðhöndlun (Gunicorn). Allt er nánast eins og í New Relic... og jafnvel aðeins meira (logs)!

Fyrir neðan línuritin eru viðskipti algjörlega svipuð og New Relic:

Í Datadog eru færslur kallaðar auðlindir. Þú getur flokkað stýringar eftir fjölda beiðna, eftir meðalviðbragðstíma og hámarkstíma sem varið er í valinn tíma.

Þú getur stækkað auðlindina og séð allt sem við höfum þegar séð í New Relic:

Það eru tölfræði um tilföngin, almennur listi yfir innri símtöl og dæmi um beiðnir sem hægt er að flokka eftir svarkóða... Við the vegur, verkfræðingum okkar líkaði mjög við þessa flokkun.

Hægt er að opna og rannsaka hvaða dæmi sem er í Datadog:

Beiðnibreytur, yfirlitsrit yfir þann tíma sem varið er í hvern íhlut og fossatöflu sem sýnir röð símtala eru kynntar. Þú getur líka skipt yfir í trjámynd af fossatöflunni:

Og það áhugaverðasta er að skoða hleðsluna á gestgjafanum sem beiðnin var framkvæmd á og skoða beiðnidagskrána.

Frábær samþætting!

Þú gætir velt því fyrir þér hvar fliparnir eru Gagnagrunnar и Ytri þjónustu, eins og í New Relic. Það eru engar hér: þar sem Datadog sundrar forritinu í íhluti, verður PostgreSQL tekin til greina sérstaka þjónustu, og í stað ytri þjónustu er það þess virði að leita að aws.storage (það verður svipað fyrir hverja aðra ytri þjónustu sem forritið hefur aðgang að).

Hér er dæmi með postgres:

Í meginatriðum er allt sem við vildum:

Þú getur séð frá hvaða „þjónustu“ beiðnin kom.

Það væri ekki rangt að minna þig á að Datadog samþættist fullkomlega NGINX Ingress og gerir þér kleift að framkvæma rakningu frá því augnabliki sem beiðni berst í þyrpinguna, og gerir þér einnig kleift að taka á móti tölfræðimælingum, safna annálum og hýsingarmælingum. .

Stór plús við Datadog er að verð þess þróast frá innviðaeftirliti, APM, Log Management og Synthetics prófi, þ.e. Þú getur valið áætlun þína á sveigjanlegan hátt.

2.Atatus

Atatus teymið heldur því fram að þjónusta þeirra sé „söm og New Relic, en betri. Við skulum sjá hvort þetta sé í alvörunni.

Aðalborðið lítur svipað út, en það var ekki hægt að ákvarða Redis og memcached sem notað er í forritinu.

APM velur allar færslur sjálfgefið, þó venjulega sé aðeins þörf á veffærslum. Eins og Datadog er engin leið til að fara í viðkomandi þjónustu frá aðalborðinu. Þar að auki eru viðskipti skráð eftir villum, sem virðist ekki mjög rökrétt fyrir APM.

Í Atatus viðskiptum er allt eins svipað og hægt er og New Relic. Gallinn er sá að gangverkið fyrir hvern stjórnanda er ekki sýnilegt strax. Þú verður að leita að því í stjórnunartöflunni, flokkað eftir Mestur tími:

Venjulegur listi yfir stýringar er fáanlegur í flipanum Skoða:

Að sumu leyti minnir þessi tafla á Datadog og mér finnst hún betri en sú svipaða í New Relic.

Þú getur stækkað hverja færslu og séð hvað forritið var að gera:

Spjaldið minnir líka meira á Datadog: það er fjöldi beiðna, almenn mynd af símtölum. Efsta spjaldið býður upp á villuflipa HTTP bilanir og dæmi um hægar fyrirspurnir Session Traces:

Ef þú ferð í færslu geturðu séð dæmi um rakningu, þú getur fengið lista yfir beiðnir í gagnagrunninn og skoðað beiðnihausana. Allt er svipað og New Relic:

Almennt séð var Atatus ánægður með nákvæmar ummerki - án hinnar dæmigerðu New Relic að líma símtöl í áminningarblokk:

Hins vegar vantar það síu sem (eins og New Relic) myndi skera úr ofurhröðum beiðnum (<5ms). Á hinn bóginn líkaði mér við birtingu lokaviðskiptaviðbragðsins (árangur eða villa).

Панель Gagnagrunnar mun hjálpa þér að rannsaka beiðnir til ytri gagnagrunna sem forritið gerir. Ég minni á að Atatus fann aðeins PostgreSQL og MySQL, þó að Redis og memcached séu einnig með í verkefninu.

Beiðnum er raðað eftir venjulegum forsendum: svartíðni, meðalviðbragðstími og svo framvegis. Mig langar líka að nefna flipann með hægustu fyrirspurnunum - hann er mjög þægilegur. Þar að auki féllu gögnin á þessum flipa fyrir PostgreSQL saman við gögnin frá viðbótinni pg_stat_statements - frábær árangur!

Tab Ytri beiðnir alveg eins og gagnasöfn.

Niðurstöður

Bæði kynntu verkfærin stóðu sig vel í hlutverki APM. Hver þeirra getur boðið upp á tilskilið lágmark. Hugmyndir okkar má draga saman í stuttu máli sem hér segir:

Gagnahundur

Kostir:

þægileg gjaldskrá (APM kostar 31 USD á gestgjafa);
virkaði vel með Python;
Möguleiki á samþættingu við OpenTracing
samþætting við Kubernetes;
samþættingu við NGINX Ingress.

Gallar:

eina APM sem olli því að forritið varð óaðgengilegt vegna einingavillu (predis);
veik PHP sjálfvirk tækjabúnaður;
að hluta til undarleg skilgreining á þjónustu og tilgangi hennar.

Atatus