System Design
Observabilidad y operación
Explica cómo diseñar logs, métricas, trazas, alertas, dashboards, runbooks y ownership para detectar, diagnosticar y operar el sistema en producción.
- Última actualización
- Actualizada
- Nivel
- Profundización
System Design
Explica cómo diseñar logs, métricas, trazas, alertas, dashboards, runbooks y ownership para detectar, diagnosticar y operar el sistema en producción.
Observabilidad no es acumular logs. Es poder formular una pregunta nueva sobre el sistema y obtener evidencia suficiente para comprender impacto, causa y estado de recuperación.
La observabilidad convierte comportamiento interno en señales externas útiles. Operación utiliza esas señales para detectar, diagnosticar, responder y aprender.
Un sistema puede estar “arriba” y aun así fallar para ciertos tenants, regiones o operaciones. Sin contexto y correlación, el equipo sabe que algo está mal, pero no quién está afectado, desde cuándo ni por qué.
comportamiento real
→ logs + métricas + trazas + perfiles + eventos de negocio
→ detección
→ diagnóstico
→ acción
→ verificación
→ aprendizajeRegistros discretos con contexto. Son útiles para eventos, decisiones y errores concretos.
Series numéricas agregables. Permiten tendencias, SLOs, alertas y capacidad.
Representan el recorrido de una operación entre componentes, con spans y relaciones temporales.
Muestran dónde se consume CPU, memoria, bloqueo o tiempo dentro de un proceso.
Pedidos confirmados, pagos inciertos o reservas fallidas ayudan a detectar impacto funcional que las métricas técnicas no muestran.
{
"timestamp": "2026-07-24T15:30:00Z",
"level": "error",
"service": "order-api",
"version": "1.42.0",
"environment": "production",
"traceId": "tr_123",
"requestId": "req_456",
"tenantId": "ten_1",
"operation": "confirm_order",
"orderId": "ord_789",
"errorCode": "PAYMENT_TIMEOUT",
"durationMs": 842
}Los campos permiten filtrar y correlacionar. No registres tokens, contraseñas, tarjetas ni PII innecesaria.
El nivel debe tener semántica consistente. Registrar cada excepción controlada como error crea ruido.
Etiquetas como userId, orderId o URL completa pueden generar millones de series métricas y elevar coste. Datos de alta cardinalidad pertenecen mejor a logs o trazas, mientras métricas usan dimensiones acotadas.
Distribución de tiempo, separando éxito y error.
Volumen de solicitudes, mensajes o transacciones.
Fallos técnicos y funcionales.
Uso cercano al límite: CPU, memoria, conexiones, lag o cola.
Estas señales forman un punto de partida, no sustituyen métricas específicas del dominio.
Ambos ayudan a estructurar dashboards sin convertirlos en colecciones arbitrarias.
Medición de experiencia, como proporción de solicitudes válidas completadas dentro de 500 ms.
Objetivo interno sobre el SLI, por ejemplo 99.9 % mensual.
Compromiso contractual y posibles consecuencias.
Un SLO debe definir población, exclusiones, ventana y fuente de datos.
buenas solicitudes = POST /orders válidos
completados con resultado conocido
en menos de 800 ms
SLI = buenas solicitudes / solicitudes elegiblesNo excluyas fallos simplemente para mejorar la cifra. Las exclusiones deben representar tráfico que realmente no mide la experiencia acordada.
Si el SLO es 99.9 %, el 0.1 % restante es presupuesto de error. Permite discutir cambios y confiabilidad con una unidad común.
Cuando se consume demasiado:
No debe usarse como permiso para causar fallos deliberadamente.
Una traza conecta spans mediante contexto propagado.
web
→ gateway
→ order-api
→ postgres
→ payment-providerCada span puede mostrar duración, resultado y atributos. Las trazas ayudan a encontrar el camino crítico, pero requieren sampling y propagación correcta.
IDs útiles:
Los IDs deben propagarse entre HTTP, colas y jobs.
Guardar todas las trazas puede ser costoso. Estrategias:
Asegura que los casos raros importantes no desaparezcan.
La profundidad sola puede parecer estable mientras mensajes antiguos incumplen el tiempo útil.
Monitorea:
Un pipeline puede estar técnicamente vivo y producir datos incorrectos.
Una alerta debe ser:
Alertan sobre experiencia: tasa de error o SLO.
Alertan sobre causas conocidas: disco casi lleno o réplica retrasada.
Las primeras detectan impacto; las segundas ayudan a prevenir o diagnosticar.
En lugar de esperar al final de la ventana del SLO, calculan qué tan rápido se consume el error budget. Ventanas rápidas detectan incidentes graves; ventanas largas detectan degradación sostenida.
Un dashboard útil responde una pregunta:
Debe mostrar contexto, comparaciones y enlaces, no todas las métricas disponibles.
Cada alerta importante enlaza a:
Flujo típico:
Durante el incidente se prioriza restaurar servicio, no encontrar culpables.
Analizan condiciones sistémicas:
Evita “error humano” como causa final; pregunta qué controles y contexto permitieron el fallo.
Segmenta por:
Un canary debe poder compararse con la versión estable.
Define niveles de retención y sampling. Logs de debug no necesitan conservarse igual que auditoría. El coste también depende de volumen, cardinalidad, consultas y exportación.
El sistema puede estar sano pero parecer invisible. Monitorea el pipeline de observabilidad de forma independiente.
Enviar logs de forma síncrona puede afectar latencia o disponibilidad.
Relojes desalineados complican secuencias. Usa sincronización y timestamps del evento y de ingestión cuando importe.
Atrapar y relanzar puede perder causa. Conserva cadena de errores y contexto.
Sanitiza atributos antes de exportar.
Cuando no existe propósito operacional, el dato es sensible, duplica otras señales o el coste supera el valor. Más telemetría no siempre produce más comprensión.
orderId suele ser mala etiqueta de métrica?Decisiones y trade-offs registra por qué se eligió una alternativa y qué consecuencias deben vigilarse.