アクションでの発報の遅延とロスについて
snmptrapの障害発報が遅延する場合とロスする場合がありました。
DBへの書き込みの遅延にて起きているのではないかと考えております。
どのあたりのパフォーマンスをチューニングすれば良いでしょうか。
また、他に遅延、ロスする原因はどのようなものがあるでしょうか。
DB：MySQL
zabbixバージョン：2.4
[アイテム]
タイプ：snmpトラップ
[トリガーの設定]
障害イベントを継続して生成:有効
[アクションの実行条件]
トリガーの値＝障害
[zabbix_server.confの設定]
StartPoollers=10
StartTrappers=10
StartDBSyncers=8
また以下の条件にて検証を実施した結果、以下の状態で発生することを確認
しました。
■ロスする場合
①nodata(30)の条件有りにてeventsテーブルをロック
1.トリガ条件式にnodata(30)をつけた状態にてeventsテーブルを手動にてロックする。
2.100件のテスト用snmptrapを送信する。
3.5分後にeventsテーブルを手動にてロック解除する。
※上記の場合アクションは実行されず、発報されない。
■遅延する場合
①nodata(30)の条件なしにてeventsテーブルをロック
1.トリガ条件式にnotedata(30)をつけた状態にてeventsテーブルを手動にてロックする。
2.100件のテスト用snmptrapを送信する。
3.5分後にeventsテーブルを手動にてロック解除する。
②nodata(30)の条件有りにてalertsテーブルをロック
1.トリガ条件式にnodata(30)をつけた状態にてalertsテーブルを手動にてロックする。
2.100件のテスト用snmptrapを送信する。
3.5分後にalertsテーブルを手動にてロック解除する。
※上記の場合ロック解除後アクションは実行され、遅延して発報される。
★補足事項
検証ではeventsとalertsのclockはeventsはsnmptrapを送信した時間ぐらいになり、
alertsはテーブルロックを解除した時間ぐらいになります。
障害が発生した場合も同様です。
CL - 投稿数: 2
今回質問の内容と検証について説明不足な点がございましたので、補足させていただきます。
下記の過去のスレッドを参考させていただき、仮説を立て、検証を実施させていただいております。
下記スレッドの真ん中ぐらいにあるZabbix-JPの鈴木様の記事を参考にさせていただいております。
http://www.zabbix.jp/node/1041
※内容抜粋
======================================================================
Poller または Trapper（監視実行、またはアクティブ監視データ受信）
・Zabbix Agent から受け取ったヒストリデータをメモリ上へ保存（この時点でヒストリとイベントに記録される「時刻」が決まる）
↓
DBSyncer（メモリからDBへデータ同期）（通常はPoller、Trapperの処理から10秒以内くらい）
・「events」テーブルにイベントを登録（この瞬間にWebのイベント画面からイベントを確認可能）
・アクション実行する場合には「escalations」テーブルへアクション実行情報を登録
↓
Escalator（アクション実行前処理）（通常はDBSyncerの処理から10秒以内くらい）
・「escalations」テーブルの内容を元に「alerts」テーブルへ情報を登録（この瞬間にイベント画面に「進捗中」表示がされる）
↓
Alerter（アクション実行）（zabbix_server.conf の SenderFrequency 秒間隔）
・「alerts」テーブルのアクション実行予定情報を元にアクションを実行（完了した瞬間にイベント画面に「OK」とかの表示がされる）
======================================================================
上記の動作をもとにメモリ上から「events」テーブルに登録が遅延した場合と「alerts」テーブルへ情報の登録が
遅延した場合を再現するために検証を実施しました。
Zabbix DBに負荷をかけてロック状態にすることが難しかったため、今回はMySQL上から
「events」テーブルと「alerts」テーブルをWRITEロックすることにより、障害の疑似状態を実現
しております。