Observați serviciul și utilizatorii săi

Începeți cu întrebarea

Monitorizarea verifică situații cunoscute. Observabilitatea vă ajută să investigați comportamentul sistemului, inclusiv defecțiuni pe care nu le-ați anticipat. Mai multe panouri de bord nu oferă automat răspunsuri mai bune.

Pentru un serviciu fictiv de export, începeți cu o întrebare a utilizatorului: poate un utilizator autorizat să primească exportul corect în timpul convenit? Apoi alegeți semnale care susțin întrebarea și ajută la explicarea defecțiunilor.

OpenTelemetry oferă instrumentare și standarde pentru telemetrie. Poate trimite semnale către backenduri compatibile. Aveți în continuare nevoie de stocare, interogări, controale de acces, păstrare și oameni care acționează pe baza dovezilor. Introducere în observabilitate.

Conectați forme diferite de dovezi

O metrică măsoară o cantitate în timp. Un log consemnează un eveniment. Un traseu conectează operațiuni înrudite pe măsură ce o cerere trece prin sistem. Un span reprezintă o operațiune dintr-un traseu.

Pentru lucrul asincron, păstrați o corelare sigură între jobul trimis și execuția workerului. Un răspuns HTTP 202 poate însemna că lucrul a fost acceptat. Nu dovedește că exportul s-a terminat.

Alertați când este necesară o acțiune

Definiți SLI-ul și numitorul său înainte de a stabili SLO-ul. În exemplu, numărați exporturile eligibile terminate corect în durata convenită. Definiți cum intră în măsurare joburile de lungă durată și cele abandonate.

Un buget de erori descrie eșecurile permise în intervalul SLO. Rata de consum descrie cât de repede consumă eșecurile acel buget. Ghidul Google folosește mai multe intervale pentru a echilibra detectarea promptă și zgomotul alertelor. Alertare pe baza SLO-urilor.

Notificați direct persoana de gardă când situația necesită acțiune promptă. Trimiteți lucrul mai puțin urgent într-o coadă. Fiecare alertă necesită un responsabil, descrierea impactului, o legătură pentru investigație și o instrucțiune de răspuns. Reevaluați alertele care repetat nu duc la nicio acțiune.

Nu folosiți un singur prag generic pentru toate serviciile. Impactul asupra utilizatorilor, traficul, programul de lucru și capacitatea de răspuns afectează decizia.

Protejați pipeline-ul de telemetrie

Telemetria poate conține date personale, tokenuri, parametri ai cererilor și documente confidențiale. Definiți câmpurile permise înainte de colectare. Restricționați accesul și păstrarea. Eliminați secretele înainte de exportul către un backend extern. Telemetrie sensibilă.

Nu folosiți adresa de e-mail a unui client sau un ID unic de job ca etichetă de metrică. Etichetele fără limite cresc numărul seriilor temporale și pot expune identificatori. Folosiți dimensiuni controlate pentru metrici. Puneți identificatorii aprobați de corelare în loguri sau trasee cu acces controlat.

Măsurați pipeline-ul însuși. Verificați eșecurile preluării datelor, datele pierdute și vechimea celei mai recente observații. Un grafic plat al erorilor poate însemna lipsa erorilor sau lipsa telemetriei primite. Arătați diferența.

Investigați o defecțiune concretă

Serviciul fictiv raportează HTTP 202 pentru fiecare cerere. Timpul de așteptare al joburilor din coadă crește de la secunde la 15 minute. Logurile workerilor arată depășiri repetate ale timpului de așteptare pentru baza de date. Traseele eșantionate plasează cea mai mare parte a timpului workerilor în apeluri către baza de date.

Dovezile susțin o investigație concentrată. Nu stabilesc dacă sursa este o modificare a interogării, epuizarea conexiunilor sau capacitatea bazei de date. Comparați ipotezele cu metoda de depanare.

Taiga Monitoring oferă o vedere a stării produsului cu semnale de disponibilitate și experiență în browser. Completează observabilitatea infrastructurii și a aplicației; nu înlocuiește aceste sisteme. Monitoring.