Estratégias de retenção de dados de observabilidade para reduzir custo

1. Fundamentos do custo de retenção em observabilidade

1.1. Onde o custo se acumula: armazenamento, processamento e ingestão

Em sistemas de observabilidade modernos, o custo não está apenas no armazenamento persistente. Três componentes principais consomem orçamento:

  • Ingestão: cada log, métrica ou trace enviado consome largura de banda e CPU no pipeline de coleta.
  • Processamento: índices, agregações e transformações em tempo real exigem recursos computacionais.
  • Armazenamento: dados retidos ocupam espaço em disco ou object storage, com custo crescente conforme o volume.

Exemplo de cálculo de custo mensal estimado:

Volume de logs: 500 GB/dia
Custo de ingestão: R$ 0,05/GB
Custo de armazenamento: R$ 0,02/GB/mês

Custo mensal de ingestão: 500 GB × 30 dias × R$ 0,05 = R$ 750
Custo mensal de armazenamento (30 dias): 500 GB × 30 × R$ 0,02 = R$ 300
Custo total: R$ 1.050/mês

1.2. Diferença entre retenção de logs, métricas e traces

Cada tipo de dado tem características de custo distintas:

Tipo Volume típico Granularidade Custo principal
Logs Alto Texto bruto Ingestão + armazenamento
Métricas Médio Numérico Cardinalidade
Traces Baixo a médio Estrutura de spans Processamento

1.3. Impacto financeiro de políticas de retenção padrão

Políticas genéricas como "reter tudo por 90 dias" geram desperdício. Exemplo comparativo:

Política padrão (90 dias):
- Armazenamento: 500 GB/dia × 90 dias = 45 TB
- Custo: 45 TB × R$ 20/TB = R$ 900/mês

Política otimizada (30 dias críticos + 90 dias agregados):
- Armazenamento: (500 GB × 30) + (50 GB agregados × 60) = 18 TB
- Custo: 18 TB × R$ 20/TB = R$ 360/mês
- Economia: 60%

2. Segmentação de dados por criticidade

2.1. Classificação de sinais em níveis

Organize os dados em três categorias:

  • Crítico: erros de produção, falhas de segurança, indisponibilidade de serviço
  • Importante: warnings, métricas de performance, logs de auditoria
  • Informativo: logs de debug, métricas de desenvolvimento, traces de endpoints pouco usados

2.2. Definição de TTL diferenciado por classe de serviço

Exemplo de configuração no OpenTelemetry Collector:

processors:
  attributes/critical:
    actions:
      - key: retention_days
        value: 365
        action: insert

  attributes/important:
    actions:
      - key: retention_days
        value: 90
        action: insert

  attributes/informative:
    actions:
      - key: retention_days
        value: 30
        action: insert

2.3. Estratégia de descarte automático de dados de ambientes não produtivos

Ambientes de desenvolvimento e staging raramente precisam de retenção longa:

# Política de descarte para ambientes não produtivos
Ambiente: staging
Retenção de logs: 7 dias
Retenção de métricas: 14 dias
Retenção de traces: 3 dias
Descarte automático: ativado após TTL

Ambiente: produção
Retenção de logs: 90 dias (crítico), 30 dias (informativo)
Retenção de métricas: 365 dias (sumarizado)
Retenção de traces: 30 dias (amostrado)

3. Amostragem inteligente e agregação

3.1. Técnicas de amostragem head-based vs. tail-based para traces

  • Head-based: decide amostrar no início do trace. Simples, mas pode perder erros raros.
  • Tail-based: amostra após identificar erros. Mais preciso, porém consome mais memória.

Configuração de amostragem head-based no OpenTelemetry:

processors:
  probabilistic_sampler:
    sampling_percentage: 10
    hash_seed: 42

3.2. Agregação de métricas de alta cardinalidade

Métricas com muitos labels (ex: user_id, request_id) inflacionam custos. Use sumários:

# Antes (alta cardinalidade):
http_requests_total{user_id="123", endpoint="/api", status="200"} 1

# Depois (agregado):
http_requests_total{endpoint="/api", status="200"} 1500

3.3. Redução de logs verbosos com filtros de nível

Configure pipelines para descartar logs de baixa relevância:

processors:
  filter/log_level:
    logs:
      include:
        match_type: regexp
        severity:
          - ERROR
          - WARN
      exclude:
        match_type: strict
        severity:
          - DEBUG
          - INFO

4. Políticas de rotação e compressão

4.1. Compactação de dados frios

Algoritmos eficientes para dados de observabilidade:

# Comparação de compressão para logs JSON
Formato original: 100 MB
Zstandard (nível 3): 12 MB (88% de redução)
Snappy: 18 MB (82% de redução)
Gzip (nível 6): 15 MB (85% de redução)

4.2. Implementação de tiered storage

Estratégia de armazenamento em camadas:

Camada quente (7 dias):
  - Armazenamento: SSD NVMe
  - Latência: < 10ms
  - Custo: R$ 100/TB/mês

Camada morna (30 dias):
  - Armazenamento: HDD 10K RPM
  - Latência: < 50ms
  - Custo: R$ 30/TB/mês

Camada fria (90+ dias):
  - Armazenamento: Object Storage (S3/MinIO)
  - Latência: > 100ms
  - Custo: R$ 10/TB/mês

4.3. Automação de arquivamento para buckets S3

Script de arquivamento automático:

#!/bin/bash
# Arquiva dados com mais de 30 dias para S3
DATA_ANTIGA=$(date -d "30 days ago" +%Y-%m-%d)

for INDEX in "logs-*" "metrics-*" "traces-*"; do
  curl -X POST "http://localhost:9200/${INDEX}/_rollover" \
    -H "Content-Type: application/json" \
    -d '{
      "conditions": {"max_age": "30d"},
      "actions": {
        "archive": {
          "repository": "s3_backup",
          "snapshot": "'${INDEX}-${DATA_ANTIGA}'"
        }
      }
    }'
done

5. Uso de sumarização e dashboards de retenção

5.1. Criação de métricas derivadas de logs e traces

Transforme logs brutos em métricas agregadas:

# Métrica derivada de logs de erro
error_rate_per_minute{service="api", endpoint="/login"} 0.05

# Métrica derivada de traces
p95_latency_ms{service="api", endpoint="/login"} 245

5.2. Substituição de dados brutos por agregados temporais

Configure rollups automáticos:

# Agregação por minuto → hora → dia
rollup_policy:
  raw: 7 dias (retenção completa)
  hourly: 30 dias (média, máximo, mínimo)
  daily: 365 dias (média, p95, p99)

5.3. Monitoramento do volume de armazenamento com alertas de custo

Dashboard de monitoramento:

# Métricas de custo por serviço
service_storage_bytes{service="api"} 50000000000
service_storage_cost{service="api"} 1000

# Alerta quando custo excede orçamento
ALERT HighStorageCost
  IF service_storage_cost > 5000
  FOR 1h
  LABELS { severity = "critical" }
  ANNOTATIONS { summary = "Custo de armazenamento acima do orçamento" }

6. Ferramentas open source para gestão de retenção

6.1. Configuração de retenção no Signoz e Thanos

Exemplo de política no Thanos:

# thanos-compactor retention
retention:
  raw: 30d
  downsample:
    5m: 90d
    1h: 365d

6.2. Uso de retention policies no OpenTelemetry Collector

Configuração avançada:

processors:
  batch:
    timeout: 1s
    send_batch_size: 10000

  memory_limiter:
    check_interval: 1s
    limit_mib: 512

  attributes/retention:
    actions:
      - key: ttl_days
        value: 30
        action: upsert

6.3. Automação com scripts e cron jobs para limpeza programada

Script de limpeza agendada:

# /etc/cron.d/observability-cleanup
0 2 * * * root /usr/local/bin/cleanup-old-data.sh

# cleanup-old-data.sh
#!/bin/bash
# Remove dados mais antigos que 90 dias
find /data/observability/ -type f -name "*.log" -mtime +90 -delete
find /data/observability/ -type f -name "*.json" -mtime +90 -delete
echo "$(date): Limpeza concluída" >> /var/log/cleanup.log

7. Governança e revisão contínua de custos

7.1. Estabelecimento de SLAs de retenção por time e serviço

Documento de governança:

SLA de Retenção - Time de Pagamentos
- Logs de produção: 90 dias (crítico), 30 dias (informativo)
- Métricas: 365 dias (sumarizado)
- Traces: 30 dias (amostragem 10%)
- Budget mensal: R$ 2.000

7.2. Auditoria periódica de cardinalidade e volume de dados

Checklist mensal:

1. Identificar métricas com > 1000 labels únicos
2. Revisar logs com > 1 GB/dia por serviço
3. Verificar traces com > 100 spans por requisição
4. Comparar custo real vs. orçado
5. Ajustar políticas de amostragem

7.3. Estratégia de rollback e ajuste fino de políticas

Processo de revisão:

1. Coletar métricas de uso por 7 dias
2. Identificar dados não consultados
3. Reduzir TTL desses dados em 50%
4. Monitorar impacto por 14 dias
5. Se sem reclamações, aplicar redução permanente
6. Se necessário, reverter para política anterior

Referências