分散監視でDB取り込みエラー？
分散監視の設定を行いましたが、以下のエラーメッセージと共にDBのレコードの情報とおぼしき文字列が親ノードのZabbix_serverログに大量に書き込まれます。
何か設定が不足している、または分散監視の設定手順で間違いがあったのでしょうか？
事前設定
1.全ノードのzabbix_server.confにNodeIDを指定
2.全ノードで以下を実施
/usr/sbin/zabbix_server -n ノードID -c /etc/zabbix/zabbix_server.conf
【親ノード】
バージョン：2.0.7
ノードID：200
【子ノード1】
バージョン：2.0.7
ノードID:1
【子ノード2】
バージョン：2.0.7
ノードID:2
親ノードのZabbix-Serverログ
4359:20140120:172702.565 NODE 200: Received history from node 2 for node 2 datalen 686
4359:20140120:172702.596 NODE 200: Received history_uint from node 2 for node 2 datalen 309
4358:20140120:172702.644 NODE 200: Received events from node 2 for node 2 datalen 125372
4353:20140120:172702.782 NODE 200: Received auditlog from node 2 for node 2 datalen 1608776
4353:20140120:172702.826 [Z3005] query failed: [1452] Cannot add or update a child row: a foreign key constraint fails (`zabbix`.`auditlog`, CONSTRAINT `c_auditlog_1` FOREIGN KEY (`userid`) REFERENCES `users` (`userid`) ON DELETE CASCADE) [insert into auditlog (auditid,userid,clock,action,resourcetype,details,ip,resourceid,resourcename) values (200000000000001,200200000000001,1186632811,3,0,'0','192.168.200.190',200200000000001,''),(200000000000002,200200000000001,1186632821,3,0,'0','192.168.200.190',200200000000001,''),(200000000000003,200200000000001,1186632843,1,0,'User alias [Admin] Name [Zabbix] Surname [Administrator] profile id [1]','192.168.200.190',0,''),(200000000000004,200200000000001,1186632862,3,0,'0','192.168.200.190',200200000000001,''),(200000000000005,200200000000001,1186632926,3,0,'0','192.168.200.190',200200000000001,''),(200000000000006,200200000000
＜中略＞
0','1'),(200000000004007,200000000008374,'items','status','0','1'),(200000000004008,200000000008375,'items','status','0','1'),(200000000004009,200000000008376,'items','status','0','1'),(200000000004010,200000000008377,'items','status','0','1'),(200000000004011,200000000008378,'items','status','0','1');
こんな感じです。（小ノード１、２、どちらからのデータでも同様の症状）
親ノードのWebGUIで子ノードに切り替えても、実際にデータは表示されません。
貼付けたログの前半を見る限りではデータのやり取り自体は出来て取り込みで失敗しているようにも見えます。
TNK - 投稿数: 4717
エラーメッセージを拝見して予想されるのは、NodeIDを設定して最初
に1回だけ -n ノードID を指定してzabbix_serverを手動で起動して、
データベースのノード構成用のDBに全データを更新するのですが、
その変換処理が正常終了していなかったのではないかと思われます。
ノード構成用に変換する途中で失敗してしまっていた場合、変換を
開始する前のバックアップにデータを戻してやり直しをしなければ
なりません。
途中から再開することはできません。
最初に1回だけ実行した変換処理時に、正常に変換が終了していたか
ご確認ください。
また、現時点ではノード構成は推奨されていないようです。
現時点の実装では、親ノードに処理が集中してしまうので、大規模に
なった場合に、親ノードには特に高い処理性能が求められます。
また、構築に失敗したらやり直しになるなど、環境構築や運用が複雑
になりますのでご注意ください。
H.Cosh - 投稿数: 8
TNK様
回答ありがとうございます。
ノード構成が推奨されていないことについては承知しております。
ノード数や監視アイテムがそれほど大規模ではないので実験的に取り入れようと思っております。
変換については全ノードにて、Susccessfullで正常終了していることを確認済みです。
親ノードは今回新規で作ったので壊れても影響がない為、一度データベースをドロップしてDB新規作成、スキーマ、イメージ、データを取り込んでから再度 -n ノードIDの変換を実施（子ノードは弄らず）して正常終了したように見えましたが、やはり結果は同じでした。
Recieved configration、Sending configuration、Received alerts from node xxxのログの後、query failed: [1452] Cannot add or update a child rowに続いて大量の生データ？が吐き出されております。
TNK - 投稿数: 4717
お手数ですが、実施された詳細な手順(特に各作業の順序)を
お教えいただけませんか？
H.Cosh - 投稿数: 8
TNK様
ありがとうございます。
実は一度だけ子ノードの情報が正しく取り込めていた事があります。
それも含めて、覚えている範囲で手順を記載させて頂きます。
1.親ノードの仮想マシンにZabbix一式をインストール
2.ノードID:200を設定してDB再構築
/usr/sbin/zabbix_server -n 200 -c /etc/zabbix/zabbix_server.conf
3.WebUI上から子ノードを追加
4.子ノード①にノードID:1を追加してDB再構築
/usr/sbin/zabbix_server -n 1 -c /etc/zabbix/zabbix_server.conf
5.子ノード①のWebUIから親ノードを追加
6.親ノードのWebUIからノード選択して子ノード①の情報が見れることを確認。また、設定変更も行って子ノード①に適用されることを確認
7.同様の手順で子ノード②（NodeID:2）も追加し、親ノードからの閲覧及び設定変更が出来ることを確認
/usr/sbin/zabbix_server -n 2 -c /etc/zabbix/zabbix_server.conf
8.VMwareの監視を行いたい為、親ノードを2.2.1にVerUp
9.バージョンアップだとVM関係のテンプレートが追加されない事がわかり、親ノードを潰して新規仮想マシンを作成
10.親ノードにZabbixサーバ一式(2.2.1)をインストール
11.親ノードにNodeID:200を設定し、DB再構築、正常終了（画面メッセージ上）
12.親ノードのWebUIから子ノード①を追加したところ、昨日の問い合わせの状況
13.子ノードのWebUIから親ノードを一旦削除し、登録し直し→×
14.子ノードのZabbixサーバサービスを再起動→×
15.親ノードの仮想マシンを作りなおし、2.0.7をインストール
16.親ノードのノードIDを100にしてDB再構築→×（ここで問い合わせ）
16.回答を頂いたので試しに親ノードのDBを一旦ドロップし、新規に作成
mysql> DROP DATABASE zabbix;
mysql> CREATE DATABASE zabbix CHARACTER SET=utf8;
mysql> grant all privileges on zabbix.* to zabbix@localhost identified by 'zabbix';
mysql> flush privileges;
# mysql -uroot zabbix < /usr/share/doc/zabbix-server-mysql-2.0.7/create/schema.sql
# mysql -uroot zabbix < /usr/share/doc/zabbix-server-mysql-2.0.7/create/images.sql
# mysql -uroot zabbix < /usr/share/doc/zabbix-server-mysql-2.0.7/create/data.sql
17.DB再構築コマンドを実施→正常終了（画面メッセージ上）
/usr/sbin/zabbix_server -n 200 -c /etc/zabbix/zabbix_server.conf
18.やはり同じ症状。子ノードで親ノードの再登録やzabbix_serverサービスの再起動などをやっても同様。
このような状況です。
今思えば最初に成功した後に（2.2.1の環境を新規に作成して)VMwareの監視アイテムをエクスポート＆インポートで持ってきていれば、、、と悔やまれます。
TNK - 投稿数: 4717
最終的には、2.2.1の環境にされるのですか？
ご存じとは思いますが、VMware監視の機能は、2.2からですので
2.0.7の環境に2.2.1からテンプレートの情報を取り込めたとしても
機能しません。
VMwareの監視をされたいのであれば、2.2.1の環境を構築されて
はいかがでしょうか？
以前の環境があって引き継がなければならないものが多いのであ
れば、一度、2.0.7で構築して2.2.1にアップグレードし、別途、2.2.1
の環境を用意しなければなりませんが、そこからVMwareのテンプ
レートで利用している値のマッピングと、テンプレートをエクスポート
してインポートすることでVMwareのテンプレートは利用できます。
# 値のマッピングは、手でWebUIから登録、もしくはSQLで流し込み
その後、ノード構成にされてはいかがでしょうか？
手順として気になったのは、ノード構成にしてDBの変換を行った後、
zabbix_serverを起動後にWebフロントエンドでノードの登録という
順番だったと記憶しています。
時間があれば、環境を作って試せるかもしれないので、2.0.7でやる
のか、2.2.1にするのかご検討ください。
H.Cosh - 投稿数: 8
TNK 様
もしバージョンが混在した分散監視が可能であれば、親ノードのみ2.2.1で行きたいと思っております。
子ノードになる監視サーバはVMを監視する必要がないのと、既に監視が動いているので長時間停止があまり好ましくない（場合によっては実施可能）のでバージョンアップせずに済むなら2.0.7のままにしておこうと思っています。
順番が気になるとの事ですので、念のためこちらでも
1.親ノードのNodeIDを100に変更して再度再構築
2.親ノードでZabbixサーバサービス起動
3.親ノードで子ノードを登録
を試してみます。
TNK - 投稿数: 4717
ProxyやNodeなどの分散監視のサーバ群のメジャーバージョンは
一致している必要があります。
親ノードを2.2.1にするのであれば、ProxyやNodeも2.2.xであるこ
とが必要です。
ご参考：
https://www.zabbix.com/documentation/2.2/manual/appendix/compatibility
H.Cosh - 投稿数: 8
なるほど。
本題とはちょっとずれますが、2.0.7から2.1.1にVerUpする場合、どの程度の停止時間が発生しますでしょうか。
登録しているアイテム数が履歴の数に影響しますか？
H.Cosh - 投稿数: 8
今、NodeIDを変更して再構築しようとしたところ、以下のエラーが出ました。
やはり前回の再構築で失敗しているのでしょうか。
# /usr/sbin/zabbix_server -n 100 -c /etc/zabbix/zabbix_server.conf
Unable to convert. Some of object IDs are out of range in table "hosts" ("hostid" = 20020000000010001)
TNK - 投稿数: 4717
一度変換してしまったDBは、自動では再度変換しなおすことが
できません。
-n ノード番号 のオプションをつけて実行するまえに、変換する前
のDBに戻しておくことが必要です。
H.Cosh - 投稿数: 8
取りあえず2.2.1は置いておき、先程の状態から再度、親ノードで
mysql> DROP DATABASE zabbix;
mysql> CREATE DATABASE zabbix CHARACTER SET=utf8;
mysql> grant all privileges on zabbix.* to zabbix@localhost identified by 'zabbix';
mysql> flush privileges;
# mysql -uroot zabbix < /usr/share/doc/zabbix-server-mysql-2.0.7/create/schema.sql
# mysql -uroot zabbix < /usr/share/doc/zabbix-server-mysql-2.0.7/create/images.sql
# mysql -uroot zabbix < /usr/share/doc/zabbix-server-mysql-2.0.7/create/data.sql
/etc/zabbix/zabbix_server.confにNodeID=999を追加
/usr/sbin/zabbix_server -n 999 -c /etc/zabbix/zabbix_server.conf
/etc/init.d/zabbix-server start
を実行。
その後、親ノードでWebUIを開いて子ノードを登録したところ、やはり同様のエラーとレコードデータ？がズラズラと出力される状態になりました。
TNK - 投稿数: 4717
2.0.10で試してみました。
親ノードを「Zabbix server P」、子ノードを「Zabbix server C」
として両方のノードでZabbix 2.0.10が個別に正常に稼働できるこ
とを確認します。
その後、それぞれのノードでNode IDを付与します。
親ノード：
# service zabbix-server stop
# service zabbix-agent stop
# service httpd stop
# zabbix_server -n 200 -c /etc/zabbix/zabbix_server.conf
# vi /etc/zabbix/zabbix_server.conf →NodeID=200を設定
# service zabbix-agent start
# service zabbix-server start
# service httpd start
子ノード：
# service zabbix-server stop
# service zabbix-agent stop
# service httpd stop
# zabbix_server -n 1 -c /etc/zabbix/zabbix_server.conf
# vi /etc/zabbix/zabbix_server.conf →NodeID=1を設定
# service zabbix-agent start
# service zabbix-server start
# service httpd start
各ノードにNodeIDの設定が終了したらそれぞれのノードでWebフロ
ントから相手のノードを追加します。
親ノード：
管理 -> 分散監視 -> プルダウンから「ノード」選択。
「ノード作成」ボタンを押して子ノードを登録。
名前 ： Remode node
ID ： 1
タイプ ： 子
マスターノード ： Local node
IPアドレス ： 子ノードのIPアドレス
ポート ： 10051
子ノード：
管理 -> 分散監視 -> プルダウンから「ノード」選択。
「ノード作成」ボタンを押して親ノードを登録。
名前 ： Parent Node
ID ： 200
タイプ ： マスター
IPアドレス ： 親ノードのIPアドレス
ポート ： 10051
設定し終えたら、より早く反映させて同期を開始させるために、
各zabbix_serverを再起動すると同期が開始されます。
以前提示頂いたエラーと同様のエラーであるならば、親ノードは作
成しなおしをされたので問題ないとすれば、子ノード側のDBに問題
があるのかもしれません。
新規に上記のような手順で行えば、問題なく同期して監視ができて
いますので、ご確認ください。
ついでに、2.0.7から2.2.1へのDBのアップグレードは、小さな変更
ですので、1.8系から2.0系にアップグレードするよりははるかに短
い時間でアップグレード処理が終了します。
1.8系から2.0系へのアップグレード時には、履歴の情報すべてに情
報項目を追加するため、履歴のサイズに大きく依存します。
ご参考：
zabbix 1.4.5 から2.2.0系へのバージョンアップパス
http://www.zabbix.jp/node/2551
H.Cosh - 投稿数: 8
ありがとうございます。
結論から言うと親ノードに関してはご提示頂いた手順で初めからやり直してみましたが、やはり症状は変わりませんでした。
と言う事はやはり子ノードのDBに問題がありそうなので、取り敢えず現在動いている2つの子ノードは諦めて、新たにテスト用の子ノードを作ってみようと思います。
もしそれで上手く行ったら、次に監視サーバを立てる時に実験的に分散構成にしてみようと思います。
ありがとうございました。