- 01Entender
- 02Priorizar
- 03Actuar
A observabilidade começa normalmente como um projecto técnico e termina como uma linha orçamental difícil de explicar. O tráfego aumenta, aparecem novas marcas e ninguém sabe quais dados realmente consulta. Reduzir custos de observabilidade não significa apagar sinais: significa pagar por evidência útil.
De onde vem a factura
De acordo com o fornecedor e o modelo de desenvolvimento, o custo pode depender de:
- GB ingeridos de logs, traços e perfis.
- Series métricas ativas e cardinalidade.
- Hosts, contentores ou serviços observados.
- Retenção e armazenamento.
- Consultas e dados analisados.
- Transferência entre regiões ou nuvens.
- Infra-estrutura e pessoal de um estágio auto-gestionado.
O primeiro passo é traduzir a factura para unidades técnicas. Sem essa relação, os equipamentos não podem alterar o seu comportamento.
1. Criar um orçamento de telemetria
Atribui visibilidade de volume e custo por serviço, equipamento, ambiente e sinal. Cada owner deve conhecer:
- GB diários de registos e traços.
- Series métricas ativas.
- Retenção aplicada.
- Principales etiquetas por cardinalidade.
- Dashboards, alertas e consultas que utilizam esses dados.
O objectivo não é cobrar internamente desde o primeiro dia, mas mostrar causa e efeito.
2. Controlar cardinalidade antes de filtrar os dados
Uma métrica cria uma série por combinação de etiquetas. Adicionar user_id, URL completo ou request ID pode produzir milhares ou milhões de combinações.
Acções de alto impacto:
- Configuração das rotas:
/orden/{id}. - Remover os IDs únicos das marcas.
- Verificar os ciclos de histogramas.
- Evitar dimensões que nunca sejam agrupadas pelo filtro.
- Definir testes de cardinalidade em instrumentação.
Os valores únicos podem ser conservados em registos ou em spans, se necessários para uma investigação.
3. Conceber logs por níveis de valor
Nem todos os registos merecem a mesma retenção.
| Nível | Exemplo | Estratégia |
|---|---|---|
| Crítico | Segurança, auditoria, transacção | Alta integridade e retenção definida |
| Operativo | Erros e Mudanças de Estado | Investigação rápida e manutenção média |
| Diagnóstico | Depuração Detalhada | Ativação temporária ou retenção curta |
| Ruído | Health checks repetitivos | Agregação, Metrica ou Descartamento |
Um log que é emitido milhares de vezes por minuto e nunca consultado é uma cobertura: é dívida.
4. Aplicar amostragem em contexto
O head sampling decide no início do traço e reduz o processamento. O tail sampling decide quando sabe o resultado e pode priorizar:
- Erros.
- Latência elevada.
- Serviços críticos.
- Clientes ou regiões estratégicas.
- Eventos raros.
- Uma amostra do tráfego saudável.
A política deve ser testada com incidentes conhecidos, uma percentagem fixa para todo o tráfego é simples, mas pode eliminar justamente a transacção que é necessária para investigar.
5. Separar a retenção operacional e histórica
Os últimos dias exigem consultas rápidas. Os dados antigos podem ser movidos para armazenamento mais económico ou adicionar.
Definai a retenção por pergunta:
- Quanto tempo demora a detectar um incidente?
- Que período exige auditoria ou regulamentação?
- Que tendência precisa de dados crus e qual aceita agregados?
- Existe um procedimento para recuperar arquivos frios?
Manter “por dúvidas” não substitui uma política.
6. Filtrar a fonte de origem
Enviar dados desnecessários para descartá-los depois de consumir a rede e a ingestão. OpenTelemetry Collector pode filtrar, transformar, redactar e amostrar antes do mecanismo.
No entanto, as regras centralizadas devem ser versadas e observadas. Um filtro errado pode esconder provas em todos os serviços ao mesmo tempo.
7. Revisar dashboards e alertas órfãos
Inventaria quem usa cada dashboard, alerta e fonte. Um recurso sem owner ou consultas por meses é candidato para arquivo ou remoção controlada.
A revisão também descobriu duplicações: a mesma telemetria enviada a duas plataformas durante uma migração pode permanecer anos.
Metrica-chave: custo por serviço observável
Relaciona custo com serviço, volume e valor. Algumas aplicações críticas justificam telemetria profunda; outras só requerem disponibilidade e erros.
Um indicador útil combina:
- Custo mensal por serviço.
- Percentagem de incidentes onde a telemetria foi utilizada.
- Tempo médio para encontrar a causa.
- Volumes sem consultas.
- Mudança de custos por relevo do crescimento de tráfego.
Unidade Económica de Telemetria
O custo absoluto cresce naturalmente com o negócio. Para saber se está fora de controlo, relaciona o consumo com uma unidade estável: milhões de transacções, mil utilizadores ativos, serviço crítico ou deployment.
Se o custo por milhão de requests subir, embora o stack não mude, investigue novas marcas, registos repetitivos ou menor eficiência de amostragem. Se baixa, confirme que a cobertura e o tempo de diagnóstico não pioraram.
Esta métrica permite conversar com as Finanças sem reduzir a discussão a “a ferramenta é cara”. Também ajuda a projetar cenários de crescimento e a negociar compromissos baseados em volume real.
Plano de redução em 30 dias
- Dias 1–5: mapear unidades de cobrança e topo consumidores.
- Dias 6–10: corrigir cardinalidade extrema.
- Dias 11–15: eliminar registos repetitivos e depuração permanente.
- Dias 16–20: projeto de amostragem e detenção por crítica.
- Dias 21–25: arquivar dashboards e pipelines sem owner.
- Dias 26-30: estabelecer orçamentos e alertas de consumo.
Cada alteração deve ser comparada com um teste de diagnóstico para verificar que não se perdem evidências essenciais.
Você vai guardar uma linha base antes de optimizar: volume, custo, tempo de consulta e capacidade de resolver três incidentes conhecidos. Repeti as mesmas pesquisas depois. A poupança é válida apenas se a evidência continua disponível no tempo que a operação precisa.
Próximo passo
CTL pode realizar um assessamento de custos, cardinalidade e cobertura sobre plataformas comerciais ou open source. Agenda uma revisão para identificar poupanças sem comprometer o SLOs nem resposta a incidentes.
Perguntas frequentes
Open source elimina o custo?
Remove ou reduz licenças, mas mantém o cálculo, armazenamento, rede, alta disponibilidade, upgrades e horas de especialistas. Deve ser comparado o custo total.
Importa-se remover os registos de health checks?
Muitas vezes podem ser convertidos em métricas ou amostrados, mas primeiro, é necessário verificar se estão a cumprir uma função de auditoria ou diagnóstico.
Quem deve governar o custo?
Uma prática de plataforma ou observabilidade pode definir padrões, mas os equipamentos donos de serviços devem ver e controlar o seu consumo.