Oghje, in più di u codice monoliticu, u nostru prughjettu include decine di microservizi. Ognunu di elli deve esse monitoratu. Fà questu in una tale scala cù l'ingegneri DevOps hè problematicu. Avemu sviluppatu un sistema di monitoraghju chì travaglia cum'è un serviziu per i sviluppatori. Puderanu indipindentamente scrive metriche in u sistema di monitoraghju, aduprate, custruisce dashboards basati nantu à elli, è aghjunghje avvisi à elli chì saranu attivati quandu i valori di soglia sò righjunti. Per l'ingegneri DevOps, solu infrastruttura è documentazione.
Questu post hè una trascrizione di u mo discorsu cù u nostru à RIT++. Parechje persone ci anu dumandatu di fà versioni di testu di rapporti da quì. Sè site in a cunferenza o avete vistu u video, ùn truverete nunda di novu. È tutti l'altri - benvenuti à u ghjattu. Vi dicu cumu avemu ghjuntu à un tali sistema, cumu funziona è cumu pensamu à aghjurnà.
U passatu: schemi è piani
Cumu avemu ghjuntu à u sistema di monitoraghju attuale? Per risponde à sta quistione, avete bisognu à andà in 2015. Eccu ciò chì pareva allora:
Avemu avutu circa 24 nodi chì eranu rispunsevuli di u monitoraghju. Ci hè un pacchettu sanu di diverse corone, scripts, daemons chì in qualchì modu monitoranu qualcosa, mandanu messagi è facenu funzioni. Avemu pensatu chì più andavamu più luntanu, u menu viable un tali sistema seria. Ùn ci hè nunda di sviluppà: hè troppu ingombrante.
Avemu decisu di sceglie quelli elementi di monitoraghju chì mantenemu è sviluppà, è quelli chì abbandunemu. Ci eranu 19. Solu grafiti, aggregatori è Grafana cum'è un dashboard restanu. Ma cumu serà u novu sistema? Cum'è què:
Avemu un almacenamentu di metrica: questi sò grafiti, chì saranu basati in unità SSD veloci, sò certi aggregatori per metriche. Next - Grafana per vede dashboards è Moira per alerting. Vulemu ancu sviluppà un sistema per a ricerca di anomalie.
Standard: Monitoring 2.0
Hè ciò chì i piani parevanu in 2015. Ma avemu avutu à preparà micca solu l'infrastruttura è u serviziu stessu, ma ancu a documentazione per questu. Avemu sviluppatu un standard corporativu per noi stessi, chì chjamemu monitoring 2.0. Chì eranu i requisiti per u sistema?
- dispunibilità constante;
- intervallu di almacenamiento di metrica = 10 seconde;
- almacenamiento strutturatu di metriche è dashboards;
- SLA > 99,99%
- cullezzione di metrica di l'eventi via UDP (!).
Avemu bisognu di UDP perchè avemu un grande flussu di trafficu è avvenimenti chì generanu metriche. Se li scrivite tutti in grafite à una volta, u almacenamentu colapserà. Avemu ancu sceltu prefissi di primu livellu per tutte e metriche.
Ogni prefissi hà qualchì pruprietà. Ci sò metriche per i servitori, rete, cuntenituri, risorse, applicazioni, etc. Un filtru chjaru, strettu, tipatu hè statu implementatu, induve accettemu metriche di primu livellu è simpricimenti abbandunate u restu. Hè cusì chì avemu pianificatu stu sistema in 2015. Chì ci hè in u presente ?
Presente: schema di interazzione di cumpunenti di monitoraghju
Prima di tuttu, monitoremu l'applicazioni: u nostru codice PHP, l'applicazioni è i microservizi - in corta, tuttu ciò chì i nostri sviluppatori scrivenu. Tutte l'applicazioni mandanu metriche via UDP à l'agregatore Brubeck (statsd, riscritta in C). Risultava esse u più veloce in testi sintetici. È manda e metriche digià aggregate à Grafite via TCP.
Havi un tipu di metrica chjamata timers. Questu hè una cosa assai còmuda. Per esempiu, per ogni cunnessione d'utilizatori à u serviziu, mandate una metrica cù u tempu di risposta à Brubeck. Un milione di risposti sò ghjunti, ma l'agregatore hà tornatu solu 10 metriche. Avete u numeru di persone chì venenu, u tempu di risposta massimu, minimu è mediu, a mediana è 4 percentiles. Allora i dati sò trasferiti à Grafite è vedemu tuttu in diretta.
Avemu ancu aggregazione per metriche nantu à hardware, software, metrica di u sistema è u nostru vechju sistema di monitoraghju Munin (hà travagliatu per noi finu à 2015). Cullemu tuttu questu attraversu u C daemon CollectD (hà una mansa di diversi plugins integrati in questu, pò sondaghju tutte e risorse di u sistema di l'ospiti nantu à quale hè stallatu, solu specificà in a cunfigurazione induve scrive i dati) è scrivite i dati à Graphite attraversu. Supporta ancu i plugins di python è i script di shell, cusì pudete scrive e vostre solu suluzioni persunalizati: CollectD raccoglierà queste dati da un host locale o remoto (assumendu Curl) è l'invià à Graphite.
Allora mandemu tutte e metriche chì avemu cullatu à Carbon-c-relay. Questa hè a suluzione di Carbon Relay da Graphite, mudificatu in C. Questu hè un router chì cullighja tutte e metriche chì avemu mandatu da i nostri aggregatori è i percorsi à i nodi. Ancu in u stadiu di routing, verifica a validità di e metriche. Prima, devenu currisponde à u schema di prefissu chì aghju dimustratu prima è, secondu, sò validi per u grafitu. Altrimenti caderanu.
Carbon-c-relay poi manda a metrica à u cluster di Grafite. Avemu aduprà Carbon-cache, riscritta in Go, cum'è u principale almacenamiento di metrica. Go-carbon, per via di u so multithreading, supera assai di Carbon-cache. Riceve dati è scrive à i dischi cù u pacchettu sussurru (standard, scrittu in python). Per leghje e dati da i nostri magazzini, usemu l'API Graphite. Hè assai più veloce di u standard di Grafite WEB. Chì succede à i dati dopu?
Vannu à Grafana. Utilizemu i nostri clusters di grafite cum'è a fonte principale di dati, in più avemu Grafana cum'è una interfaccia web per visualizà metriche è custruisce dashboards. Per ognunu di i so servizii, i sviluppatori creanu u so propiu dashboard. Allora custruiscenu grafici basati nantu à elli, chì mostranu e metriche chì scrivenu da e so applicazioni. In più di Grafana, avemu ancu SLAM. Questu hè un dimoniu pitone chì calcula SLA basatu nantu à e dati da u grafitu. Cum'è l'aghju digià dettu, avemu parechje decine di microservizi, ognunu di i quali hà i so bisogni. Utilizendu SLAM, andemu à a ducumentazione è paragunate cù ciò chì hè in Grafite è paragunate cumu bè i requisiti currispondenu à a dispunibilità di i nostri servizii.
Andemu più in là : alerte. Hè urganizatu cù un sistema forte - Moira. Hè indipendente perchè hà u so propiu Grafite sottu u cappucciu. Sviluppatu da i ragazzi da SKB "Kontur", scrittu in python è Go, cumplettamente open source. Moira riceve u stessu flussu chì entra in grafiti. Se per una certa ragione u vostru almacenamentu mori, u vostru alerting hà sempre travagliatu.
Avemu implementatu Moira in Kubernetes; usa un cluster di servitori Redis cum'è a basa di dati principale. U risultatu era un sistema tollerante à i difetti. Compara u flussu di metrica cù a lista di triggers: se ùn ci hè micca menzione in questu, allora abbanduneghja a metrica. Cusì hè capaci di digerirà gigabytes di metriche per minutu.
Avemu ancu attaccatu un LDAP corporativu à questu, cù l'aiutu di quale ogni utilizatore di u sistema corporativu pò creà notificazioni per ellu stessu basatu annantu à i triggers esistenti (o di novu creatu). Siccomu Moira cuntene Grafite, sustene tutte e so funziunalità. Allora prima pigliate a linea è copiate in Grafana. Vede cumu i dati sò visualizati nantu à i grafici. E poi pigliate a stessa linea è copiate in Moira. L'appiccicate cù i limiti è avete un avvisu à l'output. Per fà tuttu questu, ùn avete micca bisognu di cunniscenze specifiche. Moira pò avvistà via SMS, email, Jira, Slack ... Supporta ancu l'esekzione di scripts persunalizati. Quandu un trigger succedi à ella, è ella hè abbonata à un script persunalizatu o binariu, l'executa è manda JSON à stdin per questu binariu. Per quessa, u vostru prugramma deve analizà. Ciò chì fate cù questu JSON hè di voi. Se vulete, mandate à Telegram, se vulete, aprite i compiti in Jira, fate tuttu.
Avemu ancu aduprà u nostru propiu sviluppu per l'alerta - Imagotag. Avemu adattatu u pannellu, chì hè generalmente utilizatu per i tag di prezzu elettroni in i magazzini, per adattà à i nostri bisogni. Avemu purtatu triggers da Moira. Indica in quale statu si trovanu è quandu sò accaduti. Alcuni di i ragazzi di sviluppu anu abbandunatu notificazioni in Slack è email in favore di stu pannellu.
Ebbè, postu chì simu una cumpagnia progressiva, avemu ancu monitoratu Kubernetes in stu sistema. L'avemu inclusu in u sistema cù Heapster, chì avemu stallatu in u cluster, recullà e dati è l'invia à Graphite. In u risultatu, u diagramma s'assumiglia cusì:
Cumpunenti di monitoraghju
Eccu una lista di ligami per i cumpunenti chì avemu utilizatu per questu compitu. Tutti sò open source.
Grafit:
- go-carbon:
- bisbiglià :
- graphite-api:
Relè carbone-c:
Brubeck:
Raccolta:
Moira:
Grafana:
Heapster:
Статистика
È quì sò parechji numeri nantu à cumu u sistema funziona per noi.
Aggregatore (brubeck)
Numaru di metrica: ~ 300 000/sec
Intervallu per mandà metriche à Grafite: 30 sec
Usu di risorsa di u servitore: ~ 6% CPU (parlemu di servitori cumpleti); ~ 1 Gb RAM; ~ 3 Mbps LAN
Grafite (go-carbon)
Numaru di metrica: ~ 1 / min
Intervallu di aghjurnamentu di metrica: 30 sec
Schema di almacenamentu di metrica: 30sec 35d, 5min 90d, 10min 365d (vi dà una capiscitura di ciò chì succede à u serviziu per un longu periodu di tempu)
Utilizazione di risorse di u servitore: ~ 10% CPU; ~ 20 Gb RAM; ~ 30 Mbps LAN
Flessibilità
Avemu in Avito veramente valore a flessibilità in u nostru serviziu di monitoraghju. Perchè hè veramente fattu cusì? Prima, i so cumpunenti sò intercambiabili: i cumpunenti stessi è e so versioni. Siconda, supportability. Siccomu tuttu u prughjettu hè open source, pudete edità u codice sè stessu, fà cambiamenti è implementà funzioni chì ùn sò micca dispunibili fora di a scatula. Pile abbastanza cumuni sò aduprate, principarmenti Go è Python, cusì hè fattu abbastanza simplice.
Eccu un esempiu di un veru prublema. Una metrica in Graphite hè un schedariu. Hà un nome. File name = nome metricu. È ci hè un modu per arrivà. I nomi di file in Linux sò limitati à 255 caratteri. È avemu (cum'è "clienti internu") ragazzi da u dipartimentu di basa di dati. Ci dicenu: "Vulemu monitorà e nostre dumande SQL. È ùn sò micca 255 caratteri, ma 8 MB ognunu. Vulemu vede in Grafana, vede i paràmetri di sta dumanda, è ancu megliu, vulemu vede a cima di tali richieste. Serà grande s'ellu hè visualizatu in tempu reale. Saria veramente cool di metteli in l'alerta ".
L'esempiu di query SQL hè pigliatu cum'è un esempiu da
Avemu stallatu un servitore Redis è utilizate i nostri plugins Collectd, chì vanu à Postgres è piglianu tutte e dati da quì, mandendu metriche à Graphite. Ma rimpiazzà u nome metricu cù hash. Mandamu simultaneamente u stessu hash à Redis cum'è chjave, è tutta a query SQL cum'è valore. Tuttu ciò chì avemu da fà hè di assicurà chì Grafana pò andà in Redis è piglià sta infurmazione. Avemu apertu l'API Graphite perchè... Questa hè l'interfaccia principale per l'interazzione di tutti i cumpunenti di monitoraghju cù grafite, è entremu in una nova funzione chjamata aliasByHash() - da Grafana avemu u nome di a metrica, è l'utilizanu in una dumanda à Redis cum'è chjave, in risposta avemu u valore di a chjave, chì hè a nostra "query SQL" " Cusì, avemu mostratu in Grafana una visualizazione di una query SQL, chì in teoria era impussibile di vede quì, cù statistiche nantu à questu (chjamate, fila, total_time, ...).
Risultati
Disponibilidad U nostru serviziu di surviglianza hè dispunibule 24/7 da ogni applicazione è qualsiasi codice. Se avete accessu à e facilità di almacenamiento, pudete scrive dati à u serviziu. A lingua ùn hè micca impurtante, e decisioni ùn sò micca impurtanti. Solu bisognu di sapè cumu apre un socket, mette una metrica quì è chjude u socket.
Affidabilità Tutti i cumpunenti sò tolleranti à i difetti è manighjanu bè i nostri carichi.
Bassa barriera à l'entrata. Per utilizà stu sistema, ùn avete micca bisognu di amparà lingue di prugrammazione è dumande in Grafana. Basta apre a vostra applicazione, inserisci un socket in questu chì mandarà metriche à Graphite, chjude, apre Grafana, crea dashboards quì è fighjate u cumpurtamentu di e vostre metriche, riceve notificazioni attraversu Moira.
Independenza. Pudete fà tuttu questu sè stessu, senza l'aiutu di l'ingegneri DevOps. È questu hè un vantaghju, perchè pudete monitorà u vostru prughjettu avà, ùn avete micca dumandà à nimu - sia per inizià u travagliu sia per fà cambiamenti.
Chì ci volemu ?
Tuttu ciò chì elencatu quì sottu ùn hè micca solu pinsamenti astratti, ma qualcosa versu quale almenu i primi passi sò stati fatti.
- Rilevatore di anomalie. Vulemu creà un serviziu chì andarà à i nostri magazzini di Grafite è verificate ogni metrica utilizendu diversi algoritmi. Ci hè digià algoritmi chì vulemu vede, ci sò dati, sapemu cumu travaglià cun ellu.
- Metadata. Avemu parechji servizii, cambianu cù u tempu, cum'è e persone chì travaglianu cun elli. Mantene in permanenza a documentazione manualmente ùn hè micca una opzione. Hè per quessa chì avà incrustendu metadati in i nostri microservizi. Indica quale hà sviluppatu, e lingue cù quale interagisce, i requisiti SLA, induve è à quale deve esse mandate e notificazioni. Quandu implementate un serviziu, tutti i dati di l'entità sò creati indipindentamente. In u risultatu, avete dui ligami - unu à i triggers, l'altru à i dashboards in Grafana.
- Monitoraghju in ogni casa. Cridemu chì tutti i sviluppatori devenu aduprà un tali sistema. In questu casu, avete sempre capitu induve hè u vostru trafficu, ciò chì succede, induve casca, induve sò i so punti debbuli. Sè, per esempiu, qualcosa vene è crashes u vostru serviziu, allura vi amparà circa lu micca durante una chiamata da u manager, ma da una alerta, è vi ponu subitu apre l 'ultimi logs è vede ciò chì hè accadutu.
- Alte prestazioni. U nostru prughjettu hè in constantemente crescente, è oghje processa circa 2 000 000 valori metrici per minutu. Un annu fà, sta figura era 500 000. E a crescita cuntinueghja, è questu significa chì dopu à qualchì tempu Grafite (sussurru) cumincià à carricà assai u subsistema di discu. Cum'è aghju dettu, stu sistema di surviglianza hè abbastanza universale per via di l'intercambiabilità di cumpunenti. Qualchissia mantene è espansione constantemente a so infrastruttura specificamente per Graphite, ma avemu decisu di andà in una strada diversa: aduprà cum'è un repository per e nostre metriche. Sta transizione hè guasi cumpleta, è assai prestu vi dicu in più dettagliu cumu hè stata fatta: quali difficultà ci sò stati è cumu si sò stati superati, cumu si passava u prucessu di migrazione, vi discriverà i cumpunenti scelti cum'è ubligatoriu è e so cunfigurazioni.
Grazie per a vostra attenzione! Fate e vostre dumande nantu à u tema, pruvaraghju à risponde quì o in i seguenti posti. Forse qualcunu hà sperienza di custruisce un sistema di monitoraghju simile o di cambià à Clickhouse in una situazione simili - sparte in i cumenti.
Source: www.habr.com