# Observabilidad con OpenTelemetry, Prometheus y Grafana

**Categoría:** DevOps y cloud · **Nivel:** Intermedio · **Lectura:** 13 min
**Publicada:** 2026-07-27 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/devops-cloud/observabilidad-con-opentelemetry-prometheus-y-grafana/

## Respuesta rápida

**OpenTelemetry** es «un marco y conjunto de herramientas de observabilidad» para «la generación, exportación y recolección de datos de telemetría como trazas, métricas y registros», y su documentación aclara que **no es un backend de observabilidad**: no almacena ni grafica. **Prometheus** es «un kit de herramientas de monitoreo y alertado de sistemas, de código abierto» que guarda métricas como **series temporales** con etiquetas de clave y valor, y las consulta con **PromQL**. **Grafana** «te permite consultar, visualizar, alertar y explorar tus métricas, registros y trazas donde sea que estén almacenados». Es decir: OpenTelemetry **produce**, Prometheus **guarda** métricas, Grafana **pregunta**.

## Monitorear no es observar

**Monitorear** es vigilar indicadores decididos de antemano: uso de procesador, memoria, disponibilidad. **Observar** es tener suficiente telemetría como para responder preguntas que nadie anticipó, del tipo «¿por qué esta operación tarda más solo para este cliente, solo desde ayer y solo cuando pasa por el segundo servicio?».

La diferencia no está en la herramienta sino en el **detalle y el contexto** que lleva cada dato. Un tablero con cinco gráficos de promedios no permite reconstruir un caso particular.

> **La prueba honesta:** tomá el último incidente y preguntate si la telemetría existente alcanzaba para explicarlo, o si hubo que agregar registros y esperar a que se repita. La medida de éxito no es la cantidad de tableros, sino cuántas veces hizo falta desplegar código nuevo para entender una falla.

## Las tres señales

| Señal | Qué es | Qué pregunta responde |
|---|---|---|
| **Métricas** | Números agregados a lo largo del tiempo, con etiquetas | «¿Qué está pasando y a qué escala?» |
| **Trazas** | El recorrido de una operación a través de varios servicios | «¿Dónde se fue el tiempo?» |
| **Registros** | Eventos con texto y contexto, en un momento puntual | «¿Qué dijo el sistema exactamente ahí?» |

El orden durante un incidente casi siempre es el mismo: una **métrica** avisa que algo cambió, una **traza** señala en qué servicio, y un **registro** explica qué pasó. Cuando falta una de las tres, la investigación se detiene en ese eslabón.

## OpenTelemetry: qué es y qué no

> «OpenTelemetry no es un backend de observabilidad en sí mismo.»

El proyecto es «de código abierto, además de neutral respecto de proveedores y herramientas, lo que significa que puede usarse con una gran variedad de backends de observabilidad, incluidas herramientas de código abierto como Jaeger y Prometheus, así como ofertas comerciales». La consecuencia práctica: **la instrumentación deja de ser una decisión irreversible**. Cambiar de destino es cambiar la configuración del exportador, no reescribir la aplicación.

Es un proyecto de la **CNCF**, nacido de la fusión de OpenTracing y OpenCensus.

## El recolector y las convenciones

El **recolector** es un proceso intermedio que recibe la telemetría, la procesa y la reenvía. Resuelve varios problemas de una vez: la aplicación exporta a un solo lugar; se puede muestrear, filtrar o anonimizar antes de que los datos salgan; y cambiar de proveedor se hace en un archivo de configuración.

Las **convenciones semánticas** son los nombres estandarizados de los atributos. Sin ellas, cada equipo inventa sus nombres y la telemetría queda agregada pero no comparable.

```yaml
# Forma de la configuración de un recolector: recibir, procesar, exportar
receivers:
  otlp:                        # el protocolo propio de OpenTelemetry
    protocols: { grpc: {}, http: {} }

processors:
  batch: {}                    # agrupa antes de enviar: menos viajes
  memory_limiter: {}           # evita que el recolector se coma el nodo

exporters:
  prometheus: {}               # métricas para Prometheus
  otlp/trazas: {}              # trazas al backend que sea

service:
  pipelines:
    metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
    traces:  { receivers: [otlp], processors: [batch], exporters: [otlp/trazas] }
```

## Prometheus y su modelo

**Prometheus** es «un kit de herramientas de monitoreo y alertado de sistemas, de código abierto», construido en SoundCloud en 2012, que «se unió a la Cloud Native Computing Foundation en 2016 como el segundo proyecto alojado, después de Kubernetes».

«Recolecta y almacena sus métricas como datos de series temporales, es decir, la información de la métrica se guarda con la marca de tiempo en la que fue registrada, junto con pares opcionales de clave y valor llamados **etiquetas**.» Esa dimensionalidad se explota con **PromQL**.

- **Extrae, no recibe.** El servidor consulta por HTTP con la frecuencia que él decide. Distingue «el servicio no responde» de «el servicio no tiene nada que informar». Para trabajos de corta duración admite empujar métricas «a través de una pasarela intermedia».
- **Los nodos son autónomos.** «Los nodos servidor individuales funcionan de forma autónoma, sin depender de almacenamiento distribuido.» La meta declarada es «ser el sistema al que acudís durante una interrupción».

> **Dónde no sirve, según su documentación:** «Si necesitás 100 % de exactitud, como para facturación por solicitud, Prometheus no es una buena opción, porque los datos recolectados probablemente no sean lo bastante detallados y completos.» Es para diagnosticar, no para contabilizar.

## Grafana: la capa de preguntas

Grafana «te permite consultar, visualizar, alertar y explorar tus métricas, registros y trazas donde sea que estén almacenados». No guarda los datos: se conecta a donde ya están.

De sus cuatro funciones, la que suele desaprovecharse es **explorar**: la consulta improvisada durante un incidente. Los tableros predefinidos sirven para lo que se anticipó; la exploración responde lo que no se anticipó.

En 2025 se reportó que [más de 46.000 instancias de Grafana estaban expuestas a una vulnerabilidad crítica](https://blog.underc0de.org/cve-2025-4123-mas-de-46000-instancias-de-grafana-expuestas-a-vulnerabilidad-critica/). La herramienta que muestra el estado de todo el sistema es un objetivo valioso.

## La trampa de la cardinalidad

**Cada combinación distinta de valores de etiquetas crea una serie temporal propia.**

```text
# ✗ Cada usuario crea una serie nueva. Con 200.000 usuarios, 200.000 series.
solicitudes_total{servicio="pagos", usuario_id="48219", ruta="/cobro/48219"}

# ✓ Dimensiones acotadas y previsibles: unas pocas decenas de series.
solicitudes_total{servicio="pagos", entorno="produccion", ruta="/cobro/:id", codigo="500"}
```

**Las etiquetas son para dimensiones acotadas** —servicio, entorno, código de estado, región— y todo lo que sea **único por operación** va a trazas o registros. La ruta se normaliza: `/cobro/:id` y no la ruta con el número dentro.

## Qué alertar y qué no

| En lugar de alertar por… | Alertar por… | Por qué |
|---|---|---|
| Uso alto de procesador | Latencia por encima del umbral acordado | El procesador alto puede ser trabajo normal |
| Un contenedor que se reinició | Porcentaje de errores sostenido | Un reinicio aislado es lo que el sistema debe manejar solo |
| Disco al 80 % | Proyección de disco lleno en menos de X horas | Un umbral fijo avisa tarde o avisa siempre |
| Cada excepción registrada | Aumento anómalo en la tasa de excepciones | Las excepciones sueltas son ruido; el cambio de tasa es señal |

**Si una alerta suena y la respuesta correcta es no hacer nada, hay que borrarla.**

## Errores frecuentes

- **Empezar por los tableros.** El tablero es la respuesta, no el punto de partida.
- **Identificadores únicos como etiquetas de métrica.**
- **Mirar solo promedios.** Un promedio bueno esconde que el 5 % tarda diez segundos.
- **Instrumentar con una biblioteca propietaria.**
- **No usar convenciones semánticas.**
- **Registrar datos personales o secretos.** La telemetría también es un almacén de datos.
- **Alertar sobre causas y no sobre síntomas.**
- **Dejar Grafana expuesta y sin actualizar.**

## Preguntas frecuentes

**¿Qué diferencia hay entre monitorear y observar?**
Monitorear es vigilar indicadores decididos de antemano; observar es tener suficiente telemetría para responder preguntas que no se anticiparon. La diferencia está en el detalle: si la telemetría no lleva el contexto de cada operación, no hay forma de reconstruir un caso particular.

**¿Qué es OpenTelemetry y qué no es?**
Un marco de generación, exportación y recolección de telemetría. No es un backend: no almacena ni grafica, y eso es el diseño, no una carencia.

**¿Por qué Prometheus consulta en lugar de recibir?**
Porque el modelo de extracción le permite decidir la frecuencia y distinguir «no responde» de «no tiene nada que informar». Para trabajos de corta duración existe la pasarela intermedia.

**¿Cuándo no conviene Prometheus?**
Cuando se necesita 100 % de exactitud, como en facturación por solicitud. Su propia documentación lo aclara.

**¿Qué es el problema de la cardinalidad?**
Cada combinación de valores de etiquetas crea una serie temporal. Un identificador de usuario o de solicitud como etiqueta dispara el consumo de memoria hasta tumbar el servidor.

**¿Sobre qué conviene alertar?**
Sobre síntomas que afectan a quien usa el sistema, no sobre causas intermedias. Si la respuesta correcta a una alerta es no hacer nada, hay que borrarla.

## Fuentes

Fecha de consulta: 27 de julio de 2026.

**Aportes de la comunidad Underc0de**

1. Underc0de, blog. [CVE-2025-4123: más de 46.000 instancias de Grafana expuestas a vulnerabilidad crítica](https://blog.underc0de.org/cve-2025-4123-mas-de-46000-instancias-de-grafana-expuestas-a-vulnerabilidad-critica/), 15 de junio de 2025.
2. Underc0de, foro. [Sección GNU/Linux](https://underc0de.org/foro/gnulinux/).

**Documentación oficial**

3. OpenTelemetry, CNCF. [What is OpenTelemetry?](https://opentelemetry.io/docs/what-is-opentelemetry/).
4. OpenTelemetry. [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/).
5. Prometheus. [Overview](https://prometheus.io/docs/introduction/overview/).
6. Grafana Labs. [Introduction to Grafana](https://grafana.com/docs/grafana/latest/introduction/).

## Guías relacionadas

- [Platform Engineering e Internal Developer Platforms](../platform-engineering-e-internal-developer-platforms/index.md)
- [GitOps con Kubernetes y Argo CD](../gitops-con-kubernetes-y-argo-cd/index.md)
- [Pruebas de rendimiento con k6 y Grafana](../../testing/pruebas-de-rendimiento-con-k6-y-grafana/index.md)
- [Índice de DevOps y cloud](../index.md)