Danes naš projekt poleg monolitne kode vključuje na desetine mikrostoritev. Vsakega od njih je treba spremljati. Narediti to v takšnem obsegu z uporabo inženirjev DevOps je problematično. Razvili smo sistem za spremljanje, ki deluje kot storitev za razvijalce. Samostojno lahko zapišejo metrike v nadzorni sistem, jih uporabijo, na njihovi podlagi sestavijo nadzorne plošče in jim pripnejo opozorila, ki se bodo sprožila, ko bodo dosežene mejne vrednosti. Za inženirje DevOps le infrastruktura in dokumentacija.
Ta objava je prepis mojega govora z našimi pri RIT++. Veliko ljudi nas je prosilo, da od tam naredimo besedilne različice poročil. Če ste bili na konferenci ali ste gledali video, ne boste našli nič novega. Vsi ostali pa - dobrodošli pri mačku. Povedal vam bom, kako smo prišli do takega sistema, kako deluje in kako ga nameravamo posodobiti.
Preteklost: sheme in načrti
Kako smo prišli do sedanjega sistema spremljanja? Če želite odgovoriti na to vprašanje, se morate vrniti v leto 2015. Takole je to izgledalo takrat:
Imeli smo približno 24 vozlišč, ki so bila odgovorna za spremljanje. Obstaja cel paket različnih kron, skript, demonov, ki nekako spremljajo nekaj, pošiljajo sporočila in izvajajo funkcije. Mislili smo, da dlje ko gremo, manj bo tak sistem uspešen. Nima smisla ga razvijati: preveč je okoren.
Odločili smo se, da izberemo tiste elemente spremljanja, ki jih bomo ohranili in razvijali, in tiste, ki jih bomo opustili. Bilo jih je 19. Ostali so le grafitni, agregatorji in Grafana kot armaturna plošča. Kako pa bo videti nov sistem? Všečkaj to:
Imamo shrambo metrik: to so grafiti, ki bodo temeljili na hitrih SSD diskih, to so določeni agregatorji za metrike. Naprej - Grafana za prikaz nadzornih plošč in Moira za opozarjanje. Želeli smo razviti tudi sistem za iskanje anomalij.
Standard: Monitoring 2.0
Tako so bili videti načrti leta 2015. Pripraviti pa smo morali ne le infrastrukturo in samo storitev, ampak tudi dokumentacijo zanjo. Zase smo razvili korporativni standard, ki ga imenujemo monitoring 2.0. Kakšne so bile zahteve za sistem?
- stalna razpoložljivost;
- interval shranjevanja metrike = 10 sekund;
- strukturirano shranjevanje meritev in nadzornih plošč;
- SLA > 99,99 %
- zbiranje meritev dogodkov prek UDP (!).
Potrebovali smo UDP, ker imamo velik pretok prometa in dogodkov, ki ustvarjajo meritve. Če jih vse naenkrat zapišete v grafit, se bo shramba sesula. Za vse metrike smo izbrali tudi predpone prve stopnje.
Vsaka od predpon ima neko lastnost. Obstajajo meritve za strežnike, omrežja, vsebnike, vire, aplikacije itd. Implementirano je bilo jasno, strogo, vneseno filtriranje, kjer sprejemamo metrike prve stopnje in preprosto izpustimo ostale. Tako smo načrtovali ta sistem leta 2015. Kaj je v sedanjosti?
Prisotno: diagram interakcije nadzornih komponent
Najprej spremljamo aplikacije: našo kodo PHP, aplikacije in mikrostoritve – skratka vse, kar napišejo naši razvijalci. Vse aplikacije pošiljajo metrike prek UDP v agregator Brubeck (statsd, prepisano v C). Izkazalo se je, da je najhitrejši po rezultatih sintetičnih testov. In že združene meritve pošlje Graphite prek TCP.
Ima vrsto meritev, imenovanih časovniki. To je zelo priročna stvar. Na primer, za vsako uporabniško povezavo s storitvijo Brubecku pošljete metriko z odzivnim časom. Prišlo je milijon odgovorov, a agregator je vrnil le 10 metrik. Imate število ljudi, ki so prišli, največji, najmanjši in povprečni odzivni čas, mediano in 4 percentile. Nato se podatki prenesejo v Graphite in vse to vidimo v živo.
Imamo tudi agregacijo za meritve strojne opreme, programske opreme, sistemske meritve in naš stari sistem za spremljanje Munin (za nas je deloval do leta 2015). Vse to zbiramo prek C daemona CollectD (vgrajenega ima cel kup različnih vtičnikov, lahko poizveduje po vseh virih gostiteljskega sistema, na katerem je nameščen, samo v konfiguraciji določite, kam naj zapiše podatke) in prek njega zapišite podatke v Graphite. Podpira tudi vtičnike python in skripte lupine, tako da lahko napišete lastne rešitve po meri: CollectD bo te podatke zbral od lokalnega ali oddaljenega gostitelja (ob predpostavki, da je Curl) in jih poslal Graphite.
Nato vse metrike, ki smo jih zbrali, pošljemo v Carbon-c-relay. To je rešitev Carbon Relay podjetja Graphite, spremenjena v C. To je usmerjevalnik, ki zbira vse metrike, ki jih pošiljamo iz naših agregatorjev, in jih usmerja do vozlišč. Prav tako v fazi usmerjanja preveri veljavnost metrik. Prvič, ustrezati morajo shemi predpon, ki sem jo pokazal prej, in drugič, veljajo za grafit. V nasprotnem primeru bodo padle.
Carbon-c-relay nato pošlje meritve v grafitno gručo. Kot glavno shrambo metrik uporabljamo Carbon-cache, prepisan v Go. Go-carbon zaradi svoje večnitnosti močno prekaša Carbon-cache. Podatke sprejema in jih zapisuje na diske s pomočjo paketa whisper (standardno, napisano v pythonu). Za branje podatkov iz naših shramb uporabljamo Graphite API. Je veliko hitrejši od standardnega Graphite WEB. Kaj se potem zgodi s podatki?
Gredo na Grafana. Naše grafitne grozde uporabljamo kot glavni vir podatkov, poleg tega pa imamo Grafano kot spletni vmesnik za prikaz meritev in gradnjo nadzornih plošč. Za vsako od svojih storitev razvijalci ustvarijo svojo nadzorno ploščo. Nato na njihovi podlagi zgradijo grafe, ki prikazujejo meritve, ki jih zapišejo iz svojih aplikacij. Poleg Grafana imamo še SLAM. To je python demon, ki izračuna SLA na podlagi podatkov iz grafita. Kot sem že rekel, imamo več deset mikrostoritev, od katerih ima vsaka svoje zahteve. Z uporabo SLAM-a gremo do dokumentacije in jo primerjamo s tem, kar je v Graphiteu, in primerjamo, kako dobro se zahteve ujemajo z razpoložljivostjo naših storitev.
Gremo dalje: opozarjanje. Organiziran je po močnem sistemu - Moira. Samostojen je, ker ima pod pokrovom svoj Graphite. Razvili fantje iz SKB "Kontur", napisani v python in Go, popolnoma odprta koda. Moira prejme isti tok, kot gre v grafite. Če iz nekega razloga vaš pomnilnik umre, bo vaše opozorilo še vedno delovalo.
Moira smo namestili v Kubernetes; kot glavno bazo podatkov uporablja gručo strežnikov Redis. Rezultat je bil sistem, odporen na napake. Tok metrik primerja s seznamom sprožilcev: če v njem ni omemb, metriko izpusti. Tako lahko prebavi gigabajte meritev na minuto.
Nanj smo pripeli tudi korporativni LDAP, s pomočjo katerega si lahko vsak uporabnik korporativnega sistema sam ustvari obvestila na podlagi obstoječih (ali na novo ustvarjenih) sprožilcev. Ker Moira vsebuje Graphite, podpira vse njegove funkcije. Torej najprej vzamete vrstico in jo kopirate v Grafana. Oglejte si, kako so podatki prikazani na grafih. In potem vzameš isto vrstico in jo kopiraš v Moiro. Obesiš ga z omejitvami in na izhodu dobiš opozorilo. Za vse to ne potrebujete posebnega znanja. Moira lahko opozarja prek SMS-a, e-pošte, Jire, Slacka ... Podpira tudi izvajanje skript po meri. Ko se ji zgodi sprožilec in je naročena na skript po meri ali dvojiško datoteko, jo zažene in pošlje JSON v stdin za to dvojiško datoteko. V skladu s tem ga mora vaš program razčleniti. Kaj boste storili s tem JSON, je odvisno od vas. Če želite, pošljite v Telegram, če želite, odprite naloge v Jiri, naredite karkoli.
Uporabljamo tudi lasten razvoj za alarmiranje - Imagotag. Panel, ki se običajno uporablja za elektronske cenike v trgovinah, smo prilagodili svojim potrebam. K njemu smo prinesli sprožilce od Moire. Označuje, v kakšnem stanju so in kdaj so se zgodili. Nekateri razvojni fantje so opustili obvestila v Slacku in e-pošto v korist te plošče.
No, ker smo napredno podjetje, smo tudi Kubernetes spremljali v tem sistemu. V sistem smo ga vključili s pomočjo Heapsterja, ki smo ga namestili v gručo, zbira podatke in jih pošilja Graphitu. Kot rezultat, diagram izgleda takole:
Komponente za spremljanje
Tukaj je seznam povezav do komponent, ki smo jih uporabili za to nalogo. Vsi so odprtokodni.
Grafit:
- go-carbon:
- šepetaj:
- grafit-api:
Carbon-c-rele:
Brubeck:
Zbrano:
Moira:
Grafana:
Heapster:
statistika
Tukaj je nekaj številk o tem, kako sistem deluje pri nas.
Zbiralnik (brubeck)
Število meritev: ~300/sek
Interval za pošiljanje metrike v Graphite: 30 sek
Poraba virov strežnika: ~ 6% CPE (govorimo o polnopravnih strežnikih); ~ 1 Gb RAM; ~3 Mbps LAN
Grafit (go-carbon)
Število metrik: ~ 1 / min
Interval posodabljanja meritev: 30 sek
Shema shranjevanja meritev: 30 s 35 d, 5 min 90 d, 10 min 365 d (omogoča vam razumevanje, kaj se zgodi s storitvijo v daljšem časovnem obdobju)
Poraba strežniških virov: ~10 % CPU; ~ 20 Gb RAM; ~30 Mbps LAN
Prilagodljivost
Pri Avitu resnično cenimo prilagodljivost pri naših storitvah spremljanja. Zakaj je pravzaprav izpadel tak? Prvič, njegove komponente so zamenljive: tako same komponente kot njihove različice. Drugič, podpornost. Ker je celoten projekt odprtokoden, lahko sami urejate kodo, spreminjate in implementirate funkcije, ki niso na voljo takoj. Uporabljajo se precej običajni skladi, predvsem Go in Python, tako da je to narejeno precej preprosto.
Tukaj je primer resničnega problema. Metrika v Graphitu je datoteka. Ima ime. Ime datoteke = ime metrike. In obstaja pot do tja. Imena datotek v sistemu Linux so omejena na 255 znakov. In imamo (kot "interne stranke") fante iz oddelka za baze podatkov. Povedo nam: »Želimo spremljati svoje poizvedbe SQL. In niso 255 znakov, ampak 8 MB vsak. Želimo jih prikazati v Grafani, videti parametre za to zahtevo, še bolje, želimo videti vrh takih zahtev. Super bo, če bo prikazan v realnem času. Bilo bi res kul, če bi jih dali v opozorilo.«
Primer poizvedbe SQL je vzet kot primer iz
Postavili smo strežnik Redis in uporabili naše vtičnike Collectd, ki gredo v Postgres in od tam vzamejo vse podatke ter pošljejo meritve v Graphite. Toda ime metrike zamenjamo z zgoščenimi vrednostmi. Istočasno pošljemo isto zgoščeno vrednost Redisu kot ključ in celotno poizvedbo SQL kot vrednost. Vse, kar moramo storiti, je zagotoviti, da lahko Grafana odide v Redis in vzame te informacije. Graphite API odpiramo, ker... to je glavni vmesnik za interakcijo vseh nadzornih komponent z grafitom in tja vnesemo novo funkcijo, imenovano aliasByHash() - od Grafana dobimo ime metrike in jo uporabimo v zahtevi za Redis kot ključ, v odgovor dobimo vrednost ključa, ki je naša "SQL poizvedba" " Tako smo v Grafani prikazali prikaz SQL poizvedbe, ki je v teoriji tam ni bilo mogoče prikazati, skupaj s statistiko o njej (klici, vrstice, total_time, ...).
Rezultati
Razpoložljivost. Naša storitev spremljanja je na voljo 24/7 iz katere koli aplikacije in katere koli kode. Če imate dostop do prostorov za shranjevanje, lahko zapišete podatke v storitev. Jezik ni pomemben, odločitve niso pomembne. Samo vedeti morate, kako odpreti vtičnico, vanjo postaviti metriko in zapreti vtičnico.
Zanesljivost. Vse komponente so odporne na napake in dobro prenašajo naše obremenitve.
Nizka ovira za vstop. Za uporabo tega sistema se vam ni treba učiti programskih jezikov in poizvedb v Grafani. Preprosto odprite svojo aplikacijo, vanjo vnesite vtičnico, ki bo pošiljala metrike v Graphite, jo zaprite, odprite Grafana, tam ustvarite nadzorne plošče in si oglejte obnašanje svojih metrik ter prejemajte obvestila prek Moire.
Neodvisnost. Vse to lahko storite sami, brez pomoči inženirjev DevOps. In to je prednost, saj lahko zdaj spremljate svoj projekt, nikogar vam ni treba prositi - bodisi za začetek dela bodisi za spremembe.
Na kaj ciljamo?
Vse spodaj našteto niso samo abstraktne misli, ampak nekaj, k čemur so bili narejeni vsaj prvi koraki.
- Detektor anomalij. Želimo ustvariti storitev, ki bo šla v naše Graphite skladišča in preverila vsako metriko z različnimi algoritmi. Obstajajo že algoritmi, ki si jih želimo ogledati, obstajajo podatki, vemo, kako delati z njimi.
- Metapodatki. Imamo veliko storitev, spreminjajo se skozi čas, tako kot ljudje, ki delajo z njimi. Nenehno ročno vzdrževanje dokumentacije ni možnost. Zato zdaj v naše mikrostoritve vgrajujemo metapodatke. Navaja, kdo ga je razvil, jezike, s katerimi sodeluje, zahteve SLA, kam in komu je treba poslati obvestila. Pri uvajanju storitve se vsi podatki entitet ustvarijo neodvisno. Posledično dobite dve povezavi - eno do sprožilcev, drugo do nadzornih plošč v Grafanu.
- Nadzor v vsakem domu. Menimo, da bi morali vsi razvijalci uporabljati tak sistem. V tem primeru vedno razumete, kje je vaš promet, kaj se z njim zgodi, kje pade, kje so njegove slabosti. Če na primer nekaj pride in zruši vašo storitev, potem boste o tem izvedeli ne med klicem upravitelja, ampak iz opozorila, in takoj lahko odprete najnovejše dnevnike in vidite, kaj se je tam zgodilo.
- Visokozmogljivo. Naš projekt nenehno raste in danes obdeluje približno 2 metričnih vrednosti na minuto. Pred letom dni je bila ta številka 000 000. In rast se nadaljuje, kar pomeni, da bo čez nekaj časa Graphite (šepet) začel močno obremenjevati diskovni podsistem. Kot sem že rekel, je ta nadzorni sistem precej univerzalen zaradi zamenljivosti komponent. Nekdo vzdržuje in nenehno širi svojo infrastrukturo posebej za Graphite, mi pa smo se odločili za drugo pot: uporabo kot repozitorij za naše meritve. Ta prehod je skoraj končan in kmalu vam bom podrobneje povedal, kako je bilo to storjeno: kakšne težave so bile in kako so bile premagane, kako je potekal proces selitve, opisal bom komponente, izbrane za vezavo, in njihove konfiguracije.
Hvala za vašo pozornost! Zastavite svoja vprašanja o temi, poskušal bom odgovoriti tukaj ali v naslednjih objavah. Morda ima kdo izkušnje z gradnjo podobnega nadzornega sistema ali prehodom na Clickhouse v podobni situaciji - delite to v komentarjih.
Vir: www.habr.com