Meie projektis toimib tänapäeval mitme mikroteenuse kõrval ka monoliitne kood. Igaüks neist vajab jälgimist. Sedavõrd suurte mahu korral on DevOps-inseneride jõudude kaasamine keeruline. Oleme välja töötanud jälgimissüsteemi, mis töötab teenusena arendajatele. Nad saavad ise kirjutada mõõdikud jälgimissüsteemi, kasutada neid, luua nende põhjal juhtpaneele ning lisada neile häireid, mis aktiveeruvad, kui lähenetakse piirväärtustele. DevOps-inseneride osalus on vaid infrastruktuuri ja dokumentatsiooni haldamine.
See postitus on minu ettekande tõlgendus meie RIT++-l. Paljud palusid meil teha sealsetest ettekannetest tekstiversioonid. Kui olite konverentsil või vaatasite videot, ei leia te midagi uut. Kõigile teistele — teretulemast allapoole. Räägin, kuidas me sellise süsteemi juurde jõudsime, kuidas see töötab ja kuidas plaanime seda ajakohastada.
Minevik: skeemid ja plaanid
Kuidas me jõudsime olemasoleva jälgimissüsteemini? Sellele küsimusele vastamiseks peame minema tagasi 2015. aastasse. Nii see siis välja nägi:
Meil oli umbes 24 sõlme jälgimise eest vastutavad. Seal oli terve hulk erinevaid cron'e, skripte, deemonite, mis mingil viisil jälgisid, saatsid teateid, täitsid funktsioone. Arvasime, et mida kaugemale, seda vähem on selline süsteem jätkusuutlik. Selle arendamine pole mõttekas: liiga mahukas.
Otsustasime valida need jälgimise elemendid, mille me jätame ja arendame, ning need, millest loobume. Nendest osutus 19 olevat. Jõudsid ainult grafiidid, agregaatoreid ja Grafana välja visata puutepunktina. Aga kuidas näeb välja uus süsteem? Nii:
Meil on metrikate salvestus: need on grafiidid, mis asuvad kiiretel SSD-diskidel, teatud agregaatoreid metrikate jaoks. Järgmine on Grafana juhtpaneelide jaoks ja Moira häireks. Soovisime välja töötada ka anomaaliate leidmise süsteemi.
Standard: Jälgimine 2.0
Selline nägi välja plaan 2015. aastal. Kuid me pidime ette valmistama mitte ainult infrastruktuuri ja teenuse, vaid ka selle dokumentatsiooni. Koostasime oma ettevõtte standardi, mille nimeks panime monitorimine 2.0. Millised olid nõuded süsteemile?
- püsiv kätte saadavus;
- mõõdikute salvestamise intervall = 10 sekundit;
- mõõdikute ja armatuurlaudade struktureeritud salvestamine;
- SLA > 99,99%
- sündmuste mõõdikute kogumine UDP kaudu (!).
Me vajame UDP-d, sest meil on suur liiklusvoog ja sündmused, mis genereerivad mõõdikud. Kui kõik mõõdikud kohe graafikusse kirjutada, siis salvestus põrkab kokku. Valisime ka kõigi mõõdikute jaoks esimese taseme prefiksid.
Igal prefiksil on oma omadus. On olemas mõõdikud serverite, võrkude, konteinerite, ressursside, rakenduste jne kohta. Oleme rakendanud selge, range, tüübistatud filtreerimise, kus me aktsepteerime esimese taseme mõõdikuid ja kõik teised lihtsalt kõrvaldame. Nii planeerisime seda süsteemi 2015. aastal. Aga mis on hetkel?
Tänapäev: jälgimise komponentide vastastikune toimimise skeem
Esiteks jälgime rakendusi: meie PHP-kood, rakendused ja mikroteenused — ühesõnaga kõik, mida meie arendajad kirjutavad. Kõik rakendused saadavad UDP kaudu mõõdikud kogujale Brubeck (statsd, kirjutatud C keeles). See osutus sünteetiliste testide tulemusel kõige kiiremaks. Ja see saadab juba kogutud mõõdikud Graphitele TCP kaudu.
Sel on selline mõõdikute tüüp nagu ajamõõdikud. See on väga mugav asi. Näiteks iga kasutaja ühenduse kohta teenusega saadate Brubeck'ile vastuseaja mõõdiku. Saite miljon vastust, aga koguja andis välja vaid 10 mõõdikut. Teil on teada saabunud inimeste arv, maksimaalne, minimaalne ja keskmine vastusaeg, mediaan ning 4 protsentiili. Seejärel edastatakse andmed Graphitessse ja me näeme neid kõiki reaalajas.
Meil on ka aggregatsioon riistvara, tarkvara, süsteemsete mõõdikute ja meie vana jälgimissüsteemi Munin jaoks (mis töötas meil kuni 2015. aastani). Kogume kõiki neid andmeid C-iga kirjutatud CollectD deemoniga (seal on terve rida erinevaid pluginaid, mis suudavad küsida kõiki hostimisressursse, millele see on installitud, lihtsalt näidake konfiguratsioonis, kuhu andmed kirjutada) ja saadame need Graphite'i. See toetab ka Python ja shell skripte, nii et saate kirjutada oma kohandatud lahendused: CollectD kogub neid andmeid kohalikult või eemalt (eeldame, et on olemas Curl) ja saadab need Graphite'i.
Edasi saadame kõik kogutud mõõdikud Carbon-c-relay'le. See on Graphite'i Carbon Relay lahendus, täiendatud C keeles. See on marsruuter, mis kogub endasse kõik mõõdikud, mida saadame oma agregaatidest, ja suunab need sõlmedesse. Samuti kontrollib see marsruutimise etapis mõõdikute kehtivust. Esiteks peavad need vastama skeemile eelsete prefixide osas, millest ma varem rääkisin, ja teiseks peavad need olema Graphite'ile kehtivad. Vastasel juhul need jäetakse välja.
See, kuidas Carbon-c-relay edastab metrikad Graphite klastrisse. Meie peamiseks metrikate salvestamiseks on Carbon-cache, mis on kirjutatud Go keeles. Go-carbon ületab oma mitme äratuse võimekuse tõttu Carbon-cache'i jõudlust. See võtab andmeid vastu ja salvestab need kõvakettale whisper paketiga (tavaline, kirjutatud Pythonis). Andmete lugemiseks meie salvestustest kasutame Graphite API-d. See töötab tunduvalt kiiremini kui tavaline Graphite WEB. Mis juhtub andmetega edasi?
Need for Grafana. We use our Graphite clusters as the main data source, and Grafana serves as the web interface for displaying metrics and building dashboards. Each of our services has its own dashboard created by developers. They then create graphs based on these dashboards to display metrics collected from their applications. In addition to Grafana, we also have SLAM. This is a Python daemon that calculates SLA based on data from Graphite. As I mentioned, we have several dozen microservices, each with its own requirements. With SLAM, we refer to the documentation and compare it with what we have in Graphite to assess how well the requirements match the availability of our services.
Moving on to alerting. It is organized using a robust system — Moira. It's independent because it has its own Graphite running under the hood. Developed by the team at SKB 'Kontur', it's written in Python and Go, and is fully open-source. Moira processes the same flow that goes into Graphite. If for any reason your storage fails, your alerting will still function.
Moira on deployitud Kubernetesis ja kasutab põhitehnoloogia jaoks Redis-serverite klastrit. Tulemuseks on kõrgelt usaldusväärne süsteem. See võrdleb mõõdikute voogu triggereid nimekirjaga: kui nendes puuduvad mainimised, siis viskab mõõdiku ära. Sel viisil suudab ta minutis töödelda gigabaiti mõõdikuid.
Oleme sellele lisanud ettevõtte LDAP, mille kaudu saavad kõik ettevõttesüsteemi kasutajad luua endale teateid olemasolevate (või uutest loodud) trigerite järgi. Kuna Moira sisaldab Graphite'i, toetab ta kõiki selle funktsioone. Seega kopeerite esmalt rea ja kleepite selle Grafanasse. Vaadake, kuidas andmed graafikutel kuvatakse. Seejärel võtate sama rea ja kopeerite selle Moira'sse. Lisate sellele piirangud ja saate tulemuseks häireteate. Kõik see ei nõua teilt mingeid spetsiifilisi teadmisi. Moira oskab teavitada SMS-i, e-postiga, Jira's, Slack'is... Samuti toetab ta kohandatud skriptide käitamise võimalust. Kui tal toimub triger ja ta on allkirjastatud kohandatud skripti või binaarkoodi järgi, käivitab ta selle ja edastab sellele binaarkoodile JSON'i. Seega peab teie programm selle analüüsima. Mida te selle JSON-iga teete - otsustage ise. Kui soovite - saatke Telegram'i, kui soovite - avage ülesandeid Jira's, tehke, mida iganes tahate.
Meil on häälestuseks kasutusel ka meie enda arendus — Imagotag. Oleme kohandanud tavaliselt jaemüügis kasutatavat paneeli, et see sobiks meie ülesannetega. Oleme sinna lisanud Moira triggereid. Seal on märgitud, millises olekus need on ja millal need toimusid.
Ja kuna me oleme progressiivne ettevõte, oleme monitooringusüsteemi lisanud ka Kubernetes'i. Läbi Heapsteri, mille oleme klastrisse paigaldanud, kogume andmeid ja saadame need Graphitesse. Lõpptulemusena näeb skeem välja selline:
Monitooringu komponendid
Siin on loetelu linkidest nendele komponentidele, mida kasutasime selle ülesande jaoks. Kõik need on avatud lähtekoodiga.
Graphite:
- go-carbon:
- whisper:
- graphite-api:
Carbon-c-relay:
Brubeck:
Collectd:
Moira:
Grafana:
Heapster:
Statistika
Ja siin on mõned numbrid selle kohta, kuidas süsteem meil töötab.
Aggregator (brubeck)
Metrikate arv: ~ 300 000 / sek
Metrikate saatmise intervall Graphitesse: 30 sek
Serveri ressursside kasutus: ~ 6% CPU (rääkides täielikest serveritest); ~ 1Gb RAM; ~ 3 Mbps LAN
Graphite (go-carbon)
Mõõdikute arv: ~ 1 600 000 / min
Mõõdikute värskenduse intervall: 30 sek
Mõõdikute salvestamise skeem: 30sek 35d, 5min 90d, 10min 365d (annab arusaama, mis teenusega pikema aja jooksul toimub)
Serveri ressursside kasutus: ~ 10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN
Paindlikkus
Meie Avitos hindame oma jälgimisteenuses väga paindlikkust. Miks see selline on? Esiteks, selle koostisosad on vahetatavad: nii komponendid kui ka nende versioonid. Teiseks - hooldatavus. Kuna kogu projekt põhineb avatud lähtekoodiga, saate ise koodi redigeerida, muudatusi teha, ja rakendada funktsioone, mis pole vaikimisi saadaval. Kasutatakse piisavalt laialdaselt levinud tehnolooge, peamiselt Go ja Python, seetõttu on see üsna lihtne.
Siin on näide tõeliselt tekkinud probleemist. Graphite'is on mõõdik fail. Tal on nimi. Faili nimi = mõõdiku nimi. Ja tal on tee sinna. Failinimed Linuxis on piiratud 255 märgiga. Ja meil on (nagu „sisemised tellijad”) andmebaasi osakonna kutid. Nad ütlevad meile: „Me tahame jälgida meie SQL-päringuid. Ja need ei ole 255 märki, vaid 8 MB igaüks. Me tahame neid kuvada Grafanas, näha parameetreid selle päringu kohta, ja veel parem, tahame näha selliste päringute tippu. Oleks tore, kui see kuvataks reaalajas. Ja oleks täiesti äge, kui saaksime need alerteerimisse panna.”
SQL-päringu näide on toodud
Me seadistame Redis serveri ja meie Collectd pluginate abil, mis sukelduvad Postgres'i ja võtavad sealt kõik andmed, edastades mõõdikud Graphite'i. Kuid me asendame mõõdiku nime hash'idega. See sama hash saadetakse samal ajal Redis'i võtmena ja kogu SQL-päring väärtusena. Meie ülesanne on muuta niimoodi, et Grafana oskaks Redis'esse minna ja seda teavet võtta. Avame Graphite API, kuna see on peamine liides, millega kõik jälgimiskomponendid suhtlevad grafiidiga, ja kirjutame sinna uue funktsiooni, mille nimi on aliasByHash() — saame Grafanalt mõõdiku nime ja kasutame seda Redis'e päringus võtmena, millele vastuseks saame võtme väärtuse, mis on meie "SQL päring". Nii suudame Grafanas kuvada SQL-päringut, mida muidu poleks saadud seal näidata, koos selle statistika (calls, rows, total_time, …) ja kõigega.
Kokkuvõte
Saadavus. Meie jälgimisteenuse kättesaadavus on 24/7 igast rakendusest ja igast koodist. Kui teil on juurdepääs andmebaasidele, saate teenusesse andmeid kirjutada. Keeleline aspekt ei ole oluline, lahendused ei ole olulised. Te peate ainult teadma, kuidas avada sokkel, edastada mõõde ja sulgeda sokkel.
Usaldusväärsus. Kõik komponendid on tõrkekindlad ja taluvad meie koormusi hästi.
Madala sisenemise tõkkega. Selle süsteemi kasutamiseks ei pea te õppima programmeerimiskeeli ega päringuid Grafanas. Lihtsalt avate oma rakenduse, sisestate sellesse pistiku, mis saadab mõõdikud Graphitesse, sulgete selle, avate Grafana, loote seal armatuurlaudu ja vaatate oma mõõdikute käitumist, saades teateid Moira kaudu.
Iseseisvus. Kõike seda saab teha ise, ilma DevOps-inseneride abita. See on üleliigne, kuna saate oma projekti jälgida just nüüd, kedagi küsima ei pea — ei töö alustamiseks ega muudatuste tegemiseks.
Mille poole me püüame?
Kõik allpool loetletud ei ole lihtsalt abstraktsed mõtted, vaid see, mille suunas on astutud vähemalt esimesed sammud.
- Anomaaliate detektor. Soovime luua teenuse, mis kontrollib meie Graphite'ile säilitatud mõõdikuid erinevate algoritmide abil. Juba on olemas algoritmid, mida soovime läbi vaadata, andmed on olemas, me oskame nendega töötada.
- Metaandmed. Meil on palju teenuseid, mis aja jooksul muutuvad, nagu ka inimesed, kes nendega töötavad. Dokumentatsiooni käsitsi pidamine ei ole praktiline variant. Seetõttu integreeritakse meie mikroteenustesse nüüd metaandmed. Seal on kirjas, kes selle arendas, milliste keel(te)ga see töötab, SLA nõuded, kuhu ja kellele teavitusi saata. Teenuse juurutamisel luuakse kõik olendi andmed iseseisvalt. Tulemuseks on kaks linki — üks triggereid, teine — Grafana juhtpaneelidele.
- Jõudlus igas kodus. Usume, et sellist süsteemi peaksid kasutama kõik arendajad. Sel juhul mõistate alati, kus teie liiklus on, mis sellega toimub, kus see kukub ja kus on nõrgad kohad. Kui näiteks saabub midagi, mis viib teie teenuse alla, siis saate sellest teada mitte telefoni kõne ajal, vaid alert'ist ja saate kohe avada värsked logid ning vaadata, mis juhtus.
- Kõrge jõudlus. Meie projekt kasvab pidevalt ja täna töödeldakse selles umbes 2 000 000 mõõdiku väärtust minutis. Aasta tagasi oli see näitaja 500 000. Ja kasv jätkub, mis tähendab, et mõne aja pärast hakkab Graphite (whisper) väga tugevalt koormama salvestusala. Nagu ma juba mainisin, on see jälgimissüsteem üsna universaalne tänu komponentide vahetatavusele. Keegi haldab ja laiendab pidevalt oma infrastruktuuri spetsiaalselt Graphite'i jaoks, kuid meie otsustasime järgida teistsugust teed: kasutada meie mõõdikute salvestamiseks. See üleminek on peaaegu lõpetatud ja peagi räägin lähemalt, kuidas see tehti: millised olid raskused ja kuidas need ületati, kuidas toimus migratsiooniprotsess, kirjeldan valitud komponentide sidumist ja nende konfiguratsiooni.
Aitäh tähelepanu eest! Esitage oma küsimused teema kohta, üritan vastata siin või järgnevates postitustes. Võib-olla on kellelgi kogemusi sellise jälgimissüsteemi ülesehitamiseks või Clickhouse'ile ülemineku kohta sarnases olukorras – jagage seda kommentaarides.
Allikas: habr.com
