Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Dépannage Open Telemetry

Il existe de nombreuses options de configuration, mais plus important encore, chaque environnement (Kubernetes) est légèrement différent. Pour déterminer où se trouve le problème, l’approche la plus rapide consiste à choisir un pod à partir duquel des données de télémétrie sont attendues :

  1. Vérifiez le début des journaux du pod, les SDK enregistreront des avertissements ou des erreurs lorsque l’instrumentation échoue au démarrage.

  2. Vérifiez également les journaux pour toute erreur liée à l’envoi de données au collecteur.

  3. Vérifiez les journaux des pod(s) du collecteur pour des erreurs de configuration ou d’initialisation, celles-ci seront enregistrées juste après le démarrage du pod.

  4. Vérifiez également les journaux du collecteur pour des erreurs liées à l’envoi de données à SUSE Observability.

Les erreurs dans les journaux donnent généralement une bonne indication du problème. Nous listons les causes les plus courantes pour lesquelles les données Open Telemetry ne sont pas disponibles pour certaines ou toutes vos applications instrumentées. Si le problème n’est pas mentionné ici, vous pouvez également consulter la documentation SDK spécifique à la langue ou la documentation du collecteur d’Open Telemetry.

Utilisez le même nom de cluster Kubernetes.

Assurez-vous d’utiliser le même nom de cluster Kubernetes pour le même cluster lorsque :

  • Vous installez le collecteur Open Telemetry.

  • Vous installez l’agent SUSE Observability.

  • Vous installez le Kubernetes StackPack.

Lorsque des noms différents sont utilisés pour le même cluster, SUSE Observability ne pourra pas faire correspondre les données d’Open Telemetry avec les données de l’agent SUSE Observability et la perspective des traces restera vide.

Le collecteur ne peut pas envoyer de données à SUSE Observability.

Le point de terminaison OTLP et la clé API de SUSE Observability sont mal configurés.

S’il y a des erreurs de connexion, il est possible que le point de terminaison OTLP soit incorrect. S’il y a des erreurs d’authentification/autorisation (codes d’état 401 et 403), il est probable que la clé API ne soit plus valide. Vérifiez que l’URL de l’endpoint OTLP configuré est celle de votre SUSE Observability, préfixée par otlp- et suffixée par :443. Par exemple, l’endpoint OTLP pour play.stackstate.com est otlp-play.stackstate.com:443.

Pour garantir que la clé API est configurée correctement, vérifiez que :

  1. le secret contient une clé API valide (vérifiez cela dans SUSE Observability)

  2. le secret est utilisé comme variables d’environnement sur le pod

  3. l’extension bearertokenauth utilise le bon schéma et la valeur de la variable d’environnement API_KEY

  4. l’extension bearertokenauth est utilisée par l’exportateur otlp/suse-observability

Certains proxies et passerelles de périmètre de sécurité ne fonctionnent pas bien avec gRPC

Si le collecteur doit envoyer des données à SUSE Observability via un proxy ou une passerelle de périmètre de sécurité, il se peut qu’ils bloquent complètement le trafic ou qu’ils laissent tomber certaines parties des messages gRPC ou qu’ils interrompent complètement la connexion gRPC à long terme de manière inattendue. La solution la plus simple est de passer de gRPC à HTTP, en remplaçant la configuration de l’exportateur otlp/suse-observability et les références à celui-ci dans la section des pipelines par l’exportateur otlphttp/suse-observability.

Ici, <otlp-http-suse-observability-endpoint> est similaire à <otlp-suse-observability-endpoint>, mais au lieu d’un préfixe otlp-, il a un préfixe otlp-http-, par exemple, otlp-http-play.stackstate.com. Pour plus de détails, consultez la configuration du collecteur.

L’application instrumentée ne peut pas envoyer de données au collecteur

L’URL est incorrecte ou le trafic est bloqué

Si le SDK enregistre des erreurs concernant l’impossibilité de résoudre le nom DNS du collecteur, il se peut que l’URL du collecteur configurée soit incorrecte. Dans Kubernetes, votre application est généralement déployée dans un espace de noms séparé de celui du collecteur. Cela signifie que le SDK doit être configuré avec le nom de domaine complet pour le service collecteur : http://<service-name>.<namespace>.svc.cluster.local:4317. Dans les étapes d’installation du collecteur, cela était http://opentelemetry-collector.open-telemetry.svc.cluster.local:4317, mais si vous avez utilisé un espace de noms ou un nom de version différent pour le collecteur, cela peut être différent dans votre situation.

Si le SDK enregistre des délais d’attente de connexion réseau, il se peut qu’il y ait une mauvaise configuration sur le collecteur ou que le mauvais port soit utilisé. Mais il est également possible que les politiques réseau de Kubernetes bloquent le trafic réseau de votre application vers le collecteur. Cela est mieux vérifié avec votre administrateur Kubernetes. Les politiques réseau doivent au moins autoriser le trafic TCP sur le port configuré (4317 et/ou 4318) depuis toutes vos applications vers le collecteur.

Le SDK de langage ne prend pas en charge gRPC.

Tous les SDK de langage ne prennent pas en charge gRPC. Si OTLP sur gRPC n’est pas pris en charge, il est préférable de passer à OTLP sur HTTP. La configuration de l’exportateur SDK décrit comment effectuer ce changement.

Le SDK de langage utilise le mauvais port.

Utiliser le mauvais port apparaît généralement comme une erreur de connexion, mais peut également se manifester par des connexions réseau se fermant de manière inattendue. Assurez-vous que l’exportateur SDK utilise le bon port lors de l’envoi de données. Voir la configuration de l’exportateur SDK.

Les pods Kubernetes avec hostNetwork activé.

Le collecteur Open Telemetry enrichit les données de télémétrie avec des métadonnées Kubernetes. De la manière dont il est configuré, toutes les données de télémétrie qui ne peuvent pas être enrichies sont supprimées. Cependant, le collecteur ne peut pas enrichir les pods qui s’exécutent avec hostNetwork: true défini automatiquement. Cela n’est pas possible car l’identification des pods se fait en utilisant l’adresse IP du pod et les pods qui utilisent le réseau hôte utilisent l’adresse IP de l’hôte.

Pour aider le collecteur à identifier un pod, nous pouvons ajouter l’attribut k8s.pod.uid aux métadonnées en instruisant le SDK de l’ajouter directement. Pour ce faire, modifiez votre spécification de pod et ajoutez les variables d’environnement suivantes à votre conteneur d’application instrumenté :

env:
  - name: POD_UID
    valueFrom:
      fieldRef:
        apiVersion: v1
        fieldPath: metadata.uid
  - name: OTEL_RESOURCE_ATTRIBUTES
    value: k8s.pod.uid=$(POD_UID)

Si la variable d’environnement OTEL_RESOURCE_ATTRIBUTES est déjà définie, ajoutez simplement le k8s.pod.uid, en utilisant une virgule comme séparateur. La valeur est une liste séparée par des virgules.

Application Node.js sur Google Kubernetes Engine.

Le SDK Node.js, uniquement sur GKE, s’attend à ce que l’espace de noms Kubernetes soit défini via la variable d’environnement NAMESPACE. S’il n’est pas défini, il ajoutera tout de même l’attribut k8s.namespace.name mais avec une valeur vide. Cela empêche le processeur d’attributs Kubernetes d’insérer le nom correct de l’espace de noms. Jusqu’à ce que cela soit corrigé, une solution de contournement consiste à mettre à jour la spécification de votre pod et à ajouter cette variable d’environnement aux conteneurs instrumentés :

env:
  - name: NAMESPACE
    valueFrom:
      fieldRef:
        apiVersion: v1
        fieldPath: metadata.namespace

Aucune métrique disponible pour l’application Node.js

L’instrumentation automatique pour Node.js, configurée via des variables d’environnement, ne prend en charge que les traces. Au moins jusqu’à ce que ce problème Open Telemetry soit résolu. Pour activer les métriques à partir de l’instrumentation automatique, des modifications de code sont nécessaires. Veuillez suivre les instructions dans la documentation Open Telemetry pour effectuer ces modifications.

Les attributs Kubernetes ne peuvent pas être ajoutés

Lors de l’installation du collecteur, un rôle de cluster et une liaison de rôle de cluster sont créés dans Kubernetes, ce qui permet au collecteur de lire les métadonnées des ressources Kubernetes. Si cela échoue ou s’ils sont supprimés, le collecteur ne pourra plus interroger l’API Kubernetes. Cela apparaîtra comme des erreurs dans le journal du collecteur, les erreurs incluent les types de ressources pour lesquels les métadonnées n’ont pas pu être récupérées.

Pour corriger cela, réinstallez le collecteur avec le chart Helm et assurez-vous d’avoir les autorisations requises pour créer le rôle de cluster et le lien de rôle de cluster. Alternativement, demandez à votre administrateur de cluster d’effectuer l’installation du collecteur avec les autorisations requises.