🥇Ei pelkkä uusi jäännös: katso Datadog ja Atatus

SRE/DevOps-insinöörien ympäristössä ei yllätä ketään, että jonakin päivänä asiakas (tai valvontajärjestelmä) ilmestyy ja ilmoittaa, että "kaikki on menetetty": sivusto ei toimi, maksut eivät mene läpi, elämä rappeutuu. ... Riippumatta siitä, kuinka paljon haluaisit auttaa tällaisessa tilanteessa, sen tekeminen voi olla erittäin vaikeaa ilman yksinkertaista ja ymmärrettävää työkalua. Usein ongelma on piilotettu itse sovelluksen koodiin; sinun on vain lokalisoitava se.

Ja surussa ja ilossa…

Niin tapahtui, että olemme pitkään ja syvästi rakastuneet New Reliciin. Se oli ja on edelleen erinomainen työkalu sovellusten suorituskyvyn seurantaan, ja sen avulla voit myös instrumentoida mikropalveluarkkitehtuuria (agenttinsa avulla) ja paljon muuta. Ja kaikki olisi voinut olla hienoa, ellei palvelun hintapolitiikka olisi muuttunut: se maksaa alkaen 2013 vuodessa kasvoi 3+ kertaa. Lisäksi viime vuodesta lähtien kokeilutilin saaminen edellyttää yhteydenpitoa henkilökohtaisen esimiehen kanssa, mikä vaikeuttaa tuotteen esittelyä mahdolliselle asiakkaalle.

Tavanomainen tilanne: Uutta jäänteitä ei tarvita "pysyvästi", vaan he muistavat sen vasta ongelmien alkaessa. Mutta sinun on silti maksettava säännöllisesti (140 USD per palvelin kuukaudessa), ja automaattisesti skaalautuvassa pilviinfrastruktuurissa summat ovat melko suuria. Vaikka Pay-As-You-Go-vaihtoehto on olemassa, New Relicin käyttöönotto edellyttää, että sovellus on käynnistettävä uudelleen, mikä voi johtaa ongelmallisen tilanteen menettämiseen, jonka vuoksi se aloitettiin. Ei kauan sitten New Relic esitteli uuden tariffisuunnitelman - Välttämättömyydet, - joka ensi silmäyksellä näyttää järkevältä vaihtoehdolta Professionalille... mutta lähemmin tarkasteltuna kävi ilmi, että joitakin tärkeitä toimintoja puuttuu (etenkään siitä ei ole Tärkeimmät tapahtumat, Cross Application Tracing, Hajautettu jäljitys).

Tämän seurauksena aloimme miettiä halvemman vaihtoehdon etsimistä ja valintamme putosi kahteen palveluun: Datadog ja Atatus. Miksi niihin?

Tietoja kilpailijoista

Sanon heti, että markkinoilla on muitakin ratkaisuja. Harkitsimme jopa avoimen lähdekoodin vaihtoehtoja, mutta kaikilla asiakkailla ei ole vapaata kapasiteettia isännöidä itseisännöityjä ratkaisuja... - lisäksi ne vaativat lisähuoltoa. Pari, jonka valitsimme, osoittautui lähimmäksi tarpeisiimme:

sisäänrakennettu ja kehitetty tuki PHP-sovelluksille (asiakkaidemme pino on hyvin monipuolinen, mutta tämä on selkeä johtaja etsittäessä vaihtoehtoa New Relicille);
edullinen hinta (alle 100 USD kuukaudessa isäntä kohden);
automaattinen instrumentointi;
integrointi Kubernetesiin;
Samankaltaisuus New Relic -liittymän kanssa on huomattava plussa (koska insinöörimme ovat tottuneet siihen).

Siksi alkuvalintavaiheessa poistimme useita muita suosittuja ratkaisuja, ja erityisesti:

Tideways, AppDynamics ja Dynatrace - kustannuksia vastaan;
Stackify on estetty Venäjän federaatiossa ja näyttää liian vähän tietoja.

Loppuosa artikkelista on rakennettu siten, että kyseessä olevat ratkaisut esitellään ensin lyhyesti, minkä jälkeen kerron tyypillisestä vuorovaikutuksestamme New Relicin kanssa ja kokemuksista/vaikutelmista vastaavien toimintojen suorittamisesta muissa palveluissa.

Valittujen kilpailijoiden esittely

Про uusi Relic, luultavasti kaikki ovat kuulleet? Tämä palvelu aloitti kehitystyönsä yli 10 vuotta sitten, vuonna 2008. Olemme käyttäneet sitä aktiivisesti vuodesta 2012 lähtien, eikä meillä ole ollut ongelmia integroida todella paljon sovelluksia PHP:llä, Rubylla ja Pythonilla, ja meillä on myös kokemusta integroinnista C#:n ja Go:n kanssa. Palvelun tekijöillä on ratkaisuja sovellusten valvontaan, infrastruktuuriin, mikropalveluinfrastruktuurien jäljittämiseen, luotuja käteviä sovelluksia käyttäjän laitteille ja paljon muuta.

New Relic -agentti toimii kuitenkin patentoiduilla protokollilla eikä tue OpenTracingia. Kehittynyt instrumentointi vaatii muokkauksia erityisesti New Relicille. Lopuksi, Kubernetes-tuki on vielä kokeellista.

Aloitti kehittämisen vuonna 2010 Datakoira näyttää huomattavasti kiinnostavammalta kuin New Relic juuri Kubernetes-ympäristöissä käytettäessä. Erityisesti se tukee integraatiota NGINX Ingressin, lokien keräämisen, statsd- ja OpenTracing-protokollien kanssa, mikä mahdollistaa käyttäjän pyynnön seuraamisen hetkestä, jolloin se on yhdistetty sen valmistumiseen, sekä löytää lokit tälle pyynnölle (molemmat verkkopalvelimen puolella ja kuluttajalle).

Datadogia käytettäessä havaitsimme, että se joskus rakensi mikropalvelukartan väärin ja joitain teknisiä puutteita. Se esimerkiksi tunnisti väärin palvelutyypin (käsittelee Djangoa välimuistipalveluksi) ja aiheutti 500 virhettä PHP-sovelluksessa, joka käytti suosittua Predis-kirjastoa.

Atatus — nuorin soitin; palvelu otettiin käyttöön vuonna 2014. Sen markkinointibudjetti on selvästi lueteltuja kilpailijoita huonompi, maininnat ovat paljon harvinaisempia. Itse työkalu on kuitenkin hyvin samanlainen kuin New Relic, ei vain ominaisuuksiltaan (APM, selaimen valvonta jne.), vaan myös ulkonäöltään.

Merkittävä haittapuoli on, että se tukee vain Node.js:ää ja PHP:tä. Toisaalta se on toteutettu huomattavasti paremmin kuin Datadog. Toisin kuin jälkimmäinen, Atatus ei vaadi sovelluksia tekemään muutoksia tai lisäämään koodiin lisätarroja.

Kuinka työskentelemme New Relicin kanssa

Katsotaanpa nyt, kuinka yleisesti käytämme New Reliciä. Oletetaan, että meillä on ongelma, joka kaipaa ratkaisua:

Se on helppo nähdä kaaviosta tilkka - Analysoidaan sitä. New Relicissä verkkotapahtumat valitaan heti verkkosovellukselle, kaikki komponentit näkyvät suorituskykykaaviossa, on virheprosentti-, pyyntömäärä-paneelit... Tärkeintä on, että suoraan näistä paneeleista voit siirtyä erilaisten välillä. sovelluksen osia (esimerkiksi MySQL:n napsauttaminen johtaa tietokantaosioon).

Koska tarkasteltavassa esimerkissä näemme aktiivisuuden nousun PHP, napsauta tätä kaaviota ja siirry automaattisesti kohtaan Liiketoimet:

Lista tapahtumista, jotka ovat pääosin MVC-mallin ohjaimia, on jo lajiteltu Eniten aikaa vievää, mikä on erittäin kätevää: näemme heti, mitä sovellus tekee. Tässä on esimerkkejä pitkistä kyselyistä, jotka New Relic kerää automaattisesti. Lajittelua vaihtamalla löydät helposti:

eniten ladattu sovellusohjain;
useimmin pyydetty ohjain;
ohjaimista hitain.

Lisäksi voit laajentaa jokaista tapahtumaa ja nähdä, mitä sovellus teki koodin suoritushetkellä:

Lopuksi sovellus tallentaa esimerkkejä pitkien pyyntöjen jäljistä (ne, jotka kestävät yli 2 sekuntia). Tässä paneeli pitkälle tapahtumalle:

Voidaan nähdä, että kaksi menetelmää vie paljon aikaa, ja samalla näytetään myös pyynnön suoritusaika, sen URI ja domain. Hyvin usein tämä auttaa löytämään pyynnön lokeista. Menossa Jäljitystiedot, näet, mistä näitä menetelmiä kutsutaan:

Ja Tietokantakyselyt — arvioida kyselyt tietokantoihin, jotka suoritettiin sovelluksen ollessa käynnissä:

Tämän tiedon avulla voimme arvioida, miksi sovellus hidastuu, ja tehdä yhteistyötä kehittäjän kanssa strategian ratkaisemiseksi ongelman ratkaisemiseksi. Todellisuudessa New Relic ei aina anna selkeää kuvaa, mutta se auttaa valitsemaan tutkimuksen vektorin:

pitkä PDO::Construct johti meidät pgpollin outoon toimintaan;
epävakaus ajan myötä Memcache::Get ehdotti, että virtuaalikone oli määritetty väärin;
epäilyttävästi pidentynyt mallin käsittelyaika johti sisäkkäiseen silmukkaan, joka tarkastaa 500 avatarin läsnäolon objektin tallennustilassa;
jne…

Sattuu myös niin, että koodin suorittamisen sijaan jotain ulkoiseen tiedontallennukseen liittyvää kasvaa päänäytölle - ja sillä ei ole väliä mitä se tulee olemaan: Redis vai PostgreSQL - ne ovat kaikki piilossa välilehdellä Tietokannat.

Voit valita tietyn pohjan tutkimukselle ja lajitella kyselyitä - samalla tavalla kuin Tapahtumat-kohdassa. Ja menemällä Pyyntö-välilehdelle voit nähdä, kuinka monta kertaa tämä pyyntö esiintyy kussakin sovellusohjaimessa, ja myös arvioida, kuinka usein sitä kutsutaan. Se on erittäin mukava:

Välilehti sisältää samanlaisia tietoja Ulkoiset palvelut, joka piilottaa pyynnöt ulkoisille HTTP-palveluille, kuten pääsyn objektien tallennustilaan, tapahtumien lähettämiseen vartijalle tai vastaavaa. Välilehden sisältö on täysin samanlainen kuin tietokannat:

Kilpailijat: mahdollisuudet ja vaikutelmat

Nyt mielenkiintoisinta on verrata New Relicin ominaisuuksia kilpailijoiden tarjontaan. Valitettavasti emme pystyneet testaamaan kaikkia kolmea työkalua yhden tuotantovaiheessa olevan sovelluksen yhdellä versiolla. Yritimme kuitenkin vertailla tilanteita/kokoonpanoja, jotka olivat mahdollisimman identtisiä.

1. Datakoira

Datadog tervehtii meitä paneelilla, jossa on palveluseinä:

Se yrittää jakaa sovelluksia komponenteiksi/mikropalveluihin, joten esimerkki Django -sovelluksessa näemme 2 yhteyttä PostgreSQL:ään (defaultdb и postgres), sekä selleri, Redis. Datadogin kanssa työskentely edellyttää minimaalista tietoa MVC:n periaatteista: sinun on ymmärrettävä, mistä käyttäjien pyynnöt yleensä tulevat. Tämä yleensä auttaa palveluiden kartta:

Muuten, New Relicissä on jotain vastaavaa:

... ja niiden kartta on mielestäni tehty yksinkertaisemmiksi ja selkeämmiksi: se ei näytä yhden sovelluksen komponentteja (mikä tekisi siitä liian yksityiskohtaista, kuten Datadogin tapauksessa), vaan vain tietyt palvelut tai mikropalvelut.

Palataan Datadogiin: palvelukartalta näemme, että käyttäjäpyyntöjä tulee Djangoon. Mennään Django-palveluun ja katsotaan vihdoin mitä odotimme:

Valitettavasti tässä ei ole oletuksena kaaviota Verkkokaupan aika, samanlainen kuin mitä näemme New Relic -pääpaneelissa. Se voidaan kuitenkin määrittää aikataulun sijasta % käytetystä ajasta. Riittää kun vaihtaa siihen Keskimääräinen aika pyyntöä kohti tyypin mukaan... ja nyt tuttu kaavio katsoo meitä!

Miksi Datadog valitsi toisenlaisen kaavion, on meille mysteeri. Toinen turhauttava asia on, että järjestelmä ei muista käyttäjän valintaa (toisin kuin molemmat kilpailijat), ja siksi ainoa ratkaisu on luoda mukautettuja paneeleita.

Mutta olin tyytyväinen Datadogin kykyyn siirtyä näistä kaavioista toisiinsa liittyvien palvelimien mittareihin, lukea lokit ja arvioida verkkopalvelimen käsittelijöiden (Gunicorn) kuormitusta. Kaikki on melkein sama kuin New Relicissä... ja jopa vähän enemmän (tukit)!

Kaavioiden alla ovat tapahtumat, jotka ovat täysin samanlaisia kuin New Relic:

Datadogissa tapahtumia kutsutaan resursseja. Voit lajitella ohjaimet pyyntöjen lukumäärän, keskimääräisen vastausajan ja valitun ajanjakson enimmäisajan mukaan.

Voit laajentaa resurssia ja nähdä kaiken, mitä olemme jo havainneet New Relicissä:

Resurssista on tilastoja, yleinen luettelo sisäisistä puheluista ja esimerkkejä pyynnöistä, jotka voidaan lajitella vastauskoodin mukaan... Muuten, suunnittelijamme pitivät tästä lajittelusta todella paljon.

Mikä tahansa Datadogin esimerkkiresurssi voidaan avata ja tutkia:

Pyyntöparametrit, yhteenvetokaavio kuhunkin komponenttiin käytetystä ajasta ja vesiputouskaavio, joka näyttää puhelujen järjestyksen, esitetään. Voit myös vaihtaa vesiputouskartan puunäkymään:

Ja mielenkiintoisin asia on tarkastella sen isännän kuormitusta, jolla pyyntö suoritettiin, ja tarkastella pyyntölokeja.

Hieno integraatio!

Saatat ihmetellä, missä välilehdet ovat Tietokannat и Ulkoiset palvelut, kuten New Relicissä. Täällä niitä ei ole: koska Datadog hajottaa sovelluksen komponentteihin, PostgreSQL otetaan huomioon erillinen palvelu, ja ulkoisten palvelujen sijaan se kannattaa etsiä aws.storage (se on samanlainen kaikissa muissa ulkoisissa palveluissa, joita sovellus voi käyttää).

Tässä esimerkki kanssa postgres:

Pohjimmiltaan siellä on kaikki mitä halusimme:

Näet, mistä "palvelusta" pyyntö tuli.

Ei olisi väärin muistuttaa, että Datadog integroituu täydellisesti NGINX Ingressin kanssa ja mahdollistaa päästä päähän -jäljityksen siitä hetkestä lähtien, kun pyyntö saapuu klusteriin, ja voit myös vastaanottaa tilastotietoja, kerätä lokeja ja isäntämittareita. .

Datadogin valtava plussa on sen hinta on muotoutumassa infrastruktuurin valvonnasta, APM:stä, Log Managementista ja Synthetics-testistä, ts. Voit valita suunnitelmasi joustavasti.

2.Atatus

Atatus-tiimi väittää, että heidän palvelunsa on "sama kuin New Relic, mutta parempi". Katsotaan onko asia todella näin.

Pääpaneeli näyttää samanlaiselta, mutta sovelluksessa käytettyä Redistä ja välimuistia ei voitu määrittää.

APM valitsee kaikki tapahtumat oletuksena, vaikka yleensä tarvitaan vain verkkotapahtumia. Kuten Datadog, pääpaneelista ei voi navigoida haluttuun palveluun. Lisäksi tapahtumat luetellaan virheiden jälkeen, mikä ei vaikuta kovin loogiselta APM:lle.

Atatus-tapahtumissa kaikki on mahdollisimman samanlaista kuin New Relic. Huono puoli on, että kunkin ohjaimen dynamiikka ei ole heti näkyvissä. Sinun täytyy etsiä se ohjaintaulukosta lajittelemalla Eniten aikaa vietetty:

Tavallinen luettelo ohjaimista on saatavilla välilehdellä Tutkia:

Jollain tapaa tämä taulukko muistuttaa Datadogia ja pidän siitä paremmin kuin vastaavasta New Relicissä.

Voit laajentaa jokaista tapahtumaa ja nähdä, mitä sovellus teki:

Paneeli muistuttaa myös enemmän Datadogia: siellä on useita pyyntöjä, yleiskuva puheluista. Yläpaneelissa on virhevälilehti HTTP-virheet ja esimerkkejä hitaista kyselyistä Istuntojäljet:

Jos siirryt tapahtumaan, näet esimerkin jäljityksestä, voit saada luettelon pyynnöistä tietokantaan ja tarkastella pyyntöjen otsikoita. Kaikki on samanlaista kuin New Relic:

Yleisesti ottaen Atatus oli tyytyväinen yksityiskohtaisiin jälkiin - ilman tyypillistä New Relic -kutsujen liimaamista muistutuslohkoon:

Siitä puuttuu kuitenkin suodatin, joka (kuten New Relic) katkaisisi erittäin nopeat pyynnöt (<5 ms). Toisaalta pidin lopullisen tapahtumavastauksen (menestys tai virhe) näyttämisestä.

paneeli Tietokannat auttaa sinua tutkimaan sovelluksen tekemiä pyyntöjä ulkoisiin tietokantoihin. Muistutan, että Atatus löysi vain PostgreSQL:n ja MySQL:n, vaikka Redis ja memcached ovat myös mukana projektissa.

Pyynnöt lajitellaan tavanomaisten kriteerien mukaan: vastaustaajuus, keskimääräinen vastausaika ja niin edelleen. Haluaisin myös mainita välilehden, jossa on hitaimpia kyselyitä - se on erittäin kätevä. Lisäksi tämän välilehden tiedot PostgreSQL:lle olivat samat kuin laajennuksen tiedot pg_stat_statements - erinomainen tulos!

Välilehti Ulkoiset pyynnöt täysin identtinen tietokantojen kanssa.

Tulokset

Molemmat esitellyt työkalut toimivat hyvin APM:n roolissa. Jokainen heistä voi tarjota vaaditun vähimmäismäärän. Näkemyksemme voidaan tiivistää lyhyesti seuraavasti:

Datakoira

Plussat:

kätevä tariffiaikataulu (APM maksaa 31 USD per isäntä);
toimi hyvin Pythonin kanssa;
Mahdollisuus integroida OpenTracingiin
integrointi Kubernetesiin;
integrointi NGINX Ingressin kanssa.

Miinukset:

ainoa APM, joka aiheutti sen, että sovellus ei ollut käytettävissä moduulivirheen vuoksi (predis);
heikko PHP automaattinen instrumentointi;
osittain outo määritelmä palveluista ja niiden tarkoituksesta.

Atatus