El Zabbix FinOps Toolkit utiliza métricas ya recolectadas por Zabbix para identificar servidores sobredimensionados y generar recomendaciones de right-sizing. Así, los equipos de infraestructura pueden evaluar el desperdicio de CPU, memoria, disco y red sin depender de una plataforma externa.
En la práctica, el módulo transforma datos de monitoreo en información útil para decisiones de capacidad y costo. Además, funciona directamente en la interfaz de Zabbix y utiliza el historial almacenado en las tablas de trends.
El desperdicio que nadie ve
Toda empresa que opera infraestructura, ya sea on-premises, en cloud o en ambiente híbrido, enfrenta un problema recurrente: servidores dimensionados para picos que ya no ocurren.
En otros casos, las máquinas fueron aprovisionadas con capacidad adicional «por seguridad». Sin embargo, esa capacidad permaneció asignada incluso después de que la necesidad desapareciera.
El servidor sigue encendido, monitoreado y funcionando. No genera alertas y no aparece en los dashboards como un problema. Aun así, puede permanecer durante meses utilizando apenas 5% de CPU y 15% de memoria.
En cloud, ese desperdicio representa cobro recurrente. En ambientes on-premises, en cambio, representa capacidad inmovilizada que podría atender otras cargas o que tal vez ni siquiera necesitaba haberse adquirido.
Los datos ya están disponibles
Quien utiliza Zabbix normalmente ya recolecta CPU, memoria, disco y red de todos los hosts monitoreados. Además, esas métricas se almacenan continuamente y pueden analizarse a lo largo del tiempo.
Por lo tanto, el problema no es la falta de datos. El desafío es transformar telemetría operacional en información útil para decisiones de capacidad y costo.
Fue de esa necesidad que surgió el Zabbix FinOps Toolkit. El módulo usa datos ya recolectados por Zabbix para identificar posibles excesos de capacidad y generar recomendaciones de right-sizing.
Qué es FinOps
FinOps, o Financial Operations, es una práctica que acerca ingeniería, finanzas y áreas de negocio.
El objetivo no es simplemente reducir gastos. En cambio, la propuesta es tomar decisiones de infraestructura con base en consumo, costo, riesgo y necesidad real.
La práctica normalmente se apoya en tres pilares:
- Visibilidad: saber qué recursos existen, cuánto cuestan y cuánto se utilizan;
- Optimización: actuar sobre recursos ociosos o mal dimensionados;
- Cultura: hacer que los equipos consideren la eficiencia, y no solo la disponibilidad.
Por qué FinOps tiene sentido en el monitoreo
Zabbix ya cubre una parte importante del primer pilar. Recolecta métricas de CPU, memoria, disco, red, carga y varios otros indicadores.
Además, esos datos pueden permanecer almacenados durante semanas o meses. En las tablas de trends, se consolidan en intervalos de una hora.
Sin embargo, Zabbix no interpreta esas métricas automáticamente desde la perspectiva financiera.
Informa, por ejemplo, que un servidor utiliza 5% de CPU. Pero, desde el punto de vista del monitoreo, eso no representa una falla.
Desde la perspectiva de capacidad y costo, en cambio, esa baja utilización puede indicar sobredimensionamiento.
El Zabbix FinOps Toolkit cierra esa brecha al hacer una pregunta objetiva:
¿Este servidor realmente necesita toda la capacidad que recibió?
Cómo funciona el Zabbix FinOps Toolkit
El módulo analiza los últimos 30 días de métricas de cada host monitoreado.
Ese período ayuda a capturar ciclos semanales, rutinas de backup, procesamientos por lotes y cierres mensuales. Al mismo tiempo, reduce la influencia de eventos aislados.
Métricas analizadas
| Métrica | Item key de Zabbix |
|---|---|
| CPU | system.cpu.util |
| Memoria | vm.memory.utilization o vm.memory.size[pavailable] |
| Disco | vfs.fs.size[/,pused] |
| Red de entrada | net.if.in |
| Red de salida | net.if.out |
| Load average | system.cpu.load |
Con base en estas métricas, el módulo calcula indicadores para cada host.
Waste Score
El Waste Score representa un índice simplificado de posible desperdicio.
waste_score = 100 - ((media_cpu + media_ram) / 2)waste_score = 100 - ((5 + 15) / 2)
waste_score = 90Sin embargo, ese resultado no significa, literalmente, que se pueda eliminar el 90% de todos los recursos. El indicador funciona como una señal de priorización para análisis.
Clasificación del Waste Score
| Score | Clasificación |
|---|---|
| 80 o más | Alto desperdicio potencial |
| 60 a 79 | Medio desperdicio potencial |
| 40 a 59 | Bajo desperdicio potencial |
| Menos de 40 | Utilización considerada saludable |
Efficiency Score
El Efficiency Score presenta los mismos datos desde la perspectiva opuesta.
efficiency_score = (media_cpu + media_ram) / 2Mientras el Waste Score responde «¿cuánto puede estar sobrando?», el Efficiency Score responde «¿cuánto de la capacidad se está utilizando?».
Esa separación facilita la comunicación con públicos diferentes.
Por un lado, el Waste Score es más útil para discusiones de costo. Por otro, el Efficiency Score ayuda a los equipos técnicos a evaluar el aprovechamiento de la capacidad.
Qué diferencia este análisis
Calcular promedios es simple. Sin embargo, usar solo el promedio produce recomendaciones frágiles.
Por eso, el módulo agrega mecanismos para reducir falsos positivos y evitar decisiones de right-sizing basadas en datos incompletos.
Percentil 95 en vez de pico máximo
Un servidor puede presentar CPU promedio de 3% durante 30 días y, aun así, alcanzar 100% durante un backup o deploy.
Si el análisis considera solo el valor máximo, un único pico puede impedir cualquier recomendación.
Por ese motivo, el módulo usa el percentil 95, también llamado P95.
El P95 representa el valor por debajo del cual quedó el 95% de las mediciones. De esta forma, los 5% de picos más altos tienen menos influencia sobre el análisis.
Por ejemplo, si el P95 de CPU es 15%, eso indica que la utilización permaneció en hasta 15% durante el 95% del período analizado.
En ese escenario, hay evidencia de baja utilización recurrente.
Promedio bajo con P95 alto
Un promedio bajo no siempre significa ociosidad constante.
Considera un host con CPU promedio de 5% y P95 de 85%. En ese caso, existen períodos recurrentes de utilización elevada.
Por lo tanto, la recomendación correcta no es reducir de inmediato. Primero, es necesario investigar el patrón de la carga.
Así, el módulo evita sugerir una reducción basada solo en el promedio.
Detección de tendencia de crecimiento
El módulo también compara el consumo de la primera semana con el consumo de la última semana del período analizado.
Esa comparación ayuda a identificar cargas en crecimiento.
Por ejemplo, un servidor puede presentar CPU promedio de 8% en la primera semana y 18% en la cuarta semana.
Aunque el promedio general aún sea bajo, la tendencia indica un aumento de demanda. En consecuencia, reducir recursos en ese momento puede crear un problema a corto plazo.
En ese escenario, el módulo devuelve un mensaje similar a:
Carga en crecimiento. Reducción no recomendada.
Pequeñas variaciones no bloquean la recomendación
El módulo no bloquea recomendaciones por causa de cualquier aumento.
En cambio, proyecta el consumo futuro con base en el promedio actual y en la tendencia observada. La recomendación solo se bloquea cuando esa proyección alcanza o supera los límites definidos.
Así, un aumento de 2 puntos porcentuales en un servidor que utiliza 3% de CPU no invalida automáticamente una recomendación.
Análisis multidimensional
CPU y memoria bajas no significan, aisladamente, que un servidor pueda reducirse.
Un host puede presentar bajo consumo de CPU y RAM, pero estar con el disco cerca de la capacidad máxima. Además, también puede depender de un throughput de red alto.
En esos casos, reducir vCPU o memoria puede no generar beneficio y, además, aumentar el riesgo operacional.
Por eso, el módulo verifica otras métricas antes de recomendar cualquier cambio.
Si el disco está por encima de 85% o la red presenta utilización elevada de forma consistente, la recomendación cambia a:
Uso bajo de CPU y memoria, pero otros recursos presentan alta utilización. Reducción no recomendada.
Recomendaciones concretas de right-sizing
Identificar el desperdicio es solo el primer paso.
Después de eso, surge la pregunta más importante:
¿A qué capacidad debe reducirse el servidor?
El módulo calcula una recomendación con base en el 80% de la asignación actual. Además, aplica un límite para impedir que el valor recomendado quede por debajo del consumo observado en el P95.
Ejemplo de recomendación de CPU
Considera un servidor con 4 vCPUs y P95 de CPU en 15,9%.
La recomendación inicial es:
4 vCPUs × 80% = 3,2 vCPUsEl consumo correspondiente al P95 es:
4 × 15,9% = 0,636 vCPUEjemplo de recomendación de memoria
Considera ahora un servidor con 7,5 GB de RAM y P95 de memoria en 21%.
La recomendación inicial es:
7,5 GB × 80% = 6 GB7,5 GB × 21% = 1,575 GBSin embargo, cuando el 80% de la asignación actual queda por debajo del consumo observado en el P95, el módulo no presenta recomendación.
Esa decisión es intencional. Al final, la ausencia de una recomendación es más segura que una sugerencia sin margen adecuado.
Requisitos del módulo
El módulo tiene los siguientes requisitos:
- Zabbix 7.0 o superior;
- PHP 8.0 o superior;
- Hosts monitoreados con templates de sistema operativo;
- Datos disponibles en las tablas de trends.
El módulo fue probado en Zabbix 7.4.7.
Instalación del Zabbix FinOps Toolkit
Accede al directorio de módulos de la interfaz de Zabbix:
cd /usr/share/zabbix/ui/modules/git clone https://github.com/Lfijho/ZabbixFinOps.git ZabbixFinOpsToolkit- Accede a Administration > General > Modules;
- Haz clic en Scan directory;
- Localiza Zabbix FinOps Toolkit;
- Haz clic en Enable.
Después de la activación, el módulo estará disponible en:
Monitoring > Infrastructure Cost AnalyzerIntegrando el módulo al proceso de FinOps
El Zabbix FinOps Toolkit es una herramienta de diagnóstico.
Sin embargo, su valor real aparece cuando el análisis forma parte de un proceso operacional controlado.
Ciclo sugerido
- Análisis: ejecuta el módulo e identifica los hosts con mayor Waste Score;
- Validación: confirma con los equipos responsables si la reducción es técnicamente viable;
- Planificación: registra el cambio, el impacto esperado y el plan de rollback;
- Right-sizing: aplica el cambio en una ventana de mantenimiento;
- Monitoreo: observa el desempeño, la saturación y los errores después del cambio;
- Reevaluación: ejecuta el módulo nuevamente después del período de observación.
Automatizar el análisis no elimina la necesidad de control de cambios. El módulo genera evidencias, pero la decisión final sigue dependiendo del contexto de la aplicación.
Buenas prácticas
No apliques recomendaciones directamente en producción sin validación.
Antes de cualquier reducción:
- Confirma el comportamiento de la aplicación;
- Verifica los requisitos de disponibilidad y desempeño;
- Consulta a los responsables del servicio;
- Define criterios de éxito;
- Prepara un plan de rollback;
- Ejecuta el cambio en una ventana de mantenimiento;
- Monitorea el ambiente después del cambio.
Además, haz seguimiento de las métricas durante al menos una o dos semanas después del right-sizing.
Limitaciones
El módulo es comunitario. Por lo tanto, no tiene SLA oficial y no es mantenido por Zabbix.
Prueba el comportamiento en tu ambiente antes de utilizar los resultados en decisiones de producción.
Además, el módulo analiza métricas de infraestructura. No conoce el contexto completo del servicio.
Por ejemplo, no sabe si:
- El servidor recibirá una carga adicional el próximo mes;
- La máquina forma parte de una estrategia de disaster recovery;
- Existe una exigencia contractual de capacidad;
- Hay eventos estacionales previstos;
- La aplicación depende de baja latencia;
- La capacidad excedente es intencional.
El módulo también consulta datos de las tablas de trends. Esos datos se consolidan por hora, usando promedios, máximos y mínimos.
Por lo tanto, la granularidad del análisis es de una hora, y no de un minuto.
FinOps es un proceso continuo
FinOps no debe tratarse como un proyecto ejecutado una única vez.
La utilización de los servidores cambia. Las aplicaciones crecen, disminuyen o se sustituyen. En consecuencia, una configuración adecuada hoy puede volverse ineficiente después.
Por eso, el análisis necesita ser recurrente.
El proceso debe incluir medición, validación, cambio controlado y monitoreo posterior.
Sin ese ciclo, el right-sizing se convierte en una acción puntual y pierde valor con el tiempo.
Conclusión
Zabbix ya recolecta los datos necesarios para iniciar un análisis de eficiencia de infraestructura.
Lo que faltaba era una capa capaz de transformar métricas operacionales en indicadores de desperdicio y recomendaciones de capacidad.
El Zabbix FinOps Toolkit es una primera implementación de esa capa. Funciona directamente en la interfaz de Zabbix, utiliza datos existentes y no exige una plataforma externa.
Además, el proyecto tiene código abierto y puede adaptarse según las necesidades de cada ambiente.
El repositorio está disponible en GitHub. Accede al repositorio del Zabbix FinOps Toolkit
Contribuciones, issues y pull requests son bienvenidos.
Prev Post 
