Capítulo 41 — Observabilidade e Monitoramento
Este capítulo detalha a camada de Observabilidade da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como logs, métricas, traces e eventos são coletados, armazenados, analisados e acionam alertas para man…
41.1 Objetivo do Capítulo
Este capítulo detalha a camada de Observabilidade da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como logs, métricas, traces e eventos são coletados, armazenados, analisados e acionam alertas para manter a plataforma operacional, segura e performática.
Observabilidade não é apenas ferramentas. É a capacidade de o sistema comunicar seu estado interno por sinais — logs estruturados, métricas dimensionais e traces distribuídos — permitindo que operadores e arquitetos entendam o que está acontecendo sem precisar recompilação ou inserção de código.
Este capítulo cobre: princípios de observabilidade, OpenTelemetry, logging, métricas, tracing, alertas, dashboards, SLOs/SLIs, on-call e runbooks.
41.2 Princípios da Observabilidade
- Observabilidade como pré-requisito — toda aplicação emite sinais estruturados desde o design;
- Dados estruturados — logs em JSON com contexto; métricas com labels; traces com bagagem;
- Correlação — correlationId propaga entre serviços permitindo rastrear uma requisição end-to-end;
- Tenant awareness — sinais incluem tenantId para análise segregada;
- Baixo overhead — instrumentação não deve degradar performance;
- Retenção governada — logs e traces retidos conforme criticidade e conformidade;
- Alertas acionáveis — alertas descrevem o problema, não o sintoma; guardrails previnem alert fatigue;
- SLOs explícitos — cada serviço define latência, disponibilidade e taxa de erro aceitáveis;
- On-call rotação — profissionais com contexto disponíveis para escalar problemas;
- Blameless post-mortems — incidentes investigados para aprender, não para culpar.
41.3 Pilares da Observabilidade
41.3.1 Logs
Eventos estruturados que descrevem o que a aplicação fez. Formato: JSON com campos: timestamp UTC, level (DEBUG/INFO/WARN/ERROR), logger, message, contexto (tenantId, userId, correlationId, spanId), stack trace quando erro.
{
"timestamp": "2026-07-16T10:30:45.123Z",
"level": "ERROR",
"logger": "com.platform.request.service.SubmitRequestUseCase",
"message": "Falha ao validar documento exigido",
"correlationId": "corr-a7f2-4b81-9c3d",
"tenantId": "tenant-org-a",
"userId": "user-uuid-123",
"serviceId": "svc-habilitacao",
"documentType": "RG",
"error": "DOCUMENT_EXPIRED",
"stackTrace": "..."
}
41.3.2 Métricas
Números que descrevem o estado ou comportamento do sistema. Dimensionais com labels.
http_requests_total{method="POST", status="201", endpoint="/requests", tenant="org-a"} 1234
http_request_duration_seconds{method="GET", endpoint="/requests", tenant="org-a", quantile="0.95"} 0.150
database_connection_pool_active{service="request-service", pool="primary"} 42
cache_hit_rate{cache="catalog", tenant="org-a"} 0.87
41.3.3 Traces
Jornada de uma requisição através de múltiplos serviços. Contexto propaga via correlationId e trace context.
Request entrada → API Gateway (span-1)
└─ autenticação (span-2, 10ms)
└─ Request Service (span-3, 150ms)
└─ Document Service (span-4, 80ms)
└─ RabbitMQ publish (span-5, 5ms)
└─ Response (total 155ms)
41.4 OpenTelemetry
41.4.1 Architetura
OpenTelemetry é o padrão neutro de instrumentação. Código emite sinais; SDK OpenTelemetry coleta; exportador envia para backend.
Aplicação (instrumentation)
│
SDK OpenTelemetry
├─ LogRecordProcessor
├─ MetricReader
└─ SpanProcessor
│
Exportador (OTLP/gRPC ou HTTP)
│
Backend observabilidade (Grafana Loki, Prometheus, Jaeger)
41.4.2 Instrumentação Automática
Spring Boot com OpenTelemetry auto-instrumenta: HTTP requests, database queries, cache, RabbitMQ.
<!-- pom.xml -->
<dependency>
<groupId>io.opentelemetry.instrumentation</groupId>
<artifactId>opentelemetry-instrumentation-bom</artifactId>
<version>1.32.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>io.opentelemetry.instrumentation</groupId>
<artifactId>opentelemetry-spring-boot-starter</artifactId>
</dependency>
41.4.3 Exportador OTLP
# application-prod.yml
otel:
exporter:
otlp:
endpoint: http://otel-collector:4317
metrics:
export:
interval: 60000
traces:
sample_rate: 0.1
41.5 Logging Estruturado
41.5.1 MDC (Mapped Diagnostic Context)
Contexto propagado via ThreadLocal:
MDC.put("tenantId", tenantId);
MDC.put("userId", userId);
MDC.put("correlationId", correlationId);
MDC.put("spanId", spanId);
logger.info("Request iniciada");
// Log incluirá automaticamente tenantId, userId, etc.
MDC.clear(); // No final da requisição
41.5.2 Log Levels por Tipo
| Level | Uso |
|---|---|
| DEBUG | Detalhes internos (loop iterations, decisões) — desabilitado em produção por padrão |
| INFO | Eventos significativos (request iniciada, documento recebido) |
| WARN | Algo inesperado mas recuperável (retry, timeout, fallback) |
| ERROR | Algo quebrou (falha em validação, exceção não tratada) |
41.5.3 Retenção de Logs
| Tipo | Retenção | Rationale |
|---|---|---|
| DEBUG | 3 dias | Baixo valor operacional |
| INFO | 14 dias | Rastreamento de comportamento normal |
| WARN | 30 dias | Investigação de anomalias |
| ERROR | 90 dias | Forensics de incidentes, conformidade |
| AUDIT | 2 anos | LGPD, conformidade regulatória |
41.6 Métricas
41.6.1 Instrumentação
@Service
public class SubmitRequestService {
private final MeterRegistry meterRegistry;
private final Counter requestsSubmitted;
private final Timer requestLatency;
public SubmitRequestService(MeterRegistry meterRegistry) {
this.meterRegistry = meterRegistry;
this.requestsSubmitted = Counter.builder("requests.submitted")
.tag("service", "request-service")
.description("Total de solicitações submetidas")
.register(meterRegistry);
this.requestLatency = Timer.builder("request.latency.ms")
.publishPercentiles(0.5, 0.95, 0.99)
.register(meterRegistry);
}
public RequestResponse submitRequest(SubmitRequestCommand cmd) {
return requestLatency.record(() -> {
RequestResponse response = doSubmit(cmd);
requestsSubmitted.increment(1, Tags.of("status", "success"));
return response;
});
}
}
41.6.2 Métricas de RED
Rate (Taxa de requisições)
http_requests_total{endpoint="/requests", method="POST", tenant="org-a"}
Errors (Taxa de erro)
http_requests_total{endpoint="/requests", status="500"} / http_requests_total{endpoint="/requests"}
Duration (Latência)
http_request_duration_seconds{endpoint="/requests", quantile="0.95"}
41.6.3 Métricas de Negócio
Solicitações por serviço
requests_submitted_total{service_type="habilitacao", tenant="org-a"}
Taxa de complementação
requests_complement_asked_total / requests_submitted_total
Tempo médio de atendimento
request_resolution_time_seconds{service_type="habilitacao"}
41.7 Tracing Distribuído
41.7.1 Propagação de Contexto
@RestController
@RequestMapping("/requests")
public class RequestController {
@PostMapping
public ResponseEntity<RequestResponse> submitRequest(
@RequestBody SubmitRequestRequest request,
HttpServletRequest httpRequest) {
// Extrair trace context de headers (W3C Trace Context)
String traceId = httpRequest.getHeader("traceparent");
String correlationId = httpRequest.getHeader("x-correlation-id");
MDC.put("traceId", traceId);
MDC.put("correlationId", correlationId);
// Serviço consome correlationId
RequestResponse response = submitRequestService.submit(request, correlationId);
// Propagado em chamadas downstream
// Exemplo: requisição ao Document Service inclui headers
return ResponseEntity.status(HttpStatus.CREATED).body(response);
}
}
41.7.2 Jaeger para Visualização
Jaeger coleta spans e exibe traces visuais:
POST /requests (200ms total)
├─ Authentication (10ms) — IAM Service
├─ Submit Request (150ms) — Request Service
│ ├─ Validate (30ms) — validation logic
│ ├─ Document Service call (50ms) — network
│ └─ RabbitMQ publish (20ms)
└─ Response serialization (5ms)
41.8 Alertas e Observabilidade Proativa
41.8.1 SLO/SLI/SLAs
| Termo | Definição | Exemplo |
|---|---|---|
| SLI | Service Level Indicator — métrica observável | 99% de requests < 200ms |
| SLO | Service Level Objective — meta aceita | 99% de uptime |
| SLA | Service Level Agreement — contrato com cliente | Se < 99%, compensação |
41.8.2 Error Budget
Se SLO é 99.9% uptime, o erro budget é 0.1%:
Mês com 30 dias = 43.200 segundos
Error budget (0.1%) = 43,2 segundos downtime permitido
Se já usou 40s em failover, só restam 3,2s para o mês
41.8.3 Alert Policies
# Prometheus AlertManager
groups:
- name: platform
rules:
# Alert: Taxa de erro alta
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
for: 5m
annotations:
summary: "Taxa de erro > 5% no {{ $labels.service }}"
description: "{{ $value }} errors/sec"
labels:
severity: critical
team: platform
# Alert: Latência degradada
- alert: HighLatency
expr: histogram_quantile(0.95, http_request_duration_seconds) > 1
for: 10m
annotations:
summary: "P95 latência > 1s"
labels:
severity: warning
# Alert: Cache miss rate
- alert: CacheMissRateHigh
expr: rate(cache_miss_total[5m]) / rate(cache_access_total[5m]) > 0.3
annotations:
summary: "Cache miss rate > 30%"
labels:
severity: warning
41.9 Dashboards
41.9.1 Grafana
Dashboards por audiência:
Dashboard Operacional (SRE/Ops):
- Taxa de requisições, erros, latência
- Pod restarts, CPU, memória
- Replicação de banco, lag
- Alertas ativos
Dashboard de Negócio (Product/PO):
- Solicitações submetidas por tipo
- Taxa de conclusão
- Tempo médio de atendimento
- Satisfação do cidadão
Dashboard de Segurança (Security):
- Falhas de login
- Acesso a dados sensíveis
- Anomalias detectadas
- Tentativas de ataque
41.10 On-Call e Runbooks
41.10.1 Rotação On-Call
PagerDuty integrado com AlertManager:
AlertManager dispara alerta crítico
│
PagerDuty: notifica engineer on-call (SMS + app)
│
Engineer acessa runbook
│
Executa passos (kubectl, curl, rollback)
│
Escalação automática se não responder em 5m
41.10.2 Exemplo de Runbook
Runbook: Taxa de erro elevada no Request Service
# Causa Provável
1. Falha em serviço downstream (Document Service)
2. Indisponibilidade de banco de dados
3. Fuga de memória causando OOM
# Diagnóstico
## Passo 1: Verificar pods
kubectl get pods -l app=api-solicitacoes -n production
# Se algum pod em CrashLoopBackOff: verificar logs
## Passo 2: Verificar logs
kubectl logs -l app=api-solicitacoes -n production --tail=100 | grep ERROR
## Passo 3: Verificar dependências
- Document Service: curl http://document-service/health
- PostgreSQL: pg_isready -h postgres.default.svc
# Remediação
## Se Document Service indisponível
kubectl rollout status deployment/document-service -n production
# Se deployment é novo, fazer rollback
kubectl rollout undo deployment/document-service -n production
## Se banco offline
# Verificar replicação: SELECT * FROM pg_stat_replication;
# Reiniciar: kubectl rollout restart statefulset/postgres-primary
## Se OOM
# Aumentar memory limit
kubectl set resources deployment/api-solicitacoes \
--limits=memory=4Gi --requests=memory=2Gi
41.11 Rastreabilidade com o Anexo III
| Item ANX-III | Atendimento |
|---|---|
| 6.3 | Auditoria de todas as ações com rastreabilidade completa |
| 1.1 | Observabilidade end-to-end de integração entre módulos |
41.12 Benefícios
- visibilidade completa do comportamento da plataforma em produção;
- detecção rápida de anomalias antes de impacto ao cidadão;
- investigação eficiente de incidentes com traces end-to-end;
- métricas de negócio rastreadas junto a técnicas;
- on-call informado por contexto estruturado;
- decisões de capacity planning baseadas em dados;
- SLOs explícitos garantem qualidade esperada.
41.13 Riscos e Mitigações
| Risco | Consequência | Mitigação |
|---|---|---|
| Dados pessoais em logs | Exposição de PII | Redaction de campo antes de log; revisar logging policy |
| Alert fatigue | Alertas ignorados | Tuning de thresholds; guardrails de duração mínima |
| Retenção excessiva | Custo alto de storage | Retenção governada por nível; arquivamento após período |
| Spans não correlacionados | Impossível rastrear requisição | Correlationid obrigatório; propagação em todas as chamadas |
41.14 Decisões Arquiteturais
| ADR | Tema |
|---|---|
| ADR-801 | OpenTelemetry como padrão de instrumentação |
| ADR-802 | Backend de observabilidade (Prometheus + Loki + Jaeger) |
| ADR-803 | Retenção de logs por nível e conformidade |
| ADR-804 | SLOs e alertas como código |
| ADR-805 | On-call rotation e escalonamento de alertas |
41.15 Considerações Finais
Observabilidade é o superpoder do operador moderno. Quando tudo está instrumentado e conectado, o problema que levaria horas para diagnosticar em sistemas legados pode ser resolvido em minutos. A chave está em perceber que observabilidade não é um ajuste final — é parte da arquitetura desde o começo.
O Capítulo 42 detalha a Arquitetura de Segurança da plataforma.
41.16 Controle de Versão
| Campo | Valor |
|---|---|
| Documento | Documento Mestre — Plataforma de Relacionamento Digital com o Cidadão |
| Capítulo | 41 — Observabilidade e Monitoramento |
| Versão | 1.0 |
| Situação | Concluído |
| Última atualização | 16/07/2026 |
41.17 Rastreabilidade PRODEMGE
- [ANX-III] Bloco 6 — itens 6.3 (auditoria) cobertos conforme seção 41.11.
- [ANX-IV] — Capacidades técnicas de observabilidade, métricas, alertas e on-call.
- [ANX-V] — Conformidade com LGPD via redaction em logs; rastreabilidade de ações.
- [PNR] — Observabilidade como pilha técnica completa: logs estruturados, métricas dimensionais, traces distribuídos.
- [EDITAL] — Edital CP001/2026: plataforma observável com alertas proativos e operação SRE.
Capítulo 40 — DevSecOps e Entrega Contínua
Este capítulo detalha a estratégia de DevSecOps e Entrega Contínua (CI/CD) da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como código, infraestrutura e testes fluem de forma automatizada, segura e con…
Capítulo 42 — Arquitetura de Segurança
Este capítulo estabelece os princípios, padrões e controles de segurança da Plataforma de Relacionamento Digital com o Cidadão. A segurança não é um componente adicionado ao final — é um requisito transversal que permeia…