Proxy を経由した IPMI チェックでキューに残り続ける
サーバA
プロキシB
監視対象C
監視対象C 上の IPMI 監視項目を、サーバAにて設定しています
監視には、間にプロキシBが挟まっているため、実際の IPMI チェックは
B 上の IPMIPoller モジュールが実施しているものと思われます
A上にて、Cに対するIPMI監視項目の設定を行い、監視を開始させます
その後、B上にて、zabbix_proxy -R config_cache_reload コマンドを発行すると、
A上の監視キューに、同一の項目が残り続けるようです
これは‥バグでしょうか？
zabbix 2.0.3 (server/proxy/agent とも)
CentOS6 (server/proxy/agent とも)
zabbix はソースコードからコンパイル
TNK - 投稿数: 4769
zabbix_proxy.confのStartIPMIPollersの値は1以上に設定
されていますか？
デフォルトは、StartIPMIPollersが0に設定されているので、
IPMIでの監視ができません。
fripper - 投稿数: 495
TNKさん、リプライありがとうございます。
はい、IPMIPollerの設定値は１にしています
そのアイテムについてヒストリを参照すると、設定した直後から、数日間、合計数回は値がとれた履歴が
あるのですが、あるとき突然更新されなくなっており、以後キューに残り続けていたようです
同じホストに対して、別のIPMIアイテム項目で、正しく値が更新され続けているものも存在しています
滞留してしまっているアイテムを、一旦無効化して、プロキシ側で「zabbix_proxy -R config_cache_reload」コマンドを
発行してみたところ、サーバ上のキュー表示から項目が消えたので、安心していたのですが、
再度、そのアイテムを有効化して、「zabbix_proxy -R config_cache_reload」コマンドを発行してみると、
無効化前のキューのエントリがまた復活し、残り続けているように見えます（キュー遅延時間が３日とかになっている）
IPMIPoller のプロセス数が少なくて、処理遅延が起きているのだとしても、
同プロキシ上、同ターゲットホストの別IPMI項目で正しく値が更新されているものがある、ということ、
数日間のオーダーで値が更新されていないこと、という点を踏まえると、どうも原因がつかめません
TNK - 投稿数: 4769
可能であればDebugLevelをあげて詳細なログを出力させて、キュー
にたまってしまうきっかけを調べられるとよいのですが、可能でし
ょうか？
もしかしたら、タイムアウトが発生していませんか？
タイムアウトが発生したことがきっかけなのであれば、
zabbix_server.conf
zabbix_proxy.conf
のTimeoutの値を伸ばすことで改善するかもしれません。
あと、取得するIPMIの項目が多いのであれば、Pollerの数を増やした
方がよいと思います。
fripper - 投稿数: 495
TNK さん、コメントありがとうございます。
現在、Proxy 側のDebugLevelを上げて、ログ取得を始めました
とんでもない量が出るようなので、読みほどくのは厳しそうですが‥汗
Timeout値については、Server 側、Proxy側ともに「Timeout=30」としており、上限値いっぱいなので、
もう少し様子をみたいと思います
IPMI取得アイテムの数・取得間隔ですが、
アイテム数22個を指定したホストが、同プロキシ上に２台存在しています。
各アイテムが3600secおきに値を取得する設定になっています
よって、プロキシ上での換算ですと、約80秒あたりに１アイテム分の値取得が
実行される計算になります
この監視量で、Poller数１では不足‥となると、増やすしか無いのですが‥、
今ひとつ別の原因があるのでは、と疑いたくなる程度の負荷・監視間隔だと思っています
fripper - 投稿数: 495
取り急ぎ状況報告を。
当該プロキシの LogLevel を上げ、再起動したところ、キューから項目が消えてしまいました
再起動が掛かったため、該当プロキシ上でのキュー状態と、アイテムの更新タイミングがリセットされたのだと想像します
もう一台、同じサーバAからぶら下がる形で、プロキシBと同じ構成のプロキシDがあり、
そちら側も、同じような形で２台のIPMIホストを監視させています。
プロキシDについては、現段階では、ログ設定の変更も、再起動もしていません。
プロキシD側に関するキューは、依然として残ったままとなっています。
プロキシD側の設定も変更して、再起動しようかとも思ったのですが、もう少し、ログと格闘してみます
＃プロキシ側でキューに載った状態で、config_reload するとうまくリロードされないのかな‥
fripper - 投稿数: 495
プロキシBのproxyで、再起動やreloadを繰り返してみました
ログについては、DebugLevel-4 だとあまりに多すぎるため、読みきれず、
サーバ側WebUI上の「キュー状態」と、サーバ側DBの値からの推測ですが‥
通常、server側のDBにて、「値が返ってくるのを待っている状態」のアイテム（すなわち、items.lastcheck+items.delay が現在時刻より以前のもの）が
「キュー」扱いになっているものと見受けられます
proxy 側のコマンドラインからの強制的な reload や、再起動が発生した場合に、proxy はサーバDBから「監視すべきアイテムの情報」を再取得するはずですが、
リストを取ってきた時点で、「items.lastcheck+items.delay が現在時刻より以前のもの」に該当するアイテムについて
正しく Trapper を起動させていないのではないでしょうか？
その結果、Proxy 上のTrapper が値を取得してくることがないので、Server 側ではキューに載ったままに見える‥と。
エージェント（通常）やエージェント（アクティブ）の項目については、特にこのような事象は見られませんでしたが、
複数回 Proxy の reload や再起動をしているうちに、IPMI だけでなく、SNMP 関連のアイテムでも、同事象が発生してしまいました
この状況に当てはまる状況で、Server 側のDBにおいて、直接、以下の書き換えをし、
直後に、proxy 側で config_reload をすると、監視が再開されました
・update items set lastclock = null where itemid = xxx;
として、最終チェック時刻を null 化し、最新のチェックが実施されていないことにする
・update items set lastclock = xxxx where itemid = xxx;
として、最終チェック時刻を現在時刻よりも少し未来の時間として強制的に指定することで、今後の delay 計算を恒常化できるようにする
ソースコードも眺めてみたのですが、Trapper だけでなく、他のアイテム種別でのコードと共用部分が多く、
アイテムの更新タイミング関連の部分を追いきれませんでした‥