Custos de observabilidade: por que a conta cresce e como aplicar FinOps
A fatura da plataforma de observabilidade subiu de novo. No entanto, ninguém ligou servidor novo, ninguém migrou de datacenter, ninguém contratou módulo adicional. Esse descompasso se repete todo trimestre em equipes de TI brasileiras.
A explicação é curta: você não paga por infraestrutura, paga por telemetria. Ou seja, a conta acompanha o volume de dados que seus sistemas produzem, não a quantidade de máquinas que você opera. Por isso ela cresce sozinha.
Este guia trata o gasto com observabilidade como aquilo que ele é: um centro de custo que precisa de governança. Em seguida, percorremos os modelos de cobrança do mercado e os drivers de gasto de cada pilar. Por fim, chegamos às alavancas de redução que preservam a capacidade de diagnóstico.
O que são custos de observabilidade
Custos de observabilidade são o gasto total para coletar, transportar, armazenar e consultar a telemetria de um ambiente de TI. Eles reúnem a assinatura da plataforma, a infraestrutura de coleta, o armazenamento por retenção e o tempo de engenharia de sustentação. Atenção: esse gasto não se confunde com o custo da nuvem que ele ajuda a reduzir.
A distinção parece sutil, porém muda tudo na hora de defender orçamento. Uma coisa é o dinheiro que a empresa gasta com AWS, Azure ou VMware. Outra, bem diferente, é o dinheiro que a empresa gasta para enxergar o que acontece dentro desses ambientes.
Na prática, os dois orçamentos costumam viver na mesma linha de planilha. Como resultado, ninguém percebe que a segunda parcela cresce em ritmo próprio. Ela obedece a uma lógica que não tem relação direta com o tamanho do parque de servidores.
Por que a conta de observabilidade cresce mais rápido que a infraestrutura
Existe um descolamento estrutural entre as duas curvas. Enquanto o orçamento de infraestrutura acompanha máquinas, núcleos e discos, o preço da observabilidade acompanha eventos por segundo. Quando a arquitetura muda, a segunda curva dispara sem que a primeira se mexa.
Pense no que acontece ao quebrar um monólito em quarenta microsserviços. O número de servidores pode até permanecer estável. Todavia, cada requisição que antes gerava um log agora gera dezenas de spans, atravessa vários serviços e produz métricas em cada salto.
Containers agravam o efeito. A pesquisa anual da CNCF mostra 82% dos usuários de contêineres rodando Kubernetes em produção, contra 66% em 2023.
Cada pod efêmero nasce, emite telemetria, morre e deixa séries temporais para trás. Ao mesmo tempo, o orquestrador cria e destrói réplicas o dia inteiro, sem que ninguém aprove uma linha de orçamento.
Cargas de inteligência artificial adicionam uma camada nova. Elas instrumentam prompts, tokens, latência de inferência e qualidade de resposta, tudo com granularidade alta. Dessa forma, um único serviço de IA pode gerar mais telemetria que um datacenter inteiro de dez anos atrás.
O cenário financeiro reforça a urgência. O levantamento anual sobre gastos em nuvem registrou 29% de desperdício em 2026. Na mesma pesquisa, 85% das organizações apontam a gestão de gastos como principal desafio.
Trata-se da primeira alta em cinco anos. Ou seja, o custo já lidera a agenda de infraestrutura, mesmo antes de alguém olhar para a linha da telemetria.
Os modelos de cobrança do mercado e o que cada um pune
Não existe preço único de observabilidade porque não existe unidade única de cobrança. Cada fornecedor escolhe uma métrica de faturamento. Essa escolha define qual comportamento da sua equipe sai caro. Antes de tudo, identifique em qual modelo o seu contrato se encaixa.
| Modelo de cobrança | Unidade que gera a fatura | O que este modelo pune |
|---|---|---|
| Por host | Cada host ou nó monitorado, medido por hora ou por mês |
Ambientes com muitas máquinas pequenas: cada réplica e cada nó efêmero entra na contagem |
| Por volume ingerido | Cada GB que entra na plataforma, medido na ingestão |
Verbosidade: log de debug esquecido em produção vira fatura antes de virar diagnóstico |
| Por série ativa | Cada série temporal única, cobrada como custom metric |
Cardinalidade: um label com identificador de usuário multiplica séries sem gerar informação nova |
| Por retenção | Preço escalonado por janela de guarda: 30, 60 ou 90 dias |
Política única para tudo: guardar log de acesso pelo mesmo prazo do log de auditoria |
| Por consulta | Volume de dados varrido a cada busca ou painel aberto | Investigação: quem mais usa a ferramenta para diagnosticar gera a maior conta do mês |
| Por usuário | Licença nominal de acesso à interface da plataforma | Difusão da cultura: convidar o time de produto para acompanhar os painéis custa dinheiro |
A maioria dos contratos corporativos combina três ou quatro desses modelos ao mesmo tempo. Por conseguinte, a fatura deixa de ser previsível: ela passa a depender de decisões técnicas tomadas por desenvolvedores que nunca viram o contrato.
Onde o custo nasce: os drivers de cada pilar
Cada pilar da telemetria engorda a conta por um motivo distinto. Antes de cortar qualquer coisa, vale entender qual deles domina o seu gasto. Do contrário, você economiza no lugar errado e perde visibilidade sem reduzir a fatura.
Métricas: cardinalidade e frequência de coleta
Métricas parecem baratas porque cada ponto ocupa poucos bytes. Contudo, o custo não vem do tamanho do ponto, vem da quantidade de séries. Cada combinação única de labels cria uma série nova que precisa ser indexada, armazenada e mantida em memória.
Adicionar um label com identificador de sessão a uma métrica aparentemente inofensiva multiplica séries por milhares. Esse mecanismo, conhecido como explosão de cardinalidade, é o driver que mais surpreende times técnicos. A frequência de coleta age no mesmo sentido: reduzir o intervalo de 60 para 10 segundos sextuplica o volume.
A escolha do backend também pesa aqui. Bancos de séries temporais têm eficiências de compressão bem diferentes, o que altera o custo por série armazenada. Comparar as opções antes de fechar contrato, como na análise entre VictoriaMetrics e Prometheus, evita decisões caras de reverter depois.
Logs: verbosidade e indexação
Logs costumam liderar a fatura de observabilidade na maioria das empresas. Eles carregam texto livre, repetem contexto a cada linha e crescem de forma proporcional ao tráfego da aplicação. Um pico de acessos vira um pico de custo no mesmo instante.
O maior desperdício aqui tem nome: nível DEBUG ligado em produção. Times ativam o modo verboso para investigar um incidente, resolvem o problema e esquecem de desligar. Depois disso, a empresa paga meses por dados que ninguém consulta.
A indexação amplifica tudo. Plataformas que indexam todos os campos entregam busca instantânea a um preço alto, enquanto arquiteturas que indexam apenas metadados custam bem menos. Esse trade-off aparece com clareza na comparação entre Loki e Elasticsearch.
Traces: spans por transação
Rastros distribuídos são o pilar mais caro por evento. Uma única requisição de checkout pode gerar sessenta spans ao atravessar autenticação, catálogo, estoque, pagamento e notificação. Multiplique isso pelo volume transacional do seu negócio.
Por isso, praticamente nenhuma operação madura ingere 100% dos traces. As estratégias de amostragem definem quais rastros chegam ao backend, seja por probabilidade fixa, seja por decisão tomada após o trace completo. Escolher bem essa política costuma valer mais que trocar de fornecedor.
Os custos ocultos que não aparecem na proposta comercial
A proposta que chega ao comitê raramente mostra o custo real do primeiro ano. Vários itens ficam fora da apresentação inicial, embora apareçam na fatura logo nos primeiros meses de uso.
O primeiro deles é a taxa de excedente. Contratos com pacote fechado cobram tarifa diferenciada quando o volume ultrapassa o limite contratado. Essa tarifa costuma ser bem superior ao preço unitário negociado. Um incidente longo pode estourar o pacote do mês inteiro.
Outro item recorrente é a cobrança pelo pico. Alguns modelos faturam pelo maior consumo registrado no período, não pela média. Assim, uma campanha de Black Friday define o preço dos meses seguintes, mesmo que o tráfego volte ao normal em dezembro.
Há ainda a sobreposição de produtos. Empresas acumulam ferramentas por herança de projetos. Assim, o mesmo dado acaba coletado, transmitido e pago duas ou três vezes, porque cada ferramenta cobra a própria ingestão.
Por fim, existe o desperdício mais invisível de todos: telemetria coletada, paga e nunca consultada. Dashboards órfãos, métricas sem alerta associado e painéis criados para uma auditoria antiga seguem consumindo orçamento. Revisar quais indicadores de observabilidade realmente sustentam decisão elimina boa parte desse peso morto.
Como reduzir custos de observabilidade sem perder capacidade de diagnóstico
As alavancas abaixo aparecem em ordem de retorno sobre esforço. Comece pelas primeiras, que entregam economia rápida sem risco operacional. Depois disso, avance para as demais conforme a governança amadurece.
- Desligue o que ninguém olha. Levante dashboards sem acesso nos últimos 90 dias e métricas sem alerta associado. Corte primeiro o que não tem dono.
- Ajuste os níveis de log em produção. Padronize
INFOcomo padrão, reserveDEBUGpara janelas de investigação e configure expiração automática desse modo. - Filtre e agregue na origem. Use o coletor para descartar eventos de baixo valor antes da ingestão. Converter eventos repetitivos em contadores reduz volume sem perder o sinal.
- Aplique retenção por criticidade. Nem todo dado merece 90 dias. Defina camadas quente, morna e fria conforme a probabilidade real de consulta.
- Reduza cardinalidade na instrumentação. Proíba identificadores únicos como labels de métrica. Esse tipo de dado pertence a log ou trace, nunca a série temporal.
- Calibre a amostragem de traces. Mantenha a captura integral para erros e transações críticas, amostre o tráfego saudável de rotina.
- Consolide ferramentas redundantes. Duas plataformas coletando o mesmo dado significam duas faturas para o mesmo evento.
O ponto de apoio técnico de quase todas essas alavancas é a camada de coleta. Um pipeline baseado em OpenTelemetry permite filtrar, agregar e rotear telemetria antes que ela chegue ao backend pago.
A documentação oficial do Collector detalha os processadores disponíveis para essa tarefa. Vale começar pelos que descartam atributos de alta cardinalidade.
Vale ressaltar um cuidado. Cortar telemetria sem critério aumenta o tempo de diagnóstico, o que devolve em indisponibilidade tudo o que você economizou em licença. A meta nunca é ingerir menos, a meta é ingerir apenas o que sustenta decisão.
Quanto sua empresa deveria gastar em observabilidade
Não existe percentual de referência auditável para o gasto com observabilidade. Circulam pela internet faixas de proporção sobre o custo de nuvem, quase sempre atribuídas a grandes relatórios de mercado. Ao procurar o dado no relatório citado, porém, o número simplesmente não está lá.
Portanto, desconfie de qualquer benchmark que você não consiga rastrear até a página do relatório citado. O caminho honesto é outro: construir a sua própria linha de base e acompanhar a tendência dela ao longo do tempo.
Comece medindo três razões simples. Primeiro, o gasto mensal de observabilidade dividido pelo gasto total de infraestrutura. Depois, o gasto dividido pelo número de serviços realmente monitorados. Por último, o gasto dividido pelo volume de transações do negócio no mesmo período.
Essas três razões contam histórias diferentes. Se a primeira sobe enquanto a terceira cai, a operação está ficando mais eficiente por transação, embora mais pesada por servidor. Em síntese, a tendência importa mais que o valor absoluto de qualquer mês isolado.
FinOps de observabilidade: da economia pontual à prática contínua
Qualquer equipe consegue cortar a fatura uma vez. O desafio real é impedir que ela volte ao patamar anterior em seis meses. Isso acontece quando a próxima leva de serviços entra em produção sem critério de instrumentação.
É exatamente esse o papel da prática de FinOps aplicada à telemetria. Ela transporta para a observabilidade os mesmos princípios usados na nuvem: visibilidade de gasto, alocação por responsável e ciclo contínuo de otimização. A diferença está na unidade governada.
O primeiro passo é a alocação. Atribua cada gigabyte ingerido e cada série ativa ao time que a gerou, através de tags de propriedade. Enquanto o custo permanecer anônimo, ninguém tem incentivo para instrumentar com parcimônia.
Em seguida vem o showback. Envie mensalmente a cada squad o próprio consumo de telemetria, com a variação em relação ao mês anterior. Times que enxergam o próprio número tendem a se autorregular antes de qualquer política restritiva.
O terceiro elemento é o orçamento com alerta. Defina um teto de telemetria por time e dispare notificação quando o consumo projetado ultrapassar a meta. Assim, a conversa acontece no dia 12, não no fechamento da fatura.
Por fim, feche o ciclo com um indicador de valor. Acompanhe quantos incidentes reais aquela telemetria ajudou a detectar e resolver. Uma operação de observabilidade bem estruturada justifica o próprio orçamento com dados, não com opinião.
Reduza o desperdício cloud sem abrir mão da performance com FinOps.
Mapeamos, alocamos e otimizamos seus gastos em nuvem com dashboards de FinOps e relatórios de custo por equipe e por projeto.
Conclusão
Os custos de observabilidade crescem porque estão indexados ao volume de telemetria, não ao tamanho do parque de servidores. Microsserviços, containers e cargas de IA aceleram essa curva sem que ninguém aprove uma linha nova de orçamento. Reconhecer esse mecanismo já muda a conversa com o financeiro.
A partir daí, o caminho fica claro. Descubra qual modelo de cobrança rege o seu contrato, identifique o pilar que domina o seu gasto e aplique as alavancas na ordem de retorno. Comece pelo que ninguém consulta, avance para retenção por criticidade e só então discuta fornecedor.
Acima de tudo, transforme o corte em prática. Alocação por time, showback mensal e orçamento com alerta impedem que a economia evapore no próximo trimestre. Observabilidade não é um gasto a minimizar, é um investimento a governar.
Quer entender quanto da sua telemetria realmente sustenta decisão? Fale com um especialista da OpServices e receba um diagnóstico do seu ambiente.
Perguntas Frequentes
Quanto custa uma plataforma de observabilidade?
Como reduzir custos de observabilidade sem perder visibilidade?
INFO e reserve DEBUG para janelas curtas de investigação. Depois, filtre e agregue a telemetria no coletor antes da ingestão, aplique retenção diferente por criticidade do dado e calibre a amostragem de traces mantendo 100% para erros. Por último, consolide ferramentas que coletam o mesmo dado. A meta não é ingerir menos, é ingerir apenas o que sustenta decisão.O que é FinOps de observabilidade?
Qual a diferença entre cobrança por host e cobrança por GB ingerido?
GB ingerido fatura o volume de dados que chega à plataforma, independentemente de quantas máquinas o geraram. O modelo por host pune ambientes com muitas máquinas pequenas, como clusters Kubernetes cheios de pods efêmeros. O modelo por volume pune a verbosidade, principalmente logs de debug esquecidos em produção. Ambientes enxutos com aplicações falantes sofrem mais no segundo modelo.