Observabilidade em Java: de "por que caiu?" para "eu sei o que vai acontecer em um minuto"
\n\nImagine: sua aplicação Java está rodando em produção. Tudo perfeito. De repente — bum! — os usuários reclamam que a página demora 10 segundos para carregar. Você acessa o servidor, olha os logs, vê uma tonelada de INFO e nenhum ERROR. O que fazer? Onde olhar?
No monitoramento clássico, você verifica: o servidor está vivo, quanta memória está sendo usada, o processo não caiu. Mas isso é como verificar se a luz do painel está acesa — útil, mas insuficiente. Observabilidade é o próximo nível. É a capacidade de entender o estado interno do sistema através de seus dados externos: logs, métricas e traces.
\n\nNeste artigo, vou mostrar como implementar observabilidade em Java com exemplos reais. Vamos usar OpenTelemetry, Micrometer, Spring Boot Actuator e o clássico SLF4J. Você aprenderá a conectar logs, métricas e traces em uma visão unificada, e não apenas "coletar tudo em um balde".
\n\nO que é Observabilidade e por que não é apenas "coleta de logs"?
\n\nObservabilidade vem da teoria de controle. Um sistema é observável se, a partir de seus dados de saída, é possível reconstruir seu estado interno. No mundo Java, isso significa três pilares:
\n\n- \n
- Logs — registros estruturados de eventos (o que aconteceu?); \n
- Métricas — indicadores numéricos (quanto? quanto tempo?); \n
- Traces — cadeias de chamadas (qual caminho a requisição percorreu?). \n
Sem observabilidade, você está no escuro. Você sabe que a CPU está em 95%, mas não sabe qual endpoint está causando isso. Você vê um erro no log, mas não entende qual usuário o gerou e quais serviços estavam envolvidos. Observabilidade em Java não é sobre "instalar uma biblioteca", mas sobre uma cultura de desenvolvimento.
\n\nOpenTelemetry: a ferramenta universal para observabilidade
\n\nAntes, era um zoológico: Zipkin para tracing, Prometheus para métricas, ELK para logs. Cada um com seu próprio SDK. O OpenTelemetry (OTel) veio para unificar tudo. É um padrão open-source para coleta de telemetria. Ele suporta Java nativamente e se integra facilmente com Spring Boot, Micronaut, Quarkus.
\n\nComo funciona? Você adiciona um agente ou SDK à sua aplicação Java, e o OTel automaticamente intercepta requisições HTTP, chamadas a bancos de dados, filas de mensagens. Você não precisa escrever código para cada ferramenta separadamente.
\n\nExemplo: configurando OpenTelemetry no Spring Boot
\n\nAdicione a dependência no pom.xml:
<dependency>\n <groupId>io.opentelemetry</groupId>\n <artifactId>opentelemetry-api</artifactId>\n <version>1.40.0</version>\n</dependency>\n<dependency>\n <groupId>io.opentelemetry</groupId>\n <artifactId>opentelemetry-sdk</artifactId>\n <version>1.40.0</version>\n</dependency>\n<dependency>\n <groupId>io.opentelemetry.instrumentation</groupId>\n <artifactId>opentelemetry-spring-boot-starter</artifactId>\n <version>2.6.0</version>\n</dependency>\n\nAgora, na configuração (application.yml), defina o exportador, por exemplo, para Jaeger ou coletor OTLP:
otel:\n exporter:\n otlp:\n endpoint: http://localhost:4317\n traces:\n exporter: otlp\n metrics:\n exporter: otlp\n logs:\n exporter: otlp\n\nPronto! Agora, cada requisição HTTP ao seu controller cria automaticamente um trace. Você pode ver quanto tempo cada chamada ao banco de dados, API externa ou simples atraso na thread levou.
\n\nTracing em Java: como encontrar o "gargalo"
\n\nTracing é, sem dúvida, a parte mais poderosa da observabilidade. Quando sua aplicação é composta por dezenas de microsserviços, os traces são a única maneira de entender por que uma requisição leva 2 segundos, mesmo que cada ser