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.