Injection d'auto-instrumentation

L’opérateur OpenTelemetry prend en charge l’injection et la configuration d’auto-instrumentation pour les services .NET, Java, Node.js, Python et Go.

Installation

Tout d’abord, installez l’opérateur OpenTelemetry dans votre cluster.

Vous pouvez le faire avec une des versions de l’opérateur, le chart Helm de l’opérateur, ou avec Operator Hub.

Dans la plupart des cas, vous devrez installer cert-manager. Si vous utilisez le chart Helm, il y a une option pour générer un certificat auto-signé à la place.

Si vous souhaitez utiliser l’auto-instrumentation Go, vous devez expressément activer la fonctionnalité. Voir Contrôle des capacités d’instrumentation pour plus de détails.

Créer un collecteur OpenTelemetry (Optionnel)

Il est recommandé d’envoyer la télémétrie des conteneurs vers un collecteur OpenTelemetry au lieu de l’envoyer directement vers un backend. Le collecteur aide à simplifier la gestion des secrets, découple les problèmes d’export de données (tels que la nécessité de réessayer l’envoi de données) de vos applications, et vous permet d’ajouter des données supplémentaires à votre télémétrie, par exemple avec le composant k8sattributesprocessor. Si vous choisissez de ne pas utiliser de collecteur, vous pouvez passer à la section suivante.

L’opérateur fournit une définition de ressource personnalisée (CRD) pour le collecteur OpenTelemetry qui est utilisée pour créer une instance du collecteur que l’opérateur gère. L’exemple suivant déploie le collecteur en tant que déploiement (par défaut), mais il y a d’autres modes de déploiement qui peuvent être utilisés.

Lorsque vous utilisez le mode Deployment, l’opérateur créera également un service qui peut être utilisé pour interagir avec le collecteur. Le nom du service est le nom de la ressource OpenTelemetryCollector préfixé par -collector. Pour notre exemple, ce sera demo-collector.

kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1beta1 kind: OpenTelemetryCollector metadata:  name: demo spec:  config:  receivers:  otlp:  protocols:  grpc:  endpoint: 0.0.0.0:4317  http:  endpoint: 0.0.0.0:4318  processors:  memory_limiter:  check_interval: 1s  limit_percentage: 75  spike_limit_percentage: 15  batch:  send_batch_size: 10000  timeout: 10s  exporters:  debug:  verbosity: basic   service:  pipelines:  traces:  receivers: [otlp]  processors: [memory_limiter, batch]  exporters: [debug]  metrics:  receivers: [otlp]  processors: [memory_limiter, batch]  exporters: [debug]  logs:  receivers: [otlp]  processors: [memory_limiter, batch]  exporters: [debug] EOF 

La commande ci-dessus entraîne le déploiement du collecteur que vous pouvez utiliser comme point de terminaison pour l’auto-instrumentation dans vos pods.

Configurer l’auto-instrumentation automatique

Pour pouvoir gérer l’auto-instrumentation, l’opérateur doit être configuré pour savoir quels pods instrumenter et quelle auto-instrumentation utiliser pour ces pods. Cela se fait via la CRD Instrumentation.

Créer correctement la ressource Instrumentation est primordial pour que l’auto-instrumentation fonctionne. S’assurer que tous les points de terminaison et les variables d’environnement sont corrects est requis pour que l’auto-instrumentation fonctionne correctement.

.NET

La commande suivante créera une ressource Instrumentation de base qui est configurée spécifiquement pour instrumenter les services .NET.

kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata:  name: demo-instrumentation spec:  exporter:  endpoint: http://demo-collector:4318  propagators:  - tracecontext  - baggage  sampler:  type: parentbased_traceidratio  argument: "1" EOF 

Par défaut, la ressource Instrumentation qui auto-instrumente les services .NET utilise otlp avec le protocole http/protobuf. Cela signifie que le point de terminaison configuré doit être capable de recevoir OTLP sur http/protobuf. Par conséquent, l’exemple utilise http://demo-collector:4318, qui se connectera au port http du otlpreceiver du collecteur créé à l’étape précédente.

Exclure l’auto-instrumentation

Par défaut, l’auto-instrumentation .NET est livrée avec beaucoup de bibliothèques d’instrumentation. Cela rend l’instrumentation facile, mais pourrait créer trop de données ou des données indésirables. S’il y a des bibliothèques que vous ne voulez pas utiliser, vous pouvez définir OTEL_DOTNET_AUTO_[SIGNAL]_[NAME]_INSTRUMENTATION_ENABLED=false où [SIGNAL] est le type du signal et [NAME] est le nom sensible à la casse de la bibliothèque.

apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata:  name: demo-instrumentation spec:  exporter:  endpoint: http://demo-collector:4318  propagators:  - tracecontext  - baggage  sampler:  type: parentbased_traceidratio  argument: '1'  dotnet:  env:  - name: OTEL_DOTNET_AUTO_TRACES_GRPCNETCLIENT_INSTRUMENTATION_ENABLED  value: false  - name: OTEL_DOTNET_AUTO_METRICS_PROCESS_INSTRUMENTATION_ENABLED  value: false 

En savoir plus

Pour plus de détails, voir la documentation Instrumentation Zero-code .NET.

Deno

La commande suivante crée une ressource Instrumentation de base qui est configurée pour instrumenter les services Deno.

kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata:  name: demo-instrumentation spec:  env:  - name: OTEL_DENO  value: 'true'  exporter:  endpoint: http://demo-collector:4318  propagators:  - tracecontext  - baggage  sampler:  type: parentbased_traceidratio  argument: '1' EOF 

Les processus Deno exportent automatiquement les données de télémétrie vers le point de terminaison configuré lorsqu’ils sont démarrés avec la variable d’environnement OTEL_DENO=true. Par conséquent, l’exemple spécifie cette variable d’environnement dans le champ env de la ressource Instrumentation, afin qu’elle soit définie pour tous les services qui ont des variables d’environnement injectées avec cette ressource Instrumentation.

Par défaut, la ressource Instrumentation qui auto-instrumente les services Deno utilise otlp avec le protocole http/protobuf. Cela signifie que le point de terminaison configuré doit être capable de recevoir OTLP sur http/protobuf. Par conséquent, l’exemple utilise http://demo-collector:4318, qui se connecte au port http/protobuf du otlpreceiver du collecteur créé à l’étape précédente.

Options de configuration

Par défaut, l’intégration OpenTelemetry de Deno exporte la sortie console.log() en tant que logs, tout en imprimant encore les logs vers stdout / stderr. Vous pouvez configurer ces comportements alternatifs :

• OTEL_DENO_CONSOLE=replace : exporter uniquement la sortie console.log() en tant que logs ; ne pas imprimer vers stdout / stderr.
• OTEL_DENO_CONSOLE=ignore : ne pas exporter la sortie console.log() en tant que logs ; imprimer vers stdout / stderr.

En savoir plus

Pour plus de détails, voir la documentation d’intégration OpenTelemetry de Deno.

Go

La commande suivante crée une ressource Instrumentation de base qui est configurée spécifiquement pour instrumenter les services Go.

kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata:  name: demo-instrumentation spec:  exporter:  endpoint: http://demo-collector:4318  propagators:  - tracecontext  - baggage  sampler:  type: parentbased_traceidratio  argument: "1" EOF 

Par défaut, la ressource Instrumentation qui auto-instrumente les services Go utilise otlp avec le protocole http/protobuf. Cela signifie que le point de terminaison configuré doit être capable de recevoir OTLP sur http/protobuf. Par conséquent, l’exemple utilise http://demo-collector:4318, qui se connecte au port http/protobuf du otlpreceiver du collecteur créé à l’étape précédente.

L’auto-instrumentation Go ne prend pas en charge la désactivation d’une instrumentation. Voir le dépôt Go Auto-Instrumentation pour plus de détails.

Java

La commande suivante crée une ressource Instrumentation de base qui est configurée pour instrumenter les services Java.

kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata:  name: demo-instrumentation spec:  exporter:  endpoint: http://demo-collector:4318  propagators:  - tracecontext  - baggage  sampler:  type: parentbased_traceidratio  argument: "1" EOF 

Par défaut, la ressource Instrumentation qui auto-instrumente les services Java utilise otlp avec le protocole http/protobuf. Cela signifie que le point de terminaison configuré doit être capable de recevoir OTLP sur http via des payloads protobuf. Par conséquent, l’exemple utilise http://demo-collector:4318, qui se connecte au port http de l’otlpreceiver du collecteur créé à l’étape précédente.

Exclure l’auto-instrumentation

Par défaut, l’auto-instrumentation Java est livrée avec beaucoup de bibliothèques d’instrumentation. Cela rend l’instrumentation facile, mais pourrait créer trop de données ou des données indésirables. Si il y a des bibliothèques que vous ne voulez pas utiliser, vous pouvez définir OTEL_INSTRUMENTATION_[NAME]_ENABLED=false où [NAME] est le nom de la bibliothèque. Si vous savez exactement quelles bibliothèques vous voulez utiliser, vous pouvez désactiver les bibliothèques par défaut en définissant OTEL_INSTRUMENTATION_COMMON_DEFAULT_ENABLED=false puis utiliser OTEL_INSTRUMENTATION_[NAME]_ENABLED=true où [NAME] est le nom de la bibliothèque. Pour plus de détails, voir Suppression d’instrumentation spécifique.

apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata:  name: demo-instrumentation spec:  exporter:  endpoint: http://demo-collector:4318  propagators:  - tracecontext  - baggage  sampler:  type: parentbased_traceidratio  argument: '1'  java:  env:  - name: OTEL_INSTRUMENTATION_KAFKA_ENABLED  value: false  - name: OTEL_INSTRUMENTATION_REDISCALA_ENABLED  value: false 

En savoir plus

Pour plus de détails, voir Configuration de l’agent Java.

Node.js

La commande suivante crée une ressource Instrumentation de base qui est configurée pour instrumenter les services Node.js.

kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata:  name: demo-instrumentation spec:  exporter:  endpoint: http://demo-collector:4317  propagators:  - tracecontext  - baggage  sampler:  type: parentbased_traceidratio  argument: "1" EOF 

Par défaut, la ressource Instrumentation qui auto-instrumente les services Node.js utilise otlp avec le protocole grpc. Cela signifie que le point de terminaison configuré doit être capable de recevoir OTLP sur grpc. Par conséquent, l’exemple utilise http://demo-collector:4317, qui se connecte au port grpc du otlpreceiver du collecteur créé à l’étape précédente.

Exclure les bibliothèques d’instrumentation

Par défaut, l’instrumentation zero-code Node.js a toutes les bibliothèques d’instrumentation activées.

Pour activer uniquement des bibliothèques d’instrumentation spécifiques, vous pouvez utiliser la variable d’environnement OTEL_NODE_ENABLED_INSTRUMENTATIONS comme documenté dans la documentation Instrumentation Zero-code JavaScript.

apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation # ... autres champs omis de cet exemple spec:  # ... autres champs omis de cet exemple  nodejs:  env:  - name: OTEL_NODE_ENABLED_INSTRUMENTATIONS  value: http,nestjs-core # liste séparée par des virgules des noms de paquets d'instrumentation sans le préfixe `@opentelemetry/instrumentation-`. 

Pour garder toutes les bibliothèques par défaut et désactiver uniquement des bibliothèques d’instrumentation spécifiques, vous pouvez utiliser la variable d’environnement OTEL_NODE_DISABLED_INSTRUMENTATIONS. Pour plus de détails, voir Exclure les bibliothèques d’instrumentation.

apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation # ... autres champs omis de cet exemple spec:  # ... autres champs omis de cet exemple  nodejs:  env:  - name: OTEL_NODE_DISABLED_INSTRUMENTATIONS  value: fs,grpc # liste séparée par des virgules des noms de paquets d'instrumentation sans le préfixe `@opentelemetry/instrumentation-`. 

En savoir plus

Pour plus de détails, voir la documentation sur les librairies d’instrumentation JavaScript.

Python

La commande suivante créera une ressource Instrumentation de base qui est configurée spécifiquement pour instrumenter les services Python.

kubectl apply -f - <<EOF apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata:  name: demo-instrumentation spec:  exporter:  endpoint: http://demo-collector:4318  propagators:  - tracecontext  - baggage  sampler:  type: parentbased_traceidratio  argument: "1" EOF 

Par défaut, la ressource Instrumentation qui auto-instrumente les services Python utilise otlp avec le protocole http/protobuf (gRPC n’est pas pris en charge pour le moment). Cela signifie que le point de terminaison configuré doit être capable de recevoir OTLP sur http/protobuf. Par conséquent, l’exemple utilise http://demo-collector:4318, qui se connectera au port http du otlpreceiver du collecteur créé à l’étape précédente.

Depuis la version v0.108.0 de l’opérateur, la ressource Instrumentation définit automatiquement OTEL_EXPORTER_OTLP_PROTOCOL à http/protobuf pour les services Python. Si vous utilisez une version plus ancienne de l’opérateur, vous DEVEZ définir cette variable d’environnement à http/protobuf, sinon l’auto-instrumentation Python ne fonctionnera pas.

Auto-instrumenter les logs Python

Par défaut, l’auto-instrumentation des logs Python est désactivée. Si vous souhaitez activer cette fonctionnalité, vous devez définir la variable d’environnement OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED comme suit :

apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata:  name: python-instrumentation  namespace: application spec:  exporter:  endpoint: http://demo-collector:4318  env:  propagators:  - tracecontext  - baggage  python:  env:  - name: OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED  value: 'true' 

Depuis la version v0.111.0 de l’opérateur, définir OTEL_LOGS_EXPORTER à otlp n’est plus requis.

Exclure l’auto-instrumentation

Par défaut, l’auto-instrumentation Python est livrée avec beaucoup de bibliothèques d’instrumentation. Cela rend l’instrumentation facile, mais peut créer trop de données ou des données indésirables. Si il y a des paquets que vous ne voulez pas instrumenter, vous pouvez définir la variable d’environnement OTEL_PYTHON_DISABLED_INSTRUMENTATIONS.

apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata:  name: demo-instrumentation spec:  exporter:  endpoint: http://demo-collector:4318  propagators:  - tracecontext  - baggage  sampler:  type: parentbased_traceidratio  argument: '1'  python:  env:  - name: OTEL_PYTHON_DISABLED_INSTRUMENTATIONS  value:  <liste séparée par des virgules des noms de paquets à exclure de  l'instrumentation> 

Voir les docs de configuration de l’agent Python pour plus de détails.

En savoir plus

Pour les particularités spécifiques à Python, voir la documentation de l’opérateur OpenTelemetry Python et la documentation de configuration de l’agent Python.

Maintenant que votre objet Instrumentation est créé, votre cluster a la capacité d’auto-instrumenter les services et d’envoyer des données vers un point de terminaison. Cependant, l’auto-instrumentation avec l’opérateur OpenTelemetry suit un modèle d’option d’adhésion. Pour activer l’instrumentation automatique, vous devrez ajouter une annotation à votre déploiement.

Ajouter des annotations aux déploiements existants

La dernière étape est d’activer l’instrumentation automatique pour vos services. Cela se fait en mettant à jour les spec.template.metadata.annotations de votre service pour inclure une annotation spécifique au langage :

• .NET : instrumentation.opentelemetry.io/inject-dotnet: "true"
• Deno : instrumentation.opentelemetry.io/inject-sdk: "true"
• Go : instrumentation.opentelemetry.io/inject-go: "true"
• Java : instrumentation.opentelemetry.io/inject-java: "true"
• Node.js : instrumentation.opentelemetry.io/inject-nodejs: "true"
• Python : instrumentation.opentelemetry.io/inject-python: "true"

Les valeurs possibles pour l’annotation peuvent être

• "true" - pour injecter la ressource Instrumentation avec le nom par défaut du namespace actuel.
• "my-instrumentation" - pour injecter l’instance d’Instrumentation avec le nom "my-instrumentation" dans le namespace actuel.
• "my-other-namespace/my-instrumentation" - pour injecter l’instance CR Instrumentation avec le nom "my-instrumentation" d’un autre namespace "my-other-namespace".
• "false" - ne pas injecter

Alternativement, l’annotation peut être ajoutée à un namespace, ce qui entraînera tous les services de ce namespace à opter pour l’instrumentation automatique. Voir la documentation d’auto-instrumentation avec l’opérateur pour plus de détails.

Opter pour un service Go

Contrairement à l’auto-instrumentation d’autres langages, Go fonctionne via un agent eBPF s’exécutant via un sidecar. Lorsqu’il est opté, l’opérateur injectera ce sidecar dans votre pod. En plus de l’annotation instrumentation.opentelemetry.io/inject-go mentionnée ci-dessus, vous devez également fournir une valeur pour la variables d’environnement OTEL_GO_AUTO_TARGET_EXE. Vous pouvez définir cette variable d’environnement via l’annotation instrumentation.opentelemetry.io/otel-go-auto-target-exe.

instrumentation.opentelemetry.io/inject-go: 'true' instrumentation.opentelemetry.io/otel-go-auto-target-exe: '/path/to/container/executable' 

Cette variable d’environnement peut également être définie via la ressource Instrumentation, avec l’annotation prenant la priorité. Puisque l’auto-instrumentation Go nécessite OTEL_GO_AUTO_TARGET_EXE pour être défini, vous devez fournir un chemin d’exécutable valide via l’annotation ou la ressource Instrumentation. Ne pas définir cette valeur entraîne l’arrêt de l’injection d’instrumentation, laissant le pod original inchangé.

Puisque l’auto-instrumentation Go utilise eBPF, elle nécessite également des permissions élevées. Lorsque vous l’activez, le sidecar que l’opérateur injecte nécessitera les permissions suivantes :

securityContext:  privileged: true  runAsUser: 0 

Auto-instrumenter un conteneur Python basé sur musl

Depuis la version v0.113.0 de l’opérateur, l’auto-instrumentation Python respecte également une annotation qui lui permettra de s’exécuter sur des images avec une bibliothèque C différente de glibc.

# pour les images Linux basées sur glibc, c'est la valeur par défaut et peut être omise instrumentation.opentelemetry.io/otel-python-platform: "glibc" # pour les images Linux basées sur musl instrumentation.opentelemetry.io/otel-python-platform: "musl" 

Dépannage

Si vous rencontrez des problèmes en essayant d’auto-instrumenter votre code, voici des actions que vous pouvez essayer.

La ressource Instrumentation s’est-elle installée ?

Après avoir installé la ressource Instrumentation, vérifiez qu’elle s’est installée correctement en exécutant cette commande, où <namespace> est le namespace dans lequel la ressource Instrumentation est déployée :

kubectl describe otelinst -n <namespace> 

Exemple de sortie :

Name: python-instrumentation Namespace: application Labels: app.kubernetes.io/managed-by=opentelemetry-operator Annotations: instrumentation.opentelemetry.io/default-auto-instrumentation-apache-httpd-image:  ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-apache-httpd:1.0.3  instrumentation.opentelemetry.io/default-auto-instrumentation-dotnet-image:  ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-dotnet:0.7.0  instrumentation.opentelemetry.io/default-auto-instrumentation-go-image:  ghcr.io/open-telemetry/opentelemetry-go-instrumentation/autoinstrumentation-go:v0.2.1-alpha  instrumentation.opentelemetry.io/default-auto-instrumentation-java-image:  ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:1.26.0  instrumentation.opentelemetry.io/default-auto-instrumentation-nodejs-image:  ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-nodejs:0.40.0  instrumentation.opentelemetry.io/default-auto-instrumentation-python-image:  ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.39b0 API Version: opentelemetry.io/v1alpha1 Kind: Instrumentation Metadata:  Creation Timestamp: 2023-07-28T03:42:12Z  Generation: 1  Resource Version: 3385  UID: 646661d5-a8fc-4b64-80b7-8587c9865f53 Spec: ...  Exporter:  Endpoint: http://demo-collector.opentelemetry.svc.cluster.local:4318 ...  Propagators:  tracecontext  baggage  Python:  Image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.39b0  Resource Requirements:  Limits:  Cpu: 500m  Memory: 32Mi  Requests:  Cpu: 50m  Memory: 32Mi  Resource:  Sampler: Events: <none> 

Les logs de l’opérateur OTel montrent-ils des erreurs d’auto-instrumentation ?

Vérifiez les logs de l’opérateur OTel pour toute erreur relative à l’auto-instrumentation en exécutant cette commande :

kubectl logs -l app.kubernetes.io/name=opentelemetry-operator --container manager -n opentelemetry-operator-system --follow 

Les ressources ont-elles été déployées dans le bon ordre ?

L’ordre compte ! La ressource Instrumentation doit être déployée avant de déployer l’application, sinon l’auto-instrumentation ne fonctionnera pas.

Rappelez-vous l’annotation d’auto-instrumentation :

annotations:  instrumentation.opentelemetry.io/inject-python: 'true' 

L’annotation ci-dessus dit à l’opérateur OTel de chercher un objet Instrumentation dans le namespace du pod. Elle dit également à l’opérateur d’injecter l’auto-instrumentation Python dans le pod.

Lorsque le pod démarre, l’annotation dit à l’opérateur de chercher un objet Instrumentation dans le namespace du pod, et d’injecter l’auto-instrumentation dans le pod. Il ajoute un init-container au pod de l’application, appelé opentelemetry-auto-instrumentation, qui est ensuite utilisé pour injecter l’auto-instrumentation dans le conteneur de l’app.

Si la ressource Instrumentation n’est pas présente au moment du déploiement de l’application, l’init-container ne peut pas être créé. Par conséquent, si l’application est déployée avant de déployer la ressource Instrumentation, l’ auto-instrumentation échouera.

Pour s’assurer que l’init-container opentelemetry-auto-instrumentation a démarré correctement (ou a même démarré du tout), exécutez la commande suivante :

kubectl get events -n <your_app_namespace> 

Qui devrait retourner quelque chose comme ceci :

53s Normal Created pod/py-otel-server-7f54bf4cbc-p8wmj Created container opentelemetry-auto-instrumentation 53s Normal Started pod/py-otel-server-7f54bf4cbc-p8wmj Started container opentelemetry-auto-instrumentation 

Si la sortie manque les entrées Created et/ou Started pour opentelemetry-auto-instrumentation, alors cela signifie qu’il y a un problème avec votre auto-instrumentation. Cela peut être le résultat de l’un des éléments suivants :

• La ressource Instrumentation n’a pas été installée (ou n’a pas été installée correctement).
• La ressource Instrumentation a été installée après le déploiement de l’application.
• Il y a une erreur dans l’annotation d’auto-instrumentation, ou l’annotation est au mauvais endroit — voir #4 ci-dessous.

Assurez-vous de vérifier la sortie de kubectl get events pour toute erreur, car ces pourraient aider à pointer vers le problème.

L’annotation d’auto-instrumentation est-elle correcte ?

Parfois, l’auto-instrumentation peut échouer en raison d’erreurs dans l' annotation d’auto-instrumentation.

Voici quelques choses à vérifier :

• L’auto-instrumentation est-elle pour le bon langage ?
  • Par exemple, lors de l’instrumentation d’une application Python, assurez-vous que l’ annotation ne dit pas incorrectement instrumentation.opentelemetry.io/inject-java: "true" à la place.
  • Pour Deno, assurez-vous d’utiliser l’annotation instrumentation.opentelemetry.io/inject-sdk: "true", plutôt qu’une annotation contenant la chaîne deno.
• L’annotation d’auto-instrumentation est-elle au bon endroit ? Lors de la définition d’un Deployment, les annotations peuvent être ajoutées dans l’un des deux endroits : spec.metadata.annotations, et spec.template.metadata.annotations. L’ annotation d’auto-instrumentation doit être ajoutée à spec.template.metadata.annotations, sinon elle ne fonctionnera pas.

Le point de terminaison d’auto-instrumentation a-t-il été configuré correctement ?

L’attribut spec.exporter.endpoint de la ressource Instrumentation définit où envoyer les données. Cela peut être un collecteur OTel, ou tout point de terminaison OTLP. Si cet attribut n’est pas présent, il sera par défaut à http://localhost:4317, ce qui, très probablement, enverra les données de télémétrie nulle part.

Lors de l’envoi de télémétrie vers un collecteur OTel situé dans le même cluster Kubernetes, spec.exporter.endpoint devrait référencer le nom du service OTel Collector Service.

Par exemple :

spec:  exporter:  endpoint: http://demo-collector.opentelemetry.svc.cluster.local:4317 

Ici, le point de terminaison du collecteur est défini à http://demo-collector.opentelemetry.svc.cluster.local:4317, où demo-collector est le nom du service Kubernetes Service du collecteur OTel. Dans l’exemple ci-dessus, le collecteur fonctionne dans un namespace différent de l’application, ce qui signifie que opentelemetry.svc.cluster.local doit être ajouté au nom du service du collecteur, où opentelemetry est le namespace dans lequel le collecteur réside.