Observabilidad & SRE
APM, logs y trazas: los KPIs de observabilidad que realmente importan
APM, logs estructurados y trazas distribuidas: qué KPIs medir, cómo correlacionar las señales y qué herramientas usar en sistemas modernos sobre AWS.
La mayoría de equipos tienen métricas. Pocos tienen observabilidad real. La diferencia está en la correlación: poder ir de una alerta a la causa raíz en minutos, sin necesidad de reproducir el problema. APM, logs estructurados y trazas distribuidas son las tres señales que, combinadas, dan esa capacidad.
Las tres señales de observabilidad y qué responde cada una
| Señal | Pregunta que responde | KPIs clave | Herramientas AWS |
|---|---|---|---|
| Métricas (APM) | ¿Qué está pasando ahora? | Latencia p50/p95/p99, error rate, throughput, saturación | CloudWatch, X-Ray, EMF |
| Logs | ¿Qué ocurrió exactamente? | Eventos de error, auditoría de acciones, contexto de fallos | CloudWatch Logs, OpenSearch, Kinesis |
| Trazas | ¿Por qué falló y dónde? | Tiempo por servicio, cuellos de botella, dependencias lentas | AWS X-Ray, OpenTelemetry |
Impacto de tener las 3 señales correlacionadas vs. solo métricas
Resultados comparados en equipos con incidentes de producción resueltos
KPIs de APM que debes medir por tipo de sistema
| KPI | API REST | Microservicios | SaaS B2B |
|---|---|---|---|
| Latencia | p95 < 200ms | p99 por servicio | p95 por tenant |
| Error rate | < 0.1% 5xx | < 0.5% por servicio | < 0.01% transacciones de negocio |
| Disponibilidad | 99.9% (SLO) | 99.5% por servicio crítico | 99.95% para tier enterprise |
| Throughput | RPS por endpoint | Events/sec por cola | Transacciones/hora por cliente |
| Apdex | > 0.9 | > 0.85 por servicio | > 0.95 para usuarios premium |
Checklist 30/60/90 días para madurez de observabilidad
Primeros 30 días — Instrumentación básica
- Activar AWS X-Ray en todos los servicios Lambda, ECS y API Gateway críticos.
- Migrar a logs estructurados (JSON) con campos estándar: service, level, traceId, requestId, duration.
- Configurar las 4 Golden Signals como métricas de CloudWatch o Prometheus.
- Crear un dashboard operativo central con latencia, error rate y disponibilidad por servicio.
Días 31-60 — Correlación y OpenTelemetry
- Instrumentar servicios críticos con OpenTelemetry SDK (Java, Node, Python o Go).
- Configurar propagación de trace ID en headers HTTP (W3C TraceContext).
- Vincular logs con trazas: incluir traceId en todos los logs para correlación directa.
- Definir SLOs con error budgets para los 3-5 servicios más críticos del negocio.
Días 61-90 — Alerting inteligente y cultura
- Migrar alertas de umbrales fijos a alertas basadas en burn rate de error budget.
- Crear runbooks para las 10 alertas más frecuentes con pasos de diagnóstico y resolución.
- Establecer proceso de postmortem blameless con plantilla estándar.
- Revisar mensualmente SLO vs. error budget: si se consume el presupuesto, pausar features y priorizar fiabilidad.
Comparativa de stacks de observabilidad para AWS
| Stack | Componentes | Coste mensual orientativo | Mejor para |
|---|---|---|---|
| AWS nativo | CloudWatch + X-Ray + CloudWatch Logs Insights | 100–500€/mes (a escala media) | Equipos que prefieren no gestionar infraestructura de observabilidad |
| Grafana OSS | Prometheus + Loki + Tempo + Grafana | 200–800€/mes (cómputo + almacenamiento) | Equipos técnicos con presupuesto ajustado y control total |
| Grafana Cloud | Managed Prometheus + Loki + Tempo | 300–1.500€/mes (por volumen de datos) | Balance entre Grafana OSS y Datadog |
| Datadog | APM + Logs + Infra + Synthetics | 500–3.000€/mes (por hosts y logs ingestados) | Equipos que priorizan tiempo-to-valor y experiencia out-of-the-box |
Guías relacionadas
¿Quieres implementar observabilidad completa en tu sistema AWS?
Diseñamos e implantamos la stack de observabilidad adecuada a tu arquitectura: APM, logs estructurados, trazas distribuidas y dashboards operativos con SLOs definidos.
Ver servicio de observabilidad SREValidación técnica y evidencia recomendada
Para que este enfoque sea defendible ante dirección y equipos técnicos, conviene acompañar la implementación con pruebas repetibles, métricas comparables y un registro claro de decisiones.
Pruebas técnicas mínimas
- Definir SLI/SLO por servicio crítico y validar ventanas de error budget.
- Prueba de alertas con escenarios controlados (ruido vs señal).
- Simulación de incidente para validar detección y escalado.
- Revisión de postmortem con acciones preventivas verificables.
Protocolo de validación reproducible
| Fase | Objetivo | Método | Criterio de aceptación |
|---|---|---|---|
| Baseline | Identificar servicios críticos y experiencia objetivo | Definir user journeys y SLI asociados | SLO acordados por servicio crítico |
| Hipótesis | Reducir ruido y acelerar respuesta | Clasificar alertas por severidad y accionabilidad | Plan para reducir alertas irrelevantes |
| Validación | Comprobar detección y recuperación | Game day con escenarios de fallo controlado | MTTD/MTTR dentro de objetivo |
| Escalado | Sostener fiabilidad en crecimiento | Revisión semanal de error budget y postmortems | Incidentes repetitivos en descenso |
Datos que debes conservar como evidencia
| Métrica | Herramienta | Cadencia | Objetivo |
|---|---|---|---|
| Disponibilidad real | Synthetics + SLO | Diario | >= objetivo SLO |
| MTTD | Alerting | Semanal | Tendencia descendente |
| MTTR | Incidentes | Semanal | Tendencia descendente |
| Incidentes repetitivos | Postmortem tracker | Mensual | < 20% |
Dashboard mínimo recomendado
| Panel | Fuente | Actualización | Umbral operativo |
|---|---|---|---|
| Error budget | SLO platform | Diario | Consumo < 75% de ventana |
| Ruido de alertas | Pager / alert manager | Diario | Alertas accionables > 60% |
| Diagnóstico | Logs + traces + metrics | Tiempo real | Tiempo a causa raíz en descenso |
| Postmortem | Tracker de acciones | Semanal | Acciones cerradas >= 80% en plazo |
Curva de madurez esperada (referencial)
Esta visualización sirve como referencia operativa para 90 días. Debe ajustarse con tus datos reales, complejidad técnica y contexto de negocio.
SLI/SLO y señal de alertas definidos.
Reducción de ruido y mejor detección temprana.
MTTD/MTTR en descenso con playbooks activos.
Ciclo continuo de mejora con error budget.
Riesgos que invalidan resultados
- Definir SLO sin vincularlos a una experiencia de usuario concreta.
- Tener dashboards bonitos pero sin alertas accionables.
- Acumular postmortems sin cerrar acciones preventivas.
- Medir disponibilidad solo por infraestructura y no por transacción.
Recomendaciones de implementación real
- No crear alertas sin playbook asociado.
- Reducir ruido de alertado antes de ampliar cobertura.
- Unificar trazas, logs y métricas por servicio para acelerar diagnóstico.
- Cerrar postmortems solo con acciones implementadas y validadas.
Preguntas frecuentes que suele hacer un equipo técnico
¿Qué diferencia hay entre monitorización y observabilidad?
Monitorización detecta síntomas; observabilidad permite explicar causas. Para SRE necesitas ambas y trazabilidad end-to-end.
¿Cuántos SLO debería definir al inicio?
Empieza con 2-4 SLO por servicio crítico (latencia, disponibilidad, errores) y amplía cuando el proceso madure.
¿Cómo reducir la fatiga del equipo on-call?
Eliminando alertas no accionables, mejorando runbooks y midiendo de forma estricta el ratio señal/ruido.
Preguntas frecuentes
¿Qué es APM y por qué es diferente del monitoring de infraestructura?
APM (Application Performance Monitoring) monitoriza el rendimiento a nivel de aplicación: latencia de transacciones, tasa de errores, throughput, y trazas de código. El monitoring de infraestructura observa recursos (CPU, memoria, disco). Ambos son complementarios: la infraestructura dice 'la CPU está al 90%', el APM dice 'el endpoint /checkout tarda 3 segundos porque la query a RDS no usa índice'.
¿Cuáles son los KPIs de observabilidad más importantes para sistemas web?
Los 4 Golden Signals de Google SRE: latencia (tiempo de respuesta de peticiones), tráfico (rate de peticiones por segundo), errores (rate de errores 5xx y errores de negocio) y saturación (uso de recursos cercano al límite). Complementariamente: disponibilidad (uptime), MTTR (tiempo de resolución de incidentes) y error budget consumido.
¿Qué es OpenTelemetry y por qué se ha convertido en estándar?
OpenTelemetry (OTel) es un estándar open source para instrumentación de métricas, logs y trazas. Es vendor-neutral: puedes instrumentar tu aplicación una vez y enviar los datos a Datadog, Grafana, Jaeger o AWS X-Ray sin cambiar el código. Esto elimina el lock-in de vendor y es la razón por la que se ha convertido en el estándar de facto en 2025-2026.
¿Cuándo usar Datadog vs. Grafana + Prometheus?
Datadog es la opción 'plug and play' con mejor experiencia out-of-the-box, correlación automática de señales y soporte enterprise. Cuesta más (0.03–0.05€/host/hora + logs). Grafana + Prometheus + Loki + Tempo es la stack open source equivalente: más trabajo inicial de configuración, menor coste, mayor control. Para equipos técnicos con presupuesto ajustado: Grafana. Para equipos que quieren tiempo-to-valor rápido: Datadog.
¿Cómo se correlacionan logs, trazas y métricas en la práctica?
Mediante el trace ID: un identificador único que se propaga en cada petición a través de todos los servicios. Cuando una traza muestra latencia alta en el servicio B, puedes saltar directamente a los logs de ese servicio filtrados por ese trace ID, y correlacionar con las métricas de recursos de ese momento. Herramientas como Grafana Tempo + Loki + Prometheus o Datadog hacen esta correlación automáticamente.