Hace años me tocó meter los datos de una herramienta de monitoreo de red dentro de una plataforma de análisis de registros, en la fusión de dos bancos. No existía una guía. Éramos tres personas probando, rompiendo y volviendo a intentar, hasta que un día empezó a funcionar.
Nadie nos vendió esa integración. La armamos. Y eso significó que también éramos los dueños de arreglarla cada vez que se rompía, de explicarla cuando alguien nuevo llegaba, y de mantenerla cuando una de las dos partes se actualizaba.
Cuento esto porque es exactamente lo que hay que entender del stack abierto de observabilidad: no se compra, se arma. Es una decisión legítima y muchas veces la correcta. Pero armar tiene un costo, y ese costo tiene nombres y apellidos.
🔑 Lo esencial en 20 segundos
- No es una alternativa al software del fabricante: Prometheus ya viene dentro de la capa de gestión que vimos la semana pasada.
- Son tres papeles distintos: quien recoge, quien guarda y quien muestra. Telegraf empuja, Prometheus jala.
- La cardinalidad es la factura: cada serie activa cuesta entre 1 y 3 KiB de memoria, y ahí se decide todo.
- Una sola instancia vive cómoda con 1 a 2 millones de series. Pasados los 5 millones, ya es otro proyecto.
- Y el costo que nunca se cotiza no es el software: es quién lo opera.
Empecemos por lo que ya tienes
En el artículo sobre Mission Control apareció un detalle que casi nadie nota: dentro de la capa de gestión que vende el fabricante vienen Prometheus para métricas y Loki para registros.
Así que la pregunta no es “¿stack abierto o software del fabricante?”. Vas a tener stack abierto de todos modos. La pregunta correcta es cuánto de él vas a operar tú, con qué alcance, y si esa instalación empaquetada te sirve también para lo que el negocio necesita ver.
Casi nunca sirve para lo segundo, por una razón sencilla: el Prometheus que viene dentro está dimensionado para vigilar la fábrica, no para responder las preguntas de tu servicio. Y ahí empieza este artículo.
Tres papeles, y conviene no confundirlos
Todo el mundo dice “el stack de Prometheus” como si fuera una cosa. Son tres funciones separadas, y se pueden cambiar por piezas:
| Papel | Quién lo hace | La decisión que trae |
|---|---|---|
| Recoger | Telegraf, los exportadores, el recolector de OpenTelemetry | ¿Empujar o dejar que te jalen? |
| Guardar | Prometheus y, para el histórico, un almacén aparte | ¿Cuánto tiempo, y a qué costo? |
| Mostrar y alertar | Grafana y el gestor de alertas | ¿Quién mantiene los tableros cuando se van los que los hicieron? |
La diferencia entre las dos formas de recoger vale la pena porque cambia cómo se diseña todo lo demás:
- Telegraf empuja. Es un agente con muchísimos conectores —del orden de doscientos— que recoge de donde le digas y manda los datos hacia donde le digas.
- Prometheus jala. Es un servidor que va a buscar los datos a cada objetivo, con su propia base de datos de series de tiempo, su lenguaje de consulta, su gestor de alertas y su descubrimiento automático de objetivos.
Modelos de recolección y alcance de cada herramienta: comparativa Telegraf contra Prometheus.
En un clúster de IA los dos aparecen: la telemetría fina de las GPUs sale por un exportador que Prometheus recoge —de eso escribí en cómo se observa una GPU de verdad— y las cosas del mundo físico, que son las que tumban proyectos, suelen llegar mejor con un agente que empuja.
La cardinalidad es la factura
Si de este artículo te llevas una sola idea, que sea esta: en el stack abierto no pagas por consultas ni por usuarios. Pagas por cuántas series distintas existen. Y eso no lo decide el proveedor, lo decide tu propio equipo sin darse cuenta.
Los números publicados son bastante consistentes:
Con esos números, una instancia de 16 GB de memoria aguanta unos pocos millones de series activas sin sufrir. Se puede llegar a diez millones o más con hardware grande y discos rápidos, pero solo con disciplina de cardinalidad y de consultas. Y pasando de cinco millones ya hace falta combinar afinación, repartir la carga entre varias instancias y mandar el histórico a un almacén dedicado.
Costo por serie, límites por instancia y umbrales de escalamiento: Prometheus a escala, domar la alta cardinalidad (2026).
Y aquí está la parte que hay que traducir a lenguaje de negocio, porque es la misma trampa que conté en el artículo sobre la factura que se dispara:
La cardinalidad explota por una etiqueta. Alguien decide identificar cada medición con un dato que tiene millones de valores posibles —un identificador de usuario, de trabajo, de petición— y de golpe una métrica se convierte en millones de series. Nadie lo hizo con mala intención. Se hizo porque en el momento parecía útil tener ese detalle.
La forma de contenerlo no es técnica, es de gobierno: decidir qué detalle merece existir como serie propia y qué detalle se agrupa en categorías acotadas. Ese es un criterio de Producto y hay que ponerle dueño, igual que en todo lo demás de esta serie.
La retención son dos relojes, no uno
Otra decisión que la gente toma por omisión. Cuando alguien pregunta “¿cuánto tiempo guardamos?”, casi siempre se responde con un número único, y en realidad hay dos plazos distintos:
| El reloj | Para qué es | Criterio |
|---|---|---|
| Lo que se queda local | Diagnosticar el incidente que está pasando ahora | Corto. Si el histórico vive en otro sitio, con horas basta |
| El histórico | Tendencias, capacidad, cumplimiento, discusiones de contrato | Largo, en almacenamiento barato y con menos resolución |
La práctica recomendada es fijar la retención local en el mínimo que sirva para depurar —quince días es una referencia común— y bajarla a unas pocas horas cuando el histórico ya vive en un almacén aparte. La ganancia no es solo de espacio: con menos datos locales, la instancia reinicia mucho más rápido y sufre menos de memoria. Y el día que se reinicia es justamente el día en que la necesitas.
Los tres caminos para el histórico
Cuando el histórico ya no cabe, hay tres opciones maduras. Las pongo con lo que a mí me importaría al elegir:
| Opción | Su ventaja real | Lo que hay que saber |
|---|---|---|
| Thanos | El camino de menor fricción: deja tu instalación como está y le añade el histórico | Es la opción para meter el pie en el agua sin rehacer nada |
| Mimir | Multiinquilino de verdad, con límites de cardinalidad, de consultas y de ingesta por inquilino | Si vas a rentar capacidad o separar áreas internas, esto es lo que estabas buscando |
| VictoriaMetrics | Otra base de datos desde cero, que acepta los datos de Prometheus y comprime mucho mejor | En pruebas usa cinco veces menos memoria y 1,7 veces menos CPU que Mimir para la misma carga |
Y un dato que a mí me pareció el más útil de todos, porque habla de comportamiento y no de folleto: en una prueba con 5,5 millones de series activas y 360.000 muestras por segundo, la latencia del percentil 99 de Mimir llegó a picos de 47 segundos, mientras VictoriaMetrics se quedó en 20. Y los picos de Mimir coinciden con su ciclo de volcado a disco cada dos horas.
Comparativa de opciones de escalamiento y cifras de la prueba: escalar Prometheus en 2026, Thanos contra Mimir contra VictoriaMetrics y modelos de costo y retención.
Fíjate en lo del ciclo de dos horas, porque es el tipo de cosa que solo se descubre operando: un sistema que se degrada de forma periódica y predecible es distinto de uno que se degrada al azar. El primero se planea. El segundo se sufre. Que un producto tenga un patrón conocido no lo descalifica; te permite decidir con los ojos abiertos.
Y hay una consecuencia económica que conviene decir en voz alta: las dos primeras opciones guardan cada serie única en almacenamiento de objetos, así que una explosión de cardinalidad se traduce directamente en costo de almacenamiento. El problema de gobierno de arriba se convierte en una factura aquí abajo.
Lo que nadie cotiza: quién lo opera
Vuelvo al principio, a las tres personas probando y rompiendo hasta que aquello funcionó.
El stack abierto no tiene costo de licencia y por eso aparece en las propuestas como si fuera gratis. No lo es. Su costo es de gente, y se paga en tres partidas que casi nunca están en la hoja:
- Armarlo. Integrar, dimensionar, decidir la cardinalidad y la retención. Es un proyecto, no una instalación.
- Actualizarlo. Varias piezas con calendarios distintos que tienen que seguir hablándose entre sí.
- Que no dependa de una sola persona. El que armó los tableros se va, y si nadie más los entiende, la herramienta se convierte en un misterio con gráficas.
Esto no es un argumento contra el stack abierto — a mí me gusta y da un control que las plataformas cerradas no dan. Es un argumento a favor de costearlo honestamente. La comparación justa no es “licencia contra cero”. Es licencia contra el tiempo de tu propia gente, y el tiempo de tu gente es lo más escaso que tienes.
Qué preguntar antes de decidir
| La pregunta | Por qué |
|---|---|
| ¿Cuántas series activas vamos a tener, y quién revisa ese número? | Es la unidad de costo real. Si nadie lo vigila, crece solo |
| ¿Qué etiquetas van a existir, y cuáles están prohibidas? | Un identificador único como etiqueta convierte una métrica en millones de series |
| ¿Cuánto se guarda local y cuánto en el histórico? | Son dos relojes. Confundirlos encarece y hace lento el arranque |
| ¿El Prometheus que viene con la plataforma del fabricante nos sirve, o necesitamos el nuestro? | Vigilar la fábrica y responder al negocio son dos alcances distintos |
| ¿Quién opera esto, con nombre? | Es el costo real. Y si es una sola persona, ya tienes un riesgo |
| ¿Cómo se comporta la opción de histórico bajo carga real? | Hay patrones de degradación periódica documentados. Mejor elegirlos sabiendo |
| ¿Qué pasa cuando el clúster crezca al doble? | Pasados los cinco millones de series el diseño cambia. Conviene saber si ya estamos cerca |
Preguntas frecuentes
¿Cuál es la diferencia entre Telegraf y Prometheus?
Telegraf es un agente que recoge métricas y las empuja hacia donde le indiques, con un ecosistema muy amplio de conectores. Prometheus es un servidor que va a buscar los datos a cada objetivo, y además los guarda en su propia base de datos de series de tiempo, con lenguaje de consulta, alertas y descubrimiento de objetivos. Uno empuja y el otro jala, y esa diferencia condiciona el resto del diseño.
¿Cuántas series aguanta Prometheus?
Cada serie activa cuesta entre 1 y 3 KiB de memoria, así que una instancia de 16 GB vive cómoda con unos pocos millones. La zona confortable está entre uno y dos millones de series; se puede llegar a diez millones o más con hardware grande y discos rápidos, pero solo con disciplina estricta de cardinalidad. Pasados los cinco millones hay que repartir la carga y mover el histórico a un almacén dedicado.
¿Qué es la alta cardinalidad y por qué encarece?
Es tener demasiadas series distintas, y casi siempre nace de una etiqueta con muchísimos valores posibles: un identificador de usuario, de trabajo o de petición. Una sola etiqueta así convierte una métrica en millones de series, y en el stack abierto la cantidad de series es la unidad de costo, tanto en memoria como en almacenamiento del histórico.
¿Thanos, Mimir o VictoriaMetrics?
Thanos es el camino de menor fricción si ya tienes Prometheus y solo quieres histórico. Mimir aporta multiinquilinato real con límites por inquilino, útil si vas a separar áreas o rentar capacidad. VictoriaMetrics es una base de datos distinta que acepta los datos de Prometheus y en pruebas usa cinco veces menos memoria y 1,7 veces menos CPU que Mimir para la misma carga.
¿El stack abierto es gratis?
No tiene costo de licencia, que no es lo mismo. Su costo es de gente: armarlo es un proyecto, mantenerlo actualizado es continuo, y hay que evitar que dependa de una sola persona. La comparación honesta no es licencia contra cero, sino licencia contra el tiempo de tu propio equipo.
Lo que me llevo de esto
Cuando aquellas tres personas logramos que la integración funcionara, sentimos que habíamos ganado. Y habíamos ganado, pero también habíamos firmado sin saberlo: a partir de ese día, eso era nuestro para siempre.
Con el stack abierto pasa igual y sigue valiendo la pena. Lo único que pido es que la decisión se tome con el número completo enfrente: cuántas series, cuánto tiempo, cuánta gente. Porque de las tres, la que se olvida siempre es la gente, y es la única que no se puede comprar más rápido.
La próxima semana, de dónde sale toda esa telemetría cuando no puedes tocar la aplicación: eBPF. Es la técnica que está debajo de buena parte de las herramientas modernas, y merece entenderse antes de hablar de las herramientas. 🐝
Que los sistemas estén con ustedes. ✦
Imagen destacada generada con inteligencia artificial.
Ethel Méndez
Senior Product Manager en observabilidad y redes B2B, con 20 años de campo, NOC y servicios administrados en LATAM. Escribo lo que aprendí operando sistemas de verdad, no en un curso.