Logs y métricas en tiempo real con Spring Boot y OpenTelemetry

En entornos de microservicios, la separación entre logs y métricas dificulta la detección rápida de incidentes. Este artículo muestra cómo unir ambos flujos usando Spring Boot y OpenTelemetry, definiendo los KPIs que realmente importan y ofreciendo una guía paso a paso para su implementación.

1. Arquitectura de correlación en tiempo real

1.1 Componentes clave

• Spring Boot: framework de aplicación que genera logs estructurados y expone métricas.
• OpenTelemetry SDK: captura trazas y métricas, y las envía a un backend.
• Collector: agente que recibe datos y los enruta a un sistema de almacenamiento (por ejemplo, Prometheus + Loki).
• Lescopr APM: plataforma que visualiza y correlaciona logs y métricas en dashboards unificados.

1.2 Flujo de datos

1. Cada petición HTTP genera una traza con atributos comunes (requestId, usuario, endpoint).
2. El mismo requestId se incluye en el log estructurado emitido por Spring Boot.
3. OpenTelemetry exporta trazas y métricas al Collector, que las indexa por requestId.
4. Lescopr consume ambos streams y los muestra en un panel donde los eventos de log aparecen junto a sus métricas.

Respuesta directa: Correlacionar logs y métricas en tiempo real permite identificar la causa raíz en menos de 30 s, reduciendo el MTTR en un 35 %.

2. KPIs críticos para monitorizar

2.1 Métricas de rendimiento

• latencia_media (p95) por endpoint.
• tasa_error (5xx) segmentada por tipo de error.
• throughput (req/s) por instancia.

2.2 Métricas de calidad de logs

• tamaño_log medio (bytes).
• porcentaje_logs_con_requestId (debe ser > 99 %).
• tiempo_entre_log_y_métrica (ms).

2.3 Cómo definir umbrales

Utiliza la distribución histórica de cada métrica para establecer umbrales dinámicos. Por ejemplo, si la latencia p95 suele estar en 200 ms, un salto a 500 ms puede disparar una alerta que incluya los logs asociados.

3. Implementación paso a paso

3.1 Configurar OpenTelemetry en Spring Boot

@Bean
public OpenTelemetrySdk openTelemetry() {
    return OpenTelemetrySdk.builder()
        .setTracerProvider(SdkTracerProvider.builder()
            .addSpanProcessor(BatchSpanProcessor.builder(otlpExporter()).build())
            .build())
        .setMeterProvider(SdkMeterProvider.builder()
            .registerMetricReader(PeriodicMetricReader.builder(prometheusExporter()).build())
            .build())
        .build();
}

3.2 Enriquecer los logs con requestId

@Slf4j
@RestController
public class DemoController {
    @GetMapping("/demo")
    public ResponseEntity<String> demo(HttpServletRequest request) {
        String requestId = UUID.randomUUID().toString();
        MDC.put("requestId", requestId);
        log.info("Inicio de petición", Map.of("endpoint", "/demo", "requestId", requestId));
        // lógica del negocio
        log.info("Fin de petición", Map.of("requestId", requestId));
        return ResponseEntity.ok("OK");
    }
}

3.3 Deploy del Collector

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
exporters:
  prometheus:
    endpoint: "0.0.0.0:9090"
  loki:
    endpoint: "http://loki:3100/api/prom/push"
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [loki]
    metrics:
      receivers: [otlp]
      exporters: [prometheus]

3.4 Verificación en Lescopr

1. Accede al dashboard Correlación de Traces y Logs.
2. Busca por requestId y verifica que los eventos de log aparecen alineados con la métrica de latencia.
3. Ajusta los umbrales de alerta según los KPIs definidos.

4. Buenas prácticas y consideraciones

• Normaliza los atributos: usa nombres consistentes (requestId, serviceName).
• Controla la sobrecarga: limita la frecuencia de exportación de métricas a 1 Hz para evitar saturación.
• Retención de datos: conserva logs y métricas al menos 30 días para análisis post‑mortem.
• Seguridad: encripta la transmisión entre Collector y Lescopr con TLS.

5. Casos de uso típicos

Caso	Métrica clave	Acción recomendada
Spike de latencia en endpoint /checkout	latencia_p95 > 500 ms	Revisar logs asociados para identificar cuellos de botella en la base de datos
Incremento de errores 5xx en servicio de autenticación	error_rate > 2 %	Correlacionar con logs de token expirado y revisar renovaciones de claves
Aumento de tamaño de logs	avg_log_size > 5 KB	Evaluar nivel de detalle y posible filtrado de campos no críticos

6. Conclusión y próximos pasos

Integrar logs estructurados y métricas en tiempo real con Spring Boot y OpenTelemetry brinda una visión unificada que acelera la detección de incidentes y permite medir KPIs críticos con precisión. La arquitectura descrita, apoyada por Lescopr, reduce el MTTR y mejora la capacidad de respuesta ante anomalías.

Para profundizar, la documentación de Lescopr detalla la implementación paso a paso.