Introduction au monitoring IBM MQ OpenTelemetry

Les architectures d'entreprise modernes s'appuient fortement sur des applications orientées messages pour gérer des tâches critiques telles que le traitement des paiements, le routage des commandes et les services de synchronisation. Cependant, à mesure que ces dorsales de messages évoluent, le suivi de la dégradation des performances devient complexe. Imaginez une application qui ralentit soudainement — sans une visibilité approfondie, déterminer si le retard est causé par un consommateur d'application ou un arriéré de file d'attente IBM MQ peut être incroyablement difficile.

New Relic vous aide à combler ces lacunes d’observabilité en fournissant un chemin de monitoring OpenTelemetry pur pour vos gestionnaires de files d’attente IBM MQ. En tirant parti de l’exportateur Prometheus officiel de l’équipe IBM MQ mq-metric-samples, l’OpenTelemetry Collector rassemble et met en forme la télémétrie brute directement dans la base de données de New Relic. Chaque gestionnaire de files d’attente apparaît automatiquement comme une entité IBMMQ_MANAGER distincte avec ses files d’attente mappées en tant qu’entités IBMMQ_QUEUE enfants — vous donnant un accès instantané à des dashboards préconfigurés, des alertes et aux signaux dorés de votre système sans aucun agent propriétaire requis.

Fonctionnalité clé

L'intégration New Relic IBM MQ OpenTelemetry vous offre une visibilité approfondie et sans fournisseur associé sur votre infrastructure de messagerie sans la surcharge des agents propriétaires. En implémentant cette intégration, vous débloquez quatre capacités principales de monitoring conçues pour assurer le bon fonctionnement de vos systèmes asynchrones :

• Prévention automatisée des arriérés et alertes : éliminez les angles morts dans vos chemins de distribution de messages. Vous pouvez configurer des alertes actives sur l'augmentation des profondeurs de file d'attente, les pics de messages non validés et les canaux bloqués pour détecter les goulots d’étranglement avant qu'ils ne causent des retards dans les applications en aval dépendant de votre infrastructure de messagerie.

• Optimisation granulaire du débit et des performances : isolez exactement l'endroit où le traitement des messages ralentit. En suivant les taux MQPUT et MQGET en temps réel ainsi que le nombre de connexions et les temps d'attente dans les files d'attente, vous pouvez rapidement déterminer si la friction de traitement se situe au sein du broker IBM MQ lui-même ou au niveau de consommateurs d'applications lents.

• Capacité proactive et dimensionnement des ressources : éliminez les approximations de la mise à l’échelle de l’infrastructure. L’intégration fait remonter les métriques critiques du broker au niveau de l’hôte — y compris les seuils de taille de fichier de logs actifs, l’utilisation du système de fichiers et les tendances des handles ouverts — vous permettant de faire évoluer vos gestionnaires de files d’attente de manière proactive avant que l’épuisement des ressources ne déclenche un plantage du broker.

• Livraison fiable et suivi des files d'attente de lettres mortes (DLQ) : protégez l'intégrité de vos données transactionnelles. Monitorez instantanément les changements d'état des canaux, suivez les accumulations dans les files d'attente de lettres mortes et détectez tôt les appels MQI échoués pour identifier les mauvaises configurations de routage et les abandons avant que les données ne soient définitivement perdues.

Comment ça marche

Comprendre comment les données télémétriques sont collectées, traitées et modélisées vous aide à optimiser votre pipeline de monitoring. Les sections suivantes détaillent exactement comment l'intégration gère vos données du courtier à l'interface utilisateur.

Flux de données télémétriques

Les données télémétriques circulent séquentiellement à travers quatre couches distinctes avant d'être visualisées dans New Relic :

1. La couche Broker : chaque gestionnaire de files d'attente IBM MQ suit nativement les statistiques de performances opérationnelles à l'aide du format de commande programmable (PCF).
2. La couche Exporter : l’exportateur mq-metric-samples requis extrait ces statistiques PCF et les expose sur un point de terminaison HTTP /metrics Prometheus standard. Chaque guide de configuration suppose que ce composant s’exécute déjà dans votre cluster.
3. La couche Collector : Vous configurez le Collector OpenTelemetry pour scraper le point de terminaison de l’exportateur. Le collecteur filtre le bruit de fond, formate les tags d’identité et transfère les données OTLP propres à New Relic.
4. La couche Synthesis : New Relic reçoit la charge OTLP et mappe automatiquement les données en entités d’espace de travail IBM MQ lisibles et navigables.

La chaîne de traitement du pipeline

Pour garder vos données propres et optimiser les taux d'ingestion, chaque métrique recueillie par le collecteur passe par une séquence de traitement automatisée et sensible à l'ordre dans votre fichier config.yaml :

1. Ingestion Prometheus : récupère le point de terminaison /metrics Prometheus brut à partir de l'exportateur en cours d'exécution.
2. Filtre de surcharge : supprime les propres métriques de l’exportateur et les cycles de suivi en arrière-plan pour minimiser le bruit de volume.
3. Filtre de file d’attente : filtre les files d’attente internes du système qui ne nécessitent pas de suivi actif des performances.
4. Détection des ressources : estampille la charge avec les tags d'identité de l'infrastructure hôte et les métadonnées de l'environnement.
5. Transformation d’étiquette : normalise les étiquettes Prometheus brutes sous la forme OTel standard avec des points. Par exemple, le remappage de targetName vers target.name.
6. Limiteur de mémoire : impose des tampons de capsule de mémoire stricts sur le processus du collecteur pour protéger la stabilité de l’hôte.
7. Cumulative-to-Delta : convertit les compteurs de métriques Prometheus absolus et continus en valeurs delta claires.
8. Regroupement par lots : regroupe les événements de télémétrie individuels en charges OTLP par lots pour maximiser l'efficacité du réseau.
9. Exportation HTTP OTLP : envoie le bloc de données finalisé et compressé directement au système d'ingestion de données de New Relic.

Options de déploiement du collecteur

New Relic prend entièrement en charge deux distributions OpenTelemetry Collector pour votre intégration IBM MQ. Les deux options offrent des capacités fonctionnelles identiques et partagent les mêmes fichiers de configuration de base :

• NRDOT Collector (recommandé) : la distribution New Relic de l'OpenTelemetry Collector, directement soutenue par l'assistance du support technique de New Relic. Examinez le code base open source dans le référentiel GitHub NRDOT Collector.
• OpenTelemetry Collector : la distribution communautaire CNCF en amont. Consultez les détails du projet dans le référentiel GitHub OpenTelemetry Collector Contrib.

Le Modèle d’entité IBM MQ

New Relic évalue des marqueurs spécifiques dans votre flux de télémétrie pour synthétiser automatiquement les données brutes en entités :

• Noms de métrique bruts avec trait de soulignement tels que ibmmq_qmgr_status et ibmmq_queue_depth
• Étiquettes de données structurelles qmgr et queue
• L’attribut d’identité target.name selon la configuration de votre collecteur

À l'aide de ces règles, la plateforme organise vos données en une structure parent-enfant claire :

Démarrer

La configuration de votre pipeline de monitoring IBM MQ implique trois phases de mise en œuvre principales.

Documentation associée