Danas, pored monolitnog koda, naš projekat uključuje desetine mikroservisa. Svaki od njih zahtijeva praćenje. Učiniti ovo u takvom obimu pomoću DevOps inženjera je problematično. Razvili smo sistem nadzora koji radi kao servis za programere. Oni mogu samostalno upisivati metrike u sistem za praćenje, koristiti ih, graditi kontrolne table na osnovu njih i priložiti im upozorenja koja će se pokrenuti kada se dostignu granične vrijednosti. Za DevOps inženjere, samo infrastruktura i dokumentacija.
Ovaj post je transkript mog govora sa našim na RIT++. Mnogi su nas tražili da odatle napravimo tekstualne verzije izvještaja. Ako ste bili na konferenciji ili gledali video, nećete pronaći ništa novo. A svi ostali - dobrodošli mačku. Reći ću vam kako smo došli do takvog sistema, kako funkcioniše i kako planiramo da ga ažuriramo.
Prošlost: šeme i planovi
Kako smo došli do trenutnog sistema praćenja? Da biste odgovorili na ovo pitanje, morate otići u 2015. Ovako je to tada izgledalo:
Imali smo oko 24 čvora koji su bili zaduženi za praćenje. Postoji čitav paket različitih kruna, skripti, demona koji na neki način nešto nadziru, šalju poruke i izvršavaju funkcije. Mislili smo da što dalje idemo, takav sistem će biti manje održiv. Nema smisla razvijati ga: previše je glomazan.
Odlučili smo odabrati one elemente praćenja koje ćemo zadržati i razvijati, i one koje ćemo napustiti. Bilo ih je 19. Ostali su samo grafiti, agregatori i Grafana kao instrument tabla. Ali kako će izgledati novi sistem? Volim ovo:
Imamo skladište metrike: to su grafiti, koji će biti bazirani na brzim SSD diskovima, to su određeni agregatori za metriku. Sljedeće - Grafana za prikaz kontrolne table i Moira za upozorenje. Takođe smo želeli da razvijemo sistem za traženje anomalija.
Standard: Monitoring 2.0
Ovako su izgledali planovi 2015. Ali morali smo pripremiti ne samo infrastrukturu i sam servis, već i dokumentaciju za njega. Za sebe smo razvili korporativni standard koji nazivamo monitoring 2.0. Koji su bili zahtjevi za sistem?
- stalna dostupnost;
- interval skladištenja metrike = 10 sekundi;
- strukturirano skladištenje metrike i nadzornih ploča;
- SLA > 99,99%
- prikupljanje metrike događaja putem UDP-a (!).
UDP nam je bio potreban jer imamo veliki protok saobraćaja i događaja koji generišu metriku. Ako ih sve odjednom upišete u grafit, skladište će se srušiti. Također smo odabrali prefikse prvog nivoa za sve metrike.
Svaki od prefiksa ima neko svojstvo. Postoje metrike za servere, mreže, kontejnere, resurse, aplikacije itd. Implementirano je jasno, strogo, tipizirano filtriranje, gdje prihvatamo metriku prvog nivoa i jednostavno ispuštamo ostatak. Ovako smo planirali ovaj sistem 2015. godine. Šta je u sadašnjosti?
Prisutno: dijagram interakcije komponenti praćenja
Prije svega, pratimo aplikacije: naš PHP kod, aplikacije i mikroservise – ukratko, sve što naši programeri pišu. Sve aplikacije šalju metriku preko UDP-a u Brubeck agregator (statsd, prepisan u C). Pokazalo se da je najbrži u sintetičkim testovima. I šalje već agregirane metrike u Graphite preko TCP-a.
Ima vrstu metrike koja se zove tajmeri. Ovo je veoma zgodna stvar. Na primjer, za svaku korisničku vezu s uslugom šaljete metriku s vremenom odgovora Brubecku. Pristiglo je milion odgovora, ali agregator je vratio samo 10 metrika. Imate broj ljudi koji su došli, maksimalno, minimalno i prosječno vrijeme odgovora, medijanu i 4 percentila. Zatim se podaci prenose u Graphite i sve to vidimo uživo.
Također imamo agregaciju za metriku na hardveru, softveru, sistemsku metriku i naš stari Munin sistem za praćenje (radio je za nas do 2015.). Sve ovo prikupljamo preko C demona CollectD (ima čitavu gomilu različitih dodataka ugrađenih u njega, može anketirati sve resurse host sistema na kojem je instaliran, samo navedite u konfiguraciji gdje da upišete 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 hosta (pod pretpostavkom Curl) i poslati ih Graphiteu.
Zatim šaljemo sve metrike koje smo prikupili u Carbon-c-relay. Ovo je Graphite rješenje Carbon Relay, modificirano u C. Ovo je ruter koji prikuplja sve metrike koje šaljemo od naših agregatora i usmjerava ih do čvorova. Takođe 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 grafitnom klasteru. Koristimo Carbon-cache, prepisan u Go, kao glavno skladište metrike. Go-carbon, zbog svoje višenitnosti, daleko nadmašuje Carbon-cache. Prima podatke i zapisuje ih na diskove koristeći šapat paket (standardan, napisan na pythonu). Za čitanje podataka iz naših skladišta koristimo Graphite API. Mnogo je brži od standardnog Graphite WEB-a. Šta se dalje događa s podacima?
Odlaze u Grafanu. Koristimo naše grafitne klastere kao glavni izvor podataka, plus imamo Grafanu kao web sučelje za prikaz metrike i izgradnju nadzornih ploča. Za svaku od svojih usluga programeri kreiraju vlastitu kontrolnu ploču. Zatim grade grafikone na osnovu njih, koji prikazuju metriku koju pišu iz svojih aplikacija. Pored Grafane imamo i SLAM. Ovo je python demon koji izračunava SLA na osnovu podataka iz grafita. Kao što sam već rekao, imamo nekoliko desetina mikroservisa, od kojih svaki ima svoje zahtjeve. Koristeći SLAM, idemo na dokumentaciju i upoređujemo je sa onim što je u Graphite-u i upoređujemo koliko se zahtjevi podudaraju s dostupnošću naših usluga.
Idemo dalje: uzbunjivanje. Organizirano je po snažnom sistemu - Moira. Nezavisan je jer ima svoj Graphite ispod haube. Razvijen od strane momaka iz SKB "Kontur", napisan na python i Go, potpuno open source. Mojra prima isti protok koji ide u grafit. Ako iz nekog razloga vaša pohrana umre, vaše upozorenje će i dalje raditi.
Moira smo postavili u Kubernetes; ona koristi klaster Redis servera kao glavnu bazu podataka. Rezultat je bio sistem otporan na greške. On uspoređuje tok metrike sa listom okidača: ako u njemu nema spominjanja, onda ispušta metriku. Tako da je u stanju da probavi gigabajte metrike u minuti.
Uz njega smo priložili i korporativni LDAP, uz pomoć kojeg svaki korisnik korporativnog sistema može za sebe kreirati obavijesti na osnovu postojećih (ili novokreiranih) trigera. Pošto Moira sadrži grafit, podržava sve njegove karakteristike. Dakle, prvo uzmete liniju i kopirate je u Grafanu. Pogledajte kako su podaci prikazani na grafikonima. I onda uzmete isti red i kopirate ga u Moira. Objesite ga s ograničenjima i dobijete upozorenje na izlazu. Da biste sve ovo uradili, nije vam potrebno nikakvo posebno znanje. Moira može upozoravati putem SMS-a, e-pošte, Jira, Slack-a... Takođe podržava izvršavanje prilagođenih skripti. Kada joj se desi okidač, a ona je pretplaćena na prilagođenu skriptu ili binarnu datoteku, ona je pokreće i šalje JSON na stdin za ovu binarnu datoteku. Shodno tome, vaš program ga mora raščlaniti. Šta ćete uraditi sa ovim JSON-om zavisi od vas. Ako hoćeš pošalji na Telegram, ako hoćeš otvori zadatke u Jira, radi šta god.
Za dojavu koristimo i vlastiti razvoj - Imagotag. Panel, koji se obično koristi za elektronske cjenovnike u trgovinama, prilagodili smo našim potrebama. Donijeli smo okidače iz Moire. Označava u kakvom su stanju i kada su se dogodili. Neki od razvojnih momaka su odustali od obavijesti u Slack-u i e-pošte u korist ovog panela.
Pa, pošto smo mi progresivna kompanija, pratili smo i Kubernetes u ovom sistemu. Uključili smo ga u sistem koristeći Heapster koji smo instalirali u klaster, on prikuplja podatke i šalje ih Graphite-u. Kao rezultat, dijagram izgleda ovako:
Monitoring Components
Evo liste veza do komponenti koje smo koristili za ovaj zadatak. Svi su otvorenog koda.
grafit:
- go-carbon:
- šapni:
- grafit-api:
Carbon-c-relej:
Brubeck:
Prikupljeno:
mojra:
Grafana:
heapster:
Статистика
A evo i nekoliko brojeva o tome kako sistem radi za nas.
Agregator (brubeck)
Broj metrika: ~300/sec
Interval za slanje metrike u Graphite: 30 sec
Korišćenje resursa servera: ~ 6% CPU-a (govorimo o punopravnim serverima); ~ 1Gb RAM; ~3 Mbps LAN
grafit (go-carbon)
Broj metrika: ~ 1 / min
Interval ažuriranja metrike: 30 sek
Šema pohrane metrike: 30sec 35d, 5min 90d, 10min 365d (daje vam razumijevanje šta se dešava sa uslugom tokom dužeg vremenskog perioda)
Korišćenje resursa servera: ~10% CPU; ~ 20Gb RAM; ~30 Mbps LAN
Fleksibilnost
Mi u Avitou zaista cijenimo fleksibilnost u našoj usluzi nadzora. Zašto je zapravo ovako ispao? Prvo, njegove komponente su zamjenjive: i same komponente i njihove verzije. Drugo, podrška. 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 stekovi, uglavnom Go i Python, tako da se to radi prilično jednostavno.
Evo primjera stvarnog problema. metrika u Graphite je datoteka. Ima ime. Ime datoteke = naziv metrike. I postoji način da se tamo stigne. Nazivi datoteka u Linuxu su ograničeni na 255 znakova. I imamo (kao „interne kupce“) momke iz odjela baze podataka. Kažu nam: „Želimo pratiti naše SQL upite. I nisu 255 karaktera, već po 8 MB. Želimo ih prikazati u Grafani, vidjeti parametre za ovaj zahtjev, a još bolje, želimo vidjeti vrh takvih zahtjeva. Biće sjajno ako se prikazuje u realnom vremenu. Bilo bi stvarno super staviti ih na uzbunu.”
Primjer SQL upita uzet je kao primjer iz
Postavljamo Redis server i koristimo naše Collectd dodatke, koji idu u Postgres i preuzimaju sve podatke odatle, šaljući metriku u Graphite. Ali ime metrike zamjenjujemo hešovima. Istovremeno šaljemo isti hash Redis-u 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 glavni interfejs za interakciju svih komponenti za praćenje sa grafitom i tu unosimo novu funkciju pod nazivom aliasByHash() - od Grafane dobijamo naziv metrike, i koristimo ga u zahtevu Redis-u kao ključ, u odgovor dobijamo vrijednost ključa, što je naš "SQL upit" " Tako smo u Grafani prikazali prikaz SQL upita, koji je teoretski bilo nemoguće tamo prikazati, zajedno sa statistikom o njemu (pozivi, redovi, ukupno_vrijeme,...).
Ishodi
Dostupnost. Naša usluga praćenja dostupna je 24/7 iz bilo koje aplikacije i bilo kojeg koda. Ako imate pristup skladišnim prostorima, možete upisati podatke u uslugu. Nije bitan jezik, nisu važne odluke. Vi samo trebate znati kako otvoriti utičnicu, staviti metriku tamo i zatvoriti utičnicu.
Pouzdanost. Sve komponente su otporne na greške i dobro podnose naša opterećenja.
Niska barijera za ulazak. Da biste koristili ovaj sistem, ne morate učiti programske jezike i upite u Grafani. Samo otvorite svoju aplikaciju, unesite utičnicu u nju koja će slati metriku u Graphite, zatvorite je, otvorite Grafanu, kreirajte nadzorne ploče tamo i pogledajte ponašanje vaših metrika, primajući obavijesti putem Moire.
Nezavisnost. Sve ovo možete učiniti sami, bez pomoći DevOps inženjera. I to je prednost, jer možete pratiti svoj projekat upravo sada, ne morate nikoga pitati - bilo da započne rad ili da izvrši promjene.
Šta ciljamo?
Sve dole navedeno nisu samo apstraktne misli, već nešto ka čemu su učinjeni barem prvi koraci.
- Detektor anomalija. Želimo kreirati uslugu koja će ići u naše Graphite skladišta i provjeravati svaku metriku koristeći različite algoritme. Već postoje algoritmi koje želimo da vidimo, postoje podaci, znamo kako da radimo sa njima.
- Metapodaci. Imamo mnogo usluga, one se vremenom mijenjaju, baš kao i ljudi koji sa njima rade. Stalno ručno održavanje dokumentacije nije opcija. Zato sada ugrađujemo metapodatke u naše mikroservise. Navodi ko ga je razvio, jezike sa kojima komunicira, SLA zahtjeve, gdje i kome treba slati obavijesti. Prilikom implementacije usluge svi podaci entiteta se kreiraju nezavisno. Kao rezultat, dobijate dvije veze - jednu do trigera, drugu do nadzornih ploča u Grafani.
- Monitoring u svakom domu. Vjerujemo da bi svi programeri trebali koristiti takav sistem. U ovom slučaju uvek razumete gde je vaš saobraćaj, šta se sa njim dešava, gde pada, gde su njegove slabosti. Ako, na primjer, nešto dođe i sruši vašu uslugu, onda ćete o tome saznati ne tokom poziva menadžera, već iz upozorenja, i možete odmah otvoriti najnovije zapise i vidjeti šta se tamo dogodilo.
- Visoke performanse. Naš projekat stalno raste, a danas obrađuje oko 2 metričkih vrijednosti u minuti. Prije godinu dana ova brojka je bila 000 000. I rast se nastavlja, a to znači da će nakon nekog vremena Graphite (šapat) početi jako opterećivati podsistem diska. Kao što sam već rekao, ovaj sistem nadzora je prilično univerzalan zbog zamjenjivosti komponenti. Neko održava i stalno proširuje svoju infrastrukturu posebno za Graphite, ali mi smo odlučili krenuti drugim putem: koristiti kao spremište za naše metrike. Ova tranzicija je skoro gotova, a vrlo brzo ću vam detaljnije reći kako je to učinjeno: koje su poteškoće postojale i kako su prevaziđene, kako je tekao proces migracije, opisaću komponente odabrane kao obvezujuće i njihove konfiguracije.
Hvala vam na pažnji! Postavljajte svoja pitanja na temu, pokušat ću odgovoriti ovdje ili u sljedećim postovima. Možda neko ima iskustva u izgradnji sličnog sistema za praćenje ili prelasku na Clickhouse u sličnoj situaciji - podijelite to u komentarima.
izvor: www.habr.com