Como controlar o custo de observabilidade sem perder visibilidade

Por que o custo de observabilidade cresce tão rápido

O custo explode porque o volume de telemetria cresce mais rápido que a própria infraestrutura, e os modelos de cobrança da maioria das plataformas são por gigabyte ingerido ou por host. Uma equipe rodando Kubernetes em um ambiente multicloud modesto já gera milhões de linhas de log e spans por hora, e nesses modelos de preço o volume se acumula rápido^[3]. A conta da telemetria passa a rivalizar com a conta da nuvem — sem que ninguém tenha decidido isso conscientemente.

Alta cardinalidade: o multiplicador silencioso

Cardinalidade é o número de combinações únicas de labels em uma métrica, e é o que mais infla o custo sem que se perceba. Cada nova dimensão — usuário, requisição, contêiner, versão — multiplica as séries temporais armazenadas. Uma métrica com poucos labels vira milhares de séries quando se adiciona um identificador único. É o custo que cresce em progressão geométrica enquanto a equipe acha que só acrescentou "mais um detalhe".

Retenção longa demais e coleta indiscriminada

Guardar todos os sinais pelo mesmo período longo é uma das maiores fontes de desperdício. A maioria dos logs de debug perde valor em horas ou dias, mas fica meses no armazenamento caro de consulta rápida. Somado a isso, a coleta indiscriminada — instrumentar tudo "para o caso de precisar" — enche o pipeline de dados que nunca serão consultados. Times veem a conta crescer sem um aumento correspondente de insight real^[3].

Duplicação entre ferramentas

Rodar três ou quatro ferramentas desconectadas — métricas em uma, logs em outra, traces em uma terceira — significa muitas vezes coletar o mesmo dado mais de uma vez. Além do custo financeiro de agentes e plataformas sobrepostos, há o custo cognitivo: na hora do incidente, o engenheiro pula entre painéis tentando correlacionar o que deu errado^[3]. A fragmentação é cara duas vezes.

O gancho do câmbio no contexto brasileiro

No Brasil, o custo de telemetria carrega o peso adicional do câmbio, porque boa parte das plataformas é cobrada em dólar. Isso torna o controle de volume ainda mais relevante: cada gigabyte ingerido a mais tem custo direto e sujeito à variação cambial. A disciplina de instrumentar com critério deixa de ser boa prática e vira contenção orçamentária concreta.

Os três sinais: onde é seguro cortar sem perder diagnóstico

Logs, métricas e traces servem a propósitos diferentes, e saber o que cada um responde é o que permite cortar com segurança. Métricas dizem que algo está errado (uma taxa de erro subiu); traces dizem onde (qual serviço na cadeia falhou); logs dizem por quê (a mensagem de erro específica). Cortar sem entender esses papéis é cegar o diagnóstico; cortar entendendo é economizar sem perder visibilidade.

Métricas: o sinal mais barato e o último a cortar

Métricas são agregadas e compactas, o que as torna o sinal mais barato por unidade de valor — e o que você menos quer sacrificar. Elas sustentam dashboards, alertas e SLOs. O ponto de atenção não é o volume bruto, e sim a cardinalidade: uma métrica com labels de alta cardinalidade custa como se fosse muitos milhares de métricas. Controle os labels, não as métricas em si.

Logs: o maior volume e o maior alvo de corte

Logs costumam ser o maior volume e o primeiro lugar para reduzir custo. Boa parte é ruído: mensagens de debug, health checks que sempre passam, logs de acesso repetitivos. A estratégia é filtrar na borda o que não sustenta diagnóstico e aplicar retenção curta ao que é volumoso e de baixo valor duradouro. Logs de erro e de auditoria merecem tratamento diferente de logs de debug.

Traces: alto valor de diagnóstico, alto volume — o caso do sampling

Traces mostram o caminho de uma requisição por vários serviços e são valiosíssimos em investigação distribuída — mas geram volume enorme se cada requisição for gravada. É o sinal onde o sampling faz mais diferença: guardar uma amostra representativa, e todos os traces de erro ou lentidão, entrega quase todo o valor de diagnóstico com uma fração do custo. A OpenTelemetry documenta o sampling justamente como mecanismo de gerenciar volume sem perder representatividade^[1].

OpenTelemetry: instrumentar uma vez, trocar de backend sem reinstrumentar

OpenTelemetry (OTel) é um padrão aberto de instrumentação que desacopla a coleta de telemetria do backend que a armazena e analisa. Com ele, você instrumenta a aplicação uma vez e pode rotear os dados para qualquer plataforma, sem reescrever a instrumentação ao trocar de fornecedor. Isso ataca diretamente o custo de lock-in — a amarração que sustentava boa parte do poder de precificação das plataformas legadas^[3].

Por que OTel reduz o lock-in de fornecedor

Porque a telemetria deixa de ser refém do SDK de um único fornecedor. Quando a instrumentação é padrão, migrar de plataforma não exige tocar no código da aplicação — só reconfigurar o destino dos dados. Na prática, isso permite avaliar plataformas pelo mérito de análise, visualização e alerta, não pela profundidade com que seus agentes estão embutidos no código^[3]. O custo de troca cai, e com ele o poder de a plataforma cobrar caro pela permanência.

O Collector como ponto central de controle de custo

O OpenTelemetry Collector é o componente que recebe, processa e exporta a telemetria — e é onde o controle de custo acontece na prática. É nele que se aplica sampling, filtragem, agregação e roteamento antes de os dados chegarem ao backend pago. Centralizar essas decisões no Collector significa cortar volume na borda, uma vez, para todos os destinos, em vez de pagar para ingerir e só então descartar.

Padrão comum entre times

Adotar OTel como padrão único de instrumentação elimina a divergência entre equipes que cada uma instrumenta do seu jeito. Um padrão comum reduz duplicação, facilita correlação entre sinais e torna a consolidação de ferramentas viável. Os times que acertam observabilidade padronizaram a instrumentação em OpenTelemetry e consolidaram os tipos de sinal em uma plataforma, em vez de rodar stacks paralelas^[3].

Sampling e filtragem na borda

Sampling é a técnica de guardar apenas uma parte representativa dos dados — sobretudo traces — em vez de todos, reduzindo volume sem perder a capacidade de diagnóstico. Combinado com a filtragem de spans e logs de baixo valor no Collector, antes da exportação, é o mecanismo mais direto de controlar custo. A OpenTelemetry descreve duas abordagens principais: head-based e tail-based sampling^[1].

Head-based sampling: decidir no início

No head-based sampling, a decisão de amostrar é tomada no começo do trace, antes de saber como ele termina^[2]. É simples e barato de operar, porque não exige guardar o trace inteiro para decidir. A limitação é que a decisão é "cega" ao desfecho: um trace descartado no início pode ser justamente o que terminou em erro. Funciona bem quando o objetivo é reduzir volume de forma proporcional e previsível.

Tail-based sampling: decidir depois de ver o resultado

No tail-based sampling, a decisão é tomada no fim, depois que o trace completo foi observado — o que permite guardar sempre os traces de erro ou de latência alta e amostrar o resto^[2]. É a abordagem que mais preserva valor de diagnóstico, porque nunca descarta o que interessa. O custo é operacional: exige reter temporariamente os traces até a decisão, o que consome mais recurso no pipeline.

Filtragem de baixo valor no Collector

Além do sampling de traces, o Collector permite descartar na borda o que não sustenta diagnóstico: logs de debug em produção, health checks bem-sucedidos, spans de rotas irrelevantes. Filtrar antes de exportar significa não pagar para ingerir dado que seria descartado depois. É o corte de menor risco, porque atinge justamente o ruído que ninguém consulta.

Retenção em camadas: hot, warm e cold

Retenção em camadas é separar os dados por velocidade de consulta e custo de armazenamento, movendo cada tipo de sinal para a camada certa conforme envelhece. Dados recentes ficam em armazenamento rápido e caro (hot); dados intermediários, em camada de custo médio (warm); dados antigos, em arquivo barato de acesso lento (cold). O princípio é simples: você não paga preço de consulta rápida por um log que ninguém vai olhar de novo.

Hot: consulta rápida, custo alto

A camada hot guarda os dados dos últimos dias, prontos para consulta imediata durante incidentes e investigações recentes. É a mais cara por gigabyte, então deve conter só o que tem chance real de ser consultado com urgência: métricas ativas, logs de erro recentes, traces do período de troubleshooting. Manter tudo em hot "por garantia" é o erro que mais infla a conta.

Warm: intermediário para consulta ocasional

A camada warm serve a dados que ainda podem ser consultados, mas não com a urgência de um incidente ativo — análises de tendência, investigações de semanas atrás. Tem custo e velocidade intermediários. É onde os dados descem automaticamente quando saem da janela quente, preservando acesso razoável a um custo bem menor.

Cold: arquivo barato para retenção longa

A camada cold é o arquivo de baixo custo para dados que precisam existir por conformidade ou histórico, mas raramente são consultados. O acesso é lento e às vezes tem custo de recuperação, o que é aceitável para dado que se guarda "por precaução regulatória". Definir uma política por tipo de sinal — quanto tempo em cada camada — é o que transforma retenção de despesa fixa em custo gerenciado.

Consolidação de ferramentas e instrumentação guiada por SLO

As duas alavancas estruturais de custo são eliminar sobreposição de ferramentas e instrumentar a partir de objetivos de nível de serviço, não de "coletar tudo". A primeira ataca a duplicação; a segunda, a coleta indiscriminada. Juntas, mudam a lógica de "quanto mais dado, melhor" para "o dado certo, no lugar certo, rápido o suficiente para ser útil quando algo quebra"^[3].

Eliminar sobreposição de agentes e plataformas

Consolidar significa mapear onde ferramentas diferentes coletam o mesmo dado e eliminar a redundância. Métricas, logs e traces em plataformas separadas frequentemente duplicam coleta e cobram duas vezes pela mesma informação. Unificar os tipos de sinal em uma plataforma, em vez de rodar stacks paralelas, reduz custo e o esforço de correlação durante incidentes^[3].

Instrumentar guiado por SLO e jornadas críticas

Partir dos SLOs e das jornadas críticas é o que separa instrumentação útil de coleta por medo. Em vez de instrumentar tudo, pergunte: que sinais preciso para saber se estou cumprindo meus objetivos de nível de serviço e para diagnosticar quando não estou? Os times que acertam amarram o investimento em observabilidade a SLOs que importam para o negócio, não a métricas que ficam bonitas no dashboard^[3].

Pagar só pelo que se usa

Boa parte do gasto vai para capacidades que nunca são usadas — integrações, dashboards de conformidade e detecção de anomalia por ML que exigem semanas de ajuste antes de servir^[3]. Revisar o contrato à luz do que a equipe realmente usa, e modelar como a conta escala quando a infraestrutura dobra, é parte do controle de custo tanto quanto o sampling.

Custo por serviço: criar responsabilidade sobre o gasto

Medir quanto cada aplicação ou time gasta em telemetria é o que transforma custo de observabilidade de despesa difusa em responsabilidade atribuível. Sem essa visão, o gasto é "da TI" e ninguém tem incentivo para reduzi-lo; com ela, cada time enxerga o próprio consumo e passa a instrumentar com critério. É a aplicação de FinOps à telemetria: tornar o custo visível para quem o gera.

Showback e chargeback

Showback é mostrar a cada time quanto ele consome, sem cobrar; chargeback é efetivamente ratear o custo para o orçamento de cada área. O primeiro cria consciência; o segundo cria responsabilidade financeira direta. Começar por showback costuma ser suficiente para reduzir desperdício — quando o time vê que um serviço gera desproporcionalmente mais telemetria, a conversa sobre cardinalidade e retenção acontece sozinha.

Observabilidade como produto interno

Em escala maior, tratar observabilidade como produto interno com orçamento próprio muda a governança. Há um dono, um catálogo de capacidades e uma conversa explícita de custo-benefício por serviço. O gasto deixa de ser efeito colateral e vira decisão gerida, com tiers de custo oferecidos internamente e atribuição por time.