Mi chjamu Anton Baderin. U travagliu in u Centru High Technology è fà l'amministrazione di u sistema. Un mese fà, a nostra cunferenza corporativa hè finita, induve avemu spartutu a nostra sperienza accumulata cù a cumunità IT di a nostra cità. Aghju parlatu di u monitoraghju di l'applicazioni web. U materiale era destinatu à u livellu junior o mediu, chì ùn hà micca custruitu stu prucessu da zero.
A basa di ogni sistema di monitoraghju hè di risolve i prublemi di cummerciale. U monitoraghju per u surviglianza ùn interessa à nimu. Chì volenu l'affari? Cusì chì tuttu funziona rapidamente è senza errore. L'imprese volenu esse proattivu, in modu chì noi stessi identificanu i prublemi in u serviziu è risolve u più prestu pussibule. Questi, in fattu, sò i prublemi chì aghju risoltu tuttu l'annu passatu nantu à un prughjettu per unu di i nostri clienti.
À u prugettu
U prughjettu hè unu di i più grandi prugrammi di fidelizazione in u paese. Aiutemu e catene di vendita à aumentà a freccia di vendita attraversu diversi strumenti di marketing cum'è carte bonus. In u tutale, u prugettu include 14 applicazioni chì funzionanu nantu à dece servitori.
Duranti u prucessu di l'entrevista, aghju ripetutamente nutatu chì l'amministratori ùn si avvicinanu micca sempre à u monitoraghju di l'applicazioni web in modu correttu: assai si focalizeghjanu sempre nantu à e metriche di u sistema operatore è à volte monitoranu i servizii.
In u mo casu, u sistema di surviglianza di u cliente era prima basatu annantu à Icinga. Ùn risolve micca i prublemi sopra in ogni modu. Spessu u cliente stessu ci hà infurmatu nantu à i prublemi, è più spessu chì micca, simpricimenti ùn avemu micca abbastanza dati per arrivà à u fondu di u mutivu.
Inoltre, ci era una comprensione chjara di a futilità di u so sviluppu ulteriore. Pensu chì quelli chì sò familiarizati cù Icinga mi capiscenu. Dunque, avemu decisu di riprogettà cumplettamente u sistema di monitoraghju di l'applicazione web per u prugettu.
Prometheus
Avemu sceltu Prometheus basatu annantu à trè indicatori principali:
- Un gran numaru di metriche dispunibili. In u nostru casu, ci sò 60 mila. Di sicuru, vale a pena nutà chì ùn avemu micca aduprà a maiò parte di elli (probabilmente circa 95%). Per d 'altra banda, sò tutti relativamente boni. Per noi, questu hè l'altru estremu paragunatu à l'Icinga utilizatu prima. In questu, l'aghjunghje metrica era un dolore particulari: quelli esistenti eranu caru (solu fighjate à u codice fonte di qualsiasi plugin). Ogni plugin era un script in Bash o Python, u lanciamentu di quale hè caru in termini di risorse cunsumate.
- Stu sistema cunsuma una quantità relativamente chjuca di risorse. 600 MB di RAM, 15% di un core è un paru di decine di IOPS sò abbastanza per tutte e nostre metriche. Di sicuru, avete da eseguisce l'esportatori di metriche, ma sò tutti scritti in Go è ùn sò micca assai fami di putere. Ùn pensu micca chì in a realità muderna questu hè un prublema.
- Fornisce a capacità di migrà à Kubernetes. Cunsiderendu i piani di u cliente, a scelta hè ovvia.
ELK
Nanzu, ùn avemu micca raccoltu o processatu logs. I difetti sò chjaru à tutti. Avemu sceltu ELK perchè avemu digià avutu sperienza di travaglià cù stu sistema. Guardemu solu i log di l'applicazioni quì. I criterii principali di selezzione eranu a ricerca di testu sanu è a so rapidità.
Сlickhouse
Inizialmente, a scelta hè cascata nantu à InfluxDB. Avemu realizatu a necessità di cullà logs Nginx, statistiche da pg_stat_statements, è almacenà e dati storichi di Prometheus. Ùn ci hè micca piaciutu Influx perchè periodicamente hà cuminciatu à cunsumà una grande quantità di memoria è s'hè lampatu. Inoltre, vulia raggruppà e dumande per remote_addr, ma l'agrupazione in questu DBMS hè solu per tag. I tags sò caru (memoria), u so numeru hè limitatu in cundizzioni.
Avemu principiatu a nostra ricerca di novu. Ciò chì era necessariu era una basa di dati analitica cù u cunsumu minimu di risorse, preferibile cù cumpressione di dati in discu.
Clickhouse risponde à tutti questi criteri, è ùn avemu mai dispiaciutu a nostra scelta. Ùn scrivemu micca una quantità straordinaria di dati in questu (u numeru di inserimenti hè solu circa cinque mila per minutu).
New Relic
NewRelic hè stata storicamente cun noi perchè era a scelta di u cliente. Avemu aduprà cum'è un APM.
Zabbix
Usemu Zabbix esclusivamente per monitorizà a Black Box di diverse API.
Definizione di un Approcciu di Monitoraghju
Vulemu scumpressà u compitu è sistematizà cusì l'approcciu di u monitoraghju.
Per fà questu, aghju divisu u nostru sistema in i seguenti livelli:
- hardware è VMS;
- sistema upirativu;
- servizii di sistema, stack di software;
- applicazione;
- logica cummerciale.
Perchè stu approcciu hè convenientu:
- sapemu quale hè rispunsevule per u travagliu di ogni livellu è, basatu annantu à questu, pudemu mandà alerti;
- pudemu usà a struttura quandu suppressing alerts - saria stranu per mandà una alerta nantu à a indisponibilità di a basa di dati quandu a macchina virtuale in tuttu ùn hè micca dispunibule.
Siccomu u nostru compitu hè di identificà e violazioni in u funziunamentu di u sistema, duvemu à ogni livellu mette in risaltu un certu inseme di metriche chì valenu a pena attente quandu scrivite regule d'alerta. Dopu, andemu à traversu i livelli "VMS", "Sistema upirativu" è "Servizi di sistema, stack di software".
Macchine virtuale
Hosting ci attribuisce un processore, discu, memoria è rete. È avemu avutu prublemi cù i primi dui. Dunque, i metrichi:
U tempu arrubatu di CPU - quandu cumprate una macchina virtuale in Amazon (t2.micro, per esempiu), duvete capisce chì ùn site micca attribuitu un core di processatore sanu, ma solu una quota di u so tempu. È quandu l'avete esauritu, u processatore serà pigliatu da voi.
Sta metrica vi permette di seguità tali mumenti è piglià decisioni. Per esempiu, hè necessariu di piglià una tarifa più grassa o distribuisce u processu di i travaglii di fondo è e dumande API à diversi servitori?
IOPS + CPU iowait time - per una certa ragione, assai cloud hosting peccanu per ùn furnisce micca abbastanza IOPS. Inoltre, un schedariu cù IOPS bassu ùn hè micca un argumentu per elli. Dunque, vale a pena cullà CPU iowait. Cù stu paru di grafici - cù IOPS bassu è alta I / O aspetta - pudete digià parlà à l'ospitu è risolve u prublema.
sistema upirativu
Metri di u sistema operatore:
- quantità di memoria dispunibule in %;
- attività di usu di scambià: vmstat swapin, swapout;
- numeru di inodi dispunibili è spaziu liberu nantu à u sistema di fugliale in %
- carica media;
- numeru di cunnessione in dui stati;
- pienezza di u tavulinu conttrack;
- A qualità di a reta pò esse monitorata cù l'utilità ss, u pacchettu iproute2 - uttene un indicatore di cunnessione RTT da a so output è u gruppu per u portu dest.
Ancu à u livellu di u sistema upirativu avemu un tali entità cum'è prucessi. Hè impurtante identificà in u sistema un inseme di prucessi chì ghjucanu un rolu impurtante in u so funziunamentu. Se, per esempiu, avete parechji pgpools, allora avete bisognu di cullà infurmazioni per ognunu di elli.
L'inseme di metrica hè a siguenti:
- CPU;
- a memoria hè principalmente residente;
- IO - preferibile in IOPS;
- FileFd - apertu è limite;
- fallimenti di pagina significativu - questu modu pudete capisce quale prucessu hè scambiatu.
Implementemu tuttu u monitoraghju in Docker, è usemu Advisor per raccoglie dati di metrica. Nant'à altre machini avemu aduprà prucessu-esportatore.
servizii di sistema, stack di software
Ogni applicazione hà e so particularità, è hè difficiule di sceglie un settore specificu di metriche.
U set universale hè:
- tariffa di dumanda;
- numeru di sbagli;
- latenza;
- saturazione.
I nostri esempi più impressiunanti di monitoraghju à questu livellu sò Nginx è PostgreSQL.
U serviziu più carricu in u nostru sistema hè a basa di dati. In u passatu, avemu spessu avutu prublemi per capisce ciò chì a basa di dati facia.
Avemu vistu una carica alta nantu à i dischi, ma i logs lenti ùn anu micca veramente mostratu nunda. Avemu risoltu stu prublema usendu pg_stat_statements, una vista chì raccoglie statistiche di quistione.
Hè tuttu ciò chì l'amministratore hà bisognu.
Custruemu grafici di l'attività di e dumande di lettura è scrittura:
Tuttu hè simplice è chjaru, ogni dumanda hà u so culore.
Un esempiu ugualmente sorprendente hè Nginx logs. Ùn hè micca surprisante chì uni pochi di persone li analizzanu o li citanu in a lista di must-haves. U furmatu standard ùn hè micca assai informativu è deve esse allargatu.
In modu persunale, aghju aghjustatu request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Tracemu u tempu di risposta è u numeru di errori:
Custruemu grafici di u tempu di risposta è u numeru di errori. Ricurdativi? Aghju parlatu di l'ugettivi cummerciale ? À prestu è senza errori? Avemu digià cupertu sti prublemi cù dui charts. È pudete digià chjamà l'amministratori di turnu cù elli.
Ma resta un prublema più - per assicurà a rapida eliminazione di e cause di l'incidentu.
Risoluzione di incidenti
U prucessu tutale da identificà à risolve un prublema pò esse divisu in parechji passi:
- identificà u prublema;
- notificazione à l'amministratore di u duvere;
- risposta à un incidente;
- eliminazione di cause.
Hè impurtante chì avemu da fà questu u più prestu pussibule. È se in i fasi di l'identificazione di un prublema è di mandà una notificazione ùn pudemu micca guadagnà assai tempu - in ogni casu, dui minuti seranu spesi nantu à elli, allora i successivi sò simpliciamente un terrenu micca aratu per migliurà.
Imaginemu solu chì u telefonu di l'ufficiale di turnu sonò. Chì farà ? Cerca risposte à e dumande - ciò chì si rumpiu, induve si rompe, cumu reagisce? Eccu cumu rispondemu à queste dumande:
Avemu simpricimenti cumprendi tutte sta infurmazione in u testu di a notificazione, dà un ligame à una pagina wiki chì descrive cumu risponde à stu prublema, cumu risolve è scala.
Ùn aghju micca dettu nunda di a strata di l'applicazione è a logica cummerciale. Sfurtunatamente, e nostre applicazioni ùn implementanu ancu a raccolta di metriche. L'unica fonte di qualsiasi infurmazione da questi livelli hè logs.
Un paru di punti.
Prima, scrive logs strutturati. Ùn ci hè bisognu di include u cuntestu in u testu di u missaghju. Questu facenu difficiuli di gruppu è analizà. Logstash piglia assai tempu per nurmalizà tuttu questu.
Siconda, aduprate i livelli di gravità currettamente. Ogni lingua hà u so standard. In modu persunale, distingue quattru livelli:
- senza errore;
- errore di u cliente;
- l'errore hè da a nostra parte, ùn perdemu micca soldi, ùn avemu micca risichi;
- L'errore hè da a nostra parte, perdemu soldi.
Lasciami riassume. Avete bisognu di pruvà à custruisce un monitoraghju basatu nantu à a logica cummerciale. Pruvate di monitorà l'applicazione stessa è operate cù metriche cum'è u numeru di vendite, u numeru di novi registrazioni d'utilizatori, u numeru di utilizatori attualmente attivi, etc.
Se tutta a vostra attività hè un buttone in u navigatore, avete bisognu di vigilà s'ellu clica è funziona bè. Tuttu u restu ùn importa micca.
Se ùn avete micca questu, pudete pruvà à piglià cun ellu in i logs di l'applicazioni, i logs Nginx, è cusì, cum'è avemu fattu. Duvete esse u più vicinu à l'applicazione quant'è pussibule.
A metrica di u sistema operatore hè di sicuru impurtante, ma l'affari ùn hè micca interessatu in elli, ùn sò micca pagati per elli.
Source: www.habr.com