🥇Not New Relic bakarrik: Datadog eta Atatus-i begirada bat

SRE/DevOps ingeniarien ingurunean, ez da inor harrituko, egunen batean bezero bat (edo monitorizazio sistema) agertzea eta “dena galduta” dagoela jakinaraztea: guneak ez du funtzionatzen, ordainketak ez dira pasatzen, bizitza gainbehera doa. ... Ez du axola zenbat lagundu nahi duzun egoera batean, oso zaila izan daiteke hori egitea tresna sinple eta ulergarririk gabe. Askotan arazoa aplikazioaren kodean bertan ezkutatzen da; lokalizatu besterik ez duzu behar.

Eta penaz eta pozez...

Gertatu zen, aspaldi eta sakonki maitemindu garela New Relic-ekin. Aplikazioen errendimendua kontrolatzeko tresna bikaina izan zen eta izaten jarraitzen du, eta mikrozerbitzuen arkitektura (bere agentea erabiliz) eta askoz, askoz gehiago instrumentatzeko aukera ematen du. Eta dena bikaina izan zitekeen zerbitzuaren prezio politikan aldaketak izan ez balira: hura kostua 2013 urtetik aurrera 3 aldiz baino gehiago hazi zen. Gainera, iaztik, probako kontua lortzeko kudeatzaile pertsonal batekin komunikatzea eskatzen da, eta horrek zaildu egiten du produktua bezero potentzialari aurkeztea.

Ohiko egoera: Erlikia Berria ez da behar "betiko moduan"; arazoak hasten diren unean bakarrik gogoratzen dute. Hala ere, aldizka ordaindu behar duzu (140 USD zerbitzari bakoitzeko hilean), eta automatikoki eskalatzen den hodeiko azpiegitura batean, zenbatekoak nahiko handiak dira. Ordaindu ahala aukera bat dagoen arren, New Relic gaituz gero, aplikazioa berrabiarazi beharko duzu, eta horrek guztiak hasitako egoera arazotsuaren galera ekar dezake. Duela ez asko, New Relic-ek tarifa-plan berria aurkeztu zuen - Essentials, - Lehen begiratuan Profesionalaren alternatiba zentzuzko bat dirudi... baina sakonago aztertuta, funtzio garrantzitsu batzuk falta direla ikusi da (bereziki, ez du Funtsezko Transakzioak, Aplikazio gurutzatuaren jarraipena, Banatutako Trazadura).

Ondorioz, alternatiba merkeago baten bila hasi ginen pentsatzen, eta gure aukera bi zerbitzutan geratu zen: Datadog eta Atatus. Zergatik haien gainean?

Lehiakideei buruz

Esan dezadan berehala beste irtenbide batzuk badirela merkatuan. Kode irekiko aukerak ere kontuan hartu genituen, baina bezero guztiek ez dute gaitasun librea auto-ostatatutako soluzioak ostatatzeko... - horretaz gain, mantentze osagarriak beharko dituzte. Aukeratu genuen bikotea izan zen hurbilena gure beharrak:

PHP aplikazioetarako euskarria integratua eta garatua (gure bezeroen pila oso anitza da, baina hau lider argia da New Relic-en alternatiba bilatzeko testuinguruan);
kostu merkea (100 USD baino gutxiago hilean ostalari bakoitzeko);
tresneria automatikoa;
Kubernetes-ekin integratzea;
New Relic interfazearen antzekotasuna abantaila nabarmena da (gure ingeniariak ohituta daudelako).

Hori dela eta, hasierako hautaketa fasean, beste hainbat irtenbide ezagun ezabatu genituen, eta bereziki:

Tideways, AppDynamics eta Dynatrace - kostuagatik;
Stackify Errusiar Federazioan blokeatuta dago eta datu gutxiegi erakusten du.

Artikuluaren gainontzeko eran egituratuta dago, lehenik eta behin, aipatutako irtenbideak laburki aurkeztuko direlarik, eta ondoren, New Relic-ekin dugun elkarrekintza tipikoaz eta beste zerbitzu batzuetan antzeko eragiketak egitearen esperientzia/inpresioak hitz egingo dut.

Hautatutako lehiakideen aurkezpena

Про New Reliquia, ziurrenik denek entzun dute? Zerbitzu hau duela 10 urte baino gehiago hasi zen garatzen, 2008an. 2012az geroztik aktiboki erabiltzen ari gara eta ez dugu arazorik izan PHP, Ruby eta Python-en aplikazio kopuru handi bat integratzeko, eta C# eta Go-rekin integratzeko esperientzia ere izan dugu. Zerbitzuaren egileek aplikazioak monitorizatzeko, azpiegiturak, mikrozerbitzuen azpiegiturak trazatzeko irtenbideak dituzte, erabiltzaileen gailuetarako aplikazio erosoak sortu eta askoz gehiago.

Hala ere, New Relic agentea jabedun protokoloetan exekutatzen da eta ez du OpenTracing onartzen. Tresneria aurreratuak New Relic-entzat bereziki aldaketak behar ditu. Azkenik, Kubernetes laguntza esperimentala da oraindik.

2010ean hasi zen garatzen datadog New Relic baino nabarmen interesgarriagoa dirudi Kubernetes inguruneetan erabilerari dagokionez hain zuzen ere. Bereziki, NGINX Ingress, log bilketa, statsd eta OpenTracing protokoloekin integratzea onartzen du, konektatzen den unetik erabiltzaileen eskaeraren jarraipena egiteko aukera ematen duena, baita eskaera honen erregistroak aurkitzeko ere (biak web zerbitzariaren aldean). eta kontsumitzailearengan).

Datadog erabiltzean, batzuetan mikrozerbitzuen mapa gaizki eraikitzen zuela eta gabezia tekniko batzuk aurkitu genituen. Adibidez, zerbitzu mota oker identifikatu zuen (Django caching zerbitzu batekin nahastuz) eta 500 errore eragin zituen PHP aplikazio batean Predis liburutegi ezaguna erabiliz.

Atatus — instrumenturik gazteena; zerbitzua 2014an jarri zen martxan. Bere marketin-aurrekontua, argi eta garbi, zerrendatutako lehiakideen aldean txikiagoa da, aipamenak askoz gutxiago dira. Hala ere, tresna bera New Relic-en oso antzekoa da, ez bakarrik bere gaitasunetan (APM, Arakatzailearen monitorizazioa, etab.), baita itxuraz ere.

Eragozpen esanguratsu bat Node.js eta PHP bakarrik onartzen dituela da. Bestalde, Datadog baino nabarmen hobeto inplementatzen da. Azken hau ez bezala, Atatusek ez du aplikaziorik eskatzen kodeari aldaketak egiteko edo etiketa gehigarriak gehitzeko.

Nola lan egiten dugun New Relic-ekin

Orain ikus dezagun nola erabiltzen dugun oro har New Relic. Demagun konponbidea behar duen arazo bat dugula:

Grafikoan erraz ikusten da areagotu - Azter dezagun. New Relic-en, web-transakzioak berehala hautatzen dira web aplikazio baterako, osagai guztiak errendimendu grafikoan adierazten dira, errore-tasa, eskaera-tasa panelak daude... Garrantzitsuena da panel horietatik zuzenean mugi zaitezkeela aplikazioaren zatiak (adibidez, MySQL-en klik egiteak datu-basearen atalera eramango du).

Kontuan izan dugun adibidean jardueraren gorakada ikusten dugulako PHP, egin klik taula honetan eta joan automatikoki hona Transakzio:

Transakzioen zerrenda, funtsean MVC ereduko kontrolatzaileak direnak, dagoeneko ordenatuta dago Denbora gehien kontsumitzen du, oso erosoa dena: berehala ikusten dugu aplikazioak zer egiten duen. Hona hemen New Relic-ek automatikoki biltzen dituen kontsulta luzeen adibideak. Ordenaketa aldatuta, erraza da aurkitzea:

gehien kargatutako aplikazio-kontrolatzailea;
gehien eskatzen den kontrolatzailea;
kontrolagailuetatik motelena.

Horrez gain, transakzio bakoitza zabal dezakezu eta aplikazioak zer egiten zuen kodea exekutatu zenean ikusi dezakezu:

Azkenik, aplikazioak eskaera luzeen arrastoen adibideak gordetzen ditu (2 segundo baino gehiago behar dituztenak). Hona hemen transakzio luze baterako panela:

Ikusten da bi metodok denbora asko behar dutela, eta, aldi berean, eskaera exekutatu zeneko denbora, bere URIa eta domeinua ere erakusten dira. Askotan honek erregistroetan eskaera aurkitzen laguntzen du. Joan Aztarna xehetasunak, metodo hauek nondik deitzen diren ikus dezakezu:

Eta Datu-basearen kontsultak — Aplikazioa exekutatzen ari zen bitartean exekutatu ziren datu-baseetarako kontsultak ebaluatzea:

Ezagutza horrekin hornituta, aplikazioa zergatik moteltzen ari den ebaluatu eta garatzailearekin lan egin dezakegu arazoa konpontzeko estrategia bat egiteko. Egia esan, New Relic ez du beti irudi argia ematen, baina ikerketaren bektorea aukeratzen laguntzen du:

luze PDO::Construct pgpoll-en funtzionamendu bitxira eraman gintuen;
denboran zehar ezegonkortasuna Memcache::Get makina birtuala gaizki konfiguratuta zegoela iradoki zuen;
Txantiloiaren prozesatzeko denbora susmagarri handitu batek objektuen biltegian 500 avatarren presentzia egiaztatzen duen begizta habiaratu bat eragin zuen;
etab…

Gertatzen da, halaber, kodea exekutatu beharrean, kanpoko datuen biltegiratzearekin lotutako zerbait hazten dela pantaila nagusian -eta berdin du zer izango den: Redis edo PostgreSQL- fitxan ezkutatuta daude guztiak. Datu-baseak.

Oinarri zehatz bat hauta dezakezu ikerketarako eta kontsultak ordenatzeko, Transactions-en egiten den antzera. Eta eskaera fitxara joanda, eskaera hori zenbat aldiz gertatzen den ikus dezakezu aplikazio-kontrolatzaile bakoitzean, eta zenbat aldiz deitzen den ere kalkulatu. Oso erosoa da:

Fitxak antzeko datuak ditu Kanpo Zerbitzuak, kanpoko HTTP zerbitzuetarako eskaerak ezkutatzen dituena, hala nola, objektuen biltegian sartzeko, gertaerak guardiara bidaltzeko edo antzekoak. Fitxaren edukia Datu-baseen guztiz antzekoa da:

Lehiakideak: aukerak eta inpresioak

Orain interesgarriena New Relic-en gaitasunak lehiakideek eskaintzen dutenarekin alderatzea da. Zoritxarrez, ezin izan ditugu hiru tresnak probatu ekoizpenean exekutatzen ari den aplikazio baten bertsio batean. Hala ere, ahalik eta berdinen zeuden egoerak/konfigurazioak konparatzen saiatu gara.

1.Datadog

Datadog-ek zerbitzuen horma duen panel batekin agurtzen gaitu:

Aplikazioak osagai/mikrozerbitzuetan zatitzen saiatzen da, beraz Django aplikazioaren adibidean PostgreSQL-rako 2 konexio ikusiko ditugu (defaultdb и postgres), baita Apioa, Redis ere. Datadog-ekin lan egiteak MVC printzipioen ezagutza minimoa izatea eskatzen du: erabiltzaileen eskaerak orokorrean nondik datozen ulertu behar duzu. Horrek normalean laguntzen du zerbitzuen mapa:

Bide batez, antzeko zerbait dago New Relic-en:

... eta haien mapa, nire ustez, sinpleagoa eta argiagoa da: ez ditu aplikazio baten osagaiak bistaratzen (horrek zehatzegia egingo luke, Datadog-en kasuan bezala), zerbitzu edo mikrozerbitzu zehatzak soilik.

Itzul gaitezen Datadog-era: zerbitzu-mapatik ikus dezakegu erabiltzaileen eskaerak Djangora heltzen direla. Goazen Django zerbitzura eta azkenean ikus dezagun zer espero genuen:

Zoritxarrez, hemen ez dago grafikorik lehenespenez Web transakzio-denbora, New Relic panel nagusian ikusten dugunaren antzekoa. Hala ere, ordutegiaren ordez konfigura daiteke Denboraren %. Nahikoa da aldatzea Eskaera bakoitzeko batez besteko denbora motaren arabera... eta orain grafiko ezaguna guri begira dago!

Datadog-ek zergatik aukeratu duen beste grafiko bat misterio bat da guretzat. Beste gauza frustragarri bat da sistemak ez duela erabiltzailearen aukera gogoratzen (bi lehiakideek ez bezala), eta, beraz, irtenbide bakarra panel pertsonalizatuak sortzea da.

Baina pozik nengoen Datadog-ek grafiko horietatik erlazionatutako zerbitzarien metriketara aldatzeko, erregistroak irakurri eta web zerbitzarien kudeatzaileen karga ebaluatzeko (Gunicorn). Dena ia berdina da New Relic-en... eta are gehiago (erregistroak)!

Grafikoen azpian erlikia Berriaren guztiz antzeko transakzioak daude:

Datadog-en, transakzioak deitzen dira baliabideak. Kontrolagailuak eskaera kopuruaren arabera, batez besteko erantzun denboraren arabera eta hautatutako denbora-tarte batean emandako gehienezko denboraren arabera ordena ditzakezu.

Baliabidea zabal dezakezu eta dagoeneko ikusi dugun guztia ikusi New Relic-en:

Baliabideari buruzko estatistikak daude, barne deien zerrenda orokortua, eta erantzun-kodearen arabera ordena daitezkeen eskaeren adibideak... Bide batez, gure ingeniariei asko gustatu zitzaien sailkapen hau.

Datadog-en edozein baliabide adibide ireki eta azter daiteke:

Eskaeraren parametroak, osagai bakoitzari emandako denboraren laburpen-taula eta deien sekuentzia erakusten duen ur-jauziaren taula aurkezten dira. Ur-jauziaren diagramaren zuhaitz ikuspegi batera ere alda dezakezu:

Eta interesgarriena eskaera exekutatu den ostalariaren karga ikustea eta eskaeraren erregistroak ikustea da.

Integrazio bikaina!

Baliteke fitxak non dauden galdetzea Datu-baseak и Kanpo Zerbitzuak, Erlikia Berrian bezala. Hemen ez dago bat: Datadog-ek aplikazioa osagaietan deskonposatzen duenez, PostgreSQL hartuko da kontuan aparteko zerbitzu bat, eta Kanpo Zerbitzuen ordez merezi du bilatzea aws.storage (Aplikazioak atzi dezakeen kanpoko beste zerbitzu guztietan antzekoa izango da).

Hona hemen adibide bat postgres:

Funtsean, nahi genuen guztia dago:

Eskaera zein "zerbitzu"tik datorren ikus dezakezu.

Ez litzateke okerrago gogoratzea Datadog NGINX Ingress-ekin ezin hobeto integratzen dela eta eskaera bat klusterera iristen den unetik amaierako trazadura egiteko aukera ematen duela, eta, gainera, estatistikak jasotzeko, erregistroak eta ostalari-neurriak jasotzeko aukera ematen dizu. .

Datadog-en abantaila handi bat bere prezioa da garatzen da azpiegituren monitorizaziotik, APMtik, Log Management eta Synthetics probatik, hau da. Zure plana malgutasunez aukeratu dezakezu.

2.Atatus

Atatus taldeak dio euren zerbitzua "erlikia Berriaren berdina dela, baina hobea". Ea benetan horrela den.

Panel nagusiak antzeko itxura du, baina ezin izan da aplikazioan erabilitako Redis eta memcached zehaztu.

APM-k transakzio guztiak hautatzen ditu lehenespenez, nahiz eta normalean web transakzioak soilik behar diren. Datadog bezala, ez dago panel nagusitik nahi den zerbitzura nabigatzeko modurik. Gainera, transakzioak akatsen ondoren zerrendatzen dira, eta horrek ez dirudi oso logikoa APMrentzat.

Atatus-eko transakzioetan, dena da erlikia berriaren antzekoena. Alde txarra da kontrolagailu bakoitzaren dinamika ez dela berehala ikusten. Kontrolagailuen taulan bilatu behar duzu, arabera ordenatuta Denbora gehien kontsumitua:

Kontrolatzaileen ohiko zerrenda fitxan dago eskuragarri arakatu:

Nolabait, taula honek Datadog gogorarazten du eta New Relic-en antzekoa baino hobeto gustatzen zait.

Transakzio bakoitza zabal dezakezu eta aplikazioak zer egiten ari zen ikusi:

Panelak ere Datadog gogorarazten du: hainbat eskaera daude, deien argazki orokorra. Goiko panelak errore-fitxa bat eskaintzen du HTTP hutsegiteak eta kontsulta motelen adibideak Saioaren arrastoak:

Transakzio batera joaten bazara, arrasto baten adibide bat ikus dezakezu, datu-baserako eskaeren zerrenda bat lor dezakezu eta eskaeraren goiburuak begiratu. Dena New Relic-en antzekoa da:

Orokorrean, Atatus pozik dago aztarna zehatzekin - deiak abisu-bloke batean erliki berrien itsatsirik gabe:

Hala ere, ez du (erlikia berria bezala) eskaera ultra-azkarrak (<5 ms) moztuko dituen iragazkirik. Bestalde, gustatu zait azken transakzioaren erantzuna bistaratzea (arrakasta edo errorea).

panel Datu-baseak aplikazioak egiten dituen kanpoko datu-baseetarako eskaerak aztertzen lagunduko dizu. Gogorarazten dizut Atatusek PostgreSQL eta MySQL bakarrik aurkitu zituela, nahiz eta Redis eta memcached-ek ere proiektuan parte hartzen duten.

Eskaerak ohiko irizpideen arabera ordenatzen dira: erantzun maiztasuna, erantzunaren batez besteko denbora, etab. Kontsulta motelenak dituen fitxa ere aipatu nahiko nuke; oso erosoa da. Gainera, PostgreSQL-ren fitxa honetako datuak luzapeneko datuekin bat datoz pg_stat_statements - emaitza bikaina!

Fitxa Kanpoko Eskaerak Datu-baseen guztiz berdina.

Findings

Aurkeztutako bi tresnek ondo funtzionatu zuten APMren paperean. Horietako edozeinek eskatutako gutxienekoa eskain dezake. Gure inpresioak labur-labur honela laburbil daitezke:

datadog

Pros:

tarifa-ordutegi erosoa (APM-k 31 USD balio du ostalari bakoitzeko);
ondo funtzionatu zuen Pythonekin;
OpenTracing-ekin integratzeko aukera
Kubernetes-ekin integratzea;
NGINX Ingress-ekin integratzea.

Cons:

modulu-errore baten ondorioz aplikazioa erabilgarri ez egotea eragin zuen APM bakarra (predis);
PHP autotresnamendu ahula;
zerbitzuen eta haien xedearen definizio neurri batean arraroa.

Atatus