2025 年 07 月 02 日
Zabbix Proxy の活用方法
～ Zabbix Proxy を活用した多拠点監視やオンプレミスとクラウドのハイブリッド監視 ～
はじめに
2024 年 12 月、弊社の技術ブログである Zabbix テックラウンジにて、Zabbix / MIRACLE ZBX 7.0 の新機能である Zabbix Proxy HA について仕組みや構築手順などを解説しました。
今回は、より広く Zabbix の Proxy 機能を活用することに焦点をあててご紹介します。
上記のブログ記事については、以下からご参照ください。
本記事内での表記・用語について
| 表記・用語 | 解説 |
|---|---|
| Zabbix | Zabbix LLC 社が提供しているオープンソースの統合監視ソフトウェアを指します。 Zabbix として実装されている機能全般を指す場合にも本表記をします。 |
| MIRACLE ZBX | サイバートラスト株式会社が提供している Zabbix をベースとした監視ソフトウェアを指します。 |
| Zabbix Server | Zabbix / MIRACLE ZBX のサーバー機能がインストールされ稼働しているサーバーおよびその機能を指します。 |
| Zabbix Proxy | Zabbix / MIRACLE ZBX のプロキシ機能がインストールされ稼働しているサーバーおよびその機能を指します。 |
| Zabbix Agent | Zabbix / MIRACLE ZBX のエージェント機能がインストールされ稼働しているサーバーおよびその機能を指します。 |
Zabbix Proxy とは
Zabbix Proxy とは、下図のように監視対象と Zabbix Server の中継役として、Zabbix Server に代わり監視対象から監視データを収集します。
Zabbix Server の正常稼働時、監視対象からの監視データは一旦 Zabbix Proxy 上のデータベースに格納されますが、Zabbix Server にデータ送信が完了した時点でデータは消去され永続的な蓄積はされません。
Zabbix Server 自身の障害（あるいは高負荷でのデータ受信不可など）や通信障害などで、Zabbix Proxy から Zabbix Server にデータを送信できない場合には、Zabbix Proxy のデータベースにデータを蓄積し、状況改善後に順次 Zabbix Server に監視データの送信を再開します。また、Zabbix Server とのデータ送信の正常・異常を問わず「一旦は自身のデータベースにデータを格納する」という動作をするため、Zabbix Proxy に到達した監視データが喪失することはありません。ただし、アラート送信（障害通知）は Zabbix Server が担っているため、Zabbix Server が停止している期間は、監視対象の障害を検知・通知することは出来ません。
Zabbix Proxy がサポートするアイテムタイプおよび機能は以下の通りです。
| アイテムタイプ | サポート | 機能 | サポート |
|---|---|---|---|
| Zabbix エージェント | Yes | Web 監視 | Yes |
| Zabbix エージェント（アクティブ） | Yes | アイテム値の保存前処理 | Yes |
| シンプルチェック | Yes | ネットワークディスカバリ | Yes |
| SNMP エージェント | Yes | アクティブエージェントの自動登録 | Yes |
| SNMP トラップ | Yes | ローレベルディスカバリ | Yes |
| Zabbix インターナル | Yes | （アクション）リモートコマンド | Yes |
| Zabbix トラッパー | Yes | 予測トリガー関数 | No |
| 外部チェック | Yes | イベント相関 | No |
| データベースモニター | Yes | イベント処理 ※イベント生成、アクション評価など |
No |
| HTTP エージェント | Yes | アラート通知 ※アクションの実行など |
No |
| IPMI エージェント | Yes | ||
| SSH エージェント | Yes | ||
| TELNET エージェント | Yes | ||
| JMX エージェント | Yes | ||
| 計算 ※計算自体は Zabbix Server で実施 |
Yes | ||
| 依存アイテム | Yes | ||
| スクリプト | Yes | ||
| ブラウザ | Yes |
Zabbix Proxy の動作モード
Zabbix Proxy には、「アクティブプロキシ」と「パッシブプロキシ」という監視設定や監視データの送信要求の起点を決定する 2 種類の動作モードが存在します。
アクティブプロキシ
Zabbix Proxy がすべての通信の起点となる動作モードです。
Zabbix Server が保持する監視設定情報は、Zabbix Proxy からの設定情報の取得要求によって Zabbix Proxy に伝達されます。
パッシブプロキシ
Zabbix Server がすべての通信の起点となる動作モードです。
Zabbix Server が保持する監視設定情報は、Zabbix Server から Zabbix Proxy に配信されますが、監視データについては Zabbix Proxy にデータ要求を送信することで Zabbix Server に伝達されます。
どちらの動作モードも監視の機能自体に違いは生じませんが、通信の向き（TCP/IP のコネクションの向き）が異なります。のちほど解説しますが、Zabbix Proxy はファイアウォールやルータなどで Zabbix Server とネットワークが区切られている環境で使用されることが多く、その際のセキュリティポリシーに「通信の向き」が大きく影響を与えます。また、アクティブモード時の設定内容によっては、Zabbix Proxy になりすまして Zabbix Server に監視データを送信できてしまう可能性もあります。
これら「配置するセグメントのセキュリティ要件」や「扱う監視データの機密性」などから、どちらのモードを採用するか注意して選択する必要があります。
Zabbix Proxy の活用例
今回は、Zabbix Proxy を使った監視構成パターンとそのポイントなどをいくつかご紹介します。
なお、環境ごとの固有の条件や要件などにより、ここでご紹介する構成やポイントが当てはまらない場合もあります。ご了承ください。
多拠点監視パターン
本社などに Zabbix Server を設置し、そこから各拠点を監視する構成パターンです。もっとも一般的な Zabbix Proxy の利用方法となります。
本社と拠点間には VPN 回線などが利用されることが多いですが、回線障害が発生しても各拠点の Zabbix Proxy にて監視データを蓄積し、監視データの喪失を防ぐことが可能です。また、本社と拠点間の通信は、Zabbix Server と Zabbix Proxy に限定されるため、ファイアウォールなどで監視対象機器ごとの設定を行う必要がなく、運用面でも利点があります。
【ここがポイント！！①】
この構成パターンでは、Zabbix Proxy の動作モードを「パッシブモード」に限定しています。
本社・拠点ともにインバウンド・アウトバウンド通信についての許可は最小権限にすることが望ましいですが、本社（重要なデータが多い）側のインバウンド通信をより強固にすることで、外部からの不必要な通信を防ぐことになります。
【ここがポイント！！②】
ネットワーク機器の監視では、SNMP Trap 監視を多用することもあります。SNMP は V3 こそ TCP に対応しパケットの再送なども可能になりましたが、広く用いられている V2c までは UDP となります。拠点間の通信は、拠点内の通信に比べると遅延や切断の発生率が高く、エラー訂正や再送のない UDP ではデータの破損・喪失の可能性も高くなります。そこで、各拠点の Zabbix Proxy で受信した SNMP 監視データを TCP にて Zabbix Server に送信することで、データの破損や喪失を回避することができます。
オンプレミス＋クラウドの監視パターン（オンプレミスに Zabbix Server 型）
本社のオンプレミスのサーバーで業務と監視などを行い、一部のサーバーをクラウドの IaaS や SaaS に置き換えたり、SaaS 型ソリューションを利用する場合の監視構成パターンです。Zabbix Proxy を IaaS で構築しますが、IaaS 環境での監視は他は多拠点パターンの１拠点をクラウドに置き換えた構成と変わりありません。
ただし、SaaS 監視については監視の対象としたい SaaS が稼働状態等の監視に必要な情報を提供しているかに依存します。一般には REST API などによる情報取得、あるいは Webhook のような通知を Zabbix Proxy で取得することになります。ただし、Zabbix Proxy 自体は Webhook の受信には対応していないため、何らかの工夫が必要になります。
【ここがポイント！！①】
本社などオンプレミスの Zabbix Server が置かれるような環境では、インターネットからのインバウンド通信は VPN があったとしても不許可とされることもあるため、クラウド上の Zabbix Proxy の動作は「パッシブモード」を強く推奨します。なお、クラウド上の Zabbix Proxy を利用することで、オンプレミス環境から直接インターネットアクセスをすることなく、インターネット上の SaaS 監視も可能です。ただし、クラウド環境のセキュリティ設定には十分注意してください。
【ここがポイント！！②】
Zabbix Server と Zabbix Proxy 間の監視通信は暗号化が可能です。そのため、Zabbix Proxy サーバーに付与するグローバル IP に対して直接アクセスしても平文による監視データの漏洩は防ぐことが可能です。ただし、他の IaaS サーバーや SaaS 型ソリューションもあることや、Zabbix Server / Zabbix Proxy の設定も通常より複雑になることなどから、他拠点と同様に VPN で接続することを推奨します。
なお、クラウド環境では Zabbix Server と Zabbix Proxy 間の通信は課金対象となることがあります。Zabbix 4.0 以降であれば、Zabbix Proxy からの監視データは圧縮が可能ですが、監視対象が増えるとサーバー等の課金だけでなくトラフィックへの課金にも注意が必要です。
オンプレミス＋クラウドの監視パターン（クラウドに Zabbix Server 型）
今までご紹介したパターンとは逆に、クラウド上の IaaS で Zabbix Server を構築します。業務サーバーなどの大半はクラウド化できたが、まだクラウド化できないサーバーが残っていたり、拠点ごとの固有サーバーや拠点内のネットワーク機器の監視が必要となる場合の構成パターンです。
【ここがポイント！！①】
この構成における Zabbix Proxy の動作モードについては、通信方向の考え方は今までと変わりませんが、より慎重に検討する必要があります。例えば本社ファイアウォールのセキュリティ要件において、「VPN 通信を経由していてもインターネット上に存在するサーバーからのインバウンド通信は不許可」となるような場合は、今までの構成パターンでご紹介していたパッシブモードは利用できません。ただし、アクティブモードとパッシブモードを混在させると、Zabbix Server / Zabbix Proxy の設定管理だけでなくファイアウォールの設定管理など他の機器の管理までもが煩雑になります。
Zabbix Server ～ Zabbix Proxy 間の監視通信だけでなく、他の通信やファイアウォールのポリシー等も考慮して動作モードを決定してください。
【ここがポイント！！②】
Zabbix Proxy に特化したポイントではありませんが、IaaS として Zabbix Server を構築する場合には課金にも注意が必要です。Zabbix Server には多くの監視データが蓄積され、また監視データを処理する CPU やメモリの性能も必要となります。IaaS ではこれらは全て課金対象となるため、事前の費用見積もりをしっかり行うことや、監視データの保存を短期間にするなど割り切った監視設定を行うなども重要となります。
蓄積する監視データの節約には、弊社の以下のオプション製品も便利です。出力した CSV 監視データは、クラウド以外の環境に転送し、日々の運用などで加工・活用することで、クラウド上のディスク容量を大きく節約することができます。
Zabbix Proxy HA の活用例
いままでにご紹介してきた各活用例を Zabbix Proxy HA に置き換える場合の構成パターンについて、制約などの注意ポイントもあわせてご紹介します。
オンプレミス環境での活用
Zabbix Server にはクラスターソフトウェア（ CLUSTERPRO X や Lifekeeper など）を用いた Active - Standby の冗長構成、Zabbix Proxy には Zabbix Proxy HA 機能での冗長構成とする、大規模拠点かつ監視の停止が許されないようなミッションクリティカルな環境向けの構成パターンです。
Zabbix Proxy HA は、2 台以上であれば上限台数に関係なく、すべて Active の負荷分散型の HA 構成となります。そのため、監視対象であるサーバーやネットワーク機器がどの Zabbix Proxy に所属させるか考慮する必要がなく、プロキシグループに所属させるだけで冗長化された監視が可能になります。
なお、Zabbix Server は高負荷になりやすく大量の監視データも蓄積されるため、専用のクラスターソフトウェアを採用した構成パターンとなっています。専用のクラスターソフトウェアであれば、Zabbix Server が使用するデータベースやストレージまで含めて一括してクラスター化が可能です。また、Zabbix Server に障害が発生し監視データを受信できないフェイルオーバー中の状態となっても、Zabbix Proxy は監視データを蓄積するため監視データを取りこぼすことはありません。
【ここがポイント！！】
Zabbix Proxy HA は SNMP Trap 監視に対応していません。SNMP Trap 監視を行いたい場合は、Zabbix Server と同様にクラスターソフトウェアを用いた Active - Standby 型の冗長構成にする必要があります。
ただし、弊社の MIRACLE ZBX の連携ソリューションである MIRACLE MessageHandler を用いると、Zabbix Proxy HA と独立して SNMP Trap を受信することが可能になるため、Zabbix Proxy HA と SNMP Trap 監視を両立させることが可能です。
クラウド環境での活用
多くのクラウド事業者のクラウド環境では、IaaS を配置するサーバーの地理的位置（ AWS ではアベイラビリティゾーン、Azure では可用性ゾーンなど呼び方は様々ですが）を選択することが可能です。クラウド環境は、障害が発生することを前提で設計することが望ましいので、Zabbix Proxy HA を構築する際は各ゾーンに分散させますが、その際には標準機能だけで実現でき負荷分散型の HA である Zabbix Proxy HA は機能的にもコスト的にも相性がよいです。
下記の図は、 AWS において VPC の Private Subnet の各 AZ に EC2 で Zabbix Proxy を 3 台構築し Zabbix Proxy HA とする構成です。仮に 1 つの AZ が停止しても、残りの AZ にある Zabbix Proxy で監視の継続が可能です。この HA 動作については、前回のブログ「構築・設定」編の後半にてご紹介しています。
おわりに
Zabbix Proxy の活用例をご紹介してきました。セキュリティ面や運用に注意が必要な場合もある Zabbix Proxy ですが、今回ご紹介したようにオンプレミス＋クラウド環境のハイブリッド構成と非常に相性がよいです。
また、Zabbix Proxy 単体では制限が生じてしまう場合も、他オプション製品などと組み合わせることで制限を解消させることも可能です。Zabbix Proxy 構築時にお困りの際は、お気軽にお問い合わせフォームからご連絡ください。
本記事に関連するリンク
