2026.03.20 2026.03.20

ZabbixをDocker構成で動かしたらAgent接続エラーに苦戦した話

pesche

記事内に商品プロモーションを含む場合があります

こんにちは、ペスケです。

今回は、Zabbix ServerをDockerコンテナ内で動かし、Zabbix AgentはUbuntuホスト側に直接インストールするという構成を試してみたときの話です。

ネット上では「Agentはホスト側に入れたほうがCPUやメモリなどの情報を取りやすい」という情報もあり、実際にその形で構築してみました。

ですが、結論から言うとこの方法はかなり苦戦しました。
6時間ほど格闘して一度は動く形になったものの、再起動後にまったく機能しなくなってしまったため、最終的には「素直にDocker内でまとめたほうがよかったかもしれない」と感じています。

発生した症状

今回の構成では、Zabbix ServerはDocker、Zabbix AgentはUbuntuホスト上で動かしていました。

その状態でWeb UIを確認すると、以下のようなエラーが表示されました。

Received empty response from Zabbix Agent at [192.168.1.84]. Assuming that agent dropped connection because of access permissions

見た感じでは「Agentが応答を返していない」ように見えますが、実際にはアクセス権限の問題で接続を拒否されていたのが原因でした。

原因はDockerブリッジネットワークの見え方だった

今回ハマった最大のポイントは、Dockerコンテナからホストへ通信したときのIPアドレスの見え方です。

人間がブラウザからアクセスするときはホストの物理IPを使いますが、Dockerコンテナからホストへ通信する場合、Agent側からはその接続元がコンテナの内部IPとして見えます。

つまり、ホスト側のZabbix Agentは「許可していないIPアドレスからアクセスされた」と判断し、接続を拒否していました。

通信の全体像

今回の環境では、以下のようなIPになっていました。

ServerコンテナのIP: 172.16.238.2
ホストのゲートウェイIP: 172.16.238.1
ホストの物理IP: 192.168.1.84

このとき重要なのは、コンテナからホストへ通信するときに使うべきなのは物理IPではなく、Dockerブリッジ側のゲートウェイIPだったという点です。

実際にやった対処法

1. Agent側でDockerネットワークを許可する

まず、Ubuntuホスト上の zabbix_agentd.conf を編集し、Dockerネットワークからの通信を許可しました。

# /etc/zabbix/zabbix_agentd.conf

Server=127.0.0.1,172.16.238.0/24
ServerActive=127.0.0.1,172.16.238.0/24
Code language: PHP (php)

設定変更後は、Agentを再起動します。

sudo systemctl restart zabbix-agent

これで、Dockerネットワーク内のIPアドレスからの接続を受けられるようになります。

2. Web UIのホストIPを物理IPではなくゲートウェイIPにする

次に、ZabbixのWeb UIで対象ホストのインターフェース設定を見直しました。

[設定] → [ホスト] → [インターフェース] から、IPアドレスを以下のように変更します。

IPアドレス: 172.16.238.1
ポート: 10050

ここで 192.168.1.84 のような物理IPを設定してしまうと、今回の構成ではうまく通信できませんでした。

デバッグ時に役立ったコマンド

今回かなり助かったのが、ログを直接確認したことです。
やはりトラブル時は、思い込みで進めるよりログを見るのが一番早いです。

Agent側の拒否ログを確認する

sudo tail -f /var/log/zabbix/zabbix_agentd.log | grep "rejected"
Code language: JavaScript (javascript)

これを見れば、「どのIPアドレスからの接続が拒否されたのか」がすぐ分かります。
Allowed Hostsに何を追加すべきかの判断がしやすくなります。

コンテナからAgentへの疎通確認をする

docker exec -it <Serverコンテナ名> sh
zabbix_get -s 172.16.238.1 -p 10050 -k agent.ping
Code language: CSS (css)

コンテナ内から直接Agentへ問い合わせることで、通信経路に問題があるのか、Agent設定に問題があるのかを切り分けやすくなります。

今回の教訓

今回の検証で学んだことは、主にこの3つです。

1. Dockerとホストをまたぐ構成は思ったよりややこしい

一見シンプルに見えても、DockerブリッジネットワークをまたぐとIPの見え方が変わるため、想定どおりに動かないことがあります。

2. ホストの物理IPではなく、Docker側のゲートウェイIPを見るべき場面がある

今回のように、コンテナからホストへ通信する場合は、**物理IPではなくゲートウェイIP（末尾 .1 のアドレス）**を使うほうが安定しました。

3. ログ確認は最短ルート

6時間悩むくらいなら、最初からログを見たほうが早いです。
特に zabbix_agentd.log の拒否ログは、原因特定にかなり役立ちました。

まとめ

今回は、Docker上のZabbix Server と ホスト上のZabbix Agent を組み合わせた構成を試してみました。

一度は形になったものの、再起動後に接続できなくなってしまったこともあり、最終的にはこの構成はあまり安定しない印象でした。

そのため、今あらためて考えると、Zabbix関連はDocker内でまとめて構築するほうが管理しやすく、トラブルも少ないかもしれません。

同じように
「Zabbix ServerはDocker、Agentはホストに入れたい」
と考えている方は、Dockerネットワークと許可IPの設定でかなりハマる可能性があるので注意してください。

※アイキャッチ画像はAI生成画像を使用しています