Itinerari 05Lliçó 4 / 8

Observeu el servei i els seus usuaris

Connecteu mètriques, registres d'activitat i traces amb els objectius del servei. Dissenyeu alertes, límits per a les dades i comprovacions per detectar telemetria absent.

Pràctic11 minRevisat

Publicat per Com escrivim

Comproveu què heu entèsLa latència de les exportacions augmenta. Les traces mostrejades mostren spans de base de dades lents. Què podeu concloure?Feu l'exercici
La latència de les exportacions augmenta. Les traces mostrejades mostren spans de base de dades lents. Què podeu concloure?

Què aprendreu

  • Trieu telemetria que respongui una pregunta operativa concreta.
  • Distingiu un símptoma del servei d'una causa interna.
  • Protegiu la telemetria i detecteu evidències absents o obsoletes.

Comenceu per la pregunta

El monitoratge comprova condicions conegudes. L’observabilitat us ajuda a investigar el comportament del sistema, incloses les fallades que no havíeu previst. Tenir més quadres de comandament no proporciona automàticament respostes millors.

Per a un servei d’exportació fictici, comenceu amb una pregunta d’usuari: pot un usuari autoritzat rebre l’exportació correcta dins del temps acordat? Després, trieu senyals que permetin respondre aquesta pregunta i ajudin a explicar les fallades.

OpenTelemetry proporciona instrumentació i estàndards per a la telemetria. Pot enviar senyals a backends compatibles. Encara necessiteu emmagatzematge, consultes, controls d’accés, retenció i persones que actuïn segons les evidències. Introducció a l’observabilitat.

Connecteu diferents formes d’evidència

Una mètrica mesura una quantitat al llarg del temps. Un registre d’activitat recull un esdeveniment. Una traça connecta operacions relacionades mentre una petició travessa un sistema. Un span representa una operació dins d’una traça.

Pregunta operativaExemple d’evidènciaLimitació que cal recordar
Quantes exportacions que compleixen els criteris fallen?Nombre de fallades i nombre de peticions que compleixen els criterisUn denominador incorrecte dona una taxa enganyosa
Què ha passat amb una exportació?Registre estructurat amb l’identificador de la tasca, el resultat i la versióEls esdeveniments absents deixen buits
En què s’ha consumit el temps?Traça que recorre l’API, la cua, el procés de treball i la base de dadesEl mostreig i una propagació de context interrompuda poden amagar feina
Què ha canviat abans del símptoma?Registres de desplegament i configuracióLa coincidència temporal no demostra una causa

Per al treball asíncron, manteniu una correlació segura entre la tasca enviada i l’execució del procés de treball. Una resposta HTTP 202 pot significar que la feina s’ha acceptat. No demostra que l’exportació hagi acabat.

Alerteu quan calgui actuar

Definiu el SLI i el seu denominador abans d’establir el SLO. En aquest exemple, compteu les exportacions que compleixen els criteris i acaben correctament dins de la durada acordada. Definiu com entren en el mesurament les tasques de llarga durada i les abandonades.

Un pressupost d’error descriu les fallades permeses dins de la finestra del SLO. La taxa de consum indica amb quina rapidesa les fallades consumeixen aquest pressupost. Les directrius de Google fan servir diverses finestres per equilibrar la detecció oportuna i el soroll de les alertes. Alertes basades en SLO.

Aviseu la persona de guàrdia quan la condició requereixi una acció oportuna. Envieu la feina menys urgent a una cua. Cada alerta necessita un responsable, una descripció de l’impacte, un enllaç per investigar i una instrucció de resposta. Reviseu les alertes que repetidament no porten a cap acció.

No feu servir un únic llindar genèric per a tots els serveis. L’impacte sobre els usuaris, el trànsit, l’horari de servei i la capacitat de resposta afecten la decisió.

Protegiu el pipeline de telemetria

La telemetria pot contenir dades personals, tokens, paràmetres de peticions i documents confidencials. Definiu els camps permesos abans de recollir-los. Limiteu l’accés i la retenció. Retireu els secrets abans d’exportar dades a un backend extern. Telemetria sensible.

No feu servir el correu electrònic d’un client ni un identificador únic de tasca com a etiqueta d’una mètrica. Les etiquetes sense límits augmenten el nombre de sèries temporals i poden exposar identificadors. Feu servir dimensions controlades per a les mètriques. Poseu els identificadors de correlació aprovats en registres o traces amb control d’accés.

Mesureu el pipeline mateix. Comproveu les fallades d’ingestió, les dades descartades i l’antiguitat de la darrera observació. Un gràfic d’errors pla pot significar que no hi ha errors o que no arriba telemetria. Mostreu aquesta distinció.

Investigueu una fallada concreta

El servei fictici retorna HTTP 202 per a cada petició. El temps d’espera de les tasques a la cua passa de segons a 15 minuts. Els registres dels processos de treball mostren temps d’espera de base de dades exhaurits de manera repetida. Les traces mostrejades situen la major part del temps dels processos de treball en crides a la base de dades.

Aquestes evidències permeten centrar la investigació. No demostren si la causa és un canvi en una consulta, l’esgotament de les connexions o la capacitat de la base de dades. Compareu aquestes hipòtesis amb el mètode de depuració.

Monitoring de Taiga ofereix una visió de l’estat del producte amb senyals de disponibilitat i d’experiència al navegador. Complementa l’observabilitat de la infraestructura i de l’aplicació; no substitueix aquests sistemes. Monitoring.

Feu l'exercici

Per a l'exportació fictícia d'aquesta lliçó, definiu un SLI, una alerta que requereixi una acció, tres camps de telemetria permesos i dos camps prohibits. Indiqueu com detectaríeu una fallada del pipeline de telemetria.

Descarrega la fitxa (Markdown)
Comproveu què heu entès ↑

Continua aprenent

Fonts i lectures addicionals

Lectures relacionades de Taiga

Lliçó anterior: Continueu detectant i corregint vulnerabilitats