このチュートリアルでは、コア・プログラミング・エレメントやそれらの意味など、モニター・プログラミング・モデルの中心概念について学習します。モニター・プログラミング・モデルの最も基本的な概念は、モニター・モデルです。
モニター・モデルは、ビジネス・アクティビティーなどの監視可能エンティティーのモニター方法についての仕様です。モニター・モデルは、そのエンティティーから受信する情報のタイプ、およびそのエンティティーのパフォーマンス特性を判別するためのその情報の処理方法を定義します。そのようなエンティティーは、実体がある場合 (サーバー、ATM) も抽象的である場合 (プロジェクトの状況、販売実績) もあります。
モニター・モデルは、ビジネス・モニター用に設計されたプログラミング・モデルに基づいています。 ビジネス・モニターは、地域別の毎月の売り上げや、製品カテゴリー別の出荷品の返品率など、ビジネスに関連した統計の収集に焦点を当てます。IT モニターは特定のサーバーおよびソフトウェア・スタックの最大トランザクション・スループットや Web サービスの平均応答時間などの統計の収集に焦点を当てるという点で、ビジネス・モニターは IT モニターとは異なります。WebSphere Business Monitor は IT モニターを目的としていません。このチュートリアルにおけるサンプルもそうです。
このチュートリアルで使用されるサンプルは、リムジン会社の運営を想定しています。保有リムジンの走行アクティビティーをモニターしたいが、現在は紙で行われているとします。リムジンを配車するときに、自動車のプレート番号、ドライバーの名前、乗客の名前、ピックアップ場所と目的地の住所、手配したピックアップ時刻、および予定到着時刻が記載されたワークシートを作成する必要があります。ドライバーから変更が通知された場合は、ワークシートを更新する必要があります。ドライバーは、実際の到着時刻と出発時刻、走行状況、走行所要時間などのリアルタイム情報を提供する場合もあります。1 つのワークシート上でこの情報を追跡することは困難です。 リムジン会社を運営しているため、複数のドライバーと複数の自動車を保有しています。これは、この入力情報すべてを複数のワークシート間で調整する必要があることを意味します。
ビジネスの効率を向上させるために、統計を収集して定期的にこれらのシートを分析する必要があります。例えば、リムジンの毎週の平均走行距離を計算して、ガソリン代を予測して料金の調整が必要かどうかを判断できるようにする必要があります。さらに、自動車が車庫内にあって使用されていなかった平均時間、最も時間に正確なドライバー、最良の顧客なども計算する必要があります。その後、この記録情報をすべて追加のシートに保管し、参照用にフォルダーに保持することができます。 経営者として、ビジネスの運営をできる限り効率的に保持するためにこの情報を必要とすることがよくあります。この情報のうち特に重要なものは、それらを継続して追跡するため、更新情報がさっと見えるようにコルク板に貼っておきたいと思うかもしれません。この情報には、ガソリン代、駐車時間 (車庫を保有しておらず、時間単位で駐車料金を支払うため)、各ドライバーの合計走行時間などが含まれます。
保有車両のアクティビティーをモニターするために、独自のモデルをアクティブに使用しています。これがモニター・モデルです。ワークシート、フォルダー内の書類、コルク板にピンで留められた書類に保管するすべての情報は、ビジネスにとって不可欠な情報であり、最新の状態に保つ必要があります。
Development Toolkit は、紙ベースのモニター・モデルを Monitor サーバー上にデプロイ可能なコンピューター・ベースのモニター・モデルに変換するために役立ちます。次の図は、WebSphere Business Monitor にデプロイされた場合のモニター・モデルの上位ビューを表しています。
リムジンの例におけるビジネス・アクティビティーは、リムジン・レンタル・サービスです。このビジネス・アクティビティーによって生成されるイベントは、車庫からの出発、乗客のピックアップ、乗客の降車などです。Monitor サーバー上のモニター・モデルは、ビジネス・アクティビティーによって生成されるイベントを listen します。Monitor サーバーは、モニター・モデルをデプロイして実行できるランタイム環境です。1 つの Monitor サーバーに複数のモニター・モデルをデプロイできます。モニター・モデルは、着信イベントに含まれるデータを使用して、走行の所要時間、走行の状況、どのドライバーが最も時間に正確かなどの、パフォーマンス・データを計算します。その後、このデータはデータベースに保管されます。 データベースからの情報は、ダッシュボードと呼ばれるビジネス指向の UI を使用してユーザーに表示されます。ダッシュボードには、ゲージ、図表、およびグラフが含まれています。
ここまで、紙ベースのリムジン・レンタル会社を例に使用して、類似により WebSphere Business Monitor の基本概念を紹介しました。次の表に、類似点を要約します。モニター・コンテキスト、メトリック、およびイベントに関する詳細は、第 2 章で学習します。
紙ベースのモニター | コンピューター・ベースのモニター |
---|---|
データが記載されたワークシート | モニター・コンテキスト |
記録するデータの種類、およびワークシート内でどのように編成するかに関する記述 | モニター・コンテキスト定義 |
ワークシート内のフィールド | メトリック |
ドライバーからの着信電話呼び出し | イベント |
ワークシートやワークシートから計算されるその他の情報を保持するためのフォルダー | データベース |
コルク板 | ダッシュボード |
モニター・プログラミング・モデルは、イベント・ベースです。モニター・モデルは、モニター対象エンティティーから発行されるイベントから直接データ入力を受け取ります。モニター・モデルが着信イベントから正しくデータを取得できるようにするためには、関連イベント・コンテンツを参照するパス式を指定する必要があります。それらのパスを定義し、検証するためには、MME はこの情報を含むイベント・ペイロードのタイプ (レイアウト) を知る必要があります。
ペイロードには、リムジンの ID、ドライバーの名前、出発時刻など、モニター・モデルの関連データが含まれています。WebSphere Business Monitor が処理するペイロードは、XML で記述されています。正しく情報にアクセスするためには、ペイロードの XML スキーマ定義 (XSD) で MME に通知する必要があります。
リムジン・ビジネスのシナリオでは、ドライバーからの呼び出しはイベントです。ドライバーが呼び出す理由はさまざまです。乗客の住所に到着したことを伝えるために呼び出すと、「乗客のピックアップ」イベント・タイプであるとわかるため、その場所に到着した時刻やそこにいることが予期される時刻などの特定の情報をドライバーから予期できます。WebSphere Business Monitor では、この「イベント種別ステップ」はフィルター条件に基づいています。イベントが特定のタイプを持っていると認識するために、特定のデータ・エレメントがイベント内に存在するかどうか、または特定の値を持っているかどうかを Monitor がテストすることを確認できます。イベントは、チャネルまたはメディアを介して発行および送信する必要があります。紙のモデルでは、セルラー・タワーと無線周波数を使用してイベントを送信します。WebSphere Business Monitor では、イベントは Common Event Infrastructure (CEI) を介してモニター・モデルに送信されます。
次の図は、チュートリアルで前に示した図と同じですが、イベント情報が追加されています。CEI が、イベント・ソース (モニター対象エンティティー) から Monitor サーバーへの橋渡しをします。CEI のイベントは Common Based Event (CBE) と呼ばれる固有の形式で送信されます。CBE も XML で記述されています (そして、独自の XML スキーマ定義を持っています)。CBE 内には、モニター・モデルが受信するペイロードを含むフィールド (またはスロット) があります。
このレッスンは、イベントは CBE (XML ベース) として処理され、情報ペイロードも XML で記述されていることを示しています。その結果、Monitor サーバーは、特定のデータ・フィールドを取得するために CBE およびペイロードをナビゲートする手段を必要とします。その方式では、XML パス言語 (XPath) の式を使用します。
この章の始めに、「問題」タブに特定の問題が 1 つ表示されていることを思い出してください。そのエラー・メッセージは、どのイベントがインスタンスの作成を発生させるかを指定する定義を MME がモニター・モデル内で検索していることを示しています。紙ベースのモニター・モデルでは、これはドライバーが配車されると必ず新規ワークシートを開始することに対応しています。
このセクションでは、イベント・サブスクリプションを使用してこの問題を修正します。モニター対象エンティティーからモニター・モデルへの唯一の直接の入力はイベントのストリームであるため、イベント・サブスクリプションはモニター・モデルの正しい動作のための基本となります。ただし、そのエンティティーが多くの異なる種類のイベントを発行していて、一部のイベントをそのモニター・モデルが必要としない可能性があります。このため、モニター・モデルは、その計算に必要なイベントに対してのみ明示的にサブスクライブする必要があります。後続の段落で、WebSphere Business Monitor でどのようにイベント処理が行われるかについて理解を深めます。
イベントが届くと、Monitor サーバーは、これらのイベントにサブスクライブした MC にそれらを送信します。ワークシート・メタフォーを使用すると、電子ワークシートは、このシート上に記録された走行に関する情報を含むイベントに「サブスクライブ」または listen します。イベント・サブスクリプションは、モニター・プログラミング・モデル内のインバウンド・イベント定義として実装されます。
インバウンド・イベントは、2 つの不可欠なパーツを含んでいます (下のダイアグラムを参照してください)。
インバウンド・イベント定義には、これらの考えられるケースそれぞれに対して行う内容に関するディレクティブが含まれている必要があります。下の表に、これらのケースそれぞれに対して考えられるアクションを示します。
相関式の結果 | 考えられるアクション |
---|---|
ケース 1: インスタンスが一致しなかった |
|
ケース 2: 正確に 1 つのインスタンスが一致した |
|
ケース 3: 複数のインスタンスが一致した |
|
モニター・モデル開発者として、それぞれの着信イベントに対して 3 つのケースそれぞれで行う内容を決定する必要があります。指定するアクションが、モニター・モデルの処理ロジックを制御します。リムジンの例では、リムジンが配車されてドライバーより車庫からの出発を通知する呼び出しがあると、新しいワークシートを作成して初期データを入力します。このタイプのイベント (インスタンス作成を発生させる) は、作成イベントと呼ばれます。ただし、イベントが乗客をピックアップさせることであり、相関の結果一致がない場合は、存在しないワークシートを誰かが更新しようとしているため、それをエラーとして処理できます。
要約すると、モニター・コンテキストによってイベントが受信されると、まずフィルター処理を使用してイベント・タイプが識別されます。そのモニター・コンテキストにとって関心があるイベント・タイプである場合、イベントに相関処理が適用され、このイベントの影響を受けるインスタンス、およびインスタンスの数が判別されます。そのイベントに対して実行されるアクションは、相関処理の結果、および 3 つの考えられるケースそれぞれに対してどのようなアクションが指定されているかによって異なります。最後に、そのモニター・モデルがサブスクライブするそれぞれのイベント・タイプに対してインバウンド・イベント定義を作成する必要があります。
WebSphere Business Monitor のモニター・コンテキストは、イベント・サブスクリプションとメトリックの間のギャップを埋めるものを必要とします。着信イベントの内容に基づいてメトリックを更新する方法を WebSphere Business Monitor に通知する必要があります。このギャップは、マップを定義することにより埋められます。
次の図は、イベント・サブスクリプションを左側に、メトリックを右側に配置して、モニター・コンテキストを象徴的に示しています。
マップは、メトリックの値の計算方法を定義するターゲット・メトリックが所有する式によって定義されます。マップは、スプレッドシートの数式に類似しています。 インバウンド・イベントに依存するマップは、この種類のイベントがモニター・コンテキストに送信されると必ず実行されます。イベントが複数のインスタンスに送信される場合、マップは各インスタンスで実行されます。メトリックのみに依存するマップは、入力メトリックのいずれかが変更されると実行されます。
このチュートリアルでは、データ駆動のマップのみを使用します。
2 つの異なる方針に従ってマップを定義できます。データ・フロー (それぞれの種類のインバウンド・イベントについて、それぞれのメトリックに対する効果を考慮する)、または依存関係 (それぞれのメトリックについて、それぞれの種類のインバウンド・イベントによる影響を考慮する) のいずれかを参照できます。依存関係によってマップを定義する場合、最初に結果をクロスチェックする必要があります。
同様に、メトリック内のマップは、データ・フロー (このメトリックの別のメトリックに対する影響、およびその内容など)、または依存関係 (他のどのメトリックがこのメトリックに影響を与えるか、およびその方法) を参照することにより定義できます。 「他方の」方式を使用して結果をダブルチェックすることをお勧めします。
マップの定義にはいくつかの重要な制限があり、MME によって強制されます。 マップを定義すると、計算されるメトリック間に依存関係が作成される可能性があります。 これらの依存関係は非循環 (メトリック A がメトリック B に依存する場合、メトリック B がメトリック A に依存してはならない) でなければならず、マップは 1 つのインバウンド・イベントしか参照できません (複数のイベントが同時に届くことはないため、どちらか一方が使用不可になります)。
マップの定義後、結果として生成されるデータ・フローを参照するために「フロー・ビューのモニター」が役立つ場合があります。次の図は、サンプル表示を表しています。passengerPickedUp イベントが pickUpActualTime メトリックを更新し、そのメトリックが tripStatus メトリックと pickUpWasLate メトリックに対する更新を引き起こします。