8 min leitura • Guide 768 of 877
Projetos de Monitoramento e Observabilidade
Bom monitoramento previne problemas e acelera debugging. GitScrum ajuda times a planejar trabalho de observabilidade e rastrear melhorias de monitoramento junto com desenvolvimento de features.
Fundamentos de Observabilidade
Três Pilares
PILARES DE OBSERVABILIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MÉTRICAS: │
│ Medições numéricas ao longo do tempo │
│ • Contagem de requests, latência, taxa de erro │
│ • CPU, memória, uso de disco │
│ • Métricas de negócio (pedidos, cadastros) │
│ │
│ Use para: Dashboards, alertas, tendências │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ LOGS: │
│ Eventos discretos com contexto │
│ • Detalhes de request │
│ • Erros com stack traces │
│ • Eventos de auditoria │
│ │
│ Use para: Debugging, auditoria, investigação │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TRACES: │
│ Fluxo de request através de serviços │
│ • Breakdown de latência end-to-end │
│ • Dependências de serviços │
│ • Identificação de gargalos │
│ │
│ Use para: Debug distribuído, análise de performance │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ JUNTOS: │
│ Alerta dispara (métrica) → Contexto dashboard (métricas) │
│ → Investigar logs → Rastrear request específico │
└─────────────────────────────────────────────────────────────┘
Observabilidade em Features
Monitoramento em Features
OBSERVABILIDADE EM TAREFAS DE FEATURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FEATURE COM OBSERVABILIDADE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PROJ-200: Processamento de Pagamento ││
│ │ ││
│ │ REQUISITOS FUNCIONAIS: ││
│ │ ☐ Processar pagamentos com cartão de crédito ││
│ │ ☐ Lidar com falhas graciosamente ││
│ │ ☐ Enviar email de confirmação ││
│ │ ││
│ │ REQUISITOS DE OBSERVABILIDADE: ││
│ │ ││
│ │ MÉTRICAS: ││
│ │ ☐ payment_attempts_total (counter) ││
│ │ ☐ payment_success_total (counter) ││
│ │ ☐ payment_failure_total (counter, por razão) ││
│ │ ☐ payment_amount_total (counter) ││
│ │ ☐ payment_processing_duration (histogram) ││
│ │ ││
│ │ LOGS: ││
│ │ ☐ Pagamento iniciado (user_id, amount) ││
│ │ ☐ Resultado pagamento (sucesso/falha, razão) ││
│ │ ☐ SEM dados sensíveis (números de cartão) ││
│ │ ││
│ │ ALERTAS: ││
│ │ ☐ Taxa de falha de pagamento > 5% ││
│ │ ☐ Latência de pagamento p99 > 5s ││
│ │ ☐ Erros de gateway de pagamento ││
│ │ ││
│ │ DASHBOARD: ││
│ │ ☐ Painel de visão geral de pagamentos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEFINITION OF DONE INCLUI: │
│ ☐ Métricas expostas │
│ ☐ Logs estruturados com contexto de request │
│ ☐ Alertas configurados │
│ ☐ Dashboard atualizado │
└─────────────────────────────────────────────────────────────┘
Projetos de Monitoramento
Trabalho Dedicado de Observabilidade
EPIC DE MELHORIA DE OBSERVABILIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ OBS-Q1: Melhorias de Observabilidade Q1 │
│ │
│ OBJETIVO: Reduzir MTTR em 50% │
│ │
│ ESTADO ATUAL: │
│ • Tempo médio para detectar: 15 minutos │
│ • Tempo médio para diagnosticar: 45 minutos │
│ • Muitas lacunas no monitoramento │
│ │
│ ESTADO ALVO: │
│ • Tempo para detectar: < 5 minutos │
│ • Tempo para diagnosticar: < 20 minutos │
│ • Cobertura de monitoramento completa │
│ │
│ TAREFAS: │
│ ───────── │
│ │
│ ALERTING: │
│ ☐ Revisar alertas existentes (ruído vs valor) │
│ ☐ Adicionar alertas faltando │
│ ☐ Implementar playbooks de alerta │
│ ☐ Configurar escalation paths │
│ │
│ DASHBOARDS: │
│ ☐ Dashboard de overview do sistema │
│ ☐ Dashboards por serviço │
│ ☐ Dashboard de negócio │
│ ☐ Runbook links em dashboards │
│ │
│ LOGS: │
│ ☐ Padronizar formato de log │
│ ☐ Adicionar request IDs para correlation │
│ ☐ Melhorar log levels │
│ ☐ Configurar log retention │
│ │
│ TRACING: │
│ ☐ Implementar distributed tracing │
│ ☐ Instrumentar serviços críticos │
│ ☐ Integrar com logs │
│ │
└─────────────────────────────────────────────────────────────┘
Alerting
Estratégia de Alertas
ESTRATÉGIA DE ALERTING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NÍVEIS DE ALERTA: │
│ ───────────────── │
│ │
│ CRITICAL (Page): │
│ ├── Serviço completamente down │
│ ├── Dados corrompidos │
│ ├── Impacto severo em usuários │
│ └── Ação imediata necessária │
│ │
│ WARNING (Notificação): │
│ ├── Degradação de performance │
│ ├── Taxa de erro subindo │
│ ├── Recursos ficando escassos │
│ └── Atenção necessária em breve │
│ │
│ INFO (Log): │
│ ├── Eventos normais de interesse │
│ ├── Deployments │
│ ├── Mudanças de configuração │
│ └── Sem ação necessária │
│ │
│ REGRAS DE ALERTA: │
│ ───────────────── │
│ • Alertas acionáveis (o que fazer?) │
│ • Link para runbook │
│ • Contexto suficiente │
│ • Minimizar falsos positivos │
│ • Evitar fadiga de alertas │
│ │
└─────────────────────────────────────────────────────────────┘
Dashboards
Design de Dashboard
DESIGN DE DASHBOARD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ HIERARQUIA DE DASHBOARDS: │
│ ────────────────────────── │
│ │
│ Nível 1: Overview do Sistema │
│ ├── Saúde geral (verde/amarelo/vermelho) │
│ ├── Métricas de negócio chave │
│ ├── Alertas ativos │
│ └── Para: Todo mundo, executivos │
│ │
│ Nível 2: Dashboard por Serviço │
│ ├── Métricas detalhadas do serviço │
│ ├── Latência, throughput, erros │
│ ├── Dependências e saúde │
│ └── Para: Time responsável │
│ │
│ Nível 3: Dashboard de Debug │
│ ├── Métricas granulares │
│ ├── Logs correlacionados │
│ ├── Traces │
│ └── Para: Debugging incidente │
│ │
│ LAYOUT RECOMENDADO: │
│ ─────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SAÚDE GERAL │ ALERTAS ATIVOS ││
│ ├─────────────────┴──────────────────────────────────────┤│
│ │ MÉTRICAS GOLDEN SIGNALS: ││
│ │ Latência | Traffic | Errors | Saturation ││
│ ├───────────────────────────────────────────────────────┤│
│ │ MÉTRICAS DE NEGÓCIO ││
│ ├───────────────────────────────────────────────────────┤│
│ │ SERVIÇOS: saúde de cada serviço ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Rastreamento no GitScrum
Tarefas de Observabilidade
TAREFAS DE OBSERVABILIDADE NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TEMPLATE DE TAREFA DE MONITORAMENTO: │
│ ───────────────────────────────────── │
│ │
│ Título: Adicionar métricas ao Payment Service │
│ │
│ Descrição: │
│ Implementar métricas de observabilidade para │
│ monitorar performance e erros do payment service. │
│ │
│ CHECKLIST: │
│ ☐ payment_requests_total (counter) │
│ ☐ payment_duration_seconds (histogram) │
│ ☐ payment_errors_total (counter by type) │
│ ☐ Expor em /metrics │
│ ☐ Dashboard panel criado │
│ ☐ Alertas configurados │
│ │
│ Labels: monitoring, observability, payment-service │
│ │
│ CRITERIO DE ACEITAÇÃO: │
│ • Métricas disponíveis em Prometheus │
│ • Dashboard mostra métricas │
│ • Alertas disparam corretamente (testados) │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE OBSERVABILIDADE
════════════════════════════
FEATURES:
☐ Observabilidade na Definition of Done
☐ Métricas definidas para cada feature
☐ Logs estruturados implementados
☐ Alertas configurados
INFRAESTRUTURA:
☐ Stack de observabilidade funcionando
☐ Retention policies definidas
☐ Dashboards hierárquicos criados
☐ Runbooks documentados
PROCESSO:
☐ Review de alertas regular
☐ On-call rotation definida
☐ Post-mortems usam dados de observabilidade
☐ Melhoria contínua planejada
CULTURA:
☐ Time entende valor de observabilidade
☐ Observabilidade tratada como feature
☐ Tempo alocado para melhoria
☐ Métricas de negócio incluídas
Boa observabilidade transforma problemas de produção de crises em investigações metódicas.