Si tienes Prometheus, Loki, Tempo y Grafana funcionando, tienes buena observabilidad y no la vamos a discutir. Lo que falta es de otra naturaleza: una serie temporal te dice que la latencia subió a las 14:32. No te dice que a las 14:20 se desplegó la revisión 88.
Prometheus para métricas, Loki para logs, Tempo para trazas, Mimir para retención larga y Grafana para verlo todo. Es gratis, es estándar de la industria, y PromQL es un lenguaje de consulta que la gente aprende una vez y usa por años.
Para monitoreo de Kubernetes es probablemente la base instalada más común que existe, y con razón: cubre las tres señales clásicas —métricas, logs y trazas— sin pagar licencia.
Los tableros arbitrarios sobre datos propios no tienen equivalente en una herramienta enfocada. Si tu equipo armó veinte paneles que responden preguntas específicas de tu negocio, eso es valor real y no se reemplaza.
Y la madurez de las alertas —Alertmanager, silencios, agrupaciones, rutas de escalamiento— es de las mejores que hay, en cualquier categoría de precio.
Además los datos son tuyos y están en tu infraestructura. Para algunos equipos eso pesa más que cualquier función.
Prometheus solo no escala horizontalmente, y esa es la razón por la que existen Mimir y Thanos. En cuanto necesitas retención larga o federación entre clusters, adoptas un segundo sistema con su propia operación.
La cardinalidad es el enemigo permanente. Cada combinación de etiquetas es una serie, y las series viven en memoria. Un exportador que agrega una etiqueta con el identificador del pod puede multiplicar las series por la cantidad de pods y hacer que el propio Prometheus muera por memoria — con `Reason: OOMKilled`, la misma falla que estás investigando en tus servicios.
Loki y Tempo agregan cada uno su almacenamiento, su configuración de retención y su curva de aprendizaje. Nadie opera los cuatro sin dedicarle tiempo real.
Y hay un costo que no se ve en la factura: el conocimiento vive en una o dos personas del equipo. Cuando esa persona se va, se va con ella, y el reemplazo tarda meses en poder responder a un incidente del propio stack.
Esta es la diferencia de fondo y es técnica, no comercial. El modelo de datos de Prometheus es una serie temporal: un número, con etiquetas, a lo largo del tiempo. Responde «cuánto» maravillosamente bien.
«Qué revisión estaba activa» no es un número. Es un hecho discreto con un principio y un fin, una imagen, un commit y un autor. No cabe en una serie temporal, y por eso Prometheus no lo tiene.
Se puede forzar de dos maneras y las dos tienen un costo. La primera son las anotaciones de Grafana, que hay que alimentar desde el pipeline y que quedan como líneas verticales en un panel: útiles para mirar, inútiles para consultar.
La segunda es agregar una etiqueta de versión a las métricas, y ahí está la ironía: **eso multiplica la cardinalidad**, que es exactamente el problema que hace caer a Prometheus. Estás pagando el eje del cambio con la estabilidad del sistema que lo mide.
La consecuencia práctica la conoce cualquiera que estuvo de guardia: ves el gráfico que sube, y después abres tres pestañas más para averiguar qué se desplegó. Ese tramo del incidente no lo cubre ninguna de las cuatro piezas del stack, y es el que estira el MTTR.
Frecuencia de despliegue, tiempo de entrega, tasa de fallo de cambios y tiempo de recuperación son cuatro medidas sobre despliegues, no sobre carga. Prometheus no sabe qué es un despliegue.
Se pueden construir instrumentando el pipeline de CI para que emita métricas, y hay equipos que lo hacen. El trabajo es real, se desactualiza cuando el pipeline cambia, y nadie lo mantiene después del primer trimestre.
Moonin las calcula desde el historial de revisiones del propio cluster: si sabes qué se desplegó y cuándo, y cuándo se revirtió, las cuatro salen de ahí sin instrumentar nada ni tocar el pipeline.
Tempo guarda y consulta trazas, pero no las genera. Las trazas hay que producirlas, y hoy el camino estándar es OpenTelemetry: agregar el SDK a cada servicio, propagar el contexto entre llamadas, y mantener eso al día en todos los lenguajes que uses.
OpenTelemetry es la decisión correcta si quieres control fino: puedes anotar los spans con datos propios de tu negocio, medir tramos internos y decidir qué se muestrea. Eso es una capacidad real y eBPF no la da.
El costo es que hay que instrumentar, servicio por servicio, y coordinarlo con todos los equipos que los mantienen. En organizaciones con muchos servicios y varios lenguajes, ese proyecto dura trimestres — y los servicios antiguos que nadie quiere tocar nunca se instrumentan.
Moonin obtiene las trazas entre servicios con eBPF en el kernel del nodo, así que aparecen sin agregar librerías ni tocar código. Lo que se ve es el tráfico real entre servicios; lo que no se ve es el interior de cada uno. Es un intercambio explícito, no una versión mejor.
Y hay que decirlo completo: el agente de eBPF necesita privilegios en el nodo para leer el tráfico del kernel. Es la contrapartida de no instrumentar, y está documentada agente por agente.
Si lo que te falta son tableros, no es esto. Moonin no es un motor de tableros y Grafana es de los mejores que existen.
Si necesitas visibilidad dentro del código —tramos internos, anotaciones de negocio, perfilado por función— instrumenta con OpenTelemetry. Las trazas de kernel no llegan ahí.
Si tu problema es que Prometheus se cae por cardinalidad, eso se arregla en la cardinalidad. Limpiar etiquetas que nadie consulta baja la presión sin agregar herramientas, y conviene intentarlo primero.
Y si tu equipo ya opera el stack con comodidad y el eje del cambio lo cubren con anotaciones que de verdad mantienen, no hay problema que resolver. Moverse cuesta trabajo y ese trabajo tiene que comprar algo.
Casi nadie debería apagar Prometheus, y nosotros no lo proponemos. Lo que suele funcionar es dejar cada cosa donde es buena: las métricas y los tableros en el stack, y el eje del cambio aparte.
En la práctica eso significa instalar el chart de Moonin en un cluster y dejarlo dos o tres semanas en paralelo. El acceso al API de Kubernetes es de solo lectura y no interfiere con los exportadores, con el operador de Prometheus ni con los agentes de Loki.
Después la pregunta concreta es cuántas de tus investigaciones frecuentes en Grafana terminan en «y qué se desplegó». Si son varias, ahí está el tramo que no cubría el stack.
Y el precio de Moonin no depende de series ni de volumen: se cobra por el tamaño del cluster, con una Unidad de Cómputo igual a 1 vCPU o 2 GB de RAM, cobrando la dimensión mayor. Agregar una etiqueta para depurar algo no tiene consecuencia en la factura, que es exactamente lo contrario de lo que pasa con la cardinalidad en Prometheus.
De tus investigaciones más frecuentes en Grafana, cuántas terminan en «y qué se desplegó antes de esto». Ese tramo es el que el stack no cubre, y es el que estira el tiempo de recuperación.
ConócenosLicenciamientoSeguridad y permisosPrograma de partnersvs Datadogvs New Relicvs Dynatracevs ELK y ElasticsearchCrashLoopBackOffOOMKilledImagePullBackOffPod en PendingDocumentaciónDemoRegístrateContáctanosArguz, la consultora
Por un eje que el modelo de datos de Prometheus no tiene. Una serie temporal responde «cuánto» a lo largo del tiempo; no responde «qué revisión estaba activa», porque una revisión no es una medición. Puedes forzarlo con anotaciones de Grafana o con una etiqueta de versión, pero lo segundo multiplica la cardinalidad, que es justo lo que hace caer a Prometheus.
No. Grafana es un motor de tableros y de los mejores que existen; Moonin no lo es. Si lo que te falta son visualizaciones arbitrarias sobre datos propios, la respuesta es Grafana y no esto.
No directamente, porque Prometheus no sabe qué es un despliegue. Se puede instrumentar el pipeline de CI para que emita métricas, y algunos equipos lo hacen, pero ese trabajo se desactualiza cuando el pipeline cambia. Moonin las calcula desde el historial de revisiones del propio cluster, sin tocar el pipeline.
No para las trazas entre servicios: se obtienen con eBPF en el kernel del nodo, sin instrumentar código. Sí lo necesitas si quieres ver tramos internos de cada servicio, anotar spans con datos de tu negocio o perfilar por función — eso eBPF no lo da y es un intercambio explícito. El agente de eBPF, a cambio, necesita privilegios en el nodo.
No. Moonin se instala como un Helm chart aparte, su acceso al API de Kubernetes es de solo lectura, y no toca tus exportadores, tu operador de Prometheus ni tus agentes de logs. Correr las dos cosas dos o tres semanas es la forma recomendada de evaluar.