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. Los tres son proyectos de la CNCF o de su ecosistema.
Ver índice de contenidos
Monitorear no es observar
Monitorear es vigilar indicadores decididos de antemano: uso de procesador, memoria, disponibilidad. Responde bien las preguntas que alguien anticipó. 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: está en el detalle y el contexto que lleva cada dato. Un tablero con cinco gráficos de promedios no permite reconstruir un caso particular, por bonito que sea. Y ese es el montaje más común: mucha visualización, poca capacidad de responder.
La prueba honesta de un sistema de observabilidad
Tomá el último incidente que tuviste y preguntate: ¿la telemetría existente alcanzaba para explicarlo, o hubo que agregar registros y esperar a que se repita? Si fue lo segundo, el sistema monitorea pero no permite observar. 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
OpenTelemetry maneja tres tipos de señal, y cada una responde una pregunta distinta. Conviene tenerlas separadas en la cabeza porque el reflejo de mucha gente es intentar resolver todo con una sola:
| 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?» Cuántos errores, cuánta latencia, cuántas operaciones |
| Trazas | El recorrido de una operación a través de varios servicios, con el tiempo de cada tramo | «¿Dónde se fue el tiempo?» Cuál de los seis servicios que participaron es el lento |
| Registros | Eventos con texto y contexto, en un momento puntual | «¿Qué dijo el sistema exactamente ahí?» El detalle que ninguna métrica captura |
El orden en que se usan 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ó ahí. Cuando falta una de las tres, la investigación se detiene justo en ese eslabón.
OpenTelemetry: qué es y qué no
La definición oficial: «un marco y conjunto de herramientas de observabilidad diseñado para facilitar la generación, exportación y recolección de datos de telemetría como trazas, métricas y registros». Y a continuación, la aclaración que evita el malentendido más caro: «OpenTelemetry no es un backend de observabilidad en sí mismo».
Esa separación es deliberada y es su mayor aporte. 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 es concreta: la instrumentación deja de ser una decisión irreversible. Si el código está instrumentado con OpenTelemetry, cambiar de destino es cambiar la configuración del exportador, no reescribir la aplicación.
Su objetivo declarado es «hacer fácil la instrumentación de tus aplicaciones y sistemas, independientemente del lenguaje de programación, la infraestructura y los entornos de ejecución». Es un proyecto de la CNCF, nacido de la fusión de dos anteriores, OpenTracing y OpenCensus, lo que explica por qué convergieron en él enfoques que antes competían.
El recolector y las convenciones
Dos piezas del ecosistema hacen más diferencia de lo que su nombre sugiere.
La primera es el recolector: un proceso intermedio que recibe la telemetría, la procesa y la reenvía. Poner uno en el medio resuelve varios problemas de una vez: la aplicación exporta a un solo lugar y no necesita saber cuál es el destino final; se puede muestrear, filtrar o anonimizar antes de que los datos salgan; y cambiar de proveedor o mandar a dos destinos a la vez se hace en un archivo de configuración, sin volver a desplegar los servicios.
La segunda son las convenciones semánticas: los nombres estandarizados de los atributos. Que el método HTTP se llame igual en todos los servicios y en todos los lenguajes parece un detalle, y es lo que permite que un tablero o una consulta funcione para todo el parque en lugar de para un servicio. Sin convenciones, cada equipo inventa sus nombres y la telemetría queda agregada pero no comparable.
# 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 originalmente en SoundCloud en 2012, que «se unió a la Cloud Native Computing Foundation en 2016 como el segundo proyecto alojado, después de Kubernetes».
Su modelo de datos es lo que hay que entender: «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 es lo que después se explota con PromQL, descrito como «un lenguaje de consulta flexible para aprovechar esa dimensionalidad».
Dos características de su diseño sorprenden a quien viene de otros sistemas:
- Extrae, no recibe. El servidor consulta a los servicios por HTTP con la frecuencia que él decide. Eso le permite distinguir «el servicio no responde» de «el servicio no tiene nada que informar», y evita configurar cada aplicación con la dirección del destino. Para trabajos de corta duración que terminan antes de ser consultados, 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.» Eso es una decisión de fiabilidad: la meta declarada es «ser el sistema al que acudís durante una interrupción para diagnosticar problemas rápido», y para eso conviene depender de lo menos posible.
«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 una herramienta para diagnosticar, no para contabilizar. Si falta un dato es aceptable; si no lo es, hace falta otro mecanismo de registro.
Grafana: la capa de preguntas
Según su documentación, Grafana «te permite consultar, visualizar, alertar y explorar tus métricas, registros y trazas donde sea que estén almacenados». La frase importante es la última: Grafana no guarda los datos, se conecta a donde ya están, con un modelo de complementos que abarca bases de series temporales, bases relacionales y no relacionales, sistemas de tickets y herramientas de integración continua.
De sus cuatro funciones, la que suele desaprovecharse es explorar: la consulta improvisada durante un incidente, con la posibilidad de comparar rangos de tiempo y fuentes de datos lado a lado. Los tableros predefinidos sirven para lo que se anticipó; la exploración es lo que responde lo que no se anticipó, que es justamente la definición de observabilidad.
Un detalle operativo que vale mencionar, y que el propio blog de Underc0de documentó: en 2025 se reportó que más de 46.000 instancias de Grafana estaban expuestas a una vulnerabilidad crítica. La herramienta que muestra el estado de todo el sistema es, por eso mismo, un objetivo valioso: conviene tratarla como parte de la superficie de ataque, no como un tablero interno inofensivo.
La trampa de la cardinalidad
Este es el error que tumba servidores de métricas, y aparece con la mejor de las intenciones. En el modelo de Prometheus, cada combinación distinta de valores de etiquetas crea una serie temporal propia. Agregarle a una métrica una etiqueta con el identificador de usuario multiplica las series por la cantidad de usuarios; con el identificador de solicitud, por la cantidad de solicitudes.
# ✗ 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"}La regla es sencilla de recordar: 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, que están diseñados para eso. Fijate también que la ruta se normaliza: /cobro/:id en lugar de la ruta con el número dentro, o cada identificador genera una serie.
Qué alertar y qué no
Un sistema de observabilidad se juzga por sus alertas, y la mayoría falla por exceso: tantas que nadie las mira, y la que importaba pasa desapercibida. El criterio que funciona es alertar sobre síntomas, no sobre causas.
| 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; la latencia la sufre alguien |
| 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 |
Y una prueba que conviene aplicar a cada alerta existente: si suena y la respuesta correcta es no hacer nada, hay que borrarla. Una alerta que no motiva una acción está entrenando al equipo a ignorar el canal donde algún día va a llegar la que sí importa.
Errores frecuentes
- Empezar por los tableros. Primero hay que saber qué preguntas se van a hacer; el tablero es la respuesta, no el punto de partida.
- Identificadores únicos como etiquetas de métrica. La forma más rápida de tumbar el servidor de métricas.
- Mirar solo promedios. Un promedio bueno esconde perfectamente que el 5 % de las operaciones tarda diez segundos.
- Instrumentar con una biblioteca propietaria. Convierte el cambio de proveedor en un proyecto de reescritura.
- No usar convenciones semánticas. Cada equipo con sus nombres, y ninguna consulta sirve para dos servicios.
- Registrar datos personales o secretos. La telemetría también es un almacén de datos, con las mismas obligaciones.
- Alertar sobre causas y no sobre síntomas. Ruido garantizado, y la alerta importante perdida en el medio.
- Dejar Grafana expuesta y sin actualizar. Es la herramienta que ve todo el sistema: tratala como parte de la superficie de ataque.
Preguntas frecuentes
¿Qué diferencia hay entre monitorear y observar?
Monitorear es vigilar un conjunto de indicadores que se decidieron de antemano: uso de procesador, memoria, disponibilidad. Sirve para responder preguntas previstas. Observar es tener suficiente telemetría como para responder preguntas que no se anticiparon, del tipo «¿por qué esta operación tarda más solo para este cliente y solo desde ayer?». La diferencia práctica no está en la herramienta sino 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?
Es «un marco y conjunto de herramientas de observabilidad diseñado para facilitar la generación, exportación y recolección de datos de telemetría como trazas, métricas y registros». Y su documentación aclara lo que no es, que es igual de importante: «OpenTelemetry no es un backend de observabilidad en sí mismo». No almacena ni grafica: genera y exporta. El almacenamiento y la visualización quedan para otras herramientas, y ese es el diseño, no una carencia.
¿Por qué Prometheus consulta en lugar de recibir?
Porque el modelo de extracción por HTTP le da propiedades operativas útiles: el servidor decide la frecuencia, sabe distinguir «el servicio no responde» de «el servicio no tiene nada que informar», y no hay que configurar cada aplicación con la dirección del destino. La documentación aclara que también admite empujar métricas a través de una pasarela intermedia, que es la salida para trabajos de corta duración que terminan antes de que alguien pueda consultarlos.
¿Cuándo no conviene Prometheus?
Su propia documentación lo dice sin vueltas: «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 un sistema pensado para diagnosticar, no para contabilizar. Para facturación, auditoría legal o cualquier caso donde falte un dato sea inaceptable, hace falta otro mecanismo de registro.
¿Qué es el problema de la cardinalidad?
En Prometheus cada combinación distinta de valores de etiquetas crea una serie temporal propia. Si a una métrica se le agrega una etiqueta con el identificador de usuario o de solicitud, la cantidad de series crece con la cantidad de usuarios o de solicitudes, y el consumo de memoria y disco se dispara hasta tumbar el servidor. La regla práctica: las etiquetas son para dimensiones acotadas y previsibles —servicio, entorno, código de estado— y todo lo que sea único por operación va a trazas o registros.
¿Sobre qué conviene alertar?
Sobre síntomas que afectan a quien usa el sistema —errores, latencia alta, operaciones que no se completan— y no sobre causas intermedias como el uso de procesador. Una alerta por uso alto de procesador despierta a alguien cuando tal vez no pasa nada; una alerta por porcentaje de errores despierta a alguien cuando sí pasa. La prueba para decidir si una alerta merece existir es simple: si suena y la respuesta correcta es no hacer nada, hay que borrarla.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, blog. CVE-2025-4123: más de 46.000 instancias de Grafana expuestas a vulnerabilidad crítica, 15 de junio de 2025. El recordatorio de que la herramienta de observabilidad también es superficie de ataque.
- Underc0de, foro. Sección GNU/Linux. Material de la comunidad sobre administración y diagnóstico de servidores.
Documentación oficial
- OpenTelemetry, CNCF. What is OpenTelemetry?. Definición, las tres señales, la neutralidad de proveedor y la aclaración de que no es un backend, citadas textualmente.
- OpenTelemetry. OpenTelemetry Collector. Documentación del recolector y sus tuberías de recepción, procesamiento y exportación.
- Prometheus. Overview. Definición, modelo de datos, características y la sección sobre cuándo no encaja, citadas textualmente.
- Grafana Labs. Introduction to Grafana. Definición de las cuatro funciones y el modelo de fuentes de datos.