test

Sun Java System Message Queue 3.7 UR1 管理ガイド

ブローカサービス

ブローカ設定プロパティーは、影響を受けるサービスやブローカコンポーネントに応じて、いくつかのカテゴリに分類できます。

次の節では、これらの各サービスおよび、特定のニーズに合わせてサービスをカスタマイズするために使用できるプロパティーについて説明します。

接続サービス

メッセージブローカは、さまざまなトランスポートプロトコルを使用して、アプリケーションと管理クライアントの両方をサポートするさまざまな接続サービスを提供できます。接続サービスに関連するブローカ設定プロパティーについては、「接続のプロパティー」に示しています。

表 4–1 に使用できる接続サービスを示します。それらは次の 2 つの特性によって識別されます。

表 4–1 Message Queue 接続サービス

サービス名 

サービスタイプ 

プロトコルタイプ

jms

NORMAL

TCP

ssljms (Enterprise Edition)

NORMAL

TLS (SSL ベースセキュリティー)

httpjms (Enterprise Edition)

NORMAL

HTTP

httpsjms (Enterprise Edition)

NORMAL

HTTPS (SSL ベースセキュリティー)

admin

ADMIN

TCP 

ssladmin

ADMIN

TLS (SSL ベースセキュリティー) 

ブローカの imq.service.activelist プロパティーを設定することで、これらの接続サービスの一部、またはすべてを実行することができます。このプロパティーの値は、ブローカの起動時にアクティブにする接続サービスのリストであり、このプロパティーを明示的に指定しないと、jms および admin サービスがデフォルトでアクティブにされます。

各接続サービスは、特定の認証および承認機能もサポートします。詳細については 「セキュリティーサービス」を参照してください。

ポートマッパー

各接続サービスは、ホスト名 (または IP アドレス) とポート番号によって指定された特定のポートで使用できます。サービスには、静的なポートを明示的に指定するか、またはブローカのポートマッパーによって動的にポートを割り当てることができます。ポートマッパー自体は、通常、標準ポート番号 7676 にあるブローカのプライマリポートに常駐します。必要に応じて、ブローカの設定プロパティー imq.portmapper.port を使用して、このポートを別のポート番号で上書きできます。デフォルトで、各接続サービスは、起動時に自身をポートマッパーに登録します。クライアントがブローカとの接続を作成すると、Message Queue クライアントランタイムはまずポートマッパーに接続し、目的の接続サービスのポート番号を要求します。

または、ポートマッパーを上書きし、imq. serviceName.protocolType. port 設定プロパティー (この場合 serviceName と protocolType は 表 4–1に示すように、特定の接続サービスを示す) を使用して、接続サービスに静的ポート番号を明示的に割り当てることができます。この方法で設定できるのは、jms、ssljms、admin、および ssladmin 接続サービスのみです。httpjms および httpsjms サービスでは、付録 C 「HTTP/HTTPS のサポート」に説明するように、異なる設定プロパティーが使用されます。ただし、静的ポートは、一般に、ファイアウォールを介した接続 (「ファイアウォールを介した接続」を参照) を作成する場合などの特定の状況でのみ使用し、一般的な使用にはお勧めしません。

注 –

複数のホストを使用できる場合 (コンピュータに複数のネットワークカードがインストールされている場合など)、ブローカプロパティーを使用して、接続サービスのバインド先にするホストを指定できます。imq.hostname プロパティーは、すべての接続サービス用の単一のデフォルトのホストを指定し、必要に応じて、imq. serviceName. protocolType.hostname (jms、ssljms、admin、または ssl 管理サービス) または imq.portmapper.hostname (ポートマッパー自体) で、上書きできます。

複数のポートマッパー要求が同時に受け取られた場合、それらはアクションの待機中に、オペレーティングシステムのバックログに保存されます。imq.portmapper.backlog プロパティーは、そうしたバックログされた要求の最大数を指定します。この制限を超えると、バックログが縮小するまで、その後の要求が拒否されます。

スレッドプール管理

各接続サービスは、複数の接続をサポートするマルチスレッドです。これらの接続に必要なスレッドは、ブローカによって、サービスごとに個別のスレッドプールに保存されます。接続にスレッドが必要なときは、その接続をサポートするサービスのスレッドプールにスレッドが追加されます。

選択するスレッドモデルは、スレッドが 1 つの接続専用であるか、複数の接続で共有するかどうかを指定します。

ブローカの imq.serviceName. threadpool_model プロパティーは、特定の接続サービスに 2 つのうちどちらのモデルを使用するかを指定します。このプロパティーは、dedicated または shared の文字列値のどちらかになります。プロパティーを明示的に設定しない場合は、デフォルトで dedicated が使用されます。

ブローカプロパティー imq.serviceName. min_threads および imq.serviceName. max_threads を設定して、サービスのスレッドプール内のスレッドの最小数と最大数を指定することもできます。使用可能なスレッド数が、指定された最小のしきい値より少なくなると、Message Queue は、再び最小値に達するまで、スレッドをシャットダウンして、スレッドを解放します。これによって、メモリーのリソースが節約されます。負荷が重い場合、スレッドの数がプールの最大数まで増加する可能性があります。最大数に達すると、スレッドが利用できるようになるまで、新しい接続は拒否されます。

共有スレッドモデルでは、ディストリビュータスレッドを使用して、スレッドをアクティブな接続に割り当てます。ブローカプロパティー imq.shared.connectionMonitor_limit は、1 つのディストリビュータスレッドで監視できる接続の最大数を指定します。このプロパティーの値を小さくするほど、接続にスレッドを割り当てる速度が向上します。imq.ping.interval プロパティーは、時間間隔を秒単位で指定します。ブローカが定期的に接続をテスト ("ping") して、接続がまだアクティブであるか確認することによって、メッセージ送信に失敗する前に、事前に接続の障害を検出できます。

ルーティングサービス

クライアントがブローカに接続したら、メッセージのルーティングおよび配信を処理できるようになります。この段階では、ブローカはさまざまな種類の物理的送信先の作成および管理を担当し、メッセージのスムーズなフローを確保し、リソースを効率的に使用します。「ルーティングのプロパティー」で説明するブローカ設定プロパティーを使用して、それぞれのアプリケーションのニーズに合わせて、これらのタスクを管理できます。

ブローカのパフォーマンスと安定性は、使用できるメモリーなどのシステムリソースとリソースの使用効率によって異なります。設定プロパティーを設定して、受信メッセージによるブローカの過負荷やメモリー不足を防止することができます。これらのプロパティーは、リソースが不十分になってもメッセージサービスの動作を維持できるように 3 つのレベルで機能します。

こうしたシステムメモリーのしきい値がトリガーされることは、システム全体および送信先のメッセージ制限の設定が高すぎることを示しています。メモリーしきい値によって、潜在するメモリーの過負荷を必ずしもタイミングよく検出できるとは限らないため、メモリー利用率を制御するためにそれらに依存することは避け、メモリーリソースを最大限に活用できるように、システム全体および送信先の制限を再設定する必要があります。

持続サービス

障害が発生したブローカを復元するには、メッセージの配信処理の状態を作成し直す必要があります。この操作を行うには、ブローカが持続データストアに状態情報を保存する必要があります。ブローカの再起動時、ブローカは保存されたデータを使用して、送信先と永続サブスクリプションを再作成し、持続メッセージを復元して、開いているトランザクションをロールバックし、配信されていないメッセージのルーティングテーブルを再構築します。このあとに、メッセージの配信を再開できます。

Message Queue は、ファイルベースの持続モジュールと JDBC ベースの持続モジュールの両方をサポートしています (図 4–1 を参照)。ファイルベースの持続は、持続データを保存するために個別のファイルを使用し、JDBC ベースの持続では、JDBC™ (Java Database Connectivity) インタフェースを使用し、JDBC 互換のデータストアにブローカを接続します。ファイルベースの持続は一般に JDBC ベースより高速ですが、JDBC 互換ストアによって実現される冗長性や管理者による制御を好むユーザーもいます。ブローカ設定プロパティー imq.persist.store (表 14–4 を参照) は 2 つの持続形式のどちらを使用するかを指定します。

図 4–1 持続データストレージ

図は持続サービスが単層型ファイルベースのデータストアを使用するか、または JDBC ベースのデータストアを使用するかを示しています。

ファイルベースの持続

デフォルトで、Message Queue はファイルベースの持続データストアを使用します。これは、メッセージ、送信先、永続サブスクリプション、およびトランザクションなどの持続データを個別のファイルに保存します。ファイルベースの持続に関連するブローカ設定プロパティーについては、「ファイルベースの持続」に示しています。

ファイルベースのストアは、そのデータストアが属するブローカインスタンスの名前 (instanceName) によって識別されるディレクトリに配置されます。

…/instances/instanceName
/fs350/

instances ディレクトリの場所については、付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照してください。ブローカの各送信先には、その送信先に配信されるメッセージを保持する個別のサブディレクトリがあります。

注 –

持続データストアには機密事項を扱うメッセージや財産的価値のあるメッセージが含まれることがあるため、…/instances/ instanceName/fs350/ ディレクトリは承認されていないアクセスから保護するようにしてください。「持続データの保護」を参照してください。

メッセージ以外の持続データは、すべて個別のファイルに格納されます。送信先、永続サブスクリプション、トランザクション状態情報のファイルがあります。大半のメッセージは、可変長レコードから構成されるシングルファイルに格納されます。可変長レコードファイルを圧縮し、メッセージが追加および削除されたときの断片化を緩和することができます (「物理的送信先の圧縮」を参照)。さらに、特定のしきい値を超えるサイズのメッセージは、可変長レコードファイルではなく、個別のファイルに格納されます。このしきい値のサイズは、ブローカプロパティー imq.persist.file.message.max_record_size で設定できます。

ブローカは、これらの各メッセージファイル用のファイルプールを維持します。ファイルは必要なくなった場合にも削除されず、送信先ディレクトリの空きファイルのプールに戻されるため、あとで別のメッセージに再利用できます。ブローカプロパティー imq.persist.file.destination.message.filepool.limit はプール内のファイルの最大数を指定します。送信先の各メッセージファイル数がこの制限を超えた場合、ファイルが不要になると、プールに戻されずに削除されます。

ファイルをファイルプールに戻すと、ブローカは前の内容を削除せずに、再利用可能なファイルとしてタグ付けすることにより、保存領域と引き換えに時間を節約できます。imq.persist.file.message.filepool.cleanratio ブローカプロパティーを使用して、単に再利用可能とマークするだけでなく、「クリーン」(空き) 状態で維持する必要がある各送信先のファイルプール内のファイルのパーセンテージを指定します。この値を大きくするほど、ファイルプールに必要な領域は少なくなりますが、ファイルをプールに戻す際にファイルの内容を空にするために必要なオーバーヘッドが大きくなります。ブローカの imq.persist.file.message.cleanup プロパティーが true の場合、ブローカのシャットダウン時にプール内のすべてのファイルが空にされ、クリーン状態のままにされるため、保存領域は節約できますが、シャットダウンの処理速度が遅くなります。

持続ストアへのデータの書き込みにおいて、オペレーティングシステムには、データを同時に書き込むか、または「レイジー」(非同期的) に書き込むかを選択できます。レイジーストレージでは、システムクラッシュの発生時に、ブローカが持続ストレージにデータが書き込まれていなくても書き込まれたものと考えた場合に、データが損失する可能性があります。パフォーマンスと引き換えに、完全な信頼性を確保するために、ブローカプロパティー imq.persist.file.sync.enabled を true に設定して、すべてのデータを同時に書き込むように要求できます。この場合、システムがクラッシュ後に回復した際に、データの利用が保証されるため、ブローカは確実に処理を再開できます。ただし、データは失われませんが、クラスタ構成のブローカでは現在データを共有していないため、クラスタ内のほかのブローカからは使用できません。

JDBC ベースの持続

ファイルベースの持続を使用する代わりに、JDBC 互換ドライバを介してアクセスが可能な任意のデータストアにアクセスするように、ブローカを設定できます。この作業には、該当する JDBC 関連のブローカ設定プロパティーの設定、データベースマネージャーユーティリティー (imqdbmgr) を使用した適切なスキーマでのデータストアの作成が含まれます。仕様については、「JDBC ベースのストアの設定」を参照してください。

JDBC データベースを使用するように、ブローカを設定するプロパティーについては、「JDBC ベースの持続」を参照してください。これらのプロパティーを指定するには、各ブローカインスタンスのインスタンス設定ファイル (config.properties) を使用するか、ブローカユーティリティー (imqbrokerd) またはデータベースマネージャーユーティリティー (imqdbmgr) に -D コマンド行オプションを使用します。

imq.persist.jdbc.driver プロパティーは、データベースへの接続に使用する JDBC ドライバの Java クラス名を指定します。既存のデータベースへの接続 (imq.persist.jdbc.opendburl)、新しいデータベースの作成 (imq.persist.jdbc.createdburl)、およびデータベース接続のクローズ (imq.persist.jdbc.closedburl) のための URL を指定するプロパティーもあります。

imq.persist.jdbc.user および imq.persist.jdbc.password プロパティーは、データベースにアクセスするためのユーザー名とパスワードを指定し、imq.persist.jdbc.needpassword はパスワードが必要かどうかを指定するブール型のフラグです。セキュリティー上の理由から、パスワードは、-passfile コマンド行オプションで指定するパスワードファイルにのみ指定する必要があります。そうしたパスワードファイルを指定しないと、imqbrokerd および imqdbmgr コマンドではインタラクティブにパスワードの入力が要求されます。同様に、imqbrokerd コマンドに -dbuser オプション、または imqdbmgr コマンドに -u オプションを使用して、コマンド行からユーザー名を指定できます。

複数のブローカインスタンスによって共有される JDBC データベースでは、設定プロパティー imq.persist.jdbc.brokerid は、データベーステーブル名に追加される各データベースの一意のインスタンス識別子を指定します。このプロパティーは、1 つのブローカインスタンスのデータのみを格納する組み込みデータベースでは、一般に必要ありません。その他の JDBC 関連の設定プロパティーは、データベーススキーマを作成する SQL コードをカスタマイズするために使用し、1 つのプロパティーが 1 つのデータベーステーブルに対応します。たとえば、imq.persist.jdbc.table.IMQSV35 プロパティーはバージョンテーブル、imq.persist.jdbc.table.IMQCCREC35 は設定変更レコードテーブル、imq.persist.jdbc.table.IMQDEST35 は送信先テーブルを作成するための SQL コマンドを指定します。すべてのリストについては、表 14–6 を参照してください。

注 –

データベースシステムによって、必要とされる正確な SQL 構文が異なるため、詳細についてはデータベースベンダーのマニュアルを参照してください。

セキュリティーサービス

Message Queue には、ユーザーアクセス制御 (認証と承認) および暗号化のためのセキュリティーサービスが用意されています。

Message Queue 管理者は、ユーザーを認証し、ユーザーの操作を承認するために必要な情報をブローカに設定する責任があります。セキュリティーサービスに属するブローカプロパティーを 「セキュリティーのプロパティー」に示します。ブール型のプロパティー imq.accesscontrol.enabled はアクセス制御をブローカ全体 に適用するかどうかを制御するマスタースイッチとして機能しますが、厳密に制御す る場合は、imq.serviceName .accesscontrol.enabled プロパティーを設定することによって、特定の接続サービスでこの設定を上書きできます。ここで serviceName は表 4–1 に示す接続サービスの名前で、たとえば imq.httpjms.accesscontrol.enabled などになります。

図 4–2 に、ブローカが認証サービスおよび承認サービスを提供するために必要なコンポーネントを示します。これらのサービスは、メッセージングシステムのユーザーに関する情報を格納するユーザーリポジトリを使用します。ユーザーに関する情報とは、名前、パスワード、およびグループメンバーシップです。さらに、ユーザーまたはグループの特定の操作を承認するため、ブローカは、ユーザーやグループが実行できる操作を指定したアクセス制御プロパティーファイルを参照します。ブローカ全体で 1 つのアクセス制御プロパティーファイルを指定する場合は、設定プロパティー imq.accesscontrol.file.filename を使用し、1 つの接続サービスでアクセス制御プロパティーファイルを指定する場合は、imq.serviceName. accesscontrol.file.filename を使用します。

図 4–2 セキュリティーのサポート

ブローカのセキュリティーサービスがユーザーリポジトリとアクセス制御プロパティーファイルを使用していることを示している図。

図 4–2 に示すように、Message Queue サービスによって提供された単層型ファイルユーザーリポジトリにユーザーデータを格納するか、または、既存の LDAP (Lightweight Directory Access Protocol) リポジトリに接続できます。

ブローカの imq.authentication.basic.user_repository プロパティーは、どちらの種類のリポジトリを使用するかを指定します。一般に、拡張性が重要な場合、またはブローカクラスタを使用するなど、さまざまなブローカでリポジトリを共有する必要がある場合は、LDAP リポジトリをお勧めします。単層型ファイルリポジトリまたは LDAP ユーザーリポジトリの設定の詳細については、「ユーザー認証」を参照してください。

認証

ブローカへの接続を要求するクライアントは、ユーザー名とパスワードを入力する必要があります。ブローカはそれらをユーザーリポジトリに保存されているユーザー名とパスワードと比較します。クライアントからブローカに送信されるパスワードは、Base-64 (単層型ファイルリポジトリの場合) か、メッセージダイジェスト (MD5) ハッシュ (LDAP リポジトリの場合) を使用して暗号化されます。この選択は、ブローカ全体としては imq.authentication.type プロパティーで、または特定の接続サービスに対しては imq.serviceName. authentication.type で制御します。imq.authentication.client.response.timeout プロパティーは、認証要求のタイムアウトの間隔を設定します。

「パスワードファイル」で説明するように、パスワードはインタラクティブに入力を求める代わりに、パスワードファイルに指定することができます。ブール型のブローカプロパティーimq.passfile.enabled によってこのオプションを制御します。このプロパティーが true の場合、imq.passfile.dirpath および imq.passfile.name プロパティーで、パスワードファイルのディレクトリパスとファイル名を指定します。imq.imqcmd.password プロパティー (パスワードファイルに埋め込み可能) は管理ユーザーが、ブローカ、接続サービス、接続、物理的送信先、永続サブスクリプション、トランザクションの管理にコマンドユーティリティー (imqcmd) を使用することを認証するためのパスワードを指定します。

LDAP ベースのユーザーリポジトリを使用する場合は、LDAP 検索のさまざまな側面を設定するために、あらゆる範囲のブローカプロパティーを使用できます。LDAP サーバー自体のアドレス (ホスト名とポート番号) はimq.user_repository.ldap.server で指定します。imq.user_repository.ldap.principal プロパティーは、LDAP リポジトリにバインドするための識別名を指定し、imq.user_repository.ldap.password は関連パスワードを指定します。その他のプロパティーは、個々のユーザーおよびグループ検索用のディレクトリベースとオプションの JNDI フィルタ、ユーザーおよびグループ名のプロバイダ固有の属性識別子などを指定します。詳細については、「セキュリティーのプロパティー」を参照してください。

承認

ユーザーは認証されると、さまざまな Message Queue 関連のアクティビティーを実行することを承認されます。Message Queue 管理者は、ユーザーグループを定義し、各ユーザーにグループのメンバーシップを割り当てることができます。デフォルトのアクセス制御プロパティーファイルは、admin という 1 つのグループだけを明示的に参照します (「グループ」を参照)。このグループのユーザーは、admin 接続サービスの接続アクセス権を持ち、送信先の作成、ブローカの監視と制御などの管理機能を実行できます。その他のグループに定義されたユーザーは、デフォルトでは admin サービスの接続アクセス権を取得できません。

ユーザーがある操作を実行しようとすると、ブローカが、ユーザーリポジトリ内のユーザー名とグループのメンバーシップを、アクセス制御プロパティーファイル内のその操作へのアクセスに指定されたユーザー名とグループのメンバーシップと照らし合わせます。アクセス制御プロパティーファイルでは、次の操作に対するユーザーまたはグループのアクセス権を指定します。

暗号化

クライアントとブローカ間で送信されるメッセージを暗号化するには、SSL (Secure Socket Layer) 標準に基づいた接続サービスを使用する必要があります。SSL は、SSL 対応のブローカとクライアント間で暗号化された接続を確立して、接続レベルのセキュリティーを提供します。

SSL ベースの Message Queue 接続サービスを使用するには、キーツールユーティリティー (imqkeytool) を使用して、非公開鍵と公開鍵のペアを生成します。このユーティリティーは、自己署名付き証明書に公開鍵を組み込んで、それを Message Queue のキーストアに配置します。キーストア自体は、パスワードによって保護されているため、起動時に、imq.keystore.password プロパティーに指定されたキーストアのパスワードを入力して、ロックを解除する必要があります。キーストアのロックが解除されると、ブローカは、接続を要求しているクライアントに証明書を渡すことができます。証明書を受け取ると、クライアントはその証明書を使用して暗号化されたブローカへの接続を設定します。

imq.audit.enabled ブローカプロパティーは、Message Queue ブローカログファイルへの監査レコードのロギングを制御します。詳細については、「監査ロギング」を参照してください。

監視サービス

ブローカには、アプリケーションおよびブローカのパフォーマンスを監視し、診断するためのコンポーネントが含まれます。次のコンポーネントがあります。

この仕組みの概略を、図 4–3 に示します。管理サービスを設定するブローカプロパティーを、「監視のプロパティー」に示します。

図 4–3 監視のサポート

図は、ロガーへの入力、エラーレベル、および出力チャネルを示しています。図は文字で説明されます。

メトリックスジェネレータ

メトリックスジェネレータは、ブローカとの間で入出力されるメッセージフロー、ブローカメモリー内のメッセージ数とそれらが消費するメモリー量、開かれている接続の数、使用中のスレッドの数など、ブローカのアクティビティーに関する情報を提供します。ブール型のブローカプロパティー imq.metrics.enabled はそれらの情報を記録するかどうかを制御し、imq.metrics.interval は記録する頻度を指定します。

ロガー

エラーの発生時に、ロガーで、ブローカコードおよびメトリックスジェネレータによって生成された情報が取得され、その情報が標準出力 (コンソール)、ログファイル、Solaris プラットフォーム、syslog デーモンプロセスに書き込まれます。使用するログファイルは imq.log.file.dirpath および imq.log.file.filename ブローカプロパティーで指定し、imq.log.console.stream はコンソールの出力を stdout または stderr のどちらに書き込むかを指定します。

imq.log.level プロパティーは、ロガーが収集するメトリックス情報のカテゴリを制御します。カテゴリは、ERROR、WARNING、または INFO です。各レベルにはそれ以上のレベルも含まれるため、たとえばロギングレベルとして WARNING を指定すると、エラーメッセージも記録されます。imq.log.console.output および imq.log.file.output プロパティーは、指定したカテゴリのどれをコンソールに書き込み、どれをログファイルに書き込むかを制御します。たとえば、エラーと警告の両方をログファイルに書き込み、情報メッセージをコンソールに書き込む場合は、明示的に imq.log.file.output を ERROR|WARNING に設定し、imq.log.console.output を INFO に設定する必要があります。Solaris プラットフォームでは、別のプロパティー imq.log.syslog.output で、syslog デーモンに書き込むメトリックス情報のカテゴリを指定します。デッドメッセージが破棄された場合、またはデッドメッセージキューに移動された場合にログに 記録するかどうかを指定するimq.destination.logDeadMsgs プロパティーもあります。

ログファイルの場合、ファイルを閉じて出力が新しいファイルにロールオーバーされる時点を指定できます。ログファイルが指定したサイズ (imq.log.file.rolloverbytes) または有効期間 (imq.log.file.rolloversecs) に達すると、保存されて新しいログファイルが作成されます。

ログに関連するその他のブローカプロパティーについては、「監視のプロパティー」を参照してください。また、ロガーの設定方法およびロガーを使用してパフォーマンス情報を取得する方法の詳細については、「ブローカロギングの設定と使用」を参照してください。

メトリックスメッセージプロデューサ (Enterprise Edition)

メトリックスメッセージプロデューサは、メトリックスジェネレータから定期的に情報を受け取り、メトリックスメッセージに情報を書き込みます。メトリックスメッセージは、メッセージに含まれるメッセージ情報のタイプに応じて、多数のメトリックストピック送信先のいずれかに送信されます (表 4–2 を参照)。これらのメトリックストピック送信先にサブスクライブされている Message Queue クライアントはメッセージを消費し、それらに含まれるメトリックスを処理できます。これにより、開発者はカスタム監視ツールを作成して、メッセージングアプリケーションをサポートできます。各タイプのメトリックスメッセージで報告されるメトリックス数の詳細は、『Message Queue Developer's Guide for Java Clients』を参照してください。

表 4–2 メトリックスのトピック送信先

トピック名 

メトリックス情報のタイプ

mq.metrics.broker

ブローカのメトリックス 

mq.metrics.jvm

Java 仮想マシンのメトリックス 

mq.metrics.destination_list

送信先とそれらのタイプのリスト 

mq.metrics.destination.queue.queueName

指定したキューの送信先メトリックス 

mq.metrics.destination.topic.topicName

指定したトピックの送信先メトリックス 

ブローカプロパティー imq.metrics.topic.enabled および imq.metrics.topic.interval はそれぞれ、メッセージをメトリックストピック送信先に送信するかどうかと、その頻度を制御します。imq.metrics.topic.timetolive および imq.metrics.topic.persist プロパティーは、それらのメッセージの有効期間とそれらが持続メッセージであるかどうかを指定します。

メトリックスメッセージの本文に含まれる情報以外に、各メッセージのヘッダーには次の追加情報を提供するプロパティーが含まれます。

これらのプロパティーは、異なる種類または異なるブローカからのメトリックスメッセージを処理するクライアントアプリケーションに有用です。