Relacionamento Digitalcom o Cidadão
Parte V — Tecnologia
Parte V — TecnologiaCapítulo 41

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

  1. Observabilidade como pré-requisito — toda aplicação emite sinais estruturados desde o design;
  2. Dados estruturados — logs em JSON com contexto; métricas com labels; traces com bagagem;
  3. Correlação — correlationId propaga entre serviços permitindo rastrear uma requisição end-to-end;
  4. Tenant awareness — sinais incluem tenantId para análise segregada;
  5. Baixo overhead — instrumentação não deve degradar performance;
  6. Retenção governada — logs e traces retidos conforme criticidade e conformidade;
  7. Alertas acionáveis — alertas descrevem o problema, não o sintoma; guardrails previnem alert fatigue;
  8. SLOs explícitos — cada serviço define latência, disponibilidade e taxa de erro aceitáveis;
  9. On-call rotação — profissionais com contexto disponíveis para escalar problemas;
  10. 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

LevelUso
DEBUGDetalhes internos (loop iterations, decisões) — desabilitado em produção por padrão
INFOEventos significativos (request iniciada, documento recebido)
WARNAlgo inesperado mas recuperável (retry, timeout, fallback)
ERRORAlgo quebrou (falha em validação, exceção não tratada)

41.5.3 Retenção de Logs

TipoRetençãoRationale
DEBUG3 diasBaixo valor operacional
INFO14 diasRastreamento de comportamento normal
WARN30 diasInvestigação de anomalias
ERROR90 diasForensics de incidentes, conformidade
AUDIT2 anosLGPD, 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

TermoDefiniçãoExemplo
SLIService Level Indicator — métrica observável99% de requests < 200ms
SLOService Level Objective — meta aceita99% de uptime
SLAService Level Agreement — contrato com clienteSe < 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-IIIAtendimento
6.3Auditoria de todas as ações com rastreabilidade completa
1.1Observabilidade 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

RiscoConsequênciaMitigação
Dados pessoais em logsExposição de PIIRedaction de campo antes de log; revisar logging policy
Alert fatigueAlertas ignoradosTuning de thresholds; guardrails de duração mínima
Retenção excessivaCusto alto de storageRetenção governada por nível; arquivamento após período
Spans não correlacionadosImpossível rastrear requisiçãoCorrelationid obrigatório; propagação em todas as chamadas

41.14 Decisões Arquiteturais

ADRTema
ADR-801OpenTelemetry como padrão de instrumentação
ADR-802Backend de observabilidade (Prometheus + Loki + Jaeger)
ADR-803Retenção de logs por nível e conformidade
ADR-804SLOs e alertas como código
ADR-805On-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

CampoValor
DocumentoDocumento Mestre — Plataforma de Relacionamento Digital com o Cidadão
Capítulo41 — Observabilidade e Monitoramento
Versão1.0
SituaçãoConcluído
Última atualização16/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.

Nesta página