Danas, osim monolitnog koda, naš projekt uključuje desetke mikroservisa. Svaki od njih zahtijeva nadzor. Raditi to u tolikoj mjeri pomoću DevOps inženjera je problematično. Razvili smo sustav nadzora koji radi kao servis za programere. Oni mogu samostalno pisati metrike u sustav praćenja, koristiti ih, graditi nadzorne ploče na temelju njih i priložiti im upozorenja koja će se pokrenuti kada se dosegnu granične vrijednosti. Za DevOps inženjere, samo infrastruktura i dokumentacija.
Ovaj post je transkript mog govora s našim na RIT++. Mnogi su nas tražili da odatle napravimo tekstualne verzije izvješća. Ako ste bili na konferenciji ili gledali video, nećete pronaći ništa novo. A svi ostali - dobrodošli u mačku. Reći ću vam kako smo došli do takvog sustava, kako funkcionira i kako ga planiramo ažurirati.
Prošlost: sheme i planovi
Kako smo došli do trenutnog sustava nadzora? Da biste odgovorili na ovo pitanje, morate otići u 2015. godinu. Ovako je to tada izgledalo:
Imali smo oko 24 čvora koji su bili odgovorni za praćenje. Postoji cijeli paket različitih kruna, skripti, demona koji na neki način nadziru nešto, šalju poruke i obavljaju funkcije. Mislili smo da što dalje idemo, to će takav sustav biti manje održiv. Nema smisla razvijati ga: previše je glomazan.
Odlučili smo izabrati one elemente praćenja koje ćemo zadržati i razvijati, a one koje ćemo napustiti. Bilo ih je 19. Ostali su samo grafiti, agregati i Grafana kao tabla. No, kako će izgledati novi sustav? Kao ovo:
Imamo pohranu metrike: to su grafiti, koji će se temeljiti na brzim SSD diskovima, to su određeni agregatori za metriku. Dalje - Grafana za prikaz nadzornih ploča i Moira za uzbunjivanje. Htjeli smo razviti i sustav za traženje anomalija.
Standard: Monitoring 2.0
Ovako su izgledali planovi 2015. No, morali smo pripremiti ne samo infrastrukturu i samu uslugu, nego i dokumentaciju za nju. Za sebe smo razvili korporativni standard koji nazivamo monitoring 2.0. Koji su bili zahtjevi za sustav?
- stalna dostupnost;
- interval pohrane metrike = 10 sekundi;
- strukturirana pohrana metrika i nadzornih ploča;
- SLA > 99,99%
- prikupljanje metrike događaja putem UDP-a (!).
Trebao nam je UDP jer imamo veliki protok prometa i događaja koji generiraju metriku. Ako ih sve odjednom zapišete u grafit, pohrana će se urušiti. Također smo odabrali prefikse prve razine za sve metrike.
Svaki od prefiksa ima neko svojstvo. Postoje metrike za poslužitelje, mreže, spremnike, resurse, aplikacije i tako dalje. Implementirano je jasno, strogo, tipizirano filtriranje, gdje prihvaćamo metriku prve razine, a ostale jednostavno ispuštamo. Ovako smo planirali ovaj sustav 2015. godine. Što je u sadašnjosti?
Prisutno: dijagram interakcije komponenti nadzora
Prije svega, pratimo aplikacije: naš PHP kod, aplikacije i mikroservise – ukratko, sve što naši programeri napišu. Sve aplikacije šalju metriku putem UDP-a Brubeck agregatoru (statsd, prepisano u C). U sintetičkim testovima pokazao se najbržim. I šalje već agregirane metrike Graphiteu putem TCP-a.
Ima vrstu metrike koja se zove mjerač vremena. Ovo je vrlo zgodna stvar. Na primjer, za svaku vezu korisnika s uslugom, Brubecku šaljete metriku s vremenom odgovora. Stiglo je milijun odgovora, ali agregator je vratio samo 10 metrika. Imate broj ljudi koji su došli, maksimalno, minimalno i prosječno vrijeme odgovora, medijan i 4. percentil. Zatim se podaci prebacuju u Graphite i mi to sve vidimo uživo.
Također imamo agregaciju za metriku o hardveru, softveru, sistemsku metriku i naš stari sustav praćenja Munin (radio nam je do 2015.). Sve to prikupljamo preko C daemona CollectD (u njega je ugrađena cijela hrpa različitih dodataka, može anketirati sve resurse host sustava na kojem je instaliran, samo odredite u konfiguraciji gdje će pisati podatke) i preko njega zapišite podatke u Graphite. Također podržava python dodatke i shell skripte, tako da možete napisati vlastita prilagođena rješenja: CollectD će prikupiti ove podatke s lokalnog ili udaljenog računala (pretpostavljajući Curl) i poslati ih Graphiteu.
Zatim šaljemo sve metrike koje smo prikupili u Carbon-c-relay. Ovo je rješenje Carbon Relay tvrtke Graphite, modificirano u C. Ovo je usmjerivač koji prikuplja sve metrike koje šaljemo s naših agregatora i usmjerava ih do čvorova. Također u fazi usmjeravanja provjerava valjanost metrike. Prvo, moraju odgovarati shemi prefiksa koju sam ranije pokazao i, drugo, vrijede za grafit. Inače će pasti.
Carbon-c-relay zatim šalje metriku Graphite klasteru. Kao glavnu pohranu metrike koristimo Carbon-cache, prepisan u Gou. Go-carbon, zbog višenitnosti, daleko nadmašuje Carbon-cache. Prima podatke i zapisuje ih na diskove koristeći whisper paket (standardni, napisan u pythonu). Za čitanje podataka iz naših pohrana koristimo Graphite API. Mnogo je brži od standardnog Graphite WEB-a. Što se dalje događa s podacima?
Idu u Grafanu. Koristimo naše grafitne klastere kao glavni izvor podataka, plus imamo Grafanu kao web sučelje za prikaz metrike i izradu nadzornih ploča. Za svaku od svojih usluga programeri stvaraju vlastitu nadzornu ploču. Zatim na temelju njih izgrađuju grafikone koji prikazuju metriku koju pišu iz svojih aplikacija. Osim Grafana imamo i SLAM. Ovo je python demon koji izračunava SLA na temelju podataka iz grafita. Kao što sam već rekao, imamo nekoliko desetaka mikroservisa, od kojih svaki ima svoje zahtjeve. Koristeći SLAM, idemo u dokumentaciju i uspoređujemo je s onim što je u Graphiteu i uspoređujemo koliko zahtjevi odgovaraju dostupnosti naših usluga.
Idemo dalje: uzbunjivanje. Organiziran je pomoću snažnog sustava - Moira. Neovisan je jer ispod haube ima vlastiti Graphite. Razvili ga momci iz SKB "Kontur", napisano u pythonu i Gou, potpuno otvorenog koda. Moira prima isti tok koji ide u grafite. Ako iz nekog razloga vaša pohrana nestane, vaše će upozorenje i dalje raditi.
Implementirali smo Moiru u Kubernetes; ona koristi klaster Redis poslužitelja kao glavnu bazu podataka. Rezultat je bio sustav otporan na greške. Uspoređuje tok metrike s popisom okidača: ako nema spomena u njemu, ispušta metriku. Dakle, može probaviti gigabajte metričkih podataka u minuti.
Priključili smo mu i korporativni LDAP uz pomoć kojeg svaki korisnik korporativnog sustava može za sebe kreirati obavijesti na temelju postojećih (ili novoizrađenih) okidača. Budući da Moira sadrži Graphite, podržava sve njegove značajke. Dakle, prvo uzmete liniju i kopirate je u Grafanu. Pogledajte kako su podaci prikazani na grafikonima. A onda uzmete isti redak i kopirate ga u Moiru. Objesite ga s ograničenjima i dobijete upozorenje na izlazu. Za sve ovo ne trebate nikakvo specifično znanje. Moira može upozoravati putem SMS-a, e-pošte, Jire, Slacka... Također podržava izvršavanje prilagođenih skripti. Kada joj se dogodi okidač, a ona je pretplaćena na prilagođenu skriptu ili binarnu datoteku, ona je pokreće i šalje JSON u ovu binarnu datoteku na stdin. Sukladno tome, vaš ga program mora analizirati. Što ćete učiniti s ovim JSON-om ovisi o vama. Ako hoćeš, šalji na Telegram, ako hoćeš, otvaraj zadatke u Jiri, radi što god.
Koristimo i vlastiti razvoj za uzbunjivanje - Imagotag. Panel, koji se inače koristi za elektronske cjenike u trgovinama, prilagodili smo svojim potrebama. Donijeli smo mu okidače od Moire. Označava u kakvom su stanju i kada su se dogodili. Neki od razvojnih momaka napustili su obavijesti u Slacku i e-poštu u korist ovog panela.
Pa, budući da smo napredna tvrtka, pratili smo i Kubernetes u ovom sustavu. Uključili smo ga u sustav pomoću Heapstera kojeg smo instalirali u klaster, skuplja podatke i šalje ih u Graphite. Kao rezultat, dijagram izgleda ovako:
Komponente za praćenje
Ovdje je popis poveznica na komponente koje smo koristili za ovaj zadatak. Sve su one otvorenog koda.
Grafit:
- go-carbon:
- šapat:
- grafit-api:
Carbon-c-relej:
Brubeck:
Prikupljeno:
Moira:
Grafana:
Heapster:
statistika
Evo nekoliko brojki o tome kako sustav funkcionira za nas.
Agregator (brubeck)
Broj metrika: ~300 000/sek
Interval za slanje metrike u Graphite: 30 sek
Korištenje resursa poslužitelja: ~ 6% CPU (govorimo o punopravnim poslužiteljima); ~ 1Gb RAM; ~3 Mbps LAN
Grafit (go-carbon)
Broj metrika: ~ 1 / min
Interval ažuriranja metrike: 30 sek
Shema pohranjivanja metrike: 30 sekundi 35 dana, 5 minuta 90 dana, 10 minuta 365 dana (daje vam uvid u to što se događa s uslugom tijekom dugog vremenskog razdoblja)
Upotreba resursa poslužitelja: ~10% CPU; ~ 20Gb RAM; ~30 Mbps LAN
savitljivost
Mi u Avitu stvarno cijenimo fleksibilnost u našoj usluzi nadzora. Zašto je zapravo ispao ovakav? Prvo, njegove komponente su međusobno zamjenjive: i same komponente i njihove verzije. Drugo, mogućnost podrške. Budući da je cijeli projekt otvorenog koda, možete sami uređivati kod, unositi izmjene i implementirati funkcije koje nisu dostupne izvan kutije. Koriste se prilično uobičajeni stackovi, uglavnom Go i Python, tako da se to radi vrlo jednostavno.
Evo primjera stvarnog problema. Mjerni podatak u Graphiteu je datoteka. Ima ime. Naziv datoteke = naziv metrike. A postoji put do tamo. Nazivi datoteka u Linuxu ograničeni su na 255 znakova. I imamo (kao "interne kupce") dečke iz odjela baze podataka. Kažu nam: “Želimo pratiti naše SQL upite. I nisu 255 znakova, već 8 MB svaki. Želimo ih prikazati u Grafani, vidjeti parametre za ovaj zahtjev, i još bolje, želimo vidjeti vrh takvih zahtjeva. Bit će sjajno ako se prikazuje u stvarnom vremenu. Bilo bi stvarno super staviti ih u uzbunu.”
Primjer SQL upita uzet je kao primjer iz
Postavljamo Redis poslužitelj i koristimo naše Collectd dodatke, koji idu u Postgres i odatle preuzimaju sve podatke, šaljući metrike Graphiteu. Ali naziv metrike zamjenjujemo hashovima. Istodobno šaljemo isti hash Redisu kao ključ, a cijeli SQL upit kao vrijednost. Sve što trebamo učiniti je osigurati da Grafana može otići u Redis i uzeti ove informacije. Otvaramo Graphite API jer... ovo je glavno sučelje za interakciju svih komponenti nadzora s grafitom, i tu unosimo novu funkciju koja se zove aliasByHash() - od Grafana dobivamo naziv metrike, i koristimo je u zahtjevu za Redis kao ključ, u odgovor dobivamo vrijednost ključa, što je naš “SQL upit” " Tako smo u Grafani prikazali prikaz SQL upita kojeg je teoretski bilo nemoguće tamo prikazati, zajedno sa statistikom o njemu (pozivi, redovi, total_time, ...).
Rezultati
Raspoloživost. Naša usluga nadzora dostupna je 24/7 iz bilo koje aplikacije i bilo kojeg koda. Ako imate pristup skladišnim prostorima, možete pisati podatke u uslugu. Nije bitan jezik, nisu važne odluke. Samo trebate znati otvoriti utičnicu, staviti metriku i zatvoriti utičnicu.
Pouzdanost. Sve komponente otporne su na greške i dobro podnose naša opterećenja.
Niska ulazna barijera. Da biste koristili ovaj sustav, ne morate učiti programske jezike i upite u Grafani. Samo otvorite svoju aplikaciju, unesite u nju socket koji će slati metrike Graphiteu, zatvorite je, otvorite Grafanu, tamo napravite nadzorne ploče i pogledajte ponašanje svojih metrika, primajući obavijesti putem Moire.
Neovisnost. Sve to možete učiniti sami, bez pomoći DevOps inženjera. I to je prednost, jer sada možete pratiti svoj projekt, ne morate nikoga tražiti - bilo da započnete s radom, bilo da napravite promjene.
Što ciljamo?
Sve dolje navedeno nisu samo apstraktne misli, već nešto prema čemu su učinjeni barem prvi koraci.
- Detektor anomalija. Želimo stvoriti uslugu koja će ići u naše Graphite pohrane i provjeravati svaku metriku koristeći različite algoritme. Već postoje algoritmi koje želimo vidjeti, postoje podaci, znamo kako s njima raditi.
- Metapodaci. Imamo mnogo usluga, mijenjaju se s vremenom, baš kao i ljudi koji s njima rade. Stalno ručno održavanje dokumentacije nije opcija. Zato sada ugrađujemo metapodatke u naše mikroservise. Navodi tko ga je razvio, jezike s kojima komunicira, SLA zahtjeve, gdje i kome treba slati obavijesti. Prilikom implementacije usluge, svi podaci entiteta kreiraju se neovisno. Kao rezultat dobivate dvije poveznice – jednu na trigere, drugu na nadzorne ploče u Grafani.
- Nadzor u svakom domu. Vjerujemo da bi svi programeri trebali koristiti takav sustav. U ovom slučaju uvijek razumijete gdje je vaš promet, što se s njim događa, gdje pada, gdje su mu slabosti. Ako, na primjer, nešto dođe i sruši vašu uslugu, tada ćete o tome saznati ne tijekom poziva upravitelja, već iz upozorenja, a možete odmah otvoriti najnovije zapise i vidjeti što se tamo dogodilo.
- Visoke performanse. Naš projekt neprestano raste i danas obrađuje oko 2 metričkih vrijednosti u minuti. Prije godinu dana ta je brojka bila 000 000. I rast se nastavlja, a to znači da će nakon nekog vremena Graphite (šapat) početi jako opteretiti diskovni podsustav. Kao što sam već rekao, ovaj sustav nadzora je prilično univerzalan zbog zamjenjivosti komponenti. Netko održava i stalno proširuje svoju infrastrukturu posebno za Graphite, ali mi smo odlučili ići drugim putem: koristiti kao spremište za naše metrike. Ovaj prijelaz je gotovo završen i vrlo brzo ću vam detaljnije reći kako je to učinjeno: koje su poteškoće postojale i kako su prevladane, kako je tekao proces migracije, opisat ću komponente odabrane za uvezivanje i njihove konfiguracije.
Hvala na pozornosti! Postavite svoja pitanja o temi, pokušat ću odgovoriti ovdje ili u sljedećim postovima. Možda netko ima iskustva s izgradnjom sličnog sustava nadzora ili prelaskom na Clickhouse u sličnoj situaciji - podijelite to u komentarima.
Izvor: www.habr.com