Express.js
Observabilidad: logs, métricas y trazas
Explica cómo conectar logs, métricas y trazas para seguir una request por Express.js, base de datos, colas y servicios externos.
- Última actualización
- Actualizada
- Nivel
- Profundización
Express.js
Explica cómo conectar logs, métricas y trazas para seguir una request por Express.js, base de datos, colas y servicios externos.
Observabilidad es la capacidad de inferir el estado interno del sistema a partir de señales externas. Logs, métricas y trazas responden preguntas diferentes y se complementan.
logs
→ eventos detallados
métricas
→ tendencias y alertas agregadas
trazas
→ recorrido de una operación distribuidaTener muchas herramientas no garantiza observabilidad. Las señales deben estar conectadas mediante tiempo, servicio, route, request ID o trace context.
Cuando una API es lenta, necesitas distinguir:
Un log aislado o promedio global puede ocultarlo.
Para servicios HTTP, RED es una base:
Añade saturación de recursos: CPU, memoria, event loop lag, sockets, pool y queue depth.
El promedio oculta colas largas. Mide p50, p95 y p99 mediante histogramas adecuados.
No calcules percentiles promediando percentiles de instancias. El backend de métricas debe agregarlos correctamente.
Labels como método, route template, status class y service son útiles.
No uses como labels:
Alta cardinalidad incrementa coste y puede inutilizar el sistema.
Ejemplo conceptual:
httpDuration.observe({
method: request.method,
route: response.locals.routeTemplate,
status: String(Math.floor(response.statusCode / 100) * 100),
}, durationSeconds);El route template debe resolverse de forma consistente, incluidos 404.
Una trace representa una operación completa. Cada span representa una etapa:
POST /orders
├─ validate input
├─ PostgreSQL transaction
│ ├─ INSERT order
│ └─ UPDATE inventory
└─ publish outboxLos spans contienen duración, status y atributos limitados.
W3C Trace Context utiliza headers como traceparent. Propágalo a llamadas HTTP, jobs y mensajes.
No confíes ciegamente en cualquier header para decisiones de seguridad; el tracer puede aceptar o crear contexto según límites de confianza.
OpenTelemetry ofrece APIs y auto-instrumentation para Node/Express, HTTP y bases de datos. La instrumentación automática acelera, pero necesita revisión de:
Registrar todas puede ser costoso. Estrategias:
Tail sampling necesita infraestructura que vea la trace completa.
Un error log debería incluir trace ID. Desde una alerta de latencia puedes abrir una trace y después buscar logs del span.
alerta métrica
→ trace lenta
→ span PostgreSQL
→ log de timeout/queryEsta navegación es el valor combinado.
Un SLO define una expectativa, por ejemplo:
99.9% de POST /orders exitosos y debajo de 800ms en 30 díasAlertas basadas en error budget suelen ser más útiles que “CPU > 80%” aislado.
CPU es una señal diagnóstica; la experiencia del usuario es el objetivo.
Métricas técnicas no sustituyen resultados del producto:
Evita datos personales como labels. Usa agregaciones seguras.
No agregues SQL completo con valores a labels. Normaliza query name o fingerprint.
Propaga trace/context desde outbox cuando tenga sentido, reconociendo que el job puede ejecutarse mucho después.
Una alerta indica p99 alto en creación de pedidos:
POST /orders y status 2xx afectados.Sin señales conectadas, podría haberse aumentado el pool y ocultado la causa.
Un dashboard útil cuenta una historia:
No crees paneles con cientos de gráficas sin preguntas operativas.
Una alerta debe ser accionable:
Evita alertar por cada excepción individual si no requiere acción.
Telemetría tiene coste de CPU, red, almacenamiento y datos. Define sampling, retención y redacción. Un body capturado en trace puede ser tan sensible como un log.
Performance y load testing utiliza estas señales para medir capacidad y encontrar cuellos de botella.