例外の更新期間設定について
いつもお世話になってます、広瀬です
掲題の例外更新期間設定に於いて、期待した正常動作をしない為ご質問させていただきます。
Ver:Zabbix 1.8.5
死活監視等どんな監視項目でも良いのですが、通常300秒間隔で監視している項目に対して、
例外更新期間を追加設定しました。
通常更新：300秒
例外更新：3600秒 1-7,07:00-08:00
としました。設定した監視アイテム自体は、AM7時5分以降に落ち、AM7時40分前後には上が
ってくる様になっています。上記の設定は約24項目分、同一設定しています(あ、同一ホスト内
のアイテムです)
ところが、全部が全部ではありませんが、例外更新時間帯に障害通知されてしまうアイテムが
幾つか存在し、毎日微妙に変化するものが内在しているようで、7:30分頃に障害通知されたりと、
期待した動作をしてくれません。
設定に問題があるのか、それ以外の問題があるのか何か情報がありましたら、ご教授頂けると
幸いです。
宜しくお願い致します。
TNK - 投稿数: 4740
監視されている項目が多くて、アイテムの情報取得処理がキューに
溜まってしまっている場合にそのような状況が発生する可能性があ
るかもしれません。
管理 -> キュー
とキューの状態確認画面を開いて10分以上のアイテムがあったりし
ませんか？
キューが溜まってしまっていたとしても、Zabbixサーバの負荷が高
くないのであれば、Pollerの数を増やして、並列でより多くのアイ
テムの情報取得処理を実行するようにすることで改善できるかもし
れません。
もう一つの方法として、メンテナンス期間の設定を活用されてはい
かがでしょうか？
利用されているZabbixのバージョンが1.8.5とのことですので、そ
の発報して欲しくない時間帯をメンテナンス時間として登録して、
アクションのコンディションとして、
メンテナンスの状態 期間外
という条件を追加すれば、特定の時間帯に障害の状態になったとし
ても障害通知を行わないということができます。
ご検討下さい。
wakaba - 投稿数: 228
お世話になっております、広瀬です
ご返答ありがとうございます。
この点、確かに監視対象のサーバ機器が200台を超えており、既に登録アイテム数が
1万近い状態になっているので、負荷やキュー滞留が発生しても可笑しくはない程ある
と思います。
ただ、この点に関しては極力高負荷にならないように十分配慮したアイテム登録にして
いるので、現状では1秒間に36〜40アイテムの処理率に落ち着かせて居る事と、DBは
ZABBIX Serverとは別の筐体にしており、DB自体はかなりチューニングしているので、
相当数のアイテムのヒストリーデータを大量消去などをしない限りは高負荷には陥らない
ようにしているつもりです。
こちらも併せて実験していますが、多分例外更新期間の設定と被った関係だろうと思い
ますが、AM8時を回ると幾つかポロポロと異常通知されてしまう状態です(監視している
対象のプロセス自体は既にこの時には正常起動しているのは明白なのですが、何故か
異常が先に出てくる…)
例外更新期間を全削除して、メンテナンスのみだけで設定して確認してみたいと思います。
明日の朝には結果が出るかと思います。
※メンテナンス機能は対象がホスト単位と、幅が大きいのでアイテム単位でなんとかやり
繰りしてみたかったというのが、本音です。
以上です。宜しくお願い致します。
TNK - 投稿数: 4740
Zabbixサーバの負荷が高くなくても、値取得に時間がかかるような
アイテムがある場合もキューに溜まりやすくなります。
例えば、Zabbixエージェントが標準で対応しているアイテムだけで
はなく、スクリプトなどをエージェント側で実行してその結果を取
得するようなものは利用されていませんか？
負荷が高くないがキューに溜まってしまっているような場合は、
Pollerの数を増やすことで、アイテムの値取得処理を並列で複数同
時に実行できるようにして、より短時間でアイテムの取得処理を終
了できるようにすることができます。
デフォルトでは、通常のアイテムの値取得用のPollerの数が5に設
定されています。
また、Web監視など役割によっては別のPollerになっていますので、
溜まってしまっているキューに合わせて対応するPollerの数を調整
して下さい。
キューに溜まっていないのであれば別の原因かもしれませんが、ま
ずは、可能性として高いと思われるのでご確認をお願い致します。
kodai - 投稿数: 1341
Zabbixの内部の仕様的に「どの時刻に監視を実施する」かを決め内することはできないため、基本的に、例外の更新間隔の設定では「この時間は監視をしない」という使い方はできないと思っていただいた方が良いと思います。
そのような設定をされたい場合はメンテナンスの設定を利用いただくと確実に特定の期間の障害を停止することができます。
wakaba - 投稿数: 228
お世話になっております、広瀬です
なるほど。確かにアイテム毎にバラバラな監視タイミングもっていますから、当然のことですよね。
先にも書いたとおり、メンテナンス機能自体の抑止範囲がホスト単位と広範囲なのが少し痛いの
ですが、今後のZABBIXに期待したいと思います。
助言頂き、助かります。
wakaba - 投稿数: 228
ご返答遅くなりました、広瀬です
細やかなご指摘頂き、大変助かります。
確かにご指摘の通り、監視項目自体は通常のエージェントが賄える範囲では無い為、
UserParameterを併用しています。ただ、UserParameterで利用している項目は、
MySQL監視のテンプレにあるmysqladmin pingや、echoでsql文を食わせ、スレ
ーブステータスの状態確認のみです。
少し話逸れてしまいますが、通常アイテムの値取得用のPollerのデフォルト値が５と言う
ことですが、例えばこれは通常のアイテム取得がどの程度の個数可能な値なのでしょうか？
■事例
CPU全体：4項目(sys/user/idle/wait)
CPU4コア数分：4項目(同上)
ロードアベレージ：3項目
メモリ：6項目(total/user/free/available/cache/buffer)
ディスク：5項目(total/used/free/pused/pfree)
SWAP：5項目(total/used/free/pused/pfree)
ネットワーク：6項目(eth0/eth1/bond0の送受信Traffic)
死活監視：3項目(ICMP ping/TCP ping/ICMP response)
合計：48項目
上記のアイテムを登録した場合として、取得間隔は以下
・SWAP/ディスク、メモリのtotalは3600秒毎
・上記以外は全て300秒毎
・ネットワークは差分/時間
※高負荷状態なサーバで無い事を前提として…とします。
あまり、Pollerまわりを意識しては居なかったので、今後はその辺も含めて見て見るようにします。
尚、当初のご質問させて頂いた例外更新期間を辞め、メンテナンス機能に切り替えた結果、
初日はAM8時になっても落ちていたSQLスレーブステータスの検知が出来ました。
翌日は無検知で、全て正常であることを確認できました。
以上です。宜しくお願いいたします。
TNK - 投稿数: 4740
それぞれのアイテムの値取得にどれだけ時間がかかるかにも依存し
ます。
単純にアイテムの数だけではなく、それぞれの処理かかる時間も考
慮しなければ、単位時間当たりに処理できるアイテム数は想定でき
ません。
また、Zabbixエージェント側の処理待ちではなく、Zabbixサーバ側
の処理負荷が上がってくると、Zabbixサーバ用のサーバ機器の性能
も影響してきます。
極端な話になってしまいますが、全てのアイテムで値の取得に1秒
かかってしまうような状況であった場合、1つのPollerで1秒間に1
アイテム分しか処理できませんので、5つPollerが動いていても1秒
間に5アイテム分しか処理できまないでしょう。
しかも、ほとんどがZabbixエージェントでの処理を待つだけなので、
Zabbixサーバ自体の負荷は上がりません。
このような状況が発生していないかは、繰り返しになりますが、
キューに溜まっていないかをご確認下さい。
Zabbixサーバ自体の負荷が高くないのに、キューに溜まってしまう
ような場合は、Pollerの数を増やすことで対応できる場合がありま
す。