Observa el servicio y a sus usuarios

Empieza por la pregunta

La monitorización comprueba condiciones conocidas. La observabilidad ayuda a investigar el comportamiento del sistema, incluidos fallos no previstos. Más paneles no aportan automáticamente mejores respuestas.

Para un servicio ficticio de exportación, empieza por una pregunta del usuario: ¿puede un usuario autorizado recibir la exportación correcta dentro del tiempo acordado? Elige después señales que respalden esa pregunta y ayuden a explicar los fallos.

OpenTelemetry aporta instrumentación y estándares de telemetría. Puede enviar señales a backends compatibles. Sigues necesitando almacenamiento, consultas, controles de acceso, conservación y personas que actúen a partir de las pruebas. Introducción a la observabilidad.

Conecta distintas formas de prueba

Una métrica mide una cantidad a lo largo del tiempo. Un log registra un evento. Una traza conecta operaciones relacionadas mientras una solicitud recorre un sistema. Un span representa una operación dentro de una traza.

En el trabajo asíncrono, conserva una correlación segura entre el trabajo enviado y la ejecución del worker. Una respuesta HTTP 202 puede significar que se aceptó el trabajo. No demuestra que la exportación haya terminado.

Alerta cuando haga falta actuar

Define el SLI y su denominador antes de fijar el SLO. En el ejemplo, cuenta las exportaciones válidas completadas correctamente dentro de la duración acordada. Define cómo entran en la medición los trabajos largos y los abandonados.

Un presupuesto de error describe el fallo permitido dentro de la ventana del SLO. La tasa de consumo indica a qué velocidad los fallos consumen ese presupuesto. La guía de Google usa varias ventanas para equilibrar la detección oportuna y el ruido de alertas. Alertas basadas en SLO.

Avisa a la persona de guardia cuando la condición exija actuar a tiempo. Envía el trabajo menos urgente a una cola. Cada alerta necesita responsable, descripción del impacto, enlace de investigación e instrucciones de respuesta. Revisa las alertas que repetidamente no llevan a ninguna acción.

No uses un umbral genérico para todos los servicios. El impacto en usuarios, el tráfico, el horario de negocio y la capacidad de respuesta influyen en la decisión.

Protege el pipeline de telemetría

La telemetría puede contener datos personales, tokens, parámetros de solicitud y documentos confidenciales. Define los campos permitidos antes de recogerlos. Restringe acceso y conservación. Elimina los secretos antes de exportar a un backend externo. Telemetría sensible.

No uses el correo de un cliente ni un identificador único de trabajo como etiqueta de métrica. Las etiquetas sin límites aumentan el número de series temporales y pueden exponer identificadores. Usa dimensiones controladas para las métricas. Coloca los identificadores de correlación autorizados en logs o trazas con acceso controlado.

Mide el propio pipeline. Comprueba fallos de ingestión, datos descartados y antigüedad de la última observación. Una gráfica plana de errores puede significar ausencia de errores o ausencia de telemetría entrante. Haz visible esa distinción.

Investiga un fallo concreto

El servicio ficticio devuelve HTTP 202 para cada solicitud. La antigüedad de su cola pasa de segundos a 15 minutos. Los logs de workers muestran tiempos de espera de base de datos agotados repetidamente. Las trazas muestreadas sitúan la mayor parte del tiempo del worker en llamadas a la base de datos.

Estas pruebas permiten una investigación concreta. No establecen si la causa es un cambio de consulta, conexiones agotadas o capacidad de base de datos. Compara estas hipótesis con el método de depuración.

Taiga Monitoring ofrece una vista del estado del producto con señales de disponibilidad y experiencia en el navegador. Complementa la observabilidad de infraestructura y aplicación; no sustituye a esos sistemas. Monitoring.