Arquitectura · 28 de octubre de 2026 · Daniel Murillo

Observabilidad: logs, métricas, tracing y OpenTelemetry

Los logs cuentan eventos, las métricas muestran tendencias y los traces siguen una petición. Instrumenta para investigar lo que no anticipaste.

Los logs cuentan eventos, las métricas muestran tendencias y los traces ayudan a seguir una petición a través del sistema. La observabilidad consiste en poder investigar lo que no anticipaste.

Introducción

Una aplicación puede funcionar localmente y fallar bajo tráfico real, con datos inesperados o por una dependencia lenta. La observabilidad permite investigar esos comportamientos con evidencia.

No significa instalar tres dashboards ni guardar todos los logs para siempre. Significa instrumentar el sistema para responder preguntas operativas: ¿qué está fallando?, ¿a quién afecta?, ¿desde cuándo?, ¿dónde se pierde el tiempo? y ¿qué cambió?

1. Las tres señales principales

Logs

Eventos discretos con contexto. En sistemas distribuidos usa logs estructurados y campos de correlación (trace_id, request_id, order_id).

{
  "level": "error",
  "message": "payment_provider_timeout",
  "service": "checkout-api",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "order_id": "ord_123"
}

No registres contraseñas, tokens, secretos ni datos personales innecesarios.

Métricas

Valores agregados en el tiempo: tasa de peticiones, errores, latencia, CPU, memoria, conexiones del pool. Sirven para alertas y tendencias.

Modelos útiles:

RED (para servicios request/response): Rate, Errors, Duration.
USE (para recursos): Utilization, Saturation, Errors.

Evita etiquetas de cardinalidad muy alta (user_id, request_id) en métricas: disparan costo y memoria.

Distributed tracing

Un trace es el recorrido de una operación; los spans son unidades de trabajo. Una petición puede atravesar gateway, API, base de datos y un proveedor externo.

Trace: POST /checkout
 ├─ API handler          18 ms
 ├─ PostgreSQL query      7 ms
 └─ Payment provider    940 ms  ← principal sospechoso

El valor está en ver el camino de una petición, no en acumular spans sin criterio.

Cómo se complementan

Pregunta	Señal que suele responder primero
¿Está peor que ayer el p95?	Métricas
¿Qué falló en esta orden concreta?	Logs (+ `trace_id`)
¿Dónde se fue el tiempo en esta petición?	Trace
¿Cuántos usuarios afecta este error?	Métricas + logs agregados

2. OpenTelemetry: instrumentación, no el backend completo

OpenTelemetry (OTel) aporta APIs, SDKs, convenciones y protocolos (OTLP) para generar y transportar telemetría. No es por sí solo un almacén de logs, un sistema de alertas ni una UI.

Aplicación instrumentada
  ├─ traces
  ├─ métricas
  └─ logs
       ↓ OTLP
OpenTelemetry Collector
       ↓
Backend(s) de observabilidad
       ↓
Dashboards, consultas y alertas

El Collector recibe, procesa, filtra y exporta. Así evitas acoplar el código a un proveedor concreto.

3. Ejemplo mínimo: un span en Node.js

Configura el SDK y el exportador antes de cargar los módulos que quieres instrumentar. Prefiere instrumentación automática de HTTP/DB cuando exista; añade spans manuales solo en operaciones de negocio relevantes.

import { trace, SpanStatusCode } from "@opentelemetry/api";

const tracer = trace.getTracer("orders-service");

export async function createOrder(orderId: string) {
  return tracer.startActiveSpan("createOrder", async (span) => {
    try {
      span.setAttribute("order.id", orderId);
      // Validar y persistir la orden aquí.
      return { id: orderId, status: "created" };
    } catch (error) {
      span.recordException(error as Error);
      span.setStatus({ code: SpanStatusCode.ERROR });
      throw error;
    } finally {
      span.end();
    }
  });
}

Demasiados spans aumentan costo y ruido. Instrumenta lo que te ayuda a decidir.

4. Propagación de contexto

Para seguir una petición entre servicios, el contexto debe viajar en encabezados compatibles con W3C Trace Context. Si cada servicio crea un trace nuevo, pierdes la visión de extremo a extremo.

La propagación también es una frontera de confianza: no aceptes sin criterio todo el contexto de clientes no confiables (puede usarse para envenenar o sesgar muestreo).

5. Herramientas: qué problema resuelve cada una

Herramienta	Papel habitual	Consideraciones
OpenTelemetry	Instrumentación y transporte	No es backend de consulta
Prometheus	Métricas	Cuidado con la cardinalidad
Grafana	Dashboards (y más productos OTel)	Necesita fuentes bien diseñadas
Jaeger / Tempo	Traces	Escalabilidad y retención
Loki / Elastic	Logs	Etiquetas, índice y costo
Datadog / New Relic	Plataforma integrada	Conveniencia vs costo y lock-in

OpenTelemetry puede alimentar varios backends. No son sustitutos uno a uno.

6. Alertas útiles y SLO

Una alerta debe ser accionable: indicar un problema que alguien puede investigar y mitigar. Define SLO relevantes para el usuario (disponibilidad o latencia de una operación crítica), no umbrales arbitrarios de CPU.

Ejemplo conceptual de latencia en Prometheus (ajusta el nombre de la métrica a tu instrumentación):

histogram_quantile(
  0.95,
  sum(rate(http_server_duration_seconds_bucket[5m])) by (le)
)

Prueba alertas con fallos controlados. Una alerta que nadie entiende es ruido.

7. Errores frecuentes

Logs sin estructura ni trace_id.
Registrar secretos o PII.
user_id como label de métrica.
Alertar por cada error individual sin medir impacto.
Instalar OTel y creer que ya hay observabilidad.
Muestrear traces sin saber qué transacciones críticas se pierden.
No correlacionar logs ↔ métricas ↔ traces.
Dashboards bonitos que nadie usa en un incidente.

8. Matriz de decisión

Necesidad	Enfoque inicial
Investigar errores concretos	Logs estructurados + correlación
Detectar degradaciones	Métricas + alertas sobre SLO
Seguir una petición entre servicios	Tracing + propagación
Evitar acoplar a un vendor	OpenTelemetry + OTLP
Controlar costos	Muestreo, retención, filtros, cardinalidad
Equipo pequeño	Una plataforma que el equipo pueda operar

Conclusión

La observabilidad empieza por las preguntas que necesitas responder. OpenTelemetry ayuda a instrumentar; los backends almacenan y consultan; las alertas conectan señales con acción.

No hace falta capturarlo todo. Hace falta contexto suficiente para encontrar causas sin exponer datos ni pagar telemetría que nadie usa.

En esta serie

Lecturas relacionadas

Referencias

Índice

Arquitectura · 28 de octubre de 2026 · Daniel Murillo

Observabilidad: logs, métricas, tracing y OpenTelemetry

Los logs cuentan eventos, las métricas muestran tendencias y los traces siguen una petición. Instrumenta para investigar lo que no anticipaste.

Los logs cuentan eventos, las métricas muestran tendencias y los traces ayudan a seguir una petición a través del sistema. La observabilidad consiste en poder investigar lo que no anticipaste.

Introducción

Una aplicación puede funcionar localmente y fallar bajo tráfico real, con datos inesperados o por una dependencia lenta. La observabilidad permite investigar esos comportamientos con evidencia.

1. Las tres señales principales

Logs

Eventos discretos con contexto. En sistemas distribuidos usa logs estructurados y campos de correlación (trace_id, request_id, order_id).

{
  "level": "error",
  "message": "payment_provider_timeout",
  "service": "checkout-api",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "order_id": "ord_123"
}

No registres contraseñas, tokens, secretos ni datos personales innecesarios.

Métricas

Valores agregados en el tiempo: tasa de peticiones, errores, latencia, CPU, memoria, conexiones del pool. Sirven para alertas y tendencias.

Modelos útiles:

RED (para servicios request/response): Rate, Errors, Duration.
USE (para recursos): Utilization, Saturation, Errors.

Evita etiquetas de cardinalidad muy alta (user_id, request_id) en métricas: disparan costo y memoria.

Distributed tracing

Un trace es el recorrido de una operación; los spans son unidades de trabajo. Una petición puede atravesar gateway, API, base de datos y un proveedor externo.

Trace: POST /checkout
 ├─ API handler          18 ms
 ├─ PostgreSQL query      7 ms
 └─ Payment provider    940 ms  ← principal sospechoso

El valor está en ver el camino de una petición, no en acumular spans sin criterio.

Cómo se complementan

Pregunta	Señal que suele responder primero
¿Está peor que ayer el p95?	Métricas
¿Qué falló en esta orden concreta?	Logs (+ `trace_id`)
¿Dónde se fue el tiempo en esta petición?	Trace
¿Cuántos usuarios afecta este error?	Métricas + logs agregados

2. OpenTelemetry: instrumentación, no el backend completo

OpenTelemetry (OTel) aporta APIs, SDKs, convenciones y protocolos (OTLP) para generar y transportar telemetría. No es por sí solo un almacén de logs, un sistema de alertas ni una UI.

Aplicación instrumentada
  ├─ traces
  ├─ métricas
  └─ logs
       ↓ OTLP
OpenTelemetry Collector
       ↓
Backend(s) de observabilidad
       ↓
Dashboards, consultas y alertas

El Collector recibe, procesa, filtra y exporta. Así evitas acoplar el código a un proveedor concreto.

3. Ejemplo mínimo: un span en Node.js

import { trace, SpanStatusCode } from "@opentelemetry/api";

const tracer = trace.getTracer("orders-service");

export async function createOrder(orderId: string) {
  return tracer.startActiveSpan("createOrder", async (span) => {
    try {
      span.setAttribute("order.id", orderId);
      // Validar y persistir la orden aquí.
      return { id: orderId, status: "created" };
    } catch (error) {
      span.recordException(error as Error);
      span.setStatus({ code: SpanStatusCode.ERROR });
      throw error;
    } finally {
      span.end();
    }
  });
}

Demasiados spans aumentan costo y ruido. Instrumenta lo que te ayuda a decidir.

4. Propagación de contexto

Para seguir una petición entre servicios, el contexto debe viajar en encabezados compatibles con W3C Trace Context. Si cada servicio crea un trace nuevo, pierdes la visión de extremo a extremo.

La propagación también es una frontera de confianza: no aceptes sin criterio todo el contexto de clientes no confiables (puede usarse para envenenar o sesgar muestreo).

5. Herramientas: qué problema resuelve cada una

Herramienta	Papel habitual	Consideraciones
OpenTelemetry	Instrumentación y transporte	No es backend de consulta
Prometheus	Métricas	Cuidado con la cardinalidad
Grafana	Dashboards (y más productos OTel)	Necesita fuentes bien diseñadas
Jaeger / Tempo	Traces	Escalabilidad y retención
Loki / Elastic	Logs	Etiquetas, índice y costo
Datadog / New Relic	Plataforma integrada	Conveniencia vs costo y lock-in

OpenTelemetry puede alimentar varios backends. No son sustitutos uno a uno.

6. Alertas útiles y SLO

Ejemplo conceptual de latencia en Prometheus (ajusta el nombre de la métrica a tu instrumentación):

histogram_quantile(
  0.95,
  sum(rate(http_server_duration_seconds_bucket[5m])) by (le)
)

Prueba alertas con fallos controlados. Una alerta que nadie entiende es ruido.

7. Errores frecuentes

Logs sin estructura ni trace_id.
Registrar secretos o PII.
user_id como label de métrica.
Alertar por cada error individual sin medir impacto.
Instalar OTel y creer que ya hay observabilidad.
Muestrear traces sin saber qué transacciones críticas se pierden.
No correlacionar logs ↔ métricas ↔ traces.
Dashboards bonitos que nadie usa en un incidente.

8. Matriz de decisión

Necesidad	Enfoque inicial
Investigar errores concretos	Logs estructurados + correlación
Detectar degradaciones	Métricas + alertas sobre SLO
Seguir una petición entre servicios	Tracing + propagación
Evitar acoplar a un vendor	OpenTelemetry + OTLP
Controlar costos	Muestreo, retención, filtros, cardinalidad
Equipo pequeño	Una plataforma que el equipo pueda operar

Conclusión

La observabilidad empieza por las preguntas que necesitas responder. OpenTelemetry ayuda a instrumentar; los backends almacenan y consultan; las alertas conectan señales con acción.

No hace falta capturarlo todo. Hace falta contexto suficiente para encontrar causas sin exponer datos ni pagar telemetría que nadie usa.

En esta serie

Lecturas relacionadas

Referencias

Índice

Arquitectura · 28 de octubre de 2026 · Daniel Murillo

Observabilidad: logs, métricas, tracing y OpenTelemetry

Los logs cuentan eventos, las métricas muestran tendencias y los traces siguen una petición. Instrumenta para investigar lo que no anticipaste.

Los logs cuentan eventos, las métricas muestran tendencias y los traces ayudan a seguir una petición a través del sistema. La observabilidad consiste en poder investigar lo que no anticipaste.

Introducción

Una aplicación puede funcionar localmente y fallar bajo tráfico real, con datos inesperados o por una dependencia lenta. La observabilidad permite investigar esos comportamientos con evidencia.

1. Las tres señales principales

Logs

Eventos discretos con contexto. En sistemas distribuidos usa logs estructurados y campos de correlación (trace_id, request_id, order_id).

{
  "level": "error",
  "message": "payment_provider_timeout",
  "service": "checkout-api",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "order_id": "ord_123"
}

No registres contraseñas, tokens, secretos ni datos personales innecesarios.

Métricas

Valores agregados en el tiempo: tasa de peticiones, errores, latencia, CPU, memoria, conexiones del pool. Sirven para alertas y tendencias.

Modelos útiles:

RED (para servicios request/response): Rate, Errors, Duration.
USE (para recursos): Utilization, Saturation, Errors.

Evita etiquetas de cardinalidad muy alta (user_id, request_id) en métricas: disparan costo y memoria.

Distributed tracing

Un trace es el recorrido de una operación; los spans son unidades de trabajo. Una petición puede atravesar gateway, API, base de datos y un proveedor externo.

Trace: POST /checkout
 ├─ API handler          18 ms
 ├─ PostgreSQL query      7 ms
 └─ Payment provider    940 ms  ← principal sospechoso

El valor está en ver el camino de una petición, no en acumular spans sin criterio.

Cómo se complementan

Pregunta	Señal que suele responder primero
¿Está peor que ayer el p95?	Métricas
¿Qué falló en esta orden concreta?	Logs (+ `trace_id`)
¿Dónde se fue el tiempo en esta petición?	Trace
¿Cuántos usuarios afecta este error?	Métricas + logs agregados

2. OpenTelemetry: instrumentación, no el backend completo

OpenTelemetry (OTel) aporta APIs, SDKs, convenciones y protocolos (OTLP) para generar y transportar telemetría. No es por sí solo un almacén de logs, un sistema de alertas ni una UI.

Aplicación instrumentada
  ├─ traces
  ├─ métricas
  └─ logs
       ↓ OTLP
OpenTelemetry Collector
       ↓
Backend(s) de observabilidad
       ↓
Dashboards, consultas y alertas

El Collector recibe, procesa, filtra y exporta. Así evitas acoplar el código a un proveedor concreto.

3. Ejemplo mínimo: un span en Node.js

import { trace, SpanStatusCode } from "@opentelemetry/api";

const tracer = trace.getTracer("orders-service");

export async function createOrder(orderId: string) {
  return tracer.startActiveSpan("createOrder", async (span) => {
    try {
      span.setAttribute("order.id", orderId);
      // Validar y persistir la orden aquí.
      return { id: orderId, status: "created" };
    } catch (error) {
      span.recordException(error as Error);
      span.setStatus({ code: SpanStatusCode.ERROR });
      throw error;
    } finally {
      span.end();
    }
  });
}

Demasiados spans aumentan costo y ruido. Instrumenta lo que te ayuda a decidir.

4. Propagación de contexto

Para seguir una petición entre servicios, el contexto debe viajar en encabezados compatibles con W3C Trace Context. Si cada servicio crea un trace nuevo, pierdes la visión de extremo a extremo.

La propagación también es una frontera de confianza: no aceptes sin criterio todo el contexto de clientes no confiables (puede usarse para envenenar o sesgar muestreo).

5. Herramientas: qué problema resuelve cada una

Herramienta	Papel habitual	Consideraciones
OpenTelemetry	Instrumentación y transporte	No es backend de consulta
Prometheus	Métricas	Cuidado con la cardinalidad
Grafana	Dashboards (y más productos OTel)	Necesita fuentes bien diseñadas
Jaeger / Tempo	Traces	Escalabilidad y retención
Loki / Elastic	Logs	Etiquetas, índice y costo
Datadog / New Relic	Plataforma integrada	Conveniencia vs costo y lock-in

OpenTelemetry puede alimentar varios backends. No son sustitutos uno a uno.

6. Alertas útiles y SLO

Ejemplo conceptual de latencia en Prometheus (ajusta el nombre de la métrica a tu instrumentación):

histogram_quantile(
  0.95,
  sum(rate(http_server_duration_seconds_bucket[5m])) by (le)
)

Prueba alertas con fallos controlados. Una alerta que nadie entiende es ruido.

7. Errores frecuentes

Logs sin estructura ni trace_id.
Registrar secretos o PII.
user_id como label de métrica.
Alertar por cada error individual sin medir impacto.
Instalar OTel y creer que ya hay observabilidad.
Muestrear traces sin saber qué transacciones críticas se pierden.
No correlacionar logs ↔ métricas ↔ traces.
Dashboards bonitos que nadie usa en un incidente.

8. Matriz de decisión

Necesidad	Enfoque inicial
Investigar errores concretos	Logs estructurados + correlación
Detectar degradaciones	Métricas + alertas sobre SLO
Seguir una petición entre servicios	Tracing + propagación
Evitar acoplar a un vendor	OpenTelemetry + OTLP
Controlar costos	Muestreo, retención, filtros, cardinalidad
Equipo pequeño	Una plataforma que el equipo pueda operar

Conclusión

La observabilidad empieza por las preguntas que necesitas responder. OpenTelemetry ayuda a instrumentar; los backends almacenan y consultan; las alertas conectan señales con acción.

No hace falta capturarlo todo. Hace falta contexto suficiente para encontrar causas sin exponer datos ni pagar telemetría que nadie usa.