La factura de observabilidad no crece con el uso, crece con la forma en que se cobra. En Kubernetes eso se nota más que en ningún otro lado, y no todo el gasto se resuelve cambiando de herramienta.
Datadog cobra infraestructura por host, entre USD 15 y 23 al mes según el plan, y APM aparte, entre USD 31 y 40 por host. Con una flota estable eso es predecible y hasta razonable. En Kubernetes no hay flota estable.
El autoescalado crea nodos cuando hay demanda y los destruye cuando pasa. Cada nodo que existió durante el mes cuenta, así que un pico de tráfico de tres días fija la factura de los treinta. Un cluster que promedia 40 nodos y llega a 120 en un lanzamiento no paga por 40: paga por algo mucho más cercano a 120.
Es el mismo mecanismo que hace difícil presupuestar: la variable que dispara el costo (cuántos nodos existieron) no es la que el equipo controla ni mira. Nadie aprueba un gasto de más; el gasto aparece porque el HPA funcionó.
El plan incluye alrededor de 100 métricas personalizadas por host, y más allá de eso se cobra por métrica, del orden de USD 0,05 al mes cada una. Parece poco hasta que se recuerda qué es una métrica personalizada en Kubernetes.
Un cluster con los exportadores habituales de Prometheus genera decenas de miles de series distintas, porque cada combinación de etiquetas cuenta como una. Agregar una etiqueta con el identificador del pod a una métrica que ya tiene servicio, namespace y versión multiplica las series por la cantidad de pods, que en Kubernetes cambia sola.
Ese es el gasto que sorprende, porque no lo provoca una decisión de compra sino una línea de configuración que alguien agregó para depurar y nadie quitó.
La ingesta se cobra por volumen, del orden de USD 0,10 por GB, y la indexación se cobra aparte por millón de eventos, con el precio subiendo según la retención. O sea que guardar un log y poder buscarlo son dos cargos distintos.
La consecuencia práctica es que el equipo termina decidiendo qué se puede investigar según lo que se puede pagar, que es exactamente al revés de lo que se quiere durante un incidente.
Moonin responde una pregunta estrecha y por eso cuesta menos: qué cambió en el cluster y qué se rompió a partir de ese cambio. Mantiene el inventario de recursos, el historial de revisiones por servicio con su imagen y su commit, las métricas DORA calculadas desde ese historial, y trazas distribuidas obtenidas con eBPF en el kernel del nodo, sin instrumentar código.
Lo que no hace, dicho sin rodeos: no es un APM de propósito general, no es un motor de dashboards donde armar cualquier gráfico, y no reemplaza la ingesta ni la búsqueda de logs a escala. Si el equipo vive dentro de dashboards personalizados o depende de búsquedas complejas sobre terabytes de logs, esa parte se queda donde está.
La combinación que suele funcionar no es reemplazar todo: es dejar de pagar APM por host en los servicios donde el contexto de despliegue ya responde la pregunta, y conservar la herramienta grande para lo que de verdad la necesita.
Si el problema es visibilidad dentro del código (perfiles de CPU por función, trazas con anotaciones propias del negocio, seguimiento de errores con el stack completo), un APM instrumentado hace algo que las trazas de kernel no hacen. Cambiar por costo ahí sale caro después.
Si el gasto está concentrado en logs y no en hosts, cambiar de herramienta de observabilidad no lo mueve: el trabajo es de retención y de muestreo, y probablemente de decidir qué no se guarda.
Y si el cluster es estable y pequeño, el modelo por host es más barato que cualquier alternativa. La aritmética favorece a Datadog cuando la cantidad de nodos no se mueve.
Moonin no cuenta hosts. Cuenta capacidad declarada: una Unidad de Cómputo equivale a 1 vCPU o a 2 GB de RAM, y se cobra la dimensión que pesa más, nunca la suma de ambas. Un cluster con 120 vCPU y 180 GB de RAM paga 120 unidades, no 210.
La diferencia práctica es que el número no depende de cuántos nodos existieron ni de cuánto tráfico hubo. Diez nodos de 12 vCPU y veinte de 6 son la misma factura, así que el autoescalado deja de tener consecuencia económica.
El precio va por tramos incrementales: USD 20 por unidad al mes hasta 100 unidades, USD 18 de 101 a 250, USD 15 de 251 a 500, y a convenir sobre 500. Incluye 10 GB de almacenamiento por unidad y soporte estándar. No hay costo base ni cargo mínimo por cluster.
El error habitual es apagar lo que funciona antes de confiar en lo nuevo, y quedar sin visibilidad justo cuando algo se rompe. Conviene el orden inverso.
Primero se instala el chart de Moonin en un cluster y se deja correr en paralelo dos o tres semanas, sin tocar nada de lo existente. Eso da un inventario y un historial de despliegues reales para comparar contra lo que ya se está mirando.
Después se identifica qué parte del gasto actual responde preguntas que el historial de despliegues ya contesta. Ahí suele aparecer que el APM por host se estaba usando para saber qué cambió, no para perfilar código.
Recién entonces se reduce lo que sobra, servicio por servicio, y se conserva la herramienta grande donde su capacidad es realmente insustituible.
La conversación útil no empieza por el precio sino por cuántos nodos tiene tu cluster en promedio y cuántos en el peor día del mes. Con esos dos números se sabe si hay margen o no.
ConócenosLicenciamientoDemoRegístrateContáctanosArguz, la consultora
No en la mayoría de los casos, y conviene no pretenderlo. Moonin reemplaza la parte que responde qué cambió en el cluster y qué se rompió a partir de ese cambio, que suele ser buena parte del gasto de APM por host. No reemplaza un APM instrumentado para perfilar código, un motor de dashboards personalizados, ni la ingesta y búsqueda de logs a escala.
Por tres mecanismos que no dependen del tamaño promedio. El primero es que el autoescalado crea nodos y cada nodo que existió durante el mes cuenta, así que un pico de tres días fija la factura de treinta. El segundo es la cardinalidad: cada combinación de etiquetas es una métrica personalizada distinta, y agregar una etiqueta puede multiplicar las series por la cantidad de pods. El tercero es que los logs se cobran por ingesta y por indexación de forma separada.
Arguz midió entre 20% y 40% de reducción en la factura cloud en sus propios proyectos, pero eso incluye el ahorro de infraestructura y no sólo el de observabilidad. Depende del punto de partida: un ambiente donde nadie revisó el sobredimensionamiento deja mucho más margen que uno ya optimizado. Cualquiera que prometa un porcentaje sin ver los clusters está adivinando.
No. Moonin obtiene las trazas distribuidas y el tráfico entre servicios con eBPF, en el kernel del nodo, así que no hay librerías que agregar, ni SDK, ni sidecars, ni cambios en los pipelines de despliegue. Se instala un solo Helm chart por cluster.
Sí, y es la forma recomendada de empezar. El agente es de solo lectura sobre el API de Kubernetes y no interfiere con otros agentes. Correr las dos herramientas dos o tres semanas es lo que permite comparar con datos propios antes de reducir nada.