U monitoraghju hè mortu? - Viva u monitoraghju

Dapoi u 2008, a nostra cumpagnia hè stata principarmenti ingaghjata in a gestione di l'infrastruttura è u supportu tecnicu round-the-clock per i prughjetti web: avemu più di 400 clienti, chì hè circa 15% di e-commerce russu. Per quessa, una architettura assai diversa hè supportata. Se qualcosa casca, simu obligati à riparà in 15 minuti. Ma per capisce chì un accidentu hè accadutu, avete bisognu di seguità u prugettu è risponde à l'incidentu. Cumu fà questu?

Credu chì ci hè un prublema in l'urganizazione di un sistema di surviglianza propiu. S'ellu ùn ci fussi micca prublemi, allora u mo discorsu consisterebbe in una tesi: "Per piacè installate Prometheus + Grafana è i plugins 1, 2, 3". Sfurtunatamente, ùn funziona più cusì. È u prublema principali hè chì tutti cuntinueghjanu à crede in qualcosa chì esiste in u 2008, in quantu à i cumpunenti di u software.

In quantu à l'urganisazione di u sistema di surviglianza, mi azzarderaghju à dì chì... i prughjetti cù un surviglianza cumpetente ùn esistenu micca. È a situazione hè cusì male chì, se qualcosa casca, ci hè u risicu di passà inosservatu - dopu tuttu, tutti sò sicuru chì "tuttu hè monitoratu".
Forse tuttu hè monitoratu. Ma cumu ?

Avemu tutti scontru una storia cum'è a seguente: un certu devops, un certu amministratore travaglia, un squadra di sviluppu vene à elli è dice - "simu liberati, avà monitor". Monitorà chì? Cumu funziona?

OK. Monitoremu u modu anticu. È hè digià cambiatu, è risulta chì avete monitoratu u serviziu A, chì hè diventatu u serviziu B, chì interagisce cù u serviziu C. Ma u squadra di sviluppu vi dice: "Installa u software, deve monitorà tuttu!"

Allora chì hè cambiatu? - Tuttu hè cambiatu !

2008 Tuttu hè bè

Ci hè un coppiu di sviluppatori, un servitore, un servitore di basa di dati. Tuttu va da quì. Avemu qualchì infurmazione, stallà zabbix, Nagios, cacti. È dopu avemu stabilitu alerti chjaru nantu à u CPU, nantu à l'operazione di discu, è in u spaziu di discu. Facemu ancu un paru di cuntrolli manuali per assicurà chì u situ risponde è chì l'ordine sò ghjunti in a basa di dati. È questu hè - simu più o menu prutetti.

Se paragunemu a quantità di travagliu chì l'amministratore hà fattu per furnisce u monitoraghju, allora u 98% di questu era automaticu: a persona chì face u monitoraghju deve capisce cumu installà Zabbix, cumu cunfigurà è cunfigurà alerti. E 2% - per cuntrolli esterni: chì u situ risponde è fa una dumanda à a basa di dati, chì novi ordini sò ghjunti.

2010 A carica cresce

Avemu cuminciatu à scala u web, aghjunghjendu un mutore di ricerca. Vulemu assicurà chì u catalogu di i prudutti cuntene tutti i prudutti. È chì a ricerca di u produttu travaglia. Chì a basa di dati hè travagliatu, chì l'ordine sò fatti, chì u situ risponde esternamente è risponde da dui servitori è l'utilizatore ùn hè micca cacciatu fora di u situ mentre hè riequilibratu à un altru servitore, etc. Ci sò più entità.

Inoltre, l'entità assuciata à l'infrastruttura ferma sempre u più grande in u capu di u manager. Ci hè sempre una idea in u mo capu chì a persona chì face u monitoraghju hè a persona chì installerà zabbix è puderà cunfigurà.

Ma à u stessu tempu, u travagliu appare nantu à a realizazione di cuntrolli esterni, in a creazione di un inseme di script di ricerca d'indici di ricerca, un inseme di script per verificà chì a ricerca cambia durante u prucessu di indexazione, un inseme di script chì verificanu chì e merchenzie sò trasferite à u serviziu di consegna, etc. eccetera.

Nota: Aghju scrittu "un set di scripts" 3 volte. Vale à dì, a persona rispunsevuli di u monitoraghju ùn hè più quellu chì simpliciamente installate zabbix. Questa hè una persona chì principia à codificà. Ma nunda ùn hè cambiatu in a mente di a squadra.

Ma u mondu hè cambiatu, diventendu sempre più cumplessu. Una strata di virtualizazione è parechji sistemi novi sò aghjuntu. Cumincianu à interagisce cù l'altri. Quale hà dettu "puzza di microservizi?" Ma ogni serviziu pare sempre un situ web individualmente. Pudemu turnà à ellu è capisce chì furnisce l'infurmazioni necessarii è travaglia per sè stessu. È sì sì un amministratore constantemente implicatu in un prughjettu chì si sviluppa dapoi 5-7-10 anni, sta cunniscenza s'accumula: un novu livellu si prisenta - l'avete realizatu, un altru livellu appare - avete capitu ...

Ma raramente qualchissia accumpagna un prughjettu per 10 anni.

Curriculum vitae di Monitoringman

Supponete chì site ghjuntu à una nova startup chì hà assuciatu immediatamente 20 sviluppatori, hà scrittu 15 microservizi, è site un amministratore chì hè dettu: "Custruisce CI / CD. Per piacè." Avete custruitu CI / CD è di colpu avete intesu: "Hè difficiule per noi di travaglià cù a produzzione in un "cube", senza capisce cumu l'applicazione hà da travaglià in questu. Fate un sandbox in u stessu "cube".
Fate un sandbox in questu cubu. Immediatamente vi dicenu: "Vulemu una basa di dati di scena chì hè aghjurnata ogni ghjornu da a produzzione, in modu chì capiscenu chì travaglia nantu à a basa di dati, ma à u listessu tempu ùn sguassate micca a basa di dati di produzzione".

Vive in tuttu questu. Restanu 2 settimane prima di a liberazione, vi dicenu: "Avà monitoremu tuttu questu ..." Questu hè. monitorà l'infrastruttura di cluster, monitorizà l'architettura di microserviziu, monitorizà u travagliu cù servizii esterni ...

E i mo culleghi piglianu u schema di solitu da a so testa è dicenu: "Bè, tuttu hè chjaru quì! Installa un prugramma chì monitorerà tuttu questu ". Iè, sì: Prometheus + Grafana + plugins.
È aghjunghjenu: "Avete duie settimane, assicuratevi chì tuttu hè sicuru".

In parechji prughjetti chì vedemu, una persona hè attribuita per u monitoraghju. Imagine chì vulemu impiegà una persona per fà u monitoraghju per 2 settimane, è scrivimu un currículum per ellu. Chì cumpetenze deve avè sta persona, datu tuttu ciò chì avemu dettu finu à avà ?

• Deve capisce u monitoraghju è e specificità di l'operazione di l'infrastruttura di ferru.
• Deve capisce i specifichi di u monitoraghju Kubernetes (è tutti volenu andà à u "cube", perchè pudete astrattu da tuttu, ammuccià, perchè l'amministratore hà da trattà cù u restu) - stessu, a so infrastruttura, è capisce cumu monitorà l'applicazioni. dentru.
• Deve capisce chì i servizii cumunicanu cù l'altri in modi spiciali, è cunnosce i particularità di cumu i servizii interagiscenu cù l'altri. Hè abbastanza pussibule di vede un prughjettu induve certi servizii cumunicanu sincronamente, perchè ùn ci hè micca altru modu. Per esempiu, u backend passa per REST, via gRPC à u serviziu di u catalogu, riceve una lista di prudutti è torna torna. Ùn pudete micca aspittà quì. È cù altri servizii funziona in modu asincronu. Trasferite l'ordine à u serviziu di spedizione, mandate una lettera, etc.
  Probabilmente avete digià nutatu da tuttu questu? È l'amministratore, chì deve monitorà questu, hè diventatu ancu più cunfusu.
• Deve esse capace di pianificà è pianificà currettamente - cum'è u travagliu diventa più è più.
• Per quessa, deve creà una strategia da u serviziu creatu per capisce cumu per monitorà in modu specificu. Hà bisognu di una cunniscenza di l'architettura di u prugettu è di u so sviluppu + una cunniscenza di e tecnulugia aduprate in u sviluppu.

Ricurdemu un casu assolutamente normale: certi servizii sò in PHP, certi servizii sò in Go, certi servizii sò in JS. In qualchì modu travaglianu l'un l'altru. Hè quì chì u terminu "microservice" vene da: ci sò tanti sistemi individuali chì i sviluppatori ùn ponu micca capisce u prugettu in tuttu. Una parte di a squadra scrive servizii in JS chì travaglianu per sè stessu è ùn sanu micca cumu u restu di u sistema funziona. L'altra parte scrive servizii in Python è ùn interferiscenu micca cumu funziona l'altri servizii; sò isolati in a so propria zona. U terzu hè di scrive servizii in PHP o qualcosa altru.
Tutti questi 20 persone sò spartuti in 15 servizii, è ci hè solu un amministratore chì deve capisce tuttu questu. Ferma ! avemu solu split the system in 15 microservices perchè 20 persone ùn ponu micca capisce u sistema tutale.

Ma deve esse monitoratu in qualchì modu...

Chì hè u risultatu ? In u risultatu, ci hè una persona chì vene cun tuttu ciò chì tutta a squadra di sviluppatori ùn pò micca capisce, è à u stessu tempu deve ancu sapè è esse capace di fà ciò chì avemu indicatu sopra - infrastruttura hardware, infrastruttura Kubernetes, etc.

Chì possu dì... Houston, avemu prublemi.

Monitorà un prughjettu di software mudernu hè un prughjettu di software in sè stessu

Da a falsa credenza chì u monitoraghju hè un software, sviluppemu una credenza in miraculi. Ma i miraculi, ahimè, ùn succede micca. Ùn pudete micca installà zabbix è aspetta chì tuttu funziona. Ùn ci hè nunda à stallà Grafana è sperendu chì tuttu sarà bè. A maiò parte di u tempu serà passatu à urganizà cuntrolli di u funziunamentu di i servizii è a so interazzione cù l'altri, cuntrollà cumu funziona i sistemi esterni. In fatti, u 90% di u tempu serà spesu micca à scrive scripts, ma à sviluppà software. È deve esse trattatu da una squadra chì capisce u travagliu di u prugettu.
Se in questa situazione una persona hè ghjittata in u monitoraghju, allora u disastru succede. Chì ghjè ciò chì succede in ogni locu.

Per esempiu, ci sò parechji servizii chì cumunicanu cù l'altri via Kafka. L'ordine hè ghjuntu, avemu mandatu un missaghju annantu à l'ordine à Kafka. Ci hè un serviziu chì ascolta l'infurmazioni nantu à l'ordine è spedisce e merchenzie. Ci hè un serviziu chì ascolta l'infurmazioni nantu à l'ordine è manda una lettera à l'utilizatore. È dopu appariscenu una mansa di più servizii, è cuminciamu à cunfundà.

È se dà ancu questu à l'amministratore è i sviluppatori in a tappa quandu ci hè un pocu tempu prima di a liberazione, a persona hà bisognu di capisce tuttu stu protokollu. Quelli. Un prughjettu di sta scala pigghia una quantità significativa di tempu, è questu deve esse fattu in u sviluppu di u sistema.
Ma assai spessu, soprattuttu in i startups, vedemu cumu a monitorizazione hè posposta finu à più tardi. "Avà faremu una Prova di Cuncepimentu, lanceremu cun ella, lascemu falà - simu pronti à sacrificà. È dopu monitoreremu tuttu ". Quandu (o s'ellu) u prugettu cumencia à guadagnà soldi, l'affari vole aghjunghje ancu più funziunalità - perchè hà cuminciatu à travaglià, per quessa, deve esse allargatu più! È site à u puntu induve prima avete bisognu di monitorà tuttu ciò chì precede, chì ùn piglia micca 1% di u tempu, ma assai più. E per via, i sviluppatori seranu necessarii per u monitoraghju, è hè più faciule per lascià travaglià nantu à e funzioni novi. In u risultatu, e funzioni novi sò scritte, tuttu hè vintu, è site in un impastu infinitu.

Allora cumu monitorà un prughjettu da u principiu, è chì fà s'ellu avete un prughjettu chì deve esse monitoratu, ma ùn sapete micca da induve principià?

Prima, avete bisognu di pianificà.

Digressione lirica: assai spessu cumincianu cù u monitoraghju di l'infrastruttura. Per esempiu, avemu Kubernetes. Accuminciamu per installà Prometheus cù Grafana, installendu plugins per monitorizà u "cube". Micca solu i sviluppatori, ma ancu l'amministratori anu a pratica disgraziata di: "Installemu stu plugin, ma u plugin probabilmente sà cumu fà". A ghjente piace à principià cù l'azzione simplice è diretta, invece di l'azzioni impurtanti. È u monitoraghju di l'infrastruttura hè faciule.

Prima, decide ciò chì è cumu vulete monitorà, è dopu selezziunate un strumentu, perchè altri persone ùn ponu micca pensà per voi. È duveranu? L'altri pirsuni pensanu à sè stessu, nantu à un sistema universale - o ùn anu micca pensatu à tuttu quandu stu plugin hè statu scrittu. È solu perchè stu plugin hà 5 mila utilizatori ùn significa micca chì hè di ogni usu. Forse diventerai u 5001e solu perchè ci era digià 5000 persone prima.

Se cuminciate à monitorà l'infrastruttura è u backend di a vostra applicazione ùn risponde, tutti l'utilizatori perderanu a cunnessione cù l'applicazione mobile. Un errore appariscerà. Veranu da voi è dicenu "L'applicazione ùn funziona micca, chì fate quì?" - "Semu monitoraghju". - "Cumu monitorate se ùn vede micca chì l'applicazione ùn funziona micca ?!"

1. Credu chì avete bisognu di principià a monitorizazione esattamente da u puntu di entrata di l'utilizatore. Se l'utilizatore ùn vede micca chì l'applicazione funziona, hè questu, hè un fallimentu. È u sistema di surviglianza deve avvistà di questu prima.
2. È solu allora pudemu monitorà l'infrastruttura. O fate in parallelu. Hè più faciule cù l'infrastruttura - quì pudemu finalmente installà zabbix.
3. È avà avete bisognu à andà à e radiche di l'applicazione per capiscenu induve e cose ùn sò micca travagliatu.

A mo idea principale hè chì u monitoraghju deve andà in parallelu cù u prucessu di sviluppu. Se distrate u squadra di monitoraghju per altri compiti (creazione di CI / CD, sandboxing, riurganizazione di l'infrastruttura), u monitoraghju principià à lag è ùn pudete mai ghjunghje à u sviluppu (o prima o dopu avete da piantà).

Tuttu per livelli

Questu hè cumu vecu l'urganizazione di un sistema di surviglianza.

1) Livellu di applicazione:

• surviglianza di a logica cummerciale di l'applicazione;
• surviglianza metrica di salute di servizii;
• monitoraghju di l'integrazione.

2) Livellu di l'infrastruttura:

• monitoraghju di u livellu di l'orchestrazione;
• monitoraghju di u software di u sistema;
• monitoraghju di u nivellu di ferru.

3) Di novu u livellu di l'applicazione - ma cum'è un pruduttu di ingegneria:

• raccoglie è monitorizà i logs di l'applicazioni;
• APM;
• traccia.

4) Alerta:

• urganizazione di un sistema di avvirtu;
• urganizazione di un sistema di duveri;
• urganizazione di una "base di cunniscenza" è u flussu di travagliu per u processu di incidenti.

impurtanti: ghjunghjemu à l'alerta micca dopu, ma subitu ! Ùn ci hè bisognu di lancià u monitoraghju è "di qualchì manera più tardi" capisce quale riceverà alerti. Dopu tuttu, quale hè u compitu di u monitoraghju: per capiscenu induve in u sistema qualcosa hè travagliatu male, è per fà sapè à e persone ghjusti. Se lasciate questu finu à a fine, allora e persone giuste sapranu chì qualcosa va male solu chjamendu "nunda ùn funziona per noi".

Stratu di l'applicazione - Monitoraghju di a logica cummerciale

Quì avemu parlatu di verificà u fattu assai chì l'applicazione travaglia per l'utilizatore.

Stu livellu deve esse fattu durante a fase di sviluppu. Per esempiu, avemu un Prometheus cundizionale: va à u servitore chì face i cuntrolli, tira l'endpoint, è l'endpoint va è verifica l'API.

Quandu spessu dumandate à monitorà a pagina di casa per assicurà chì u situ hè travagliatu, i programatori dà un manicu chì pò esse tiratu ogni volta chì anu bisognu di assicurà chì l'API hè travagliatu. È i programatori in questu mumentu piglianu è scrivenu /api/test/helloworld
L'unicu modu per assicurà chì tuttu funziona? - Innò!

• A creazione di tali cuntrolli hè essenzialmente u compitu di i sviluppatori. I testi di unità deve esse scritti da i programatori chì scrivenu u codice. Perchè s'ellu si filtra à l'amministratore, "Amicu, eccu una lista di protokolli API per tutte e 25 funzioni, per piacè monitorizà tuttu!" - nunda ùn funziona.
• Se stampate "hello world", nimu ùn saperà mai chì l'API duveria è funziona. Ogni cambiamentu di l'API deve purtà à un cambiamentu di cuntrolli.
• Sè vo avete digià un tali prublemu, firmavanu i funziunalità è attribuisce i sviluppatori chì scriveranu sti cuntrolli, o accettà i perditi, accettà chì nunda hè verificatu è falla.

Cunsiglii tecnichi:

• Assicuratevi di urganizà un servitore esternu per urganizà cuntrolli - duvete esse sicuru chì u vostru prughjettu hè accessibile à u mondu esternu.
• Organizà cuntrolli in tuttu u protocolu API, micca solu punti finali individuali.
• Crea un prometheus-endpoint cù i risultati di a prova.

Stratu d'applicazione - monitoraghju di metrica di salute

Avà parlemu di metrica di salute esterna di servizii.

Avemu decisu chì monitoremu tutte e "maniche" di l'applicazione cù cuntrolli esterni, chì chjamemu da un sistema di monitoraghju esternu. Ma questi sò i "manichi" chì l'utilizatori "vede". Vulemu esse sicuru chì i nostri servizii stessi funzionanu. Ci hè una storia megliu quì: K8s hà cuntrolli di salute, perchè almenu u "cube" stessu pò esse cunvinta chì u serviziu funziona. Ma a mità di i cuntrolli chì aghju vistu sò a stessa stampa "hello world". Quelli. Allora tira una volta dopu a distribuzione, hà rispostu chì tuttu hè bè - questu hè tuttu. È u serviziu, s'ellu furnisce u so propiu API, hà un gran numaru di punti di ingressu per quella stessa API, chì deve ancu esse monitoratu, perchè vulemu sapè chì funziona. È l'avemu digià monitoratu in l'internu.

Cumu implementà questu tecnicumente currettamente: ogni serviziu espone un endpoint nantu à a so prestazione attuale, è in i grafici di Grafana (o qualsiasi altra applicazione) vedemu u statutu di tutti i servizii.

• Ogni cambiamentu di l'API deve purtà à un cambiamentu di cuntrolli.
• Crea un novu serviziu subitu cù metriche di salute.
• Un amministratore pò vene à i sviluppatori è dumandà "aghjunghje un paru di funzioni in modu chì capisce tuttu è aghjunghje infurmazioni nantu à questu à u mo sistema di monitoraghju". Ma i sviluppatori di solitu rispondenu: "Ùn aghjunghje micca nunda duie settimane prima di a liberazione".
  Fate sapè à i gestori di u sviluppu chì ci saranu tali perdite, chì a gestione di i gestori di u sviluppu sapia ancu. Perchè quandu tuttu cade, qualcunu chjamà sempre è dumandà à monitorà u "serviziu in constantemente caduta" (c)
• In modu, assignate sviluppatori per scrive plugins per Grafana - questu serà un bonu aiutu per l'amministratori.

Stratu di l'applicazione - Monitoraghju di l'integrazione

U monitoraghju di l'integrazione si focalizeghja in u monitoraghju di e cumunicazioni trà i sistemi critichi per l'affari.

Per esempiu, ci sò 15 servizii chì cumunicanu cù l'altri. Questi ùn sò più siti separati. Quelli. ùn pudemu micca tirà u serviziu per sè stessu, uttene / helloworld è capisce chì u serviziu hè in esecuzione. Perchè u serviziu web d'ordine deve mandà infurmazioni nantu à l'ordine à l'autobus - da u busu, u serviziu di magazzini deve riceve stu missaghju è travaglià cun ellu più. È u serviziu di distribuzione di e-mail deve processà questu in una certa manera, etc.

In cunsiquenza, ùn pudemu micca capisce, pudendu à ogni serviziu individuale, chì tuttu funziona. Perchè avemu un certu autobus attraversu quale tuttu cumunica è interagisce.
Dunque, sta tappa deve marcà u stadiu di i servizii di prova per l'interazzione cù altri servizii. Hè impussibile d'urganizà a surviglianza di a cumunicazione monitorendu u broker di messagiu. Se ci hè un serviziu chì emette dati è un serviziu chì riceve, quandu u monitoraghju di u broker, vi vede solu dati chì vola da un latu à l'altru. Ancu s'è avemu in qualchì modu riesciutu à monitorà l'interazzione di sti dati internu - chì un certu pruduttore publica i dati, qualcunu li leghje, stu flussu cuntinueghja à andà à Kafka - questu ùn ci darà micca infurmazione se un serviziu hà mandatu u missaghju in una versione. , ma l'altru serviziu ùn s'aspittava micca sta versione è l'hà saltatu. Ùn sapemu micca di questu, postu chì i servizii ci diceranu chì tuttu funziona.

Cosa vi cunsigliu di fà:

• Per a cumunicazione sincrona: l'endpoint fa richieste à i servizii cunnessi. Quelli. Pigliemu questu endpoint, tirà un script in u serviziu, chì và à tutti i punti è dice "Puderaghju tirà quì, è tirà quì, possu tirà quì ..."
• Per a cumunicazione asincrona: missaghji in entrata - l'endpoint verifica l'autobus per i missaghji di prova è mostra u statu di trasfurmazioni.
• Per a cumunicazione asincrona: missaghji in uscita - l'endpoint manda messagi di prova à l'autobus.

Cum'è di solitu: avemu un serviziu chì tira dati in l'autobus. Venemu à stu serviziu è vi dumandemu di parlà di a so salute integrazione. È se u serviziu hà bisognu di pruduce un missaghju in un locu più (WebApp), allora pruducerà stu missaghju di prova. È s'ellu ci hè un serviziu nantu à u latu OrderProcessing, prima postu ciò chì pò pubblicà indipindenti, è s'ellu ci sò parechje cose dipendente, allora leghje un inseme di messagi di teste da l'autobus, capisce chì pò processà, rappurtallu è , se ne necessariu, postu più, è annantu à questu dice - tuttu hè bè, sò vivu.

Assai spessu sentemu a quistione "cumu pudemu pruvà questu nantu à e dati di cummattimentu?" Per esempiu, parlemu di u listessu serviziu di ordine. L'ordine manda messagi à u magazzinu induve e merchenzie sò scritte: ùn pudemu micca pruvà questu nantu à e dati di cummattimentu, perchè "a mo merchenzie serà scritta!" Soluzione: Pianificate sta prova sana à u principiu. Avete ancu e teste di unità chì facenu mocks. Allora, fate à un livellu più profundo induve avete un canali di cumunicazione chì ùn dannu micca u funziunamentu di l'affari.

Livellu di infrastruttura

U monitoraghju di l'infrastruttura hè qualcosa chì hè statu longu cunzidiratu u monitoraghju stessu.

• U monitoraghju di l'infrastruttura pò è deve esse lanciatu cum'è un prucessu separatu.
• Ùn avete micca principiatu cù u monitoraghju di l'infrastruttura nantu à un prughjettu in esecuzione, ancu s'ellu vulete veramente. Questu hè un dolore per tutti i devops. "Prima aghju monitoratu u cluster, aghju monitoratu l'infrastruttura" - i.e. Prima, monitorerà ciò chì si trova sottu, ma ùn entrerà in l'applicazione. Perchè l'applicazione hè una cosa incomprensibile per i devops. Hè stata filtrata à ellu, è ùn capisce micca cumu si travaglia. È capisce l'infrastruttura è principia cun ella. Ma no - avete sempre bisognu di monitorà l'applicazione prima.
• Ùn andate in mare cù u numeru di alerti. In cunsiderà a cumplessità di i sistemi muderni, l'alerte sò constantemente volate, è avete da campà in qualchì manera cù questa mansa di alerti. È a persona di chjamà, dopu avè vistu un centu di e prossime alerte, deciderà "Ùn vogliu micca pensà à questu". L'alerte anu da avvisà solu nantu à e cose critiche.

Livellu di applicazione cum'è unità cummerciale

Punti chjave:

• ELK. Questu hè u standard di l'industria. Se per una certa ragione ùn site micca aggregating logs, cuminciate à fà immediatamente.
• APM. APM esterni cum'è un modu per chjude rapidamente u monitoraghju di l'applicazione (NewRelic, BlackFire, Datadog). Pudete installà sta cosa temporaneamente per almenu capisce ciò chì succede cun voi.
• Tracing. In decine di microservizi, avete a traccia di tuttu, perchè a dumanda ùn vive più da sola. Hè assai difficiuli di aghjunghje dopu, per quessa, hè megliu pianificà immediatamente a traccia in u sviluppu - questu hè u travagliu è l'utilità di i sviluppatori. Se ùn l'avete ancu implementatu, implementate ! Vede Jaeger/Zipkin

Alerta

• Urganizazione di un sistema di notificazione: in cundizioni di monitorizazione di una mansa di cose, deve esse un sistema unificatu per mandà notificazioni. Pudete in Grafana. In l'Occidenti, tutti usanu PagerDuty. L'alerta deve esse chjara (per esempiu, da induve venenu...). È hè cunsigliu per cuntrullà chì e notificazioni sò ricevute in tuttu
• Urganisazione di un sistema di duvere: l'alerta ùn deve esse mandata à tutti (o tutti reagiranu in una folla, o nimu ùn reagisce). I sviluppatori anu ancu bisognu à esse oncall: assicuratevi di definisce e zone di rispunsabilità, fate struzzioni chjaru è scrivite in ellu quale esattamente chjamà u luni è u mercuri, è quale chjamà u marti è u vennari (altrimenti ùn chjamà nimu ancu in u avvenimentu di un grande prublema - avaranu paura di svegliate o disturbà : a ghjente in generale ùn piace micca chjamà è svegliate altre persone, soprattuttu di notte). E spiegà chì dumandà aiutu ùn hè micca un indicatore di incompetenza ("Dumandu aiutu, questu significa chì sò un malu travagliadore"), incuraghjenu e dumande d'aiutu.
• Urganizazione di una "base di cunniscenza" è u flussu di travagliu per u processu di l'incidentu: per ogni incidente seriu, un post-mortem deve esse pianificatu, è cum'è una misura temporale, l'azzioni chì risolverà l'incidentu deve esse registratu. È fate una pratica chì l'alerta ripetuta sò un peccatu; anu da esse riparatu in u travagliu di codice o infrastruttura.

Pila di tecnulugia

Imaginemu chì a nostra pila hè a siguenti:

• raccolta di dati - Prometheus + Grafana;
• analisi di log - ELK;
• per APM o Tracing - Jaeger (Zipkin).

A scelta di l'opzioni ùn hè micca critica. Perchè se à u principiu avete capitu cumu monitorà u sistema è hà scrittu un pianu, allora avete principiatu à sceglie l'arnesi per adattà à i vostri bisogni. A quistione hè ciò chì avete sceltu di monitorà in u primu locu. Perchè forse l'uttellu chì avete sceltu à u principiu ùn hè micca adattatu à i vostri bisogni.

Uni pochi punti tecnichi chì vecu in ogni locu ultimamente:

Prometheus hè imbuttatu in Kubernetes - quale hè stata cun questu ?! Se u vostru cluster crashes, chì fate? Se tenete un cluster cumplessu in l'internu, allora ci duverebbe esse un sistema di monitoraghju in u cluster, è un pocu fora, chì raccoglierà dati da l'internu di u cluster.

Dentru u cluster, cullemu logs è tuttu u restu. Ma u sistema di surviglianza deve esse fora. Moltu spessu, in un cluster induve ci hè Promtheus installatu internamente, ci sò ancu sistemi chì facenu cuntrolli esterni di u funziunamentu di u situ. E se e vostre cunnessione cù u mondu esternu sò cascate è l'applicazione ùn funziona micca? Ci hè chì tuttu hè bè in l'internu, ma ùn facilita micca e cose per l'utilizatori.

scuperti

• U sviluppu di monitoraghju ùn hè micca a stallazione di utilità, ma u sviluppu di un pruduttu software. U 98% di u monitoraghju d'oghje hè codificazione. Codificà in servizii, codificà i cuntrolli esterni, cuntrollà i servizii esterni, è questu hè tuttu.
• Ùn perde micca u tempu di i vostri sviluppatori in u monitoraghju: pò piglià finu à u 30% di u so travagliu, ma vale a pena.
• Devops, ùn vi preoccupate micca chì ùn pudete micca monitorà qualcosa, perchè certe cose sò un modu completamente diversu di pensà. Ùn erate micca un programatore, è u travagliu di monitoraghju hè esattamente u so travagliu.
• Se u prugettu hè digià in esecuzione è ùn hè micca monitoratu (è site un manager), assignate risorse per u monitoraghju.
• Se u pruduttu hè digià in pruduzzione, è site un devops chì hè statu dettu di "istituì u monitoraghju" - pruvate à spiegà à a gestione ciò chì aghju scrittu tuttu questu.

Questa hè una versione estesa di u rapportu à a cunferenza di Saint Highload++.

Sè site interessatu à e mo idee è pinsamenti nantu à questu è temi cunnessi, allora pudete quì leghje u canali 🙂

Source: www.habr.com