Zabbix-Serverが死んだ際の、"監視の取りこぼし"について

当方のZabbix-Server環境は、
・Web2台(PacemakerでActive-Standby。障害時は自動切替)
・DB2台 (MySQLでMaster-Slave。障害時は手動切替)
となっております。

ここで、WebのActive側に障害が発生した際の"監視の取りこぼし"を気にしています。
自動切替が完了するまで、Zabbix-Server発信の監視が取得できないことは仕方がないのですが、
例えば以下の監視はどのような扱いになるのでしょうか?

1.ActiveCheck(syslog監視)
2.SNMPtrap

もしとりこぼしが発生するのであれば、皆さんはどのようにそれを対処しているのでしょうか?
(何かしらの機能でキューイングが可能とか、もしくは潔く諦めているか等)

他にも気にしたほうがよい点等あればご教授いただけると助かります。
以上、よろしくお願い致します。

コメント表示オプション

お好みのコメント表示方法を選び「設定の保存」をクリックすると変更が反映されます。
ユーザー TNK の写真

1.ActiveCheck(syslog監視)

短時間であれば、Zabbixエージェント側のメモリ上で保持されて
いるので、再度接続されたらメモリ上で保持されていたものが送
られるので欠損しないはずです。

2.SNMPtrap

UDPでパケットが投げられるだけなので、受け取るサーバが受け取
れなければ、その情報は欠損することになります。

Zabbixサーバに問題が発生していなくても、UDPだと他の様々な要
因で欠損する可能性があるので、可能であれば、トラップ以外の方
法でも状態を把握して2重に監視しておくことも検討されてはいか
がでしょうか?

可能かどうかわかりませんが、2台のZabbixサーバで監視を行うよ
うにして、両方のサーバにトラップも送るように設定できれば、両
方のZabbixサーバが同時に停止してしまわない限り、どちらかのサ
ーバでデータを取得して欠損を防ぐことはできると思います。

ユーザー tomozo6 の写真

TNKさん

返信していただきありがとうございます。

1.ActiveCheck(syslog監視)

短時間であれば、Zabbixエージェント側のメモリ上で保持されて
いるので、再度接続されたらメモリ上で保持されていたものが送
られるので欠損しないはずです。

どのぐらいのメモリが確保されているのでしょうか?
また再送の仕組みなどもご存知であれば教えていただきたいです。
例えば何秒かおきに最大何回まで再送を試みるて諦めて捨てるのかなど。
またその値はconfファイルで変えられるものなのでしょうか?

2.SNMPtrap

UDPでパケットが投げられるだけなので、受け取るサーバが受け取
れなければ、その情報は欠損することになります。
確かにUDPなので欠損する可能性はありますね…。
Zabbix発信のSNMP監視も追加するよう検討します。

可能かどうかわかりませんが、2台のZabbixサーバで監視を行うよ
うにして、両方のサーバにトラップも送るように設定できれば、両
方のZabbixサーバが同時に停止してしまわない限り、どちらかのサ
ーバでデータを取得して欠損を防ぐことはできると思います。

その方法であれば、少なくとも後から追うことはできそうです!
その方針で検討しようと思います。ありがとうございます。

ユーザー KAZ の写真

tomozo6さん

どのぐらいのメモリが確保されているのでしょうか?
また再送の仕組みなどもご存知であれば教えていただきたいです。
例えば何秒かおきに最大何回まで再送を試みるて諦めて捨てるのかなど。
またその値はconfファイルで変えられるものなのでしょうか?

confファイルで変えられます。

zabbix_agentd.confの設定で関連するのは下記ですかね?
BufferSend … 送信間隔(秒数)
BufferSize … 送信バッファ(件数:ログ監視は1行1件)

BufferSizeが保持するバッファサイズになります。
BufferSendの時間が経過するかBufferSize÷2の量のデータが溜まったら送信します。

BufferSizeの件数をオーバーしたら捨てられます。

なので、BufferSizeを大きくすると保持件数が大きくなります。

ログは最大で1件(1行)64KB使用できます。(固定ではなく可変でメモリを確保します。)
ありえないと思いますが、計算上の最大値はMax4GBになりますので注意してください。

ユーザー tomozo6 の写真

KAZさん

返信していただきありがとうございます。

なるほど!「BufferSend」「BufferSize」
コントロールできそうですね。

BufferSendについて少し質問なのですが、
私の環境では「BufferSend」がデフォルトの5、とあるアイテム(アクティブ)の更新間隔が60秒となっています。
確認したところ、実際にデータが送られるのは60秒毎のようでした。

アイテム(アクティブ)に関して言えば、「BufferSend」の設定は生きていないように思えるのですが、
「BufferSend」はなにに使用されているのかご存知でしょうか。

以上、よろしくお願い致します。

ユーザー TNK の写真

アイテムのデータの送信間隔は、アイテムの設定に依存します。

BufferSendは、送信できなかったときにどれだけの時間保持して
置くかであったと思いますので、例えば、通常は1分間隔で送って
いて、接続できなくなった時に、その状態が5分以上経過したら、
古いデータは削除してしまうようにするときに利用したと思います。

----- 追記(2015/09/12 0:00) -----
私の回答は正確ではなかったようです。

ソースを見て確認してみていますが、Zabbixエージェントから
Zabbixサーバに送信しようとしたときに、Zabbixエージェント側
のキューに溜まっていなければ先に回答させていただいた通り、
アイテムに設定した間隔で送ろうとします。

アクティブなアイテムの個数が多かったり、ログ監視で取得され
たデータが大量であった場合は、Zabbixサーバ側に送るデータ
が送るタイミングで1度に送るデータの数が設定で制限されている
ため、それを超える個数のアイテムのデータを1度にZabbixサーバ
に送ることができず、Zabbixエージェント側のキュー(バッファ)
に保存され、BufferSendで指定した時間間隔でリトライが行われる
ようです。

キューに溜まらなければ、それぞれのアイテムで設定された間隔で
値の取得とZabbixサーバへの送信が行われます。

ユーザー KAZ の写真

tomozo6さん

更新間隔が60秒のアクティブ監視1つだけだと、
60秒単位で情報が収集されます。

データが無い場合はZabbixエージェントは送信しないのでBufferSendが5秒でも送信されません。

ユーザー tomozo6 の写真

TNKさん KAZさん

返信していただきありがとうございます。

なるほど、「BufferSend」はそのような意味だったのですね。
理解できました。ありがとうございました!

ユーザー tomozo6 の写真

すいません…追加で質問をさせていただけないでしょうか。

Zabbix-Serverが死んだときの状況は理解できたのですが、
Zabbix-Serverのプロセスが生きていて、DB(MySQL)が死んでいた場合、
その間収集したアイテムの情報等は、どこかにキューイングされてくれるのでしょうか?

お手数ですがご教授いただけると助かります。
以上、よろしくお願い致します。

ユーザー TNK の写真

短時間であれば、Zabbixサーバプロセス上のキャッシュに保持されると
思います。

ユーザー tomozo6 の写真

TNKさん

返信していただきありがとうございます。

なるほど、Agentのように明確にはキューイングしてくれないんですかね。
それに関するパラメータもconfになさそうなので、実際どのような動きをするか
MySQLを落としてテストしようかと思います。

以上、よろしくお願い致します。

ユーザー heya の写真

横からですが、zabbix_server.conf には CacheSize とか HistoryCacheSize といったような ~CacheSize という項目があります。
細かい挙動は知らないのですが、その辺りも変えながらテストしてみるといいかと思います。
https://www.zabbix.com/documentation/2.2/jp/manual/appendix/config/zabbi...

ユーザー KAZ の写真

tomozo6さん

取得した値を保持するのはhistory(履歴)キャッシュになります。
pollerプロセスやtrapperプロセスから取得したデータをhistory syncerプロセスが受け取ってDBに保存するまでの間、履歴キャッシュに保存します。
で、定期的にDBに更新をかけます。

その他キャッシュですが…
config(設定)キャッシュは各種設定情報の保持に使用します。
Value(値)キャッシュはトリガーの評価に使用します。
VMwareキャッシュはVMwareから取得した情報を展開するキャッシュでZabbixのpollerプロセスがここからデータを取得します。

履歴キャッシュには履歴キャッシュとテキスト履歴キャッシュの2つがあって、
履歴キャッシュには取得したデータのタイプとかアイテム情報も持ってます。

監視タイプがログ・文字列・テキストの場合、取得した文字情報のみテキスト履歴キャッシュに持ちます。
※:その場合もデータのタイプ等のアイテム情報は履歴キャッシュに持ちます。

DB更新時は履歴キャッシュの整合性を保つために履歴キャッシュに排他ロックがかかります。
また、DBがダウンしているとZabbixは基本は再接続を繰り返します。
なので、DB障害時は更新時に接続エラーでリトライ続ける間は履歴キャッシュに排他ロックがかかってデータ自体が受け取り不可になるかと…A(^^;
推測なので何とも言えませんが、更新間隔は一定期間あるので、DB更新に行くまでは溜めこまれると思います。

尚、history syncerプロセスのビジー率100%とかになるとデータの取りこぼしが発生する話を何件か耳にしています。

ユーザー tomozo6 の写真

heyaさん KAZさん

返信していただきありがとうございます。

お二人にいただいた情報を元にテストをしてみましたところ、
結論から言うとうまくいきました。
(もしかしたら多少取りこぼしはしているのかもしれません)

テストは単純に、Zabbixで使用しているMySQLをshutdownさせました。
1時間程放置し、その後MySQLを起動させました。

【MySQL起動後にZabbixのグラフ等をみてわかったこと】
・アイテムの収集データについて、わりとすぐにMySQLに反映してくれた
・任意のホストの任意のアイテム(更新間隔30秒)についてグラフを見る限り、取りこぼしはなさそうに見えた
・history syncerプロセスは、MySQLをshutdownさせてからすぐにビジー率が100%になりそのままはりついていた。
・MySQLをダウンさせている間、history write cacheはじわじわ減っている

history write cacheを食い潰させるまでのテストは実施しなかったのですが、
一旦これで期待通りの動きをしてくれそうということがわかりました。

いろいろアドバイスいただきありがとうございました。
以上、よろしくお願い致します。