spring boot opentelemetry

Spring Boot Opentelemetry

Métrica

Spring Boot Actuator proporciona gestión de dependencia y autoconfiguración para micrómetro, que ofrece una fachada conveniente sobre muchos sistemas de monitoreo diferentes. Uno de ellos es Opentelemety.

Los desarrolladores de arranque de primavera pueden permitir que sus aplicaciones exporten métricas a través del protocolo OTLP a un backend de Opentelemety agregando un actuador de arranque de primavera y la dependencia de OperElemety dedicada de micrómetro a sus proyectos.

dependencies {
    implementation ' org.springframework.boot:spring-boot-starter-actuator '
    runtimeOnly ' io.micrometer:micrometer-registry-otlp '
    .. .
}

El exportador proporcionado por el Registro de Micrómetro OTLP es un exportador HTTP y se puede configurar a través de propiedades gracias a la Autoconfiguración para Opentelemetry.

 management :
  otlp :
    metrics :
      export :
        url : http://localhost:4318/v1/metrics
        step : 5s

OPENTELEMETRY admite pares de clave/valor adicionales (llamados resource attributes ) que se incluirán en los datos de telemetría. Spring Boot Actuator proporciona autoconfiguración para aquellos y permite agregar nuevos atributos de recursos a través de propiedades.

 management :
  opentelemetry :
    resource-attributes :
      cluster : local
      " service.name " : ${spring.application.name}

Hice una aplicación de demostración para mostrar esta configuración.

Problema: OTLP Metrics Exporter no es configurable a través de OPENTELEMETRY

El módulo OTLP Registry Micrometry utiliza un cliente HTTP compatible con OTLP para exportar métricas a un back-end de OperElemetry. Internamente, el OtlpMeterRegistry utiliza un objeto HttpSender privado para configurar el cliente HTTP. El beneficio de este enfoque es que el módulo es liviano y no necesita dependencia del SDK OPENTELEMETRY. Solo usa la biblioteca io.opentelemetry.proto que proporciona la configuración de ProtoBuf para opentelemetría.

Por otro lado, tal enfoque significa que:

• No es posible configurar el exportador de métricas a través de la configuración estándar de OpenTelemetry;
• No es posible configurar la compresión;
• No es posible compartir la configuración de OperElemetry en el arranque de primavera entre métricas y trazas.

El nuevo genérico OpenTelemetryAutoConfiguration en Spring Boot 3.2 Autoconfiguración de un frijol OpenTelemetry y hace posible configurar un frijol SdkMeterProvider . ¿Qué pasaría si Micrometry pudiera usar eso para configurar el exportador de métricas Operentelemetry?

Posibles soluciones:

• Actualice el módulo OTLP Registry Micromsey existente para implementar un MeterRegistry que acepte un objeto OpenTelemetry para la configuración (similar al OpenTelemetryMeterRegistry utilizado por la biblioteca OpenTelemetry Java Instrumentation). Si es necesaria la compatibilidad hacia atrás, la nueva implementación necesitaría coexistir con la existente (¿tal vez un indicador de características podría cambiar entre los dos?);
• Cree un nuevo módulo de OpenTelemetry Registry de Micromsey para implementar lo que se describe en el punto anterior, pero sin tener problemas con la compatibilidad hacia atrás.

He enviado un problema al proyecto de micrómetro y compartí estas sugerencias. Construir (o actualizar) dicho módulo permitiría reutilizar la misma OpenTelemetryAutoConfiguration introducida en Spring Boot 3.2 tanto para métricas como para trazas (y, en el futuro, también para registros).

• Ya existe un problema en el proyecto Spring Boot para autoconfigurar un SdkMeterProvider Bean y, en general, para usar métricas con opentelemetría. Pero nos faltan soporte de micrómetro antes de que eso sea factible.
• También permitiría cambiar la implementación del cliente entre HTTP y GRPC utilizando el enfoque estándar de OpenTelemetry (es decir, configurar un OtlpHttpMetricExporter o OtlpGrpcMetricExporter ).
• Finalmente, facilitaría que los desarrolladores usen micrómetros en aplicaciones junto con el agente Java Operentelemetry o, en general, la instrumentación Java OperElemetry. Esos proyectos actualmente mantienen una cuña entre micrómetro y operentelemetría. Esa cuña probablemente ya no se necesitaría. Por lo tanto, tal cambio también reduciría la carga de trabajo para mantener la instrumentación Java Operentelemetry compatible con el micrómetro.

Para obtener más contexto sobre los desafíos actuales, consulte este problema en el proyecto Spring Boot.

Rastros

Spring Boot Actuator proporciona gestión de dependencia y autoconfiguración para el rastreo de micrómetro, que ofrece una fachada conveniente sobre algunos backends de rastreo distribuidos diferentes. Uno de ellos es Opentelemety.

Los desarrolladores de arranque de primavera pueden permitir que sus aplicaciones exporten trazas a través del protocolo OTLP a un backend de Operentelemetry agregando un actuador de arranque de resorte, el rastreo de micrómetro y la dependencia dedicada de Opentelemetry de micrómetro a sus proyectos.

dependencies {
    implementation ' org.springframework.boot:spring-boot-starter-actuator '
    implementation ' io.micrometer:micrometer-tracing-bridge-otel '
    implementation ' io.opentelemetry:opentelemetry-exporter-otlp '
    .. .
}

El exportador proporcionado por la autoconfiguración del actuador de arranque de Spring es un exportador HTTP (un bean OtlpHttpSpanExporter ) y se puede configurar mediante propiedades gracias a la configuración de rastreo en OtlpAutoConfiguration .

 management :
  otlp :
    tracing :
      endpoint : http://localhost:4318/v1/traces

OPENTELEMETRY admite pares de clave/valor adicionales (llamados resource attributes ) que se incluirán en los datos de telemetría. Spring Boot Actuator proporciona autoconfiguración para aquellos y permite agregar nuevos atributos de recursos a través de propiedades. El atributo estándar service.name Resource del servicio se configura automáticamente al valor de spring.application.name (si se define) o de lo contrario a un valor application predeterminado.

 management :
  opentelemetry :
    resource-attributes :
      cluster : local

Hice una aplicación de demostración para mostrar esta configuración.

Problema de exportación de trazas a través de GRPC

En este problema en el proyecto Spring Boot, se ha agregado autoconfiguración para un bean OtlpHttpSpanExporter a las trazas de exportación a través de HTTP.

Un requisito común es exportar trazas a través de GRPC (el enfoque más utilizado en OperElemety). Actualmente, los desarrolladores pueden configurar un bean OtlpGrpcSpanExporter por sí mismos. Sería bueno si el actuador de arranque de primavera proporcionaría autoconfiguración para eso, mejorando la OtlpAutoConfiguration .

Ya hay un problema en el proyecto Spring Boot para agregar dicha autoconfiguración.

Resumen

En general, estos son los problemas y sugerencias que he estado describiendo hasta ahora.

Cambios propuestos mínimos para consolidar el soporte de Operentelemetría en primavera para métricas y trazas

Micrómetro

• Introducir una implementación MeterRegistry creada sobre OpenTelemetry y configurable a través de sus enfoques estándar, de modo que sea posible compartir la configuración entre métricas y trazas.

Actuador de arranque de primavera

• Introducir la autoconfiguración para las métricas de operelemetría. La OpenTelemetry y los frijoles Resource se pueden reutilizar de la configuración existente de Operentelemetry. Además de eso, la autoconfiguración debería definir los valores predeterminados para SdkMeterProvider , OtlpHttpMetricExporter y OtlpGrpcMetricExporter .
• Introduzca la autoconfiguración para exportar trazas de Operentelemetry a través de GRPC definiendo un bean OtlpGrpcSpanExporter .
• Consolidar las clases de autoconfiguración de OperElemetry a través de métricas y trazas. La opentelemetryautoconfiguration podría usarse para la configuración compartida. Además de eso, se necesitan clases de autoconfiguración dedicadas para configurar los exportadores específicos para cada tipo de telemetría. Las trazas ya tienen eso en la Otlpautoconfiguration.

Primavera inicializr

• Después de pasar por todos los cambios anteriores, debe volverse directo agregar una opción de Operentelemetría al primavera inicializr. Agregarlo ahora con el estado actual de las cosas, podría hacer que las cosas sean confusas teniendo en cuenta las diferentes formas de configurar Operelemtry entre métricas y trazas.

Cambios adicionales para extender el soporte de Operentelemetry en la primavera a los registros

Actuador de arranque de primavera

• Introduzca la autoconfiguración para los registros de operelemetría. La OpenTelemetry y los frijoles Resource se pueden reutilizar de la configuración existente de Operentelemetry. Además de eso, la autoconfiguración debe definir los valores predeterminados para SdkLoggerProvider , OtlpHttpLogRecordExporter y OtlpGrpcLogRecordExporter .
• Agregue soporte para logback (predeterminado) y log4j2. Para inspiración, la instrumentación Java Operentelemetry proporciona apéndices para logback y log4j2.
• Posiblemente un problema relacionado en el proyecto Spring Boot.

Mejoras adicionales

• Se ha abierto un problema para investigar cómo limitar el número de frijoles configurables actualmente disponibles en el rastreo OpenTelemetryAutoConfiguration (este problema podría considerarse para la OpenTelemetryAutoConfiguration global una vez que el rastreo específico se elimina).