¶ 🏗 Zabbix 監視アーキテクチャ
¶ 🧭 このページについて
このページでは、本環境における Zabbix の監視構成 を整理する。
Zabbix は単にインストールするだけでは十分ではない。
どのサーバーに監視機能を集約するのか、監視対象からどのように情報を取得するのか、Web 画面をどのように公開するのか、といった全体像を先に整理しておくことで、構築手順や監視設計の内容も理解しやすくなる。
本環境では、監視サーバー上に Zabbix Server、Web フロントエンド、データベースを集約し、複数の Linux サーバーに Zabbix Agent2 を導入して監視する構成を採用している。
また、監視サーバー自身にも Agent2 を導入し、自己監視を行う。
¶ 📝 サーバー名の表記について
本ページは 外部公開向けページ である。
ただし、Zabbix の管理画面や監視基盤そのものは外部公開しておらず、内部利用を前提としている。
そのため、本ページでは実際のサーバー名や内部 IP アドレスは記載せず、仮称を用いて構成を説明する。
以後、本ページでは以下の仮称を使用する。
- 監視サーバー（仮称）（ZBX-WEB）
- 証明書管理サーバー（仮称）（CERT-WEB）
- 監視対象 Web サーバー（仮称）（MON-WEB01）
- 監視対象 DB サーバー（仮称）（MON-DB01）
以後、この仮称を用いて構成を説明する。
¶ 📌 本環境の構成方針
本環境では、次の方針で監視基盤を構成している。
- 監視サーバーに Zabbix の主要機能を集約する
- 監視対象サーバーには Zabbix Agent2 を導入する
- 監視サーバー自身も監視対象に含める
- Zabbix の Web 画面は Apache 経由で提供する
- Web 画面は HTTPS で公開する
- 外部公開ページでは実サーバー名や内部 IP アドレスは出さない
この構成により、監視の中心を 1 台にまとめつつ、各サーバーの状態を一元的に把握しやすくしている。
¶ 🗺 全体構成図
まずは、本環境における監視基盤の全体像を示す。
ここでは細かなコンポーネントまでは書かず、どのサーバーがどの役割を持つかに絞って整理する。
この構成では、監視サーバー（仮称）（ZBX-WEB）が監視基盤の中心となり、監視対象サーバーから情報を取得する。
また、Web 画面は HTTPS で利用し、証明書は証明書管理サーバー（仮称）から配置する。
¶ 🧱 監視サーバーの内部構成
次に、監視サーバー（仮称）（ZBX-WEB）の内部構成を示す。
監視サーバーには、監視に必要な主要コンポーネントを集約している。
¶ 🧩 各コンポーネントの役割
¶ Zabbix Server
Zabbix Server は監視の中心となるコンポーネントである。
監視対象サーバーから取得した情報をもとに、状態判定、イベント生成、トリガー評価、通知処理を行う。
¶ PostgreSQL
PostgreSQL は Zabbix の設定情報、履歴データ、イベント情報を保存する。
監視を継続するほどデータは蓄積されるため、監視基盤において重要な構成要素となる。
¶ Apache
Apache は、ブラウザからの HTTP / HTTPS アクセスを受け付ける Web サーバーである。
管理者は Apache を経由して Zabbix の画面へアクセスする。
¶ Zabbix Web Frontend
Zabbix Web Frontend は、ブラウザから利用する管理画面である。
監視設定、障害確認、グラフ参照、ダッシュボード表示などを行う。
¶ PHP-FPM
PHP-FPM は、PHP アプリケーションを動作させるための仕組みである。
Zabbix の Web 画面は PHP ベースで動作するため、Apache だけでなく PHP-FPM も必要になる。
¶ Zabbix Agent2
Zabbix Agent2 は、監視サーバー自身の CPU、メモリ、ディスク、サービス状態を取得する。
監視基盤そのものも監視対象に含めることで、監視サーバー自身の異常にも気付きやすくなる。
¶ 🖥 監視対象サーバーの役割
本環境では、監視対象サーバー側に Zabbix Agent2 を導入し、OS およびサービスの状態を取得する。
¶ 監視対象 Web サーバー（仮称）（MON-WEB01）
監視対象 Web サーバー（仮称）（MON-WEB01）は、主に Web 系サービスを提供するサーバーである。
監視例：
- CPU 使用率
- メモリ使用率
- ディスク使用率
- Apache の起動状態
- Web アプリケーションの状態
- systemd サービス状態
¶ 監視対象 DB サーバー（仮称）（MON-DB01）
監視対象 DB サーバー（仮称）（MON-DB01）は、主にデータベース系または補助サービスを提供するサーバーである。
監視例：
- CPU 使用率
- メモリ使用率
- ディスク使用率
- DB サービス状態
- Fail2Ban の動作状況
- systemd サービス状態
¶ 🔄 監視データの流れ
監視データは、次の流れで処理される。
監視対象サーバーの情報は Agent2 を通じて監視サーバーへ送られ、監視サーバー側で判定された後、データベースへ保存される。
異常が検知された場合は、イベントやトリガーとして扱われ、通知や画面表示に反映される。
¶ 🧱 監視レイヤーの考え方
本環境では、監視対象をレイヤーごとに整理して考える。
このように整理することで、障害発生時に
- OS の問題か
- サービスの問題か
- アプリケーションの問題か
- 監視基盤側の問題か
を切り分けやすくなる。
¶ 🔐 HTTPS 公開の考え方
本環境では、Zabbix の Web 画面を HTTPS で公開する構成としている。
この構成では、証明書を管理する役割と、監視画面を提供する役割を分けている。
これにより、ブラウザからのアクセスを暗号化通信で扱える。
¶ 🎯 本環境で監視する主な対象
本環境では、単なる生死監視ではなく、OS・サービス・アプリケーションをまとめて監視する。
主な監視対象は以下のとおりである。
- Linux サーバーの稼働状態
- CPU 使用率
- メモリ使用率
- ディスク使用率
- Apache の状態
- DB サービスの状態
- Web アプリケーションの状態
- Fail2Ban の動作状況
- systemd サービスの状態
- 監視サーバー自身の状態
¶ ✅ この構成のメリット
¶ 一元管理しやすい
監視サーバーに監視機能を集約しているため、管理者が全体状態を把握しやすい。
¶ 自己監視できる
監視サーバー自身にも Agent2 を導入しているため、監視基盤そのものの異常も把握しやすい。
¶ サービス単位で状態を把握しやすい
OS リソースだけでなく、Apache、DB、Fail2Ban などのサービス状態も監視できる。
¶ 拡張しやすい
監視対象サーバーを追加する場合でも、Agent2 の導入とホスト登録により拡張しやすい。
¶ ⚠ 設計上の注意点
本構成では、次の点に注意する必要がある。
- 監視サーバー障害時は全体の可視性が下がる
- PostgreSQL の蓄積データにより容量が増加する
- 監視項目を増やしすぎると運用負荷が高くなる
- 通知を増やしすぎると重要な障害が埋もれやすい
- 外部公開ページでは実サーバー名や内部ネットワーク情報を出さない
¶ 📚 関連ページ
¶ 📝 まとめ
本環境の Zabbix 監視アーキテクチャは、監視サーバー（仮称）（ZBX-WEB）に Zabbix Server、Web フロントエンド、PostgreSQL を集約し、監視対象サーバーへ Agent2 を導入して監視する構成である。
また、監視サーバー自身も自己監視対象に含めることで、監視基盤全体の健全性も確認できる。
この構成により、OS 監視、サービス監視、障害通知、可視化を一元的に実現できる。