Tänapäeval tegutsevad meie projektis lisaks monoliitsele koodile kümned mikroteenused. Igaüks neist vajab jälgimist. DevOpsi inseneride jaoks on seda sellistes mahtudes problemaatiline teha. Oleme välja töötanud seiresüsteemi, mis töötab arendajatele mõeldud teenusena. Nad saavad iseseisvalt kirjutada mõõdikuid seiresüsteemi, kasutada neid, ehitada nende põhjal armatuurlaudu, lisada neile hoiatusi, mis käivituvad läviväärtuste saavutamisel. DevOpsi inseneridega – ainult infrastruktuur ja dokumentatsioon.
See postitus on meie kõne ärakiri RIT++-s. Paljud palusid meil teha sealt aruannetest tekstiversioone. Kui olete konverentsil käinud või videot vaadanud, ei leia te midagi uut. Ja kõigile teistele – tere tulemast kassi alla. Ma räägin teile, kuidas me sellise süsteemini jõudsime, kuidas see töötab ja kuidas plaanime seda uuendada.
Minevik: skeemid ja plaanid
Kuidas jõudsime olemasoleva seiresüsteemini? Sellele küsimusele vastamiseks peate minema 2015. aastasse. Selline see siis välja nägi:
Meil oli umbes 24 sõlme, mis vastutasid jälgimise eest. Seal on terve hunnik erinevaid krone, skripte, deemoneid, mis kuskil midagi jälgivad, sõnumeid saadavad, funktsioone täidavad. Arvasime, et mida edasi, seda vähem on selline süsteem elujõuline. Seda pole mõtet arendada: see on liiga tülikas.
Otsustasime valida need seireelemendid, mille jätame ja arendame, ja need, millest loobume. Neid oli 19. Alles jäid vaid grafiidid, agregaatorid ja Grafana kui armatuurlaud. Kuidas aga uus süsteem välja näeb? Nagu nii:
Meil on mõõdikute hoidla: need on grafiidid, mis põhinevad kiiretel SSD-draividel, need on teatud mõõdikute agregaatorid. Järgmine – Grafana armatuurlaudade kuvamiseks ja Moira hoiatuseks. Samuti soovisime välja töötada süsteemi kõrvalekallete leidmiseks.
Standard: seire 2.0
Sellised nägid plaanid välja aastal 2015. Kuid lisaks taristule ja teenusele tuli ette valmistada ka selle dokumentatsioon. Oleme enda jaoks välja töötanud ettevõtte standardi, mille nimetasime monitooringuks 2.0. Millised olid süsteemile esitatavad nõuded?
- pidev kättesaadavus;
- meetriline salvestusintervall = 10 sekundit;
- mõõdikute ja armatuurlaudade struktureeritud salvestamine;
- SLA > 99,99%
- sündmuste mõõdikute kogumine UDP kaudu (!).
Vajasime UDP-d, kuna meil on palju liiklust ja sündmusi, mis mõõdikuid genereerivad. Kui need kõik korraga grafiidiga kirja panna, kukub hoidla kokku. Samuti valisime kõigi mõõdikute jaoks esimese taseme eesliited.
Igal eesliitel on mingi omadus. Mõõdikud on olemas serverite, võrkude, konteinerite, ressursside, rakenduste ja muu kohta. Rakendatud on selge, range ja trükitud filtreerimine, mille puhul aktsepteerime esimese taseme mõõdikuid ja jätame ülejäänud lihtsalt ära. Nii kavandasime selle süsteemi 2015. aastal. Mis on olevikus?
Olevik: seirekomponentide koostoime skeem
Esiteks jälgime rakendusi: meie PHP koodi, rakendusi ja mikroteenuseid – ühesõnaga kõike, mida meie arendajad kirjutavad. Kõik rakendused saadavad mõõdikuid UDP kaudu Brubecki koondajasse (statsd, C-vormingus ümber kirjutatud). See osutus sünteetiliste testide tulemuste järgi kõige kiiremaks. Ja see saadab juba koondatud mõõdikud Graphite'ile TCP kaudu.
Sellel on sellist tüüpi mõõdikud nagu taimerid. See on väga mugav asi. Näiteks iga kasutaja teenusega ühenduse loomise kohta saadate Brubeckile reageerimisaja mõõdiku. Tuli miljon vastust ja koondaja andis välja vaid 10 mõõdikut. Teil on kohale tulnud inimeste arv, maksimaalne, minimaalne ja keskmine reageerimisaeg, mediaan ja 4 protsentiili. Seejärel edastatakse andmed Graphite'i ja me näeme neid kõiki otseülekandes.
Meil on ka riistvara, tarkvara, süsteemimõõdikute ja meie vana Munini seiresüsteemi koondamine (see töötas meiega kuni 2015. aastani). Kogume seda kõike C'ish deemoni CollectD kaudu (sellesse on õmmeldud terve hulk erinevaid pistikprogramme, see saab päringuid teha kõigi selle hostisüsteemi ressursside kohta, kuhu see on installitud, lihtsalt määrake konfiguratsioonis, kuhu andmeid kirjutada ) ja kirjutage selle kaudu andmed grafiidis. See toetab ka pythoni pistikprogramme ja shelliskripte, nii et saate kirjutada oma kohandatud lahendused: CollectD kogub need andmed kohalikult või kaughostilt (eeldusel, et Curl on saadaval) ja saadab need Graphite'ile.
Lisaks saadetakse kõik meie kogutud mõõdikud Carbon-c-releele. See on Graphite'i Carbon Relay lahendus, mida on muudetud C-vormingus. See on ruuter, mis kogub kõik mõõdikud, mille me oma agregaatoritelt saadame, ja suunab need läbi sõlmede. Ka marsruutimise etapis kontrollib see mõõdikute kehtivust. Esiteks peavad need vastama minu varem näidatud eesliidete skeemile ja teiseks peavad need kehtima grafiidi jaoks. Vastasel juhul kukuvad nad maha.
Seejärel saadab Carbon-c-relee mõõdikud grafiidiklastrisse. Kasutame mõõdikute peamise salvestusruumina Go-s ümber kirjutatud Carbon-cache. Go-carbon on oma mitme keermelisuse tõttu jõudluses palju parem kui Carbon-cache. See võtab andmed enda sisse ja kirjutab need kettale, kasutades whisper paketti (standardne, kirjutatud pythonis). Oma salvestustelt andmete lugemiseks kasutame Graphite API-t. See töötab palju kiiremini kui tavaline Graphite WEB. Mis juhtub andmetega järgmisena?
Nad lähevad Grafanasse. Peamise andmeallikana kasutame oma grafiidiklastreid, lisaks on meil Grafana veebiliides mõõdikute kuvamiseks ja armatuurlaudade koostamiseks. Iga teenuse jaoks loovad arendajad oma armatuurlaua. Seejärel koostavad nad nende põhjal graafikud, mis kuvavad nende rakendustest kirjutatud mõõdikuid. Lisaks Grafanale on meil ka SLAM. See on püütoonide deemon, mis arvutab SLA grafiidi andmete põhjal. Nagu ma ütlesin, on meil mitukümmend mikroteenust, millest igaühel on oma nõuded. SLAM-i abil läheme dokumentatsiooni juurde ja võrdleme seda Graphite'is olevaga ning võrdleme, kuidas vastavad nõuded meie teenuste saadavusele.
Edasi liikumine: hoiatamine. See on korraldatud tugeva süsteemiga – Moira. Ta on iseseisev, sest tal on kapoti all oma Grafiit. Välja töötatud SKB Konturi poiste poolt, kirjutatud pythonis ja Go's, täielikult avatud lähtekoodiga. Moira saab sama voolu, mis läheb grafiiti. Kui teie salvestusruum mingil põhjusel sureb, töötab teie hoiatus.
Moira juurutasime Kubernetesis, see kasutab põhiandmebaasina Redise serverite klastrit. Tulemuseks on tõrkekindel süsteem. See võrdleb mõõdikute voogu käivitajate loendiga: kui selles pole mainimisi, siis see mõõdik loobub. Seega suudab ta minutis seedida gigabaiti mõõdikuid.
Lisasime sinna ka ettevõtte LDAP, mille abil saab iga ettevõtte süsteemi kasutaja luua enda jaoks teateid olemasolevate (või vastloodud) trigerite kohta. Kuna Moira sisaldab grafiiti, toetab see kõiki selle funktsioone. Nii et kõigepealt võtate liini ja kopeerite selle Grafanasse. Vaadake, kuidas andmed diagrammidel kuvatakse. Ja siis võtate sama rea ja kopeerite selle Moirasse. Riputage see piirangutega ja saate väljundis hoiatuse. Selle kõige tegemiseks pole vaja mingeid spetsiifilisi teadmisi. Moira saab hoiatada SMS-i, e-posti, Jira, Slacki… See toetab ka kohandatud skripte. Kui tal on päästik ja ta on tellinud kohandatud skripti või binaarfaili, käivitab ta selle ja saadab selle JSON-i binaarfaili stdinile. Seetõttu peaks teie programm seda sõeluma. See, mida te selle JSON-iga ette võtate, on teie otsustada. Soovi korral saada Telegrami, kui tahad, ava Jiras ülesanded, tee mida tahad.
Kasutame hoiatamiseks ka oma arendust – Imagotag. Paneeli, mida tavaliselt kasutatakse kauplustes elektrooniliste hinnasiltide jaoks, kohandasime oma vajadustele vastavaks. Moirast tõime selle juurde päästikud. See näitab, millises seisukorras nad on, millal need juhtusid. Mõned arenduse tüübid loobusid teatistest Slackis ja posti teel selle paneeli kasuks.
Noh, kuna oleme edumeelne ettevõte, siis jälgisime selles süsteemis ka Kubernetest. Lisades selle süsteemi Heapsteri abil, mille me klastris installisime, kogub see andmeid ja saadab need Graphite'ile. Selle tulemusena näeb skeem välja järgmine:
Järelevalve komponendid
Siin on linkide loend komponentidele, mida selle ülesande jaoks kasutasime. Kõik need on avatud lähtekoodiga.
Grafiit:
- go-carbon:
- sosistada:
- grafiit-api:
Carbon-c-relee:
Brubeck:
Tasakaalukas:
Moira:
Grafana:
heapster:
Statistika
Ja siin on mõned numbrid selle kohta, kuidas süsteem meie jaoks töötab.
Agregaator (brubeck)
Mõõdikute arv: ~ 300 000 / sek
Grafiitmõõdikute saatmise intervall: 30 sek
Serveri ressursikasutus: ~ 6% CPU (räägime täisväärtuslikest serveritest); ~ 1 Gb RAM; ~ 3 Mbps LAN
Grafiit (süsinik)
Mõõdikute arv: ~ 1 600 000 / min
Mõõdiku uuendamise intervall: 30 sek
Mõõdikute salvestusskeem: 30 s 35 p, 5 min 90 p, 10 min 365 p (annab mõista, mis teenusega pika aja jooksul juhtub)
Serveri ressursikasutus: ~10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN
Paindlikkus
Meie, Avito, hindame väga meie seireteenuse paindlikkust. Miks ta tegelikult selliseks osutus? Esiteks on selle koostisosad omavahel asendatavad: nii komponendid ise kui ka nende versioonid. Teiseks hooldatavus. Kuna kogu projekt on üles ehitatud avatud lähtekoodile, saate koodi ise redigeerida, teha muudatusi ja rakendada funktsioone, mis pole karbist väljas saadaval. Kasutatakse üsna levinud pinu, peamiselt Go ja Python, nii et seda tehakse üsna lihtsalt.
Siin on näide tõelisest probleemist. Grafiidi mõõdik on fail. Sellel on nimi. Faili nimi = mõõdiku nimi. Ja sinna on võimalik jõuda. Linuxis on failinimed piiratud 255 tähemärgiga. Ja meil on ("siseklientidena") kutid andmebaasiosakonnast. Nad ütlevad meile: "Me tahame oma SQL-päringuid jälgida. Ja need ei ole 255 tähemärki, vaid igaüks 8 MB. Soovime neid Grafanas kuvada, näha selle päringu parameetreid ja mis veelgi parem, tahame näha selliste päringute tippu. See on suurepärane, kui seda kuvatakse reaalajas. Ja oleks tõesti lahe neid hoiatusse lükata.
SQL-päringu näide on võetud näitena aadressilt
Tõstame üles Redise serveri ja meie Collectd pluginad, mis lähevad Postgresse ja võtame sealt kõik andmed, saadame mõõdikud Graphite'i. Kuid mõõdiku nime asendame räsidega. Sama räsi saadetakse samaaegselt Redisele võtmena ja kogu SQL-päring väärtusena. Jääb üle anda Grafanale võimalus minna Redisesse ja võtta see teave. Avame Graphite API, kuna see on peamine liides kõigi seirekomponentide koostoimeks grafiidiga ja me sisestame sinna uue funktsiooni nimega aliasByHash () - saame Grafanalt mõõdiku nime ja kasutame seda Redisele suunatud päringus võtmena. vastuseks saame võtme väärtuse, mis on meie "SQL-päring". Nii tõime Grafanasse SQL-päringu kuva, mida teoreetiliselt seal kuvada ei saaks, koos selle statistikaga (kõned, read, total_time, ...).
Tulemused
Kättesaadavus. Meie jälgimisteenus on saadaval 24/7 mis tahes rakendusest ja mis tahes koodist. Kui teil on juurdepääs salvestustele, saate teenusesse andmeid kirjutada. Keel pole oluline, otsused pole olulised. Peate ainult teadma, kuidas pistikupesa avada, visata sinna mõõdik ja sulgeda pistikupesa.
Usaldusväärsus Kõik komponendid on veakindlad ja saavad meie töökoormusega hästi hakkama.
Madal sisenemislävi. Selle süsteemi kasutamiseks ei pea te Grafanas programmeerimiskeeli ega päringuid õppima. Lihtsalt avage oma rakendus, lisage sellele pesa, mis saadab mõõdikud Graphite'ile, sulgege see, avage Grafana, looge seal armatuurlauad ja vaadake oma mõõdikute käitumist, saades Moira kaudu teateid.
Iseseisvus. Saate seda kõike ise teha, ilma DevOpsi inseneride abita. Ja see on ülefunktsioon, sest saate oma projekti kohe jälgida, te ei pea kelleltki paluma - ei töö alustamiseks ega muudatuste tegemiseks.
Mille poole me püüdleme?
Kõik allpool loetletud ei ole lihtsalt abstraktsed mõtted, vaid midagi, mille poole on vähemalt esimesed sammud astutud.
- anomaalia detektor. Soovime luua teenuse, mis läheks meie grafiidimäludesse ja kontrolliks iga mõõdikut erinevate algoritmide abil. Juba on olemas algoritmid, mida tahame vaadata, andmed on olemas, me teame, kuidas nendega töötada.
- metaandmed. Meil on palju teenuseid, need muutuvad ajas, samuti inimesed, kes nendega töötavad. Käsitsi arvestuse pidamine ei ole valik. Seetõttu on metaandmed nüüd meie mikroteenustesse manustatud. Selles on kirjas, kes selle välja töötas, keeled, millega see suhtleb, SLA nõuded, kuhu ja kellele teateid saata. Teenuse juurutamisel luuakse kõik olemi andmed iseseisvalt. Selle tulemusel saate kaks linki – ühe päästikute jaoks, teise Grafana armatuurlaudade jaoks.
- Järelevalve igas kodus. Usume, et kõik arendajad peaksid sellist süsteemi kasutama. Sel juhul saate alati aru, kus teie liiklus on, mis sellega juhtub, kuhu see langeb, kus on nõrgad kohad. Kui näiteks midagi tuleb ja teie teenus kokku jookseb, saate sellest teada mitte halduri kõne, vaid märguande kaudu ning saate kohe avada värsked logid ja vaadata, mis seal juhtus.
- Suur jõudlus. Meie projekt kasvab pidevalt ja täna töötleb see umbes 2 000 000 meetrilist väärtust minutis. Aasta tagasi oli see arv 500 000. Ja kasv jätkub ja see tähendab, et mõne aja pärast hakkab Graphite (sosin) ketta alamsüsteemi väga tugevalt koormama. Nagu ma ütlesin, on see seiresüsteem komponentide vahetatavuse tõttu üsna mitmekülgne. Keegi spetsiaalselt Graphite'i jaoks hooldab ja laiendab pidevalt oma infrastruktuuri, kuid otsustasime minna teist teed: kasutada meie mõõdikute hoidlana. See üleminek on peaaegu lõppenud ja peagi räägin teile lähemalt, kuidas seda tehti: millised olid raskused ja kuidas need ületati, kuidas migratsiooniprotsess kulges, kirjeldan sidumisena valitud komponente ja nende konfiguratsioone.
Täname tähelepanu eest! Esitage oma küsimused teemal, püüan vastata siin või järgmistes postitustes. Võib-olla on kellelgi kogemusi sarnase jälgimissüsteemi ehitamisega või sarnases olukorras Clickhouse'ile üleminekuga - jagage seda kommentaarides.
Allikas: www.habr.com