![[目次]](GRAPHICS/CONTENT.GIF)
![[索引]](GRAPHICS/INDEX.GIF)
![[前へ]](GRAPHICS/FRONT.GIF)
![[次へ]](GRAPHICS/AFTER.GIF)
Tuning Manager ユーザーズガイド
- この項の構成
- (1) アラームで評価するレコードの保存について
- (2) アラーム数の制限について
- (3) 文字コード種別の変更について
- (4) 値の存在を監視するアラームを設定する場合の注意について
- (5) アラームの発生数によるエージェントの接続数への影響について
- (6) アラームの発生数によるシステムリソースへの影響について
- (7) 文字列フィールドに対する条件式の集約について
アラームの条件として選択したレコードは，エージェントのPerformanceデータベースに記録する必要はありません。
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を使用できなくなるおそれがあります。
アラームの数は，アラームの条件式によっては範囲を指定することで集約できる場合があります。詳細については「(7) 文字列フィールドに対する条件式の集約について」を参照してください。
Tuning Managerシリーズのシステム内でエージェントにアラームを多数バインドすると，PFM - Managerおよびエージェントの処理に遅延が発生する場合があります。バインドするアラームの数は次の値を超えないように設定してください。
- 1エージェント当たり250個
- Tuning Managerシリーズのシステム全体で10,000個
アラームを作成する際，全角文字や半角カタカナを使用した場合，OSの文字コード種別は変更しないでください。途中で文字コード種別を変更すると，以前に定義したアラームやレポートが実行されなくなります。
OSの文字コードを変更する場合は，一度Tuning Manager serverをアンインストールして，環境を再構築してください。
(4) 値の存在を監視するアラームを設定する場合の注意について
［値の存在を監視するアラームとする］をチェックした場合，アラーム通知時は収集されたデータに条件式で指定した値が存在しません。このためメッセージテキストやMail Subjectに変数%CVSを指定しても，アラーム正常回復時の測定値出力機能を有効に設定している場合は「N/A」，無効に設定している場合は空文字列に変換されるので注意してください。
(5) アラームの発生数によるエージェントの接続数への影響について
Performance Managementでは，PFM - Managerがエージェントから発行されるアラームを受信し，順次エージェントのStoreデータベース（Master Store）に格納するなどの処理をします。アラームの発行が頻繁になったり多数のエージェントから同時にアラームが発行されたりすると，PFM - Managerの処理に遅延が発生することがあります。遅延が発生すると，処理されていないアラームはPFM - Managerホストのメモリーに蓄積されるため，メモリー使用量が増加したり，システムの性能が低下したりするおそれがあります。
そのため，PFM - Manager が単位時間当たりに処理できるアラーム数を超えないように，アラームの発生頻度を考慮してアラームを定義することをお勧めします。また，あらかじめPFM - Managerに接続するエージェント数を決めておくことをお勧めします。1 つのPFM - Manager に接続できるエージェントの最大数については，マニュアル「JP1/Performance Management 設計・構築ガイド」の付録を参照してください。
(6) アラームの発生数によるシステムリソースへの影響について
アクションが設定されたアラームが，同時に多数発行されると，その数だけアクションが実行され，システムリソースを消費してシステムが不安定になることがあります。
アラームの条件式で文字フィールドに対して条件を指定した場合の例を次に示します。
ワイルドカードを使用して指定すると，アラームの定義を集約できます。
VSP G1000で，LDEV Number（LDEV_NUMBER）フィールドのCU番号が10～1FのLDEVを監視するアラームを作成する場合の例を次の表に示します。
表9-8 アラーム定義の集約（ワイルドカードを使用して指定した場合）
集約前のアラーム 集約後のアラーム アラーム名 アラーム条件式 アラーム名 アラーム条件式 Alarm5 LDEV_NUMBER="00:10:00" Alarm1 LDEV_NUMBER="00:1?:??" Alarm6 LDEV_NUMBER="00:10:01" ：
：：
：Alarmxx LDEV_NUMBER="00:1F:yy" ワイルドカード「?」による桁数指定と大小比較を組み合わせることで，数字（文字列）としての大小比較を数値による大小比較のように扱い，アラームの定義を集約できます。
Hitachi AMS2000シリーズで，LDEV Number（LDEV_NUMBER）フィールドが5～150までのLDEVを監視するアラームを作成する場合の例を次の表に示します。
表9-9 アラーム定義の集約（大小比較の条件を指定した場合）
集約前のアラーム 集約後のアラーム アラーム名 アラーム条件式 アラーム名 アラーム条件式 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つのアラームに集約しています。範囲指定の上限と下限に対応する桁数のアラームに対して，大小比較の条件式を追加することで，桁数が異なる数字の大小比較を実現しています。
- 参考
- アラームの条件式で，文字列フィールドに対して大小比較の条件を指定した場合，ASCIIコードの昇順によって比較されます。ASCIIコードの昇順による比較では，2つの文字列が先頭（一番左側）から比較され，最初に異なる文字に出会ったときのASCIIコードの大小が文字列の大小となります。なお，一方の文字列がもう一方の文字列の先頭から切り出した部分文字列の場合，長い文字列の方が大きいと判定されます（例："abcdef">"abc"）。
- 数字（文字列）に対する大小比較（ASCIIコードの昇順比較）は，比較対象の数字が同じ桁数の範囲内の場合に，数字を数値と見なして比較した場合の大小比較結果と一致します。
なお，文字列フィールドの大小比較はASCIIコードの昇順に比較されるため，数値比較の結果とは異なります。
例えば，LDEV Number（LDEV_NUMBER）フィールドは文字列フィールドのため，条件式LDEV_NUMBER >="100"をLDEV_NUMBER="2"やLDEV_NUMBER="3"も満たします。
All Rights Reserved. Copyright© 2014, 2020, Hitachi, Ltd.