Problèmes connus et limitations

Consultez la liste des problèmes connus et des limitations concernant l'observabilité d' IBM Instana.

Problèmes connus

Incompatibilité du module « sidecar » d' CrowdStrike Falcon avec l'agent d' Instana

Le conteneur d'agent « Instana » n'est pas compatible avec le sidecar « CrowdStrike Falcon ». Vous ne pouvez utiliser Falcon qu'en tant qu' DaemonSet.

Problème de mémoire avec l'agent d' Instana sur le serveur d' Windows s 2016

Modifier en ligne

Sur les serveurs Windows Server 2016, une bibliothèque utilisée par l'agent Instana consomme progressivement de la mémoire sans la libérer correctement, ce qui peut entraîner une augmentation de l'utilisation de la mémoire sur les systèmes Windows concernés. Afin de maîtriser la consommation de mémoire, les agents d' Instana s sont redémarrés automatiquement. La fonction de redémarrage automatique permet d'éviter que le problème de mémoire n'ait un impact sur les mises à jour automatiques de l'agent. Par défaut, tous les agents d' Instana s déployés sur un serveur d' Windows s 2016 redémarrent tous les 7 jours entre 5 h 00 et 5 h 30. Cette fonctionnalité est disponible depuis la version 1.1.702 du pack d'agents d' Instana. La version du pack d'agents peut être vérifiée dans les journaux de démarrage de l'agent d' Instana.

Pour modifier le comportement par défaut en cas de redémarrage, définissez les variables d'environnement suivantes avant de lancer l'agent d' Instana.


Nom de la variable d'environnement	Par défaut	Important
`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_ENABLED`	`true`	Indicateur d'activation ou de désactivation du redémarrage automatique.
`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME`	`5:15`	L'heure à laquelle l'agent « Instana » redémarre.
`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN`	`30`	Gigue en minutes pour définir la plage de temps au cours de laquelle l'agent redémarre. Ce décalage vise à empêcher les agents d' Instana ation de redémarrer simultanément. L'heure de redémarrage est sélectionnée de manière aléatoire dans la plage spécifiée. Pour modifier la randomisation de l'heure de redémarrage, définissez une valeur supérieure à 1. L'intervalle pour l'heure de redémarrage est calculé à l'aide de la formule `INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME` -(`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN`/2) et `INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_TIME` + (`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_JITTER_IN_MIN`/2). Par exemple, si l'heure de redémarrage est fixée à 5.15 h avec une marge de 30 minutes, le redémarrage aura lieu entre 05 h 00 et 05 h 30.
`INSTANA_AUTO_RESTART_WINDOWS_SERVER_2016_RESTART_MIN_INTERVAL_IN_DAYS`	`7`	Intervalle avant le prochain redémarrage. Définissez une valeur supérieure à zéro.

Conflits d'identifiant d'agent dus à des adresses MAC identiques

Modifier en ligne

Lorsque plusieurs systèmes partagent la même adresse MAC, ils génèrent des identifiants d'agent identiques, ce qui entraîne des conflits d'identité d'hôte. Cela a pour conséquence que les agents écrasent les données les uns des autres, et qu'un processus provenant d'un hôte puisse être attribué à tort à un autre.

Pour résoudre ce problème, vous pouvez utiliser l'une des options de configuration suivantes :

Option 1 : Ajouter le nom de domaine complet (FQDN) à l'identifiant de l'agent

Définissez la variable d'environnement INSTANA_APPEND_FQDN_TO_AGENT_ID=true afin d'inclure le nom de domaine complet (FQDN) dans l'identifiant de l'agent. Cette configuration garantit que chaque identifiant d'agent est unique, même si les adresses MAC sont identiques.

Utilisez cette option lorsque plusieurs hôtes partagent la même adresse MAC mais possèdent des noms de domaine complets (FQDN) ou des noms d'hôte uniques.

Option 2 : Conserver l'identifiant unique de l'hôte

Définissez la variable d'environnement INSTANA_PERSIST_HOST_UNIQUE_ID=true pour générer et conserver un identifiant d'agent unique basé sur un hachage. Lors de son premier démarrage, l'agent génère un identifiant unique et l'enregistre sur le disque, garantissant ainsi que le même identifiant est utilisé à chaque redémarrage de l'agent.

L'agent enregistre l'identifiant aux emplacements spécifiques à la plateforme suivants. Si le site principal n'est pas accessible, l'agent tente automatiquement d'accéder aux sites de secours :

Linux ou Unix :

Principal : /proc/1/root/var/lib/instana/instana-agent-id (fonctionne dans des conteneurs et sur l'hôte)
Solution de secours : /var/lib/instana/instana-agent-id

macOS:

Principal : ~/Library/Application Support/com.instana.agent/instana-agent-id (spécifique à l'utilisateur)
Solution de secours : /Library/Application Support/com.instana.agent/instana-agent-id (à l'échelle du système)

Windows:

Principal :%LOCALAPPDATA%\Instana\agent\instana-agent-id
Solution de secours : %APPDATA%\Instana\agent\instana-agent-id ou %PROGRAMDATA%\Instana\agent\instana-agent-id

Vous pouvez remplacer ces emplacements en définissant la variable d'environnement INSTANA_AGENT_ID_FILE_PATH=/custom/path/to/instana-agent-id.

Utilisez cette option lorsque vous avez besoin d'un identifiant d'agent stable qui persiste après les redémarrages, ou lorsque vous travaillez dans des environnements conteneurisés où les adresses MAC sont éphémères.

Option 3 : Configurer un identifiant d'agent statique

Spécifiez manuellement un identifiant d'agent statique dans le fichier de <instanaAgentDir>/etc/instana/com.instana.agent.main.config.Agent.cfg configuration de l'agent en ajoutant la ligne suivante :

uniqueAgentId=SomeUniqueString

Remplacez SomeUniqueString par l'identifiant unique de votre choix. Par exemple :

uniqueAgentId=prod-server-01-custom-id

Utilisez cette option lorsque vous avez besoin d'un contrôle total sur l'identifiant de l'agent ou que vous souhaitez appliquer une convention de nommage spécifique.

Remarque :

Lorsque plusieurs options de configuration sont définies, l'agent les utilise dans l'ordre suivant :

Identifiant d'agent statique (uniqueAgentId)
Identifiant unique persistant (INSTANA_PERSIST_HOST_UNIQUE_ID)
Identifiant basé sur l'adresse MAC avec nom de domaine complet (INSTANA_APPEND_FQDN_TO_AGENT_ID)
Identifiant par défaut basé sur l'adresse MAC

Échec de la connexion CRI- API sur les anciennes installations d' Kubernetes et d' containerd

Modifier en ligne

Dans les environnements d' Kubernetes s exécutant des versions plus anciennes ou personnalisées d' RKE2 et de Containerd, l'agent de surveillance peut ne pas parvenir à établir la communication avec le moteur d'exécution des conteneurs via l'interface CRI (Container Runtime Interface) gRPC API.

Exemples de versions :

Version du moteur d'exécution des conteneurs : containerd://1.4.12-k3s1
Version de Kubelet : v1.21.8+rke2r1

Ce problème se traduit par des erreurs du type :

io.grpc.StatusRuntimeException: UNIMPLEMENTED: unknown service runtime.v1.RuntimeService
at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:268) ~[?:?]

Ce problème survient car les anciennes versions d' Kubernetes et de Containerd peuvent ne pas prendre entièrement en charge l'interface CRI gRPC API requise par l'agent, ce qui entraîne des échecs de connexion lors de l'interaction avec le moteur d'exécution du conteneur.

À titre de solution de contournement, définissez la variable d'environnement INSTANA_USE_CONTAINERD_CRI_CLIENT=false sur l'agent afin de désactiver l'interaction avec le runtime du conteneur via le client CRI. L'agent utilise ctr ensuite pour collecter les métriques.

Limitations connues

Modifier en ligne

Elasticsearch 8.18 + monitoring failure

Modifier en ligne

À partir de la version Elasticsearch 8.18.0, l'agent Instana ne peut plus se connecter aux machines virtuelles Java (JVM) de Elasticsearch. Cette erreur survient car Elasticsearch 8.18.0 est passé définitivement de Java SecurityManager au cadre de sécurité « Entitlements ». Pour plus d'informations, consultez les notes de mise à jour d' Elasticsearch 8.18.0.

Le cadre de sécurité intercepte et limite les opérations JDK sensibles effectuées par du code chargé dynamiquement. Lorsque l'agent Instana tente d'utiliser l' API standard « Attach » de l' JVM, il injecte un composant de chargement dans l' JVM cible. Le chargeur doit effectuer plusieurs opérations pour mettre en place la surveillance, notamment créer une instance d' ClassLoaders,, utiliser l'interface Instrumentation API pour modifier le bytecode, ouvrir une connexion TCP sortante vers l'agent et lancer des threads en arrière-plan pour la collecte de données.

Le système de sécurité de Elasticsearch bloque ces opérations sans avertissement. Par conséquent, le chargeur ne peut pas mener à bien sa séquence d'initialisation ni établir la connexion de rappel requise. L'agent attend 90 secondes pour obtenir une réponse. S'il ne reçoit pas de réponse, l'agent marque l' JVM e comme exclue et met fin à toutes les tentatives de surveillance. En raison de ce comportement, l'agent d' Instana s ne peut pas surveiller les processus Elasticsearch, 8.18 + et Java.

Remarque : les versions d' Elasticsearch ( 8.18 et ultérieures) sont prises en charge à partir de la version 1.2.61 de l'agent Instana, publiée sous le tag de modification 2026.04.16.1110. Cette mise à jour introduit la compatibilité avec le système de droits d'accès d' Elasticsearch grâce à la transformation du bytecode. Cela permet à l'agent d' Instana s de fonctionner correctement sans déclencher de violations de sécurité ou de droits dans l' Elasticsearch.

Prise en charge des groupes de processeurs sur Windows

Modifier en ligne

Sur les serveurs d' Windows, versions 2008 à 2019, équipés de plus de 64 cœurs, l'agent d' Instana ne peut surveiller que les cœurs appartenant au groupe de processeurs qui lui est attribué. Cette limitation est due au fait que la version actuelle de l'agent ne prend pas en charge les groupes de processus, ce qui signifie qu'il ne peut pas reconnaître les cœurs qui ne font pas partie du groupe de processeurs.

Analyse des traces et des appels

Modifier en ligne

Lorsque les appels sont regroupés par log.level ou log.message, le groupe de balises spécial Tag not present n'est pas affiché de la même manière que les autres balises.

Pour plus d'informations sur cette fonctionnalité, consultez la section « Analyse des traces et des appels ».

Filtrage avec mise au point dynamique

Modifier en ligne

Pour plus d'informations sur cette fonctionnalité, consultez la section « Filtrage avec Dynamic Focus ».

Contraintes de syntaxe

Modifier en ligne

Les espaces ne sont pas autorisés entre le ! et la requête à annuler. Utilisez !<query> ou NOT <query> à la place.
Lorsque plusieurs des mêmes mots clés entity.application.name, entity.service.name, entity.endpoint.name de Dynamic Focus sont utilisés ensemble, ils ne peuvent être joints que par l'opérateur OR. E.g. ces requêtes ne sont pas entity.application.name:foo entity.application.name:bar prises entity.application.name:foo AND entity.application.name:bar en charge. La requête entity.application.name:foo OR entity.application.name:bar est prise en charge.
Lorsque plusieurs des mots clés entity.application.name, entity.service.name, entity.endpoint.name de Dynamic Focus sont utilisés ensemble, ils ne peuvent être joints que par l'opérateur AND. E.g. la requête entity.application.name:foo OR entity.service.name:bar n'est pas prise en charge, alors que la requête entity.application.name:foo AND entity.service.name:bar est prise en charge.
Les requêtes contenant une négation de l'application, du service ou du nom de noeud final ne sont pas prises en charge. Par conséquent, ni NOT entity.application.name:foo, !entity.service.name:bar ni NOT entity.endpoint.name:foobar sont valides. Toutefois, le filtrage des événements d'une application, d'un service ou d'un noeud final est toujours possible en utilisant NOT event.entity.label:foo à la place.
Les requêtes Dynamic Focus entity.application.name:<term>, entity.service.name:<term> et entity.endpoint.name:<term> sont évaluées à l'aide de la chaîne logique contains , par exemple, la requête Dynamic Focus entity.application.name:shop correspond également à entity.application.name:shop-frontend.
Les mots clés de requête Dynamic Focus entity.application.name, entity.service.name et entity.endpoint.name ne sont pris en charge que dans les requêtes booléennes (voir les contraintes de logique booléenne ci-dessus), les requêtes de terme, les requêtes de phrase et les requêtes de préfixe.

Limitations des requêtes

Modifier en ligne

Les requêtes Dynamic Focus sur event.text contenant des tirets peuvent produire des résultats inattendus. Par exemple, event.text:"foo-bar-random" renvoie également des événements contenant uniquement foo , bar ou random en raison de la segmentation de l'analyseur Lucene.
Les entités comme suit d'un conteneur Docker , tel que Host ou Availability Zone, ne peuvent pas être sélectionnées lors de la définition de la portée sur la plupart des mots clés Kubernetes . Par exemple, la requête entity.kubernetes.deployment.name:my-K8s-deployment AND entity.selfType:host ne renvoie aucun hôte. En revanche, la requête entity.kubernetes.deployment.name:my-K8s-deployment AND entity.selfType:docker renvoie tous les conteneurs Docker liés au déploiement. Cependant, il existe quelques mots clés kubernetes qui peuvent être utilisés pour sélectionner les entités Hôte, à savoir entity.kubernetes.cluster.* et entity.kubernetes.node.*. Par exemple, la requête entity.kubernetes.cluster.label:my-K8s-cluster AND entity.selfType:host renvoie tous les hôtes associés du cluster.

Métriques de l'infrastructure

Modifier en ligne

Pour des raisons de performances, les entités ne peuvent afficher que 3 000 indicateurs au maximum dans l'interface utilisateur d' Instana. Les tableaux de bord avec plus de métriques que cette limite auront des métriques manquantes.
Les valeurs de métrique négatives ne sont pas affichées.

IBM App Connect Enterprise s de surveillance (ACE)

Modifier en ligne

Si l'authentification par certificat ( HTTPS ) est activée pour l'interface REST API, vous devez spécifier les paramètres keystore et keystorePassword dans le fichier <agent_install_dir>/etc/instana/configuration.yaml. Pour le type de fichier de clés, seul JKS ou P12 est pris en charge.
La méthode de traçage des exits utilisateur ACE ne prend en charge que les configurations à nœud unique. Les configurations à haute disponibilité (HA) et les environnements en cluster ne sont pas pris en charge. Pour les déploiements HA ou les environnements en cluster, utilisez la prise en charge native du traçage d' OpenTelemetry s plutôt que la méthode des exits utilisateur.

Pour plus d'informations sur cette fonctionnalité, consultez la section « Surveillance de l' IBM App Connect Enterprise (ACE) ».

Surveillance de l'application d' IBM API Connect

Modifier en ligne

DataPower La fonctionnalité de traçage prend uniquement en charge la passerelle « API » et ne prend pas en charge d'autres services tels que la passerelle multiprotocole et le proxy de services Web.

Pour plus d'informations sur cette fonctionnalité, consultez la section « Surveillance de l'application IBM API Connect ».

Jaeger traçage

Modifier en ligne

Les données de traçage collectées à partir de Jaeger ne seront pas corrélées avec les données de traçage collectées via AutoTrace, ce qui entraîne des traces distinctes, même si les systèmes suivis respectivement par Jaeger et Instana AutoTrace, interagissent directement entre eux.
Étant donné que les données de traçage de l' Jaeger e ne permettent pas de déterminer quel processus les envoie à l'agent hôte, l' Instana e met en corrélation ces traces avec l'hôte sur lequel repose l'agent hôte. Cela empêche l'association avec le processus, et donc également avec la hiérarchie des conteneurs et de la plateforme (par exemple, un pod, un espace de noms et un cluster d' Kubernetes ).
Jaeger ne prend pas en compte la surveillance des utilisateurs (même si cela pourrait changer à terme avec l'adoption de W3C TraceContext.md); par conséquent, les balises collectées via Instana Website Monitoring ne seront pas mises en corrélation avec les traces backend collectées sur Jaeger.
L'agent hôte prend en charge la collecte des traces Jaeger uniquement sur HTTP. UDP, protocole utilisé si vous configurez les variables d'environnement JAEGER_AGENT_HOST et JAEGER_AGENT_PORT, n'est pas pris en charge.

Pour plus d'informations sur cette fonctionnalité, consultez Jaeger

OpenTelemetry traçage

Modifier en ligne

OpenTelemetrylinks ne sont pas pris en charge.
La combinaison du propagateur de contexte par défaut d' Instana avec d'autres propagateurs W3C Trace Context de contexte n'est pas prise en charge. W3C Trace Context est le propagateur de contexte par défaut d' OpenTelemetry.

Pour plus d'informations sur cette fonctionnalité, consultez la page « OpenTelemetry Tracing »

IBM MQ Traçage

Modifier en ligne

Un problème connu sur la plateforme Windows empêche d'utiliser simultanément les niveaux de surveillance de la file d'attente de destination (IBMMQ_DEST_MONITOR_LEVEL_*) et le niveau de surveillance global (MONITOR_LEVEL).

Sur la plateforme AIX, le protocole OTLP gRPC (activé lorsque vous configurez OTLP_EXPORTER_GRPC_ENDPOINT ) n'est pas disponible, donc HTTP est utilisé par défaut.

Zipkin traçage

Modifier en ligne

Les données de traçage collectées à partir de Zipkin ne seront pas corrélées avec celles collectées via AutoTrace, ce qui entraîne des traces distinctes, même si les systèmes suivis respectivement par Zipkin et Instana AutoTrace interagissent directement entre eux.
Zipkin ne prend pas en compte la surveillance des utilisateurs (même si cela pourrait changer à terme avec l'adoption de W3C TraceContext.md); par conséquent, les balises collectées via Instana Website Monitoring ne seront pas mises en corrélation avec les traces backend collectées sur Zipkin.
L'agent hôte prend en charge la collecte des traces Zipkin uniquement sur HTTP, ce qui correspond au paramètre COLLECTOR_HTTP_ENABLED de Zipkin.

Pour plus d'informations sur cette fonctionnalité, consultez Zipkin

Surveillance de Containerd

Modifier en ligne

Les métriques CPU Total Normalized et Memory Working Set Usage % sont disponibles uniquement sur les systèmes qui utilisent le groupe de contrôle v1 (cgroupv1).

Surveillance d'Amazon MSK

Modifier en ligne

Le détecteur Amazon MSK prend en charge la surveillance uniquement pour le type de cluster MSK mis à disposition. Le type de cluster sans serveur n'est pas pris en charge.

Assistance ALPN

Modifier en ligne

L'agent et le backend d' Instana prennent en charge la connexion via la négociation de protocole au niveau de la couche application (ALPN) lorsque les conditions suivantes sont remplies :

Netty 4.1.49.Final ou version ultérieure
Java Kit de développement (JDK) 1.8.0_251 ou version ultérieure

Remédier à une utilisation élevée du processeur

Modifier en ligne

Une utilisation élevée de l'unité centrale est observée dans les agents basés sur des points d'accès avec le conteneur d'agent 1.263.3 et les versions antérieures. Pour résoudre ce problème, réinstallez l'agent. La taille du cache de code réservé est désormais augmentée pour prendre en charge une utilisation élevée de l'unité centrale. Pour les agents qui s'exécutent dans un environnement hôte, supprimez l'agent, puis réinstallez-le.

Si vous utilisez Kubernetes (k8s) ou OpenShift Container Platform (OCP), procédez comme suit:

Désinstallez l'agent:

kubectl delete agents.instana.io instana-agent -n instana-agent --wait; helm uninstall instana-agent -n instana-agent; kubectl delete crd agents.instana.io; kubectl delete namespace instana-agent

Installez l'agent:

Pour installer l'agent Instana, utilisez le graphique « Helm » disponible sur Kubernetes ou OpenShift Container Platform.

Caractéristiques des tests synthétiques

Modifier en ligne

L'utilisation de Jest comme moteur de test ( scriptType ) n'est pas prise en charge pour les tests Browser Simple, API Script et API Simple sur l'interface utilisateur et API. L' scriptType e « Jest » ne peut être utilisé qu'avec les tests de scripts de navigateur.

Certains attributs de test synthétiques ne sont pas pris en charge dans l'interface utilisateur d' Instana. Pour définir ces attributs, utilisez l' API -Open ou synctl l'outil. Les attributs non pris en charge dans l'interface utilisateur d' Instana s sont répertoriés dans le tableau suivant :


Attribut de test	Script de navigateur	Simple navigateur	API simple	Script d'API
navigateur	☒	☒	Non disponible	Non disponible
expectExists	Non disponible	Non disponible	☒	Non disponible
expectNotEmpty	Non disponible	Non disponible	☒	Non disponible
ScriptType	☒	Non disponible	Non disponible	☒
HEAD (opération)	Non disponible	Non disponible	☒	Non disponible
DELETE (opération)	Non disponible	Non disponible	☒	Non disponible
OPTIONS (opération)	Non disponible	Non disponible	☒	Non disponible
PATCH (opération)	Non disponible	Non disponible	☒	Non disponible
POST (Opération)	Non disponible	Non disponible	☒	Non disponible
PUT (Opération)	Non disponible	Non disponible	☒	Non disponible

Le symbole ☒ indique que cet attribut n'est pas pris en charge dans l'interface utilisateur d' Instana.

N/A indique que l'attribut n'est pas applicable pour le type de test.

Processus métier

Modifier en ligne

Une limitation connue dans certaines versions d' Business Automation Workflow (BAW) fonctionnant sur IBM J9 JVM peut avoir une incidence sur les capacités des processus métier. Ce problème peut entraîner la disparition ou l'inaccessibilité de certains ou de tous les processus au sein du système.

Perspectives métier

Modifier en ligne

L'onglet « Perspectives commerciales » est désactivé si Instana ne détecte aucun agent connecté. Pour consulter vos perspectives commerciales, assurez-vous qu'au moins un agent est connecté.

Rendu sur toile

Modifier en ligne

Il se peut que certaines toiles ne s'affichent pas correctement dans l'interface utilisateur d' Instana lors de l'utilisation de Safari. Cela inclut :

Le schéma des processus métier
Le graphique de l'infrastructure
Topologie des causes probables de l'événement
Le graphique de l'éditeur de configuration de l' OTel

Utilisez d'autres navigateurs, tels que Chrome ou Firefox, pour un meilleur affichage.