Bună ziua tuturor!
Compania noastră este angajată în dezvoltarea de software și asistența tehnică ulterioară. Asistența tehnică necesită nu doar remedierea erorilor, ci și monitorizarea performanței aplicațiilor noastre.
De exemplu, dacă unul dintre servicii s-a prăbușit, atunci trebuie să înregistrați automat această problemă și să începeți să o rezolvați și să nu așteptați ca utilizatorii nemulțumiți să contacteze suportul tehnic.
Avem o companie mică, nu avem resursele să studiem și să întreținem soluții complexe de monitorizare a aplicațiilor, trebuia să găsim o soluție simplă și eficientă.
Strategia de monitorizare
Nu este ușor să verifici funcționalitatea unei aplicații; această sarcină nu este banală, s-ar putea spune chiar creativă. Este deosebit de dificil de verificat un sistem multi-link complex.
Cum poți mânca un elefant? Doar pe părți! Folosim această abordare pentru a monitoriza aplicațiile.
Esența strategiei noastre de monitorizare:
Împărțiți aplicația în componente.
Creați verificări de control pentru fiecare componentă.
O componentă este considerată operațională dacă toate verificările sale de control sunt efectuate fără erori. O aplicație este considerată sănătoasă dacă toate componentele sale sunt funcționale.
Astfel, orice sistem poate fi reprezentat ca un arbore de componente. Componentele complexe sunt împărțite în altele mai simple. Componentele simple au verificări.
Benchmark-urile nu sunt menite să efectueze teste funcționale, nu sunt teste unitare. Verificările de control ar trebui să verifice cum se simte componenta în momentul actual, dacă există toate resursele necesare pentru funcționarea acesteia și dacă există probleme.
Nu există miracole; majoritatea verificărilor vor trebui dezvoltate independent. Dar nu vă speriați, pentru că în cele mai multe cazuri o verificare are 5-10 linii de cod, dar puteți implementa orice logică și veți înțelege clar cum funcționează verificarea.
Sistem de monitorizare
Să presupunem că am împărțit aplicația în componente, am creat și am implementat verificări pentru fiecare componentă, dar ce să facem cu rezultatele acestor verificări? De unde știm dacă o verificare a eșuat?
Vom avea nevoie de un sistem de monitorizare. Ea va îndeplini următoarele sarcini:
- Primiți rezultatele testelor și utilizați-le pentru a determina starea componentelor.
Din punct de vedere vizual, aceasta arată ca evidențierea arborelui componente. Componentele funcționale devin verzi, cele problematice devin roșii. - Efectuați verificări generale din cutie.
Sistemul de monitorizare poate efectua singur unele verificări. De ce să reinventăm roata, să le folosim. De exemplu, puteți verifica dacă o pagină de site web se deschide sau serverul emite ping. - Trimiteți notificări de probleme către părțile interesate.
- Vizualizarea datelor de monitorizare, furnizarea de rapoarte, grafice și statistici.
Scurtă descriere a sistemului ASMO
Cel mai bine este să explici cu un exemplu. Să ne uităm la modul în care este organizată monitorizarea performanței sistemului ASMO.
ASMO este un sistem automat de suport meteorologic. Sistemul îi ajută pe specialiștii în service rutier să înțeleagă unde și când este necesar să se trateze drumul cu materiale de degivrare. Sistemul colectează date de la punctele de control rutier. Un punct de control rutier este un loc de pe drum unde sunt instalate echipamente: o stație meteo, o cameră video etc. Pentru a prezice situații periculoase, sistemul primește prognoze meteo din surse externe.
Deci, compoziția sistemului este destul de tipică: site web, agent, echipament. Să începem monitorizarea.
Descompunerea sistemului în componente
Următoarele componente pot fi distinse în sistemul ASMO:
1. Cont personal
Aceasta este o aplicație web. Cel puțin, trebuie să verificați dacă aplicația este disponibilă pe Internet.
2. Baza de date
Baza de date stochează date care sunt importante pentru raportare și trebuie să vă asigurați că copiile de siguranță ale bazei de date sunt create cu succes.
3. Server
Prin server ne referim la hardware-ul pe care rulează aplicațiile. Este necesar să verificați starea HDD, RAM, CPU.
4. Agent
Acesta este un serviciu Windows care efectuează multe sarcini diferite într-un program. Cel puțin, trebuie să verificați dacă serviciul rulează.
5. Sarcina de agent
Doar să știi că un agent lucrează nu este suficient. Un agent poate lucra, dar nu poate îndeplini sarcinile care i-au fost atribuite. Să împărțim componenta agent în sarcini și să verificăm dacă fiecare activitate de agent funcționează cu succes.
6. Puncte de control rutier (containerul tuturor MPC-urilor)
Există multe puncte de control rutier, așa că haideți să combinăm toate MPC-urile într-o singură componentă. Acest lucru va face mai convenabil citirea datelor de monitorizare. Când vizualizați starea componentei „sistem ASMO”, va fi imediat clar unde sunt problemele: în aplicații, hardware sau în sistemul de control maxim.
7. Punct de control rutier (o limită maximă)
Vom considera că această componentă poate fi reparată dacă toate dispozitivele de pe acest MPC sunt reparabile.
8. Dispozitiv
Aceasta este o cameră video sau o stație meteo care este instalată la limita maximă de concentrație. Este necesar să verificați dacă dispozitivul funcționează corect.
În sistemul de monitorizare, arborele componente va arăta astfel:
Monitorizarea aplicațiilor web
Deci, am împărțit sistemul în componente, acum trebuie să venim cu verificări pentru fiecare componentă.
Pentru a monitoriza o aplicație web folosim următoarele verificări:
1. Verificarea deschiderii paginii principale
Această verificare este efectuată de sistemul de monitorizare. Pentru a-l executa, indicăm adresa paginii, fragmentul de răspuns așteptat și timpul maxim de executare a cererii.
2. Verificarea termenului de plată a domeniului
O verificare foarte importantă. Când un domeniu rămâne neplătit, utilizatorii nu pot deschide site-ul. Rezolvarea problemei poate dura câteva zile, deoarece... Modificările DNS nu sunt aplicate imediat.
3. Verificarea certificatului SSL
În prezent, aproape toate site-urile web folosesc protocolul https pentru acces. Pentru ca protocolul să funcționeze corect, aveți nevoie de un certificat SSL valid.
Mai jos este componenta „Cont personal” din sistemul de monitorizare:
Toate verificările de mai sus vor funcționa pentru majoritatea aplicațiilor și nu necesită codificare. Acest lucru este foarte tare pentru că puteți începe să monitorizați orice aplicație web în 5 minute. Mai jos sunt verificări suplimentare care pot fi efectuate pentru o aplicație web, dar implementarea lor este mai complexă și specifică aplicației, așa că nu le vom acoperi în acest articol.
Ce altceva poți verifica?
Pentru a monitoriza mai complet aplicația dvs. web, puteți efectua următoarele verificări:
- Numărul de erori JavaScript pe perioadă
- Numărul de erori din partea aplicației web (back-end) pentru perioada respectivă
- Numărul de răspunsuri nereușite ale aplicației web (codul de răspuns 404, 500 etc.)
- Timp mediu de execuție a interogării
Monitorizarea unui serviciu Windows (agent)
În sistemul ASMO, agentul joacă rolul unui planificator de sarcini, care execută sarcinile programate în fundal.
Dacă toate sarcinile agentului sunt finalizate cu succes, agentul funcționează corect. Se pare că, pentru a monitoriza un agent, trebuie să-i monitorizezi sarcinile. Prin urmare, împărțim componenta „Agent” în sarcini. Pentru fiecare sarcină, vom crea o componentă separată în sistemul de monitorizare, unde componenta „Agent” va fi „părintele”.
Împărțim componenta Agent în componente copil (sarcini):
Deci, am împărțit o componentă complexă în câteva simple. Acum trebuie să venim cu verificări pentru fiecare componentă simplă. Vă rugăm să rețineți că componenta părinte „Agent” nu va avea nicio verificare, deoarece sistemul de monitorizare își va calcula starea independent pe baza stării componentelor sale secundare. Cu alte cuvinte, dacă toate sarcinile sunt finalizate cu succes, atunci agentul rulează cu succes.
Există mai mult de o sută de sarcini în sistemul ASMO, este cu adevărat necesar să se vină cu verificări unice pentru fiecare sarcină? Desigur, controlul va fi mai bun dacă venim cu și implementăm propriile verificări speciale pentru fiecare sarcină de agent, dar în majoritatea cazurilor este suficient să folosim verificări universale.
Sistemul ASMO utilizează numai verificări universale pentru sarcini și acest lucru este suficient pentru a monitoriza performanța sistemului.
Verificarea progresului
Cea mai simplă și mai eficientă verificare este verificarea execuției. Verificarea verifică dacă sarcina este finalizată fără erori. Toate sarcinile au această verificare.
Algoritm de verificare
După fiecare execuție a sarcinii, trebuie să trimiteți rezultatul verificării SUCCESS către sistemul de monitorizare dacă execuția sarcinii a avut succes sau EROARE dacă execuția s-a finalizat cu o eroare.
Această verificare poate detecta următoarele probleme:
- Sarcina rulează, dar eșuează cu o eroare.
- Sarcina a încetat să ruleze, de exemplu, a înghețat.
Să ne uităm la modul în care aceste probleme sunt rezolvate mai detaliat.
Problema 1 – Sarcina rulează, dar eșuează cu o eroare
Mai jos este un caz în care sarcina rulează, dar eșuează între 14:00 și 16:00.
Figura arată că atunci când o sarcină eșuează, un semnal este trimis imediat către sistemul de monitorizare și starea verificării corespunzătoare în sistemul de monitorizare devine alarmă.
Vă rugăm să rețineți că în sistemul de monitorizare, starea componentei depinde de starea verificării. Starea de alarmă a verificării va schimba toate componentele de nivel superior în alarmă, vezi figura de mai jos.
Problema 2 - Sarcina a încetat să se execute (înghețată)
Cum va înțelege sistemul de monitorizare că o sarcină este blocată?
Rezultatul verificării are o perioadă de valabilitate, de exemplu, 1 oră. Dacă trece o oră și nu există un rezultat nou al testului, sistemul de monitorizare va seta starea testului la alarmă.
În imaginea de mai sus, luminile au fost stinse la ora 14:00. La ora 15:00, sistemul de monitorizare va detecta că rezultatul testului (de la ora 14:00) este putrezit, deoarece Timpul de relevanță a expirat (o oră), dar nu există un rezultat nou și va trece verificarea în starea de alarmă.
La ora 16:00 luminile au fost aprinse din nou, programul va finaliza sarcina și va trimite rezultatul execuției către sistemul de monitorizare, starea testului va deveni din nou succes.
Ce timp de verificare ar trebui să folosesc?
Timpul de relevanță trebuie să fie mai mare decât perioada de execuție a sarcinii. Recomand setarea timpului de relevanță de 2-3 ori mai mare decât perioada de execuție a sarcinii. Acest lucru este necesar pentru a evita primirea de notificări false atunci când, de exemplu, o sarcină a durat mai mult decât de obicei sau cineva a reîncărcat programul.
Verificarea progresului
Sistemul ASMO are o sarcină „Load Forecast”, care încearcă să descarce o nouă prognoză dintr-o sursă externă o dată pe oră. Nu se cunoaște ora exactă când apare o nouă prognoză în sistemul extern, dar se știe că aceasta se întâmplă de 2 ori pe zi. Se pare că, dacă nu există o nouă prognoză pentru câteva ore, atunci acest lucru este normal, dar dacă nu există o nouă prognoză pentru mai mult de o zi, atunci ceva s-a stricat undeva. De exemplu, formatul datelor dintr-un sistem extern de prognoză se poate modifica, motiv pentru care ASMO nu va vedea o nouă ediție de prognoză.
Algoritm de verificare
Sarcina trimite rezultatul verificării SUCCESS către sistemul de monitorizare atunci când reușește să obțină progrese (descărcarea unei noi prognoze meteo). Dacă nu există niciun progres sau apare o eroare, atunci nimic nu este trimis către sistemul de monitorizare.
Verificarea trebuie să aibă un interval de relevanță astfel încât în acest timp să fie garantat că va primi progrese noi.
Vă rugăm să rețineți că vom afla despre problemă cu o întârziere, deoarece sistemul de monitorizare așteaptă până când expiră perioada de valabilitate a ultimului rezultat al scanării. Prin urmare, perioada de valabilitate a verificării nu trebuie să fie prea lungă.
Monitorizarea bazei de date
Pentru a controla baza de date în sistemul ASMO, efectuăm următoarele verificări:
- Se verifică crearea copiei de rezervă
- Se verifică spațiul liber pe disc
Se verifică crearea copiei de rezervă
În majoritatea aplicațiilor, este important să aveți copii de siguranță actualizate ale bazei de date, astfel încât, dacă serverul eșuează, puteți implementa programul pe un nou server.
ASMO creează o copie de rezervă o dată pe săptămână și o trimite la stocare. Când această procedură este finalizată cu succes, rezultatul verificării succesului este trimis către sistemul de monitorizare. Rezultatul verificării este valabil 9 zile. Acestea. Pentru a controla crearea de copii de rezervă, se folosește mecanismul de „verificare a progresului”, despre care am discutat mai sus.
Se verifică spațiul liber pe disc
Dacă nu există suficient spațiu liber pe disc, baza de date nu va putea funcționa corect, așa că este important să controlați cantitatea de spațiu liber.
Este convenabil să utilizați valori pentru a verifica parametrii numerici.
Valori este o variabilă numerică a cărei valoare este transmisă sistemului de monitorizare. Sistemul de monitorizare verifică valorile de prag și calculează starea metricii.
Mai jos este o imagine a cum arată componenta „Bază de date” în sistemul de monitorizare:
Monitorizare server
Pentru a monitoriza serverul, folosim următoarele verificări și valori:
1. Spațiu liber pe disc
Dacă spațiul pe disc se epuizează, aplicația nu va putea funcționa. Folosim 2 valori de prag: primul nivel este AVERTISMENT, al doilea nivel este ALARMĂ.
2. Valoarea RAM medie în procente pe oră
Folosim media orară pentru că... nu ne interesează rase rare.
3. Procentul mediu CPU pe oră
Folosim media orară pentru că... nu ne interesează rase rare.
4. Verificare ping
Verifică dacă serverul este online. Sistemul de monitorizare poate efectua această verificare; nu este nevoie să scrieți cod.
Mai jos este o imagine a cum arată componenta „Server” în sistemul de monitorizare:
Monitorizarea echipamentelor
Vă spun cum sunt obținute datele. Pentru fiecare punct de control rutier (MPC) există o sarcină în planificatorul de sarcini, de exemplu, „Survey MPC M2 km 200”. Sarcina primește date de la toate dispozitivele MPC la fiecare 30 de minute.
Problema canalului de comunicare
Majoritatea echipamentelor se află în afara orașului; pentru transmiterea datelor este utilizată o rețea GSM, care nu funcționează stabil (există o rețea sau nu există).
Din cauza defecțiunilor frecvente ale rețelei, la început, verificarea sondajului MPC în monitorizare a arătat astfel:
A devenit clar că aceasta nu era o opțiune de lucru, deoarece existau multe notificări false despre probleme. Apoi s-a decis să se utilizeze o „verificare a progresului” pentru fiecare dispozitiv, adică. Doar semnalul de succes este trimis către sistemul de monitorizare atunci când dispozitivul este interogat fără eroare. Timpul de relevanță a fost stabilit la 5 ore.
Acum, monitorizarea trimite notificări despre probleme numai atunci când dispozitivul nu poate fi interogat mai mult de 5 ore. Cu un grad ridicat de probabilitate, acestea nu sunt alarme false, ci probleme reale.
Mai jos este o imagine a cum arată echipamentul în sistemul de monitorizare:
Important!
Când rețeaua GSM nu mai funcționează, toate dispozitivele MDC nu sunt interogate. Pentru a reduce numărul de e-mailuri din sistemul de monitorizare, inginerii noștri se abonează la notificări despre problemele componentelor de tipul „MPC” mai degrabă decât „Dispozitiv”. Acest lucru vă permite să primiți o notificare pentru fiecare MPC, în loc să primiți o notificare separată pentru fiecare dispozitiv.
Schema finală de monitorizare ASMO
Să punem totul cap la cap și să vedem ce fel de schemă de monitorizare avem.
Concluzie
Să rezumam.
Ce ne-a oferit monitorizarea performanței ASMO?
1. Timpul de eliminare a defectelor a scăzut
Am auzit anterior despre defecte de la utilizatori, dar nu toți utilizatorii raportează defecte. S-a întâmplat să aflăm despre o defecțiune a unei componente a sistemului la o săptămână după ce a apărut. Acum sistemul de monitorizare ne anunță problemele de îndată ce o problemă este detectată.
2. Stabilitatea sistemului a crescut
Deoarece defectele au început să fie eliminate mai devreme, sistemul în ansamblu a început să funcționeze mult mai stabil.
3. Reducerea numărului de apeluri către suport tehnic
Multe probleme sunt acum rezolvate înainte ca utilizatorii să știe despre ele. Utilizatorii au început să contacteze mai rar asistența tehnică. Toate acestea au un efect bun asupra reputației noastre.
4. Creșterea loialității clienților și utilizatorilor
Clientul a observat schimbări pozitive în stabilitatea sistemului. Utilizatorii întâmpină mai puține probleme în utilizarea sistemului.
5. Reduceți costurile de suport tehnic
Am încetat să efectuăm orice verificări manuale. Acum toate verificările sunt automatizate. Anterior, am aflat despre probleme de la utilizatori; era adesea dificil să înțelegem despre ce problemă vorbea utilizatorul. Acum, cele mai multe probleme sunt raportate de sistemul de monitorizare; notificările conțin date tehnice, care arată întotdeauna clar ce a mers prost și unde.
Important!
Nu puteți instala sistemul de monitorizare pe același server pe care rulează aplicațiile dvs. Dacă serverul se defectează, aplicațiile vor înceta să funcționeze și nu va fi nimeni care să notifice despre asta.
Sistemul de monitorizare trebuie să ruleze pe un server separat dintr-un alt centru de date.
Dacă nu doriți să utilizați un server dedicat într-un nou centru de date, puteți utiliza un sistem de monitorizare în cloud. Compania noastra foloseste sistemul de monitorizare cloud Zidium, dar puteti folosi orice alt sistem de monitorizare. Costul unui sistem de monitorizare în cloud este mai mic decât închirierea unui nou server.
Recomandări:
- Defalcați aplicațiile și sistemele sub forma unui arbore de componente cât mai detaliat posibil, astfel încât va fi convenabil să înțelegeți unde și ce este stricat, iar controlul va fi mai complet.
- Pentru a verifica funcționalitatea unei componente, utilizați teste. Este mai bine să folosiți mai multe verificări simple decât una complexă.
- Configurați praguri de metrică pe partea sistemului de monitorizare, în loc să le scrieți în cod. Acest lucru vă va scuti de a fi necesar să recompilați, să reconfigurați sau să reporniți aplicația.
- Pentru verificările personalizate, utilizați o marjă de timp de relevanță pentru a evita primirea de notificări false, deoarece unele verificări au durat puțin mai mult decât de obicei.
- Încercați să faceți componentele din sistemul de monitorizare să devină roșii numai atunci când cu siguranță există o problemă. Dacă devin roșii degeaba, atunci veți înceta să fiți atenți la notificările sistemului de monitorizare, sensul acestuia se va pierde.
Dacă nu utilizați încă un sistem de monitorizare, începeți! Nu este atât de dificil pe cât pare. Distrați-vă să vă uitați la copacul de ingrediente verzi pe care l-ați cultivat singur.
Mult noroc.
Sursa: www.habr.com