前のトピック: クラスタ化メトリックの登録

次のトピック: 出力 - ユーザ テーブル

Agents

各メトリックには、トラッキング期間の定義が 1 つあります。 トラッキング期間は、メトリックがサービス レベルの結果を出力しなければならない期間で、その結果は、定義されているターゲットと比較する必要があります。 トラッキング期間に生成された結果はビジネス結果であり、これは言い換えると、特定のターゲットのサービス レベルを提供するためにプロバイダがコミットした契約上の結果です。 各期間のビジネス ロジックのインスタンスはそれぞれ 1 つのエージェントと呼ばれるもので、各メトリックに関連付けられている粒度に直接関係しています。

たとえば、メトリックに 1 か月のトラッキング期間が定義されている場合、このメトリックは月単位の結果を提供するために実行されます。

月単位の結果について、さらに日単位の結果を参照できるようにするドリル ダウン機能を提供するために、メトリックでは、追加の時間単位の定義が必要になります。この時間単位でメトリックを計算する必要があります。 時間単位は、[粒度]タブの[メトリック]の[一般詳細]セクションで定義されます。

メトリックの[粒度]タブで、トラッキング期間に対して定義されたそれぞれの時間単位について、別のビジネス ロジック インスタンスがエンジンによって実行されます。 これらの各インスタンスは同じビジネス ロジック コードを実行しますが、これらの各インスタンスに対して OnPeriodStart と OnPeriodEnd は別にトリガされます。 日単位のインスタンスについては、1 日の始めと 1 日の終わりにトリガされます。 各時間単位については、その時間単位の開始と終了のポイントに従ってトリガされます。

ビジネス ロジックの各インスタンスは、対象の時間単位の結果を生成するために実行されます。 また、各期間では、あらゆる例外を考慮した結果を備えている必要があります。 (例外が定義されている場合)、このような結果を保持していない期間は、ユーザが、考慮された例外あり、または例外なしのどちらでサービス レベルの結果を見るかを選択できるようにする必要があります。 この要件があるために、各メトリックは、エンジンによって実行される 14 個のエージェント(インスタンス)を潜在的に備えています。2 つのエージェントはビジネス結果用で、12 個のエージェントは追加の 6 個の運用期間用です。

エージェントの例

これは、別のエージェントに対してはそれぞれの期間が計算されるため、粒度の定義が計算エンジンのパフォーマンスに多大な影響を与えることを意味します。 したがって、全体または部分的にドリル ダウン機能が必要でない場合には、いくつかのエージェントをオフにすることが推奨されます。 これは、時間単位の結果のように、粒度が低い場合には特に大きな影響があります。 また、エンジンは、発生したそれぞれのクラスタアイテムに対して上記のすべての計算を行うため、これはクラスタ化メトリックに対しても多大な影響があります。 実際には、エンジンは各クラスタアイテムを新しいメトリックとして扱います。 たとえば、50 のアイテムのリソース グループでメトリックを計算する場合には、同様の非クラスタ化メトリックに比べて、エンジンが行なう処理の 49 倍機能します。

たとえば、メトリックが数日間、解決時間を計算するよう設定された場合は、時間単位の結果は意味がありません。また、エンジンが不要な計算を実行しないように、粒度のタブでチェックを解除しておく必要があります。

Context オブジェクトの TimeUnit 属性(つまりビジネス ロジックの context.TimeUnit)は、実行中のエージェントの時間単位を返します。ここで返される値として可能性のあるものは、HOUR、DAY、WEEK、MONTH、QUARTER、YEAR です。

たとえば、日単位のエージェントの場合、Context.TimeUnit は "DAY" を返します。

Context オブジェクトの IsTrackingPeriod 属性は、トラッキング期間の時間単位を計算するエージェントに対して True を返します。 また、メトリックの[粒度]タブに示されているエージェントは、メトリックのトラッキング期間のエージェントに付加されたものであることに注意してください。 このため、月単位のトラッキング期間を持つメトリックに対しても、月単位のエージェントをオフにしたうえで、月単位のサービス レベルを(ビジネス結果として)計算することができます(非オペレーション結果)。

エージェントの例

上記で説明するように、各種のエージェントは通常同じビジネス ロジック コードを実行しますが、わずかに異なるロジックを適用しなければならない場合もあります。

たとえば、月単位の場合には、以下に示すように、結果として各月でそれぞれ何回か停止時間がありました。

エージェントの例

日単位でドリルダウンする場合には、累積した停止時間を参照できるようにして、それぞれの日が、月の始めからの日数の合計になるようにする必要があります。 このメソッドは、以下に示すように 1 月以下のすべての時間単位に適用されます。

エージェントの例

2 つの時間単位の違いは、停止時間が発生するトラッキング期間を計算しているエージェントは、各期間の最初に 0 に初期化されますが、日単位のエージェントでは、月の最初の日だけカウンタが初期化される、ということです。

OnPeriodStart イベント ハンドラは以下のとおりです。
Sub OnPeriodStart(time)
     If InStr(“MONTH,QUARTER,YEAR”, Context.TimeUnit) > 0 _
 Or (Context.TimeUnit = “DAY” And Day(time) = 1) _
 Or (Context.TimeUnit = “HOUR” And Day(time) = 1 And Hour(time) = 0) Then
          DownTimeCounter = 0
     End If
End Sub

再計算とは

関連付けエンジンが、メトリックの最終期間の結果が有効ではなく、結果を再計算しなければならないことが認識された場合に、再計算が実行されます。

再計算は以下の事項によって生じることがあります。

登録するための最も効率的なメソッドは、契約関係者およびサービスです。 契約関係者およびサービスのリソースを整理すると、システムでのデータ レイヤとビジネス レイヤの間の論理関係を表現することができます。 これらのエンティティを介してリソースを登録すると、別の契約で使用されている場合、または別のサービスに対して使用されている場合でも計算式に対する変更が不要になります。 メトリックの現在のコンテキストは契約およびサービスを特定しましたが、これは対象の契約関係者、および関連するサービスを定義します。 このタイプの登録で定義されているビジネス ロジックの計算式は、登録において変更が必要ないため、簡単に再利用できます。