spring boot opentelemetry

OpenTelemetry de démarrage de printemps

Métrique

Spring Boot Actorator fournit la gestion des dépendances et l'autoconfiguration pour le micromètre, qui offre une façade pratique sur de nombreux systèmes de surveillance différents. L'un d'eux est l'opentélémétrie.

Les développeurs de démarrage de Spring peuvent permettre à leurs applications d'exporter des mesures via le protocole OTLP à un backend OpenTelemétrie en ajoutant un actionneur de démarrage de Spring et la dépendance dédiée à l'OpenTelelemetry du micromètre à leurs projets.

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

L'exportateur fourni par le Registre des micromètres OTLP est un exportateur HTTP et peut être configuré via des propriétés grâce à l'autoconfiguration de l'OpenLelemetry.

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

L'OpenTelemetry prend en charge les paires de clés / valeur supplémentaires (appelées resource attributes ) à inclure dans les données de télémétrie. Spring Boot Actorator fournit une configuration automatique pour ceux-ci et permet d'ajouter de nouveaux attributs de ressources via des propriétés.

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

J'ai fait une application de démonstration pour présenter cette configuration.

Problème: OTLP Metrics Exporter n'est pas configurable via OpenTelemetry

Le module OTLP de registre micrométrique utilise un client HTTP compatible OTLP pour exporter des métriques vers un backend OpenTelemetry. En interne, l' OtlpMeterRegistry utilise un objet HttpSender privé pour configurer le client HTTP. L'avantage de cette approche est que le module est léger et n'a besoin d'aucune dépendance à l'égard du SDK opentélémétrique. Il utilise uniquement la bibliothèque io.opentelemetry.proto qui fournit la configuration de Protobuf pour l'OpenTelemetry.

D'un autre côté, une telle approche signifie que:

• Il n'est pas possible de configurer l'exportateur de métriques via la configuration standard de l'OpenTelemetry;
• Il n'est pas possible de configurer la compression;
• Il n'est pas possible de partager la configuration de l'OpenTelemetry dans le démarrage de printemps entre les métriques et les traces.

La nouvelle OpenTelemetryAutoConfiguration générique AutoConfiguration dans Spring Boot 3.2 AutoConfigures un bean OpenTelemetry et permet de configurer un bean SdkMeterProvider . Et si le micromètre pouvait l'utiliser pour la configuration de l'exportateur de métriques OpenLelemetry?

Solutions possibles:

• Mettez à jour le module OTLP de registre des micromètres existants pour implémenter un MeterRegistry qui accepte un objet OpenTelemetry pour la configuration (similaire à la bibliothèque d'operbemétrie de OpenTelemetryMeterRegistry utilisée par la bibliothèque d'instrumentation Java OpenTelemetry). Si une compatibilité arriérée est nécessaire, la nouvelle implémentation devrait coexister avec celle existante (peut-être qu'un drapeau de fonction pourrait basculer entre les deux?);
• Créez un nouveau module d'OpenTelemetry de registre micrométrique pour implémenter ce qui décrit dans le point précédent, mais sans avoir de problèmes avec une compatibilité arrière.

J'ai soumis un problème au projet micrométrique et partagé ces suggestions. Construire (ou mettre à jour) un tel module permettrait de réutiliser le même OpenTelemetryAutoConfiguration introduit dans Spring Boot 3.2 pour les métriques et les traces (et, à l'avenir, pour les journaux également).

• Un problème existe déjà sur le projet Spring Boot pour automatiquement un haricot SdkMeterProvider et, en général, pour l'utilisation de mesures avec OpenteLelemetry. Mais nous manquons le support micrométrique avant que cela ne soit faisable.
• Il permettrait également de changer l'implémentation du client entre HTTP et GRPC en utilisant l'approche OpenTelemétrie standard (c'est-à-dire en configurant un OtlpHttpMetricExporter ou OtlpGrpcMetricExporter ).
• Enfin, cela faciliterait les développeurs en utilisant le micromètre dans les applications ainsi que l'agent Java OpenLelemetry ou, en général, l'instrumentation Java OpenLelemetry. Ces projets maintiennent actuellement une cale entre le micromètre et l'opentélémétrie. Ce cale ne serait probablement plus nécessaire. Ainsi, un tel changement réduirait également la charge de travail sur le maintien de l'instrumentation Java OpenTelemetry compatible avec le micromètre.

Pour plus de contexte sur les défis actuels, reportez-vous à ce problème sur le projet Spring Boot.

Traces

Le Spring Boot Actorator fournit la gestion des dépendances et l'autoconfiguration pour le traçage des micromètres, qui offre une façade pratique sur quelques backends de traçage distribués différents. L'un d'eux est l'opentélémétrie.

Les développeurs de démarrage de Spring peuvent permettre à leurs applications d'exporter des traces via le protocole OTLP à un backend Opentelémétrie en ajoutant un actionneur de démarrage Spring, un traçage micrométrique et la dépendance dédiée à l'OpenTelelemetry du micromètre à leurs projets.

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

L'exportateur fourni par l'autoconfiguration de l'actionneur de démarrage de Spring est un exportateur HTTP (un bean OtlpHttpSpanExporter ) et peut être configuré via des propriétés grâce à la configuration de traçage dans OtlpAutoConfiguration .

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

L'OpenTelemetry prend en charge les paires de clés / valeur supplémentaires (appelées resource attributes ) à inclure dans les données de télémétrie. Spring Boot Actorator fournit une configuration automatique pour ceux-ci et permet d'ajouter de nouveaux attributs de ressources via des propriétés. L'attribut standard OpenteLelemetry service.name est configuré automatiquement à la valeur de spring.application.name (si défini) ou bien à une valeur application par défaut.

 management :
  opentelemetry :
    resource-attributes :
      cluster : local

J'ai fait une application de démonstration pour présenter cette configuration.

Publier des traces d'exportation via GRPC

Dans ce numéro sur le projet Spring Boot, AutoConfiguration pour un bean OtlpHttpSpanExporter a été ajouté aux traces d'exportation via HTTP.

Une exigence commune consiste à exporter des traces via GRPC (l'approche la plus utilisée dans l'opentélémétrie). Actuellement, les développeurs peuvent configurer en eux-mêmes un OtlpGrpcSpanExporter . Ce serait bien si l'actionneur de démarrage de Spring fournirait une autoconfiguration pour cela, en améliorant l' OtlpAutoConfiguration existante.

Il y a déjà un problème sur le projet Spring Boot pour ajouter une telle autoconfiguration.

Résumé

Dans l'ensemble, ce sont les problèmes et les suggestions que j'ai décrits jusqu'à présent.

Modifications minimales proposées pour consolider le support d'opentélémétrie au printemps pour les métriques et les traces

Micromètre

• Introduisez une implémentation MeterRegistry construite au-dessus de l'OpenTelemetry et configurable via ses approches standard, afin qu'il soit possible de partager la configuration entre les métriques et les traces.

Actionneur de démarrage de printemps

• Introduisez l'autoconfiguration pour les mesures d'opentelémétrie. Les haricots OpenTelemetry et Resource peuvent être réutilisés à partir de la configuration existante de l'OpenTelelemetry. En plus de cela, l'autoconfiguration doit définir les défauts de défaut pour SdkMeterProvider , OtlpHttpMetricExporter et OtlpGrpcMetricExporter .
• Introduisez l'autoconfiguration pour l'exportation des traces d'openLelemetry via GRPC en définissant un haricot OtlpGrpcSpanExporter .
• Consolider les classes d'autoconfiguration de l'OpenTeleMetry à travers les métriques et les traces. L'OpenTelemetryAutoConfiguration existante pourrait être utilisée pour la configuration partagée. En outre, des classes d'autoconfiguration dédiées sont nécessaires pour configurer les exportateurs spécifiques pour chaque type de télémétrie. Les traces ont déjà cela dans l'otlpautoconfiguration.

Printemps initializr

• Après avoir parcouru toutes les modifications précédentes, il devrait devenir simple en ajoutant une option d'OpenTelemétrie au printemps initialiNiSR. L'ajoutant maintenant avec l'état actuel des choses, cela pourrait rendre les choses déroutantes compte tenu des différentes façons de configurer l'OpenTelemret entre les métriques et les traces.

Modifications supplémentaires pour étendre le support opentelémétrie au printemps aux journaux

Actionneur de démarrage de printemps

• Introduisez l'autoconfiguration pour les journaux d'openteLemétrie. Les haricots OpenTelemetry et Resource peuvent être réutilisés à partir de la configuration existante de l'OpenTelelétrie. En plus de cela, l'autoconfiguration doit définir les défauts par défaut pour SdkLoggerProvider , OtlpHttpLogRecordExporter et OtlpGrpcLogRecordExporter .
• Ajoutez la prise en charge de la journalisation (par défaut) et du log4j2. Pour l'inspiration, l'Opentelemetry Java Instrumentation fournit des annexes pour la connexion et le log4j2.
• Problème éventuellement connexe sur le projet Spring Boot.

Améliorations supplémentaires

• Un problème a été ouvert pour étudier comment limiter le nombre de haricots configurables actuellement disponibles dans le traçage OpenTelemetryAutoConfiguration (ce problème pourrait être pris en compte pour l' OpenTelemetryAutoConfiguration globale une fois que le tracé est supprimé).