Especialização em Backend com Java & Spring Boot • Spring Boot 3 & Java 21 LTS • Spring Data JPA, Security, Microsserviços e Cloud

🗺️ Mapa Conceitual do Tópico

flowchart TD
    A["Cliente HTTP / Frontend"] --> B["API Gateway / Router"]
    B --> C["Controller / Handler"]
    C --> D["Service Layer (Regras de Negócio)"]
    D --> E["Repository / ORM (Persistência)"]
    E --> F["Banco de Dados / Cache"]

    subgraph ARQ["Arquitetura do Capítulo"]
        G["Conceito: Observabilidade com Spring Boot Actuator, Micrometer e Prometheus"]
        H["Segurança, Validação e Resiliência"]
        I["Alta Performance e Escalabilidade"]
    end

    D --> ARQ

    style A fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px
    style B fill:#fff3e0,stroke:#ff9800,stroke-width:2px
    style C fill:#ede7f6,stroke:#7e57c2,stroke-width:2px
    style D fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
    style E fill:#fce4ec,stroke:#e91e63,stroke-width:2px
    style F fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px

🏛️ 1. Fundamentos Técnicos de Observabilidade com Spring Boot Actuator, Micrometer e Prometheus

Os três pilares de observabilidade: métricas, logs e traces. Em um sistema monolítico, um System.out.println estratégico já revela boa parte do comportamento em execução. Em um sistema distribuído com dezenas de instâncias efêmeras, essa abordagem é inviável — é preciso instrumentação estruturada que responda “o sistema está saudável?” (métricas agregadas), “o que aconteceu neste request específico?” (logs correlacionados) e “por onde essa requisição passou entre serviços?” (tracing distribuído). O Spring Boot Actuator, o Micrometer e o Prometheus cobrem essas três dimensões de forma integrada.

Spring Boot Actuator: endpoints de gestão prontos para uso. Adicionar spring-boot-starter-actuator expõe automaticamente endpoints de gerenciamento sem código adicional: /actuator/health reporta o status agregado da aplicação (UP/DOWN) consolidando verificações de banco, disco e outros recursos registrados; /actuator/metrics lista métricas individuais consultáveis; /actuator/env expõe propriedades de configuração ativas; /actuator/info expõe metadados de build. Por segurança, nem todos os endpoints ficam expostos por padrão — management.endpoints.web.exposure.include=health,info,metrics,prometheus declara explicitamente quais habilitar via HTTP, evitando vazar informação sensível (como /actuator/env, que pode expor segredos) em produção sem controle de acesso adequado.

Micrometer: a fachada de instrumentação, independente do backend de monitoramento. Assim como o SLF4J é uma fachada para diferentes implementações de log, o Micrometer é uma fachada de métricas: o código de aplicação usa uma API única (MeterRegistry, Counter, Timer, Gauge), e a biblioteca traduz para o formato do backend efetivamente plugado — Prometheus, Datadog, CloudWatch — sem alterar uma linha do código de instrumentação ao trocar de ferramenta de monitoramento. Counter.builder("pedidos_criados_total").tag("ambiente", "producao").register(registry) cria uma métrica cumulativa (só aumenta) com tags que permitem segmentar a consulta depois (por ambiente, por região, por tipo).

Health Indicators customizados. O health check embutido cobre infraestrutura genérica (banco, disco), mas regras de negócio específicas — “o gateway de pagamento externo está respondendo?” — exigem verificação própria. Implementar a interface HealthIndicator e sobrescrever health() permite compor um indicador customizado que retorna Health.up() ou Health.down().withDetail(...); o Actuator agrega automaticamente todos os indicadores registrados no status consolidado de /actuator/health — se qualquer um reportar DOWN, o status geral da aplicação também reporta DOWN.

Prometheus: coleta por pull, não por push. Diferente de soluções que exigem que a aplicação envie métricas ativamente, o modelo do Prometheus é o inverso: o servidor Prometheus periodicamente raspa (scrape) o endpoint /actuator/prometheus de cada instância, coletando o estado atual de todas as métricas em formato de texto padronizado (OpenMetrics). Isso simplifica a topologia — a aplicação só precisa expor um endpoint HTTP passivo, sem gerenciar conexão de saída com um coletor externo — e permite que o Prometheus descubra e monitore instâncias dinamicamente via integração com o Service Discovery.

Probes de Kubernetes: liveness vs. readiness. Em ambientes orquestrados, o Kubernetes precisa responder duas perguntas distintas sobre cada Pod: “está travado e precisa ser reiniciado?” (liveness) e “está pronto para receber tráfego agora?” (readiness — por exemplo, ainda inicializando conexões com banco). management.endpoint.health.probes.enabled=true expõe /actuator/health/liveness e /actuator/health/readiness separadamente, permitindo que o Kubernetes reinicie apenas Pods travados (sem afetar Pods que só estão temporariamente indisponíveis para tráfego) e retire da fila de balanceamento Pods ainda não prontos, sem reiniciá-los desnecessariamente.

Tracing distribuído: correlacionar logs através de múltiplos serviços. Quando uma requisição atravessa Gateway → Pedidos → Pagamentos → Estoque, um erro em Estoque só faz sentido investigado junto com o contexto da requisição original. O Micrometer Tracing injeta um traceId (constante em toda a jornada) e um spanId (único por serviço/etapa) propagados automaticamente entre chamadas HTTP/mensageria, e configurados via MDC do SLF4J para aparecer em todo log emitido — permitindo, em uma ferramenta como Zipkin ou Grafana Tempo, reconstruir visualmente o caminho completo de uma requisição e identificar exatamente em qual etapa e serviço o tempo foi gasto ou o erro ocorreu.

💻 2. Código de Demonstração Corporativo

package com.empresa.api.metrics;

import io.micrometer.core.instrument.Counter;
import io.micrometer.core.instrument.MeterRegistry;
import io.micrometer.core.instrument.Timer;
import org.springframework.stereotype.Service;

@Service
public class PedidoMetricsService {

    private final Counter pedidosCriadosCounter;
    private final Timer processamentoPedidoTimer;

    public PedidoMetricsService(MeterRegistry registry) {
        this.pedidosCriadosCounter = Counter.builder("pedidos_criados_total")
            .description("Total de pedidos criados com sucesso")
            .tag("ambiente", "producao")
            .register(registry);

        this.processamentoPedidoTimer = Timer.builder("pedidos_processamento_tempo")
            .description("Tempo de processamento do fluxo de criação de pedido")
            .register(registry);
    }

    public void registrarPedidoCriado() {
        pedidosCriadosCounter.increment();
    }

    public <T> T medirProcessamento(java.util.function.Supplier<T> operacao) {
        // O Timer registra automaticamente contagem, soma e percentis de duração.
        return processamentoPedidoTimer.record(operacao);
    }
}

package com.empresa.api.metrics;

import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;
import org.springframework.web.client.RestClientException;
import org.springframework.web.client.RestTemplate;

@Component
public class GatewayPagamentoHealthIndicator implements HealthIndicator {

    private final RestTemplate restTemplate;

    public GatewayPagamentoHealthIndicator(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    @Override
    public Health health() {
        try {
            restTemplate.getForEntity("https://gateway-pagamento.exemplo.com/ping", String.class);
            return Health.up().withDetail("gateway", "Disponível").build();
        } catch (RestClientException ex) {
            // Um HealthIndicator DOWN derruba o status agregado de /actuator/health.
            return Health.down().withDetail("gateway", "Indisponível").withException(ex).build();
        }
    }
}

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus
  endpoint:
    health:
      show-details: always
      probes:
        enabled: true # habilita /actuator/health/liveness e /readiness
  metrics:
    tags:
      application: pedidos-service