Cette traduction automatique est fournie pour votre commodité.
En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.
Lors du monitoring d’IBM MQ avec les collecteurs OpenTelemetry, vous pourriez rencontrer des problèmes de démarrage du collecteur, de flux de données ou de synthèse d’entité. Ce guide vous aide à diagnostiquer et à résoudre les problèmes courants pour les déploiements d’hôte Linux et Kubernetes.
Collector ne démarre pas ou ne reste pas en cours d’exécution
Validez le statut de votre collecteur, et vérifiez les logs pour identifier le problème :
bash
$
sudo systemctl status nrdot-collector.service --no-pager
Vous devriez voir une ligne par gestionnaire de files d’attente. Si vous ne voyez aucune sortie, l’exportateur ne fonctionne pas correctement.
Vérifiez que votre collecteur est sain et découvre les cibles.
bash
$
curl http://127.0.0.1:13133
$
# Expected: {"status":"Server available", ...}
otelcol_receiver_accepted_metric_points supérieur à 0 confirme que le collecteur a trouvé des cibles. otelcol_exporter_send_failed_metric_points doit rester à 0.
Vérifier les problèmes de découverte de cibles
Vérifiez que vos variables IBMMQ_QMN_ENDPOINT pointent vers des exportateurs fonctionnels
Assurez-vous que le collecteur peut atteindre chaque point de terminaison d’exportateur
Vérifiez que votre configuration de cible statique est correcte
Vérifiez si des métriques sont collectées mais n’apparaissent pas dans New Relic :
Région du point de terminaison OTLP: confirmez que votre point de terminaison correspond à la région de votre compte New Relic (US ou EU)
Clé de licence: vérifiez que votre clé de licence est valide et dispose des autorisations appropriées
Connectivité réseau: assurez-vous que le collecteur peut atteindre le point de terminaison OTLP de New Relic
Une région incorrecte supprime silencieusement les données sans erreur côté collecteur.
Vérifiez que vos exportateurs IBM MQ fonctionnent :
otelcol_receiver_accepted_metric_points supérieur à 0 confirme que le collecteur a trouvé des cibles. otelcol_exporter_send_failed_metric_points doit rester à 0.
Vérifiez si otelcol_receiver_accepted_metric_points reste à 0 :
Vos pods de gestionnaire de files d’attente doivent porter les annotations requises sur le modèle de pod, avec prometheus.io/scrape défini exactement sur "true"
Les pods doivent s’exécuter dans l’espace de nommage ibmmq
Assurez-vous que clusterRole.create: true est appliqué ; sans cela, kubernetes_sd renvoie 403 Forbidden
Vérifiez si des métriques sont collectées mais n’apparaissent pas dans New Relic :
Région du point de terminaison OTLP: confirmez que votre point de terminaison correspond à la région de votre compte New Relic (US ou EU)
Clé de licence: vérifiez que votre clé de licence est valide et dispose des autorisations appropriées
Connectivité réseau: assurez-vous que le collecteur peut atteindre le point de terminaison OTLP de New Relic
Une région incorrecte supprime silencieusement les données sans erreur côté collecteur.
Aucune entité IBM MQ n’apparaît dans New Relic
Si vous voyez des métriques IBM MQ dans New Relic, mais qu’aucune entité IBMMQ_MANAGER, ou IBMMQ_QUEUE n’apparaît :
Vérifiez l’ordre des Processeurs : le Processeur transform/ibmmq-cleanupdoit s’exécuter aprèsresourcedetection. Si cet ordre est inversé, les métriques atterrissent sur la propre entité du collecteur au lieu des entités IBM MQ, et les dashboards deviennent vides.
Vérifiez les étiquettes requises : vos métriques doivent inclure ces étiquettes :
Labelqmgr: l’exportateur mq-metric-samples doit émettre ceci avec le nom du gestionnaire de files d’attente (par ex., qmgr="QM1")
Labelqueue: pour les métriques au niveau de la file d’attente, doit contenir le nom de la file d’attente
Attributtarget.name: provient de votre variable d’environnement TARGET_NAME et forme le GUID de l’entité
Vérifiez la cohérence de TARGET_NAME : ne modifiez jamais la valeur TARGET_NAME après le déploiement initial. Cette valeur fait partie du GUID de chaque entité (target.name:qmgr), et sa modification crée de nouvelles entités et rend orphelines celles existantes, cassant les dashboards et les alertes.
Visibilité des données
Cela est presque toujours causé par la modification de la forme de la métrique critique de l’entité. La synthèse de l’entité se base sur les métriques brutes avec trait de soulignement (ibmmq_*), l’étiquette brute qmgr et un attribut target.name. Vérifiez que :
Les noms des métriques ne comportent pas de points. Vous devriez voir ibmmq_queue_depth, et non ibmmq.queue.depth.
L’étiquette qmgr est présente et n’est pas renommée. Vérifié qu’elle ne s’affiche pas comme ibmmq.queue_manager.name.
Le target.name est défini sur les métriques et assurez-vous qu’il n’est pas affiché en camelCase targetName. Si targetName est toujours présent et que transform/ibmmq-cleanup n’est pas en cours d’exécution ou est mal ordonné :
FROM Metric SELECT uniques(target.name), uniques(qmgr)WHERE metricName LIKE'ibmmq_%' SINCE 30 minutes ago
L'ordre du Processeur dans la configuration du collecteur est déterminant — resourcedetection → transform/ibmmq-cleanup. Si vous avez réorganisé ou supprimé transform/ibmmq-cleanup, les métriques IBM MQ sont acheminées vers la propre entité du collecteur au lieu d'une entité IBMMQ_MANAGER. Restaurez l'ordre documenté du pipeline.
New Relic attend une temporalité delta pour les compteurs ; Prometheus émet des valeurs cumulées. Le processeur cumulativetodelta/ibmmq les convertit sur place. Si les compteurs semblent plats, confirmez que le processeur est présent dans chaque pipeline de métriques.
La valeur target.name (définie via la variable d’environnement TARGET_NAME sur Linux, ou le relabel targetName sur Kubernetes) est le premier segment de chaque GUID IBMMQ_MANAGER et IBMMQ_QUEUE. La modifier après le déploiement crée de toutes nouvelles entités et les anciennes deviennent obsolètes, cassant les dashboards et les alertes qui pointent vers les anciens GUID. Choisissez une valeur stable une fois pour toutes et ne la modifiez jamais.
Si vous l'avez déjà modifié, restaurez la valeur TARGET_NAME d'origine et redémarrez le collecteur. Les entités correctement nommées reprennent le reporting ; les doublons créés sous le mauvais nom cessent de recevoir des données et disparaissent de l’interface utilisateur après la fenêtre de reporting d’entité de New Relic.