Observabilidad en sistemas distribuidos
Un sistema distribuido falla de formas que no se ven en una sola máquina. La observabilidad es la capacidad de inferir el estado interno del sistema a partir de lo que emite hacia afuera, sin tener que instrumentar cada caso por adelantado.
Las tres señales
- Logs: registros de eventos, con texto y estructura, lo que pasó en un instante.
- Métricas: números agregados en el tiempo (conteos, latencias), buenos para tendencias y alertas.
- Trazas: el recorrido completo de una petición a través de varios servicios.
Trazas distribuidas
Una traza es el camino de una petición end-to-end; se descompone en spans, cada uno una unidad de trabajo en un servicio. Un identificador de traza se propaga entre servicios para poder reconstruir el recorrido y ver dónde se acumula la latencia.
Métricas: RED y USE
- RED para servicios: Rate (peticiones por segundo), Errors, Duration.
- USE para recursos: Utilization, Saturation, Errors.
- Las métricas definen indicadores de servicio (SLI) y objetivos (SLO).
Logs estructurados y correlación
Un log con campos y el mismo identificador de traza permite saltar de un pico en un dashboard a la traza lenta y de ahí al log exacto. Sin correlación, el ingeniero busca a mano y pierde el hilo.
OpenTelemetry y sampling
OpenTelemetry es el estándar abierto para instrumentar y exportar las tres señales. Como trazar todo cuesta, se usa muestreo: head sampling (decidir al inicio) o tail sampling (conservar siempre los errores y las trazas lentas).
| Señal | Qué es | Sirve para | Costo |
|---|---|---|---|
| Métricas | números agregados | alertar y ver tendencias | bajo |
| Logs | eventos con detalle | entender qué pasó | medio |
| Trazas | recorrido por servicio | localizar cuellos de botella | alto |
Alertar sobre síntomas, diagnosticar con todo
Una alerta debe encenderse por un síntoma que le duele al usuario (latencia o error rate alto), no por cada causa posible. El panel y las trazas sirven para diagnosticar una vez que la alerta sonó.
Errores frecuentes
- Logs sin estructura que nadie puede filtrar.
- Alertar por causas y despertar al equipo por ruido.
- Instrumentar sin correlación, de modo que nada se puede hilar.
Ejemplo resuelto: una compra tardó 8 segundos
- La alerta de latencia (un SLI) dispara.
- Abrir una traza muestreada lenta para ver en qué span se fue el tiempo.
- Identificar el servicio culpable (una llamada a inventario).
- Correlacionar con logs de ese servicio filtrando por el id de traza.
- Crear una métrica y una alerta para detectar el patrón antes que el usuario.
¿Para qué sirve en la realidad?
Sin observabilidad, un incidente en un sistema distribuido es un cuarto oscuro. Con ella, el recorrido de pregunta-resuesta se acorta: ver el síntoma, aislar el servicio y entender la causa antes de que escale.
¿Qué diferencia la observabilidad del monitoreo clásico?
En una traza distribuida, un span representa una unidad de trabajo dentro de un servicio.
El estándar abierto para instrumentar y exportar logs, métricas y trazas se llama .
Clasifica cada pregunta según la señal que mejor la responde.
Métrica
Traza
Log
Une cada término con su definición.
Observabilidad
Observabilidad distribuida: logs, métricas y trazas
# Observabilidad ## Senales ### logs ### metricas RED y USE ### trazas y spans ## Recolectar ### OpenTelemetry ### head y tail sampling ## Usar ### alertar sintomas ### diagnosticar con trazas y logs ### correlacionar por id
OpenTelemetry (documentación oficial)
Referencia del estándar para instrumentar trazas, métricas y logs.
Monitoreo de sistemas distribuidos (Google SRE Book)
Cómo pensar señales, SLI y alertas basadas en síntomas.
Tu servicio de checkout tiene latencia intermitente que solo aparece bajo carga y ningún tablero la muestra. ¿Qué traza de señal implementarías primero (logs, métricas o trazas) y cómo la correlacionarías para encontrar el cuello de botella?