Dashboard de Observabilidad con OpenTelemetry y Grafana

La observabilidad se ha convertido en un pilar fundamental para cualquier equipo de operaciones o desarrollo que gestione sistemas en producción. Ya no basta con saber si un servicio está caído; necesitamos entender por qué, en qué punto exacto y cómo está afectando al resto de la arquitectura. Aquí es donde entra en juego la combinación de OpenTelemetry como estándar de instrumentación y Grafana como plataforma de visualización unificada. En este artículo, exploraremos cómo construir un Dashboard de Observabilidad que consolide trazas, métricas y logs, eliminando silos de datos y proporcionando una visión holística de tu infraestructura.

¿Por qué OpenTelemetry y no otro estándar?

OpenTelemetry se ha convertido en el estándar de facto para la instrumentación de aplicaciones. Su principal ventaja es que unifica la recolección de trazas, métricas y logs bajo un mismo protocolo (OTLP), evitando la necesidad de múltiples agentes propietarios.

• Vendor-neutral: Puedes cambiar de backend (Prometheus, Jaeger, SigNoz, etc.) sin modificar el código de tu aplicación.
• Amplio soporte: SDKs para Python, Go, Java, .NET, Node.js, Rust, etc.
• Contexto de propagación: Permite seguir una petición a través de microservicios, incluso si usan diferentes lenguajes.

Al integrar OpenTelemetry con Grafana, logramos que los datos de observabilidad fluyan desde la aplicación hasta un panel interactivo en tiempo real, sin depender de soluciones cerradas.

Arquitectura típica del pipeline de observabilidad

Para construir un dashboard efectivo, necesitas entender el flujo de datos:

1. Instrumentación: El código de tu aplicación exporta señales (trazas, métricas, logs) mediante el SDK de OpenTelemetry.
2. Recolector (OpenTelemetry Collector): Un agente ligero que recibe, procesa y enruta los datos. Es fundamental para filtrar, muestrear o enriquecer la información antes de enviarla al backend.
3. Backend de almacenamiento: Aquí se guardan los datos. Las opciones más comunes son:
   • Prometheus para métricas.
   • Tempo para trazas (específico de Grafana).
   • Loki para logs.
4. Visualización: Grafana consulta estos backends y los presenta en dashboards unificados.

[INFO] Aunque Prometheus es el backend de métricas más popular, Grafana también soporta Graphite, InfluxDB o incluso bases de datos SQL. La clave es que el OpenTelemetry Collector pueda hablar con ellos mediante exporters.

Configuración del OpenTelemetry Collector

El Collector es el cerebro de la operación. A continuación, un ejemplo de configuración básica (otel-collector-config.yaml) para recibir datos OTLP y enviar métricas a Prometheus y trazas a Tempo.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
    namespace: "myapp"
  otlp:
    endpoint: "tempo:4317"  # Asumiendo que Tempo corre en otro contenedor
    tls:
      insecure: true

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Lanza el collector con Docker:

docker run -d --name otel-collector \
  -v $(pwd)/otel-collector-config.yaml:/etc/otel-collector-config.yaml \
  -p 4317:4317 -p 4318:4318 -p 8889:8889 \
  otel/opentelemetry-collector-contrib:latest \
  --config=/etc/otel-collector-config.yaml

Instrumentando una aplicación de ejemplo

Supongamos que tienes una API en Python usando Flask. Con OpenTelemetry, añadir trazas y métricas es casi trivial.

from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry import metrics
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader

# Configurar trazas
trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://localhost:4317", insecure=True))
)

# Configurar métricas
reader = PeriodicExportingMetricReader(OTLPMetricExporter(endpoint="http://localhost:4317", insecure=True))
metrics.set_meter_provider(MeterProvider(metric_readers=[reader]))

# Instrumentar Flask
app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)

@app.route("/api/items")
def get_items():
    return {"items": ["a", "b", "c"]}

if __name__ == "__main__":
    app.run(port=5000)

[TIP] Si usas frameworks como Django, FastAPI o Express.js, los instrumentadores de OpenTelemetry son igual de sencillos. Revisa la documentación oficial para cada lenguaje.

Construyendo el Dashboard en Grafana

Una vez que los datos fluyen hacia Prometheus y Tempo, es hora de diseñar el panel de control. Un buen dashboard de observabilidad debe responder a tres preguntas clave:

• ¿Qué está pasando ahora? (Métricas en tiempo real)
• ¿Qué pasó exactamente? (Trazas distribuidas)
• ¿Por qué pasó? (Logs, aunque no los cubriremos en detalle aquí)

Panel de Métricas (Prometheus)

Crea un panel con consultas a Prometheus. Por ejemplo, para monitorizar la latencia de peticiones:

rate(http_server_duration_milliseconds_sum[5m]) / rate(http_server_duration_milliseconds_count[5m])

Este panel te mostrará la latencia media de los endpoints.

Agrega también:

• Tasa de errores: rate(http_server_duration_milliseconds_count{status_code=~"5.."}[5m])
• Carga de CPU por servicio: rate(process_cpu_seconds_total[1m])

Panel de Trazas (Tempo)

Grafana permite enlazar directamente desde una métrica (por ejemplo, un pico de latencia) a las trazas asociadas en Tempo. Configura una variable de plantilla en el dashboard para filtrar por service.name y http.method.

1. Añade una variable $service de tipo query: label_values(up, service_name)
2. Crea un panel con una consulta a Tempo: {service.name="$service"}
3. Usa el visualizador de Trace de Grafana para mostrar la cascada de spans.

Cuando veas un pico de latencia, haz clic en el punto y selecciona "View trace". Te llevará directamente al span donde se produjo el cuello de botella.

Panel de Servicios Críticos (Red de Dependencias)

Una de las visualizaciones más potentes es el Graph de Grafana, que usando datos de Tempo puede mostrar la topología de tus microservicios. Cada nodo es un servicio, cada arista una llamada. El grosor de la arista indica la frecuencia, y el color la latencia o tasa de error.

Para ello, usa la fuente de datos Tempo y selecciona la consulta search con un rango de tiempo. Luego aplica el panel de tipo Node Graph.

[WARNING] El Node Graph puede ser intensivo en recursos si tienes cientos de servicios. Aplica filtros por namespace o servicio raíz para evitar sobrecargar el navegador.

Mejores prácticas para tu dashboard

• Jerarquía de paneles: Coloca los paneles más críticos (latencia global, tasa de errores) arriba. Deja los detalles (trazas individuales, distribuciones) en la parte inferior.
• Variables dinámicas: Usa variables de Grafana para cambiar entre entornos (producción, staging), servicios o regiones.
• Alertas integradas: No solo visualices, configura alertas en Grafana que se activen cuando una métrica supere un umbral. Enlaza la alerta con un panel de trazas para un diagnóstico rápido.
• Uso de annotations: Marca despliegues o cambios de configuración en el timeline del dashboard. Así podrás correlacionar picos de latencia con releases.

Conclusión

La combinación de OpenTelemetry y Grafana ofrece una solución de observabilidad completa, abierta y escalable. Al unificar trazas y métricas en un solo dashboard, los equipos pueden pasar de "algo está mal" a "el problema está en el servicio de pagos, en la llamada a la base de datos, con una latencia de 2 segundos" en cuestión de segundos. La inversión en instrumentar tu código con OpenTelemetry se amortiza rápidamente cuando reduces el tiempo medio de resolución (MTTR) de incidentes.

Empieza por instrumentar un servicio pequeño, configura el Collector y construye tu primer dashboard con métricas y trazas. Verás cómo la visibilidad que ganas transforma la forma en que operas tu infraestructura.