Monitooring teenusena: modulaarne süsteem mikroteenuste arhitektuuriks

Täna meie projektis toimivad lisaks monoliitsele koodile ka kümned mikroteenused. Igaüht nendest tuleb jälgida. Selliste mahtude puhul on DevOps-inseneride jõududes keeruline. Oleme välja arendanud jälgimissüsteemi, mis töötab teenusena arendajatele. Nad saavad ise kirjutada mõõdikud jälgimissüsteemi, kasutada neid, luua nende põhjal armatuurlaudu ja ühendada neile häireid, mis aktiveeruvad, kui piirväärtused on saavutatud. DevOps-insenerid on seotud vaid infrastruktuuri ja dokumentatsiooniga.

See postitus on minu esitluse salvestus meie sektori RIT++-l. Paljud palusid meil teha sealt tekstiversioone. Kui olite konverentsil või vaatasite videot, siis ei leia te seal midagi uut. Kõigile teistele — tere tulemast allapoole. Räägin, kuidas me sellise süsteemi juurde jõudsime, kuidas see töötab ja kuidas plaanime seda uuendada.

Minevik: skeemid ja plaanid

Kuidas me jõudsime olemasoleva jälgimissüsteemini? Sellele küsimusele vastamiseks tuleb tagasi minna 2015. aastasse. Nii see siis välja nägi:

Meil oli umbes 24 sõlme, mis vastutasid jälgimise eest. Siin on hulk erinevaid crone, skripte, deemonite, mis mingil moel jälgivad, saadavad sõnumeid, täidavad funktsioone. Mõtlesime, et mida kaugemale, seda vähem on selline süsteem elujõuline. Selle arendamine pole mõistlik: liiga mahukas.
Otsustasime valida need jälgimise elemendid, mida jätame ja arendame, ja need, millest loobume. Nende hulk oli 19. Järele jäid vaid grafiidid, agregaatid ja Grafana armatuurlaudade jaoks. Kuid kuidas näeb uus süsteem välja? Nii:

Meil on mõõdikute salvestus: need on grafiidid, mis põhinevad kiiretel SSD-diskidel, ja teatud agregaatide mõõdikud. Edasi — Grafana armatuurlaudade kuvamiseks ja Moira häirete tõhususe jaoks. Samuti soovisime välja töötada anomaaliate otsimisse süsteemi.

Standard: Jälgimine 2.0

Nii nägid plaanid välja 2015. aastal. Kuid me pidime ette valmistama mitte ainult infrastruktuuri ja teenuse ise, vaid ka dokumentatsiooni selle jaoks. Me töötasime välja ettevõtte standardi, mille nimetasime jälgimiseks 2.0. Millised olid nõuded süsteemile?

• pidev kättesaadavus;
• mõõdikute salvestusintervall = 10 sekundit;
• struktureeritud metrikate ja juhtpaneelide salvestamine;
• SLA > 99,99%
• ürituste metrikate kogumine UDP kaudu (!).

Me vajasime UDP-d, kuna meil on suur liiklus ja sündmuste voog, mis genereerib metrikaid. Kui kirjutada kõik Graphite'i korraga, tahab salvestus kokku kukkuda. Samuti valisime kõigi metrikate jaoks esmaklassilised prefiksid.

Iga prefiks omab mõnda omadust. On metrikad serverite, võrkude, konteinerite, ressursside, rakenduste ja nii edasi. On rakendatud selge, range ja tüpiseeritud filtreerimine, kus me võtame esmaklassilised metrikad ja ülejäänud lihtsalt lükkame kõrvale. Nii me plaanisime seda süsteemi 2015. aastal. Mis on aga reaalsus?

Reaalsus: monitooringu komponentide interaktsiooni skeem

Esiteks jälgime rakendusi: meie PHP-koodi, rakendusi ja mikroteenuseid – sõnaga, kõike, mida meie arendajad kirjutavad. Kõik rakendused saadavad UDP kaudu metrikad koondajale Brubeck (statsd, C-keeles ümber kirjutatud). Tulemuseks oli see, et see osutus sünteetiliste testide tulemusel kõige kiiremaks. Ning see saadab koondatud metrikad Graphite'i kaudu TCP.

Sel on selline metrikate tüüp nagu taimerid. See on äärmiselt mugav asi. Näiteks igakord, kui kasutaja teenusega ühendust võtab, saadate Brubeck'i metrika response time. Kui miljon vastust saabus, antakse koondajale vaid 10 metrikat. Teil on teada tulnud inimeste arv, maksimaalne, minimaalne ja keskmine vastusaeg, mediaan ja 4 persentiili. Seejärel edastatakse andmed Graphite'i ja me näeme neid kõik reaalajas.

Samuti on meil andmete koondamine riistvara, tarkvara, süsteemsete metrikate ja meie vana monitooringusüsteemi Munin jaoks (mis töötas meil kuni 2015. aastani). Kõike seda kogume C-demoniga CollectD (millesse on sisse ehitatud terve hulk erinevaid pluginaid, mis oskab küsida kõiki hostimise süsteemi ressursse, millele see on installitud, lihtsalt määrake konfiguratsioonis, kuhu andmed kirjutada) ja kirjutame andmed Graphite'i kaudu. Samuti toetab see python ja shell-skriptide pluginaid, nii et saate kirjutada oma kohandatud lahendusi: CollectD kogub neid andmeid kohalikult või eemalt hostilt (kui eeldada, et seal on Curl) ja saadab need Graphite'i.

Jätkame: kõik mõõdikud, mida oleme kogunud, saadame Carbon-c-relay'le. See on Carbon Relay Graphitelt, C keeles täiustatud lahendus. See on ruuter, mis kogub endasse kõik mõõdikud, mille me saadame oma aggregeerijatelt, ja suunab need nodidesse. Samuti kontrollib see suunamise etapis mõõdikute kehtivust. Esiteks peavad nad vastama sellele scheemile koos eelliidetega, mida ma varem näitasin, ja teiseks peavad nad olema Graphitele kehtivad. Vastasel juhul visatakse nad välja.

Siis saadab Carbon-c-relay mõõdikud Graphite klastrisse. Kasutame peamise mõõdikute salvestusena Carbon-cache'i, mis on kirjutatud Go-s. Go-carbon ületab oma mitme töötluse tõttu oluliselt Carbon-cache'i jõudlust. See võtab andmed enda alla ja salvestab need kettale kasutades whisperi paketti (tavaline, kirjutatud pythonis). Andmete lugemiseks meie salvestitest kasutame Graphite API-d. See töötab oluliselt kiiremini kui standardne Graphite WEB. Mis juhtub andmetega edasi?

Need lähevad Grafanasse. Peamise andmeallikana kasutame meie Graphite klastreid, pluss meil on Grafana veebiliides mõõdikute kuvamiseks ja armatuurlaudade koostamiseks. Iga teenuse arendaja loob oma armatuuri. Seejärel koostavad nad graafikuid, millel kuvatakse mõõdikud, mida nad oma rakendustest saadavad. Peale Grafana on meil ka SLAM. See on Pythonis kirjutatud demon, mis arvutab SLA-d Graphite andmete põhjal. Nagu ma juba ütlesin, on meil mitu tosinat mikroteenust, millest igaühel on oma nõuded. SLAM-i abil vaatame dokumentatsiooni ja võrdleme seda Graphite'is oleva infoga, kontrollime, kui hästi nõuded vastavad meie teenuste saadavusele.

Jätkame: häirituse jälgimise süsteem. See on organiseeritud tugeva süsteemi, Moira, abil. See on iseseisev, kuna selle all on oma Graphite. Arendatud SКB 'Kontur' poolt, kirjutatud pythonis ja Go-s, täiesti avatud lähtekoodiga. Moira saab endasse kõik sama voogu, mis suundub Graphite'idesse. Kui mingil põhjusel sureb teie salvestus, töötab teie hädahäiresüsteem ikka.

Moira on laotud Kubernetesesse ja see kasutab peamise andmebaasina Redis-serverite klastrit. Tulemuseks on talitlushäirekindel süsteem. See võrdleb mõõdikute voogu triggereid loendiga: kui see ei sisalda nimetusi, siis visatakse mõõdiku andmed minema. Nii suudab see töödelda gigabaite mõõdikute andmeid minutis.

Lisaks integreerisime sellele ettevõtte LDAP-i, mille abil saavad kõik ettevõtte süsteemi kasutajad luua endale teateid olemasolevate (või uute) triggereid põhjal. Kuna Moira sisaldab Graphite'i, toetab see kõiki selle funktsioone. Esiteks võtate rea ja kopeerite selle Grafanasse. Vaadake, kuidas andmed graafikutel kuvatakse. Seejärel võtate selle sama rea ja kopeerite selle Moira-sse. Lisate sellele piirangud ja saate alarme. Kõik see ei nõua mingeid spetsiifilisi teadmisi. Moira suudab genereerida teateid SMS-i, e-posti, Jira, Slack'i kaudu... Samuti toetab see kohandatud skriptide täitmist. Kui tal tekib trigger ja see on seotud kohandatud skripti või binaariga, siis käivitab ta selle ja annab sellele stdin-is JSON-i. Seetõttu peab teie programm selle parsima. Mida te selle JSON-iga teete, on teie otsustada. Kui soovite — saatke see Telegrammi, kui soovite — avage ülesandeid Jira's, tehke mida iganes.

Meie alarmeerimiseks kasutame ka oma arengut — Imagotag. Oleme kohandanud paneeli, mida tavaliselt kasutatakse poodides elektrooniliste hinnasiltide jaoks, meie vajaduste jaoks. Oleme sellele välja toonud Moira triggereid. Seal on näidatud, millises olekus need on ja millal need toimusid. Osa arendusmeeskonnast loobus teavitustest Slack'is ja e-kirjas selle paneeli kasuks.

Kuna oleme progressiivne ettevõte, seetõttu seirasime selles süsteemis ka Kubernetes'i. Lülitasime selle süsteemi läbi Heapsteri, mille paigaldasime klastrisse, mis kogub andmeid ja saadab need Graphite'i. Tulemuseks on järgmine skeem:

Monitooringu komponendid

Siin on linkide loend nende komponentide jaoks, mida kasutasime selle ülesande täitmiseks. Kõik need on avatud lähtekoodiga.

Graphite:

• go-carbon: github.com/lomik/go-carbon
• whisper: github.com/graphite-project/whisper
• graphite-api: github.com/brutasse/graphite-api

Carbon-c-relay:

github.com/grobian/carbon-c-relay

Brubeck:

github.com/github/brubeck

Collectd:

collectd.org

Moira:

github.com/moira-alert

Grafana:

grafana.com

Heapster:

github.com/kubernetes/heapster

Statistika

Ja natuke numbreid selle kohta, kuidas meie süsteem töötab.

Koguja (brubeck)

Mõõdikute arv: ~ 300 000 / sec
Mõõdikute saatmise intervall Graphitesse: 30 sec
Serveri ressursikasutus: ~ 6% CPU (täisfunktsionaalsed serverid); ~ 1Gb RAM; ~ 3 Mbps LAN

Graphite (go-carbon)

Mõõdikute arv: ~ 1 600 000 / min
Mõõdikute uuendamise intervall: 30 sec
Mõõdikute säilitamise skeem: 30sec 35d, 5min 90d, 10min 365d (annab ülevaate sellest, mis teenusega pikemas perspektiivis toimub)
Serveri ressursikasutus: ~ 10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN

Paindlikkus

Me hindame Avitos oma jälgimisteenuses paindlikkust. Miks see täpselt selline on? Esiteks on selle koostisosad omavahel asendatavad: nii komponendid kui ka nende versioonid. Teiseks — hooldatavus. Kuna kogu projekt on rajatud avatud lähtekoodiga, saate ise koodi muuta, muudatusi sisse viia, luua funktsioone, mis ei ole välja toodud. Kasutatakse üsna levinud tehnoloogiaid, peamiselt Go ja Python, seega on see üsna lihtne.

Siin on näide tõeliselt tekkinud probleemist. Mõõdik Graphites on fail. Sellel on nimi. Faili nimi = mõõdiku nimi. Ja on tee selle juurde. Linuxis on failinimede pikkus piiratud 255 sümboliga. Ja meil on (siseprojektide “tellijatena”) inimesed andmebaasi osakonnast. Nad ütlevad meile: “Tahame jälgida oma SQL-päringuid. Need ei ole 255 sümbolit, vaid 8 MB igaühe kohta. Tahame neid kuvada Grafanas, näha selle päringu parameetreid, ja veel parem, tahame näha selliste päringute topi. Oleks tore, kui see kuvataks reaalajas. Ja täiuslik oleks see sisse panna häiretesse.”

SQL-päringu näide on toodud näiteks saidilt postgrespro.ru

Me tõstame Redis serveri ja meie Collectd-pluginad, mis käivad Postgreses ja võtavad sealt kõik andmed, saadame mõõdikud Graphite'i. Aga me asendame mõõdiku nime hash'ideks. See sama hash saadame samuti Redis'esse võtmena ja kogu SQL-päringu väärtusena. Meil on jäänud veel teha nii, et Grafana oskaks Redis'esse minna ja selle teabe kätte saada. Me avame Graphite API, kuna see on peamine liides kõigi jälgimiskomponentide vahel, ja kirjutame sinna uue funktsiooni, mida kutsutakse aliasByHash() — Grafanast saame mõõdiku nime ja kasutame seda Redis'e päringus võtmena, millele saame vastuseks võtme väärtuse, milleks on meie "SQL päring". Nii oleme Grafanas välja toonud SQL päringu, mida seal muidu kuidagi ei saanud näidata, koos selle statistika (calls, rows, total_time, …) nägemisega.

Summary

Saadavus. Meie jälgimisteenus on saadaval 24/7 igast rakendusest ja igast koodist. Kui teil on ligipääs ladustamissüsteemidele, võite teenusele andmeid kirjutada. Keel ei ole oluline, lahendused ei ole olulised. Teil on vaja ainult teada, kuidas avada pesa, saata sinna mõõdik ja siis pesa sulgeda.

Usaldusväärsus. Kõik komponendid on talitlushäireteta ja suudavad meie koormusi hästi taluda.

Madala sisenemise künnis. Selle süsteemi kasutamiseks ei pea te õppima programmeerimiskeeli ega päringuid Grafanas. Lihtsalt avage oma rakendus, kirjutage sinna pesa, mis saadab mõõdikud Graphite'i, sulgege see, avage Grafana, looge seal armatuurlaud ja vaadake oma mõõdikute käitumist, saades hoiatusi Moira kaudu.

Iseseisvus. Kogu seda saab teha iseseisvalt, DevOps- inseneride abita. Ja see on pealehakkamiseks ideaalne, kuna saate oma projekti jälgida kohe, kedagi ei pea paluma — ei alguses ega muudatuste tegemiseks.

Mille poole me püüdleme?

Kõik allpool loetletud on mitte lihtsalt abstraktsed mõtted, vaid see, mille suunal on tehtud vähemalt esimesed sammud.

1. Anomaaliate tuvastaja. Tahame luua teenuse, mis läheb meie Graphite'i ladustamisse ja kontrollib iga mõõdiku erinevate algoritmide järgi. Algoritmid on juba olemas, mida tahame vaadata, andmed on olemas, me oskame nendega töötada.
2. Metaandmed. Meil on palju teenuseid, mis ajas muutuvad, samuti nagu ka inimesed, kes nendega töötavad. Dokumentatsiooni pidev käsitsi pidamine ei ole variant. Seetõttu integreerime praegu oma mikroteenustesse metaandmed. Seal on kirjas, kes selle arendas, milliste keeltega ta suhtleb, SLA nõudmised, kuhu ja kellele saata teavitusi. Teenuse juurutamisel luuakse kõik andmed iseseisvalt. Lõpuks saad kaks linki — üks triggerite jaoks, teine — Grafana armatuurlaudade jaoks.
3. Seire iga koju. Usume, et sellisest süsteemist peaksid kõik arendajad kasutama. Sel juhul tead alati, kus on su liiklus, mis temaga toimub, kus see langeb, kus on nõrgad kohad. Kui näiteks juhtub midagi, mis rikub su teenuse, saad sellest teada mitte telefonikõnest haldurilt, vaid häiresignaalist ning saad kohe avada värsked logid ja vaadata, mis juhtus.
4. Kõrge jõudlus. Meie projekt kasvab pidevalt ja täna töödeldakse selles umbes 2 000 000 mõõtmeväärtust minutis. Aasta tagasi oli see number 500 000. Ja kasv jätkub, mis tähendab, et mõne aja pärast hakkab Graphite (whisper) väga tugevalt koormama salvestussüsteemi. Nagu ma juba ütlesin, on see seiresüsteem üsna universaalne oma komponentide vahetatavuse tõttu. Keegi hooldab ja laiendab oma infrastruktuuri spetsiaalselt Graphite'i jaoks, kuid me otsustasime minna teist teed: kasutada ClickHouse kui meie mõõtmete salvestust. See üleminek on peaaegu lõpule jõudnud ning peagi räägin detailselt, kuidas see tehti: millised olid raskused ja kuidas need ületati, kuidas toimus migratsiooniprotsess, kirjeldan valitud komponentide sidumist ja nende seadistusi.

Aitäh tähelepanu eest! Esitage oma küsimusi teema kohta, püüan siin või järgnevates postitustes vastata. Võib-olla on kellelgi kogemusi sarnase seiresüsteemi loomise või Clickhouse'ile ülemineku osas — jagage neid kommentaarides.

Allikas: habr.com