シチュエーションのモニターおよび間隔の設定

モニター対象とするシチュエーションと、それらのシチュエーションをモニターしなければならない頻度を識別します。ソフトウェアの設計について理解するようになると、さまざまな間隔の設定が、過剰なシステム・リソース要求の原因となることに気付きます。 間隔の頻度を低くすることで、システム・リソースの需要を削減できる場合、あるいは増加させてしまう場合が分かるようになります。

ソフトウェアによる例外しきい値のデータ収集方法を考慮に入れてください。ソフトウェアは、シチュエーションを使用して例外を表します。 シチュエーションは、インテリジェントな間隔設定値を選択するのに役立ちます。 ソフトウェアには、アプリケーション要約、キャッシュ CU パフォーマンス、仮想磁気テープ・サブシステムなどのリーフ名を持つナビゲーター・ビューがあります。 リーフ名は、単一のデータ・コレクターによって収集される多数のデータ列が含まれるワークスペースにリンクしています。

例えば、「アドレス・スペース」リーフを右クリックすると、そのリーフに関連付けられたすべてのシチュエーションを表示できます。リーフ上のシチュエーションは、いずれも同じデータ・コレクターを使用します。 リーフ上のすべてのシチュエーションに同じ間隔を設定すると、これらのシチュエーションが 1 つのグループにまとめられます。 シチュエーションがグループにまとめられていれば、データ・コレクターを 1 回呼び出すだけで、データを収集できます。 一方、シチュエーションごとに異なる間隔が設定されている場合には、データ・コレクターはリーフ上のシチュエーションごとに呼び出されたり、実行されたりすることになります。

間隔を 2 分から 1 分に変更すると、システム・リソースに対する要求が増加します。 ソフトウェアはしきい値をグループにまとめ、同じ表または属性グループから同時にすべてのデータを収集します。 間隔を変更すると、新規データ・コレクターをスケジュールすることになり、システム・リソースに対する要求が 2 倍になります。 3 個目のしきい値を変更して 3 分に設定すると、システム・リソース要求は 3 倍になります。 サンプリングの頻度を下げたい場合、同じ属性グループに属するすべてのシチュエーションの間隔を低い頻度に設定する必要があります。

リーフにあるシチュエーションが 4 件以下の場合には、必ず警告シチュエーションとクリティカル・シチュエーションに同じ間隔を設定してください。 こうすることで、データ・コレクターを 1 回実行するだけで、データを収集することができます。 アクティブ・シチュエーションが 5 件以上ある場合は、コレクターがすでに 2 回実行されているため、利益はありません。 同じ間隔が設定されたシチュエーションは、すべて一緒にスケジュールされます。 例えば、ある間隔に 4 件の警告シチュエーションを適用し、別のより高い頻度の間隔に 4 件のクリティカル・シチュエーションを適用することで、システム・リソースに対する要求を削減できます。 このアプローチは、ほとんどの製品で提供されるシチュエーションと同様に、シチュエーションに対して 2 件の条件または項目が評価されることを前提としています。7 件の複雑な条件または評価基準のシチュエーションをコーディングしても、そのシチュエーションは、おそらく複数のシチュエーションを追加してスケジュールされることはありません。実際には、ルールのサイズによって制限されます。

変更の影響を評価する前に、IBM Tivoli Enterprise Monitoring Server ハブを再始動する必要があります。結合のプロセスは、自動的に開始されるシチュエーションの開始時にのみ行われます。つまり、それまで結合されていたものはすべて、変更を加えると結合されなくなるため、再始動するまでシステム・リソースに対する要求が増加します。