Observabilidade tem custos reais: armazenamento de
log, cardinality de métrica, overhead de tracing.
As decisões abaixo forçam a articular onde investir
e onde economizar — porque instrumentar tudo com
máxima granularidade é economicamente inviável em
escala.
Stack open source (Prometheus + Loki + Jaeger) ou plataforma comercial (Datadog)?
Stack open source tem custo de infra e custo de
operação (alguém precisa manter Prometheus, Loki,
Jaeger, Grafana, Alertmanager). Plataforma comercial
tem custo por host/volume/usuário que escala
rapidamente — Datadog a $23/host/mês vira $23.000/mês
com 1.000 hosts. A decisão muda por tamanho: times
pequenos (<10 engenheiros, <50 hosts) pagam
menos com Datadog; times maiores frequentemente
economizam operando o próprio stack. A exceção é
quando a plataforma comercial fornece capacidade
que o open source não tem (Dynatrace Davis AI,
Datadog watchdog) — aí o trade-off muda.
Head-based ou tail-based sampling para tracing?
Head-based: decisão de samplear é tomada no início
da requisição, antes de saber o resultado. Simples,
baixo overhead. Problema: amostras aleatórias perdem
requisições lentas ou com erro (que são exatamente
as mais interessantes) se a taxa de erro for baixa.
Tail-based: decisão é tomada após a requisição
completar — amostrar 100% de erros e requisições
lentas, baixa taxa de requisições normais. Mais
útil, mas requer infraestrutura de tail sampling
(OTel Collector com tail sampling processor). Para
começar, head-based a 10-20% captura suficiente.
Tail-based quando taxa de erro é baixa e você precisa
de cobertura completa de casos de interesse.
Quantos logs é demais?
Logs têm custo duplo: geração (CPU e I/O) e
armazenamento (ingestion em Elasticsearch custa
por GB). Sem estratégia, sistemas em produção
geram gigabytes por hora de logs que nunca são
consultados. As práticas da indústria: DEBUG
desabilitado em produção por padrão; sampling
de logs de sucesso (só 1 em 100 requisições
OK gera log completo, 100% das requisições com
erro gera log); campos estruturados de alta
cardinalidade (user_id, trace_id) apenas quando
necessários. Regra prática: se um tipo de log
nunca foi pesquisado em 30 dias, é candidato
a remoção.
Instrumentação automática ou manual com OpenTelemetry?
Instrumentação automática (agente OTel, bytecode
instrumentation em Java, auto-instrumentation em
Python) captura spans de bibliotecas conhecidas
(HTTP, banco, fila) sem escrever código. Cobre
80% do que você precisa com zero esforço.
Instrumentação manual adiciona spans de negócio
que a automação não captura: "tempo de avaliar
regra de desconto", "tempo de montar resposta
personalizada". A estratégia correta é automática
como base, manual para os caminhos de negócio que
realmente precisam de visibilidade — não instrumentar
manualmente tudo, porque vira manutenção.
Alerta por anomalia ou por threshold?
Threshold estático (latência > 500ms) é simples
mas gera falsos positivos em sazonalidade normal
(pico de segunda-feira) e falsos negativos quando
o problema está abaixo do threshold mas é anômalo
para aquela hora. Alertas baseados em SLO e burn
rate (módulo 08) resolvem parte disso. Alertas por
anomalia (Datadog Watchdog, Google Cloud Anomaly
Detection) detectam desvios do padrão histórico
sem threshold fixo — mais sensíveis, mais falsos
positivos em sistemas com sazonalidade alta. A
combinação prática: SLO burn rate para alertas
primários (baixo ruído, alta precisão), anomaly
detection como sinal secundário de investigação.