• /
  • EnglishEspañolFrançais日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

IBM MQ OpenTelemetry監視の概要

現代のエンタープライズアーキテクチャーは、支払いの処理、注文のルーティング、サービスの同期マッチングなどの重要なタスクを処理するために、メッセージ駆動型アプリケーションに大きく依存しています。しかし、これらのメッセージバックボーンが拡張するにつれて、パフォーマンス低下を追跡することは複雑になります。アプリケーションが突然遅くなることを想像してみてください。深い可視性がなければ、遅延の原因がアプリケーション消費者にあるのか、IBM MQキューのバックログにあるのかを特定することは非常に困難です。

New Relicは、IBM MQキューマネージャーに純粋なOpenTelemetry監視パスを提供することで、これらのオブザーバビリティのギャップを埋めるのに役立ちます。IBM MQチームの公式mq-metric-samples Prometheusエクスポーターを活用することで、OpenTelemetry Collectorは生のテレメトリーを収集し、New Relicのデータベースに直接整形します。各キューマネージャーは個別のIBMMQ_MANAGERエンティティとして自動的に表示され、そのキューは子IBMMQ_QUEUEエンティティとしてマッピングされます — プロプライエタリなエージェントを一切必要とせずに、事前構築済みのダッシュボード、アラート、およびシステムのゴールデンシグナルに即座にアクセスできます。

New Relic dashboard showing IBM MQ queue manager health, connections, message rates, and queue depth

New Relic IBM MQダッシュボードで、キューマネージャーのヘルス、接続、メッセージスループット、およびキューの深さを可視化します。

主な特徴

New RelicのIBM MQ OpenTelemetryインテグレーションにより、独自のエージェントのオーバーヘッドなしに、メッセージングインフラストラクチャに対する詳細でベンダーニュートラルな可視性が得られます。このインテグレーションを実装することで、非同期システムをスムーズに稼働させるために設計された4つのコア監視機能を利用できるようになります:

  • 自動化されたバックログの防止とアラート: メッセージ配信パスの死角を排除します。メッセージングバックボーンに依存するダウンストリームアプリケーションで遅延が発生する前にボトルネックを捕捉するために、キューの深さの増加、コミットされていないメッセージのスパイク、および停止したチャネルに対するアクティブなアラートを構成できます。

  • 詳細なスループットとパフォーマンスの最適化: メッセージ処理が遅延している箇所を正確に特定します。リアルタイムのMQPUTおよびMQGETレートを接続数やキュー待機時間とともに追跡することで、処理の遅延の原因がIBM MQブローカー自体にあるのか、それとも遅いアプリケーション消費者にあるのかを迅速に判断できます。

  • プロアクティブなキャパシティとリソースのサイジング: インフラストラクチャのスケーリングから推測を排除します。インテグレーションは、重要なホストレベルのブローカーメトリクス — アクティブなログファイルのサイズ閾値、ファイルシステムの使用量、オープンハンドルの傾向など — を提示し、リソースの枯渇によってブローカーがクラッシュする前に、キューマネージャーをプロアクティブにスケーリングできるようにします。

  • 信頼性の高い配信とデッドレターキュー(DLQ)の追跡: トランザクションデータの整合性を保護します。チャネルステータスの変更を即座にモニターし、デッドレターキューの蓄積を追跡し、失敗したMQI呼び出しを早期に捕捉して、データが永久に失われる前にルーティングの構成ミスやドロップオフを特定します。

使い方

テレメトリーデータがどのように収集、処理、モデル化されるかを理解することは、監視パイプラインを最適化するのに役立ちます。以下のセクションでは、インテグレーションがブローカーからUIまでデータをどのように処理するかを正確に解説します。

テレメトリーデータフロー

テレメトリーデータは、New Relic内で視覚化される前に、4つの異なるレイヤーを順番に流れます:

  1. ブローカーレイヤー: 各IBM MQキューマネージャーは、Programmable Command Format(PCF)を使用して、運用パフォーマンスの統計をネイティブに追跡します。
  2. エクスポーター層: 必須のmq-metric-samplesエクスポーターは、これらのPCF統計をプルし、標準のHTTP/metricsPrometheusエンドポイントで公開します。各セットアップガイドでは、このコンポーネントがクラスタ内で既に実行されていることを前提としています。
  3. Collectorレイヤー: エクスポーターのエンドポイントをスクレイプするようにOpenTelemetry Collectorを設定します。コレクターはバックグラウンドノイズをフィルタリングし、IDタグをフォーマットして、クリーンなOTLPデータをNew Relicに転送します。
  4. 合成レイヤー: New RelicはOTLPペイロードを受信し、データを読みやすく、ナビゲート可能なIBM MQワークスペースエンティティに自動的にマッピングします。

パイプライン処理チェーン

データをクリーンに保ち、取り込みレートを最適化するために、コレクターによって収集されたすべてのメトリクスは、config.yamlファイル内の自動化された順序に依存する処理シーケンスを経由します:

  1. Prometheus Ingest: 実行中のエクスポーターから生のPrometheus/metricsエンドポイントをスクレイプします。
  2. オーバーヘッドフィルター: ボリュームノイズを最小限に抑えるために、エクスポーター自身のセルフメトリクスとバックグラウンドトラッキングサイクルを破棄します。
  3. キューフィルター:アクティブなパフォーマンス追跡を必要としない内部システムキューを除外します。
  4. リソース検出: ペイロードにホストインフラストラクチャのIDタグと環境メタデータをスタンプします。
  5. ラベル変換: 生のPrometheusラベルを標準のドット付きOTel形式に正規化します。たとえば、targetNametarget.nameに再マッピングします。
  6. メモリリミッター: ホストの安定性を保護するために、コレクタープロセスに厳密なメモリカプセルバッファを課します。
  7. Cumulative-to-Delta: 絶対的で連続的なPrometheusメトリクスカウンターを明確なデルタ値に変換します。
  8. バッチバンドリング: ネットワーク効率を最大化するために、個々のテレメトリーイベントをバッチ処理されたOTLPペイロードにグループ化します。
  9. OTLP HTTP Export: 確定され、圧縮されたデータブロックをNew Relicのデータ取り込みシステムに直接送信します。

Collectorのデプロイメントオプション

New Relicは、IBM MQインテグレーション向けに2つのOpenTelemetry Collectorディストリビューションを完全にサポートしています。どちらのオプションも同一の機能を提供し、同じコア設定ファイルを共有します:

  • NRDOT Collector(推奨): New Relicのテクニカルサポート支援によって直接バックアップされた、OpenTelemetry CollectorのNew Relicによる厳選されたディストリビューションです。NRDOT Collector GitHubリポジトリでオープンソースのコードベースを確認してください。
  • OpenTelemetry Collector: アップストリームのCNCFコミュニティディストリビューション。プロジェクトの詳細については、OpenTelemetry Collector ContribのGitHubリポジトリを確認してください。

IBM MQエンティティモデル

New Relicは、テレメトリーストリーム内の特定のマーカーを評価して、生データを自動的にエンティティに合成します:

  • ibmmq_qmgr_statusなどの生のアンダースコア付きメトリクス名と ibmmq_queue_depth
  • 構造的なqmgrおよびqueueデータラベル
  • コレクターのセットアップに応じたtarget.nameID属性

これらのルールを使用して、プラットフォームはデータを明確な親子構造に編成します:

エンティティタイプ複合アイデンティティキーコア表現
IBMMQ_MANAGERtarget.name:qmgr単一のキューマネージャーを表します。例: prod-mq-01:QM1
IBMMQ_QUEUEtarget.name:qmgr:queueマネージャー内にネストされた単一のメッセージキューを表します

注意

メトリクス名やqmgrおよびqueueラベルの名前を変更しないでください。New Relicは、ワークスペースを自動的に合成するために、生のPrometheusアンダースコア形式(ibmmq_*)に依存しています。これらの名前を変更したり、ドット表記に変換したりすると、インテグレーションが機能しなくなり、ダッシュボードが空になります。唯一の例外はtargetNameおよびclusterNameスクレイプラベルであり、プラットフォームのルックアップキーを満たすためにtarget.nameおよびcluster.nameにマッピングする必要があります。

始めましょう

IBM MQ監視パイプラインのセットアップには、3つの主要な実装フェーズが含まれます。

前提条件

環境が、その環境に対して定義されたインテグレーションのすべての要件を満たしていることを確認してください:

Collectorのセットアップ

インフラストラクチャに基づいてインストレーションパスを選択してください:

自分のデータを見る

コレクターのセットアップが完了すると、New RelicでIBM MQのメトリクスを表示し、NRQLでクエリを実行し、ダッシュボードを構築して、アラートを設定できます。詳細については、データの表示とクエリドキュメントを参照してください。

重要

New Relic IBM MQインテグレーションは、さまざまなブローカーメトリクスを追跡します。サポートされているデータ型と属性の詳細については、『IBM MQメトリクスリファレンスガイド』を参照してください。

IBM MQのセルフホスト型計装

New Relicでセルフホスト型監視のためにIBM MQを設定する方法を学びます。

IBM MQのKubernetes計装

New RelicでIBM MQ for Kubernetes監視を設定する方法を学びます。

データの表示およびクエリ

New RelicでIBM MQデータを表示およびクエリする方法をご覧ください。

Copyright © 2026 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.