この章の内容は次のとおりです。
Oracle Service Busでは、サービス・コンポーネントに対して、サービス・レベル・アグリーメント(SLA)のアラートとパイプライン・アラートという2つの異なるタイプのアラートを定義します。どちらのタイプのアラートでも、電子メール・アドレスやJMSキューなどのアラート宛先を指定できます。
SLAアラート・ルールはOracle Service Busコンソールで定義し、パイプライン・アラート・ルールはOracle Service BusコンソールまたはJDeveloperで定義します。次の図は、Service Busの「サービス・ヘルス」ページを示し、アラートを生成したサービスのリストが表示されています。
Fusion Middleware Controlでは、Service Busの「ダッシュボード」ページでドメイン全体のSLAアラートおよびパイプライン・アラートをモニターできます。このページには、指定された間隔内に、または統計が最後にリセットされて以降、ドメインで発生したすべてのアラートに関する情報が表示されます。ダッシュボードには次の情報が含まれています。
指定された期間のアラートを重大度別に示した円グラフ。
現在の集約間隔内に、指定されたタイプのアラートが発生した上位10件のサービス(降順に表示されます)。
円グラフで示されているアラートとその説明が表示された表。
最も多くのエラーが発生したサービスが表示された表。
このページに表示されるアラートは、円グラフに示されているアラートです。このページのどの表でも、アラートまたはサービスの名前をクリックすると、詳細情報を表示できます。または、円グラフのセクションをクリックすると、指定された重大度のアラートに関する詳細情報が表示されます。
アラートは、電子メール・アドレス、JMSキュー、SNMPトラップなど、複数のアラート宛先に送信できます。アラートの宛先はアラート宛先リソースで定義され、このリソースがService Busでアラートに関連付けられます。アラート宛先の詳細は、『Oracle Service Busでのサービスの開発』のアラート宛先の操作に関する項を参照してください。
アラートが生成されるのは、Service Busドメインでアラートおよびモニターが有効化されている場合のみです。SLAアラートの場合、個別のサービスとドメインの両方でSLAアラートを有効にする必要があります。パイプライン・アラートの場合、個別のパイプラインとドメインの両方でパイプライン・アラートを有効にする必要があります。操作設定の詳細は、「操作設定とグローバル設定の構成」を参照してください。
SLAアラートの目的は、Service Busサービスのヘルスや提供されているサービスの品質に関連する問題を運用チームに知らせることです。
SLAアラート・ルールは、各サービスで定義されている条件に基づいて、プロキシ・サービス、ビジネス・サービス、パイプラインおよび分割-結合に対するアラートをトリガーします。プロジェクトのService Busリソースを作成する際に、これらのアラートを構成できます。アラート・ルールの作成時に、アラート・ルールの名前、説明、概要、期間、重大度、頻度および状態を定義します。ルールに基づいてアラートをトリガーする1つ以上の条件を定義することもできます。条件には、メッセージ数またはエラー数、レスポンス時間、失敗率または成功率、およびエンドポイントURIのステータスを含めることができます。
SLAアラートは、SLAアラート・ルールへの違反に対するレスポンスを自動化したもので、ダッシュボードおよび「アラート履歴」ページに表示されます。ビジネスおよびパフォーマンスの要件に従い、許容できないサービス・パフォーマンスを指定するアラート・ルールを定義します。SLAアラート・ルールの作成時に、アラートの日次作動時間帯およびアラート・ルールが失効する日付を指定できます。ルールによって生成されるアラートの集約間隔も指定できます。アラートに設定された集約間隔は、サービスに設定された集約間隔の影響を受けません。集約間隔の詳細は、「集約間隔」を参照してください。
モニターが有効になっているサービスでは、アラート・ルールは個々の間隔で評価されます。作成したアラート・ルールは、まず集約間隔の最後に評価され、その後は各サンプル間隔の最後に評価されます。たとえば、アラート・ルールの集約間隔が5分である場合、それは作成してから5分後に評価され、その後は1分ごとに評価されます(5分に対するサンプル間隔は1分であるため)。
ルールがfalseと評価された場合は、アラートは生成されません。ルールがtrueと評価された場合は、アラートの生成はアラート間隔の頻度によって制御されます。頻度が毎回
である場合は、アラート・ルールがtrueと評価されるたびにアラートが生成されます。頻度が1回通知
である場合は、前回の評価でアラートが生成されなかったときのみアラートが生成されます。つまり、アラートはアラート・ルールが最初にtrueと評価されたときに生成され、条件がリセットされ、再びTrueと評価されるまで、通知は生成されません。
SLAまたはパイプライン・アラート・ルールを作成する際、アラートの重大度を指定します。それらのレベルは、Service Bus内では具体的な意味を持ちませんが、特定の実装に対してアラートがどのような意味を持つのかを定義します。アラートには、次の重大度レベルを設定できます。
通常
警告
軽度
重度
クリティカル
致命的
集約間隔により、モニター・システムがアラート条件をテストする頻度が決定されます。1つの集約間隔を構成するのに十分なデータのサンプルがモニター・サブシステムで収集されるたびに、条件がテストされます。たとえば、1時間の集約間隔を選択した場合、1時間分のデータが利用可能になると条件がテストされます。条件が最初にテストされるのは、1時間後です。1時間の集約間隔のサンプル間隔が10分に設定されているため、条件はそれ以降10分ごとにテストされます。
アラート・ルールの作成および構成時に、そのルールの集約間隔を指定します。この集約間隔は、サービスに設定された集約間隔の影響を受けません。
アラート・ルールの条件が満たされるたびにアラートを生成するか、最初に条件が満たされたときにのみアラートを生成するかを指定できます。条件が満たされるとアラート・ルールによってアラートが生成され、アラート・ルールの評価がtrue
になるたびに、アラート・ルールに含まれているアクションが実行されます。たとえば、平均レスポンス時間が300ミリ秒を超えるという条件を定義した場合、この条件の評価がtrue
になるたびにアラートが送信されます。
アラート・ルールが評価される回数は、集約間隔と、そのルールに関連付けられたサンプル間隔によって異なります。集約間隔が5分に設定されている場合は、サンプル間隔が1分になります。5つのデータ・サンプルが利用可能になると、ルールが評価されます。したがって、ルールは作成されてから約5分後に初めて評価され、それ以降は1分ごとに評価されます。
アラートを1回だけ生成するようにアラート・ルールが構成されている場合、ルールの評価が初めてtrue
となったときにルールに含まれているアクションが実行されて、条件がリセットされ、評価が再びtrue
となるまでそれ以外のアラートは生成されません。たとえば、平均レスポンス時間が300ミリ秒未満という条件を定義した場合、この条件の評価が初めてtrue
となったときにアラートが送信されます。ただし、条件の評価がfalse
となり、再びtrue
となるまでそれ以外のアラートは送信されません。アラートのタイムスタンプは更新され、ダッシュボードに表示されます。
SLAアラート・ルールのアラート条件を定義する際、複数のメジャーから、アラートの評価に使用するものを選択できます。評価する特定のカウント、最小、最大、平均、ステータスなどが含まれます。選択可能な統計のリストは、選択内容によって異なります。たとえば、「最小」、「最大」または「平均」を選択すると、「レスポンス時間」統計が使用できるようになります。また、使用できる統計は、サービス自体の構成によっても異なります。統計の数は、パイプライン、ルート・ノード、処理などがサービスにあるかどうかによって異なります。
次の各項では、各メジャーに使用できる統計のリストと説明を示します。
次の表では、カウント統計の詳細について説明します。
表4-1 カウント統計の詳細
統計 | 説明 |
---|---|
キャッシュのヒット数 |
結果キャッシュを使用するビジネス・サービスの場合、キャッシュを使用してレスポンスがクライアントに返されるたびに、この統計が増分されます。 |
エラー数 |
エラーの数。メッセージの処理が失敗するたびに、この数が増分されます。 |
フェイルオーバー数 |
(ビジネス・サービスの場合のみ)フェイルオーバーが発生した回数。 |
失敗率(%) |
指定された集約間隔で、発生したエラー数と正しく処理されたメッセージ数の比率。 |
メッセージ数 |
処理されたメッセージの合計数。 |
成功率(%) |
指定された集約間隔で、正しく処理されたメッセージ数と発生したメッセージ数の比率。 |
|
(パイプラインの場合のみ)リクエスト・パイプラインにより処理されたエラー・メッセージの数。 |
|
(パイプラインの場合のみ)リクエスト・パイプラインにより処理されたメッセージの数。 |
|
(パイプラインの場合のみ)レスポンス・パイプラインにより処理されたエラー・メッセージの数。 |
|
(パイプラインの場合のみ)レスポンス・パイプラインにより処理されたメッセージの数。 |
検証エラー数 |
(パイプラインに検証アクションのあるプロキシ・サービスの場合)検証エラー数。パイプラインの場合、この統計はvalidation-errorsという名前です。 |
WSSエラー数 |
サービスのトランスポート(HTTPを使用など)によっては、このオペランドが使用できます。処理されたWebサービス・セキュリティ(WSS)のエラー・メッセージの数です。このカウンタはWSDLベースのサービスだけに使用でき、WSSエラーが発生するとインクリメントされます。 |
URI: |
これらのオペランドは、ビジネス・プロセスのエンドポイントURIのアラートを設定します。エンドポイントURIに基づいてアラートを生成する方法の詳細は、「ビジネス・サービスのエンドポイントURIのモニターおよび管理」を参照してください。 |
次の表では、最大、最小および平均の統計の詳細について説明します。
表4-2 最大、最小および平均の統計の詳細
統計 | 説明 |
---|---|
|
(パイプラインの場合のみ)リクエスト・パイプラインが各メッセージを処理するためにかかった時間。 |
|
(パイプラインの場合のみ)レスポンス・パイプラインが各メッセージを処理するためにかかった時間。 |
経過時間 |
(パイプラインおよび分割-結合の場合のみ)各リクエストまたはレスポンスを処理するためにかかった時間。 |
レスポンス時間 |
各リクエストまたはレスポンスを処理するためにかかった時間(ミリ秒)。 |
スロットル時間 |
(ビジネス・サービスの場合のみ)スロットルで構成されているビジネス・サービスによって処理されたメッセージがスロットル・キュー内に存在していた時間。 |
URI: |
このオペランドは、ビジネス・プロセスのエンドポイントURIのアラートを設定します。エンドポイントURIに基づいてアラートを生成する方法については、「ビジネス・サービスのエンドポイントURIのモニターおよび管理」を参照してください。 |
ステータス統計は、ビジネス・サービスにのみ適用され、ビジネス・サービスのエンドポイントURIがオンラインであるかオフラインであるかを条件の基準として使用できます。
次の表では、ステータス統計の詳細について説明します。
表4-3 ステータス統計の詳細
統計 | 説明 |
---|---|
オフラインのすべてのURI |
クラスタ内のすべてのURIがオフラインである場合、trueに評価します。 |
オンラインのすべてのURI |
クラスタ内のすべてのURIがオンラインである場合、trueに評価します。 |
オフラインの特定のURI |
クラスタ内の任意のURIがオフラインである場合、trueに評価します。 |
オンラインの特定のURI |
クラスタ内の任意のURIがオンラインである場合、trueに評価します。 |
パイプライン・アラートは、事前定義された条件セットではなく、メッセージのコンテキストに基づいてトリガーされます。
アラート・アクションを追加および構成することで、パイプライン・メッセージ・フローに直接パイプライン・アラートを定義します。パイプライン・アラート・アクションは、パイプライン内のメッセージ・コンテキストに基づいてアラートを生成します。また、アラート名、説明($order
などのメッセージ要素を含めることが可能)、アラート宛先およびアラート重大度を含めるように構成できます。SLAアラートと異なり、パイプライン・アラート・アクションで生成された通知は、主にビジネスでの使用、またはエラーの報告を目的とし、システムの状態を監視するものではありません。
パイプライン・アラートをトリガーする条件を定義するには、XQueryエディタなどのパイプライン・エディタで使用できる条件構文やif-then-else構文を使用します。アラート本文(コンテキスト変数を含みます)を完全に制御し、メッセージの一部を抽出してアラートに含めることができます。Fusion Middleware Controlでパイプライン・アラートを表示するだけでなく、電子メールによる通知の送信先のアラート宛先またはJMS宛先を選択することもできます。
詳細は、『Oracle Service Busでのサービスの開発』のアラート・アクションの追加に関する項を参照してください。
パイプライン・アラートの使用例として、メッセージ・フローに特殊なビジネス条件が見つかった場合に通知を受け取る必要があるとします。このような定義済条件が見つかった場合にアラートを発生させるように、パイプラインのアラート・アクションを構成できます。また、アラートの通知を受け取るように電子メールおよびJMSアラート宛先を構成し、アラート受信者にペイロードの形式で詳細を送信することもできます。
たとえば、購入注文のWebサイトに注文をルーティングするパイプラインに、1000万ドルを超える注文がルーティングされたときに通知を受け取るようにすることが考えられます。パイプラインの適切な場所に、1000万ドルを超えるという条件を定義するアラート・アクションを作成し、そのアラート・アクションでターゲット宛先として電子メール・アラート宛先を構成することができます。アラートのコンテンツを構成したり、ペイロード形式で注文の詳細を含めたりすることができます。
また、パイプライン・アラートを使用してメッセージ・フローのエラーを検出することもできます。たとえば、プロキシ・サービスが入力ドキュメントを検証する際、クライアントに連絡して問題を修正できるように、検証が失敗したときには通知を受け取るようにすることが考えられます。その場合、パイプラインのエラー・ハンドラ内にアラート・アクションを構成する必要があります。このアクションでは、ペイロードとして送信するために、実際のエラー・メッセージをfault変数に、その他の詳細情報をSOAPヘッダーに含めることができます。アラート・アクション内でアラート宛先リソースを使用することにより、追加のアラート宛先を構成することもできます。
SLAアラートまたはパイプライン・アラートを発生させるには、まずアラート・ルールを定義し、サービス・レベルとグローバル・レベルの両方でアラートおよびモニターを有効にする必要があります。
たとえば、プロキシ・サービスに対してSLAアラートを有効にするには、Oracle Service Busコンソールでそのサービスのアラート・ルールを定義し、そのプロキシ・サービスに対してSLAアラートおよびモニターを有効にして、サービス・バス・ドメインに対してグローバルにSLAアラートおよびモニターを有効にする必要があります。後者の2つの手順は、Fusion Middleware Controlで実行します。パイプライン・アラートを有効にする場合も、同じ手順を実行します。
サービスの操作設定の構成方法の詳細は、「操作設定の表示と構成」を参照してください。「アラート履歴」パネルには、システムにおける違反またはイベントの発生に関する情報を表示する、カスタマイズ可能なテーブルがあります。
SLAアラート・ルールの作成は、2つの手順があるプロセスです。まず、ルールを評価する方法とタイミング、ルールから生成されるアラートの電子メールまたはJMS宛先、生成されるアラートの重大度など、アラート・ルールのプロパティを構成します。プロパティが構成されたら、アラートを生成する条件(条件が満たされると、アラートが生成されます)を指定することができます。
注意:
サービスが別のサービスから作成された場合、アラート・ルールは次のようにして管理されます。
プロキシ・サービスがビジネス・サービスから、またはビジネス・サービスがプロキシ・サービスから作成された場合、アラート・ルール(ある場合)は削除されます。
プロキシ・サービスが別のプロキシ・サービスから、またはビジネス・サービスが別のビジネス・サービスから作成された場合、アラート・ルール(ある場合)は保持されます。
SLAアラート・ルールによってアラートを生成して、電子メール・アドレスまたはJMSキューに通知を送信する場合、それらの宛先を定義するアラート宛先を作成する必要があります。詳細は、『Oracle Service Busでのサービスの開発』のアラート宛先の操作に関する項を参照してください。
単純な式で構成される、少なくとも1つの条件を定義する必要があります。複数の条件を指定する場合は、And/Or演算子を使用して結合します。条件の定義に使用できるメジャーおよび統計の詳細は、「SLAアラートの統計」を参照してください。
この手順では、「SLAアラート・ルールのプロパティの構成」を完了し、「SLAアラート・ルールの作成」ウィザードの「ルール条件」ページを表示していることを前提としています。
SLAアラート・ルールの条件を定義するには:
「SLAアラート・ルールの作成」ウィザードの「ルール条件」ページで、「条件の集約間隔」の時間間隔を選択します。
詳細は、「集約間隔」を参照してください。
条件を定義するには、次の手順を実行します。
表にテンプレート行がない場合は、条件ビルダー表の上の「新しい条件の追加」をクリックします。
表に新しい行が表示されます。
最初のオプション・リストから、統計の評価に使用するメジャーのタイプを選択します。
「カウント」、「最小」、「最大」、「平均」または「ステータス」のいずれかを選択します。
注意:
ステータスはビジネス・サービスでのみ使用可能であり、エンドポイントURIがオンラインであるかオフラインであるかを条件の基準にすることができます。
2番目のオプション・リストから、エラー数、フェイルオーバー率(%)、レスポンス時間など、評価する統計を選択します。
使用可能な統計は、選択したメジャーのタイプによって異なります。詳細は、「SLAアラートの統計」を参照してください。
3番目のオプション・リストから、比較演算子(=、!=、>
または<)を選択します。
比較演算子の後のフィールドに、実際の統計と比較する値を入力します。条件がエンドポイントURIのステータスに基づいている場合は、「True」または「False」を選択します。
条件がエンドポイントURIのステータスに基づいている場合は、すべてのサーバーに対してルールを評価するか、任意のサーバーでルールを評価するかを選択します。
行の右にある「条件の更新」をクリックします。
アラート・ルールに含める必要のあるすべての条件が追加されるまで、前述の手順を繰り返します。
定義した条件を結合するには、結合する条件を選択し、「選択した条件を結合します」をクリックして、AndまたはOr演算子を選択します。
選択した条件が1つの複雑な式に結合されます。
注意:
複数の条件が同じレベルにあり、同じ演算子で結合される場合は、それらの条件を一度に結合できます。条件のグループを結合する場合、結合により作成された複雑な式をさらに別の条件と結合すると、その複雑な式は、最終的な複雑な式ではカッコ内にネストされます。
複雑な式を元の別々の条件に戻すには、複雑な式を選択し、「選択した条件を分割します」をクリックします。
プロパティの構成および条件の作成を行ったら、「作成」をクリックします。
次の図に示すように、サマリー表に新しいアラート・ルールが表示されます。
Fusion Middleware ControlでSLAアラートおよびパイプライン・アラートをモニターしているとき、ドメイン内のすべてのアラートまたはアラートのサブセットの統計を表示したり、特定のアラートに関する詳細情報を表示したり、アラートを削除またはパージしたりできます。特定のアラートに対してアラート・ルールがどのように構成されているかを表示することもできます。
SLAアラートをモニターするためには、モニターとSLAアラートの両方をグローバル・レベルで有効にする必要があります。グローバル設定の構成の詳細は、「グローバル・レベルの操作設定の構成」を参照してください。
グローバル設定が構成されたら、SLAアラートをモニターする各サービスに対してモニターとSLAアラートを有効にすることも必要になります。アラート・レベルを指定することもできます。手順は、次のトピックを参照してください。
Service Busの「アラート履歴」ページでは、表示する特定のアラートを検索できます。アラートはWebLogic診断フレームワークを使用して格納されます。このフレームワークには、ワイルドカード文字などの独自の問合せ言語が含まれています。アラート履歴のアラートをフィルタするには、『Oracle WebLogic Server診断フレームワークの構成と使用』の「WLDF問合せ言語」に記載されている構文を使用してください。
「ダッシュボード」ページで、SLAアラートおよびパイプライン・アラートの円グラフの特定の領域をクリックして、選択した重大度レベルおよびアラート履歴期間のアラートに関する「アラート履歴」ページを表示することもできます。
注意:
このページは、「ダッシュボード」ページでアラートを選択したときも表示されます。
Service Busホーム・ページからアラートの検索を実行するには:
Service Busダッシュボードの「アラート履歴」表または「アラート履歴」ページにアラートが表示されたら、アラートの名前をクリックして、そのアラートに関する詳細を表示できます。
アラートをトリガーする実際のルールの構成を表示できます。「アラート・ルール」ダイアログには、ルールに関する次の構成情報が表示されます。
アラート・ルールの名前(SLAアラートの場合のみ)
ルールの名前と説明
ルールの有効期限
ルールが有効か無効か
アラートの重大度
アラートの間隔
アラートの生成後、ルールの処理が停止されるかどうか
集約間隔
条件式
Service Busダッシュボードでアラート・ルール構成を表示できます。
ダッシュボードでアラート・ルール構成を表示するには: