Observeu el servei i els seus usuaris
CompletadaConnecteu 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.
Publicat per TaigaCom 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
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 operativa | Exemple d’evidència | Limitació que cal recordar |
|---|---|---|
| Quantes exportacions que compleixen els criteris fallen? | Nombre de fallades i nombre de peticions que compleixen els criteris | Un 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 dades | El 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)Desmarcar aquesta opció elimina tot el progrés desat en aquest navegador.
El progrés es queda en aquest navegador. Sense compte ni seguiment.
Fonts i lectures addicionals
- OpenTelemetry: Observability primer ↗
- OpenTelemetry: Handling sensitive data ↗
- Google SRE: Alerting on SLOs ↗
- Taiga docs: Monitoring ↗