Danas na našem projektu, osim monolitnog koda, funkcioniše desetine mikroservisa. Svaki od njih zahteva da se prati. Raditi to u takvim obimima je problematično za DevOps inženjere. Razvili smo sistem praćenja koji funkcioniše kao usluga za programere. Oni mogu samostalno pisati metrike u sistem praćenja, koristiti ih, graditi na osnovu njih nadzorne table, povezivati alarme koji će se aktivirati kada dostignu prag vrednosti. Od DevOps inženjera – samo infrastruktura i dokumentacija.
Ova objava je transkript mog izlaganja sa naše na RIT++. Mnogi su tražili da napravimo tekstualne verzije predavanja s tog skupa. Ako ste bili na konferenciji ili gledali video, nećete pronaći ništa novo. A svi ostali – dobrodošli ispod. Pričaću vam kako smo došli do takvog sistema, kako on funkcioniše i kako planiramo da ga ažuriramo.
Prošlost: sheme i planovi
Kako smo došli do postojećeg sistema praćenja? Da bismo odgovorili na ovo pitanje, treba da se vratimo u 2015. godinu. Ovako je to izgledalo tada:
Imali smo oko 24 čvora koji su bili odgovorni za praćenje. Ovdje postoji ceo niz različitih cronova, skripti, demona koji nešto negde na neki način prate, šalju poruke, obavljaju funkcije. Pomislili smo da će takav sistem postati sve manje održiv. Nema smisla razvijati ga: previše je nespretno.
Odlučili smo da izaberemo one elemente praćenja koje ćemo zadržati i razviti, i one od kojih ćemo odustati. Ispostavilo se da ih je 19. Ostali su samo grafiti, agregatori i Grafana kao nadzorna tabla. Kako će izgledati novi sistem? Ovako:
Imamo skladište metrika: to su grafiti koji će biti zasnovani na brzim SSD diskovima, to su određeni agregatori za metrike. Zatim – Grafana za prikazivanje nadzornih tabli i Moira kao sistem za alarme. Takođe, planirali smo da razvijemo sistem za pretraživanje anomalija.
Standard: Praćenje 2.0
Ovako su izgledali planovi u 2015. Sada smo morali da pripremimo ne samo infrastrukturu i samu uslugu, već i dokumentaciju za nju. Razvili smo korporativni standard koji smo nazvali praćenje 2.0. Koji su zahtevi postavljeni pred sistem?
- stalna dostupnost;
- interval čuvanja metrika = 10 sekundi;
- struktura pohrane metrika i nadzornih ploča;
- SLA > 99,99%
- prikupljanje događajnih metrika putem UDP (!).
Trebali smo UDP jer imamo veliki protok prometa i događaja koji generiraju metrike. Ako bismo ih sve odjednom zapisivali u Graphite, pohrana bi srušila. Također smo odabrali prefikse prvog nivoa za sve metrike.
Svaki od prefiksa nosi određenu karakteristiku. Tu su metrike za poslužitelje, mreže, kontejnere, resurse, aplikacije i tako dalje. Implementirana je jasna, stroga, tipizirana filtracija, gdje prihvaćamo metrike prvog nivoa, a ostale jednostavno odbacujemo. Tako smo planirali ovaj sustav 2015. godine. A što je sa sadašnjošću?
Sadašnjost: shema interakcije komponenti nadzora
Prvo, nadziremo aplikacije: naš PHP kod, aplikacije i mikroservise — ukratko, sve što naši programeri razvijaju. Sve aplikacije kroz UDP šalju metrike u agregator Brubeck (statsd, prepravljen na C). Pokazao se kao najbrži prema rezultatima sintetičkih testova. On već agregirane metrike šalje u Graphite putem TCP-a.
Ima takav tip metrika kao što su tajmeri. To je vrlo korisna stvar. Na primjer, za svaku povezanost korisnika sa servisom šaljete u Brubeck metriku s vremenom odgovora. Stiglo je milion odgovora, a agregator je izdao samo 10 metrika. Imate broj pristiglih ljudi, maksimalno, minimalno i srednje vrijeme odziva, medijana i 4 percentila. Zatim se podaci šalju u Graphite i vidimo ih uživo.
Također imamo agregaciju za metrike vezane uz opremu, softver, sistemske metrike i našu staru sistem nadzora Munin (koja je radila kod nas do 2015. godine). Sve to prikupljamo putem C daemon-a CollectD (u njega je ugrađena čitava serija različitih dodataka, može ispitivati sve resurse hhostske systeme na kojima je instaliran, samo navedite u konfiguraciji gdje zapisivati podatke) i putem njega zapisujemo podatke u Graphite. Također podržava python dodatke i shell skripte, tako da možete pisati svoja prilagođena rešenja: CollectD će prikupljati te podatke s lokalnog ili udaljenog hosta (pretpostavimo da imate Curl) i slati ih u Graphite.
Dalje, sve metrike koje smo skupili šaljemo u Carbon-c-relay. Ovo je rešenje Carbon Relay od Graphite, unapređeno na C. To je ruter koji prikuplja sve metrike koje šaljemo sa naših agregatora i usmerava ih po nodovima. Takođe, u fazi usmeravanja proverava valjanost metrika. One, pre svega, moraju biti u skladu sa shemom prefiksa koju sam ranije pokazao i, drugo, moraju biti validne za Graphite. U suprotnom, biće odbijene.
Nakon toga, Carbon-c-relay šalje metrike u Graphite klaster. Kao glavno skladište metrika koristimo Carbon-cache, prepisan na Go. Go-carbon, zbog svoje višedretvenosti, znatno nadmašuje performanse Carbon-cache-a. Prihvata podatke i zapisuje ih na diskove pomoću whisper paketa (standardni, napisan na Pythonu). Da bismo pročitali podatke iz naših skladišta, koristimo Graphite API. On radi mnogo brže od standardnog Graphite WEB. Šta se dešava sa podacima dalje?
Oni idu u Grafanu. Kao glavni izvor podataka koristimo naše Graphite klastere, plus imamo Grafanu kao web interfejs za prikazivanje metrika i izradu kontrolnih tabli. Svaki svoj servis programeri postavljaju svoj kontrolni tablu. Zatim kreiraju grafikone na kojima su prikazane metrike koje pišu iz svojih aplikacija. Pored Grafane, imamo još SLAM. To je Python demon koji izračunava SLA na osnovu podataka iz Graphite-a. Kao što sam već spomenuo, imamo nekoliko desetina mikros servisa, od kojih svaki ima svoje zahteve. Pomoću SLAM-a upoređujemo dokumentaciju sa onim što imamo u Graphite-u i proveravamo koliko zahtevi odgovaraju dostupnosti naših servisa.
Idemo dalje: aleriranje. Ono je organizovano putem snažnog sistema - Moira. Ona je nezavisna jer ima svoj vlastiti Graphite. Razvijena od strane momaka iz SKB 'Kontur', napisana na Python-u i Go, potpuno je open source. Moira prima sav taj isti tok koji ide u Graphite. Ako iz nekog razloga umre vaše skladište, vaše aleriranje će i dalje raditi.
Moira je razmještena u Kubernetesu, a kao glavna baza podataka koristi klaster Redis poslužitelja. Kao rezultat, nastao je otporan sustav. Ona uspoređuje tok metrika sa popisom okidača: ako u njemu nema spominjanja, tada odbacuje metrik. Na taj način može obraditi gigabajte metrika u minuti.
Također smo joj pridružili korporativni LDAP, pomoću kojeg svaki korisnik korporativnog sustava može kreirati obavijesti za postojeće (ili novo kreirane) okidače. Kako Moira sadrži Graphite, podržava sve njegove funkcije. Stoga najprije uzmete redak i kopirate ga u Grafanu. Pogledate kako se podaci prikazuju na grafikonima. A zatim uzmete isti redak i kopirate ga u Moiru. Povezujete ga s limitima i na izlazu dobivate obavijesti. Da biste sve to radili, ne trebate nikakva specifična znanja. Moira može slati obavijesti putem SMS-a, e-pošte, u Jira, Slack… Također podržava izvršavanje prilagođenih skripti. Kada se dogodi okidač, a ona je prijavljena na prilagođenu skriptu ili binarni program, ona ga pokreće i šalje JSON na stdin tom binarnom programu. Što ćete s tim JSON-om raditi — odlučite sami. Želite — šaljite u Telegram, želite — otvarajte zadatke u Jiri, radite što god želite.
Za obavijesti koristimo još i vlastiti razvoj — Imagotag. Prilagodili smo panel koji se obično koristi za elektroničke cijene u trgovinama, za naše zadatke. Iz Moire smo iznijeli okidače. Tamo je naznačeno u kojem su stanju i kada su se dogodili. Dio članova razvojnog tima odustao je od obavijesti u Slacku i e-pošti u korist ove panel.
Budući da smo progresivna tvrtka, nadzirali smo u ovom sustavu i Kubernetes. Uključili smo ga u sustav putem Heapstera, kojeg smo instalirali u klaster, koji prikuplja podatke i šalje ih u Graphite. Na kraju, shema izgleda ovako:
Komponente nadzora
Evo popisa poveznica na komponente koje smo koristili za ovaj zadatak. Sve su otvorenog koda.
Graphite:
- go-carbon:
- whisper:
- graphite-api:
Carbon-c-relay:
Brubeck:
Collectd:
Moira:
Grafana:
Heapster:
Statistika
Evo nekoliko podataka o tome kako naš sustav radi.
Aggregator (brubeck)
Broj metrike: ~ 300 000 / sek
Interval slanja metrike u Graphite: 30 sek
Korištenje resursa poslužitelja: ~ 6% CPU (govorimo o punopravnim poslužiteljima); ~ 1Gb RAM; ~ 3 Mbps LAN
Graphite (go-carbon)
Broj metrike: ~ 1 600 000 / min
Interval ažuriranja metrike: 30 sek
Shema pohrane metrike: 30 sek 35d, 5min 90d, 10min 365d (daje uvid u to što se događa sa servisom na duže vrijeme)
Korištenje resursa poslužitelja: ~ 10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN
Fleksibilnost
U Avitu jako cijenimo fleksibilnost u našem sustavu nadzora. Zašto je to tako? Prvo, njegovi dijelovi su međusobno zamjenjivi: i sami komponenti, i njihove verzije. Drugo — održivost. Budući da je cijeli projekt izgrađen na otvorenom kodu, možete sami uređivati kod, unositi promjene, implementirati funkcije koje nisu dostupne van kutije. Koriste se dovoljno uobičajeni stekovi, uglavnom, Go i Python, tako da to ide prilično lako.
Evo primjera stvarnog problema. Metrika u Graphiteu je datoteka. Ima svoje ime. Ime datoteke = ime metrike. I postoji put do nje. Imena datoteka u Linuxu su ograničena na 255 znakova. A imamo (kao 'unutarnje naručitelje') ekipu iz odjela za baze podataka. Oni nam kažu: 'Želimo pratiti naše SQL upite. A to nisu 255 znakova, već 8 MB svaki. Želimo ih prikazivati u Grafani, vidjeti parametre za taj upit, a još bolje, želimo vidjeti top takvih upita. Bilo bi sjajno ako bi se prikazivao u stvarnom vremenu. A bilo bi sjajno kad bi ih mogli ubaciti u upozorenja.'
Primjer SQL upita uzet je kao primjer s
Pokrećemo Redis server zajedno s našim Collectd pluginovima koji idu u Postgres i preuzimaju sve podatke, šaljemo metrike u Graphite. Međutim, mijenjamo ime metrike u hash. Taj isti hash istovremeno šaljemo u Redis kao ključ, a cijeli SQL upit kao vrijednost. Ostalo nam je samo osigurati da Grafana može pristupiti Redis-u i preuzeti te informacije. Otvaramo Graphite API jer je to glavno sučelje za interakciju svih komponenti monitoringa s Graphite-om, i dodajemo novu funkciju koja se zove aliasByHash() — od Grafane dobivamo ime metrike i koristimo ga u upitu prema Redis-u kao ključ, a kao odgovor dobivamo vrijednost ključa, koja je naš "SQL upit". Na taj način smo u Grafanu prikazali SQL upit koji inače nije bilo moguće prikazati, zajedno sa statistikama (calls, rows, total_time, …).
Zaključci
Dostupnost. Naša usluga monitoringa dostupna je 24/7 iz bilo koje aplikacije i bilo kojeg koda. Ako imate pristup skladištima, možete slati podatke u servis. Jezik nije bitan, rješenja nisu bitna. Sve što trebate je znati kako otvoriti socket, poslati metriku i zatvoriti socket.
Pouzdanost. Sve komponente su otporne na greške i dobro se nose s našim opterećenjima.
Nizak ulazni prag. Da biste koristili ovaj sustav, ne trebate učiti programske jezike ili upite u Grafani. Jednostavno otvorite svoju aplikaciju, upišete socket koji će slati metrike u Graphite, zatvorite ga, otvorite Grafanu, kreirate nadzorne ploče i promatrate ponašanje svojih metrike, dobivajući obavijesti putem Moira.
Samostalnost. Sve to možete raditi sami, bez pomoći DevOps inženjera. I to je overkill, jer možete pratiti svoj projekt odmah, ne trebate nikoga pitati — ni za početak rada, ni za promjene.
Čemu težimo?
Sve navedeno dolje nije samo apstraktna razmišljanja, već su to ciljevi prema kojima smo napravili barem prve korake.
- Detektor anomalija. Želimo razviti uslugu koja će odlaziti u naše Graphite spremnike i provjeravati svaku metriku prema različitim algoritmima. Već imamo algoritme koje želimo pregledavati, imamo podatke i znamo s njima raditi.
- Metapodaci. Imamo mnogo usluga koje se s vremenom mijenjaju, kao i ljudi koji s njima rade. Stalno vođenje dokumentacije ručno nije opcija. Zbog toga se sada u naše mikroslužbe ugrađuju metapodaci. Tu je navedeno tko ih je razvio, jezike s kojima surađuje, zahtjeve za SLA, kamo i kome slati obavijesti. Prilikom implementacije usluge svi podaci entiteta se stvaraju automatski. Na kraju dobivate dvije veze — jedna za okidače, druga za nadzorne ploče u Grafani.
- Praćenje u svaku kuću. Smatramo da bi ovakav sustav trebali koristiti svi programeri. U tom slučaju uvijek znate gdje je vaš promet, što se s njim događa, gdje pada, gdje su mu slabe točke. Ako, recimo, dođe nešto i sruši vašu uslugu, saznat ćete za to ne tijekom poziva od menadžera, već od upozorenja, i odmah ćete moći otvoriti svježe logove i pogledati što se dogodilo.
- Visoka izvedba. Naš projekt konstantno raste, i danas obrađuje oko 2.000.000 vrijednosti metrike u minuti. Prije godine taj je pokazatelj iznosio 500.000. A rast se nastavlja, što znači da će uskoro Graphite (whisper) snažno opteretiti diskovni sustav. Kao što sam već spomenuo, ovaj sustav praćenja je prilično univerzalan zbog zamjenjivosti komponenti. Netko posebno održava infrastrukturu za Graphite i neprekidno je proširuje, ali mi smo odlučili krenuti drugim putem: koristiti kao skladište naših metrika. Ova promjena je gotovo završena, i uskoro ću detaljnije objasniti kako je to izvedeno: s kojim smo se teškoćama suočili i kako su one prevladane, kako je tekao proces migracije, opisaću odabrane komponente za povezivanje i njihove konfiguracije.
Hvala na pozornosti! Slobodno postavite svoja pitanja po temi, nastojat ću odgovoriti ovdje ili u sljedećim objavama. Moguće je da netko ima iskustva u izgradnji sličnog sustava praćenja ili prelasku na Clickhouse u sličnim situacijama — podijelite to u komentarima.
Izvor: habr.com
