--- title: "Monitorizare și Observabilitate" description: "Prometheus, Grafana și stivă ELK configurate corect: alerte care înseamnă ceva, obiective SLO realiste și diagnostic rapid al incidentelor." url: "https://nixit.ro/servicii/monitorizare-observabilitate/" lang: "ro-RO" --- # Monitorizare și Observabilitate Construim monitorizare care detectează problemele înainte de clienți și alerte pe care echipa nu le ignoră. Cea mai proastă modalitate de a afla că un serviciu nu funcționează este apelul unui client. A doua cea mai proastă este o alertă care ajunge într-un canal unde se adună zilnic două sute de mesaje și pe care nu îl mai citește nimeni. Monitorizarea nu este o problemă de instrumente, pentru că instrumentele bune sunt gratuite și mature. Este o problemă de a decide ce contează cu adevărat și de a alerta doar pe acele lucruri. ## Ce monitorizăm și de ce Construim pe trei niveluri. Infrastructura acoperă utilizarea resurselor, spațiul pe disc, starea hardware și disponibilitatea rețelei. Aplicațiile aduc rata de erori, distribuția timpilor de răspuns, lungimea cozilor și starea dependențelor externe. Al treilea nivel, cel mai util și cel mai des omis, urmărește indicatori de business: comenzi plasate pe minut, autentificări reușite, plăți procesate. O scădere bruscă a comenzilor detectează o problemă reală mai repede decât orice metrică tehnică, pentru că măsoară efectul, nu cauza. Pentru timpii de răspuns folosim percentile, nu medii. Media ascunde exact utilizatorii afectați: dacă nouăzeci la sută dintre cereri se rezolvă în cincizeci de milisecunde și cinci la sută în opt secunde, media rămâne acceptabilă, iar experiența reală a unei părți din utilizatori este proastă. ## Alerte care înseamnă ceva O alertă trebuie să însemne că un om trebuie să intervină acum. Orice altceva aparține unui panou de urmărire sau unui raport. Alertăm pe simptome vizibile pentru utilizator, nu pe cauze posibile: creșterea ratei de erori HTTP contează, o utilizare de procesor de nouăzeci la sută pe un serviciu care răspunde normal nu. Fiecare alertă are atașată o procedură care explică ce înseamnă, cum se verifică rapid dacă este reală și care sunt primii pași de intervenție. Alertele fără procedură se transformă, în cele din urmă, în alerte ignorate. Pragurile se calibrează pe comportamentul real al sistemului, iar setul se revizuiește periodic: alertele care nu s-au declanșat niciodată sau care se declanșează fals în mod repetat sunt eliminate sau corectate. ## Jurnale și diagnostic Metricile arată că există o problemă, jurnalele explică de ce. Colectarea centralizată cu Loki sau Elasticsearch face diferența dintre a găsi cauza în cinci minute și a te conecta pe rând la douăsprezece servere. Stabilim politici de retenție diferențiate, pentru că păstrarea integrală a tuturor jurnalelor un an devine scumpă rapid, iar cerințele NIS2 privind jurnalizarea se pot îndeplini cu o retenție bine gândită, nu cu una maximală. Pentru sistemele distribuite adăugăm trasabilitatea cererilor prin OpenTelemetry, astfel încât o cerere lentă să poată fi urmărită prin toate serviciile pe care le traversează. Fără această componentă, diagnosticarea într-o arhitectură cu multe servicii se bazează în mare parte pe intuiție. ## Obiective de nivel de serviciu Definim SLO împreună cu partea de business, pornind de la ce este cu adevărat tolerabil pentru utilizatori. O disponibilitate de 99,9% înseamnă aproximativ patruzeci și trei de minute de indisponibilitate pe lună, iar 99,99% înseamnă mai puțin de cinci. Diferența de cost între cele două este considerabilă, iar decizia trebuie luată în cunoștință de cauză, nu prin adăugarea unei cifre într-un contract. Odată stabilit obiectivul, bugetul de eroare devine un instrument util de decizie. Când este consumat, prioritatea trece de la funcționalități noi la stabilitate. Este o discuție mult mai productivă decât cea despre cine este vinovat pentru ultimul incident. ## Pentru cine este potrivit Serviciul se potrivește companiilor care depind de disponibilitatea sistemelor pentru veniturile zilnice, echipelor care au deja monitorizare, dar nu au încredere în ea, și organizațiilor care trebuie să demonstreze capacitate de detectare a incidentelor pentru cerințele de conformitate. Rezultatul practic este că problemele sunt observate de echipă înainte de clienți, iar durata medie a incidentelor scade pentru că diagnosticul nu mai începe de la zero. ## Ce primești - Stivă de monitorizare instalată și configurată, cu metrici de sistem, aplicație și business - Panouri Grafana adaptate pe roluri: echipă tehnică, conducere, stare publică - Set de alerte pe simptome, cu praguri calibrate și procedură atașată fiecărei alerte - Colectare centralizată a jurnalelor, cu retenție stabilită și căutare rapidă - Obiective SLO definite împreună cu business-ul, cu raportare lunară a realizării ## Tehnologii Prometheus, Grafana, Loki, Elasticsearch, Zabbix, Alertmanager, OpenTelemetry, Grafana Tempo ## Întrebări frecvente ### Avem deja monitorizare, dar nimeni nu se mai uită la alerte. Ce se poate face? Este simptomul clasic al alertelor prea numeroase și prea puțin relevante. Refacem setul de la zero, pornind de la simptomele resimțite de utilizatori, nu de la fiecare metrică disponibilă. O alertă trebuie să însemne că cineva chiar trebuie să intervină acum; restul devin panouri de urmărire. ### Ce se monitorizează într-o infrastructură obișnuită? Pe trei niveluri: infrastructura, adică procesor, memorie, disc, rețea și starea echipamentelor; aplicațiile, adică rata de erori, timpii de răspuns și cozile de procesare; și indicatorii de business, precum comenzi finalizate sau autentificări reușite pe minut. Ultimul nivel detectează cel mai rapid problemele reale. ### Cât timp durează implementarea? O stivă funcțională, cu metrici de bază și alerte esențiale, se pune în două-trei săptămâni. Partea care cere timp este calibrarea: eliminarea alertelor false, ajustarea pragurilor pe comportamentul real al sistemului și scrierea procedurilor. Aceasta continuă în primele două-trei luni. ### Preferați soluții open source sau comerciale? Depinde de volum și de echipă. Prometheus, Grafana și Loki acoperă foarte bine majoritatea cazurilor și evită costurile de licențiere care cresc odată cu traficul. Pentru volume foarte mari de jurnale sau cerințe specifice de conformitate, o soluție comercială poate fi justificată. Prezentăm costul total pentru ambele variante.