housekeeperの初回起動でクラッシュする

2015/03/11 - 17:03 (水) yamato3000 - 投稿数: 7

日本Zabbixユーザー会フォーラム

はじめて質問させていただきます。
どうぞよろしくお願い致します。

Zabbix server2.4.3をyumでインストールし、運用しようとしているのですが、
Zabbix serverの起動から30分後(housekeeper起動のタイミング)でZabbix serverが
クラッシュして停止してしまいます。
手動で何度起動しなおしても、30分後に停止します。

こちら対処方法がわからず、お力を貸していただきたいです。
よろしくお願い致します。

■OS
CentOS release 6.6 (Final)

■zabbix
Zabbix server v2.4.3 (revision 51175) (15 December 2014)

■zabbix_server.log
添付いたしました。

■試したこと(いずれも効果なし)
housekeeperの無効化
Zabbix server v2.4.4 (revision 52341)へアップグレード
yum update(全パッケージ)
全ての監視(ホスト)を無効化

zabbix_server_log.txt (31.28 KB)

ログイン（登録）してコメントを投稿

2015/03/11 - 17:35 (水)
TNK - 投稿数: 4740

zabbix_server.confのデフォルトから変更した箇所をお教えくださ
い。

もしかしたら、監視する規模に対してキャッシュのサイズが不足し
ている可能性も考えられますので、可能であれば、Zabbixサーバに
対して、

　Template App Zabbix Server

のテンプレートを適用して、各種キャッシュの利用状況を確認して
みてください。

ログイン（登録）してコメントを投稿

2015/03/11 - 21:20 (水)
yamato3000 - 投稿数: 7

早々にご返答いただき、ありがとうございます！

zabbix_server.confにつきましては、VMwareCacheSize,CacheSize,HistoryCacheSize,
TrendCacheSizeを64Mや1Gに変更してみております。

また、各種キャッシュの利用状況を見てみましたが、全て99%以上freeとなっており、
特に問題は無いように思えます。

ログイン（登録）してコメントを投稿

2015/03/12 - 15:01 (木)
TNK - 投稿数: 4740

zabbix_server.confにつきましては、VMwareCacheSize,CacheSize,HistoryCacheSize,
TrendCacheSizeを64Mや1Gに変更してみております。

トータルでどのくらいのサイズを指定されていますか？

そのサイズは、MySQLサーバも同居させているのであれば、MySQLに
割り当てたメモリサイズも考慮して、稼働させているサーバの物理
的なメモリサイズやkernelで確保している共有メモリのサイズを超
過してしまっていたりしませんか？

あと、変更されたのは、記載頂いたキャッシュサイズのみですか？

ログからは、恐らくStartVMwareCollectorsなどのプロセス数も変
更されていることが推測されるのですが、変更されているのではあ
りませんか？
変更されているのであれば、変更されている箇所とその値をお教え
ください。

あと、可能であれば監視対象の規模もお教え頂けないでしょうか？

起動するプロセス数が多かったり、監視対象の規模が大きい場合、
共有メモリなどのリソースが不足して、エラーログも出力せずに異
常終了してしまう場合があるということを聞いたことがあります。
そのような場合は、各キャッシュのサイズを抑えたり、カーネルの
パラメータの調整が必要となるかもしれません。

ログイン（登録）してコメントを投稿

2015/03/13 - 12:19 (金)
yamato3000 - 投稿数: 7

現状の設定はこんな感じです。

VMwareCacheSize=64M
CacheSize=64M
HistoryCacheSize=64M
TrendCacheSize=64M
HistoryTextCacheSize=64M
ValueCacheSize=64M

サーバのメモリは16GBです。
my.cnfは添付のような内容です。

他のパラメータについては、以下を変更しています。
(StartVMwareCollectorsは変更していません)

StartPollersUnreachable=10
StartPingers=5

監視対象の規模につきまして、現状59台のホストを登録しています。

mycnf.txt (1.92 KB)

ログイン（登録）してコメントを投稿

2015/03/13 - 15:31 (金)
KAZ - 投稿数: 1085

yamato3000さん

再現性のあるクラッシュなら
zabbix_server.confのDebugLevel=4にして、
クラッシュ時のログをとってみてはどうでしょう？

クラッシュダンプのログが出力されるはずです。

ログイン（登録）してコメントを投稿

2015/03/16 - 13:26 (月)
yamato3000 - 投稿数: 7

KAZさん

DebugLevel=4でログを取ってみました(添付しました)。

In check_vcenter_vm_vfs_dev_read()のところで落ちてる感じでしょうか・・・

zabbix_server-log_20150316.txt (67.31 KB)

ログイン（登録）してコメントを投稿

2015/03/16 - 15:24 (月)
KAZ - 投稿数: 1085

yamato3000さん

housekeeperプロセスのcheck_vcenter_vm_vfs_dev_discoveryで落ちてますね…

 41271:20150316:105032.760 === Backtrace: ===
 41271:20150316:105032.762 12: zabbix_server: housekeeper [removing old history and trends](print_fatal_info+0x280) [0x468940]
 41271:20150316:105032.762 11: zabbix_server: housekeeper [removing old history and trends]() [0x46905c]
 41271:20150316:105032.762 10: /lib64/libc.so.6() [0x3259e326a0]
 41271:20150316:105032.762 9: zabbix_server: housekeeper [removing old history and trends](check_vcenter_vm_vfs_dev_read+0x60) [0x42bb70]
 41271:20150316:105032.762 8: zabbix_server: housekeeper [removing old history and trends](zbx_hashset_search+0x14) [0x4653f4]
 41271:20150316:105032.762 7: zabbix_server: housekeeper [removing old history and trends]() [0x430a29]
 41271:20150316:105032.762 6: zabbix_server: housekeeper [removing old history and trends](housekeeper_thread+0x39a) [0x430fea]
 41271:20150316:105032.762 5: zabbix_server: housekeeper [removing old history and trends](zbx_thread_start+0x64) [0x469504]
 41271:20150316:105032.762 4: zabbix_server: housekeeper [removing old history and trends](MAIN_ZABBIX_ENTRY+0x3de) [0x418a9e]
 41271:20150316:105032.762 3: zabbix_server: housekeeper [removing old history and trends](daemon_start+0x1a1) [0x467931]
 41271:20150316:105032.762 2: zabbix_server: housekeeper [removing old history and trends](main+0x2d3) [0x419103]
 41271:20150316:105032.762 1: /lib64/libc.so.6(__libc_start_main+0xfd) [0x3259e1ed5d]
 41271:20150316:105032.762 0: zabbix_server: housekeeper [removing old history and trends]() [0x413839]

2.4系からhousekeeper プロセスの初回動作が起動後30分以降に変更されているので、事象から見て間違いないでしょう。
VMware監視の設定でおかしなところがあるかもしれません。
取り敢えず、[管理]-[一般設定]-[データの保存期間設定]を開いて「データの削除処理を有効」のチェックを外して逃げられませんかね？

ログイン（登録）してコメントを投稿

2015/03/16 - 16:33 (月)
yamato3000 - 投稿数: 7

KAZさん

「データの削除処理を有効」のチェックを全て外しても同じ現象となります。
(housekeeperが起動してクラッシュする)

VMwareの監視も特に設定した記憶は無いのですが、、、
(StartVMwareCollectors=0ですし)

他に何か確認すべきところ等ありますでしょうか？

ログイン（登録）してコメントを投稿

2015/03/16 - 17:03 (月)
KAZ - 投稿数: 1085

う〜ん、難しいですね…

確かにチェック外してもhousekeeperプロセスは起動してしまうので…
今のところZabbixSIAのJIRAではまだこの報告ないんですよね…

クラッシュダンプとれているので、JIRAにバグ報告するのが早いかもしれません…

ログイン（登録）してコメントを投稿

2015/03/16 - 17:51 (月)
zinten - 投稿数: 69

KAZさん

素朴な疑問なのですがさっと見た限りだと「check_vcenter_vm_vfs_dev_discovery()」って
housekeeperプロセスで呼ばれない気がするのですが…
何かパッケージに問題があるとかないですか？

ログイン（登録）してコメントを投稿

2015/03/16 - 19:47 (月)
TNK - 投稿数: 4740

私もcheck_vcenter_vm_vfs_dev_discovery()が呼び出されるのがお
かしいと思って、zabbix_server.confの設定内容を再度確認させて
頂いたのですが、先ほど頂いた回答にもStartVMwareCollectors=0
とのことですので、問題個所が特定できていない状態です。

パッケージに関しては、私が検証用に起動している複数の環境上で
2.4.2、2.4.3、2.4.4など稼働させていましたが、今回のような現
象は一切発生していません。

再度、質問内に64bit版であることは明記されていませんが、ログ
から判断してCentOS 6.6(x86_64)の環境を新規に構築し、Zabbix
SIAのリポジトリを利用して、Zabbix 2.4.3の環境をDB作成を含め
新規作成してみましたが、housekeeperの処理は問題なく処理を行
って継続して動作できています。

ですので、これまでの構築経験と今回改めて確認した限り、パッケ
ージには問題が無いと思われます。

ちなみに、zabbix_server.confには、以下の設定を反映してありま
す。

VMwareCacheSize=64M
CacheSize=64M
HistoryCacheSize=64M
TrendCacheSize=64M
HistoryTextCacheSize=64M
ValueCacheSize=64M
StartPollersUnreachable=10
StartPingers=5

あと、異なるとしたら、頂いたご質問内に利用されているMySQLに
関する情報の記載がないので、その部分で何らかの違いがあるかも
しれません。
利用されているMySQLは、CentOS 6標準のものを利用されているか
を確認させてください。＞ yamato3000さん

ちなみに、私が利用したのは、CentOS 6標準の

　mysql-server-5.1.73-3.el6_5.x86_64

です。

ログイン（登録）してコメントを投稿

2015/03/16 - 20:30 (月)
yamato3000 - 投稿数: 7

すいません、mysqlは5.6を使っていました。

mysql-community-server-5.6.22-2.el6.x86_64

今まで疑ってなかったのですが、これが怪しいですかね・・・

ログイン（登録）してコメントを投稿

2015/03/16 - 22:31 (月)
TNK - 投稿数: 4740

Zabbixのパッケージは、各ディストリビューションの標準パッケー
ジの組み合わせでコンパイルしてテストしているので、標準外のパ
ッケージと組み合わせた場合に問題が発生する可能性が考えられま
す。
例えば、ZabbixサーバからMySQLサーバにアクセスする際に、動的
にMySQLのクライアントライブラリを呼び出すので、ライブラリの
バージョンが異なるために呼び出す関数の互換性に問題があると異
常終了してしまう場合があります。

とはいえ、以前、Zabbix 2.2系とMySQL 5.5系の組み合わせで、コ
ンパチブルパッケージなども一緒にインストールすることで正常に
稼働できる環境は構築できたと思うので、MySQL 5.6系でも組み合
わせによっては稼働できるかもしれません。

MySQL関連のパッケージとして何をインストールされ、各パッケー
ジのバージョンとどこから入手されたのかをお教えください。
ディストリビューション標準のものと混在させてしまっているので
あれば、それも合わせて各パッケージのバージョンと一緒に情報と
してご提供いただけませんでしょうか？

ログイン（登録）してコメントを投稿

2015/03/17 - 10:55 (火)
yamato3000 - 投稿数: 7

TNKさん

以下、mysql関連パッケージとバージョン、入手リポジトリです。

mysql-community-client.x86_64 5.6.22-2.el6 @mysql56-community
mysql-community-common.x86_64 5.6.22-2.el6 @mysql56-community
mysql-community-devel.x86_64 5.6.22-2.el6 @mysql56-community
mysql-community-libs.x86_64 5.6.22-2.el6 @mysql56-community
mysql-community-libs-compat.x86_64 5.6.22-2.el6 @mysql56-community
mysql-community-release.noarch el6-5 @/mysql-community-release-el6-5.noarch
mysql-community-server.x86_64 5.6.22-2.el6 @mysql56-community
php-mysql.x86_64 5.3.3-40.el6_6 @updates
zabbix-server-mysql.x86_64 2.4.3-1.el6 @zabbix
zabbix-web-mysql.noarch 2.4.3-1.el6 @zabbix

ログイン（登録）してコメントを投稿

2015/03/17 - 12:55 (火)
TNK - 投稿数: 4740

以下のURLで紹介されているRHEL 6用のyumリポジトリ用のパッケー
ジをインストールして、環境を構築してみました。
http://dev.mysql.com/downloads/repo/
http://dev.mysql.com/get/mysql-community-release-el6-5.noarch.rpm

極力バージョンを合わせるため、以下のパッケージをインストール
しています。

mysql-community-client-5.6.22-2.el6.x86_64.rpm
mysql-community-common-5.6.22-2.el6.x86_64.rpm
mysql-community-libs-5.6.22-2.el6.x86_64.rpm
mysql-community-libs-compat.x86_64 0:5.6.22-2.el6

Zabbixのバージョンは、2.4.3です。
実際にインストール後稼働させてみましたが、問題なく稼働できて
いるようです。

環境構築時に気になった点としては、MySQLの導入手順です。

もしかして、MySQL 5.6をインストールする前に、別のバージョン
のMySQLをインストールしていませんでしたか？
そうであるならば、MySQL 5.6をインストール後に、データ用ディ
レクトリの初期化かアップグレード処理(mysql_upgrade)は行われ
ましたか？

古いバージョンのデータファイルのまま5.6を稼働させていると、
必要な管理用テーブルが不足していてMySQLサーバが正常に機能で
きません。
/var/log/mysqld.logなどのログにエラーなどが出力されていない
かご確認ください。

あとは、OS標準以外のパッケージを他にも利用していないか、パッ
ケージインストール時に警告を無視したりしなかったか、環境構築
時に説明できないような変な動作がなかったかなど、何か問題とな
りそうなことがなかったかがあればそれらもお教えください。

ログイン（登録）してコメントを投稿

2015/03/17 - 14:22 (火)
KAZ - 投稿数: 1085

zintenさん

言われてみるとそうですね…
もしかすると、check_vcenter_vm_vfs_dev_discovery関数のアドレスが
シンプルチェック・プロセスのstaticに載っているので、
housekeeperプロセスが間違ってcheck_vcenter_vm_vfs_dev_discovery関数を呼び出してしまい、
check_vcenter_vm_vfs_dev_discovery関数が準備されていない
VMware関連のパラメータ取得を実行してメモリアクセス違反でクラッシュした…？

となると、zbx_hashset_searchのほうが怪しいな…

ログイン（登録）してコメントを投稿

2015/03/17 - 14:57 (火)
KAZ - 投稿数: 1085

うーん…
ログとバックトレースから関数の呼び出しは下記の通り…

housekeeping_history_and_trends関数
→hk_history_delete_queue_prepare_all関数
→→hk_history_update関数
→→→hk_history_item_update関数
→→→→zbx_hashset_search関数

その後、何故かcheck_vcenter_vm_vfs_dev_discovery関数が呼ばれました！

うーん…

ログイン（登録）してコメントを投稿

2015/03/17 - 15:02 (火)
TNK - 投稿数: 4740

なので、ライブラリの不整合によるメモリ破壊を疑ったのですが、
普通に質問者が書かれていたバージョンのMySQLとの組み合わせで
も私の手元では初回はもちろん、その後の1時間毎のhousekeeping
処理を繰り返し実行できています。

ログイン（登録）してコメントを投稿

2015/03/17 - 15:28 (火)
zinten - 投稿数: 69

＞となると、zbx_hashset_searchのほうが怪しいな…
同じくそう思います。
なんとなく「zbx_hashset_search()」内のcompare_func()あたりで何かあったのかなぁと…

環境の問題だと別のところでメモリーリークが起きた影響だったり、
仮想環境のメモリ管理で何か起きていたりしないかなぁと。

意外とrpmをダウンロードしてきてインストールしなおしたり、
逆にVMWareCollector動かしたらうまく行ったりしないですかね…

ログイン（登録）してコメントを投稿

日本Zabbixユーザー会

housekeeperの初回起動でクラッシュする

コメント表示オプション

yamato3000さんについて

新しいフォーラムトピック

活発なフォーラムトピック

ユーザーログイン

Twitter