Monitoramento de aplicações pós-deploy

1. Fundamentos do monitoramento pós-deploy

Monitorar uma aplicação imediatamente após um deploy é radicalmente diferente do monitoramento contínuo de produção. Enquanto o monitoramento rotineiro busca estabilidade ao longo do tempo, o monitoramento pós-deploy precisa detectar rapidamente regressões, comportamentos inesperados e degradações introduzidas pela nova versão.

Os Quatro Sinais de Ouro do monitoramento — latência, taxa de erro, throughput e saturação — ganham ainda mais relevância nesse contexto. Uma mudança de 50ms na latência pode ser aceitável em horário normal, mas catastrófica se introduzida por um deploy às 14h de uma Black Friday.

Existem duas abordagens complementares:

  • Monitoramento sintético: scripts que simulam interações do usuário em intervalos regulares. Ideal para detectar falhas antes que usuários reais sejam afetados.
  • Monitoramento real de usuários (RUM): coleta dados de navegação real. Captura problemas que afetam apenas grupos específicos (navegadores, localizações, dispositivos).
# Exemplo de métrica sintética pós-deploy
métrica: "synthetic_check_latency_ms"
versão_deploy: "v2.3.1"
timestamp: 1696000000
valor: 245
threshold_baseline: 180
status: "ALERTA - 36% acima do baseline"

2. Configuração de alertas inteligentes para novos deploys

Alertas com limites fixos são inadequados para o período pós-deploy. Uma aplicação que naturalmente tem latência de 200ms durante picos não deve disparar o mesmo alerta que uma versão que subitamente passou de 50ms para 200ms.

Estratégias recomendadas:

  • Baseline histórico: calcular média móvel das últimas 24h ou 7 dias, ajustando sazonalidade.
  • Canary monitoring: comparar métricas da nova versão com a versão estável em tempo real.
  • Thresholds adaptativos: usar desvio padrão percentual (ex: alertar se métrica ultrapassar 3σ do baseline).
# Regra de alerta adaptativo para pós-deploy
alerta: "latencia_nova_versao"
condição: |
  avg by (versao) (http_request_duration_seconds{
    versao="v2.3.1"
  }) > 
  avg by (versao) (http_request_duration_seconds{
    versao="v2.3.0"
  }) * 1.5
duração: "5m"
severidade: "critical"

Para evitar fadiga de alerta, agregue temporalmente: um pico de 2 segundos não exige ação, mas 10 minutos de degradação contínua sim.

3. Observabilidade distribuída: logs, métricas e traces

A observabilidade pós-deploy exige correlação entre logs, métricas e traces. OpenTelemetry é o padrão para instrumentar código e gerar spans que rastreiam requisições completas.

# Instrumentação com OpenTelemetry (pseudo-código)
tracer = opentelemetry.trace.get_tracer("meu-servico")
with tracer.start_as_current_span("processar_pedido") as span:
    span.set_attribute("versao.deploy", "v2.3.1")
    span.set_attribute("usuario.id", user_id)
    resultado = processar_pedido(dados)
    span.set_attribute("resultado.status", resultado.status)

Centralização de logs: todo log deve conter a tag da versão do deploy. Ferramentas como Loki ou Elasticsearch permitem filtrar rapidamente por versao="v2.3.1".

Dashboards dinâmicos: crie painéis que aceitam variáveis como $versao, permitindo comparar visualmente a nova versão com a anterior.

# Query PromQL para dashboard dinâmico
rate(http_requests_total{versao="$versao", status=~"5.."}[5m])
/
rate(http_requests_total{versao="$versao"}[5m])

4. Monitoramento de infraestrutura e recursos

Além das métricas de aplicação, a infraestrutura pode revelar problemas sutis pós-deploy:

  • CPU e memória: picos sustentados indicam loops infinitos ou vazamento de memória.
  • I/O de disco: aumento repentino pode indicar logging excessivo ou escrita em arquivos temporários.
  • Banco de dados: lentidão em queries, aumento de conexões ou locks após deploy.
# Alerta de vazamento de memória progressivo
alerta: "vazamento_memoria_pos_deploy"
condição: |
  predict_linear(container_memory_usage_bytes{
    versao="v2.3.1"
  }[30m], 3600) > container_memory_limit_bytes{
    versao="v2.3.1"
  } * 0.9
mensagem: "Vazamento de memória detectado na versão v2.3.1"

5. Estratégias de rollback baseadas em métricas

O monitoramento pós-deploy deve ser capaz de decidir automaticamente pelo rollback. Para isso, defina:

  • SLIs (Service Level Indicators): métricas como disponibilidade, latência p95, taxa de erro.
  • SLOs (Service Level Objectives): metas como "99.9% de disponibilidade nos primeiros 30 minutos".
# Gatilho automático de rollback (pseudo-código)
function verificar_rollback(versao_nova):
    erro_rate = get_metric("error_rate", versao_nova)
    baseline = get_baseline("error_rate", ultimas_24h)

    if erro_rate > baseline * 2 and erro_rate > 0.01:
        executar_rollback(versao_nova, motivo="Taxa de erro 2x acima do baseline")
        notificar_time("rollback automático executado")

Ferramentas de auto-remediation como Rundeck ou scripts integrados ao CI/CD podem executar o rollback e notificar a equipe.

6. Ferramentas e stacks recomendadas

Stack open-source recomendada:

  • Prometheus: coleta de métricas com suporte a rótulos (tags de versão).
  • Grafana: dashboards dinâmicos com variáveis de template.
  • Alertmanager: roteamento de alertas com supressão temporária para deploys.
  • Loki: logs centralizados com consulta via LogQL.

Soluções SaaS:

  • Datadog: APM completo com rastreamento distribuído e dashboards por serviço.
  • New Relic: Change Tracking que correlaciona deploys com métricas.
  • Dynatrace: detecção automática de anomalias pós-deploy.

Integração com CI/CD:

# Notificação de deploy no GitHub Actions
steps:
  - name: Notificar deploy
    run: |
      curl -X POST https://api.datadoghq.com/api/v1/events \
        -H "Content-Type: application/json" \
        -d '{
          "title": "Deploy v2.3.1 iniciado",
          "text": "Monitoramento ativo para nova versão",
          "tags": ["versao:v2.3.1", "ambiente:producao"]
        }'

7. Boas práticas e armadilhas comuns

Armadilhas:

  • Confiar apenas em health checks HTTP: eles testam conectividade, não funcionalidade.
  • Usar métricas agregadas como média — o p95 pode estar péssimo enquanto a média parece normal.
  • Ignorar degradação parcial: uma funcionalidade específica pode quebrar sem afetar o sistema como um todo.

Boas práticas:

  • Monitorar comportamento funcional com testes sintéticos que executam fluxos completos.
  • Criar runbooks específicos para cada tipo de anomalia pós-deploy (ex: "vazamento de memória", "lentidão em consultas", "erro de autenticação").
  • Documentar o procedimento de rollback e garantir que seja executável em menos de 5 minutos.
# Runbook: Degradação de performance pós-deploy
1. Verificar dashboard "Comparação de versões" no Grafana
2. Identificar qual endpoint ou serviço está degradado
3. Coletar spans de trace da nova versão com OpenTelemetry
4. Verificar logs da nova versão no Loki: {versao="v2.3.1"}
5. Se degradação > 30% por mais de 10 minutos: executar rollback
6. Se degradação < 30%: escalar para time de desenvolvimento

Referências