OSS 運 管理勉強会商用統合監視ソフトウェアからの移 事例と HP サーバーの HW 監視 2013 年 11 月 19 日
Agenda HP サーバの HW 監視 (10 分 ) 商用統合監視 SW からの移 事例 (15 分 ) QA(5 分 ) 2
HP サーバの HW 監視
Zabbix と HW 監視 Zabbix はアプリケーションからハードウェアまで一括して監視できる ただし Zabbix で HW を監視するのは大変 App Middleware Zabbix Server OS MIB の解析 量のアイテム トリガーの作成障害試験. Hardware 4
MIRACLE ZBX HP サーバ用監視テンプレートによる受信 どのホストで何が起きたかがすぐにわかる SNMP Trap 送信元ホスト名を表示 障害内容の概要を表示 Phisical Drive Status Change (3046) on zab460l Logical Drive Status Change (3034) on zab460l 5
MIRACLE ZBX HP サーバ用監視テンプレートによる受信 詳細な障害箇所も Zabbix から確認 SNMP Trap 全体を Zabbix 上に表示 Port 1I Box 1 Bay 2 failed 6
MIRACLE ZBX HP サーバ用監視テンプレートによる受信 500 以上の SNMP Trap に対応したアイテムとトリガーを登録済み 未登録の SNMP Trap を受信しても重度の障害として通知 7
SNMP Trap 受信方式 Zabbix 1.8でもZabbix 2.0でも利 できます snmptrapdから呼び出されたスクリプトがzabbix_senderコマンドを実 します Zabbix サーバ 監視対象 HW/SW SNMP Trap snmptrapd スクリプト ( テンプレート付属 ) snmptrapd が SNMP Trap 受信時にスクリプトを呼び出す スクリプト中で Zabbix_Sender コマンドを実 し Zabbix サーバに通知する Zabbix サーバ 8
テンプレートの構成 スクリプト Zabbix サーバ テンプレート zabbix_sender s < 送信元 IP の逆引き結果 > k <MIB オブジェクト名 > o <SNMP Trap のデータ全て > 紐づけ 値として保存 コマンド引数 zabbix_sender s < ホスト > k < キー > o < 値 > SNMP Trap 送信元ホストの障害として通知 アイテムとトリガーは 1 対 1 に対応 アイテム トリガー キー値 CPQIDA-MIB_cpqDa2PhyDrvStatusChange CPQIDA-MIB_cpqDa2LogDrvStatusChange CPQNIC-MIB_cpqNic2RedundancyIncreased CPQNIC-MIB_cpqNic3RedundancyReduced 名前 深刻度 Physical Drive Status Change (3003) 致命的 Logical Drive Status Change (3001) 致命的 NIC Redundancy Increased Trap (18007) 情報 NIC Redundancy Reduced Trap (18014) 重度 9
商用統合監視 SWとZabbixの機能差分 Zabbixへ移 をしようとすると 困った! 旧システムで使用していた監視 SW の機能がない! 1. 過去アラームのローカル出 機能がない 2. 取得したリソース値のローカル出 機能がない 3. ログ SNMP Trap 内のメッセージを抽出し イベントやアクションに 反映ができない 作りこみで対応 4. アラーム抑止の時間リセット機能がない 5. アクションがテンプレート管理ではない 6. 監視条件に優先順位がないため すべて排他の条件にしなければならない 工夫次第で何とかなる! 11
4. アラーム抑止の時間リセット機能がない除外期間と除外解除期間 指定期間内にログ出 された重複アラームを抑止し 一定期間超過後にリセットする機能 除外期間 期間を指定 ( 例 :2 分間で条件にマッチするエラーが複数 でても 最初の のみアラームとする ) 除外解除周期 初回アラームから指定時間超過後に 抑止をリセット ( 例 : 初回アラームから 15 分後に抑止を解除 ) nodata 関数を使えば簡単に実現できそうに思えるが 後者の 除外解除周期 が難しい 12
4. アラーム抑止の時間リセット機能がない nodata 関数だけで実現しようとすると [ アイテム ].regexp(.*)#0 & [ アイテム ].nodata(120)#1 ( ノーマル ) このとき DB に値が入ったタイミング ( アイテム収集タイミング ) と タイマー系関数である nodata 関数の毎分 0 秒と 30 秒に過去 120 秒の値を確認する 13
4. アラーム抑止の時間リセット機能がない nodata 関数だけで実現しようとすると [ アイテム ].regexp(.*)#0 & [ アイテム ].nodata(120)#1 ( ノーマル ) 初回アラームを基準とするのではなく DB の値を過去に遡って確認する仕様であるため エラーが出 され続けた時にトリガーステータスが正常に戻らない 14
4. アラーム抑止の時間リセット機能がない [ 準備 1] アクションを作成 エスカレーションを 有効 期間を初回アラームから抑止リセットさせたい時間 ( 秒 ) アクションのオペレーションをステップ2 zabbix_senderで該当トリガーキーに対して 抑止リセット という文字を送信 /usr/bin/zabbix_sender -z < ホスト名 > -s {HOSTNAME} -k '{TRIGGER.KEY}' -o '< 抑止リセット >' [ 準備 2] トリガーに条件追加 [ アイテム ].regexp(.*)#0 & [ アイテム ].nodata(120)#1 [ アイテム ].regexp(.*)#0 & [ アイテム ].nodata(120)#1 & [ アイテム ].regexp(" 抑止リセット ")}=0 15
4. アラーム抑止の時間リセット機能がない [ 参考 ] アクションの例 16
4. アラーム抑止の時間リセット機能がない 結果 17
5. アクションがテンプレート管理ではない アクションのインポート / エクスポートが出来ない ある商用統合監視 SW の場合は自動アクション機能が Zabbix でいうトリガーの一部として設定できたため その自動アクションもテンプレートとしてインポート / エクスポートができたが Zabbix ではそれが出来ない 18
5. アクションがテンプレート管理ではない アクションのインポート / エクスポートが出来ない DB を直接書き換える方法も考えられるが Zabbix が使用する DB に直接 INSERT することで 予期せぬ動作をする懸念があった 開発環境で試験をしたアクション設定値が 商用環境でも同一の設定となっていることの担保がとれればよい ことから アクションの設定一覧のエクスポート機能を実装した これは単純にアクションに使用している actions operations conditions を DB から SELECT し テキストに出 する機能 商用環境でアクションを作成後 あらかじめ開発環境で上記機能を使用して生成されたテキストデータとの差分比較をすることにより 最低限のエンドユーザー要望を満たすことが出来た 19
6. 監視条件に優先順位がないため すべて排他の条件にしなければならない 商用統合監視 SW の場合 条件を上から順番にマッチングしていき マッチしたタイミングでそれより下の条件は ない [ 例 ] YYYY/MM/DD hh:mm::ss error エラーコード =[xxxx] あるログに error という 字列が書き込まれたときにアラームとしたい 但し ログ内に書かれたエラーコードが 1000/2000/3000/4000/5000 のときはアラームとはしたくない ある商用統合監視 SW であれば 右図のようにアラーム発報したい条件より上に 除外条件 を追加するだけでよかった +/- 条件 1 除外 エラーコード =[1000] 2 除外 エラーコード =[2000] 3 除外 エラーコード =[3000] 4 除外 エラーコード =[4000] 5 除外 エラーコード =[5000] 6 発報 error 20
6. 監視条件に優先順位がないため すべて排他の条件にしなければならない Zabbixで普通に条件を作ると Zabbixではすべての条件がフラットに評価される 前ページの例でトリガーを作ると [ アイテム ].regexp(.*error.* )#0 errorという 字列が含まれる & [ アイテム ].regexp(.* エラーコード = [1000 ].* )=0 エラーコード1000は除外 & [ アイテム ].regexp(.* エラーコード = [2000 ].* )=0 エラーコード2000は除外 & [ アイテム ].regexp(.* エラーコード = [3000 ].* )=0 エラーコード3000は除外 & [ アイテム ].regexp(.* エラーコード = [4000 ].* )=0 エラーコード4000は除外 & [ アイテム ].regexp(.* エラーコード = [5000 ].* )=0 エラーコード5000は除外 という いトリガーを作らないとならない 正規表現を使ってみる 21
6. 監視条件に優先順位がないため すべて排他の条件にしなければならない独自正規表現を作成する [ 管理 ] > [ 一般設定 ] から正規表現を作成する 22
6. 監視条件に優先順位がないため すべて排他の条件にしなければならない 独自正規表現を作成する 名前 :errorcode 条件式 : 右表 とすると トリガー条件式は [ アイテム ].regexp(@errorcode)#0 という短い条件で済む また 除外したいエラーコードの追加 / 削除があったとしても 正規表現側を修正するだけで容易に修正が可能になる 期待値 条件 1 結果が真.*eroor.* 2 結果が偽.* エラーコード = [1000 ].* 3 結果が偽.* エラーコード = [2000 ].* 4 結果が偽.* エラーコード = [3000 ].* 5 結果が偽.* エラーコード = [4000 ].* 6 結果が偽.* エラーコード = [5000 ].* 23
Thank you