メッセージキューバックエンド構成の例

キュー名を無視することによるサーバーのモニタリング

JMSの例では、アプリケーションが複数のキューを処理するメッセージサーバーに対してコールを行なっています。例の宛先名は以下のようになります。

• AccountQ
• AccountReplyQ
• AccountRecQ
• AccountDebitQ

デフォルトの自動検出ルールは、一意の宛先ごとに 1 つのバックエンドを検出するので、フローマップにはキュー名ごとに 1 つのキューバックエンドが表示されます。この例では、上記はそれぞれアプリケーション フロー マップに個別のバックエンドとして表示されます。各キュー名ではなくサーバのパフォーマンスのモニタリングが対象の場合は、構成を変更して宛先プロパティを無視し、タイプとベンダーのみを使用できます。 

この結果を得るためには、カスタムJMS検出ルールを新規作成します。

別の例としてIBM MQでは、アプリケーションが複数のキューを処理するメッセージサーバーに対してコールを行なっています。例の宛先名は以下のようになります。

• MQhostwest-US:1521
• MQhosteast-US:1521
• MQhostsouth-US:1521

デフォルトの自動検出ルールは、一意の宛先ごとに 1 つのバックエンドを検出するので、フローマップにはキュー名ごとに 1 つのキューバックエンドが表示されます。この例では、上記はそれぞれアプリケーション フロー マップに個別のバックエンドとして表示されます。各キュー名ではなくサーバのパフォーマンスのモニタリングが対象の場合は、次のようにホストとポートのみを使用する検出ルールを作成できます。

一時キュー

この例では、アプリケーションが、メッセージの受信後に削除される一時的なJMS応答キューを多く作成します。デフォルトで、AppDynamicsでは、こうしたキューが別々に検出され、それぞれが一意のリモートサービスとしてリストアップされます。このデフォルトの動作では、おそらく効果的なモニタリングを行うことができません。代わりに、宛先名に「TemporaryQueue」が含まれるかどうかを指摘するカスタムJMS検出ルールを作成し、これを「WeblogicTempQueue」など、お使いのモニタリング環境に合った名前でリストアップすることができます。こうすることで、重要なパフォーマンスをモニタリングすることができます。これを行うための構成を、以下のスクリーンショットに示します。

キュー名のセッションID

JMSキューが宛先のセッションIDを使用する場合、これにより各セッションは独立したバックエンドとして識別されます。この場合、各キューを個別に表示するのではなく、同じホストおよびポートのすべてを同じバックエンドに集約すると良いでしょう。自動検出ルールを編集することで、モニタリングするバックエンドの適切な名前と正しい番号を生成することができます。これにより、最も関心のあるキーパフォーマンスインジケータ（KPI）をモニターすることができます。