Observabilidad que responde preguntas
Conecta métricas, logs y trazas con las decisiones que una persona de operación realmente necesita tomar.
AL TERMINAR, PODRÁS
- Elegir señales a partir del comportamiento visible para el usuario
- Distinguir métricas, logs y trazas
- Controlar la cardinalidad y los datos sensibles
Descripción del diagrama: ¿Por qué se retrasan? → Métricas; ¿Por qué se retrasan? → Trazas; ¿Por qué se retrasan? → Logs; Métricas → Respuesta; Trazas → Respuesta; Logs → Respuesta
Empieza con una pregunta
La observabilidad es útil cuando ayuda a explicar qué está haciendo el sistema a partir de lo que produce.
Empieza con preguntas operativas: ¿se están aceptando los trabajos?, ¿se completan a tiempo?, ¿dónde se concentran las fallas? Tráfico, errores, latencia y saturación son un buen conjunto inicial de señales. En una cola, la antigüedad del trabajo en espera más viejo puede revelar el problema del usuario más directamente que el uso de CPU.
Un endpoint HTTP sano puede convivir con una flota de workers que dejó de procesar, así que observa el resultado de punta a punta además de los componentes individuales.
Usa las señales en conjunto
Las métricas agregan mediciones en el tiempo y permiten tendencias y alertas.
Los logs capturan eventos y contexto. Las trazas (traces) conectan el trabajo a través de las fronteras entre componentes y ayudan a ubicar retrasos a lo largo de un camino. Lleva el contexto de correlación desde la entrada, pasando por el almacenamiento de la cola, hasta la ejecución en el worker, recordando que el trabajo asíncrono puede durar más que la petición original.
Un ID de trabajo pertenece a los logs o atributos de traza relevantes; usar cada ID de trabajo como etiqueta de una métrica puede crear una cardinalidad sin límite de series de tiempo y volver el monitoreo caro o inservible.
Instrumenta los caminos de falla
Registra la aceptación, la reserva (claim), el reintento, la finalización y la falla permanente con significados coherentes.
Separa el tiempo de espera en la cola de la duración de la ejecución, para que un sistema lento apunte a la planificación o al manejo en lugar de a un único número mezclado. Mide distribuciones y la latencia en los percentiles altos (tail latency); los promedios pueden esconder a un grupo pequeño de usuarios que espera mucho más. Evita registrar secretos de los cuerpos o información personal innecesaria.
Las alertas deberían indicar una condición accionable, con un responsable y un runbook (guía de operación) útil. Un panel que nadie sabe interpretar durante un incidente es decoración, por muy pulido que se vea.
ERROR FRECUENTE
Los promedios y los logs que solo registran éxitos pueden hacer que un sistema parezca sano mientras los trabajos lentos o fallidos desaparecen de la medición.
INTÉNTALO TÚ
Elige tres métricas de Relay, dos eventos de log estructurados y un camino de traza. Para cada uno, escribe la pregunta operativa que responde y los datos sensibles que hay que excluir.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Instrumenta en Relay la espera en cola, la duración de la ejecución, los resultados de finalización y la antigüedad del trabajo pendiente más viejo, con definiciones coherentes.