🥇Mitte uus reliikvia üksi: pilk Datadog ja Atatus

SRE/DevOpsi inseneride keskkonnas ei üllata kedagi, kui ühel päeval ilmub välja klient (või jälgimissüsteem) ja teatab, et “kõik on kadunud”: sait ei tööta, maksed ei käi läbi, elu laguneb. ... Olenemata sellest, kui väga soovite sellises olukorras aidata, võib seda ilma lihtsa ja arusaadava tööriistata olla väga raske teha. Sageli on probleem peidetud rakenduse koodis endas; peate selle lihtsalt lokaliseerima.

Ja kurbuses ja rõõmus…

Juhtus nii, et oleme New Relic’i ammu ja sügavalt armunud. See oli ja jääb suurepäraseks tööriistaks rakenduste jõudluse jälgimiseks, samuti võimaldab teil instrumenteerida mikroteenuse arhitektuuri (kasutades selle agenti) ja palju-palju muud. Ja kõik oleks võinud olla suurepärane, kui poleks olnud muudatusi teenuse hinnapoliitikas: see maksma alates 2013 aastast kasvas 3+ korda. Lisaks eeldab eelmisest aastast proovikonto saamine suhtlemist isikliku halduriga, mistõttu on toote esitlemine potentsiaalsele kliendile keeruline.

Tavaline olukord: Uut reliikviat pole vaja “alaliselt”, nad mäletavad seda alles siis, kui probleemid algavad. Kuid ikkagi peate regulaarselt maksma (140 USD serveri kohta kuus) ja automaatselt skaleeruvas pilveinfrastruktuuris on summad üsna suured. Kuigi on olemas suvand Pay-As-You-Go, nõuab New Relic lubamine teil rakenduse taaskäivitamist, mis võib põhjustada probleemse olukorra kadumise, mille tõttu see kõik käivitati. Mitte kaua aega tagasi tutvustas New Relic uut tariifiplaani - Esmavajalik, - mis esmapilgul tundub mõistlik alternatiiv Professionalile... kuid lähemal uurimisel selgus, et mõned olulised funktsioonid on puudu (eelkõige pole sellel Peamised tehingud, Rakendustevaheline jälgimine, Distributed Tracing).

Selle tulemusena hakkasime mõtlema odavama alternatiivi otsimisele ja meie valik langes kahele teenusele: Datadog ja Atatus. Miks neile?

Konkurentide kohta

Ütlen kohe ära, et turul on ka teisi lahendusi. Kaalusime isegi avatud lähtekoodiga võimalusi, kuid mitte igal kliendil pole vaba mahtu isehostitud lahenduste majutamiseks... - lisaks vajavad need täiendavat hooldust. Meie valitud paar osutus kõige lähedasemaks meie vajadused:

sisseehitatud ja arendatud tugi PHP rakendustele (meie klientide pinu on väga mitmekesine, kuid see on New Relic'ile alternatiivi otsimise kontekstis selge liider);
taskukohane hind (alla 100 USD kuus hosti kohta);
automaatsed mõõteriistad;
integreerimine Kubernetesiga;
Sarnasus New Relic liidesega on märgatav pluss (kuna meie insenerid on sellega harjunud).

Seetõttu välistasime esialgses valikuetapis mitmed muud populaarsed lahendused, eelkõige:

Tideways, AppDynamics ja Dynatrace – kulu eest;
Stackify on Vene Föderatsioonis blokeeritud ja näitab liiga vähe andmeid.

Ülejäänud artikkel on üles ehitatud nii, et esmalt tutvustatakse lühidalt kõnealuseid lahendusi, misjärel räägin meie tüüpilisest suhtlusest New Reliciga ja kogemustest/muljetest sarnaste toimingute tegemisel teistes teenustes.

Valitud võistlejate esitlus

edasi uus reliikvia, ilmselt on kõik kuulnud? See teenus alustas oma arendamist enam kui 10 aastat tagasi, 2008. aastal. Oleme seda aktiivselt kasutanud alates 2012. aastast ning meil pole olnud probleeme tõeliselt suure hulga rakenduste integreerimisega PHP-s, Ruby-s ja Pythonis, samuti on meil kogemusi integreerimisel C# ja Go-ga. Teenuse autoritel on lahendused rakenduste jälgimiseks, taristu, mikroteenuste infrastruktuuride jälgimiseks, loodud mugavad rakendused kasutajaseadmetele ja palju muud.

New Relic agent töötab aga patenteeritud protokollidel ega toeta OpenTracingut. Täiustatud mõõteriistad nõuavad muudatusi spetsiaalselt uue reliikvia jaoks. Lõpuks on Kubernetese tugi endiselt eksperimentaalne.

Alustas oma arendamist 2010. aastal Andmebaas Tundub, et just Kubernetese keskkondades kasutamise osas tundub New Relic’ist märgatavalt huvitavam. Eelkõige toetab see integreerimist NGINX Ingressi, logide kogumise, statsd ja OpenTracingi protokollidega, mis võimaldab jälgida kasutajapäringut alates hetkest, mil see ühendatakse kuni lõpetamiseni, samuti leida selle päringu logisid (mõlemad veebiserveri poolel ja tarbijale).

Datadogi kasutamisel avastasime, et mõnikord ehitas see mikroteenuste kaardi valesti ja tehnilisi puudusi. Näiteks tuvastas see valesti teenuse tüübi (ajades Django vahemällu salvestamise teenuseks) ja põhjustas populaarset Predise teeki kasutavas PHP-rakenduses 500 viga.

Atatus — noorim pill; teenus käivitati 2014. aastal. Selle turunduseelarve on selgelt madalam loetletud konkurentidest, mainimisi on palju vähem. Tööriist ise on aga väga sarnane New Relic’ile mitte ainult oma võimaluste (APM, Browser Monitoring jne), vaid ka välimuselt.

Märkimisväärne puudus on see, et see toetab ainult Node.js-i ja PHP-d. Teisest küljest on see rakendatud märgatavalt paremini kui Datadog. Erinevalt viimasest ei nõua Atatus rakendustelt muudatusi ega koodile täiendavate siltide lisamist.

Kuidas me New Reliciga töötame

Nüüd vaatame, kuidas me üldiselt uut reliikviat kasutame. Oletame, et meil on probleem, mis vajab lahendust:

Seda on graafikult lihtne näha pritsima - Analüüsime seda. New Relic'is valitakse veebitehingud kohe veebirakenduse jaoks, kõik komponendid on näidatud jõudlusgraafikus, on veamäära, taotluste määra paneelid... Kõige olulisem on see, et otse nendelt paneelidelt saab liikuda erinevate vahel. rakenduse osad (näiteks MySQL-i klõpsamine viib andmebaasi sektsiooni).

Kuna vaadeldavas näites näeme aktiivsuse tõusu PHP, klõpsake sellel diagrammil ja minge automaatselt lehele Tehingud:

Tehingute loend, mis on sisuliselt MVC mudeli kontrollerid, on juba sorteeritud Kõige aeganõudvam, mis on väga mugav: näeme kohe, mida rakendus teeb. Siin on näited pikkadest päringutest, mille New Relic automaatselt kogub. Sortimist vahetades on lihtne leida:

enim koormatud rakenduskontroller;
kõige sagedamini nõutav kontroller;
kontrolleritest kõige aeglasem.

Lisaks saate iga tehingut laiendada ja vaadata, mida rakendus koodi käivitamise ajal tegi:

Lõpuks salvestab rakendus pikkade päringute jälgede näiteid (need, mis võtavad rohkem kui 2 sekundit). Siin on pika tehingu paneel:

On näha, et kaks meetodit võtavad palju aega ja samal ajal näidatakse ka päringu täitmise aega, selle URI-d ja domeeni. Väga sageli aitab see päringu logidest üles leida. Lähen Jälje üksikasjad, näete, kust neid meetodeid kutsutakse:

Ja Andmebaasi päringud — hinnata päringuid andmebaasidele, mis käivitati rakenduse töötamise ajal:

Nende teadmistega saame hinnata, miks rakendus aeglustub, ja töötada koos arendajaga välja strateegia probleemi lahendamiseks. Tegelikkuses ei anna uus reliikvia alati selget pilti, kuid aitab valida uurimise vektori:

pikk PDO::Construct viis meid pgpolli kummalise toimimiseni;
ebastabiilsus aja jooksul Memcache::Get tegi ettepaneku, et virtuaalmasin on valesti konfigureeritud;
mallide töötlemise kahtlaselt pikenenud aeg viis pesastatud silmuseni, mis kontrollis objektimälus 500 avatari olemasolu;
jne…

Samuti juhtub, et koodi täitmise asemel kasvab põhiekraanil midagi välise andmesalvestusega seotud – ja pole vahet, mis see saab: Redis või PostgreSQL – need on kõik vahekaardil peidetud. Andmebaasid.

Saate valida uurimise jaoks konkreetse aluse ja sortida päringuid – sarnaselt sellele, kuidas seda tehakse tehingutes. Ja minnes vahekaardile Päring, näete, mitu korda see päring igas rakenduse kontrolleris esineb, ja hinnata ka seda, kui sageli seda kutsutakse. See on väga mugav:

Vahekaart sisaldab sarnaseid andmeid Välisteenused, mis peidab päringuid välistele HTTP-teenustele, nagu näiteks juurdepääs objektide salvestusruumile, sündmuste saatmine valvurile vms. Vahekaardi sisu on täiesti sarnane andmebaasidega:

Konkurendid: võimalused ja muljed

Nüüd on kõige huvitavam võrrelda New Relici võimalusi konkurentide pakutavaga. Kahjuks ei saanud me kõiki kolme tööriista ühe tootmistöös oleva rakenduse ühes versioonis testida. Siiski proovisime võrrelda olukordi/konfiguratsioone, mis olid võimalikult identsed.

1. Andmekoer

Datadog tervitab meid paneeliga, millel on teenuste sein:

See proovib jagada rakendusi komponentideks/mikroteenusteks, nii et näites Django rakenduses näeme 2 ühendust PostgreSQL-iga (defaultdb и postgres), samuti seller, Redis. Datadogiga töötamine eeldab, et teil on minimaalsed teadmised MVC põhimõtetest: peate mõistma, kust kasutajate taotlused üldiselt pärinevad. See tavaliselt aitab teenuste kaart:

Muide, uues reliikvias on midagi sarnast:

... ja nende kaart on minu arvates tehtud lihtsamaks ja selgemaks: see ei näita ühe rakenduse komponente (mis muudaks selle liiga detailseks, nagu Datadogi puhul), vaid ainult konkreetseid teenuseid või mikroteenuseid.

Pöördume tagasi Datadogi juurde: teeninduskaardilt näeme, et kasutajate päringud tulevad Djangole. Läheme Django teenindusse ja vaatame lõpuks, mida ootasime:

Kahjuks siin vaikimisi graafikut pole Veebitehingu aeg, mis on sarnane sellele, mida näeme põhipaneelil New Relic. Seda saab aga ajakava asemel konfigureerida % kulutatud ajast. Piisab selle ümberlülitamisest Keskmine aeg päringu kohta tüübi järgi... ja nüüd vaatab meile vastu tuttav graafik!

Miks Datadog teistsuguse diagrammi valis, on meie jaoks mõistatus. Teine masendav asi on see, et süsteem ei mäleta kasutaja valikut (erinevalt mõlemast konkurendist) ja seetõttu on ainus lahendus luua kohandatud paneelid.

Kuid ma olin rahul Datadogi võimalusega lülituda nendelt graafikutelt seotud serverite mõõdikutele, lugeda logisid ja hinnata veebiserveri töötlejate (Gunicorn) koormust. Kõik on peaaegu sama, mis uues reliikvias... ja isegi natuke rohkem (palgid)!

Graafiku all on tehingud, mis on täiesti sarnased uue reliikviaga:

Datadogis nimetatakse tehinguid ressursse. Saate kontrollereid sortida päringute arvu, keskmise reageerimisaja ja valitud ajavahemiku jooksul kulutatud maksimaalse aja järgi.

Saate ressurssi laiendada ja näha kõike, mida oleme uues reliikvias juba täheldanud:

Seal on statistika ressursi kohta, üldistatud sisekõnede loend ja näited päringutest, mida saab vastusekoodi järgi sorteerida... Muide, meie inseneridele see sorteerimine väga meeldis.

Datadogi mis tahes näidisressurssi saab avada ja uurida:

Esitatakse päringu parameetrid, igale komponendile kulutatud aja kokkuvõtlik diagramm ja juga diagramm, mis näitab kõnede jada. Saate lülituda ka juga diagrammi puuvaatele:

Ja kõige huvitavam on vaadata selle hosti koormust, millel taotlus täideti, ja taotluste logide vaatamine.

Suurepärane integratsioon!

Võite küsida, kus need vahelehed on Andmebaasid и Välisteenused, nagu uues reliikvias. Siin neid pole: kuna Datadog jagab rakenduse komponentideks, võetakse arvesse PostgreSQL eraldi teenusja välisteenuste asemel tasub seda otsida aws.storage (see on sarnane kõigi teiste välisteenustega, millele rakendus pääseb juurde).

Siin on näide koos postgres:

Sisuliselt on kõik, mida tahtsime:

Näete, millisest "teenusest" päring tuli.

Poleks vale teile meelde tuletada, et Datadog integreerub suurepäraselt NGINX Ingressiga ja võimaldab teil teostada täielikku jälgimist hetkest, kui päring klastrisse saabub, ning samuti võimaldab teil saada statsd-mõõdikuid, koguda logisid ja hostimõõdikuid. .

Datadogi suur pluss on selle hind on kuju võtmas taristu monitooringust, APM-ist, Log Managementist ja Synthetics testist, s.o. Saate valida oma plaani paindlikult.

2.Atatus

Atatuse meeskond väidab, et nende teenus on "sama, mis uus reliikvia, kuid parem". Vaatame, kas see on tõesti nii.

Põhipaneel näeb küll sarnane välja, kuid rakenduses kasutatud Redist ja memcachedit ei olnud võimalik kindlaks teha.

APM valib vaikimisi kõik tehingud, kuigi tavaliselt on vaja ainult veebitehinguid. Nagu Datadog, ei saa peapaneelilt soovitud teenusele navigeerida. Veelgi enam, tehingud on loetletud vigade järel, mis ei tundu APM-i jaoks kuigi loogiline.

Atatuse tehingutes on kõik võimalikult sarnane uue reliikviaga. Negatiivne külg on see, et iga kontrolleri dünaamikat pole kohe näha. Seda tuleb otsida kontrolleri tabelist sorteerides Kõige ajakulu:

Tavaline kontrollerite loend on saadaval vahekaardil vaata:

Mõnes mõttes meenutab see tabel Datadogi ja mulle meeldib see rohkem kui New Relic samalaadne.

Saate iga tehingut laiendada ja vaadata, mida rakendus tegi:

Paneel meenutab ka rohkem Datadogi: päringuid on hulk, kõnede üldpilt. Ülemisel paneelil on veakaart HTTP tõrked ja näiteid aeglastest päringutest Seansi jäljed:

Kui lähete tehingu juurde, näete jälje näidet, saate andmebaasi päringute loendi ja vaadata päringu päiseid. Kõik sarnaneb uue reliikviaga:

Üldiselt oli Atatus üksikasjalike jälgedega rahul – ilma tüüpilise uue reliikvia kõnede meeldetuletusplokkide liimimiseta:

Sellel puudub aga filter, mis (nagu New Relic) katkestaks ülikiired päringud (<5 ms). Teisest küljest meeldis mulle tehingu lõpliku vastuse (edu või viga) kuvamine.

Paneel Andmebaasid aitab teil uurida päringuid välistele andmebaasidele, mida rakendus teeb. Tuletan meelde, et Atatus leidis ainult PostgreSQL ja MySQL, kuigi projektis osalevad ka Redis ja memcached.

Taotlused sorteeritakse tavapäraste kriteeriumide järgi: vastamise sagedus, keskmine reageerimisaeg jne. Tahaksin mainida ka kõige aeglasemate päringutega vahekaarti - see on väga mugav. Veelgi enam, sellel PostgreSQL-i vahekaardil olevad andmed langesid kokku laienduse andmetega pg_stat_statements - suurepärane tulemus!

Tab Välised taotlused täiesti identsed andmebaasidega.

Järeldused

Mõlemad esitatud tööriistad toimisid APM-i rollis hästi. Igaüks neist suudab pakkuda nõutavat miinimumi. Meie muljed võib lühidalt kokku võtta järgmiselt:

Andmebaas

plussid:

mugav tariifigraafik (APM maksab 31 USD hosti kohta);
töötas Pythoniga hästi;
Võimalus integreerida OpenTracinguga
integreerimine Kubernetesiga;
integreerimine NGINX Ingressiga.

miinuseid:

ainus APM, mis põhjustas rakenduse kättesaamatuks muutumise mooduli vea tõttu (predis);
nõrk PHP automaatseade;
osaliselt kummaline teenuste määratlus ja nende eesmärk.

Atatus