(1) アラームの評価時刻について
アラームに複数のレコードの監視条件を設定し,レコードの監視間隔およびオフセット(開始時間)が異なる場合,アラームは収集スケジュールが同じ時刻となるときだけ評価されます。必要に応じて,収集間隔の設定を見直してください。
(2) アラームで評価するレコードの保存について
アラームの条件として選択したレコードは,Storeデータベースに記録する必要はありません。
(3) アラーム数の制限について
1つのAgent製品に定義できるアラームテーブルの数は1,024個までです。また,1つのアラームテーブルに登録できるアラームの数は,Performance ReporterのGUIを使用する場合は50個まで,jpctool alarm(jpcalarm)コマンドを使用する場合は250個までです。ただし,Performance ReporterのGUIを使用する場合でも,表示は250個までできます。1つのエージェントにバインドできるアラームテーブルは1つだけです。
なお,定義するアラームの数は,Tuning Managerシリーズのシステム全体で10,000個以内にしてください。10,000個を超えるアラームを定義した場合,Performance Reporterのサービスがダウンし,Performance Reporterを使用できなくなるおそれがあります。
アラームの数は,アラームの条件式によっては範囲を指定することで集約できる場合があります。詳細については「(8) 文字列フィールドに対する条件指定について」を参照してください。
Tuning Managerシリーズのシステム内でエージェントにアラームを多数バインドすると,PFM - Managerおよびエージェントの処理に遅延が発生する場合があります。バインドするアラームの数は次の値を超えないように設定してください。
(4) 文字コード種別の変更について
アラームを作成する際,全角文字や半角カタカナを使用した場合,OSの文字コード種別は変更しないでください。途中で文字コード種別を変更すると,以前に定義したアラームやレポートが実行されなくなります。
OSの文字コードを変更する場合は,一度Tuning Manager serverをアンインストールして,環境を再構築してください。
(5) 値の存在を監視するアラームを設定する場合の注意について
[値の存在を監視するアラームとする]をチェックした場合,アラーム通知時は収集されたデータに条件式で指定した値が存在しません。このためメッセージテキストやMail Subjectに変数%CVSを指定しても,アラーム正常回復時の測定値出力機能を有効に設定している場合は「N/A」,無効に設定している場合は空文字列に変換されるので注意してください。
(6) アラームの発生数によるエージェントの接続数への影響について
Performance Managementでは,PFM - Managerがエージェントから発行されるアラームを受信し,順次Storeデータベース(Master Store)に格納するなどの処理をします。アラームの発行が頻繁になったり多数のエージェントから同時にアラームが発行されたりすると,PFM - Managerの処理に遅延が発生することがあります。遅延が発生すると,処理されていないアラームはPFM - Managerホストのメモリーに蓄積されるため,メモリー使用量が増加したり,システムの性能が低下したりするおそれがあります。
そのため,PFM - Manager が単位時間当たりに処理できるアラーム数を超えないように,アラームの発生頻度を考慮してアラームを定義することをお勧めします。また,あらかじめPFM - Managerに接続するエージェント数を決めておくことをお勧めします。1 つのPFM - Manager に接続できるエージェントの最大数については,マニュアル「JP1/Performance Management 設計・構築ガイド」の付録を参照してください。ただし,SolarisおよびLinuxの場合,1 つのTuning Manager server に接続できるエージェントの最大数は400 です。
(7) アラームの発生数によるシステムリソースへの影響について
アクションが設定されたアラームが,同時に多数発行されると,その数だけアクションが実行され,システムリソースを消費してシステムが不安定になることがあります。
(8) 文字列フィールドに対する条件指定について
アラームの条件式で,文字列フィールドに対して大小比較の条件を指定した場合,ASCIIコードの昇順によって比較されます。ASCIIコードの昇順による比較では,2つの文字列が先頭(一番左側)から比較され,最初に異なる文字に出会ったときのASCIIコードの大小が文字列の大小となります。なお,一方の文字列がもう一方の文字列の先頭から切り出した部分文字列の場合,長い文字列の方が大きいと判定されます(例:"abcdef">"abc")。
数字(文字列)に対する大小比較(ASCIIコードの昇順比較)は,比較対象の数字が同じ桁数の範囲内の場合に,数字を数値と見なして比較した場合の大小比較結果と一致します。※
この性質を利用して,ワイルドカード「?」による桁数指定と大小比較を組み合わせることで,数字(文字列)としての大小比較を数値による大小比較のように扱い,アラームの定義を集約できます。
Hitachi AMS2000シリーズで,LDEV Number(LDEV_NUMBER)フィールドが5~150までのLDEVを監視するアラームを作成する場合の例を次の表に示します。
表8-8 アラーム定義の集約
集約前のアラーム | 集約後のアラーム | ||
---|---|---|---|
アラーム名 | アラーム条件式 | アラーム名 | アラーム条件式 |
Alarm5 | LDEV_NUMBER="5" | Alarm1 | LDEV_NUMBER="?" AND LDEV_NUMBER>="5" |
Alarm6 | LDEV_NUMBER="6" | ||
: : | : : | ||
Alarm9 | LDEV_NUMBER="9" | ||
Alarm10 | LDEV_NUMBER="10" | Alarm 10 | LDEV_NUMBER="??" |
Alarm11 | LDEV_NUMBER="11" | ||
: : | : : | ||
Alarm99 | LDEV_NUMBER="99" | ||
Alarm100 | LDEV_NUMBER="100" | Alarm 100 | LDEV_NUMBER="???" AND LDEV_NUMBER<="150" |
Alarm101 | LDEV_NUMBER="101" | ||
: : | : : | ||
Alarm150 | LDEV_NUMBER="150" |
ワイルドカードを利用しない場合(集約前)は,1つのアラーム条件式に対して1つのアラームを定義しており,合計146個のアラームを作成しています。一方,集約後の例では,LDEV Number(LDEV_NUMBER)の桁数別に3つのアラームに集約しています。範囲指定の上限と下限に対応する桁数のアラームに対して,大小比較の条件式を追加することで,桁数が異なる数字の大小比較を実現しています。