Dépannage d' IBM MQ

Pour les gestionnaires de file d'attente en cours d'exécution, après avoir accordé des privilèges à l'utilisateur, assurez-vous que les paramètres de sécurité fonctionnent. Vous devez soit actualiser la sécurité en exécutant la commande IBM MQ runmqsc suivante, soit redémarrer le gestionnaire de files d'attente pour que l'autorisation que vous avez accordée prenne effet.

REFRESH SECURITY
 

En mode de liaison client, le capteur d' IBM MQ s agit comme une application cliente pour se connecter au gestionnaire de file d'attente. Par conséquent, le capteur nécessite les mêmes autorisations que toute autre application pour se connecter au gestionnaire de file d'attente et consulter les données, comme l'explorateur MQ ou l'application exemple amqsputcMQ. Lorsque le gestionnaire de file d'attente ne se connecte pas avec les paramètres que vous avez configurés, vous pouvez essayer vos paramètres de connexion avec l'explorateur MQ pour vous connecter au gestionnaire de file d'attente et vérifier si vous pouvez vous connecter au gestionnaire de file d'attente.

Consultez les numéros suivants à titre de référence :

1. RC 2538 - MQRC_HOST_NOT_AVAILABLE

   Instana message du journal de l'agent : Listener not started on{host}:{port} ({exceptionCode}) {message}.

   • Le lecteur n'est pas lancé.

     Solution : Démarrez le listener. Pour démarrer l'écoute, exécutez la commande runmqscIBM MQ suivante :

     START LISTENER($Listener_Name)
      

   • Qmgr@host introuvable. Vérifiez si le gestionnaire de file d'attente et les noms d'hôte sont corrects et peuvent être connectés.

     Solution : vérifiez si les paramètres de connexion pour le gestionnaire de file d'attente et les noms d'hôte sont corrects et permettent la connexion. Ou vérifiez si un pare-feu bloque la connexion.

   • L'hôte et le port sont configurés dans le fichier de configuration de l'agent dans le cluster Kubernetes.

     Dans le cluster Kubernetes, lorsque le gestionnaire de file d'attente est redémarré, l'adresse IP de l'hôte change. Par conséquent, le capteur d' IBM MQ s ne parvient pas à se connecter au gestionnaire de file d'attente.

     Solution : pour détecter automatiquement les informations relatives à l'hôte et au port, supprimez l'hôte et le port dans le fichier de configuration de l'agent pour l'agent hôte dans le cluster Kubernetes.

2. RC 2540 - Le canal n'est pas défini.

   Instana message du journal de l'agent : Channel {channel} is not defined ({exceptionCode}). {message}.

   Solution : vérifiez si le canal SVRCONN correct est configuré dans le fichier de configuration configuration.yaml de l'agent.

3. RC 2035 - Problème d'autorité.

   Instana message du journal de l'agent : Channel {channel} authorization failed for user {username} ({exceptionCode}). {message}.

   Le problème est dû à un problème d'autorité et peut avoir différentes causes selon les configurations d' MQ. Pour résoudre le problème d'autorité, vérifiez si la sécurité du canal est activée :

   • Si la sécurité du canal est désactivée, mais ne signale aucune autorité avec l'utilisateur, l'application MQ affirme que l'utilisateur n'a aucune autorité. Vérifiez quel utilisateur est utilisé et attribuez les autorisations appropriées à cet utilisateur ou passez à un autre utilisateur approprié pour vous connecter au gestionnaire de file d'attente.
   • Si la sécurité du canal est activée. Vérifiez si l'utilisateur et le mot de passe fournis disposent des autorisations nécessaires pour se connecter au gestionnaire de file d'attente. Si l'option « TLS » (Activer la gestion des files d'attente) est activée, vous devez fournir les paramètres corrects keystore, keystorePassword, et correspondants cipherSuite pour vous connecter au gestionnaire de files d'attente.

L'image suivante illustre le diagramme du processus de débogage :

Les problèmes suivants, fréquemment rencontrés, peuvent provoquer l'erreur 2035 :

1. La sécurité du canal est désactivée, mais aucune autorité avec « root » n'est signalée.

   En général, lorsque CHLAUTH le paramètre est désactivé et que CONNAUTH le paramètre n'est pas défini, la sécurité du canal MQ est désactivée. Vous devez déterminer quel utilisateur est utilisé pour l'autorisation. Voici l'ordre de priorité des dispositifs de sécurité.

   Si vous ne configurez pas Security exit, channel record USERSRC(MAP), CLNTUSER, MCAUSER, alors l'application utilise l'utilisateur affirmé, qui est l'utilisateur du système d'exploitation dans une connexion à distance. Dans ce scénario, « root » est utilisé comme utilisateur déclaré par l'application, car l'agent d' Instana s s'exécute en tant que root. Si root n'a pas les droits nécessaires, vous n'obtiendrez aucun droit avec « root » dans le journal des erreurs IBM MQ. Pour plus d'informations sur les priorités des autorisations utilisateur, consultez les documents IBM MQ.

   Solution : Vous pouvez configurer l'enregistrement du canal et définir CLNTUSER ou MCAUSER pour le canal. Définissez MCAUSER comme utilisateur disposant d'une autorisation d'accès de type « MQ » pour votre canal de connexion au serveur, puis utilisez cet utilisateur pour vous connecter au gestionnaire de file d'attente.

   Exemple: alter channel(SVRCONN) chltype(SVRCONN) MCAUSER(‘mqmtest‘)

2. Aucune autorisation n'est accordée pour se connecter au canal de connexion du serveur SYSTEM.

   Certains canaux de connexion au serveur système, tels que SYSTEM.AUTO.SVRCONN, sont bloqués par défaut. Voici les règles BLOCKUSERS d' MQ : Il existe trois règles par défaut pour le traitement CHLAUTH :

   • Aucun accès à tous les canaux pour les utilisateurs MQ -admin*
   • ACCÈS INTERDIT à tous les SYSTÈMES.* canaux par tous les utilisateurs
   • Autoriser l'accès au canal SYSTEM.ADMIN.SVRCONN (utilisateurs non MQ -admin)

   Les deux premières règles bloquent l'accès à tous les canaux. La troisième règle est plus spécifique et prévaut sur les deux autres, c'est-à-dire que CHLAUTH autorise uniquement l'accès au canal SYSTEM.ADMIN.SVRCONN. Pour plus d'informations, consultez la section Résolution des problèmes d'accès CHLAUTH.

   Solution : débloquez l'utilisateur pour le canal de connexion au serveur système avant que l'utilisateur ne soit utilisé, ou définissez votre propre canal de connexion au serveur pour la connexion, ce qui permet de contourner ce problème de blocage de l'utilisateur.

3. La sécurité est activée ou TLS est activé

   Lorsque la sécurité du canal est activée (CHLAUTH(ENABLED)) ou que l'authentification par clé ( TLS ) est activée, mais que le nom d'utilisateur et le mot de passe correspondants ou les paramètres du magasin de clés (keystore, keystorePassword, et cipherSuite ) ne sont pas fournis, fournissez les informations d'identification. Après avoir modifié les configurations liées à la sécurité d' MQ, vous devez exécuter refresh security type(CONNAUTH) à partir de runmqsc l'invite pour que cela fonctionne.

   Solution : Indiquez le nom d'utilisateur et le mot de passe correspondants ou les paramètres du keystore dans le fichier de configuration de l'agent.

4. La sécurité est activée pour CHLAUTH et CONNAUTH, mais l'utilisateur rencontre toujours des problèmes d'autorisation pour se connecter au gestionnaire de file d'attente.

   Solution : Configurations CHLAUTH et CONNAUTH dans le gestionnaire de file d'attente, puis vérification du flux d'interactions CHLAUTH et CONNAUTH pour confirmer la priorité afin de déterminer quel enregistrement de sécurité fonctionne, et correction du problème. Pour plus d'informations, voir Interaction entre CHLAUTH et CONNAUTH.

5. MQ La connexion fonctionne correctement, mais la sécurité des objets n'est pas suffisante pour permettre à l'utilisateur d'obtenir d'autres données de surveillance.

   Solution : consultez le journal des erreurs MQ pour identifier l'objet et l'utilisateur concernés par le problème d'autorisation, puis attribuez l'autorisation appropriée à l'objet afin de résoudre le problème. Pour plus d'informations, consultez la section « Configuration des autorisations d' IBM MQ ».

Vous rencontrez l'erreur suivante lorsque l' IBM MQ e ne dispose pas des autorisations suffisantes pour obtenir les données statistiques de réinitialisation de la file d'attente. Pour obtenir les données statistiques relatives à la réinitialisation des files d'attente, vous devez disposer d'une autorisation de modification pour y accéder SYSTEM.AUTH.DATA.QUEUE. Mais SYSTEM.AUTH.DATA.QUEUE il s'agit d'une file d'attente spéciale pour laquelle vous ne pouvez pas accorder l'autorisation de modifier les droits.

AMQ8077W: Entity 'user' has insufficient authority to access object
'SYSTEM.AUTH.DATA.QUEUE'.

EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: chg
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.
 

Solution : si vous souhaitez empêcher l'apparition de ces messages d'erreur dans le journal IBM MQ pour SYSTEM.AUTH.DATA.QUEUE, attribuez des privilèges à l'utilisateur de l'agent Instana.

Pour résoudre le problème, procédez comme suit :

1. Assurez-vous que tracelibrary.so (sur Linux / AIX ) ou tracelibrary.dll (sur Windows ) puisse résoudre toutes les dépendances pour tous les utilisateurs qui lancent les services IBM MQ, y compris mqm l'utilisateur sur Linux ou AIX et celui MQ_USER sur Windows. Pour vérifier, utilisez les commandes suivantes :

   • Linux: ldd
   • AIX : dump -H ou ldd
   • Windows:dumpbin /dependents
2. Vérifiez que tous les fichiers requis se trouvent aux emplacements prévus :
   • Linux: .so
   • AIX : .a ou .so
   • Windows: .dll
3. Vérifiez que la version requise d' OpenSSL est installée sur le système et que tracelibrary.so ou tracelibrary.dll peut la résoudre lors de l'exécution.

Pour propager les informations de corrélation de trace, l'exit utilisateur de trace IBM MQ ajoute des en-têtes d' MQRFH2 s supplémentaires (X_INSTANA_T, X_INSTANA_S X_INSTANA_L, traceparent, et tracestate) aux messages qui sont tracés lorsque les messages contiennent déjà des en-têtes d' MQRFH2 s ou lorsque le niveau de surveillance de la destination du message est défini sur debug. Cependant, la présence de données d'en-tête supplémentaires dans les messages peut entraîner des erreurs de traitement et le rejet des messages dans certaines applications consommatrices d' IBM MQ s. Si les en-têtes supplémentaires MQRFH2 provoquent des erreurs dans une application cliente IBM MQ, effectuez l'une des actions suivantes :

• Modifiez l'application cliente IBM MQ afin qu'elle ignore les en-têtes MQRFH2 supplémentaires contenant les informations de corrélation de trace ajoutées par Instana.
• Désactivez la propagation de la corrélation des traces en ajoutant les files d'attente de la chaîne de messagerie au paramètre de configuration de sortie utilisateur de IBMMQ_DEST_MONITOR_LEVEL_QUIET suivi de l' IBM MQ.
• Modifiez la valeur de PROPCTL la propriété pour NONE la file d'attente connectée par l'application cliente IBM MQ.

Par défaut, les informations de corrélation de trace sont automatiquement ajoutées aux messages d' IBM MQ qui contiennent des en-têtes d' MQRFH2 s ou des propriétés de message. Pour éviter de perturber le fonctionnement de vos applications client IBM MQ, IBM MQ Le traçage des exits utilisateur n'ajoute pas d'informations de corrélation de trace aux messages en texte brut. Si vous souhaitez tout de même ajouter les informations de corrélation de trace aux messages, vous pouvez ajouter les destinations des messages au paramètre de configuration de sortie IBMMQ_DEST_MONITOR_LEVEL_DEBUGutilisateur de trace IBM MQ. Cependant, vous devez vous assurer que votre application cliente IBM MQ peut analyser les messages contenant des en-têtes d' MQRFH2 s supplémentaires.

Vous pouvez associer un appel généré par la sortie utilisateur de traçage IBM MQ à une entité d'infrastructure surveillée du gestionnaire de file d'attente IBM MQ, qui est collectée par le capteur Instana IBM MQ dans l'interface utilisateur Instana. Le lien d'infrastructure peut ne pas être disponible dans les scénarios de haute disponibilité d' IBM MQ, car l'ID d'entité d'un gestionnaire de file d'attente collecté par le capteur Instana IBM MQ contient l'hôte des nœuds actifs et de secours d' IBM MQ. Cela contraste avec l'ID d'entité généré par la sortie utilisateur Tracing de l' IBM MQ, qui inclut uniquement l'hôte du nœud actif de l' IBM MQ. Cette incompatibilité perturbe le lien entre les détails de l'appel et l'entité de file d'attente. Pour résoudre ce problème, vous pouvez prendre les mesures suivantes :

1. Go au tableau de bord du gestionnaire de files d'attente haute disponibilité dans la vue Infrastructure de l'interface utilisateur d' Instana.
2. Recherchez l'attribut Nom dans la barre latérale du tableau de bord du gestionnaire de file d'attente pour extraire les informations relatives à l'hôte du gestionnaire de file d'attente. L'hôte du gestionnaire de file d'attente haute disponibilité est la partie de la Name chaîne qui suit le @ symbole. Par exemple, si le nom du gestionnaire de file d'attente apparaît sous la forme haqm1@ibmmqnode1.ibm.com-ibmmqnode2.ibm.com-ibmmqnode3.ibm.com, alors l'hôte du gestionnaire de file d'attente est ibmmqnode1.ibm.com-ibmmqnode2.ibm.com-ibmmqnode3.ibm.com.
3. Accédez au serveur IBM MQ et ouvrez le fichier mqtracingexit.conf de configuration pour IBM MQ Tracing user exit.
4. Définissez le champ HOST_ALIAS sur le nom d'hôte du gestionnaire de file d'attente obtenu à l'étape 2.
5. Sauvegardez le fichier de configuration.
6. Redémarrez le gestionnaire de file d'attente haute disponibilité pour appliquer les modifications.