Pilares de la Observabilidad | Métricas Logs y Traces

Cuando una solicitud tarda 5 segundos en responder, tienes tres preguntas fundamentales: cuándo comenzó el problema, dónde está el cuello de botella y qué causó la falla. Las métricas detectan cuándo algo está roto a través de anomalías en la línea de tiempo. Los traces muestran dónde y cómo viajó la solicitud a través de servicios distribuidos. Los logs diagnostican qué sucedió en detalle. Juntos, forman la base de la observabilidad moderna.

Los sistemas distribuidos generan datos en múltiples capas, cada una respondiendo a una pregunta diferente del flujo de depuración. Aislar un solo pilar limita severamente la capacidad de investigación. La correlación entre métricas, logs y traces es la clave para un diagnóstico eficaz en arquitecturas modernas.

¿Qué son los Tres Pilares de la Observabilidad?

Los tres pilares de la observabilidad son métricas, logs y traces. Las métricas son valores numéricos agregados a lo largo del tiempo. Los logs son registros de eventos discretos con marcas de tiempo. Los traces rastrean el camino de las solicitudes a través de sistemas distribuidos. Juntos, estos pilares permiten investigar problemas complejos correlacionando diferentes tipos de datos.

El concepto de los tres pilares fue popularizado por la comunidad de observabilidad a partir de 2017, con contribuciones significativas de ingenieros como Charity Majors, como una forma de estructurar la telemetría necesaria para entender sistemas distribuidos. Cada pilar captura una dimensión diferente de la realidad operativa del sistema, y la correlación entre ellos crea una visión completa.

Por Qué los Tres Pilares son Complementarios

Ningún pilar aislado es suficiente para la investigación de problemas en sistemas modernos. La correlación entre métricas, logs y traces crea una observabilidad verdadera.

Flujo de investigación SRE típico:

1. Las métricas detectan la anomalía: “Latencia P95 superó el SLO a las 14:32”
2. Los traces localizan el cuello de botella: “El servicio de pago tardó 1,8s en la validación de base de datos”
3. Los logs diagnostican la causa: “Stack trace de timeout de conexión con la base de datos”

Aisladamente, cada pilar ofrece una visión parcial. Correlacionados, forman un sistema completo de investigación.

Métricas

Las métricas son valores numéricos agregados a lo largo del tiempo, que representan el estado del sistema en formato de series temporales. Responden preguntas cuantitativas sobre el comportamiento del sistema: “¿cuál es la tasa de error actual?”, “¿la latencia está dentro del SLO?”, “¿cuántas solicitudes por segundo estamos procesando?”.

Características clave:

• Agregación: Los datos se resumen en promedios, sumas, percentiles
• Timestamped: Cada punto tiene una marca de tiempo precisa
• Baja cardinalidad: Pocos valores únicos por dimensión de etiqueta
• Compresibles: Ocupan poco espacio de almacenamiento
• Consulta rápida: Operaciones matemáticas en tiempo real

Tipos de Métricas

Counters (Contadores) son valores que solo aumentan con el tiempo, contando eventos acumulativos.

• Total de solicitudes HTTP procesadas
• Total de errores ocurridos
• Bytes transferidos acumulados

Casos de uso: Calcular tasas (requests per second), frecuencia de eventos, throughput.

Gauges (Indicadores) son valores que pueden subir o bajar, representando un estado momentáneo.

• Uso de CPU en porcentaje
• Memoria disponible en MB
• Conexiones activas en el momento
• Tamaño de cola actual

Casos de uso: Monitorear capacidad, utilización de recursos, estado actual del sistema.

Histograms (Histogramas) agrupan valores en buckets predefinidos, permitiendo calcular distribución y percentiles.

• Latencia de solicitudes (P50, P95, P99)
• Tamaño de payloads
• Tiempo de procesamiento

Casos de uso: SLIs de rendimiento, entender distribución de valores, detectar outliers.

Summaries (Resúmenes) son similares a histograms, pero calculan percentiles en el lado del cliente antes de enviar.

• Request duration percentiles calculados localmente
• Response size percentiles

Casos de uso: Percentiles de alta precisión cuando no quieres depender de buckets predefinidos.

Golden Signals

Las “golden signals” de Google SRE son las 4 métricas más importantes para cualquier sistema:

1. Latencia: Tiempo para responder solicitudes
2. Tráfico: Volumen de solicitudes (requests per second)
3. Errores: Tasa de solicitudes con error
4. Saturación: Qué tan “lleno” está el sistema (CPU, memoria, conexiones)

Estas métricas forman la base para dashboards de salud y alertas de SLOs.

Explosión de Cardinalidad en Métricas

El mayor desafío técnico en los sistemas de métricas es la explosión de cardinalidad — el crecimiento del número de series temporales cuando se añaden dimensiones con muchos valores únicos.

En sistemas como Prometheus, el número total de series temporales activas (S_total) depende exclusivamente del producto cartesiano de las dimensiones de metadatos (labels):

S_total = ∏(i=1 to n) |C_i|

Donde |C_i| es el número de valores únicos para cada dimensión de label.

Ejemplo práctico: Si tienes 10 endpoints (|C_1| = 10), 5 métodos HTTP (|C_2| = 5), y 3 entornos (|C_3| = 3), el número de series es 10 × 5 × 3 = 150.

Importante: El volumen de solicitudes (V) no afecta el número de series. Si un solo usuario hace un millón de solicitudes idénticas con los mismos labels, el sistema generará solo una única serie temporal. El volumen solo actualiza los valores de los contadores y gauges existentes.

Mitigaciones para cardinalidad alta:

• Limitar el número de labels por métrica (ej: máximo 10)
• Usar agregación top-K para mantener solo los K valores más frecuentes
• Pre-agregar datos de alta cardinalidad antes de exportar
• Mover datos de alta cardinalidad (user_id, request_id) a logs y traces

Consecuencia: Añadir un label como user_id con 1 millón de valores únicos crearía 1 millón de series temporales — generalmente inviable.

Logs

Los logs son registros inmutables con marca de tiempo de eventos discretos que ocurrieron en el sistema. Cada entrada de log captura un momento específico con contexto detallado, respondiendo preguntas como “¿qué pasó exactamente a las 14:32?” y “¿cuál fue el stack trace del error?”.

Características clave:

• Inmutables: Una vez escritos, no se pueden modificar
• Timestamped: Cada entrada tiene marca de tiempo precisa (milisegundos)
• Alta cardinalidad: Pueden contener IDs únicos, mensajes específicos
• Contexto rico: Incluyen metadatos, stack traces, datos del evento
• Auditables: Forman trails para cumplimiento e investigación

Estructura de un Log

Log no estructurado (difícil de parsear):

[2026-06-01 14:32:15] ERROR Falló el pago para el usuario 789: timeout

Log estructurado (fácil de buscar y correlacionar):

{
  "timestamp": "2026-06-01T14:32:15.123Z",
  "level": "ERROR",
  "service": "payment-api",
  "trace_id": "abc123def456",
  "span_id": "span456",
  "user_id": "user_789",
  "message": "Error al procesar el pago",
  "error": "connection timeout",
  "stack_trace": "java.net.ConnectException...",
  "duration_ms": 5432
}

Log Levels (Niveles de Severidad)

• DEBUG: Información detallada para depuración durante el desarrollo
• INFO: Eventos informativos de negocio (request received, order created)
• WARN: Condiciones potencialmente problemáticas, pero no errores
• ERROR: Errores que no interrumpen la operación del sistema
• FATAL: Errores críticos que interrumpen la operación

Mejor práctica: Usa los niveles de forma consistente. DEBUG en desarrollo, INFO/WARN/ERROR en producción.

Structured Logging

Los logs estructurados usan un formato de datos estructurado (JSON, protobuf) en lugar de texto libre. Esto permite:

• Consultas precisas: Buscar por campo específico (level: ERROR AND service: payment)
• Correlación automática: Cruzar trace_id entre logs y traces
• Parsing eficiente: Las herramientas procesan automáticamente
• Integración con SIEM: Splunk, Datadog, Elasticsearch entienden nativamente

Beneficios prácticos:

• Reduce el tiempo de depuración de horas a minutos
• Permite dashboards dinámicos basados en cualquier campo
• Facilita el cumplimiento normativo (PCI-DSS, GDPR exigen trails auditables)

Correlation IDs

Incluir IDs de correlación en logs permite rastrear solicitudes a través de múltiples servicios y entradas de log:

{
  "trace_id": "abc123def456",
  "span_id": "span456",
  "parent_span_id": "span123",
  "user_id": "user_789",
  "request_id": "req999",
  ...
}

Estos IDs conectan logs, traces y métricas, creando una visión unificada del evento.

Context Enrichment

Añadir contexto enriquece los logs para una depuración más eficiente:

• User context: user_id, session_id, tenant_id, account_type
• Request context: request_id, trace_id, http_method, path, query_params
• System context: host, service, version, environment, region
• Business context: order_id, cart_id, transaction_id, payment_method

Cuanto más contexto, más rápida la investigación.

Traces (Rastreo Distribuido)

Los traces representan el camino completo de una solicitud a través de múltiples servicios en un sistema distribuido. Conectan eventos de diferentes sistemas en un recorrido unificado, respondiendo preguntas como “¿por qué esta solicitud tardó 2 segundos?” y “¿qué servicios fueron llamados?”.

Características clave:

• End-to-end: Del inicio al fin de una solicitud
• Cross-service: Atraviesa múltiples servicios, bases de datos, cachés
• Causal: Muestra relación de causa y efecto entre operaciones
• Temporal: Cada paso tiene marca de tiempo y duración precisas

Trace ID y Span ID

Trace ID es el identificador único para una solicitud completa, compartido entre todos los servicios involucrados. Permite agrupar todos los eventos de un solo recorrido.

Span ID es el identificador único para cada operación individual dentro del trace. Cada span representa una unidad de trabajo.

Parent Span ID conecta spans en un árbol de dependencias, mostrando la jerarquía de llamadas.

Estructura de un trace:

Trace: abc123def456 [duration: 50ms]
├── Span: span001 (API Gateway) [0ms - 50ms]
│   ├── Span: span002 (Auth Service) [10ms - 25ms]
│   └── Span: span003 (Payment Service) [30ms - 45ms]
│       ├── Span: span004 (Database Query) [35ms - 38ms]
│       └── Span: span005 (Cache Lookup) [40ms - 42ms]

Context Propagation

La propagación de contexto es el mecanismo de pasar trace ID, span ID y otros metadatos entre servicios para conectar spans en un recorrido unificado.

Mecanismos de propagación:

• HTTP Headers: traceparent, tracestate (estándar W3C Trace Context)
• gRPC Metadata: Clave-valor en el metadata del RPC
• Message Headers: Headers en sistemas de mensajería (Kafka, RabbitMQ, SQS)

Ejemplo W3C Trace Context:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
tracestate: vendor=value

El estándar W3C Trace Context garantiza la interoperabilidad entre sistemas y herramientas de diferentes proveedores.

Sampling (Muestreo)

Recolectar el 100% de los traces es inviable para sistemas de alto volumen. El muestreo reduce el costo de almacenamiento y procesamiento.

Tipos de sampling:

• Head-based sampling: Decisión al inicio del trace (más eficiente, puede perder traces de errores)
• Tail-based sampling: Decisión al final del trace (más inteligente, captura errores y latencia alta)
• Adaptive sampling: Ajusta la tasa dinámicamente según el volumen y presupuesto

Tasas típicas de muestreo:

• 0.1% - 1% para sistemas de alto volumen (10k+ RPS)
• 10% - 50% para sistemas medios
• 100% para sistemas críticos o de bajo volumen

Consejo práctico: Captura siempre el 100% de los traces con error y latencia alta, incluso en sistemas de alto volumen.

Casos de Uso para Traces

• Identificar cuellos de botella de latencia (¿qué servicio está lento?)
• Visualizar dependencias entre servicios
• Depurar fallos en cascada (el servicio A falló porque el servicio B está caído)
• Optimizar caminos críticos de rendimiento
• Entender el flujo de datos en arquitecturas de microservicios

La Sinergia de los Tres Pilares

La correlación entre métricas, logs y traces a través de IDs compartidos es lo que transforma datos aislados en observabilidad verdadera.

Flujo de Investigación Correlacionado

Escenario: La latencia P95 aumentó de 100ms a 2 segundos.

1. Las métricas detectan la anomalía: El dashboard muestra latencia P95 > SLO a las 14:32
2. Los traces localizan el servicio: El Trace ID abc123 muestra que el Payment Service tardó 1,8s
3. Los logs diagnostican la causa: Los logs con trace_id abc123 revelan timeout de conexión con la base de datos

Correlación vía trace_id:

// Métrica agregada
{ "metric": "latency_p95", "value": 2000, "service": "payment", "timestamp": "..." }

// Log correlacionado
{ "trace_id": "abc123", "level": "ERROR", "message": "timeout", "service": "payment" }

// Trace correlacionado
{ "trace_id": "abc123", "spans": [...], "duration_ms": 2000, "service": "payment" }

Cuándo Usar Cada Pilar

Más Allá de los Tres Pilares: OpenTelemetry

El modelo de los tres pilares está evolucionando hacia señales correlacionadas a través de OpenTelemetry, el estándar abierto de la CNCF para telemetría unificada.

Problemas de los Pilares Aislados

• Logs, métricas y traces en herramientas separadas
• Correlación manual entre sistemas
• Duplicación de instrumentación de código
• Vendor lock-in con herramientas propietarias

Solución OpenTelemetry

OpenTelemetry unifica la recopilación de los tres pilares en una sola API y SDK:

• Traces API: Recopilar traces y spans con context propagation
• Metrics API: Recopilar métricas con instrumentación automática
• Logs API: Recopilar logs estructurados (en desarrollo activo)
• Baggage: Contexto compartido entre todas las señales

Beneficios:

• Una instrumentación para todas las señales: No duplicar código
• Correlación nativa: Logs, métricas y traces conectados automáticamente
• Neutral para proveedores: Funciona con cualquier backend (Prometheus, Jaeger, Datadog, etc.)
• Elimina el vendor lock-in: La misma instrumentación funciona localmente, en la nube o en runtimes distribuidos compatibles con WinterCG

Estado de OpenTelemetry:

• Tracing: Generally Available (GA)
• Metrics: Generally Available (GA)
• Logs: En desarrollo activo (beta)

Estándar W3C Trace Context

El estándar W3C Trace Context garantiza la interoperabilidad entre sistemas:

• Formato estandarizado para traceparent y tracestate
• Soportado por todos los frameworks y herramientas principales
• Permite propagar contexto entre sistemas heterogéneos

Esto significa que puedes usar OpenTelemetry para instrumentar tu código y elegir cualquier backend posteriormente sin reescribir la instrumentación.

Recopilación de Telemetría en Arquitecturas Distribuidas

En sistemas distribuidos globalmente, recopilar métricas, logs y traces de múltiples regiones introduce latencia que puede dificultar la respuesta rápida a incidentes.

Procesamiento Distribuido de Telemetría

Procesar datos de telemetría directamente en la infraestructura distribuida ofrece ventajas significativas:

• Recopilación con latencia ultra baja: Eventos disponibles en menos de 60 segundos
• Streaming unificado: Logs, métricas y eventos en un solo flujo
• Correlación automática: Trace IDs y request IDs conectados nativamente
• Múltiples destinos: Splunk, Datadog, BigQuery, S3, Azure Monitor

Protocolos de Transporte Modernos

La ingesta y streaming de telemetría depende críticamente de los protocolos de transporte:

Limitaciones de TCP:

• Head-of-line blocking: La pérdida de paquetes paraliza toda la conexión
• Handshake overhead: Three-way handshake añade latencia
• Congestion control agresivo: Backoff excesivo en redes con pérdida

Ventajas de QUIC/HTTP3:

El protocolo QUIC (Quick UDP Internet Connections), base de HTTP/3, resuelve estas limitaciones:

• Sin head-of-line blocking: Streams independientes no se afectan entre sí
• 0-RTT connection resumption: Reanudar conexiones instantáneamente
• Multiplexación nativa: Múltiples streams en una sola conexión
• Cambio de red seamless: Migración de IP sin ruptura de conexión

Impacto práctico: El streaming de logs y eventos vía QUIC/HTTP3 elimina el impacto del head-of-line blocking, garantizando que las métricas en tiempo real y los logs de ciberseguridad lleguen a los destinos analíticos (SIEM) en menos de 60 segundos, incluso bajo condiciones de red inestables.

WebSockets para Latencia Sub-segundo

El soporte nativo de WebSockets permite que los dashboards de monitoreo y los sistemas de telemetría interactiva actualicen datos en tiempo real con latencia de sub-segundo, sin polling HTTP.

Casos de Éxito: Tres Pilares en la Práctica

Netshoes: 385 TB de Logs y Eventos Correlacionados

Netshoes es el mayor e-commerce de estilo de vida deportivo de América Latina, con 54 millones de visitantes únicos por mes.

Uso de los tres pilares:

• Métricas: Monitoreo de latencia, tasas de error, throughput en tiempo real
• Logs: 385 TB de eventos recolectados vía Data Streaming en 6 meses
• Traces: Correlación de solicitudes end-to-end para depuración

Resultados verificados:

• 4 millones de amenazas bloqueadas automáticamente por WAF en el primer semestre de 2020
• 84% del procesamiento transferido a infraestructura distribuida, con 200 mil millones de solicitudes procesadas
• Correlación de logs con métricas de WAF para inteligencia de seguridad

Magalu: 20 TB/mes Correlacionados en Tiempo Real

Magazine Luiza es una de las empresas minoristas más innovadoras de América Latina, con R$ 10 mil millones en ventas digitales en 2021.

Uso de los tres pilares:

• Métricas: Dashboards de disponibilidad y rendimiento para cientos de aplicaciones
• Logs: 20 TB/mes vía Data Streaming enviados a plataformas SIEM
• Traces: Investigación de incidentes cross-service durante eventos críticos

Resultados verificados:

• Millones de amenazas bloqueadas automáticamente
• Alta disponibilidad garantizada durante Black Friday
• Correlación de eventos de WAF con métricas de negocio en tiempo real

Comparativa: Métricas vs Logs vs Traces

Preguntas Frecuentes sobre los Tres Pilares

¿Qué son los tres pilares de la observabilidad?

Los tres pilares son métricas, logs y traces. Las métricas son valores numéricos agregados a lo largo del tiempo (como latencia, tasa de error). Los logs son registros de eventos discretos con marcas de tiempo y contexto detallado. Los traces rastrean el camino de las solicitudes a través de sistemas distribuidos, conectando múltiples servicios en un recorrido unificado.

¿Cuál es la diferencia entre métricas, logs y traces?

Las métricas agregan valores numéricos (ej: latencia media), sin contexto individual de cada evento. Los logs capturan eventos específicos con detalles ricos (ej: stack trace, user_id). Los traces conectan eventos a través de múltiples servicios, mostrando el recorrido completo de una solicitud. Usa métricas para tendencias y alertas, logs para depuración detallada, y traces para entender el flujo en sistemas distribuidos.

¿Cuándo usar métricas, logs o traces?

Usa métricas para dashboards, alertas y análisis de tendencias (ej: latencia P95 > SLO). Usa logs para depuración detallada, auditoría y cumplimiento (ej: quién ejecutó esta acción, cuál fue el error específico). Usa traces para investigar latencia, dependencias y fallos en cascada (ej: qué servicio está lento, cómo se propagó la falla). Idealmente, correlaciona los tres pilares vía trace IDs.

¿Qué es el rastreo distribuido?

El rastreo distribuido sigue las solicitudes a través de múltiples servicios en arquitecturas distribuidas. Cada solicitud recibe un trace ID único compartido entre todos los servicios, y cada operación dentro de ella es un span. Esto permite visualizar el recorrido completo, identificar cuellos de botella de latencia y entender cómo se propagan las fallas entre servicios.

¿Qué son los logs estructurados?

Los logs estructurados usan un formato de datos estructurado (como JSON) en lugar de texto libre. Cada campo tiene un nombre y valor definidos (ej: {"level": "ERROR", "user_id": "123", "message": "timeout"}). Esto permite consultas más rápidas y precisas, correlación automática entre campos, parsing por herramientas de análisis e integración nativa con SIEM.

¿Cómo correlacionar métricas, logs y traces?

Usa IDs de correlación compartidos entre los tres pilares. Incluye trace_id, span_id y request_id en logs y traces. Usa trace IDs para agrupar spans en un recorrido. Las métricas pueden filtrarse por service name y correlacionarse con traces y logs del mismo período. Herramientas como OpenTelemetry facilitan la correlación automática.

¿Qué herramienta es más importante: métricas, logs o traces?

Ninguna es más importante — son complementarias. Las métricas detectan que hay un problema, los logs diagnostican qué sucedió y los traces muestran dónde y cómo sucedió. Los sistemas maduros usan los tres pilares correlacionados vía trace IDs. Comienza con métricas (golden signals), añade logs estructurados e implementa tracing para sistemas distribuidos.

Conclusión

Los tres pilares de la observabilidad — métricas, logs y traces — forman la base para la investigación de problemas en sistemas distribuidos modernos.

Conceptos clave para recordar:

• Las métricas detectan: Responden “cuándo” a través de anomalías en la línea de tiempo
• Los traces localizan: Muestran “dónde” y “cómo” a través del recorrido de solicitudes
• Los logs diagnostican: Explican “qué” sucedió en detalle
• La correlación es esencial: Los trace IDs conectan los tres pilares
• OpenTelemetry unifica: El estándar abierto elimina el vendor lock-in

Próximos pasos recomendados:

Para principiantes:

1. Implementa golden signals: latencia, tráfico, errores, saturación
2. Usa structured logging (JSON) con correlation IDs
3. Comienza con métricas, luego añade logs y traces

Para equipos intermedios:

1. Añade rastreo distribuido en servicios críticos
2. Correlaciona logs y traces vía trace IDs
3. Define SLOs basados en métricas

Para equipos avanzados:

1. Adopta OpenTelemetry para instrumentación unificada
2. Implementa correlación automática entre pilares
3. Usa Data Streaming para análisis en tiempo real

¿Quieres correlacionar métricas, logs y traces en tiempo real con latencia ultra baja? Descubre cómo Data Stream, Real-Time Events y Real-Time Metrics pueden transformar tu visibilidad operacional en una arquitectura distribuida global. Comienza gratis.