O Zabbix FinOps Toolkit utiliza métricas já coletadas pelo Zabbix para identificar servidores superdimensionados e gerar recomendações de right-sizing. Assim, equipes de infraestrutura podem avaliar desperdício de CPU, memória, disco e rede sem depender de uma plataforma externa.
Na prática, o módulo transforma dados de monitoramento em informações úteis para decisões de capacidade e custo. Além disso, ele funciona diretamente na interface do Zabbix e utiliza o histórico armazenado nas tabelas de trends.
O desperdício que ninguém vê
Toda empresa que opera infraestrutura, seja on-premises, em cloud ou em ambiente híbrido, enfrenta um problema recorrente: servidores dimensionados para picos que não acontecem mais.
Em outros casos, as máquinas foram provisionadas com capacidade adicional “por segurança”. No entanto, essa capacidade permaneceu alocada mesmo depois de a necessidade desaparecer.
O servidor continua ligado, monitorado e funcionando. Ele não gera alertas e não aparece nos dashboards como um problema. Ainda assim, pode permanecer durante meses utilizando apenas 5% de CPU e 15% de memória.
Em cloud, esse desperdício representa cobrança recorrente. Já em ambientes on-premises, representa capacidade imobilizada que poderia atender outras cargas ou que talvez nem precisasse ter sido adquirida.
Os dados já estão disponíveis
Quem utiliza o Zabbix normalmente já coleta CPU, memória, disco e rede de todos os hosts monitorados. Além disso, essas métricas são armazenadas continuamente e podem ser analisadas ao longo do tempo.
Portanto, o problema não é a falta de dados. O desafio é transformar telemetria operacional em informação útil para decisões de capacidade e custo.
Foi dessa necessidade que surgiu o Zabbix FinOps Toolkit. O módulo usa dados já coletados pelo Zabbix para identificar possíveis excessos de capacidade e gerar recomendações de right-sizing.
O que é FinOps
FinOps, ou Financial Operations, é uma prática que aproxima engenharia, finanças e áreas de negócio.
O objetivo não é simplesmente reduzir gastos. Em vez disso, a proposta é tomar decisões de infraestrutura com base em consumo, custo, risco e necessidade real.
A prática normalmente se apoia em três pilares:
- Visibilidade: saber quais recursos existem, quanto custam e quanto são utilizados;
- Otimização: agir sobre recursos ociosos ou mal dimensionados;
- Cultura: fazer com que as equipes considerem eficiência, e não apenas disponibilidade.
Por que FinOps faz sentido no monitoramento
O Zabbix já atende parte importante do primeiro pilar. Ele coleta métricas de CPU, memória, disco, rede, carga e vários outros indicadores.
Além disso, esses dados podem permanecer armazenados por semanas ou meses. Nas tabelas de trends, eles são consolidados em intervalos de uma hora.
Entretanto, o Zabbix não interpreta essas métricas automaticamente sob a perspectiva financeira.
Ele informa, por exemplo, que um servidor utiliza 5% de CPU. Porém, do ponto de vista do monitoramento, isso não representa uma falha.
Sob a perspectiva de capacidade e custo, por outro lado, essa baixa utilização pode indicar superdimensionamento.
O Zabbix FinOps Toolkit fecha essa lacuna ao fazer uma pergunta objetiva:
Este servidor realmente precisa de toda a capacidade que recebeu?
Como funciona o Zabbix FinOps Toolkit
O módulo analisa os últimos 30 dias de métricas de cada host monitorado.
Esse período ajuda a capturar ciclos semanais, rotinas de backup, processamentos em lote e fechamentos mensais. Ao mesmo tempo, reduz a influência de eventos isolados.
Métricas analisadas
| Métrica | Item key do Zabbix |
|---|---|
| CPU | system.cpu.util |
| Memória | vm.memory.utilization ou vm.memory.size[pavailable] |
| Disco | vfs.fs.size[/,pused] |
| Rede de entrada | net.if.in |
| Rede de saída | net.if.out |
| Load average | system.cpu.load |
Com base nessas métricas, o módulo calcula indicadores para cada host.
Waste Score
O Waste Score representa um índice simplificado de possível desperdício.
waste_score = 100 - ((media_cpu + media_ram) / 2)waste_score = 100 - ((5 + 15) / 2)
waste_score = 90Entretanto, esse resultado não significa, literalmente, que 90% de todos os recursos podem ser removidos. O indicador funciona como um sinal de priorização para análise.
Classificação do Waste Score
| Score | Classificação |
|---|---|
| 80 ou mais | Alto desperdício potencial |
| 60 a 79 | Médio desperdício potencial |
| 40 a 59 | Baixo desperdício potencial |
| Abaixo de 40 | Utilização considerada saudável |
Efficiency Score
O Efficiency Score apresenta os mesmos dados pela perspectiva oposta.
efficiency_score = (media_cpu + media_ram) / 2Enquanto o Waste Score responde “quanto pode estar sobrando?”, o Efficiency Score responde “quanto da capacidade está sendo utilizada?”.
Essa separação facilita a comunicação com públicos diferentes.
Por um lado, o Waste Score é mais útil para discussões de custo. Por outro, o Efficiency Score ajuda equipes técnicas a avaliar o aproveitamento da capacidade.
O que diferencia essa análise
Calcular médias é simples. No entanto, usar apenas a média produz recomendações frágeis.
Por isso, o módulo adiciona mecanismos para reduzir falsos positivos e evitar decisões de right-sizing baseadas em dados incompletos.
Percentil 95 em vez de pico máximo
Um servidor pode apresentar CPU média de 3% durante 30 dias e, ainda assim, atingir 100% durante um backup ou deploy.
Caso a análise considere apenas o valor máximo, um único pico pode impedir qualquer recomendação.
Por esse motivo, o módulo usa o percentil 95, também chamado de P95.
O P95 representa o valor abaixo do qual ficaram 95% das medições. Dessa forma, os 5% maiores picos têm menos influência sobre a análise.
Por exemplo, se o P95 de CPU é 15%, isso indica que a utilização permaneceu em até 15% durante 95% do período analisado.
Nesse cenário, há evidência de baixa utilização recorrente.
Média baixa com P95 alto
Uma média baixa nem sempre significa ociosidade constante.
Considere um host com CPU média de 5% e P95 de 85%. Nesse caso, existem períodos recorrentes de utilização elevada.
Portanto, a recomendação correta não é reduzir imediatamente. Primeiro, é necessário investigar o padrão da carga.
Assim, o módulo evita sugerir uma redução baseada apenas na média.
Detecção de tendência de crescimento
O módulo também compara o consumo da primeira semana com o consumo da última semana do período analisado.
Essa comparação ajuda a identificar cargas em crescimento.
Por exemplo, um servidor pode apresentar CPU média de 8% na primeira semana e 18% na quarta semana.
Embora a média geral ainda seja baixa, a tendência indica aumento de demanda. Consequentemente, reduzir recursos naquele momento pode criar um problema em curto prazo.
Nesse cenário, o módulo retorna uma mensagem semelhante a:
Carga em crescimento. Redução não recomendada.
Pequenas variações não bloqueiam a recomendação
O módulo não bloqueia recomendações por causa de qualquer aumento.
Em vez disso, ele projeta o consumo futuro com base na média atual e na tendência observada. A recomendação só é bloqueada quando essa projeção alcança ou ultrapassa os limites definidos.
Assim, um aumento de 2 pontos percentuais em um servidor que utiliza 3% de CPU não invalida automaticamente uma recomendação.
Análise multidimensional
CPU e memória baixas não significam, isoladamente, que um servidor pode ser reduzido.
Um host pode apresentar baixo consumo de CPU e RAM, mas estar com disco próximo da capacidade máxima. Além disso, também pode depender de alto throughput de rede.
Nesses casos, reduzir vCPU ou memória pode não gerar benefício e ainda aumentar o risco operacional.
Por isso, o módulo verifica outras métricas antes de recomendar qualquer mudança.
Se o disco estiver acima de 85% ou a rede apresentar utilização elevada de forma consistente, a recomendação muda para:
Uso baixo de CPU e memória, porém outros recursos apresentam alta utilização. Redução não recomendada.
Recomendações concretas de right-sizing
Identificar desperdício é apenas o primeiro passo.
Depois disso, surge a pergunta mais importante:
Para qual capacidade o servidor deve ser reduzido?
O módulo calcula uma recomendação com base em 80% da alocação atual. Além disso, aplica uma trava para impedir que o valor recomendado fique abaixo do consumo observado no P95.
Exemplo de recomendação de CPU
Considere um servidor com 4 vCPUs e P95 de CPU em 15,9%.
A recomendação inicial é:
4 vCPUs × 80% = 3,2 vCPUsO consumo correspondente ao P95 é:
4 × 15,9% = 0,636 vCPUExemplo de recomendação de memória
Considere agora um servidor com 7,5 GB de RAM e P95 de memória em 21%.
A recomendação inicial é:
7,5 GB × 80% = 6 GB7,5 GB × 21% = 1,575 GBEntretanto, quando 80% da alocação atual fica abaixo do consumo observado no P95, o módulo não apresenta recomendação.
Essa decisão é intencional. Afinal, uma ausência de recomendação é mais segura do que uma sugestão sem margem adequada.
Requisitos do módulo
O módulo possui os seguintes requisitos:
- Zabbix 7.0 ou superior;
- PHP 8.0 ou superior;
- Hosts monitorados com templates de sistema operacional;
- Dados disponíveis nas tabelas de trends.
O módulo foi testado no Zabbix 7.4.7.
Instalação do Zabbix FinOps Toolkit
Acesse o diretório de módulos da interface do Zabbix:
cd /usr/share/zabbix/ui/modules/git clone https://github.com/Lfijho/ZabbixFinOps.git ZabbixFinOpsToolkit- Acesse Administration > General > Modules;
- Clique em Scan directory;
- Localize Zabbix FinOps Toolkit;
- Clique em Enable.
Após a ativação, o módulo ficará disponível em:
Monitoring > Infrastructure Cost AnalyzerIntegrando o módulo ao processo de FinOps
O Zabbix FinOps Toolkit é uma ferramenta de diagnóstico.
No entanto, seu valor real aparece quando a análise faz parte de um processo operacional controlado.
Ciclo sugerido
- Análise: execute o módulo e identifique os hosts com maior Waste Score;
- Validação: confirme com as equipes responsáveis se a redução é tecnicamente viável;
- Planejamento: registre a mudança, o impacto esperado e o plano de rollback;
- Right-sizing: aplique a alteração em janela de manutenção;
- Monitoramento: acompanhe desempenho, saturação e erros após a mudança;
- Reavaliação: execute o módulo novamente depois do período de observação.
Automatizar a análise não elimina a necessidade de controle de mudança. O módulo gera evidências, mas a decisão final continua dependendo do contexto da aplicação.
Boas práticas
Não aplique recomendações diretamente em produção sem validação.
Antes de qualquer redução:
- Confirme o comportamento da aplicação;
- Verifique requisitos de disponibilidade e desempenho;
- Consulte os responsáveis pelo serviço;
- Defina critérios de sucesso;
- Prepare um plano de rollback;
- Execute a mudança em janela de manutenção;
- Monitore o ambiente após a alteração.
Além disso, acompanhe as métricas por pelo menos uma ou duas semanas depois do right-sizing.
Limitações
O módulo é comunitário. Portanto, não possui SLA oficial e não é mantido pela Zabbix.
Teste o comportamento no seu ambiente antes de utilizar os resultados em decisões de produção.
Além disso, o módulo analisa métricas de infraestrutura. Ele não conhece o contexto completo do serviço.
Por exemplo, ele não sabe se:
- O servidor receberá uma carga adicional no próximo mês;
- A máquina faz parte de uma estratégia de disaster recovery;
- Existe uma exigência contratual de capacidade;
- Há eventos sazonais previstos;
- A aplicação depende de baixa latência;
- A capacidade excedente é intencional.
O módulo também consulta dados das tabelas de trends. Esses dados são consolidados por hora, usando médias, máximos e mínimos.
Portanto, a granularidade da análise é de uma hora, e não de um minuto.
FinOps é um processo contínuo
FinOps não deve ser tratado como um projeto executado uma única vez.
A utilização dos servidores muda. As aplicações crescem, diminuem ou são substituídas. Consequentemente, uma configuração adequada hoje pode se tornar ineficiente depois.
Por isso, a análise precisa ser recorrente.
O processo deve incluir medição, validação, mudança controlada e monitoramento posterior.
Sem esse ciclo, o right-sizing se transforma em uma ação pontual e perde valor ao longo do tempo.
Conclusão
O Zabbix já coleta os dados necessários para iniciar uma análise de eficiência de infraestrutura.
O que faltava era uma camada capaz de transformar métricas operacionais em indicadores de desperdício e recomendações de capacidade.
O Zabbix FinOps Toolkit é uma primeira implementação dessa camada. Ele funciona diretamente na interface do Zabbix, utiliza dados existentes e não exige uma plataforma externa.
Além disso, o projeto possui código aberto e pode ser adaptado conforme as necessidades de cada ambiente.
O repositório está disponível no GitHub. Acesse o repositório do Zabbix FinOps Toolkit
Contribuições, issues e pull requests são bem-vindos.
Prev Post 
