ネットワーク機器のSNMP監視(アラートメール)について
お世話になっております。
CentOS5.3にZABBIX1.6.8をインストールしております。
ネットワーク機器のSNMPトラップ発生時のアラートの設定についてご教授願います。
?SNMPのログから link という文字列がある場合、
ログ情報を取得するトリガー作成
アラートメールのアクションを実行
アラートメール タイトル トリガー名 (linkUP/DOWN検知)
※LINK UP DOWN の監視目的
?SNMPのログから power-on という文字列がある場合、
ログ情報を取得するトリガー作成
アラートメールのアクションを実行
アラートメール タイトル トリガー名 (coldstart検知)
※COLD START の監視目的
と??の設定をしているのですが、
検証として、ネットワーク機器をrestartを行なった際の
ヒストリー情報では、以下のように表示されます。
=======================================================
タイムスタンプ 値
?[2010.Feb.23 21:05:06]
IPアドレス : [xxx.xxx.xxx.xxx]
対象インターフェイス :FastEthernet0/19
状態 :linkUp
?[2010.Feb.23 21:05:06]
IPアドレス : [xxx.xxx.xxx.xxx]
対象インターフェイス :FastEthernet0/1
状態 :linkUp
?[2010.Feb.23 21:05:06]
IPアドレス : [xxx.xxx.xxx.xxx]
対象インターフェイス :Vlan1
状態 :linkUp
?[2010.Feb.23 21:05:06]
IPアドレス : [xxx.xxx.xxx.xxx]
対象インターフェイス :"power-on"
状態 :coldStart
?[2010.Feb.23 21:02:25]
IPアドレス : [xxx.xxx.xxx.xxx]
対象インターフェイス :"power-on"
状態 :enterprises.9.0.0
=======================================================
しかし、実際に届くアラートメールですが、
タイムスタンプの若い順に実際メールは行なわれているのですが、
?のメール タイトルと本文共に正常
?〜? 実際restart後 のメールは
タイトルは正常にトリガー名ですが、
本文は全て最終の?のログ情報になってしまいます。
気になる点は、restart後ですので、ログ時刻が同じです。
ヒストリー?のメールが、以下の内容で飛んできます。
=======================================================
メールタイトル coldstart検知
本文
IPアドレス : [xxx.xxx.xxx.xxx]
対象インターフェイス :FastEthernet0/19
状態 :linkUp
=======================================================
トリガーの内容ですが、以下になっております。
coldstart検知用
条件式 : {HOSTNAME:snmptraps.str(power-on)}=1
イベント生成 :ノーマル+障害イベントを継続して生成 を選択
linkUP/DOWN検知用
条件式 : {HOSTNAME:snmptraps.str(link)}=1
イベント生成 :ノーマル+障害イベントを継続して生成 を選択
ただ、ヒストリー情報は正常に取得されております。
ヒストリーの情報と同じ内容のメールが届くには、どうしたら良いのかご教授願います。
KAZ - 投稿数: 1085
MOSAさん
すいませんが、アクションに設定している情報も教えて頂けますか?
MOSA - 投稿数: 10
KAZ様
お世話になっております。
============================================================
>すいませんが、アクションに設定している情報も教えて頂けますか?
============================================================
以下に記載させて頂きます。
============================================================
■アイテムの設定情報■
名前 TRAP-Check
タイプ ZABBIXトラッパー
キー snmptraps
データ型 ログ
ヒストリの保存期間(日) 90
ステータス 有効
ログの時間の形式
許可されたホスト
アプリケーションの作成
アプリケーション -なし-
============================================================
============================================================
■アクションの設定情報■
名前 SNMPTRAP
イベントソース トリガー
エスカレーションを有効 チェックなし
デフォルトの件名
[ZABBIX:Alarm] {HOSTNAME} - {TRIGGER.NAME}: {STATUS}
デフォルトのメッセージ
発生日時 :{DATE} - {TIME}
{ITEM.LASTVALUE}
リカバリメッセージ チェックなし
ステータス 有効
アクションの状態
計算のタイプ OR (A or B)
コンディション (A)トリガー= Coldstart用
(B)トリガー= linkUP/Down用
============================================================
ご確認の程、何卒、宜しくお願いいたします。
KAZ - 投稿数: 1085
MOSAさん
検証してみました。
バグですね。A(^^;
多分、指摘通り検知時間が一緒だとその一番最後の情報を出力するみたいです。(まだソースを追ってないので詳細は不明)
このバグが直せるかソースを見てみます。
が、結構厳しそうな気配がします…
MOSA - 投稿数: 10
KAZ様
お世話になっております。
ご連絡ありがとうございます。
検証の程、宜しくお願いいたします。
KAZ - 投稿数: 1085
MOSAさん
ソースを追っかけてみました。
アクションの動作ですが、メール投げる時点の最新の値を設定するようになっていました。(テーブル構成からしてそういう作りになってました。)
バグと言うよりは「仕様上の制限」と言う感じです。
確かに{ITEM.LASTVALUE} = 最新値なわけですから…
現時点でこの動きを回収するのはかなり厳しいです。
すいません。m(__)m
MOSA - 投稿数: 10
KAZ様
お世話になっております。
迅速な調査とご連絡、真にありがとうございます。
ZABBIXでのSNMPによるネットワーク機器の監視に関しまして、
使用上の制限とのことですので、今回の設定{ITEM.LASTVALUE}による
ログ情報からのアラートメールを送信する方法は見直させて頂きます。
{ITEM.LASTVALUE} = 最新値なんですね。
修正されるのを期待させて頂きます。
お手数をおかけしますが、別の方法にてネットワーク機器のCOLDSTART時の検知と
リンクアップ・ダウンを取得し、アラートメールの発行を行なう設定方法がございましたら、
ご教授の程、何卒、宜しくお願い致します。
KAZ - 投稿数: 1085
MOSAさん
下記のみでcoldstartと判断しては不味いでしょうか?
MOSA - 投稿数: 10
KAZ様
お世話になっております。
ご連絡ありがとうございます。
今回の件にて、ネットワーク機器などのrestartの場合、SNMPのトラップ情報としてcoldstart→各インターフェイスのUPですので、
同時刻のトラップということでは、各インターフェイスのUP情報が最新情報になることはKAZ様の調査結果にてわかりました。
目視により判断だけではなく、restart時のlinkup/down coldstart 等 ZABBIXでのアラートメールの配信方法が、別のマクロで実現可能等ございましたら、ご教授願います。
また、この件ですが、ZABBIXのVer1.8.1ではどうなのでしょうか?
ご確認の程、宜しくお願いいたします。
KAZ - 投稿数: 1085
MOSAさん
えーっと、書き方が悪かったかも知れません。
「coldstart 」のキーワードのみをzabbix監視してはダメですか?と言う意味でした。
要するに事象の発生わかるユニークなキーワードだけで確認だけをすると言う方向性はどうでしょうかと…A(^^;
詳細は後でゆっくりsnmptrapのログを見ると…
逃げでしょうか…A(^^;
別スレで話に上がりましたが、「{ITEM.LASTVALUE} = 最新値」です。
ちなみに、役に立たないかもしれませんが一個前の値なら下記で見れるかもしれません。
{{HOSTNAME}:{TRIGGER.KEY}.prev(0)}
昔は「{ITEM.LASTVALUE}」などなかったので下記で見てました。
{{HOSTNAME}:{TRIGGER.KEY}.last(0)}
※:〜last(0)は1.6.8-1で動いてます。
MOSA - 投稿数: 10
KAZ様
ご連絡ありがとうございます。
==================================================================
えーっと、書き方が悪かったかも知れません。
「coldstart 」のキーワードのみをzabbix監視してはダメですか?と言う意味でした。
要するに事象の発生わかるユニークなキーワードだけで確認だけをすると言う方向性はどうでしょうかと…A(^^;
詳細は後でゆっくりsnmptrapのログを見ると…
逃げでしょうか…A(^^;
==================================================================
やはり、そうなりますか。了解いたしました。
ありがとうございました。
kodai - 投稿数: 1341
こんにちは。すっかり乗り遅れました。
以前調べたときにはZabbix 1.6系のアクションの実行とマクロの展開は以下のようになっていたと思います。(テーブル名はうろ覚えなので正確な名前ではないかもしれません)
1. トリガーで障害として検知 -> イベント生成
2. escalationテーブルに情報を保存
3. 3秒おき(固定値)にactionテーブルに保存しなおす (エスカレーションの機能の実現のため)
4. zabbix_server.confのSenderFrequency(デフォルト30秒)ごとにactionに保存されたイベントのマクロを展開してメール送信
ようするに、標準の設定ではイベントの生成からマクロの展開までに30秒近く間があくわけですが、{ITEM.LASTVALUE}マクロは最後のアクションの実行時点での最新のアイテムデータを利用するので、ログやトラップのように1度に複数行を受信する場合はエラー行とは異なるデータがアクションに利用されてしまうことが多いです。
1.8系はまだ試していないのですが、アクションに{ITEM.VALUE}マクロを利用できるようになっていて、マニュアルには以下のような記載があります。
これがアクション実行時にはどのような動きをするかに期待しているのですが...
KAZ - 投稿数: 1085
MOSAさん、kodaiさん
{ITEM.VALUE}ですか、{ITEM.LASTVALUE}で調べていたので見落としました…A(^^;
調査しなおします。
と言っても、本日はOSC 2010 tokyoなので来週からですが…A(^^;
MOSA - 投稿数: 10
kodai様 KAZ 様
ご連絡ありがとうございます。
{ITEM.VALUE}ですか、また、試させていただきますね。
ご連絡ありがとうございます。
また、別件にて、質問事項がございますので、別スレも作らせていただきます。
その際も、ご教授の程、宜しくお願いいたします。
KAZ - 投稿数: 1085
MOSAさん
kodaiさん
※:一部、漢字変換ミスがあったので訂正しました。 3/1 17:57
ざっくりと{ITEM.VALUE}の関連部分のソースを見てみました。
下記の部分です。
<code>
switch (value_type) {
case ITEM_VALUE_TYPE_FLOAT: table = "history"; break;
case ITEM_VALUE_TYPE_UINT64: table = "history_uint"; break;
case ITEM_VALUE_TYPE_TEXT: table = "history_text"; break;
case ITEM_VALUE_TYPE_STR: table = "history_str"; break;
case ITEM_VALUE_TYPE_LOG:
default: table = "history_log"; break;
}
zbx_snprintf(tmp, sizeof(tmp), "select value from %s where itemid=%s and clock<=%d order by itemid,clock desc",
table, row[0], clock);
</code>
これだと確かに検知した時の情報が取れますが、検知した時間が同じ場合、一番最新の値が取れます…
時間指定じゃなくて、historyに保存した時のIDじゃないと意味がないんですよね…
Zabbixのテーブル構成や作り上、トリガーが検知した時のhistoryのIDをキーにしない限り検知した情報は取得できないんですよ…
下記、1.8.1環境でソース通りにSQLを実行してみました。
いっぱい出るので2件に絞ってます。 (limit 0,2)
実際はこれの上の行が{ITEM.VALUE}で取得されることになります。
<code>
mysql> select * from history_log where itemid=19451 and clock<=1266990230 order by itemid,clock desc limit 0,2;
+------+--------+------------+------------+-------------------------+----------+--------------------------------------------------------------+------------+
| id | itemid | clock | timestamp | source | severity | value | logeventid |
+------+--------+------------+------------+-------------------------+----------+--------------------------------------------------------------+------------+
| 3076 | 19451 | 1266990230 | 1266988957 | Service Control Manager | 1 | Google Software Updater サービスは、停止 状態に入りました。 | 7036 |
| 3075 | 19451 | 1266990230 | 1266988897 | Service Control Manager | 1 | Google Software Updater サービスは、実行中 状態に入りました。| 7036 |
+------+--------+------------+------------+-------------------------+----------+--------------------------------------------------------------+------------+
2 rows in set (0.00 sec)
</code>
MOSA - 投稿数: 10
KAZ様
とてもわかりやすい{ITEM.VALUE}での動作検証のご連絡ありがとうございます。
知識不足の為、現状では、同時刻の複数情報検知時のキーとなるidを元としての
log情報取得の条件式(テンプレートとして使用可能なトリガー)が、思いつきません。
なかなか、難しいですね。
実現可能なトリガーが、思いつきましたら、ご教授の程、宜しくお願いいたします。
KAZ様・kodai様
色々とお調べ頂きまして、真にありがとうございます。
kodai - 投稿数: 1341
だめでしたか...。
この問題、トリガーで何とかするというよりは、Zabbix SIAに報告してロジックを修正してもらった方が良いだろうと思ってますので、時間が取れたらやってみようと思います。
KAZ - 投稿数: 1085
kodaiさん
この処理を見た感じでは無理な感じではないんですよ。
時間があれば修正できそうなんですが…
テーブルのカラムを追加して時刻を保持するんじゃなく、historyのid保持すれ良いので。