Avemu pensatu à creà un sistema di surviglianza in u stadiu di furmà squadre di produttu. Hè diventatu chjaru chì a nostra attività - sfruttamentu - ùn cascà micca in queste squadre. Perchè hè questu?
U fattu hè chì tutti i nostri squadre sò custruiti intornu à i sistemi d'infurmazioni individuali, i microservizii è i fronti, cusì i squadre ùn vedenu micca a salute generale di u sistema sanu in tuttu. Per esempiu, ùn ponu micca sapè cumu una piccula parte in u backend deep influenza u front end. U so scopu di interessu hè limitatu à i sistemi cù quale u so sistema hè integratu. Se una squadra è u so serviziu A ùn anu quasi nisuna cunnessione cù u serviziu B, allora un tali serviziu hè quasi invisibili à a squadra.
A nostra squadra, à u turnu, travaglia cù sistemi chì sò assai integrati cù l'altri: ci sò parechje cunnessione trà elli, questu hè una infrastruttura assai grande. È u funziunamentu di a tenda online dipende di tutti questi sistemi (di quale avemu, per via, un gran numaru).
Allora si trova chì u nostru dipartimentu ùn appartene à alcuna squadra, ma hè situatu un pocu à u latu. In tutta sta storia, u nostru compitu hè di capisce in modu cumpletu cumu funziona i sistemi d'infurmazione, e so funziunalità, integrazioni, software, rete, hardware, è cumu tuttu questu hè cunnessu à l'altri.
A piattaforma nantu à quale operanu i nostri buttreghi in linea hè cusì:
- fronte,
- middle office
- back office
Ùn importa micca quantu vuleriamu, ùn succede micca chì tutti i sistemi funzionanu bè è impeccable. U puntu, di novu, hè u numeru di sistemi è integrazioni - cù qualcosa cum'è a nostra, certi incidenti sò inevitabbili, malgradu a qualità di teste. Inoltre, sia in un sistema separatu sia in quantu à a so integrazione. È avete bisognu di monitorà u statu di tutta a piattaforma in modu cumpletu, è micca solu ogni parte individuale di questu.
Ideale, u monitoraghju di a salute in tutta a piattaforma deve esse automatizatu. È avemu ghjuntu à u monitoraghju cum'è una parte inevitabbile di stu prucessu. Inizialmente, hè stata custruita solu per a parte di prima linea, mentre chì i specialisti di rete, l'amministratori di software è hardware anu avutu è anu sempre i so propri sistemi di surviglianza strata per capa. Tutte queste persone anu seguitu u monitoraghju solu à u so livellu; nimu hà avutu ancu una comprensione cumpleta.
Per esempiu, se una macchina virtuale crashes, in a maiò parte di i casi solu l'amministratore rispunsevuli di u hardware è a macchina virtuale sapi. In tali casi, a squadra di prima linea hà vistu u fattu stessu di u crash di l'applicazione, ma ùn hà micca datu nantu à u crash di a macchina virtuale. È l'amministratore pò sapè quale hè u cliente è avè una idea approssimativa di ciò chì hè attualmente in esecuzione nantu à sta macchina virtuale, sempre chì hè un tipu di grande prughjettu. Probabilmente ùn sapi micca di i chjuchi. In ogni casu, l'amministratore deve andà à u pruprietariu è dumandà ciò chì era nantu à sta macchina, ciò chì deve esse restauratu è ciò chì deve esse cambiatu. E s'è qualcosa veramente seriu s'hè rottu, cuminciaru à curriri in cerchi - perchè nimu hà vistu u sistema in tuttu.
In ultimamente, storie cusì disparate afectanu tuttu u frontend, l'utilizatori è a nostra funzione core business - vendita in linea. Siccomu ùn simu micca parte di una squadra, ma sò impegnati in l'operazione di tutte l'applicazioni di ecommerce cum'è parte di una tenda in linea, avemu pigliatu u compitu di creà un sistema di monitoraghju cumpletu per a piattaforma di ecommerce.
Struttura di u sistema è stack
Avemu principiatu per identificà parechji strati di monitoraghju per i nostri sistemi, in quale avemu bisognu di cullà metriche. È tuttu ciò chì deve esse cumminatu, chì hè ciò chì avemu fattu in u primu stadiu. Avà in questa tappa simu finalizendu a cullezzione di metrica di più alta qualità in tutti i nostri strati per custruisce una correlazione è capisce cumu i sistemi influenzanu l'altri.
A mancanza di monitoraghju cumpletu in e fasi iniziali di u lanciu di l'applicazione (dapoi chì avemu cuminciatu à custruisce quandu a maiò parte di i sistemi eranu in produzzione) hà purtatu à u fattu chì avemu avutu un debitu tecnicu significativu per stabilisce u monitoraghju di tutta a piattaforma. Ùn pudemu micca permette di fucalizza nantu à a stallazione di u monitoraghju per un IS è di travaglià u monitoraghju per ellu in dettagliu, postu chì u restu di i sistemi seranu lasciati senza monitoraghju per qualchì tempu. Per risolve stu prublema, avemu identificatu una lista di e metriche più necessarie per evaluà u statu di u sistema d'infurmazione per strati è cuminciaru à implementà.
Per quessa, anu decisu di manghjà l'elefante in parte.
U nostru sistema hè custituitu da:
- hardware;
- sistema upirativu;
- software;
- Parti UI in l'applicazione di monitoraghju;
- metrica cummerciale;
- applicazioni di integrazione;
- sicurità di l'infurmazioni;
- rete;
- equilibrador di trafficu.
À u centru di stu sistema hè u monitoraghju stessu. Per capisce in generale u statu di tuttu u sistema, avete bisognu di sapè ciò chì succede cù l'applicazioni nantu à tutti questi strati è in tuttu u settore di applicazioni.
Allora, nantu à a pila.
Avemu aduprà software open source. À u centru avemu Zabbix, chì avemu usatu principalmente cum'è un sistema d'alerta. Tuttu u mondu sapi chì hè ideale per u monitoraghju di l'infrastruttura. Chì significà questu? Esattamente quelli metrichi di livellu bassu chì ogni cumpagnia chì mantene u so propiu centru di dati hà (è Sportmaster hà i so centri di dati) - temperatura di u servitore, statutu di memoria, raid, metrica di u dispositivu di rete.
Avemu integratu Zabbix cù u messenger di Telegram è Microsoft Teams, chì sò attivamente utilizati in squadre. Zabbix copre a strata di a rete attuale, hardware è qualchì software, ma ùn hè micca una panacea. Avemu arricchisci sta dati da qualchi altri servizii. Per esempiu, à u nivellu di hardware, cunnettamu direttamente via API à u nostru sistema di virtualizazione è recullemu dati.
Ciò chì. In più di Zabbix, usemu Prometheus, chì ci permette di monitorà e metriche in una applicazione di l'ambiente dinamicu. Vale à dì, pudemu riceve metriche di l'applicazioni via un endpoint HTTP è ùn preoccupate micca di quale metrica carica in questu è quale micca. Basatu nantu à sti dati, e dumande analitiche ponu esse sviluppate.
I fonti di dati per altri strati, per esempiu, metriche di l'affari, sò divisi in trè cumpunenti.
Prima, questi sò sistemi di cummerciale esterni, Google Analytics, cullemu metriche da logs. Da elli avemu a dati nantu à l'utilizatori attivi, cunversione è tuttu ciò chì tocca à l'affari. Siconda, questu hè un sistema di monitoraghju UI. Si deve esse discrittu in più detail.
Una volta avemu principiatu cù testi manuali è hè diventatu in teste automatiche di funziunalità è integrazioni. Da questu avemu fattu u monitoraghju, lascendu solu a funziunalità principale, è s'appoghjanu nantu à i marcatori chì sò stabile quant'è pussibule è ùn cambianu micca spessu cù u tempu.
A nova struttura di squadra significa chì tutte l'attività di l'applicazione sò limitate à e squadre di produttu, cusì avemu cessatu di fà una prova pura. Invece, avemu fattu u monitoraghju UI da e teste, scritte in Java, Selenium è Jenkins (usatu cum'è sistema per lancià è generà rapporti).
Avemu avutu assai teste, ma à a fine avemu decisu di andà à a strada principale, a metrica di u primu livellu. È s'è avemu assai testi specifichi, serà difficiule di mantene e dati à ghjornu. Ogni liberazione successiva romperà significativamente u sistema sanu, è tuttu ciò chì faremu hè di riparà. Per quessa, avemu focu annantu à e cose assai fundamentali chì raramente cambianu, è li monitoremu solu.
Infine, in terzu, a fonte di dati hè un sistema di logu centralizatu. Utilizemu Elastic Stack per i logs, è poi pudemu tirà queste dati in u nostru sistema di monitoraghju per e metriche di l'affari. In più di tuttu questu, avemu u nostru propiu serviziu di Monitoring API, scrittu in Python, chì interruga ogni serviziu via API è raccoglie dati da elli in Zabbix.
Un altru attributu indispensabile di u monitoraghju hè a visualizazione. U nostru hè basatu annantu à Grafana. Si distingue trà l'altri sistemi di visualizazione in quantu vi permette di visualizà metriche da diverse fonti di dati nantu à u dashboard. Pudemu raccoglie metriche di primu livellu per una tenda in linea, per esempiu, u numeru di ordini piazzati in l'ultima ora da u DBMS, metriche di rendiment per u SO nantu à quale sta tenda in linea funziona da Zabbix, è metriche per esempi di sta applicazione. da Prometheus. È tuttu questu serà nantu à un dashboard. Chjara è accessibile.
Permettemu di nutà nantu à a sicurità - simu attualmente finalizendu u sistema, chì dopu integraremu cù u sistema di monitoraghju glubale. In my opinion, i prublemi principali chì e-commerce face in u campu di a sicurità di l'infurmazioni sò ligati à i bots, parsers è brute force. Avemu bisognu di tene un ochju nantu à questu, perchè tuttu questu pò influenzà criticamente l'operazione di e nostre applicazioni è a nostra reputazione da un puntu di vista cummerciale. È cù a pila scelta, copremu cù successu sti travaglii.
Un altru puntu impurtante hè chì a strata di l'applicazione hè assemblata da Prometheus. Ellu stessu hè ancu integratu cù Zabbix. È avemu ancu sitespeed, un serviziu chì ci permette di vede paràmetri cum'è a velocità di carica di a nostra pagina, i colli di bottiglia, a rendering di a pagina, i script di carica, etc., hè ancu API integrata. Allora e nostre metriche sò cullate in Zabbix, è per quessa, avemu ancu avvisu da quì. Tutte l'alerte sò attualmente mandate à i metudi principali di mandatu (per avà hè email è telegramma, MS Teams hè statu ancu cunnessu di pocu tempu). Ci hè un pianu di aghjurnà l'alerta à un tali statu chì i bots intelligenti travaglianu cum'è serviziu è furnisce infurmazioni di monitoraghju à tutti i gruppi di produtti interessati.
Per noi, e metriche sò impurtanti micca solu per i sistemi d'infurmazioni individuali, ma ancu e metriche generali per tutta l'infrastruttura chì l'applicazioni utilizanu: clusters di servitori fisici nantu à quale eseguite e macchine virtuali, balancers di trafficu, Network Load Balancers, a reta stessa, l'utilizazione di i canali di cumunicazione. . Plus metriche per i nostri centri di dati (avemu parechji di elli è l'infrastruttura hè abbastanza grande).
I vantaghji di u nostru sistema di surviglianza sò chì cù u so aiutu vedemu u statu di salute di tutti i sistemi è ponu valutà u so impattu nantu à l'altri è nantu à e risorse spartute. È in fine, ci permette di participà à a pianificazione di risorse, chì hè ancu a nostra rispunsabilità. Gestemu e risorse di u servitore - una piscina in e-commerce, cumissioni è disattivazione di novi equipaghji, cumprà un equipamentu novu supplementu, fà un auditu di l'utilizazione di e risorse, etc. Ogni annu, i squadre pianificanu novi prughjetti, sviluppanu i so sistemi, è hè impurtante per noi di furnisce i risorse.
È cù l'aiutu di e metriche, vedemu a tendenza in u cunsumu di risorse da i nostri sistemi d'infurmazione. È basatu annantu à elli pudemu pianificà qualcosa. À u livellu di virtualizazione, cullemu dati è vede l'infurmazioni nantu à a quantità dispunibile di risorse per data center. È digià in u centru di dati pudete vede u riciclamentu, a distribuzione attuale è u cunsumu di risorse. Inoltre, sia cù servitori standalone è macchine virtuali è clusters di servitori fisici nantu à quale tutte queste macchine virtuali giranu vigorosamente.
Prospetti
Avà avemu u core di u sistema in tuttu prontu, ma ci sò sempre assai cose chì anu da esse travagliatu. À u minimu, questu hè una strata di sicurità di l'infurmazioni, ma hè ancu impurtante per ghjunghje à a reta, sviluppà l'alerta è risolve u prublema di correlazione. Avemu parechje strati è sistemi, è nantu à ogni strata ci sò assai più metriche. Risulta esse una matryoshka à u gradu di una matryoshka.
U nostru compitu hè di fà ultimamente l'alerte ghjusti. Per esempiu, s'ellu ci era un prublema cù u hardware, di novu, cù una macchina virtuale, è ci era una applicazione impurtante, è u serviziu ùn hè micca sustinutu in ogni modu. Scupremu chì a macchina virtuale hè morta. Allora e metriche di l'affari vi avvisanu: l'utilizatori sò spariti in qualchì locu, ùn ci hè micca cunversione, l'UI in l'interfaccia ùn hè micca dispunibule, u software è i servizii sò ancu morti.
In questa situazione, riceveremu spam da alerti, è questu ùn si mette più in u formatu di un sistema di surviglianza propiu. A quistione di a correlazione si pone. Dunque, idealmente, u nostru sistema di surviglianza deve dì: "Ragazzi, a vostra macchina fisica hè morta, è cù questu questa applicazione è queste metriche", cù l'aiutu di una alerta, invece di bombardà in furia cù un centu di alerti. Ci vole à rapportà u principale - a causa, chì aiuta à eliminà rapidamente u prublema per via di a so localizazione.
U nostru sistema di notificazione è u processu d'alerta hè custruitu intornu à un serviziu di linea diretta XNUMX ore. Tutte l'alerta chì sò cunsiderate un must-have è sò incluse in a lista di cuntrollu sò mandate quì. Ogni alerta deve avè una descrizzione: ciò chì hè accadutu, ciò chì significa veramente, ciò chì affetta. È ancu un ligame à u dashboard è struzzioni nantu à ciò chì fà in questu casu.
Questu hè tutte e esigenze per custruisce una alerta. Allora a situazione pò sviluppà in duie direzzione - o ci hè un prublema è deve esse risolta, o ci hè statu un fallimentu in u sistema di surviglianza. Ma in ogni casu, avete bisognu à andà è capisce.
In media, avemu avà ricevutu un centu di alerti per ghjornu, tenendu in contu u fattu chì a correlazione di alerti ùn hè micca stata cunfigurata bè. È s'ellu ci vole à fà u travagliu tecnicu, è avemu a forza fora qualcosa, u so numeru aumenta significativamente.
In più di u monitoraghju di i sistemi chì operamu è a cullizzioni di metriche chì sò cunsiderate impurtanti da u nostru latu, u sistema di surviglianza ci permette di cullà dati per e squadre di produttu. Puderanu influenzà a cumpusizioni di metriche in i sistemi d'infurmazione chì monitoremu.
U nostru cumpagnu pò vene è dumandà à aghjunghje qualchì metrica chì serà utile per noi è per a squadra. O, per esempiu, a squadra ùn pò micca avè abbastanza di e metriche basiche chì avemu; anu bisognu di seguità alcune specifiche. In Grafana, creemu un spaziu per ogni squadra è cuncedemu diritti di amministratore. Inoltre, se una squadra hà bisognu di dashboards, ma elli stessi ùn ponu micca / ùn sanu micca cumu fà, l'aiutemu.
Siccomu simu fora di u flussu di a creazione di valore di a squadra, i so rilasci è a pianificazione, simu gradualmenti à a cunclusione chì e versioni di tutti i sistemi sò senza saldatura è ponu esse lanciate ogni ghjornu senza coordinazione cun noi. È hè impurtante per noi di monitorà queste versioni, perchè puderanu influenzà u funziunamentu di l'applicazione è rompe qualcosa, è questu hè criticu. Per gestisce e versioni, usemu Bamboo, da induve ricevemu dati via API è ponu vede quali versioni sò stati liberati in quale sistemi d'informazione è u so statutu. È u più impurtante hè in quale ora. Superposemu marcatori di liberazione nantu à i principali metrichi critichi, chì hè visualmente assai indicativu in casu di prublemi.
Questu modu pudemu vede a correlazione trà e novi versioni è i prublemi emergenti. L'idea principale hè di capiscenu cumu u sistema funziona in tutti i strati, localizà rapidamente u prublema è risolve u stessu rapidamente. Dopu tuttu, spessu succede chì ciò chì pigghia u più tempu ùn hè micca risolviri u prublema, ma cerca di a causa.
È in questu spaziu in u futuru vulemu fucalizza nantu à a proattività. Ideale, mi piacerebbe sapè in anticipu nantu à un prublema chì si avvicina, è micca dopu à u fattu, per pudè prevene invece di risolve. Calchì volta i falsi alarmi di u sistema di surviglianza si verificanu, sia per errore umanu sia per cambiamenti in l'applicazione. E avemu travagliatu nantu à questu, debug, è pruvate à avvistà l'utilizatori chì l'utilizanu cun noi prima di ogni manipulazione di u sistema di surviglianza. , o fà sti attività in a finestra tecnica.
Allora, u sistema hè stata lanciata è hà travagliatu cù successu da u principiu di a primavera ... è mostra prufitti assai reali. Di sicuru, questu ùn hè micca a so versione finale; introduceremu assai più funzioni utili. Ma avà, cù tante integrazioni è applicazioni, l'automatizazione di monitorizazione hè veramente inevitabbile.
Sè ancu monitorà i grandi prughjetti cù un numeru significativu di integrazioni, scrivite in i cumenti chì balla d'argentu truvate per questu.
Source: www.habr.com