Mappages de services liés à OpenTelemetry et corrélation d'infrastructure
Cette rubrique fournit des conseils aux clients qui envoient manuellement des données d' OpenTelemetry s à Instana.
Si vous utilisez la distribution « Instana » du collecteur « OpenTelemetry » ( IDOT ), vous n'avez pas besoin de suivre la procédure de configuration manuelle, car « IDOT » gère automatiquement les mappages de services et la corrélation de l'infrastructure par défaut.
Vous pouvez suivre les instructions fournies dans ce document pour intégrer OpenTelemetry à Instana et activer des mappages de services complets ainsi que la corrélation de l'infrastructure lorsque vous envoyez manuellement des données de télémétrie. Ce document explique comment utiliser certains attributs de ressources d' OpenTelemetry s afin d'optimiser la liaison et la visibilité des données au sein d' Instana, en particulier dans les environnements Kubernetes et le middleware IBM.
OpenTelemetry cartographie des services
Instana s'aligne sur les conventions sémantiques d' OpenTelemetry pour associer les métriques, les intervalles et les journaux aux services. Ces conventions définissent des noms d'attributs et des modèles d'utilisation normalisés, favorisant ainsi la cohérence et l'interopérabilité entre les outils d'observabilité. En se conformant à ces normes, Instana garantit une intégration transparente des données de télémétrie dans sa plateforme de surveillance et d'observabilité.
Voici les principaux attributs utilisés dans la cartographie des services :
- attribut de ressource
service.name - Attribut « trace span »
peer.service
attribut de ressource service.name
L'attribut service.name identifie de manière unique un service dans OpenTelemetry. Chaque application, microservice ou composant dispose d'un identifiant unique et logique service.name afin de permettre un filtrage, une analyse et une visualisation efficaces des données de télémétrie. Instana associe ces données service.name à ses services, en reliant les traces, les métriques et les journaux à l'application qui les a générés. Une nomenclature cohérente service.name et descriptive permet de garantir un regroupement précis et une meilleure observabilité au sein d' Instana.
Dans l' OpenTelemetry,, vous pouvez définir service.name l'attribut à différents niveaux de votre application, en fonction des besoins spécifiques de votre configuration d'observabilité. Dans le tableau ci-dessous, vous pouvez voir les différentes façons dont service.name peut être configuré :
| Niveau | Méthode de définition | Exemple | Cas d'utilisation |
|---|---|---|---|
| Code de l'application | Directement dans l'application lors de l'instrumentation manuelle | service.name="orders-service" |
Lorsque le service.name est codé en dur ou configuré dans l'application elle-même |
| Variable d'environnement | En utilisant la variable OTEL_SERVICE_NAME d'environnement |
OTEL_SERVICE_NAME=payments-service |
Courant dans les environnements qui utilisent l'auto-instrumentation sur plusieurs services |
| Attributs de ressource | En utilisant OTEL_RESOURCE_ATTRIBUTES des paires clé-valeur |
OTEL_RESOURCE_ATTRIBUTES=service.name=inventory-service |
Utile pour combiner service.name avec d'autres attributs tels que host.id |
| Configuration du collecteur | Dans OpenTelemetry Collector, à l'aide du resource processeur |
service.name: shipping-service |
Contrôle centralisé des données de télémétrie avant leur transmission au serveur |
Attribut « trace span » peer.service
Dans ` OpenTelemetry, `, peer.service l'attribut spécifie le nom du service distant auquel un span se connecte, ce qui permet d'identifier les dépendances externes telles que les bases de données, les intermédiaires de messagerie ou d'autres microservices. Instana se connecte peer.service à un service d' Instana, permettant ainsi de visualiser les dépendances et les interactions entre les services.
- Bibliothèques d'instrumentation : certaines bibliothèques s'initialisent automatiquement
peer.servicelorsqu'elles sont correctement configurées. Par exemple :- JDBC : L'instrumentation d' OpenTelemetry JDBC peut déduire les informations
peer.servicede connexion à la base de données. - HTTP Clients : les bibliothèques de la bibliothèque « HTTP », telles que Apache et HttpClient, peuvent être dérivées
peer.serviceà partir du nom d'hôte du service distant.
- JDBC : L'instrumentation d' OpenTelemetry JDBC peut déduire les informations
Dans le tableau ci-dessous, vous pouvez voir les différentes façons dont peer.service peut être défini ou configuré dans OpenTelemetry:
| Niveau | Description | Exemple | Cas d'utilisation |
|---|---|---|---|
| Code de l'application | Définissez directement peer.service l'attribut dans votre code à l'aide de la balise OpenTelemetry API |
span.setAttribute("peer.service", "backend-service") |
Lorsque vous disposez de connaissances spécifiques sur le service concerné et que vous souhaitez lui attribuer un nom personnalisé |
| Fichiers de configuration (propriété système) | Définissez la peer.service valeur dans les propriétés système utilisées par l'agent ou le SDK d' OpenTelemetry |
otel.instrumentation.common.peer-service-mapping: "api.example.com=example-api-service,1.2.3.4=cats-service" |
Lorsque vous souhaitez associer des noms d'hôte, des adresses IP ou une combinaison des deux à des noms de service dans un fichier de configuration |
| Variables d'environnement | Définissez cette peer.service valeur en tant que variable d'environnement accessible à votre application |
OTEL_INSTRUMENTATION_COMMON_PEER_SERVICE_MAPPING="api.example.com=example-api-service,1.2.3.4=cats-service" |
Lorsque vous devez définir dynamiquement la peer.service valeur en fonction des conditions d'exécution ou de l'environnement de déploiement (à l'instar des propriétés système, mais en utilisant des variables d'environnement) |
| Bibliothèque d'instruments | Définis automatiquement par les bibliothèques d' OpenTelemetry | peer.service="postgresql" |
C'est courant pour les bibliothèques courantes telles que les clients de bases de données et d' HTTP, qui s'initialisent peer.service automatiquement |
Cartographie des services pour les protocoles courants
Outre les attributs généraux tels que service.name et peer.service, le document « OpenTelemetry » définit un ensemble complet de conventions sémantiques pour des protocoles bien connus, notamment HTTP, RPC, les bases de données, les systèmes de messagerie, etc.
Pour obtenir la liste complète des protocoles, consultez les conventions sémantiques de Trace.
HTTP attributs de balise span
OpenTelemetry fournit des conventions sémantiques pour les segments d' HTTP, afin d'assurer la cohérence entre les différents systèmes de traçage, notamment des attributs qui permettent de mieux comprendre les requêtes et les réponses d' HTTP.
Dans le tableau ci-dessous, vous pouvez voir les différentes façons dont les attributs de http balise `span` peuvent être définis ou configurés dans OpenTelemetry:
| Attribut | Description | Exemple |
|---|---|---|
http.method |
HTTP méthode (GET, POST ) | http.method="GET" |
http.route |
Chemin d'accès de la requête HTTP | http.route="/webshop/articles/:id" |
url.path |
Composante du chemin d'accès de l' URL complète | url.path="/webshop/articles/4" |
http.host |
Nom d'hôte du serveur | http.host="api.example.com" |
http.target |
URL s de destination de la requête | http.target="/users" |
Bien que http.host et http.target permettent souvent de déduire le service, le routage dynamique ou la découverte de services peuvent nécessiter des informations supplémentaires provenant de fichiers de configuration ou de registres de services pour assurer un mappage précis.
Les appels de procédure à distance couvrent les attributs
OpenTelemetry fournit des conventions sémantiques pour les segments de RPC (RPC) afin d'assurer la cohérence entre les systèmes de traçage, y compris des attributs qui fournissent des informations utiles. Les principaux attributs de portée d' RPC s utilisés pour le mappage des services dans OpenTelemetry sont les suivants :
- rpc.method : Spécifie la méthode ou la fonction appelée, en fournissant des informations détaillées sur l'opération.
- rpc.service : identifie le nom du service appelé, ce qui est essentiel pour associer les appels de type « RPC » à des services spécifiques.
| Attribut | Description | Exemple |
|---|---|---|
rpc.service |
Nom du service distant | rpc.service="user-service" |
rpc.method |
Une méthode ou une fonction qui est appelée | rpc.method="GetUserInfo" |
En combinant rpc.service et rpc.method avec d'autres attributs tels que peer.service, les appels vers RPC peuvent être mappés vers les services correspondants.
Attributs de portée de la base de données
OpenTelemetry fournit des conventions sémantiques pour les segments de base de données afin d'assurer la cohérence entre les systèmes de traçage, en proposant des attributs clés qui apportent des informations précieuses sur les opérations et les interactions au sein de la base de données. Ces informations sont essentielles pour comprendre les performances et le comportement des systèmes de bases de données au sein d'une application distribuée.
Le tableau ci-dessous présente les principaux attributs de plage de bases de données utilisés pour le mappage des services dans l' OpenTelemetry.
| Attribut | Description | Exemple |
|---|---|---|
db.system |
Système de base de données (par exemple, MySQL et PostgreSQL ) | db.system="mysql" |
db.instance |
Nom ou identifiant de l'instance de base de données | db.instance="my_database" |
db.name |
Le nom de la base de données à laquelle on accède | db.name="users_db" |
db.statement |
Requête SQL ou commande de base de données exécutée | db.statement="SELECT * FROM users" |
db.operation |
Type d'opération sur la base de données (par exemple, SELECT et INSERT) | db.operation="SELECT" |
Bien que ces caractéristiques décrivent principalement les interactions avec la base de données, elles peuvent contribuer indirectement à la cartographie des services. Par exemple, db.instance l'attribut pourrait permettre d'identifier le service qui interagit avec une instance de base de données spécifique.
Attributs de portée des messages
OpenTelemetry fournit des conventions sémantiques pour les segments de messagerie afin d'assurer la cohérence entre les systèmes de traçage, y compris des attributs qui fournissent des informations utiles.
Les principaux attributs de la plage de messages utilisés pour le mappage des services dans l' OpenTelemetry. sont les suivants :
| Attribut | Description | Exemple |
|---|---|---|
messaging.system |
Système de messagerie utilisé (par exemple, Kafka, RabbitMQ, et AMQP) | messaging.system="kafka" |
messaging.destination |
Adresse de destination (par exemple, nom du sujet et nom de la file d'attente) | messaging.destination="user-events" |
messaging.operation |
Opération effectuée (par exemple, ENVOI, RÉCEPTION, PUBLICATION et ABONNEMENT) | messaging.operation="SEND" |
Ces attributs permettent de cartographier les services en fonction des systèmes de messagerie avec lesquels ils interagissent et des sujets ou files d'attente spécifiques qu'ils utilisent. Par exemple, si l'on sait qu'un service envoie des messages à un sujet Kafka spécifique, messaging.destination l'attribut peut aider à identifier ce service.
OpenTelemetry corrélation des infrastructures connexes
Instana prend en charge les attributs de ressource décrits sur OpenTelemetry ainsi que de nombreuses définitions couramment utilisées dans les conventions sémantiques relatives aux ressources disponibles sur OpenTelemetry. Instana présente les flux de services et les ressources d' OpenTelemetry s sous forme d'entités d'infrastructure. Vous pouvez associer ces entités à des entités physiques telles que des processus, des hôtes ou des conteneurs, ainsi qu'à des segments de trace et à des enregistrements de journaux, en particulier lorsqu'un agent d' Instana s s'exécute sur le même hôte.
Si vous utilisez l'auto-instrumentation d' OpenTelemetry s basée sur le langage, utilisez la dernière version de l'agent OpenTelemetry. Le dernier agent génère suffisamment d'attributs de ressources pour établir des liens entre les entités, les segments et les enregistrements de journal.
service.name et service.instance.id, les attributs de ressource suivants sont essentiels pour l'établissement de liens :
Dans les environnements d' Kubernetes, l'attribut k8s.pod.uid « resource » est essentiel pour associer les entités d' OpenTelemetry aux pods d' Kubernetes. Il établit des liens entre les intervalles, les journaux et les indicateurs associés à ces pods, offrant ainsi une vue d'ensemble cohérente des performances des applications et de l'infrastructure.
Stratégies de corrélation
Instana utilise différentes stratégies pour établir une corrélation entre les segments d' OpenTelemetry s et les entités d'infrastructure, en fonction des données de télémétrie disponibles :
Stratégie n° 1 : traces et indicateurs d' OpenTelemetry s (recommandé)
Si votre service génère à la fois des traces et des métriques via l' OpenTelemetry, le processus suivant se déroule :
- Instana crée une entité « OpenTelemetry » à partir des données de métriques.
- OpenTelemetry Les liens renvoient automatiquement vers cette entité OpenTelemetry grâce aux attributs de
service.nameressourceservice.instance.idet. Ce processus établit la chaîne de corrélation suivante : intervalle de temps ( OpenTelemetry ) > entité de temps ( OpenTelemetry ).
L'entité « OpenTelemetry » utilise différents attributs de ressource pour établir un lien avec les entités d'infrastructure existantes correspondantes :
k8s.pod.uid- liens vers les podcasts « Kubernetes ».Chaîne de corrélation : OpenTelemetry span > OpenTelemetry entity > Kubernetes pod > autres entités d' Kubernetes d'infrastructure
container.id- liens vers des entités conteneurs.Chaîne de corrélation : portée « OpenTelemetry » > entité « OpenTelemetry » > entité «container» > autres entités d'infrastructure
process.pidethost.id- des liens vers des entités de processus.Chaîne de corrélation : portée « OpenTelemetry » > entité « OpenTelemetry » > entité «Process» > autres entités d'infrastructure
host.id- liens vers l'entité hôte.Chaîne de corrélation : intervalle « OpenTelemetry » > entité « OpenTelemetry » > entité « Host »
Assurez-vous que les attributs des ressources sont cohérents entre les métriques et les traces provenant d'un même service. Pour savoir comment définir ces attributs de ressource, consultez l'exemple de configuration.
Stratégie 2 : traces « OpenTelemetry » uniquement (à l'aide du collecteur OpenTelemetry )
Si votre application génère uniquement des traces (spans) et non des métriques, utilisez la fonction spanmetrics connecteur dans le OpenTelemetry Collector pour générer des métriques à partir des traces. Cela permet d'appliquer la même stratégie de corrélation que la stratégie 1.
connectors:
spanmetrics: null
service:
pipelines:
metrics:
receivers:
- spanmetrics
traces:
exporters:
- spanmetricsStratégie 3 : Corrélation des infrastructures pour le traçage de l' OpenTelemetry s à l'aide du middleware d' IBM
Instana fournit une infrastructure permettant d'assurer la traçabilité d' OpenTelemetry s avec les intergiciels IBM, notamment IBM MQ, IBM App Connect Enterprise (ACE) et IBM DataPower.
- Pour les appels vers IBM MQ, vous pouvez établir une liaison avec une entité de file d'attente collectée par le capteur Instana IBM MQ.
- Pour les appels vers IBM ACE, vous pouvez établir un lien vers une entité de flux de messages collectée par le capteur IBM ACE de l' Instana.
- Pour les appels vers IBM DataPower, vous pouvez établir un lien vers une entité de domaine collectée par le capteur Instana IBM DataPower.
Les liaisons d'infrastructure sont généralement créées automatiquement pour les appels « OpenTelemetry » vers le middleware « IBM » et ne nécessitent aucune configuration supplémentaire. Ces liens apparaissent sur la page des détails de l'appel.
L'exemple suivant illustre la configuration de l'infrastructure pour les appels de type « OpenTelemetry » vers l'entité de file d'attente « IBM MQQ1» :
Stratégie 4 : Corrélation des infrastructures pour le traçage de l' OpenTelemetry s à l'aide d'entités de processus
process.pid,host.id, etentity.type(avec la valeurprocess)Chaîne de corrélation : portée de l' OpenTelemetry > Entité de processus > autres entités d'infrastructure
process.pidLimite : dans les environnements d' Kubernetes, cette stratégie est difficile à mettre en œuvre de manière fiable, car la plupart des SDK d' OpenTelemetry fournissent le PID du processus au sein du conteneur, mais les entités de processus d' Instana utilisent le PID du processus au niveau de l'hôte pour effectuer la corrélation de l'infrastructure.
Exemple de configuration
La démo officielle de l' OpenTelemetry illustre les meilleures pratiques pour la configuration service.namede, service.instance.id, k8s.pod.uid, et d'autres attributs de ressources d' OpenTelemetry.
Dans les applications qui utilisent l'instrumentation manuelle d' OpenTelemetry ( OTel ), le service.name est généralement défini dans le code de l'application. Toutefois, si vous utilisez l'instrumentation automatique d' OTel, vous devez la configurer à l'aide de la variable OTEL_SERVICE_NAME d'environnement (prise en charge par tous les SDK de langage) ou OTEL_RESOURCE_ATTRIBUTES. L'exemple suivant illustre leur utilisation :
- env:
- name: OTEL_SERVICE_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.labels['app.kubernetes.io/component']
- name: OTEL_RESOURCE_ATTRIBUTES
value: service.name=$(OTEL_SERVICE_NAME),service.namespace=opentelemetry-demoPour ajouter les attributs de service.instance.id ressource k8s.pod.uid , container.id, et, utilisez les resource processeurs k8sattributes et dans le collecteur OpenTelemetry. Envoyez les traces et les métriques à l'adresse Instana.
Le SDK d' OpenTelemetry s définit généralement l'attribut « process.pid resource » automatiquement.
Vous ne devez fournir l'attribut « host.id resource » que lorsque vous envoyez des données de type « OpenTelemetry » directement au backend « Instana ». Pour plus d'informations, consultez la section « Envoi de données d' OpenTelemetry s vers le backend Instana ». Il n'est pas nécessaire de fournir host.id ces informations lorsque vous envoyez des données d' OpenTelemetry s à l'agent Instana.
Si votre application génère uniquement des traces (spans) et non des métriques, utilisez le spanmetrics connecteur. Instana sert spanmetrics à générer des entités d' OpenTelemetry, ce qui permet de mettre en corrélation les segments d'application avec les entités d'infrastructure (telles que les pods d' Kubernetes et les nœuds physiques). spanmetrics contribue à garantir une corrélation et une visibilité totales au sein d' Instana.
L'exemple suivant montre comment configurer le collecteur OpenTelemetry avec le k8sattributes processeur, resource le processeur et spanmetrics le connecteur afin d'optimiser la corrélation au sein de l'infrastructure :
connectors:
spanmetrics: null
exporters:
otlp:
endpoint: instana-agent.instana-agent:4317
tls:
insecure: true
processors:
batch: {}
k8sattributes:
extract:
metadata:
- k8s.namespace.name
- k8s.deployment.name
- k8s.statefulset.name
- k8s.daemonset.name
- k8s.cronjob.name
- k8s.job.name
- k8s.node.name
- k8s.pod.name
- k8s.pod.uid
- k8s.pod.start_time
- container.id
passthrough: false
pod_association:
- sources:
- from: resource_attribute
name: k8s.pod.ip
- sources:
- from: resource_attribute
name: k8s.pod.uid
- sources:
- from: connection
resource:
attributes:
- action: insert
from_attribute: k8s.pod.uid
key: service.instance.id
receivers:
otlp:
protocols:
grpc:
endpoint: ${env:MY_POD_IP}:4317
http:
cors:
allowed_origins:
- http://*
- https://*
endpoint: ${env:MY_POD_IP}:4318
service:
pipelines:
logs:
exporters:
- otlp
processors:
- k8sattributes
- resource
- batch
receivers:
- otlp
metrics:
exporters:
- otlp
processors:
- k8sattributes
- resource
- batch
receivers:
- otlp
- spanmetrics
traces:
exporters:
- otlp
- spanmetrics
processors:
- k8sattributes
- resource
- batch
receivers:
- otlp- Si vos applications OpenTelemetry ( OTel ) génèrent déjà des métriques, vous n'avez pas besoin de configurer le
spanmetricsconnecteur. - Assurez-vous que le
k8sattributesprocesseur est placé avant leresourceprocesseur dans le pipeline. - Définissez
passthroughl'attribut duk8sattributesprocesseur surfalse. - Le
resourceprocesseur copie lek8s.pod.uidcontenu dansservice.instance.idafin de permettre une identification correcte de l'entité. - Si votre SDK OpenTelemetry fournit déjà cette
service.namefonctionnalité, vous pouvez la conserver. Il n'est pas nécessaire de le redéfinir dans la configuration du collecteur. Ne configurez cette optionservice.namedans le collecteur que si le SDK ne l'a pas déjà définie ou si vous devez harmoniser la nomenclature entre plusieurs services.
Dépannage en cas d'absence de corrélation de l'infrastructure
Absence de corrélation avec les entités d' OpenTelemetry
Si les segments d' OpenTelemetry s ne renvoient pas vers des entités d' OpenTelemetry s, procédez aux vérifications suivantes :
- Vérifiez que l'entité « OpenTelemetry » existe :
- Dans l'interface utilisateur d' Instana, cliquez sur Infrastructure > Analyser l'infrastructure.
- Sélectionnez « OpenTelemetry » dans la liste des types d'entités.
- Utilisez
service.nameouservice.instance.idcomme filtre de balises pour rechercher l'entité OpenTelemetry correspondante. - Si l'entité n'existe pas, vérifiez que votre service génère bien des métriques d' OpenTelemetry s (et pas seulement des traces).
- Vérifier que les attributs des ressources correspondent :
- Assurez-vous que les
service.nameattributs et de vos segmentsservice.instance.idde portée dans OpenTelemetry correspondent auxservice.namevaleursservice.instance.idet de l'entité OpenTelemetry. - Si vous utilisez le collecteur « OpenTelemetry » avec plusieurs pipelines, assurez-vous que la configuration
resourcedu processeur est identique dans tous les pipelines pour un même service.
- Assurez-vous que les
Absence de corrélation avec les pods « Kubernetes »
Si les intervalles d' OpenTelemetry s ne correspondent pas aux pods d' Kubernetes, effectuez les vérifications suivantes :
- Vérifiez que l'entité « OpenTelemetry » existe :
- Dans l'interface utilisateur d' Instana, cliquez sur Infrastructure > Analyser l'infrastructure > OpenTelemetry.
- Utilisez
service.nameouservice.instance.idpour filtrer et trouver votre entité « OpenTelemetry ».
- Vérifiez si le pod « Kubernetes » apparaît dans le fil d'Ariane de l'entité « OpenTelemetry » :
- Ouvrez les détails de l'entité « OpenTelemetry ».
- Consultez le fil d'Ariane en haut de la page.
- Si le pod « Kubernetes » apparaît dans le fil d'Ariane, cela signifie que la mise en correspondance fonctionne.
- Vérifiez que le pod « Kubernetes » existe dans « Instana » :
- Dans l'interface utilisateur d' Instana, cliquez sur Infrastructure > Analyser l'infrastructure > Pods.
- Filtrez par
k8s.pod.uidpour rechercher le pod souhaité. - Si le pod n'existe pas, vérifiez que l'agent d' Instana s s'exécute dans le même cluster d' Kubernetes.
- Vérifiez que la
k8s.pod.uidvaleur figurant dans vos données « OpenTelemetry » correspond bien à l'UID réel du pod dans « Kubernetes ».
Absence de corrélation avec les entités de processus
Si les intervalles de l' OpenTelemetry ation ne correspondent pas aux entités de processus, procédez aux vérifications suivantes :
- Vérifiez que
process.pidest correct :- Dans les environnements d' Kubernetes, veillez à utiliser le PID du processus au niveau de l'hôte, et non celui du conteneur.
- Dans l'interface utilisateur d' Instana, cliquez sur Infrastructure > Analyser l'infrastructure > Processus.
- Ouvrez les détails de l'entité de processus et vérifiez l 'ID du processus dans le panneau de gauche.
- Assurez-vous que la longueur de la balise
process.piddans votre fichier OpenTelemetry correspond à cette valeur.
- Vérifiez que
host.idest correct :- Depuis la page de détails de l'entité de processus, utilisez le fil d'Ariane situé en haut de la page pour accéder à l'entité hôte correspondante.
- Vérifiez l 'ID de l'hôte dans le volet gauche de la page de détails de l'entité hôte.
- Assurez-vous que la longueur de la balise
host.iddans votre fichier OpenTelemetry correspond à cette valeur.
Absence de corrélation avec les entités de conteneur
Si les plages d' OpenTelemetry s ne correspondent pas aux entités de conteneur, procédez aux vérifications suivantes :
- Vérifiez que l'entité « OpenTelemetry » existe :
- Dans l'interface utilisateur d' Instana, cliquez sur Infrastructure > Analyser l'infrastructure > OpenTelemetry.
- Utilisez
service.nameouservice.instance.idpour filtrer et trouver votre entité « OpenTelemetry ».
- Vérifiez si le conteneur apparaît dans le fil d'Ariane de l'entité « OpenTelemetry » :
- Ouvrez les détails de l'entité « OpenTelemetry ».
- Vérifiez le fil d'Ariane de l'entité.
- Si le conteneur apparaît dans le fil d'Ariane, cela signifie que la mise en correspondance fonctionne.
- Vérifiez que l'entité « container » existe dans Instana :
- Dans l'interface utilisateur d' Instana, cliquez sur Infrastructure > Analyser l'infrastructure.
- Recherchez le type de conteneur, puis sélectionnez l'un des environnements d'exécution de conteneurs pris en charge (par exemple, Containerd, CRI-O, Docker, OTel, Kubernetes ou Podman ).
- Filtrez par
containerIdpour rechercher le conteneur souhaité. - Si le conteneur n'existe pas, vérifiez que l'agent d' Instana s s'exécute sur le même hôte.
- Vérifiez que la
container.idvaleur figurant dans vos données « OpenTelemetry » correspond bien à l'ID réel du conteneur.
Absence de corrélation d'infrastructure pour les appels vers le middleware « IBM »
Si le nom d'hôte collecté par le suivi « OpenTelemetry » du middleware « IBM » diffère du nom d'hôte collecté par le capteur du middleware « Instana », un Infrastructure: Correlation missing message peut s'afficher dans l'interface utilisateur d' Instana.
En fonction de l'environnement dans lequel le middleware IBM est déployé, vous pouvez résoudre ce problème dans la configuration de OpenTelemetry ou dans la configuration du middleware IBM :
OpenTelemetry configuration
- Environnement non- Kubernetes
Si le middleware IBM est déployé sur une machine virtuelle standard ( VM ), configurez un alias d'hôte pour les appels OpenTelemetry comme suit :
Pour résoudre ce problème, définissez un alias d'hôte pour les appels OpenTelemetry en suivant les étapes suivantes :
Sur le serveur exécutant IBM MQ, IBM ACE ou IBM DataPower, arrêtez le service correspondant et définissez une variable d'environnement :
OTEL_RESOURCE_ATTRIBUTES=host.alias=<alias_of_the_host>Remplacez <alias_de_l'hôte> par le nom d'hôte détecté par le capteur middleware Instana.
Par exemple, si le capteur Instana IBM MQ recueille le nom d'hôte
instmq1.example.com, mais que le traçage IBM MQ OpenTelemetry recueille l'adresse IP de l'hôte, vous devez exporter la variable comme suit :OTEL_RESOURCE_ATTRIBUTES=host.alias=instmq1.example.comRedémarrez IBM MQ, IBM ACE ou IBM DataPower.
- Kubernetes environnement
Lorsqu'un middleware d' IBM (tel que IBM ACE, IBM MQ ou DataPower ) est installé sur un cluster Kubernetes, il s'exécute dans un conteneur, ce qui diffère de l'environnement standard d' VM. Contrairement aux machines virtuelles, les conteneurs ont des noms d'hôte ou des adresses IP dynamiques, ce qui entraîne des appels non surveillés et une corrélation incorrecte de l'infrastructure dans l' Instana.
Pour résoudre ce problème, procédez comme suit :
Exporter les variables d'environnement dans l'instance de la ressource personnalisée (CR) du middleware « IBM ». Dans le fichier de configuration CR, ajoutez les variables d'environnement suivantes dans la section deployment/demonset :
spec: containers: - env: - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP - name: OTEL_RESOURCE_ATTRIBUTES value: "host.alias=$(POD_IP)"Attendez que le CR se resynchronise avec les déploiements concernés.
Redémarrez IBM MQ, IBM ACE ou IBM DataPower, si nécessaire.
Cette configuration permet de s'assurer que chaque conteneur middleware d' IBM comporte sa POD_IP propre host.alias valeur, ce qui facilite la corrélation au sein de l'infrastructure.
IBM configuration du middleware
Pour un serveur d'intégration d' IBM App Connect Enterprise, vous pouvez configurer une trace d' OpenTelemetry s pour tous les flux de messages au sein d'un serveur d'intégration et exporter les données de span vers un collecteur d' OpenTelemetry s.
Dans la ResourceManagers section du server.conf.yaml fichier, définissez les propriétés openTelemetryHostName de la OpenTelemetryManager sous-section afin de remplacer Hostname l'attribut pour les segments de télémétrie. Pour plus d'informations, consultez la section « Configuration de la trace d' OpenTelemetry s pour un serveur d'intégration ».