閾値監視の使用例を示します。閾値監視の参考にしてください。
ケース1：架空A社様 オンライン業務システムの場合
- 資料 － システム運用規定および性能要件（抜粋）
オンライン業務の稼働時間帯は、毎日8時～18時。 オンライン業務の繁忙時間帯は、毎日12時～15時。 当システムは、繁忙時間帯でもオペレーター端末操作がノンストレスであることを必須とする。
したがって、I/O レスポンスの性能目標は、一般的な基準値の「30msec以下」とする。
なお、繁忙時間帯以外の I/O レスポンスの性能目標は、業務量の比率（繁忙時間帯の業務量は、繁忙時間帯以外の約3倍）から、30msec の 1/3 の「10msec以下」とする。 繁忙時間帯は、データ参照・更新・追加処理の集中で、最大60分間連続実行する場合がある。
I/O レスポンス 30msec 以上の状態が当該連続実行中の 10% 相当（6分間）発生した場合、オペレーター端末の操作にストレスを与える可能性がある。
したがって、この状態が発生した時にアラームログを作成するように設定する。 繁忙時間帯の I/O レスポンスが繁忙時間帯以外の性能目標と同等の 10msec 以下になった場合は、それ以前に発生していた I/O レスポンス遅延は瞬間的な現象と判断する。
したがって、この状態が発生した時はアラームログを作成しなくても良い。 イベントログは、アラームログ作成時に毎回表示する必要はなく、1日1回の表示で良い。
（システム管理者は、1日1回コンディションレポートをチェックするため）
|
- A社様 オンライン業務システムの稼働状況イメージ（LogicalVolume レスポンスの変化）
- A社様 オンライン業務システムにおける閾値監視設定の例
資料に対応する番号 | 設定項目 | 設定値（設定内容） |
|---|
1 | 閾値監視時間 | 8:00-18:00 |
2 | アラーム表示時間 | 12:00-15:00 |
3 | 閾値監視対象 | LogicalVolume レスポンス |
3 | 閾値 | 30msec |
4 | 閾値監視単位時間 | 60分 |
4 | アラーム許容範囲 | 合計時間 360秒 |
5 | 下限値 | 10msec |
6 | アラーム表示頻度 | 日毎 |
ケース2：架空B社様 オンラインショッピングシステムの場合
- 資料 － システム運用規定および性能要件（抜粋）
オンライン業務稼働時間帯は、24時間365日。 オンライン業務繁忙時間帯は、特定できない。 当システムは、本稼働を開始してから徐々に「ご利用会員数」が増加するのに伴い、アクセス数も増加していく。このため、ストレージに対する負荷も徐々に増大していくものと推測する。したがって、ストレージのリソース（CM、ディスク）のビジー率が6～8割程度を超えた場合は、対策を講じなければならない。 当システムではクレジット決済処理が5分間隔で発動するため、決済直前の5分間は商品の検索・注文の処理がノンストレスで実行されなければならない。もし、ストレージのリソースのビジー状態（ビジー率6～8割を超える状態）が5分間続く場合、取引に影響する可能性がある。したがって、この状態が発生した時は、アラームログを作成するように設定する。 イベントログは、アラームログ作成時に毎回表示するようにする。システム管理者は、イベントログ表示を契機にコンディションレポートをチェックする。
|
- B社様 オンラインショッピングシステムの稼働状況イメージ（CM ビジー率の変化）
- B社様 オンラインショッピングシステムにおける閾値監視設定の例
資料に対応する番号 | 設定項目 | 設定値（設定内容） |
|---|
1 | 閾値監視時間 | 0:00-24:00 |
2 | アラーム表示時間 | 0:00-24:00 |
3 | 閾値監視対象 | CM ビジー率 |
3 | 閾値 | 60％ |
4 | アラーム許容範囲 | 連続時間 300秒 |
5 | アラーム表示頻度 | すべて |
資料に対応する番号 | 設定項目 | 設定値（設定内容） |
|---|
1 | 閾値監視時間 | 0:00-24:00 |
2 | アラーム表示時間 | 0:00-24:00 |
3 | 閾値監視対象 | RAIDGroup ビジー率 |
3 | 閾値 | 80％ |
4 | アラーム許容範囲 | 連続時間 300秒 |
5 | アラーム表示頻度 | すべて |
ケース3：架空C社様 複数DBサーバ（クラスタシステム）によるバッチ処理運用の場合
- 資料 － システム運用規定および性能要件
システム運用時間帯は、24時間365日。 バッチ処理稼働時間帯は、毎日20時～23時。 当システムは、3ノードで Oracle RAC システムを構築している。現在はデータ量が少ないためバッチ処理の性能に問題はないが、将来はデータ量の増加に伴う FC スイッチとストレージ間の FC パス転送能力ネックが懸念される。
もし、FC パスのボトルネックが生じた場合、速やかに対処しなくてはならない。 FC パスのボトルネックとして、Port スループットが最大転送能力の8割程度に達した状態を想定する。この状態が30分間以上続く時は、アラームログを作成するように設定する。 イベントログは、アラームログ作成時に毎回表示する必要はなく、バッチ処理稼働時間帯で1回以上アラームログが発生した場合でも1回表示されれば良い。システム管理者は、イベントログ表示を契機にコンディションレポートをチェックする。
|
- C社様 複数DBサーバ（クラスタシステム）でのバッチ処理状況イメージ（Port スループットの変化）
- C社様 業務システムのバックアップ運用における閾値監視設定の例
資料に対応する番号 | 設定項目 | 設定値（設定内容） |
|---|
1 | 閾値監視時間 | 0:00-24:00 |
2 | アラーム表示時間 | 20:00-23:00 |
3 | 閾値監視対象 | Port スループット |
3 | 閾値 | 80％ |
4 | アラーム許容範囲 | 連続時間 1800秒 |
5 | アラーム表示頻度 | 監視時間毎 |
