Ne-am gândit să creăm un sistem de monitorizare în etapa formării echipelor de produse. A devenit clar că afacerea noastră – exploatarea – nu se încadrează în aceste echipe. De ce este asta?
Faptul este că toate echipele noastre sunt construite în jurul sistemelor informaționale individuale, microserviciilor și fronturilor, astfel încât echipele nu văd starea generală de sănătate a întregului sistem în ansamblu. De exemplu, s-ar putea să nu știe cum o parte mică din backend-ul adânc afectează partea frontală. Domeniul lor de interes este limitat la sistemele cu care este integrat sistemul lor. Dacă o echipă și serviciul său A aproape nu au nicio legătură cu serviciul B, atunci un astfel de serviciu este aproape invizibil pentru echipă.
Echipa noastră, la rândul său, lucrează cu sisteme care sunt foarte puternic integrate între ele: există multe conexiuni între ele, aceasta este o infrastructură foarte mare. Și funcționarea magazinului online depinde de toate aceste sisteme (dintre care avem, de altfel, un număr uriaș).
Deci, se dovedește că departamentul nostru nu aparține niciunei echipe, ci este situat puțin în lateral. În toată această poveste, sarcina noastră este să înțelegem cuprinzător cum funcționează sistemele informaționale, funcționalitatea, integrările, software-ul, rețeaua, hardware-ul lor și modul în care toate acestea sunt conectate între ele.
Platforma pe care funcționează magazinele noastre online arată astfel:
- faţă
- Biroul din mijloc
- back office
Indiferent cât de mult ne-am dori, nu se întâmplă ca toate sistemele să funcționeze fără probleme și fără cusur. Ideea, din nou, este numărul de sisteme și integrări - cu ceva ca al nostru, unele incidente sunt inevitabile, în ciuda calității testării. Mai mult, atât în cadrul unui sistem separat, cât și în ceea ce privește integrarea acestora. Și trebuie să monitorizați în mod cuprinzător starea întregii platforme și nu orice parte individuală a acesteia.
În mod ideal, monitorizarea sănătății la nivel de platformă ar trebui automatizată. Și am ajuns la monitorizare ca o parte inevitabilă a acestui proces. Inițial, a fost construit doar pentru partea de primă linie, în timp ce specialiștii în rețea, administratorii de software și hardware au avut și au în continuare propriile lor sisteme de monitorizare strat cu strat. Toți acești oameni au urmat monitorizarea doar la nivelul lor; nici nimeni nu a avut o înțelegere cuprinzătoare.
De exemplu, dacă o mașină virtuală se blochează, în cele mai multe cazuri numai administratorul responsabil pentru hardware și mașina virtuală știe despre aceasta. În astfel de cazuri, echipa din prima linie a văzut însuși faptul că s-a prăbușit aplicația, dar nu a avut date despre prăbușirea mașinii virtuale. Și administratorul poate ști cine este clientul și poate avea o idee aproximativă despre ceea ce rulează în prezent pe această mașină virtuală, cu condiția să fie un fel de proiect mare. Cel mai probabil nu știe despre cei mici. În orice caz, administratorul trebuie să meargă la proprietar și să întrebe ce a fost pe această mașină, ce trebuie restaurat și ce trebuie schimbat. Și dacă ceva cu adevărat grav s-a stricat, au început să alerge în cerc - pentru că nimeni nu a văzut sistemul în întregime.
În cele din urmă, astfel de povești disparate afectează întregul front-end, utilizatorii și funcția noastră principală de afaceri - vânzările online. Deoarece nu facem parte dintr-o echipă, ci suntem angajați în operarea tuturor aplicațiilor de comerț electronic ca parte a unui magazin online, ne-am asumat sarcina de a crea un sistem cuprinzător de monitorizare pentru platforma de comerț electronic.
Structura și stiva sistemului
Am început prin a identifica mai multe straturi de monitorizare pentru sistemele noastre, în cadrul cărora ar trebui să colectăm valori. Și toate acestea trebuiau combinate, ceea ce am făcut în prima etapă. Acum, în această etapă, finalizăm colecția de valori de cea mai înaltă calitate pe toate straturile noastre pentru a construi o corelație și a înțelege modul în care sistemele se influențează reciproc.
Lipsa monitorizării cuprinzătoare în etapele inițiale de lansare a aplicației (de când am început să o construim când majoritatea sistemelor erau în producție) a condus la faptul că aveam datorii tehnice semnificative pentru a configura monitorizarea întregii platforme. Nu ne puteam permite să ne concentrăm pe configurarea monitorizării pentru un singur IS și pe monitorizarea acestuia în detaliu, deoarece restul sistemelor ar rămâne fără monitorizare pentru o perioadă de timp. Pentru a rezolva această problemă, am identificat o listă cu cele mai necesare metrici pentru evaluarea stării sistemului informațional pe nivel și am început implementarea acesteia.
Prin urmare, au decis să mănânce elefantul în părți.
Sistemul nostru este format din:
- hardware;
- sistem de operare;
- software;
- părți UI în aplicația de monitorizare;
- valori de afaceri;
- aplicații de integrare;
- securitatea informațiilor;
- rețele;
- echilibrator de trafic.
În centrul acestui sistem se află monitorizarea în sine. Pentru a înțelege în general starea întregului sistem, trebuie să știți ce se întâmplă cu aplicațiile pe toate aceste straturi și pe întregul set de aplicații.
Deci, despre stiva.
Folosim software open source. În centru avem Zabbix, pe care îl folosim în primul rând ca sistem de alertă. Toată lumea știe că este ideal pentru monitorizarea infrastructurii. Ce înseamnă acest lucru? Exact acele valori de nivel scăzut pe care le are fiecare companie care își menține propriul centru de date (și Sportmaster are propriile centre de date) - temperatura serverului, starea memoriei, raid, valorile dispozitivului de rețea.
Am integrat Zabbix cu Telegram messenger și Microsoft Teams, care sunt utilizate activ în echipe. Zabbix acoperă nivelul rețelei reale, hardware și software, dar nu este un panaceu. Îmbogățim aceste date de la alte servicii. De exemplu, la nivel hardware, ne conectăm direct prin API la sistemul nostru de virtualizare și colectăm date.
Ce altceva. Pe lângă Zabbix, folosim Prometheus, care ne permite să monitorizăm valorile într-o aplicație de mediu dinamic. Adică, putem primi valori ale aplicației printr-un punct final HTTP și să nu ne facem griji cu privire la valorile să încărcăm în el și care nu. Pe baza acestor date, pot fi dezvoltate interogări analitice.
Sursele de date pentru alte straturi, de exemplu, valorile de afaceri, sunt împărțite în trei componente.
În primul rând, acestea sunt sisteme externe de afaceri, Google Analytics, colectăm valori din jurnale. De la ei obținem date despre utilizatorii activi, conversii și orice altceva legat de afacere. În al doilea rând, acesta este un sistem de monitorizare a UI. Ar trebui descris mai detaliat.
Pe vremuri am început cu testarea manuală și s-a transformat în teste automate de funcționalitate și integrări. Din aceasta am făcut monitorizare, lăsând doar funcționalitatea principală, și ne-am bazat pe markeri cât mai stabili și nu se schimbă des în timp.
Noua structură de echipă înseamnă că toate activitățile aplicației sunt limitate la echipele de produse, așa că am încetat să mai facem teste pure. În schimb, am realizat monitorizarea UI din teste, scrise în Java, Selenium și Jenkins (folosit ca sistem de lansare și generare de rapoarte).
Am avut multe teste, dar până la urmă ne-am hotărât să mergem pe drumul principal, metrica de nivel superior. Și dacă avem o mulțime de teste specifice, va fi dificil să păstrăm datele la zi. Fiecare lansare ulterioară va distruge semnificativ întregul sistem și tot ce vom face este să-l reparăm. Prin urmare, ne-am concentrat pe lucruri foarte fundamentale care se schimbă rar și le monitorizăm doar.
În cele din urmă, în al treilea rând, sursa de date este un sistem de înregistrare centralizat. Folosim Elastic Stack pentru jurnale și apoi putem extrage aceste date în sistemul nostru de monitorizare pentru valorile de afaceri. Pe lângă toate acestea, avem propriul nostru serviciu API de monitorizare, scris în Python, care interogează orice servicii prin API și colectează date de la acestea în Zabbix.
Un alt atribut indispensabil al monitorizării este vizualizarea. Al nostru se bazează pe Grafana. Se remarcă printre alte sisteme de vizualizare prin faptul că vă permite să vizualizați valorile din diferite surse de date pe tabloul de bord. Putem colecta valori de nivel superior pentru un magazin online, de exemplu, numărul de comenzi plasate în ultima oră din DBMS, valori de performanță pentru sistemul de operare pe care rulează acest magazin online de la Zabbix și valori pentru instanțe ale acestei aplicații de la Prometeu. Și toate acestea vor fi pe un singur tablou de bord. Clar și accesibil.
Permiteți-mi să notez despre securitate - în prezent finalizăm sistemul, pe care ulterior îl vom integra cu sistemul global de monitorizare. În opinia mea, principalele probleme cu care se confruntă comerțul electronic în domeniul securității informațiilor sunt legate de boți, parseri și forță brută. Trebuie să fim atenți la acest lucru, deoarece toate acestea pot afecta în mod critic atât funcționarea aplicațiilor noastre, cât și reputația noastră din punct de vedere al afacerii. Și cu stiva aleasă acoperim cu succes aceste sarcini.
Un alt punct important este că stratul de aplicare este asamblat de Prometheus. El însuși este, de asemenea, integrat cu Zabbix. Și mai avem sitespeed, un serviciu care ne permite să vedem parametri precum viteza de încărcare a paginii noastre, blocajele, randarea paginii, încărcarea scripturilor etc., este și API integrat. Deci, valorile noastre sunt colectate în Zabbix și, în consecință, alertăm și de acolo. Toate alertele sunt trimise în prezent către principalele metode de trimitere (deocamdată este e-mail și telegramă, MS Teams a fost și el recent conectat). Există planuri de actualizare a alertelor la o astfel de stare încât roboții inteligenți să funcționeze ca un serviciu și să ofere informații de monitorizare tuturor echipelor de produse interesate.
Pentru noi, metricile sunt importante nu numai pentru sistemele informaționale individuale, ci și metricile generale pentru întreaga infrastructură pe care o folosesc aplicațiile: clustere de servere fizice pe care rulează mașinile virtuale, balansoare de trafic, Network Load Balancer, rețeaua însăși, utilizarea canalelor de comunicație. . Plus metrics pentru propriile noastre centre de date (avem mai multe dintre ele și infrastructura este destul de mare).
Avantajele sistemului nostru de monitorizare sunt că, cu ajutorul acestuia, vedem starea de sănătate a tuturor sistemelor și putem evalua impactul acestora unul asupra celuilalt și asupra resurselor partajate. Și în cele din urmă, ne permite să ne angajăm în planificarea resurselor, care este și responsabilitatea noastră. Gestionăm resursele serverului - un grup în cadrul comerțului electronic, punem în funcțiune și scoatem din funcțiune echipamente noi, achiziționăm echipamente noi suplimentare, efectuăm un audit al utilizării resurselor etc. În fiecare an, echipele planifică noi proiecte, își dezvoltă sistemele și este important pentru noi să le oferim resurse.
Și cu ajutorul unor metrici, vedem tendința în consumul de resurse de către sistemele noastre informaționale. Și pe baza lor putem planifica ceva. La nivel de virtualizare, colectăm date și vedem informații despre cantitatea disponibilă de resurse în funcție de centru de date. Și deja în interiorul centrului de date puteți vedea reciclarea, distribuția efectivă și consumul de resurse. Mai mult, atât cu servere autonome, cât și cu mașini virtuale și clustere de servere fizice pe care toate aceste mașini virtuale se rotesc puternic.
Perspective
Acum avem nucleul sistemului în ansamblu pregătit, dar încă mai sunt multe lucruri la care mai trebuie lucrat. Cel puțin, acesta este un nivel de securitate a informațiilor, dar este, de asemenea, important să ajungeți în rețea, să dezvoltați alerte și să rezolvați problema corelației. Avem multe straturi și sisteme, iar pe fiecare strat există mult mai multe metrici. Se dovedește a fi o matrioșcă la gradul de matrioșcă.
Sarcina noastră este să facem în cele din urmă alertele potrivite. De exemplu, dacă a existat o problemă cu hardware-ul, din nou, cu o mașină virtuală, și a existat o aplicație importantă, iar serviciul nu a fost făcut în niciun fel de backup. Aflăm că mașina virtuală a murit. Apoi, valorile de afaceri vă vor alerta: utilizatorii au dispărut undeva, nu există nicio conversie, interfața de utilizare din interfață nu este disponibilă, software-ul și serviciile au murit și ele.
În această situație, vom primi spam de la alerte, iar acesta nu se mai încadrează în formatul unui sistem de monitorizare adecvat. Se pune problema corelației. Prin urmare, în mod ideal, sistemul nostru de monitorizare ar trebui să spună: „Băieți, mașina voastră fizică a murit și, odată cu ea, această aplicație și aceste valori”, cu ajutorul unei alerte, în loc să ne bombardeze cu furie cu o sută de alerte. Ar trebui să raporteze principalul lucru - cauza, care ajută la eliminarea rapidă a problemei datorită localizării sale.
Sistemul nostru de notificare și procesarea alertelor este construit în jurul unui serviciu de linie fierbinte de XNUMX de ore pe zi. Toate alertele care sunt considerate obligatorii și care sunt incluse în lista de verificare sunt trimise acolo. Fiecare alertă trebuie să aibă o descriere: ce s-a întâmplat, ce înseamnă de fapt, ce afectează. Și, de asemenea, un link către tabloul de bord și instrucțiuni despre ceea ce trebuie făcut în acest caz.
Acesta este totul despre cerințele pentru crearea unei alerte. Atunci situația se poate dezvolta în două direcții - fie există o problemă și trebuie rezolvată, fie a existat o defecțiune a sistemului de monitorizare. Dar, în orice caz, trebuie să te duci și să-ți dai seama.
În medie, primim acum aproximativ o sută de alerte pe zi, ținând cont de faptul că corelarea alertelor nu a fost încă configurată corespunzător. Și dacă trebuie să efectuăm lucrări tehnice și oprim ceva cu forța, numărul lor crește semnificativ.
Pe lângă monitorizarea sistemelor pe care le operam și colectarea de valori care sunt considerate importante din partea noastră, sistemul de monitorizare ne permite să colectăm date pentru echipele de produse. Ele pot influența compoziția metricilor în cadrul sistemelor informaționale pe care le monitorizăm.
Colegul nostru poate veni și cere să adauge o măsurătoare care ne va fi utilă atât pentru noi, cât și pentru echipă. Sau, de exemplu, este posibil ca echipa să nu aibă suficiente valorile de bază pe care le avem; trebuie să urmărească unele specifice. În Grafana, creăm un spațiu pentru fiecare echipă și acordăm drepturi de administrator. De asemenea, dacă o echipă are nevoie de tablouri de bord, dar ei înșiși nu pot/nu știu cum să o facă, o ajutăm.
Deoarece ne aflăm în afara fluxului de creare de valoare a echipei, lansările și planificarea acestora, ajungem treptat la concluzia că versiunile tuturor sistemelor sunt fără probleme și pot fi lansate zilnic fără coordonare cu noi. Și este important pentru noi să monitorizăm aceste versiuni, deoarece ar putea afecta funcționarea aplicației și ar putea întrerupe ceva, iar acest lucru este critic. Pentru a gestiona versiunile, folosim Bamboo, de unde primim date prin API și putem vedea ce versiuni au fost lansate în ce sisteme de informații și starea acestora. Și cel mai important lucru este la ce oră. Suprapunem markeri de eliberare pe principalele valori critice, ceea ce este foarte indicativ din punct de vedere vizual în cazul unor probleme.
În acest fel putem vedea corelația dintre noile versiuni și problemele emergente. Ideea principală este să înțelegeți cum funcționează sistemul la toate straturile, să localizați rapid problema și să o remediați la fel de repede. La urma urmei, se întâmplă adesea ca ceea ce necesită cel mai mult timp să nu fie rezolvarea problemei, ci căutarea cauzei.
Și în acest domeniu ne dorim pe viitor să ne concentrăm pe proactivitate. În mod ideal, aș dori să știu despre o problemă care se apropie din timp, și nu după fapt, pentru a o preveni mai degrabă decât a o rezolva. Uneori apar alarme false ale sistemului de monitorizare, atât din cauza unei erori umane, cât și din cauza modificărilor din aplicație. Și lucrăm la asta, o depanăm și încercăm să avertizăm utilizatorii care îl folosesc cu noi despre acest lucru înainte de orice manipulare a sistemului de monitorizare. , sau efectuați aceste activități în fereastra tehnică.
Deci, sistemul a fost lansat și funcționează cu succes de la începutul primăverii... și înregistrează profituri foarte reale. Desigur, aceasta nu este versiunea sa finală; vom introduce multe alte funcții utile. Dar acum, cu atât de multe integrări și aplicații, automatizarea monitorizării este cu adevărat inevitabil.
Dacă monitorizezi și proiecte mari cu un număr semnificativ de integrări, scrie în comentarii ce glonț de argint ai găsit pentru asta.
Sursa: www.habr.com