Numele meu este Anton Baderin. Lucrez la Centrul de Înaltă Tehnologie și fac administrare de sistem. În urmă cu o lună, s-a încheiat conferința noastră corporativă, unde am împărtășit experiența acumulată comunității IT din orașul nostru. Am vorbit despre monitorizarea aplicațiilor web. Materialul a fost destinat nivelului junior sau mediu, care nu a construit acest proces de la zero.
Piatra de temelie care stă la baza oricărui sistem de monitorizare este rezolvarea problemelor de afaceri. Monitorizarea de dragul monitorizării nu interesează pe nimeni. Ce vrea afacerile? Pentru ca totul să funcționeze rapid și fără erori. Companiile vor să fie proactive, astfel încât noi înșine să identificăm problemele din serviciu și să le reparăm cât mai repede posibil. Acestea sunt, de fapt, problemele pe care le-am rezolvat tot anul trecut la un proiect pentru unul dintre clienții noștri.
Despre proiect
Proiectul este unul dintre cele mai mari programe de loialitate din țară. Ajutăm lanțurile de retail să crească frecvența vânzărilor prin diverse instrumente de marketing, cum ar fi carduri bonus. În total, proiectul include 14 aplicații care rulează pe zece servere.
În timpul procesului de interviu, am observat în mod repetat că administratorii nu abordează întotdeauna corect aplicațiile web de monitorizare: mulți încă se concentrează pe valorile sistemului de operare și ocazional monitorizează serviciile.
În cazul meu, sistemul de monitorizare al clientului se baza anterior pe Icinga. Nu a rezolvat în niciun fel problemele de mai sus. Adesea, clientul însuși ne-a informat despre probleme și, de cele mai multe ori, pur și simplu nu aveam suficiente date pentru a ajunge la fundul motivului.
În plus, a existat o înțelegere clară a inutilității dezvoltării sale ulterioare. Cred că cei care sunt familiarizați cu Icinga mă vor înțelege. Așadar, am decis să reproiectăm complet sistemul de monitorizare a aplicației web pentru proiect.
Prometeu
Am ales Prometheus pe baza a trei indicatori principali:
- Un număr mare de valori disponibile. În cazul nostru sunt 60 de mii dintre ele. Desigur, este de remarcat faptul că nu folosim marea majoritate a acestora (probabil aproximativ 95%). Pe de altă parte, toate sunt relativ ieftine. Pentru noi, aceasta este cealaltă extremă în comparație cu Icinga folosită anterior. În ea, adăugarea de valori a fost o problemă deosebită: cele existente erau scumpe (doar uitați-vă la codul sursă al oricărui plugin). Orice plugin era un script în Bash sau Python, a cărui lansare este costisitoare în ceea ce privește resursele consumate.
- Acest sistem consumă o cantitate relativ mică de resurse. 600 MB de RAM, 15% dintr-un nucleu și câteva zeci de IOPS sunt suficiente pentru toate valorile noastre. Desigur, trebuie să rulați exportatori de metrici, dar toate sunt scrise în Go și, de asemenea, nu sunt foarte înfometate de putere. Nu cred că în realitățile moderne aceasta este o problemă.
- Oferă posibilitatea de a migra la Kubernetes. Având în vedere planurile clientului, alegerea este evidentă.
ELAN
Anterior, nu colectam sau procesam jurnalele. Neajunsurile sunt clare pentru toată lumea. Am ales ELK pentru că aveam deja experiență cu acest sistem. Acolo stocăm doar jurnalele aplicațiilor. Principalele criterii de selecție au fost căutarea full-text și viteza acesteia.
Сlickhouse
Inițial, alegerea a căzut pe InfluxDB. Ne-am dat seama că trebuie să colectăm jurnalele Nginx, statistici din pg_stat_statements și să stocăm datele istorice Prometheus. Nu ne-a plăcut Influx pentru că periodic a început să consume o cantitate mare de memorie și s-a prăbușit. În plus, am vrut să grupez interogările după remote_addr, dar gruparea în acest DBMS se face doar prin etichete. Etichetele sunt scumpe (memoria), numărul lor este limitat condiționat.
Am început din nou căutarea. Ceea ce era nevoie era o bază de date analitică cu un consum minim de resurse, de preferință cu compresie de date pe disc.
Clickhouse îndeplinește toate aceste criterii și nu am regretat niciodată alegerea făcută. Nu scriem cantități extraordinare de date în el (numărul de inserții este de doar aproximativ cinci mii pe minut).
NewRelic
NewRelic a fost cu noi din punct de vedere istoric pentru că a fost alegerea clientului. Îl folosim ca APM.
Zabbix
Folosim Zabbix exclusiv pentru a monitoriza Cutia Neagră a diferitelor API-uri.
Definirea unei abordări de monitorizare
Am vrut să descompunem sarcina și, prin urmare, să sistematizăm abordarea monitorizării.
Pentru a face acest lucru, am împărțit sistemul nostru în următoarele niveluri:
- hardware și VMS;
- sistem de operare;
- servicii de sistem, stivă de software;
- aplicare;
- lociga afacerii.
De ce este convenabilă această abordare:
- știm cine este responsabil de munca fiecărui nivel și, pe baza acestuia, putem trimite alerte;
- putem folosi structura atunci când suprimăm alertele - ar fi ciudat să trimitem o alertă despre indisponibilitatea bazei de date atunci când mașina virtuală în ansamblu nu este disponibilă.
Deoarece sarcina noastră este să identificăm încălcările în funcționarea sistemului, trebuie să evidențiem la fiecare nivel un anumit set de metrici cărora merită să fim atenți atunci când scriem reguli de alertă. În continuare, să trecem prin nivelurile „VMS”, „Sistem de operare” și „Servicii de sistem, stivă de software”.
Mașini virtuale
Gazduirea ne aloca un procesor, un disc, o memorie si o retea. Și am avut probleme cu primele două. Deci, metrica:
Timp furat CPU - atunci când cumpărați o mașină virtuală de pe Amazon (t2.micro, de exemplu), ar trebui să înțelegeți că nu vi se alocă un întreg nucleu de procesor, ci doar o cotă din timpul său. Și când îl epuizați, procesorul vă va fi luat.
Această măsurătoare vă permite să urmăriți astfel de momente și să luați decizii. De exemplu, este necesar să luați un tarif mai mare sau să distribuiți procesarea sarcinilor de fundal și a solicitărilor API către diferite servere?
IOPS + CPU iowait time - din anumite motive, multe găzduiri cloud păcătuiesc prin faptul că nu oferă suficiente IOPS. Mai mult, un program cu IOPS scăzut nu este un argument pentru ei. Prin urmare, merită să colectați CPU iowait. Cu această pereche de grafice - cu IOPS scăzut și așteptare mare I/O - puteți deja să vorbiți cu găzduirea și să rezolvați problema.
Sistem de operare
Valorile sistemului de operare:
- cantitatea de memorie disponibilă în %;
- activitate de utilizare a schimbului: vmstat swapin, swapout;
- numărul de inoduri disponibile și spațiul liber pe sistemul de fișiere în %
- sarcina medie;
- numărul de conexiuni în stare tw;
- plinătatea tabelului conttrack;
- Calitatea rețelei poate fi monitorizată folosind utilitarul ss, pachetul iproute2 - obțineți un indicator al conexiunilor RTT de la ieșirea acesteia și grupați-l după portul de destinație.
Tot la nivel de sistem de operare avem o astfel de entitate ca procesele. Este important să identificăm în sistem un set de procese care joacă un rol important în funcționarea acestuia. Dacă, de exemplu, aveți mai multe pgpools, atunci trebuie să colectați informații pentru fiecare dintre ele.
Setul de valori este următorul:
- CPU-uri;
- memoria este în principal rezidentă;
- IO - de preferință în IOPS;
- FileFd - deschidere și limită;
- erori semnificative ale paginii - în acest fel puteți înțelege ce proces este schimbat.
Implementăm toată monitorizarea în Docker și folosim Advisor pentru a colecta date despre valori. Pe alte mașini folosim proces-exportator.
Servicii de sistem, stivă de software
Fiecare aplicație are propriile sale specificități și este dificil să evidențiezi un set specific de valori.
Setul universal este:
- rata de solicitare;
- numărul de greșeli;
- latență;
- saturare.
Cele mai izbitoare exemple ale noastre de monitorizare la acest nivel sunt Nginx și PostgreSQL.
Cel mai încărcat serviciu din sistemul nostru este baza de date. În trecut, am avut adesea probleme în a ne da seama ce face baza de date.
Am văzut o sarcină mare pe discuri, dar jurnalele lente nu au arătat nimic. Am rezolvat această problemă folosind pg_stat_statements, o vizualizare care colectează statistici de interogare.
Asta e tot ce are nevoie administratorul.
Construim grafice ale activității de solicitări de citire și scriere:
Totul este simplu și clar, fiecare cerere are culoarea ei.
Un exemplu la fel de izbitor sunt jurnalele Nginx. Nu este de mirare că puțini oameni le analizează sau le menționează în lista de must-have. Formatul standard nu este foarte informativ și trebuie extins.
Personal, am adăugat request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Reprezentăm timpul de răspuns și numărul de erori:
Construim grafice ale timpului de răspuns și ale numărului de erori. Tine minte? Am vorbit despre obiectivele de afaceri? Pentru a rapid și fără erori? Am acoperit deja aceste probleme cu două diagrame. Și deja puteți apela administratorii de serviciu folosindu-le.
Mai rămâne însă o problemă - să se asigure eliminarea rapidă a cauzelor incidentului.
Rezolvarea incidentelor
Întregul proces de la identificarea până la rezolvarea unei probleme poate fi împărțit în mai mulți pași:
- identificarea problemei;
- notificarea administratorului de serviciu;
- răspuns la un incident;
- eliminarea cauzelor.
Este important să facem acest lucru cât mai repede posibil. Și dacă în etapele de identificare a unei probleme și de trimitere a unei notificări nu putem câștiga mult timp - în orice caz se vor cheltui două minute pentru ele, atunci cele ulterioare sunt pur și simplu câmp nearat pentru îmbunătățiri.
Să ne imaginăm că a sunat telefonul ofițerului de serviciu. Ce va face? Căutați răspunsuri la întrebări - ce s-a rupt, unde s-a rupt, cum să reacționați? Iată cum răspundem la aceste întrebări:
Pur și simplu includem toate aceste informații în textul notificării, îi dăm un link către o pagină wiki care descrie cum să răspundem la această problemă, cum să o rezolvăm și să o escaladăm.
Încă nu am spus nimic despre nivelul aplicației și logica de afaceri. Din păcate, aplicațiile noastre nu implementează încă colectarea de valori. Singura sursă de informații de la aceste niveluri sunt jurnalele.
Câteva puncte.
Mai întâi, scrieți jurnalele structurate. Nu este nevoie să includeți context în textul mesajului. Acest lucru le face dificil de grupat și analizat. Logstash durează mult timp pentru a normaliza toate acestea.
În al doilea rând, utilizați corect nivelurile de severitate. Fiecare limbă are propriul său standard. Personal, disting patru niveluri:
- nicio eroare;
- eroare din partea clientului;
- greșeala este de partea noastră, nu pierdem bani, nu asumăm riscuri;
- Greșeala este de partea noastră, pierdem bani.
Lasă-mă să rezum. Trebuie să încercați să construiți monitorizarea bazată pe logica de afaceri. Încercați să monitorizați aplicația în sine și să operați cu valori precum numărul de vânzări, numărul de noi înregistrări de utilizatori, numărul de utilizatori activi în prezent și așa mai departe.
Dacă întreaga afacere este un buton în browser, trebuie să monitorizați dacă face clic și funcționează corect. Tot restul nu contează.
Dacă nu aveți acest lucru, puteți încerca să îl atingeți în jurnalele de aplicații, jurnalele Nginx și așa mai departe, așa cum am făcut noi. Ar trebui să fii cât mai aproape de aplicație.
Valorile sistemului de operare sunt desigur importante, dar afacerile nu sunt interesate de ele, nu suntem plătiți pentru ele.
Sursa: www.habr.com