Zabbix Server＋Zabbix Agent 2を利用して、クライアントPC監視システムを構築した際の記録です。
今回は検証環境として、不要になったWindows PCを流用してZabbix Serverを構築しました。
この記事では細かなインストール手順ではなく、
- なぜ監視が必要だったのか
- どのような構成にしたのか
- 実際に何を監視したのか
を中心にまとめています。実際私も手順はAIに聞きながら設定などをくみ上げて1週間もあれば組みあがりました。
特に、
- 普段は利用しない端末
- リモート接続前提の端末
- 台数だけ増えて管理が追いつかない端末
を抱えている環境では、監視を入れるだけでも運用負荷がかなり変わると感じました。
課題背景
常時利用しないクライアント端末では、以下のような問題が発生しやすくなります。
- 稼働状態が把握できない
- 必要なタイミングで利用できない
- Windows UpdateやOS自動処理による停止に気づけない
- リモート接続前に障害へ気づけない
1〜2台程度なら手動確認でも運用できますが、10台を超えてくると確認コストが無視できなくなります。
特に「普段使わない端末」は、
「問題が起きない端末」ではなく、「問題に気づきにくい端末」
になりやすいと感じました。
そのため今回は、「状態が見えないことによる運用リスク」を減らすため、Zabbixによる監視環境を構築しました。
Zabbixって何？
Zabbixについて詳しく知りたい方は、以下の記事がおすすめです。
簡単にまとめると、
- OSSの無料監視ツール
- 非常に多機能
- 官公庁や大手SIerでも導入実績あり
- OSSのためインターネット上に情報が豊富
という特徴があります。
環境構成
Zabbix Server側
- Zabbix Server 7.4
- MySQL
- Ubuntu 22.04 LTS
- 旧Windows PCを流用
DBはMySQLを選定しました。
PostgreSQL構成も検討しましたが、既存Zabbix環境との互換性や運用ノウハウを優先しています。
監視対象端末
- Windows 10
- Windows 11
- Zabbix Agent 2
構成イメージ
今回は検証目的のため、専用サーバーではなく既存PCを流用しています。
構築概要
細かなインストール手順は、公式ドキュメントや生成AIでも十分確認できるため、本記事では概要のみ記載します。
1. 既存Windows環境の初期化
既存PCを監視サーバーとして利用するため、Windows環境を初期化しました。
2. Ubuntu Server 22.04 LTS の構築
Ubuntu公式サイトからISOを取得し、Rufusを利用してUSBブートメディアを作成しました。
Ubuntu 22.04 LTSを選定した理由は以下の通りです。
- LTSによる長期サポート
- Zabbixとの相性
- サーバー用途での安定性
Ubuntu公式:
https://releases.ubuntu.com/jammy/
3. MySQLの構築
Zabbix Server用DBとしてMySQLを構築しました。
今回はZabbix Serverと同一端末上に構築しています。
参考:
https://www.tohoho-web.com/ex/mysql.html
4. Zabbix Serverの構築
Zabbix公式サイトの手順を利用して構築しました。
https://www.zabbix.com/jp/download
なお、MySQLを事前に構築しておかないと、手順通り進められない箇所があったため注意が必要でした。
Zabbix Agent 2の導入
監視対象となる各Windows PCへ、Zabbix Agent 2をインストールしました。
Agentを導入することで、
- CPU使用率
- メモリ使用率
- ディスク容量
- Windowsサービス状態
など、Ping監視だけでは取得できない詳細情報を収集できるようになります。
今回は新規構築だったため、従来Agentではなく、より高機能なZabbix Agent 2を採用しました。
インストーラーは以下の公式サイトから取得できます。
https://www.zabbix.com/jp/download_agents
WindowsではMSIインストーラー形式のため、比較的簡単に導入できます。
設定としては主に、
- Zabbix ServerのIPアドレス
- Hostname
を指定する程度で、基本的な監視はすぐ利用できました。
また、インターネット接続のない閉域環境でも、インストーラーさえ持ち込めば構築可能だった点は運用上かなり楽でした。
監視要件とテンプレート設定
今回は主に「端末が利用可能な状態か」を確認するため、以下を監視対象としました。
- Zabbix Agent2サービス稼働確認
- リモート接続用サービス稼働確認
- CPU使用率
- メモリ使用率
- ディスク容量
特にAgent2監視を入れたことで、
「PC自体は起動しているが、監視エージェントが停止している」
という状態を検知できるようになった点は大きかったです。
テンプレートの活用
Zabbix Agent用テンプレートを適用することで、以下の監視項目を自動で取得できました。
- CPU使用率
- メモリ使用率
- ストレージ使用率
- Windowsサービス監視
基本的な監視はテンプレート適用だけで利用できたため、導入コストはかなり低く感じました。
一方で、Windowsサービス監視では「停止していても問題ないサービス」まで障害として検知されるケースがありました。
そのため実運用では、
- 不要サービスを監視除外
- 必要サービスのみ個別監視
といった調整を行っています。
特にリモート接続関連サービスについては、専用テンプレートとして分離することで管理しやすくしました。
障害通知の設定
Zabbixでは、障害発生時にメールやTeamsへ自動通知できます。
今回はメール通知を利用し、以下の条件で発報するよう設定しました。
- Zabbix Agentサービス停止
- リモート接続サービス停止
- Zabbixテンプレート上の重大障害
障害が一定時間（約3分）継続した場合に通知されるよう設定しています。
また、メール件名へ特定キーワードを含めることで、クライアント側の通知ルールとも連携できるようにしました。
実際に感じた効果
監視導入後は、
- 「使おうと思ったら端末が停止していた」
- 「Windows Update後にPCが停止していた」
- 「誰も異常に気づいていなかった」
という状況を事前に把握できるようになりました。
今までは、実際にリモートデスクトップ接続しないと端末状態を把握できませんでした。
以前は障害発生から半日〜1日程度気づけないこともありましたが、現在は障害検知から復旧まで10分程度で対応できるようになっています。
監視導入後は、
「利用前に障害へ気づける」
状態になったことで、運用負荷がかなり下がったと感じています。
監視というとサーバーやネットワーク機器のイメージが強いですが、
実際には、
- 「たまにしか使わない端末」
- 「誰も状態を見ていない端末」
ほど、監視による効果が大きいと感じました。
今後の課題
アプリケーションログ監視
アプリケーションログ内の ERROR 文字列検知や、Windowsイベントログ監視なども今後実施したいと考えています。
また、タスクスケジューラー実行結果なども監視対象に加えることで、より実運用に近い監視へ拡張できそうです。
自動復旧との連携
現在は障害検知と通知までですが、
- サービス再起動
- スクリプト実行
- 自動復旧処理
などと連携できれば、さらに運用負荷を下げられると感じています。
また、「障害発生時にどう対応するか」を手順化できれば、属人化の軽減にも繋がると考えています。
まとめ
今回の構築を通して、
「監視」はサーバーだけではなく、
“普段使われないクライアント端末” にこそ価値がある
と感じました。
特に、
- リモート利用前提
- 台数が増えてきた
- 手動確認が限界
といった環境では、小規模でも監視を入れる価値は十分あると思います。
同じような課題を抱えている方の参考になれば幸いです。