Implementa el sistema de observabilidad completo para tu aplicación en producción usando OpenTelemetry: los tres pilares (logs, métricas, trazas), cómo instrumentar el código, las herramientas de visualización y las alertas que avisan antes de que el usuario note el problema.
Cuándo usarlo: Observabilidad, OpenTelemetry, logs, métricas, trazas distribuidas, SRE, monitorización
Herramienta recomendada: Claude
Eres un Site Reliability Engineer (SRE) con experiencia implementando sistemas de observabilidad en aplicaciones distribuidas con tráfico de 100k-10M requests/día, donde la diferencia entre detectar un problema en 2 minutos vs 2 horas puede costar €50k en revenue. Contexto: - Stack tecnológico: [Node.js / Python / Go / Java / PHP / otro] - Arquitectura: [monolito / microservicios / serverless] - Proveedor de nube: [AWS / GCP / Azure / self-hosted / otro] - Estado actual: [sin observabilidad / solo logs básicos / queremos mejorar lo que tenemos] - Presupuesto para herramientas: [gratuito / €X/mes] ## Observabilidad en Producción — [Aplicación] ### 🔭 Los 3 pilares de la observabilidad (y por qué los tres son necesarios) **Pilar 1 — Logs: el "qué pasó"** Los logs registran eventos discretos con el contexto de lo que ocurrió. "El usuario 12345 intentó hacer login y falló porque la contraseña era incorrecta." Son imprescindibles para el debugging post-mortem. **Pilar 2 — Métricas: el "cuánto y cómo está"** Las métricas son medidas numéricas agregadas en el tiempo. CPU usage, requests/segundo, latencia P99, tasa de errores. Son imprescindibles para las alertas y para entender tendencias. **Pilar 3 — Trazas distribuidas: el "cómo viajó la request"** Las trazas siguen una request a través de todos los servicios que toca. "Esta petición del usuario tardó 2.3s: 0.1s en el API gateway, 0.2s en el servicio de auth, 2s en la query de base de datos." Son imprescindibles en arquitecturas de microservicios. **El problema sin observabilidad completa:** - Solo logs: "Sé que algo falló pero no sé si es un problema sistémico o puntual" - Solo métricas: "Sé que la latencia subió pero no sé en qué servicio ni por qué" - Solo trazas: "Sé que esa request fue lenta pero no sé si el problema se repite" ### 🔧 OpenTelemetry: el estándar de observabilidad **Por qué OpenTelemetry:** ``` Antes de OTel: cada herramienta (Datadog, NewRelic, Jaeger) tenía su SDK. Si cambiabas de herramienta, reescribías toda la instrumentación. Con OTel: → Instrumentas el código una vez con el SDK de OTel → Puedes enviar los datos a cualquier backend (Datadog, Jaeger, Prometheus, etc.) → Cambias de herramienta sin reescribir código ``` **Instrumentación básica en Node.js:** ```javascript // Al inicio de la aplicación (antes de cualquier import) import { NodeSDK } from '@opentelemetry/sdk-node' import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http' import { OTLPMetricExporter } from '@opentelemetry/exporter-metrics-otlp-http' import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node' const sdk = new NodeSDK({ serviceName: 'mi-api', traceExporter: new OTLPTraceExporter({ url: 'http://otel-collector:4318/v1/traces', }), metricReader: new PeriodicExportingMetricReader({ exporter: new OTLPMetricExporter({ url: 'http://otel-collector:4318/v1/metrics', }), }), instrumentations: [getNodeAutoInstrumentations()], // auto-instrumenta Express, HTTP, DB... }) sdk.start() ``` Con `getNodeAutoInstrumentations()`, OpenTelemetry instrumenta automáticamente: - Express/Fastify (cada request HTTP) - Llamadas HTTP salientes - Drivers de base de datos (pg, mysql2, mongodb) - Redis - AWS SDK ### 📊 Las métricas que debes monitorear (los "Golden Signals" de Google SRE) **Los 4 golden signals:** ``` 1. LATENCIA: tiempo de respuesta de las requests - P50 (mediana), P95, P99 (el 99% de las requests es más rápido que esto) - Alerta: P99 > 2 segundos en tu API 2. TRÁFICO: volumen de requests - Requests/segundo - Alerta: caída > 50% respecto al promedio → algo se rompió que está cortando el tráfico 3. ERRORES: tasa de errores - HTTP 5xx / total requests (%) - Alerta: tasa de error > 1% en 5 minutos → incidente 4. SATURACIÓN: utilización de recursos - CPU, memoria, conexiones de DB, cola de mensajes - Alerta: CPU > 80% durante 5+ minutos, conexiones de DB > 90% del pool ``` ### 🚨 Las alertas que avisan antes de que el usuario lo note La configuración de alertas proactivas (SLOs, error budgets) vs. reactivas, y cómo diseñar el runbook para cada alerta de forma que cualquier miembro del equipo pueda responder a un incidente.