Zabbix Proxy導入で躓いたとこ

振り返れば当たり前なんだが気づくのに3時間ぐらいかかったので戒めに書いておく。

なんやかんやあって、30台以上のラズパイを管理しているので監視用にZabbixを導入している。
システム部門でもなく生産技術の人間なので、サーバを新たにたてるわけにもいかず、部門NASとして導入しているSynologyのDS718+でZabbix ServerとZabbix FrontendをDockerで起動させ、DBはIoT用としてシステム部門に用意してもらっているものに間借りさせている。

今までは、用途的に必要があり社内LANに直接つながるものばかりだったので特に問題なかったが、社内LANとはつながらない設備内固有のLAN内に設置するもの(以降Aと呼称)が出てきた。
幸い同一の設備内LANには別用途ですでに社内LANにもつながっている個体(以降Bと呼称)がいるので、そいつにZabbix Proxyを導入することで対処しようとした。

で、単純にBで"sudo apt install zabbix-proxy-sqlite3"としてインストールして"/etc/zabbix/zabbix-proxy.conf"いじって、AのZabbix Agnetの向き先をBとしてリロードしたら以下のエラーメッセージ。

No active checks on server: host [****] not found

Zabbix Proxy側には以下のようなメッセージ。

cannot send list of active checks to [***]: host [***] not found

Zabbix Server側の設定を見直したり、Agent側の設定を変えたりしたけど状況変わらず。
そもデフォルトの設定ではServerとProxy間の設定情報の更新は1時間ごとなので、Sever側の設定を変更しても最長1時間Proxyには影響を与えない。
それにしてもおかしいと思いログを見直したらProxy側に以下のようなメッセージもあるのに気づく。

failed to update local proxy configuration copy: invalid table name "interface_snmp"

ググったら以下が引っかかる。
www.zabbix.com

そういえば、数カ月前にServer側を4.4から5.0LTSにバージョンアップしたなあと思いだすも、以前調べたときはAgentとバージョンが異なってもServer側のほうが上なら問題ないとなっていたから気にしていなかったし、ラズパイ自体もその間にStretchからBusterに上げていたからバージョン不一致は解消されたんではと思っていた。
しかしながらDebian側のリポジトリはBusterでも4.0なのね。
普段使ってるのFedoraだからディストリのバージョンを最新にしたらパッケージ自体もアップストリームのほぼ最新を追随してると無意識に思っちゃったけど、そういえばDebianはそんなことないわ、むしろStable=OLDな世界だったわ。

upstreamからパッケージ持ってきてProxyのバージョンも5.0LTSに上げたら、何の問題もなくServer上でProxyの先のAgentを認識できた。
まあ、設定自体は正しかったし当然ではある。

結論として、Agent自体はServerより古いバージョンでも問題ないけどProxyはServerと同じバージョンじゃないとダメ。