Removendo um custo desnecessário de ingestão de monitoramento
Uma redução medida em uma linha de cobrança, com a funcionalidade de monitoramento verificada separadamente.
A linha de ingestão gerenciada foi removida; compute, armazenamento e manutenção autogerenciados ainda têm custos.
Contribuição em resumo
- Minha responsabilidade
- Substituí a ingestão gerenciada de métricas e preservei os targets, dashboards e a configuração de alertas.
- Escopo
- Uma linha de cobrança de ingestão gerenciada do Prometheus, denominada em GBP.
- Colaboração & limites
- Mudei a infraestrutura de monitoramento e verifiquei a saúde dos targets, o acesso de consulta e a ausência de ingestão gerenciada adicional.
- Resultado
- £1,165.80/mês removidos dessa linha; £13,989.60 anualizados. Os custos de hospedagem e manutenção permanecem.
O problema
Uma implantação do Prometheus encaminhava métricas para um caminho de ingestão de monitoramento gerenciado. O registro operacional atribuía £1,165.80 por mês a essa linha de cobrança, enquanto o time também mantinha uma stack de monitoramento local.
Minha contribuição
Substituí o caminho de ingestão gerenciado por uma stack padrão do Prometheus e atualizei sua configuração, preservando os scrape targets, dashboards e alertas existentes. A mudança foi aplicada com verificações de saúde dos targets, acesso de consulta e a ausência de ingestão gerenciada adicional.
O trade-off
Remover a ingestão gerenciada transfere a responsabilidade por armazenamento, disponibilidade e operações para a stack autogerenciada. Uma redução na cobrança só tem valor se o time entende essas responsabilidades e valida a capacidade de monitoramento de que ainda precisa.
Resultados e medição
A linha de ingestão registrada caiu de £1,165.80 por mês para zero. O equivalente anualizado é £13,989.60, calculado como doze vezes essa redução mensal. A moeda é GBP.
Isso não significa um custo total de monitoramento zero. Compute, armazenamento, manutenção e requisitos futuros de capacidade continuam separados. O valor anualizado é uma estimativa de run-rate, não uma alegação de doze meses de economia realizada, e não é somado a outros totais de economia do portfólio.
A validação cobriu mais de 120 blackbox targets, mais de 20 aplicações com métricas personalizadas, acesso ao Grafana e a configuração de scrape existente. O registro operacional reportou que essas funções foram mantidas após a mudança.
O que eu aprendi
A engenharia de custos começa por identificar o mecanismo cobrável exato. Publicar sua moeda, escopo e trade-off operacional torna o resultado mais útil do que uma grande alegação de economia agregada.
Decisões e próximos passos
Uma visão retrospectiva da abordagem e seus limites. A próxima melhoria é uma proposta, não um resultado entregue.
Alternativa e justificativa
A ingestão gerenciada transfere o trabalho operacional para um provedor; o Prometheus autogerenciado muda o caminho de cobrança e mantém essa responsabilidade com o time.
Trade-off
A redução bruta da linha de cobrança não é uma economia líquida depois de compute, armazenamento e manutenção de engenharia.
O que eu melhoraria em seguida
Próxima melhoria: acompanhar o custo líquido de propriedade e testar periodicamente a recuperação da stack de monitoramento.