Mitme New Relic'i: vaade Datadogile ja Atatusele

SRE- ja DevOps-inseneride seas ei üllata peaaegu kedagi, kui klient (või monitooringusüsteem) teatab, et "kõik on kadunud": veebileht ei tööta, maksed ei lähe läbi, elu on tühi... Kuigi soov aidata on suur, on see sageli väga keeruline ilma lihtsa ja arusaadava tööriistata. Sageli on probleem peidus rakenduse enda koodis — seda tuleb lihtsalt lokaliseerida.

Nii rõõmus kui kurb...

On nii kujunenud, et me oleme juba ammu ja tõeliselt armastanud New Relic'ut. See on olnud ja on endiselt suurepärane tööriist rakenduse jõudluse monitooringuks ning võimaldab mikroteenuste arhitektuuri instrumenteerimist (oma agendi abil) ja palju muud. Ja kõik oleks võinud olla suurepärane, kui mitte teenuse hinnastrateegia muudatused: selle hind alates 2013. aastast on tõusnud üle 3 korra. Lisaks on alates eelmise aasta eest proovikonto saamiseks vajalik suhtlemine isikliku juhiga, mis muudab toote potentsiaalsele kliendile esitlemise keerulisemaks.

Tavaline olukord: New Relic ei ole "pikaajaliselt" vajalik, seda meenutatakse ainult siis, kui probleemid on alanud. Kuid tasuda tuleb siiski regulaarselt (140 USD serveri kohta kuus), ja automaatselt skaaleerivas pilvinfrastruktuuris kogunevad summad üsna suured. Kuigi on ka võimalus "Pay-As-You-Go", kuid New Relic'i aktiveerimiseks tuleb rakendus taaskäivitada, mis võib viia probleemi kadumiseni, mille tõttu kõik algas. Hiljuti on New Relic tutvustanud uut hinnakava - Alustavad, - mis esmapilgul näeb välja mõistlik alternatiiv Professional ... kuid detailide ülevaatamisel selgus, et osa olulisi funktsioone puudub (eriti puuduvad seal Key Transactions, Cross Application Tracing, Distributed Tracing).

Seeläbi hakkasime mõtlema odavama alternatiivi otsimisele ning meie valik langes kahele teenusele, Datadog ja Atatus. Miks just need?

Konkurentidest

Tuleb kohe märkida, et turul on ka teisi lahendusi. Me isegi kaalume Open Source variante, kuid mitte iga kliendi jaoks ei ole vaba ressursse self-hosted lahenduste paigutamiseks ... — lisaks vajavad need täiendavat hooldust. Meie valitud paar osutus meie vajadustele kõige lähedasemaks:

• Sisseehtinud ja arenenud PHP rakenduste tugi (meie klientide tehnoloogiad on väga erinevad, kuid see on ilmne liider alternatiivi otsingul New Relic'ile);
• taskukohane hind (alla 100 USD kuus hostimise eest);
• automaatne instrumenteerimine;
• integreerimine Kubernetesega;
• sarnasus New Relic'i liidesele — märkimisväärne pluss (sest meie insenerid on sellega harjunud).

Seetõttu kõrvaldati esialgsel valikul mitmed teised populaarsed lahendused, sealhulgas:

• Tideways, AppDynamics ja Dynatrace — hinna tõttu;
• Stackify — Venemaal blokeeritud ja näitab liiga vähe andmeid.

Järgmine artikkel on üles ehitatud nii, et esmalt tutvustatakse lühidalt arutluse all olevaid lahendusi, seejärel räägin meie tüüpilisest koostööst New Relic'iga ja kogemustest / muljetest sarnaste toimingute tegemisel teistes teenustes.

Valitud konkurentide esitlus

Küsimus New Relic, ilmselt on igaüks kuulnud? See teenus alustas oma arengut üle 10 aasta tagasi, 2008. aastal. Me oleme seda aktiivselt kasutanud alates 2012. aastast ja pole tõeliselt suures hulkade rakenduste integreerimisega probleeme kogenud, sealhulgas PHP, Ruby ja Python keeles, samuti on meil olnud kogemusi C# ja Go integreerimisega. Teenuse autoritel on lahendused rakenduste, infrastruktuuri monitoorimiseks, mikroteenusinfrastruktuuride jälgimiseks, loodud mugavad rakendused kasutajaseadmetele ja palju muud.

Kuid New Relic'i agent töötab omandiõiguse alusel, tal puudub OpenTracing tugi. Täiustatud instrumenteerimiseks on vajalikud muudatused spetsiaalselt New Relic'i jaoks. Lõpuks on Kubernetes'e tugi hetkel katsefaasis.

Arengut alustanud 2010. aastal Datadog näib Kubernetes keskkondades olevat oluliselt huvitavam kui New Relic. Eelkõige toetab see integreerimist NGINX Ingress'iga, logide kogumist, protokolle statsd ja OpenTracing, mis võimaldab jälgida kasutaja päringut ühenduse loomisest kuni töö lõpetamiseni, samuti leida selle päringuga seotud logisid (nii veebiserveri poolel kui ka tarbijate poolel).

Datadog'i kasutamisel kohtasime probleemi, et see mõnikord ehitas vale mikroteenuste kaardi ja teisi tehnilisi puudusi. Näiteks tuvastas see vale teenuse tüübi (võttis Django teenusena, mis tegeleb vahemälu haldamisega) ning põhjustas 500 viga PHP rakenduses, mis kasutas populaarset teeki Predis.

Atatus — kõige noorem tööriist; teenus käivitati 2014. aastal. Selle turunduseelarve jätab oluliselt alla loetletud konkurentide puhul, mainimised esinevad oluliselt harvem. Siiski on tööriist iseenesest väga sarnane New Relic'ule, mitte ainult funktsioonide (APM, brauseri jälgimine jne) poolest, vaid ka välimuse poolest.

Oluliseks puuduseks on toetuse pakkumine vaid Node.js ja PHP-le. Teisest küljest, see on realiseeritud märkimisväärselt paremini kui Datadog'i puhul. Erinevalt viimasest ei nõua Atatus rakendustelt täiendavate markeeringute lisamist koodis.

Kuidas me töötame New Relic'uga

Nüüd vaatame, kuidas me tavaliselt New Relic'ut kasutame. Oletame, et meil on probleem, mis vajab lahendamist:

Diagrammil on kergesti märgatav piik — analüüsime seda. New Relic'is on veebirakenduse jaoks kohe valitud veebitehingud, jõudluse diagrammil on näidatud kõik komponendid, sealhulgas error-rate, request-rate... Mis on kõige olulisem — otse nendelt paneelidelt saab liikuda erinevate rakenduse osade vahel (näiteks klikkimine MySQL viib andmebaaside sektsiooni).

Kuna antud näites näeme aktiivsuse piiki PHP, klikki selle diagrammi peale ja liikuge automaatselt Tehingud:

Tehingute nimekiri, mis sisuliselt on MVC mudeli kontrollerid, on juba sorteeritud järgi Enim aega nõudvad, mis on väga mugav: me näeme kohe, millega rakendus tegeleb. Siin on ka näidatud pikaajaliste päringute näidised, mis kogutakse automaatselt New Relic'i poolt. Sortimise vahetamisel on lihtne leida:

• rakenduse kõige koormatud kontroller;
• kõige sagedamini küsitud kontroller;
• kõige aeglasem kontrolleritest.

Lisaks on võimalik iga tehingu avada ja näha, millega rakendus tegi koodi täitmise ajal:

Lõpuks salvestatakse rakenduses näidised pikaajaliste päringute jälgedest (mis kestavad üle 2 sekundi). Siin on paneel pika tehingu jaoks:

Nähtav on, et palju aega kulub kahele meetodile, näidatakse ka aega, millal päring täideti, selle URI ja domeeni. Väga sageli aitab see leida päringu logidest. Liikudes Jälgimise üksikasjad, saab vaadata, kust need meetodid kutsutakse:

Ja Andmebaasi päringud — hinnata andmebaasi päringuid, mis toimusid rakenduse töötamise ajal:

Relvastades neid teadmisi, saame hinnata rakenduse aeglustumise põhjust ja koostada koos arendajaga strateegia probleemi lahendamiseks. Tegelikult ei paku New Relic alati selget pilti, kuid see aitab valida uurimise suuna:

• pikalt PDO::Construct viis meid kummalise pgpoll'i toimimise juurde;
• ebastabiilsus ajas Memcache::Get töötas välja vale virtuaalmasina konfiguratsiooni;
• kahtlaselt pikenenud mallide töötlemise aeg viis 500 avatariga objektihoidlasse kontrolliva sisemise tsüklini;
• ja nii edasi…

Oht, et koodi asemel põhilisel ekraanil tõuseb midagi, mis on seotud välise andmehoidla - olgu see Redis või PostgreSQL, - peitub kõikides vahekaartides Andmebaasid.

Saate valida konkreetse andmebaasi uurimiseks ja sorteerida päringuid - sarnaselt sellele, kuidas seda tehakse Transactions. Ja liikudes päringu vahekaardile, saate näha, kui sageli see päring esineb iga rakenduse kontrolleris ja hinnata, kui tihti seda kutsutakse. See on väga mugav:

Sarnaseid andmeid sisaldab vahekaart External Services, mis peidab endas väliste HTTP-teenuste päringud, nagu objektide hoidla kõned, sündmuste saatmine sentry'le või midagi sarnast. Oma sisu poolest on see vahekaart täielikult analoogne Databases:

Konkurendid: võimalused ja muljed

Nüüd on kõige huvitavam - võrreldame New Relici võimalusi selle, mida pakuvad konkurendid. Kahjuks ei õnnestunud meil testida kõiki kolme tööriista ühe tööversiooni production rakenduses. Sellegipoolest üritasime võrrelda võimalikult identsed olukorrad/konfiguratsioonid.

1. Datadog

Datadog tervitab meid teenuste seinaga:

Ta püüab rakendused jagada komponentide/mikroteenuste vahel, seega näeme antud näites Django rakenduse korral 2 ühendust PostgreSQL-iga (defaultdb ja postgres), samuti Celery, Redis. Datadogiga töötamine nõuab teilt minimaalset arusaamist MVC põhimõtetest: on vajalik mõista, kuhu kasutajate päringud tegelikult jõuavad. Tavaline abi on teenuste kaart:

Muide, midagi sarnast on ka New Relicis:

… ja nende kaart, minu arvates, on lihtsam ja arusaadavam: see kajastab mitte ühe rakenduse komponente (mis võiks muuta selle liialt detailsiseks, nagu Datadogi puhul), vaid ainult konkreetseid teenuseid või mikroteenuseid.

Naaseme Datadogi juurde: teenuste kaardilt on näha, et kasutajate päringud jõuavad Django kaudu. Läheme edasi Django teenusesse ja lõpuks näeme seda, mida ootasime:

Kahjuks pole siin vaikimisi graafikut Veebitehingu aeg, mis on analoogne sellele, mida näeme New Relici põhimenüüs. Siiski saab selle seadistada graafiku kohale % aega veedetud. Piisab selle lülitamisest Keskmine aeg päringu kohta tüübi järgi… ja nüüd vaatab meile vastu tuttav graafik!

Miks on Datadog eelistanud teistsugust graafikut — on meie jaoks mõistatus. Pettumus oli ka see, et süsteem ei mäleta kasutaja valiku (erinevalt mõlemast konkurendist), seega päästab ainult kasutajapaneelide loomine.

Küll aga rõõmustas Datadog võimalus liikuda nende graafikute kaudu seotud serverite mõõdikutele, lugeda logisid ja hinnata veebiserveri (Gunicorn) koormust. Peaaegu nagu New Relicis… ja isegi natuke rohkem (logid)!

Graafikute all on tehingud, mis on täielikult analoogsed New Relici omadega:

Datadogis nimetatakse tehinguid ressurssideks. Saame sorteerida kontrollerid päringute arvu, keskmise vastuseaja ja valitud ajavahemiku maksimaalse aja põhjal.

Ressursse saab avada ja näha kõike seda, mida oleme juba New Relicis jälginud:

Saadaval on nii ressursi statistika, alustatud sisekutsed, kui ka päringute näidised, mida saab sorteerida vastuskoodi järgi… Muide, see sorteerimine meeldis meie inseneridele väga.

Iga Datadogi ressursi näidet saab avada ja uurida:

Kuvatakse päringu parameetrid, iga komponendi kulutatud aja kokkuvõtte diagramm ja vesiputouvi diagramm, kus on nähtavad kutsete järjekord. Samuti on saadaval vahetus puustruktuuri diagrammi vaate vahel:

Ja huvitav on vaadata ka hosti koormust, millel päring tehti, ja vaadata päringu logisid.

Suurepärane integreerimine!

Võib tekkida küsimus, kus on vahelehed Andmebaasid ja External Services, nagu New Relicis. Siin neid ei ole: kuna Datadog jagab rakenduse komponentideks, loetakse PostgreSQL erinevaks teenuseks, ja väljaspool teenuseid tuleb otsida aws.storage (sama kehtib ka iga muu väline teenus, millega rakendus ühendust võtab).

Siin on näide postgres:

Sisuliselt on kõik see, mida me soovisime:

On selgelt näha, millisest "teenusest" pärineb päring.

Ei tee paha meenutada, et Datadog integreerub suurepäraselt NGINX Ingressiga ja võimaldab läbi jälgida päringu teekonda klastrisse ning võimaldab vastu võtta statsd mõõdikud, koguda logisid ja hostide mõõdikuid.

Suur pluss Datadogi juures on see, et tema hind koosneb infrastruktuuri jälgimisest, APM-ist, logihalduse ja Synthetics testi, st plaani on paindlikult võimalik valida.

2. Atatus

Meeskond Atatus väidab, et nende teenus on "samamoodi nagu New Relic, kuid parem". Vaadakem, kas see on tõsi.

Peamenüü näeb tõepoolest sarnane välja, kuid rakenduses kasutatavaid Redis ja memcached ei õnnestunud tuvastada.

APM valib vaikimisi kõik tehingud, ehkki tavaliselt on vajalikud ainult veebitehingud. Nagu Datadogis, ei ole võimalik peamenüüst liikuda soovitud teenusele. Veelgi enam, tehingud asuvad loendis pärast vigu, mis APM-i puhul ei tundu eriti loogiline.

Tehingud Atatuses näevad maksimaalselt välja nagu New Relicis. Miinus — ei ole kohe näha dünaamikat iga kontrolleri jaoks. Selle leidmine peab toimuma kontrollerite tabelis, sorteerides läbi Enim kulutatud aeg:

Tuttav kontrollerite nimekiri on saadaval vahekaardil Uuring:

See tabel meenutab veidi Datadogi ja on rohkem meelepärane kui sama New Relicis.

Iga tehingu saab avada ja näha, millega rakendus tegeles:

Menüü sarnaneb rohkem Datadogile: seal on päringute arv, ülevaade kõigist kutsetest. Ülemine paneel pakub veaparand vana HTTP tõrked ja aeglaste päringute näidiseid Seansi jäljed:

Kui liikuda tehingusse, on nähtav näide jäljest, saab saada loendi päringutest andmebaasi ja vaadata päringu päiseid. Kõik on sarnane New Relicile:

Üldiselt, Atatus pakkus põhjalikke jälgi — ilma tüüpiliste New Relici kutsetelekkimisteta mälestuste plokkidesse:

Kuid siit puudub filter, mis (nagu New Relicis) eemaldas ülikiired päringud (<5ms). Teisest küljest meeldis tehingu lõppvastuse kuvamine (edukalt või viga).

Paneel Andmebaasid aitab uurida välistest andmebaasidest päringu tegemise aspekte. Tuletan meelde, et Atatus leidis ainult PostgreSQL ja MySQL, kuigi projektis on kasutusel veel Redis ja memcached.

Päringud sorteeritakse tuttavate kriteeriumide järgi: esinemissagedus, keskmine vastamisaeg ja nii edasi. Eraldi tasub mainida aeglasemate päringute vahekaart — see on väga mugav. Veelgi enam, andmed selles vahekaardis PostgreSQL-i kohta kattuvad laienduse andmetega. pg_stat_statements — suurepärane tulemus!

Vahekaart Välistingimused on täielikult identne andmebaasidega.

Järeldused

Mõlemad esitletud tööriistad on oma rollis APM-is hästi esinenud. Igaüks neist võib pakkuda vajaliku miinimumi. Üldiselt võib meie muljeid kokku võtta järgmiselt:

Datadog

Plussid:

• mugav hinnakujundus (APM maksab 31 USD hosti kohta);
• näitas end Pythoniga suurepäraselt;
• võimalus integreerida OpenTracinguga
• integreerimine Kubernetesega;
• integreerimine NGINX Ingressiga.

Miinused:

• ainus APM, mis tekitas rakenduse kättesaamatuse mooduli vea tõttu (predis);
• nõrk automaatne instrumentatsioon PHP-le;
• osaliselt kummaline teenuste määratlemine ja nende eesmärk.

Atatus

Plussid:

• sügav instrumentatsioon PHP-le;
• kasutajaliides on sarnane New Relicile.

Miinused:

• ei tööta vanadel operatsioonisüsteemidel (Ubuntu 12.05, CentOS 5);
• nõrk automaatne instrumenteerimine;
• toetab vaid kahte programmeerimiskeelt (Node.js ja PHP);
• liidese aeglane töö.

Arvestades Atatuse hinda 69 USD kuus serveri kohta, eelistaksime pigem Datadogi, mis integreerub suurepäraselt meie vajadustega (veebirakendused K8s-is) ja omab palju kasulikke funktsioone.

P.S.

Lugege ka meie blogist:

• «Rakenduste arendamise tööriistad, mis käivitatakse Kuberneteses»;
• «Kubernetesi pod'ide tõrkeotsimiseks mõeldud kubectl-debug plugin»;
• «Mikroteenused: suurus loeb, isegi kui teil on Kubernetes».

Allikas: habr.com