Observabilidad en Java: trazado, métricas, logs para profesionales

Observabilidad en Java: de «¿por qué cayó?» a «sé lo que pasará en un minuto»

Imagina: tu aplicación Java funciona en producción. Todo perfecto. Y luego, ¡pum! — los usuarios se quejan de que la página tarda 10 segundos en cargar. Accedes al servidor, miras los logs, ves un montón de INFO y ni un solo ERROR. ¿Qué hacer? ¿Dónde mirar?

En la monitorización clásica verificas: si el servidor está vivo, cuánta memoria se usa, si el proceso ha caído. Pero esto es como comprobar si la bombilla del tablero está encendida: útil, pero insuficiente. Observabilidad es el siguiente nivel. Es la capacidad de entender el estado interno de un sistema a través de sus datos de salida externos: logs, métricas y trazas.

En este artículo, mostraré cómo implementar la observabilidad en Java con ejemplos reales. Usaremos OpenTelemetry, Micrometer, Spring Boot Actuator y el clásico SLF4J. Aprenderás a vincular logs, métricas y trazas en una imagen unificada, y no solo a «recopilarlo todo en un montón».

¿Qué es la Observabilidad y por qué no es solo «recopilación de logs»?

La observabilidad proviene de la teoría de control. Un sistema es observable si, a partir de sus datos de salida, se puede reconstruir su estado interno. En el mundo Java, esto significa tres pilares:

\n
• Logs — registros estructurados de eventos (¿qué ocurrió?);
\n
• Métricas — indicadores numéricos (¿cuánto? ¿cuánto tiempo?);
\n
• Trazas — cadenas de llamadas (¿qué camino siguió la solicitud?).
\n

Sin observabilidad, estás ciego. Sabes que la CPU está al 95%, pero no sabes qué endpoint específico la está cargando. Ves un error en el log, pero no entiendes qué usuario lo provocó ni qué servicios participaron. La observabilidad en Java no se trata de «instalar una librería», sino de una cultura de desarrollo.

OpenTelemetry: herramienta universal para la observabilidad

Antes había un zoológico: Zipkin para trazado, Prometheus para métricas, ELK para logs. Cada uno con su propio SDK. OpenTelemetry (OTel) llegó para unificarlos. Es un estándar open-source para la recopilación de telemetría. Soporta Java de forma nativa y se integra fácilmente con Spring Boot, Micronaut, Quarkus.

¿Cómo funciona? Añades un agente o SDK a tu aplicación Java, y OTel intercepta automáticamente las solicitudes HTTP, llamadas a bases de datos, colas de mensajes. No necesitas escribir código para cada herramienta por separado.

Ejemplo: configuración de OpenTelemetry en Spring Boot

Añade la dependencia en 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>

Ahora, en la configuración (application.yml), especifica el exportador, por ejemplo, a Jaeger o al colector 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

¡Voilà! Ahora cada solicitud HTTP a tu controlador crea automáticamente una traza. Puedes ver cuánto tiempo tomó cada llamada a la base de datos, API externa o simplemente la latencia en el hilo.

Trazado en Java: cómo encontrar el «cuello de botella»

El trazado es, quizás, la parte más potente de la observabilidad. Cuando tu aplicación consta de decenas de microservicios, las trazas son la única forma de entender por qué una solicitud tarda 2 segundos, aunque cada serv