El precio por host no es el problema. Lo es qué cuenta como host
Datadog cobra infraestructura por host, y APM aparte, también por host. Con una cantidad fija de servidores eso es predecible y hasta razonable. En Kubernetes la cantidad no es fija.
El autoescalado crea nodos cuando hay demanda y los apaga cuando pasa. Pero cada nodo que existió durante el mes se cuenta, aunque haya vivido tres días. Un cluster que promedia 40 nodos y sube a 120 en un lanzamiento no paga por 40: paga por algo mucho más cercano a 120.
Por eso la factura es difícil de presupuestar. Lo que dispara el costo es cuántos nodos existieron, y ese número nadie lo decide ni lo mira: lo produce el autoescalado solo. Nadie aprobó gastar más; el gasto apareció porque el sistema funcionó como debía.
La segunda fuente: cada etiqueta que agregas multiplica el cobro
El plan incluye alrededor de 100 métricas personalizadas por host. Pasado eso se cobra por métrica. Suena poco, y lo es hasta que se entiende qué cuenta como una métrica distinta.
Para Datadog, cada combinación de etiquetas es una métrica aparte. Si mides la latencia de un servicio y la etiquetas con el nombre del servicio, el namespace y la versión, eso ya son varias. Si además le agregas el identificador del pod, la cuenta se multiplica por la cantidad de pods que haya en ese momento — y en Kubernetes esa cantidad cambia sola.
Una métrica con cuatro etiquetas de diez valores posibles cada una son diez mil métricas distintas. Los exportadores habituales de Prometheus, instalados tal como vienen, producen decenas de miles.
Este es el gasto que sorprende, porque no lo provoca una compra. Lo provoca una línea de configuración que alguien agregó para depurar un problema y nadie quitó después.
La tercera: guardar un log y poder buscarlo son dos cobros
La ingesta se cobra por volumen. La indexación se cobra aparte, por millón de eventos, y sube según cuántos días quieras conservarlos. Son dos cargos separados sobre el mismo log.
La consecuencia práctica llega en el peor momento: el equipo empieza a decidir qué puede investigar según lo que puede pagar. Durante un incidente eso es exactamente al revés de lo que hace falta.
Qué reemplaza Moonin y qué no
Moonin responde dos preguntas y solo esas, y cuesta menos precisamente por eso: qué cambió en el cluster, y qué se rompió después de ese cambio. Para responderlas mantiene el inventario de recursos, el historial de revisiones de cada servicio con su imagen y su commit, las métricas DORA calculadas desde ese historial, y las trazas entre servicios 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 tableros donde armar cualquier gráfico, y no reemplaza la ingesta ni la búsqueda de logs a gran escala. Si tu equipo vive dentro de tableros hechos a mano, o depende de búsquedas complejas sobre terabytes de logs, esa parte se queda donde está.
Lo que suele funcionar no es reemplazar todo. Es dejar de pagar APM por host en los servicios donde saber qué se desplegó ya responde la pregunta, y conservar la herramienta grande para lo que de verdad la necesita.
Cuándo Moonin no es la respuesta
Si lo que necesitas es ver dentro del código —cuánta CPU consume cada función, trazas con anotaciones propias de tu negocio, errores con el stack completo— un APM instrumentado hace algo que las trazas de kernel no hacen. Cambiar ahí por ahorrar sale caro después.
Si tu gasto está concentrado en logs y no en hosts, cambiar de herramienta de observabilidad no lo mueve. Ese trabajo es de retención y de muestreo, y probablemente de decidir qué directamente no se guarda.
Y si tu cluster es chico y estable, el cobro por host es más barato que cualquier alternativa. Cuando la cantidad de nodos no se mueve, la aritmética favorece a Datadog.
Cómo cambia la cuenta cuando se cobra por capacidad
Moonin no cuenta hosts. Cuenta el tamaño de lo que tienes corriendo: una Unidad de Cómputo equivale a 1 vCPU o a 2 GB de RAM, y se cobra la dimensión que resulte mayor, nunca la suma de las dos. Un cluster con 120 vCPU y 180 GB de RAM paga 120 unidades: 120 vCPU contra 90 unidades de RAM, gana 120. No 210.
Lo que eso cambia en la 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 son 120 vCPU; veinte nodos de 6 también son 120. Misma factura. El autoescalado deja de tener consecuencia económica.
El precio baja por tramos, y cada tramo se cobra a su propio precio — no se aplica un precio único a todo. Las primeras 100 unidades van a USD 20 cada una; de la 101 a la 250, a USD 18; de la 251 a la 500, a USD 15; y sobre 500 se conviene.
Un cluster de 300 unidades, entonces, paga 100 × 20 más 150 × 18 más 50 × 15, o sea USD 5.450 al mes. No paga 300 × 15 ni 300 × 20. Incluye 10 GB de almacenamiento por unidad y soporte estándar. No hay costo base ni cargo mínimo por cluster.
Cómo migrar sin quedarte a ciegas
El error habitual es apagar lo que funciona antes de confiar en lo nuevo, y quedarse sin visibilidad justo cuando algo se rompe. Conviene el orden inverso.
Primero instalas el chart de Moonin en un cluster y lo dejas corriendo en paralelo dos o tres semanas, sin tocar nada de lo que ya tienes. Eso te da un inventario y un historial de despliegues reales, tuyos, para comparar contra lo que ya estás mirando.
Después identificas qué parte de tu gasto actual responde preguntas que ese historial ya contesta. Ahí es donde suele aparecer que el APM por host se estaba usando para saber qué cambió, no para perfilar código.
Recién entonces reduces lo que sobra, servicio por servicio, y conservas la herramienta grande donde su capacidad de verdad no se puede sustituir.
Ver si aplica a tu caso
La conversación útil no empieza por el precio. Empieza por dos números: cuántos nodos tiene tu cluster en un día normal, y cuántos en el peor día del mes. Con esos dos se sabe si hay margen o no.
El precio de Moonin por Unidad de Cómputo · Ver Moonin sobre un cluster real, sin formulario