Observabilidad Empresarial: Más Allá del Monitoreo Tradicional

Los tres pilares: métricas, logs y trazas distribuidas

Los tres pilares de observabilidad son complementarios, no redundantes. Las métricas dicen que hay un problema (latencia p99 subió a 2 segundos). Los logs dicen qué pasó (error 500 en el endpoint /checkout). Las trazas distribuidas dicen por qué pasó (la query a la base de datos de inventario tardó 1.8 segundos porque no hay índice en la columna product_sku).

La mayoría de las empresas tienen logs. Menos tienen métricas de aplicación (más allá de CPU/memoria). Muy pocas tienen trazas distribuidas correlacionadas. La observabilidad real requiere los tres, correlacionados por trace ID.

OpenTelemetry: el estándar que unifica los tres pilares

OpenTelemetry (OTel) es el proyecto open-source que estandariza la instrumentación de aplicaciones para emitir métricas, logs y trazas en un formato neutro de vendor. La ventaja clave: instrumentas la aplicación una vez y envías los datos a cualquier backend (Grafana, Jaeger, Tempo, Datadog, New Relic) sin cambiar el código.

// Instrumentación automática Node.js con OpenTelemetry SDK
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { PrometheusExporter } from '@opentelemetry/exporter-prometheus';
import { resourceDetectors } from '@opentelemetry/auto-resource-detection';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: 'http://otel-collector:4318/v1/traces',
  }),
  metricReader: new PrometheusExporter({ port: 9090 }),
  instrumentations: [getNodeAutoInstrumentations()],
  resourceDetectors,
});

sdk.start();

La instrumentación automática de Node.js captura trazas de HTTP requests, queries a base de datos (pg, mysql2, mongoose), llamadas a Redis, y cualquier cliente gRPC — sin modificar una sola línea de código de negocio. Las trazas incluyen automáticamente los spans correctos con atributos estándar.

Prometheus: arquitectura de métricas production-grade

Prometheus usa un modelo pull — scrapea los endpoints /metrics de los servicios cada N segundos. Para producción empresarial, el stack correcto es Prometheus + Thanos o Prometheus + VictoriaMetrics para retención de largo plazo y alta disponibilidad.

# PrometheusRule — SLO-based alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: api-slos
  namespace: monitoring
spec:
  groups:
  - name: api.slos
    rules:
    # Tasa de error > 1% durante 5 minutos
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m])) > 0.01
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "API error rate above SLO ({{ $value | humanizePercentage }})"

    # Latencia p99 > 500ms durante 10 minutos
    - alert: HighP99Latency
      expr: |
        histogram_quantile(0.99,
          sum(rate(http_request_duration_seconds_bucket[10m])) by (le)
        ) > 0.5
      for: 10m
      labels:
        severity: warning

Grafana Loki: logs sin el costo de Elasticsearch

Loki es el sistema de logs de Grafana diseñado para integrarse nativamente con Prometheus y Tempo. A diferencia de Elasticsearch, Loki no indexa el contenido de los logs — solo indexa los labels (namespace, pod, app, env). Esto reduce el costo de almacenamiento 10x pero requiere que las queries tengan labels como filtro inicial.

# Promtail config — recolección de logs de Kubernetes con labels automáticos
scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        target_label: app
      - source_labels: [__meta_kubernetes_namespace]
        target_label: namespace
      - source_labels: [__meta_kubernetes_pod_name]
        target_label: pod
    pipeline_stages:
      - json:
          expressions:
            level: level
            msg: message
            trace_id: trace_id   # extraer trace_id para correlación con trazas
      - labels:
          level:
          trace_id:

Grafana Tempo: trazas distribuidas sin costo de Jaeger

Tempo es el backend de trazas distribuidas de Grafana, diseñado para almacenamiento barato (solo object storage: S3, GCS) con búsqueda por trace ID. La integración con Loki es la característica más valiosa: desde un log con trace_id, puedes saltar directamente a la traza distribuida completa de esa request en un solo click.

El stack completo en Kubernetes con kube-prometheus-stack

kube-prometheus-stack (Helm chart) despliega Prometheus Operator, Grafana, Alertmanager, node-exporters y dashboards de Kubernetes preconfigurados en un solo comando. Es el punto de partida correcto para observabilidad en Kubernetes.

helm upgrade --install kube-prometheus-stack \
  prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set grafana.enabled=true \
  --set grafana.adminPassword=${GRAFANA_PASSWORD} \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi