🥇Ne New Relic sole: rigardo al Datadog kaj Atatus

En la medio de SRE/DevOps-inĝenieroj, neniun surprizos, ke iam kliento (aŭ monitora sistemo) aperas kaj raportas, ke "ĉio estas perdita": la retejo ne funkcias, pagoj ne trairas, la vivo kadukiĝas. ... Kiom ajn vi ŝatus helpi en tia situacio, povas esti tre malfacile fari tion sen simpla kaj komprenebla ilo. Ofte la problemo estas kaŝita en la aplika kodo mem; vi nur bezonas lokalizi ĝin.

Kaj en malĝojo kaj en ĝojo...

Okazis, ke ni longe kaj profunde enamiĝis al New Relic. Ĝi estis kaj restas bonega ilo por monitori aplikaĵan agadon, kaj ankaŭ permesas vin instrumenti la mikroservan arkitekturon (uzante ĝian agenton) kaj multe, multe pli. Kaj ĉio povus esti bonega se ne estus ŝanĝoj en la prezo-politiko de la servo: ĝi kosto de 2013-jara jaro kreskis 3+ fojojn. Krome, ekde la pasinta jaro, akiri provan konton postulas komunikadon kun persona administranto, kio malfaciligas prezenti la produkton al ebla kliento.

La kutima situacio: Nova Relikvo ne estas bezonata sur "konstanta bazo"; ili memoras ĝin nur en la momento kiam problemoj komenciĝas. Sed vi ankoraŭ devas pagi regule (140 USD po servilo monate), kaj en aŭtomate grima nuba infrastrukturo la sumoj sumiĝas sufiĉe grandaj. Kvankam ekzistas opcio Pay-As-You-Go, ebligi New Relic postulos, ke vi rekomencu la aplikaĵon, kio povas konduki al la perdo de la problema situacio, por kiu ĝi ĉio estis komencita. Antaŭ nelonge, New Relic prezentis novan tarifplanon - Havendaĵoj, - kiu unuavide aspektas kiel racia alternativo al Profesiulo... sed post pli proksima ekzameno montriĝis, ke kelkaj gravaj funkcioj mankas (precipe ĝi ne havas Ŝlosilaj Transakcioj, Transversa Apliko-Spurado, Distribuita Spurado).

Kiel rezulto, ni ekpensis serĉi pli malmultekostan alternativon, kaj nia elekto falis sur du servoj: Datadog kaj Atatus. Kial sur ili?

Pri konkurantoj

Mi diru tuj, ke ekzistas aliaj solvoj sur la merkato. Ni eĉ pripensis Malfermfontajn opciojn, sed ne ĉiu kliento havas liberan kapablon gastigi memgastigitajn solvojn... - krome, ili postulos plian prizorgadon. La paro, kiun ni elektis, montriĝis la plej proksima niaj bezonoj:

enkonstruita kaj evoluinta subteno por PHP-aplikoj (la stako de niaj klientoj estas tre diversa, sed ĉi tio estas klara gvidanto en la kunteksto de serĉado de alternativo al New Relic);
pagebla kosto (malpli ol 100 USD monate por gastiganto);
aŭtomata instrumentado;
integriĝo kun Kubernetes;
La simileco al la interfaco New Relic estas rimarkinda pluso (ĉar niaj inĝenieroj kutimas ĝin).

Tial, en la komenca elekta etapo, ni forigis plurajn aliajn popularajn solvojn, kaj precipe:

Tideways, AppDynamics kaj Dynatrace - kontraŭ kosto;
Stackify estas blokita en la Rusa Federacio kaj montras tro malmulte da datumoj.

La resto de la artikolo estas strukturita tiel, ke la koncernaj solvoj unue estos mallonge prezentitaj, post kio mi parolos pri nia tipa interago kun Nova Relikvo kaj sperto/impresoj de farado de similaj operacioj en aliaj servoj.

Prezento de elektitaj konkurantoj

pri Nova Relikvo, verŝajne ĉiuj aŭdis? Ĉi tiu servo komencis sian evoluon antaŭ pli ol 10 jaroj, en 2008. Ni aktive uzas ĝin ekde 2012 kaj ne havis problemojn integri vere grandan nombron da aplikoj en PHP, Ruby kaj Python, kaj ni ankaŭ havis sperton integri kun C# kaj Go. La aŭtoroj de la servo havas solvojn por monitori aplikojn, infrastrukturojn, spuri mikroservajn infrastrukturojn, kreis oportunajn aplikojn por uzantaj aparatoj kaj multe pli.

Tamen, la New Relic-agento funkcias per proprietaj protokoloj kaj ne subtenas OpenTracing. Altnivela instrumentado postulas redaktojn specife por New Relic. Fine, la subteno de Kubernetes ankoraŭ estas eksperimenta.

Komencis ĝian evoluon en 2010 datuma hundo aspektas videble pli interesa ol New Relic ĝuste laŭ uzo en Kubernetes-medioj. Precipe, ĝi subtenas integriĝon kun NGINX Ingress, protokolojn de protokoloj, statsd kaj OpenTracing, kiuj ebligas al vi spuri uzantan peton de la momento, kiam ĝi estas konektita ĝis kompletigo, kaj trovi protokolojn por ĉi tiu peto (ambaŭ ĉe la retservila flanko. kaj ĉe la konsumanto).

Uzante Datadog, ni renkontis, ke ĝi foje konstruis la mikroservan mapon malĝuste, kaj iujn teknikajn mankojn. Ekzemple, ĝi misidentigis la servospecon (konfuzante Django kun kaŝmemorservo) kaj kaŭzis 500 erarojn en PHP-aplikaĵo uzante la popularan Predis-bibliotekon.

Atato — la plej juna instrumento; la servo estis lanĉita en 2014. Ĝia merkatika buĝeto estas klare pli malalta ol la listigitaj konkurantoj, mencioj estas multe malpli oftaj. Tamen, la ilo mem estas tre simila al New Relic, ne nur laŭ siaj kapabloj (APM, Retumilo-monitorado ktp.), sed ankaŭ laŭ aspekto.

Grava malavantaĝo estas, ke ĝi nur subtenas Node.js kaj PHP. Aliflanke, ĝi estas efektivigita videble pli bone ol Datadog. Male al ĉi-lasta, Atatus ne postulas aplikojn fari modifojn aŭ aldoni pliajn etikedojn al la kodo.

Kiel ni laboras kun New Relic

Nun ni eltrovu kiel ni ĝenerale uzas Novan Relikaĵon. Ni diru, ke ni havas problemon, kiu bezonas solvon:

Estas facile videbla sur la grafikaĵo superforte - Ni analizu ĝin. En New Relic, interretaj transakcioj estas tuj elektitaj por TTT-apliko, ĉiuj komponantoj estas indikitaj en la agado-grafiko, estas paneloj pri eraro-indico, peto-takso... Plej gravas, ke rekte de ĉi tiuj paneloj vi povas moviĝi inter malsamaj. partoj de la aplikaĵo (ekzemple, klakado sur MySQL kondukos al la datumbaza sekcio).

Ĉar en la konsiderata ekzemplo ni vidas kreskon de agado PHP, alklaku ĉi tiun diagramon kaj aŭtomate iru al transakcioj:

La listo de transakcioj, kiuj estas esence regiloj de la MVC-modelo, jam estas ordigita per Plej tempopostula, kio estas tre oportuna: ni tuj vidas, kion faras la aplikaĵo. Jen ekzemploj de longaj demandoj, kiuj estas aŭtomate kolektitaj de New Relic. Ŝanĝante ordigon, estas facile trovi:

la plej ŝarĝita aplika regilo;
plej ofte petita regilo;
la plej malrapida el la regiloj.

Krome, vi povas vastigi ĉiun transakcion kaj vidi kion la aplikaĵo faris en la momento, kiam la kodo estis ekzekutita:

Fine, la aplikaĵo konservas ekzemplojn de spuroj de longaj petoj (tiuj kiuj daŭras pli ol 2 sekundojn). Jen la panelo por longa transakcio:

Videblas, ke du metodoj bezonas multan tempon, kaj samtempe la tempo, kiam la peto estis ekzekutita, ĝia URI kaj domajno ankaŭ estas montritaj. Tre ofte ĉi tio helpas trovi la peton en la protokoloj. Iru al Spuri detalojn, vi povas vidi de kie ĉi tiuj metodoj estas nomitaj:

Kaj en Demandoj pri datumbazoj — taksi demandojn al datumbazoj, kiuj estis ekzekutitaj dum la aplikaĵo funkciis:

Armitaj kun ĉi tiu scio, ni povas taksi kial la aplikaĵo malrapidiĝas kaj labori kun la programisto por elpensi strategion por solvi la problemon. En realeco, New Relic ne ĉiam donas klaran bildon, sed ĝi helpas elekti la vektoron de esploro:

longa PDO::Construct kondukis nin al la stranga funkciado de pgpoll;
malstabileco laŭlonge de la tempo Memcache::Get sugestis, ke la virtuala maŝino estis malĝuste agordita;
suspektinde pliigita tempo por ŝablonprilaborado kondukis al nestita buklo kontrolanta la ĉeeston de 500 avataroj en la objektostokado;
kaj tiel plu…

Okazas ankaŭ, ke anstataŭ ekzekuti kodon, io rilata al ekstera datumstokado kreskas sur la ĉefa ekrano - kaj ne gravas kio ĝi estos: Redis aŭ PostgreSQL - ili ĉiuj estas kaŝitaj en la langeto. datumbazoj.

Vi povas elekti specifan bazon por esplori kaj ordigi demandojn - simile al kiel ĝi estas farita en Transakcioj. Kaj irante al la petoklapeto, vi povas vidi kiom da fojoj ĉi tiu peto okazas en ĉiu el la aplikaĵregiloj, kaj ankaŭ taksi kiom ofte ĝi estas vokita. Ĝi estas tre komforta:

La langeto enhavas similajn datumojn Eksteraj Servoj, kiu kaŝas petojn al eksteraj HTTP-servoj, kiel alirado de objektostokado, sendado de eventoj al gardostaranto aŭ simile. La enhavo de la langeto estas tute simila al Datumbazoj:

Konkurantoj: ŝancoj kaj impresoj

Nun la plej interesa afero estas kompari la kapablojn de New Relic kun tio, kion proponas konkurantoj. Bedaŭrinde, ni ne povis testi ĉiujn tri ilojn sur unu versio de unu aplikaĵo funkcianta en produktado. Tamen ni provis kompari situaciojn/agordojn kiel eble plej identajn.

1.Datadog

Datadog salutas nin per panelo kun muro de servoj:

Ĝi provas rompi aplikaĵojn en komponantojn/mikroservojn, do en la ekzemplo Django-apliko ni vidos 2 konektojn al PostgreSQL (defaultdb и postgres), same kiel Celery, Redis. Labori kun Datadog postulas, ke vi havu minimuman scion pri MVC-principoj: vi devas kompreni de kie ĝenerale venas uzantpetoj. Ĉi tio kutime helpas mapo de servoj:

Cetere, estas io simila en New Relic:

... kaj ilia mapo, laŭ mi, fariĝas pli simpla kaj klara: ĝi ne montras la komponantojn de unu aplikaĵo (kio farus ĝin tro detala, kiel en la kazo de Datadog), sed nur specifajn servojn aŭ mikroservojn.

Ni revenu al Datadog: el la serva mapo ni povas vidi, ke uzantpetoj venas al Django. Ni iru al la servo Django kaj finfine vidu, kion ni atendis:

Bedaŭrinde, ne estas grafikaĵo ĉi tie defaŭlte Interreta transakcia tempo, simila al tio, kion ni vidas sur la ĉefa Nova Relic panelo. Tamen, ĝi povas esti agordita anstataŭ la horaro % de Tempo elspezita. Sufiĉas ŝanĝi ĝin al Meza tempo por peto laŭ Tipo... kaj nun la konata grafeo rigardas nin!

Kial Datadog elektis malsaman diagramon estas mistero por ni. Alia frustranta afero estas, ke la sistemo ne memoras la elekton de la uzanto (male al ambaŭ konkurantoj), kaj tial la sola solvo estas krei kutimajn panelojn.

Sed mi ĝojis pri la kapablo en Datadog ŝanĝi de ĉi tiuj grafikaĵoj al la metrikoj de rilataj serviloj, legi la protokolojn kaj taksi la ŝarĝon sur la retservilaj prizorgantoj (Gunicorn). Ĉio estas preskaŭ sama kiel en New Relic... kaj eĉ iom pli (ŝtipoj)!

Sub la grafikaĵoj estas transakcioj tute similaj al New Relic:

En Datadog, transakcioj estas nomitaj rimedoj. Vi povas ordigi regilojn laŭ la nombro da petoj, laŭ meza responda tempo kaj laŭ la maksimuma tempo pasigita por elektita tempodaŭro.

Vi povas vastigi la rimedon kaj vidi ĉion, kion ni jam observis en New Relic:

Estas statistiko pri la rimedo, ĝeneraligita listo de internaj alvokoj, kaj ekzemploj de petoj ordigeblaj laŭ respondkodo... Cetere, niaj inĝenieroj tre ŝatis ĉi tiun ordigon.

Ajna ekzempla rimedo en Datadog povas esti malfermita kaj studita:

Petaj parametroj, resuma diagramo de la tempo pasigita sur ĉiu komponanto, kaj akvofala diagramo montranta la sinsekvon de vokoj estas prezentitaj. Vi ankaŭ povas ŝanĝi al arba vido de la akvofala diagramo:

Kaj la plej interesa afero estas vidi la ŝarĝon de la gastiganto sur kiu la peto estis efektivigita kaj vidi la petajn protokolojn.

Bonega integriĝo!

Vi povas scivoli kie estas la langetoj datumbazoj и Eksteraj Servoj, kiel en New Relic. Ne estas ĉi tie: ĉar Datadog malkomponas la aplikaĵon en komponantojn, PostgreSQL estos konsiderata aparta servo, kaj anstataŭ Eksteraj Servoj indas serĉi ĝin aws.storage (ĝi estos simila por ĉiu alia ekstera servo, kiun la aplikaĵo povas aliri).

Jen ekzemplo kun postgres:

Esence estas ĉio, kion ni deziris:

Vi povas vidi de kiu "servo" venis la peto.

Ne estus malbone memorigi vin, ke Datadog perfekte integriĝas kun NGINX Ingress kaj permesas al vi plenumi fin-al-finan spuradon de la momento, kiam peto alvenas en la areton, kaj ankaŭ permesas ricevi statsd-metrikojn, kolekti protokolojn kaj gastigantajn metrikojn. .

Grandega pluso de Datadog estas, ke ĝia prezo evoluas de infrastrukturmonitorado, APM, Log Management kaj Synthetics-testo, t.e. Vi povas elekti vian planon flekseble.

2.Atato

La teamo de Atatus asertas, ke ilia servo estas "la sama kiel New Relic, sed pli bona." Ni vidu ĉu ĉi tio vere estas tiel.

La ĉefa panelo aspektas simila, sed ne eblis determini la Redis kaj memcached uzatajn en la aplikaĵo.

APM elektas ĉiujn transakciojn defaŭlte, kvankam tipe nur Retaj transakcioj estas necesaj. Kiel Datadog, ne ekzistas maniero navigi al la dezirata servo de la ĉefa panelo. Plie, transakcioj estas listigitaj post eraroj, kio ne ŝajnas tre logika por APM.

En Atatus-transakcioj, ĉio estas kiel eble plej simila al New Relic. La malavantaĝo estas, ke la dinamiko por ĉiu regilo ne tuj videblas. Vi devas serĉi ĝin en la regilo-tabelo, ordigante Plej Tempo Konsumita:

La kutima listo de regiloj estas disponebla en la langeto esplori:

Iel ĉi tiu tablo rememorigas Datadog kaj mi ŝatas ĝin pli bone ol la simila en New Relic.

Vi povas vastigi ĉiun transakcion kaj vidi kion la aplikaĵo faris:

La panelo ankaŭ pli memorigas pri Datadog: ekzistas kelkaj petoj, ĝenerala bildo de vokoj. La supra panelo provizas eraran langeton HTTP Fiaskoj kaj ekzemploj de malrapidaj demandoj Sesiaj Spuroj:

Se vi iras al transakcio, vi povas vidi ekzemplon de spuro, vi povas ricevi liston de petoj al la datumbazo kaj rigardi la petajn kapliniojn. Ĉio similas al New Relic:

Ĝenerale, Atatus kontentiĝis pri detalaj spuroj - sen la tipa New Relic gluado de vokoj en memorblokon:

Tamen, al ĝi mankas filtrilo kiu (kiel New Relic) fortranĉus ultrarapidajn petojn (<5ms). Aliflanke, mi ŝatis la montradon de la fina transakcia respondo (sukceso aŭ eraro).

Panelo datumbazoj helpos vin studi la petojn al eksteraj datumbazoj, kiujn la aplikaĵo faras. Mi memorigu vin, ke Atatus trovis nur PostgreSQL kaj MySQL, kvankam Redis kaj memcached ankaŭ estas implikitaj en la projekto.

Petoj estas ordigitaj laŭ la kutimaj kriterioj: respondfrekvenco, meza respondtempo, ktp. Mi ankaŭ ŝatus mencii la langeton kun la plej malrapidaj demandoj - ĝi estas tre oportuna. Plie, la datumoj en ĉi tiu langeto por PostgreSQL koincidis kun la datumoj de la etendaĵo pg_stat_statements - bonega rezulto!

Tab Eksteraj Petoj tute identa al datumbazoj.

trovoj

Ambaŭ prezentitaj iloj bone agis en la rolo de APM. Ĉiu el ili povas oferti la bezonatan minimumon. Niaj impresoj povas esti mallonge resumitaj jene:

datuma hundo

Pros:

oportuna tarifhoraro (APM kostas 31 USD per gastiganto);
bone funkciis kun Python;
Eblo de integriĝo kun OpenTracing
integriĝo kun Kubernetes;
integriĝo kun NGINX Ingress.

Kons:

la nura APM kiu igis la aplikaĵon iĝi malhavebla pro moduleraro (predis);
malforta PHP-aŭtomata instrumentado;
parte stranga difino de servoj kaj ilia celo.

Atato