Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Bonghjornu ognunu!

A nostra cumpagnia hè impegnata in u sviluppu di u software è u sustegnu tecnicu sussegwenti. U supportu tecnicu richiede micca solu di correggere l'errori, ma di monitorà u rendiment di e nostre applicazioni.

Per esempiu, s'è unu di i servizii hà sbattutu, allura vi tuccherà à registrà in autumàticu stu prublemu è cumincianu a risolviri lu, è ùn aspittà di utilizatori dissatisfied à cuntattà u sustegnu tecnicu.

Avemu una piccula cumpagnia, ùn avemu micca e risorse per studià è mantene ogni suluzione cumplessa per l'applicazioni di monitoraghju, avemu bisognu di truvà una suluzione simplice è efficace.

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Strategia di monitoraghju

Ùn hè micca faciule per verificà a funziunalità di una applicazione; stu compitu ùn hè micca triviale, si pò ancu dì creativa. Hè soprattuttu difficiuli di verificà un sistema multi-link cumplessu.

Cumu pudete manghjà un elefante? Solu in parti! Utilizemu stu approcciu per monitorà l'applicazioni.

L'essenza di a nostra strategia di monitoraghju:

Divide a vostra applicazione in cumpunenti.
Crea cuntrolli di cuntrollu per ogni cumpunente.

Un cumpunente hè cunsideratu operativu se tutti i so cuntrolli di cuntrollu sò realizati senza errori. Una applicazione hè cunsiderata sana se tutti i so cumpunenti sò funziunali.

Cusì, ogni sistema pò esse rapprisintatu cum'è un arbre di cumpunenti. I cumpunenti cumplessi sò spartuti in più simplici. I cumpunenti simplici anu cuntrolli.

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

I benchmarks ùn sò micca destinati à fà teste funziunali, ùn sò micca teste di unità. I cuntrolli di cuntrollu deve verificà cumu si senti u cumpunente in u mumentu attuale in u tempu, s'ellu ci sò tutte e risorse necessarie per u so funziunamentu, è s'ellu ci sò prublemi.

Ùn ci sò micca miraculi; a maiò parte di i cuntrolli anu da esse sviluppati indipindente. Ma ùn vi scantati, perchè in a maiò parte di i casi un verificatu pigghia 5-10 linee di codice, ma pudete implementà ogni logica è capisce chjaramente cumu u cuntrollu funziona.

Sistema di monitoraghju

Diciamu chì avemu spartutu l'applicazione in cumpunenti, hà sviluppatu è implementatu cuntrolli per ogni cumpunente, ma chì fà cù i risultati di sti cuntrolli? Cumu sapemu s'ellu ci hè stata una verificazione?

Avemu bisognu di un sistema di surviglianza. Ella farà i seguenti compiti:

  • Riceve risultati di teste è aduprate per determinà u statutu di cumpunenti.
    Visualmente, questu s'assumiglia à mette in risaltu l'arbulu di cumpunenti. I cumpunenti funziunali diventanu verdi, quelli problematici diventanu rossi.
  • Eseguite cuntrolli generali fora di a scatula.
    U sistema di surviglianza pò fà alcuni cuntrolli stessu. Perchè reinventà a rota, usemu. Per esempiu, pudete verificà chì una pagina di u situ web hè apertu o u servitore hè ping.
  • Mandate notifiche di prublemi à i partiti interessati.
  • Visualizazione di dati di monitoraghju, furnimentu di rapporti, grafici è statistiche.

Breve descrizzione di u sistema ASMO

Hè megliu spiegà cù un esempiu. Fighjemu cumu u monitoraghju di u funziunamentu di u sistema ASMO hè urganizatu.

ASMO hè un sistema di supportu meteorologicu automatizatu. U sistema aiuta à i spezialisti di u serviziu di strada à capiscenu induve è quandu hè necessariu di trattà a strada cù materiali di de-icing. U sistema raccoglie dati da i punti di cuntrollu di strada. Un puntu di cuntrollu di strada hè un locu nantu à a strada induve l'equipaggiu hè stallatu: una stazione meteorologica, una videocamera, etc. Per predichendu situazioni periculose, u sistema riceve previsioni meteorologiche da fonti esterne.

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Dunque, a cumpusizioni di u sistema hè abbastanza tipica: situ web, agente, equipamentu. Cuminciamu a monitorizazione.

Spartite u sistema in cumpunenti

I seguenti cumpunenti ponu esse distinti in u sistema ASMO:

1. contu persunale
Questa hè una applicazione web. À u minimu, avete bisognu di verificà chì l'applicazione hè dispunibule nantu à Internet.

2. Database
A basa di dati guarda dati chì hè impurtante per u rapportu, è avete da assicurà chì e backups di basa di dati sò creati bè.

3. Servitore
Per servitore intendemu u hardware nantu à quale l'applicazioni eseguite. Hè necessariu di verificà u statutu di HDD, RAM, CPU.

4. Agente
Questu hè un serviziu Windows chì eseguisce parechje attività diverse nantu à un schedariu. À u minimu, avete bisognu di verificà chì u serviziu funziona.

5. Compito di agenti
Solu sapendu chì un agentu travaglia ùn hè micca abbastanza. Un agentu pò travaglià, ma micca eseguisce i so compiti assignati. Dividemu u cumpunente di l'agente in attività è verificate se ogni attività di l'agente funziona bè.

6. Punti di cuntrollu di strada (contenitore di tutti i MPC)
Ci sò parechji punti di cuntrollu di strada, cusì unisce tutti i MPC in un cumpunente. Stu vi farà più còmuda à leghje dati surviglianza. Quandu si vede u statutu di u cumpunente "sistema ASMO", serà immediatamente chjaru induve sò i prublemi: in applicazioni, hardware o in u sistema di cuntrollu massimu.

7. Puntu di cuntrollu di strada (un limite massimu)
Avemu da cunsiderà stu cumpunente à esse serviceable se tutti i dispusitivi in ​​stu MPC sò serviceable.

8. Dispositivu
Questa hè una videocamera o stazione meteorologica chì hè stallata à u limitu massimu di cuncentrazione. Hè necessariu di verificà chì u dispusitivu hè travagliatu bè.

In u sistema di surviglianza, l'arburu di cumpunenti serà cusì:

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Monitoraghju di l'applicazioni Web

Dunque, avemu divisu u sistema in cumpunenti, avà avemu bisognu di cuntrolli per ogni cumpunente.

Per monitorà una applicazione web usemu i seguenti cuntrolli:

1. Verificate l'apertura di a pagina principale
Stu cuntrollu hè realizatu da u sistema di surviglianza. Per eseguisce, indichemu l'indirizzu di a pagina, u frammentu di risposta prevista è u tempu massimu di esecuzione di a dumanda.

2. Cuntrollà u termini di pagamentu duminiu
Un cuntrollu assai impurtante. Quandu un duminiu ùn hè micca pagatu, l'utilizatori ùn ponu micca apre u situ. Risolviri u prublema pò piglià parechji ghjorni, perchè ... I cambiamenti DNS ùn sò micca applicati immediatamente.

3. Cuntrollà u certificatu SSL
Oghje, quasi tutti i siti web utilizanu u protocolu https per l'accessu. Per u protocolu per travaglià bè, avete bisognu di un certificatu SSL validu.

Quì sottu hè u cumpunente "Contu persunale" in u sistema di monitoraghju:

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Tutti i cuntrolli sopra travaglianu per a maiò parte di l'applicazioni è ùn necessitanu micca codificazione. Questu hè assai bellu perchè pudete inizià a monitorizazione di qualsiasi applicazione web in 5 minuti. Quì sottu sò cuntrolli supplementari chì ponu esse realizati per una applicazione web, ma a so implementazione hè più cumplessa è specifica per l'applicazione, per quessa ùn l'avemu micca copre in questu articulu.

Chì altru pudete verificà?

Per monitorizà più cumpletamente a vostra applicazione web, pudete fà i seguenti cuntrolli:

  • Numero di errori JavaScript per periodu
  • Numaru di errori in u latu di l'applicazione web (back-end) per u periodu
  • Numeru di risposte di l'applicazioni web senza successu (codice di risposta 404, 500, etc.)
  • Tempu mediu di esecuzione di a dumanda

Monitoring un serviziu Windows (agente)

In u sistema ASMO, l'agente ghjoca u rolu di un pianificatore di attività, chì eseguisce i travaglii pianificati in fondo.

Se tutti i travaglii di l'agente cumpletu bè, l'agente funziona bè. Ci hè chì per monitorà un agentu, avete bisognu di monitorà e so attività. Per quessa, avemu dividitu u cumpunenti "Agent" in compiti. Per ogni compitu, creeremu un cumpunente separatu in u sistema di surviglianza, induve u cumpunente "Agent" serà u "parent".

Dividemu u cumpunente di l'Agente in cumpunenti di u zitellu (tasks):

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Dunque, avemu spartutu un cumpunente cumplessu in parechje simplicità. Avà avemu bisognu di cuntrolli per ogni cumpunente simplice. Per piacè nutate chì u cumpunente parent "Agent" ùn averà micca cuntrolli, perchè u sistema di surviglianza calculerà u so status indipindentamente basatu annantu à u statutu di i so cumpunenti di u zitellu. In altri palori, se tutti i travaglii sò cumpletati cù successu, allora l'agente funziona bè.

Ci hè più di centu cumpetenze in u sistema ASMO, hè veramente necessariu di vene cun cuntrolli unichi per ogni compitu? Di sicuru, u cuntrollu serà megliu s'ellu ci vene è implementà i nostri cuntrolli speciali per ogni compitu di l'agente, ma in a maiò parte di i casi hè abbastanza per utilizà cuntrolli universali.

U sistema ASMO usa solu cuntrolli universali per i travaglii è questu hè abbastanza per monitorizà u rendiment di u sistema.

Cuntrollà u prugressu
A verificazione più simplice è efficace hè a verificazione di l'esekzione. U cuntrollu verifica chì u compitu hè cumpletu senza errori. Tutti i travaglii anu stu cuntrollu.

Algoritmu di cuntrollu

Dopu à ogni esecutivu compitu, avete bisognu di mandà u risultatu di u cuntrollu SUCCESS à u sistema di surviglianza se l'esekzione di u compitu hè successu, o ERRORE se l'esekzione hè cumpletata cù un errore.

Stu cuntrollu pò detectà i seguenti prublemi:

  1. U compitu corre ma falla cù un errore.
  2. U compitu hà cessatu di correre, per esempiu, hè congelatu.

Fighjemu cumu questi prublemi sò risolti in più detail.

Issue 1 - U compitu corre ma falla cù un errore
Quì sottu hè un casu induve u compitu corre ma falla trà 14:00 è 16:00.

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

A figura mostra chì quandu un compitu falla, un signalu hè immediatamente mandatu à u sistema di surviglianza è u statutu di u cuntrollu currispundente in u sistema di surviglianza diventa alarma.

Per piacè nutate chì in u sistema di surviglianza, u statutu di u cumpunente dipende da u statu di verificazione. U statutu d'alarma di u cuntrollu cambierà tutti i cumpunenti di livellu più altu in alarme, vede a figura sottu.

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Prublemu 2 - U compitu hà cessatu di eseguisce (congelatu)
Cumu u sistema di monitoraghju capisce chì un compitu hè stuck?

U risultatu di u cuntrollu hà un periodu di validità, per esempiu, 1 ora. Se passa una ora è ùn ci hè micca un novu risultatu di teste, u sistema di surviglianza stabiliscerà u statu di prova in alarme.

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

In a stampa sopra, i lumi sò stati spenti à 14:00 p.m. À 15:00, u sistema di surviglianza detecterà chì u risultatu di a prova (da 14:00) hè rottu, perchè U tempu di pertinenza hè scadutu (una ora), ma ùn ci hè micca un novu risultatu, è cambia u cuntrollu à u statu di alarme.

À 16:00 i luci sò stati tornati, u prugramma hà da compie u compitu è ​​mandà u risultatu di l'esekzione à u sistema di surviglianza, u statutu di a prova serà torna successu.

Chì verificate u tempu di pertinenza deve aduprà?

U tempu di pertinenza deve esse più grande di u periodu di esecuzione di u travagliu. Aghju ricumandemu di stabilisce u tempu di pertinenza 2-3 volte più longu di u periodu di esecuzione di u travagliu. Questu hè necessariu per evità di riceve notifiche falsi quandu, per esempiu, un compitu hà pigliatu più di u solitu o qualcunu hà ricaricatu u prugramma.

Cuntrollà u prugressu

U sistema ASMO hà un compitu "Load Forecast", chì prova di scaricà una nova previsione da una fonte esterna una volta à l'ora. L'ora esatta quandu una nova previsione appare in u sistema esternu ùn hè micca cunnisciutu, ma hè cunnisciutu chì questu succede 2 volte à ghjornu. Risulta chì s'ellu ùn ci hè micca una nova previsione per parechje ore, allora questu hè normale, ma s'ellu ùn ci hè micca una nova previsione per più di un ghjornu, allora qualcosa hè rottu in qualchì locu. Per esempiu, u formatu di dati in un sistema di previsione esterna pò cambià, per quessa ASMO ùn vede micca una nova liberazione di previsione.

Algoritmu di cuntrollu

U compitu manda u risultatu di a verificazione SUCCESS à u sistema di surviglianza quandu riesce à ottene u prugressu (scaricamentu di una nova previsione meteorologica). Se ùn ci hè micca prugressu o un errore si trova, allora nunda hè mandatu à u sistema di surviglianza.

U cuntrollu deve avè un intervallu di rilevanza cusì chì durante stu tempu hè garantitu per riceve novi prugressi.

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Per piacè nutate chì avemu da amparà nantu à u prublema cù un ritardu, perchè u sistema di surviglianza aspetta finu à u periodu di validità di l'ultimu risultatu di scansione. Per quessa, u periodu di validità di u cuntrollu ùn deve esse fattu troppu longu.

Monitoraghju di basa di dati

Per cuntrullà a basa di dati in u sistema ASMO, facemu i seguenti cuntrolli:

  1. Verificà a creazione di salvezza
  2. Verificate u spaziu di discu liberu

Verificà a creazione di salvezza
In a maiò parte di l'applicazioni, hè impurtante di avè una copia di salvezza di basa di dati aghjurnata per chì se u servitore falla, pudete implementà u prugramma à un novu servitore.

ASMO crea una copia di salvezza una volta à settimana è a manda à u almacenamiento. Quandu sta prucedura hè cumpleta cù successu, u risultatu di u cuntrollu di successu hè mandatu à u sistema di surviglianza. U risultatu di verificazione hè validu per 9 ghjorni. Quelli. Per cuntrullà a creazione di copia di salvezza, hè utilizatu u mecanismu di "verifica di u prugressu", chì avemu discututu sopra.

Verificate u spaziu di discu liberu
Se ùn ci hè micca abbastanza spaziu liberu nantu à u discu, a basa di dati ùn puderà micca funzionà bè, per quessa hè impurtante di cuntrullà a quantità di spaziu liberu.

Hè cunvenutu à utilizà metrica per verificà i paràmetri numerichi.

Metriche hè una variabile numerica, u valore di quale hè trasmessu à u sistema di surviglianza. U sistema di surviglianza verifica i valori di soglia è calcula u statutu metricu.

Quì sottu hè una figura di ciò chì u cumpunente "Database" s'assumiglia in u sistema di surviglianza:

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Surviglianza di u servitore

Per monitorà u servitore usemu i seguenti cuntrolli è metriche:

1. Spaziu discu liberu
Se u spaziu di discu scorri, l'applicazione ùn puderà micca travaglià. Avemu aduprà 2 valori di soglia: u primu livellu hè AVVISU, u sicondu livellu hè ALARM.

2. Valore RAM mediu in percentu per ora
Usemu a media oraria perchè ... ùn avemu micca interessatu in rari rari.

3. Percentuale media di CPU per ora
Usemu a media oraria perchè ... ùn avemu micca interessatu in rari rari.

4. Ping check
Verificate chì u servitore hè in linea. U sistema di surviglianza pò fà sta verificazione; ùn ci hè bisognu di scrive codice.

Quì sottu hè una stampa di ciò chì u cumpunente "Server" s'assumiglia in u sistema di surviglianza:

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Monitoraghju di l'equipaggiu

Vi dicu cumu si ottene e dati. Per ogni puntu di cuntrollu di strada (MPC) ci hè un compitu in u pianificatore di u travagliu, per esempiu, "Survey MPC M2 km 200". U compitu riceve dati da tutti i dispositi MPC ogni 30 minuti.

Prublemu di u canali di cumunicazione
A maiò parte di l'equipaggiu si trova fora di a cità; una reta GSM hè aduprata per a trasmissione di dati, chì ùn viaghja micca stabile (ci hè una reta, o ùn ci hè micca una).

A causa di frequenti fallimenti di a rete, in prima, a verificazione di l'indagine MPC in u monitoraghju pareva cusì:

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Hè diventatu chjaru chì questu ùn era micca una opzione di travagliu, perchè ci sò parechje notifiche falsi nantu à i prublemi. Allora hè statu decisu di utilizà un "verificà di prugressu" per ogni dispusitivu, i.e. Solu u signale successu hè mandatu à u sistema di surviglianza quandu u dispusitivu hè polled senza errore. U tempu di pertinenza hè stata stabilita à 5 ore.

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Avà u monitoraghju manda notifiche nantu à i prublemi solu quandu u dispusitivu ùn pò esse sondatu per più di 5 ore. Cù un altu gradu di probabilità, ùn sò micca falsi alarmi, ma prublemi veri.

Quì sottu hè una figura di ciò chì l'equipaggiu pare in u sistema di monitoraghju:

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

Impurtante!
Quandu a reta GSM ferma di travaglià, tutti i dispusitivi MDC ùn sò micca sondati. Per riduce u nùmeru di email da u sistema di surviglianza, i nostri ingegneri abbonate à notificazioni nantu à i prublemi di cumpunenti cù u tipu "MPC" invece di "Dispositivu". Questu permette di riceve una notificazione per ogni MPC, invece di riceve una notificazione separata per ogni dispusitivu.

Schema finali di monitoraghju ASMO

Mettimu tuttu inseme è vedemu chì tipu di schema di surviglianza avemu.

Manghjemu l'elefante in parte. Strategia di monitoraghju di a salute di l'applicazione cù esempi

cunchiusioni

Riassumemu.
Chì ci hà datu u monitoraghju di u rendiment di ASMO ?

1. U tempu di eliminazione di difetti hè diminuitu
Avemu digià intesu parlà di difetti da l'utilizatori, ma micca tutti l'utilizatori riportanu difetti. Hè accadutu chì avemu amparatu nantu à un malfunzionamentu di un cumpunente di u sistema una settimana dopu à l'apparizione. Avà u sistema di surviglianza ci avvisa di prublemi appena un prublema hè rilevatu.

2. A stabilità di u sistema hà aumentatu
Siccomu i difetti cuminciaru à esse eliminati prima, u sistema in generale hà cuminciatu à travaglià assai più stabile.

3. Reducing the number of calls to support technique
Parechji prublemi sò avà risolti prima chì l'utilizatori anu ancu sapè di elli. L'utilizatori cuminciaru à cuntattà u supportu tecnicu menu spessu. Tuttu chistu hà un bonu effettu nantu à a nostra reputazione.

4. Aumentà a fidelizazione di i clienti è di l'utilizatori
U cliente hà nutatu cambiamenti pusitivi in ​​a stabilità di u sistema. L'utilizatori scontranu menu prublemi cù u sistema.

5. Reduce i costi di supportu tecnicu
Avemu cessatu di fà qualsiasi cuntrolli manuali. Avà tutti i cuntrolli sò automatizati. Nanzu, avemu amparatu nantu à i prublemi da l'utilizatori; era spessu difficiuli di capisce quale prublema parlava l'utilizatore. Avà, a maiò parte di i prublemi sò signalati da u sistema di monitoraghju; e notificazioni cuntenenu dati tecnichi, chì sempre rende chjaru ciò chì hè andatu male è induve.

Impurtante!
Ùn pudete micca installà u sistema di surviglianza in u stessu servitore induve e vostre applicazioni eseguite. Se u servitore scende, l'applicazioni cessanu di travaglià è ùn ci sarà nimu per avvisà.

U sistema di surviglianza deve eseguisce nantu à un servitore separatu in un altru centru di dati.

Se ùn vulete micca aduprà un servitore dedicatu in un novu centru di dati, pudete aduprà un sistema di surviglianza in nuvola. A nostra cumpagnia usa u sistema di surviglianza in nuvola Zidium, ma pudete aduprà qualsiasi altru sistema di surviglianza. U costu di un sistema di surviglianza in nuvola hè più bassu di l'affittu di un novu servitore.

Récordi:

  1. Rompe l'applicazioni è i sistemi in a forma di un arbre di cumpunenti in u più dettagliu pussibule, cusì serà cunvene per capiscenu induve è ciò chì hè rottu, è u cuntrollu serà più cumpletu.
  2. Per verificà a funziunalità di un cumpunente, utilizate testi. Hè megliu aduprà parechje cuntrolli simplici chè unu cumplessu.
  3. Configurate i limiti metrici à u latu di u sistema di surviglianza, invece di scrive in codice. Questu vi salverà da avè da recompilà, cunfigurà o riavvia l'applicazione.
  4. Per i cuntrolli persunalizati, aduprate un marghjenu di tempu di rilevanza per evità di riceve notifiche falsi perchè qualchì verificazione hà pigliatu un pocu più di tempu per esse cumpletu di u solitu.
  5. Pruvate di fà i cumpunenti in u sistema di surviglianza diventanu rossi solu quandu ci hè definitu un prublema. S'elli diventanu rossi per nunda, allora vi cessate di attentu à e notificazioni di u sistema di surviglianza, u so significatu serà persu.

Se ùn avete micca aduprà un sistema di monitoraghju, cuminciate! Ùn hè micca cusì difficiule cum'è pare. Prufittate di guardà l'arburu di ingredienti verdi chì avete cultivatu stessu.

Bona furtuna.

Source: www.habr.com

Add a comment