はじめに

近年、システムの停止やパフォーマンス低下による業務影響は、企業にとって無視できないリスクとなっています。
クラウドとオンプレミスが混在する環境では、どこで何が起きているのかを正確に把握することがこれまで以上に重要になりました。

しかし現場では、
「とりあえずPingだけ監視している」
「アラートが多すぎて誰も見ていない」
といった、“監視はあるが運用できていない状態”に陥りがちです。

本記事では、統合監視ツールであるZabbixを例に、情シスが実務で使える監視設計の考え方を整理します。
単なるツールの使い方ではなく、「どのように監視を整えれば運用が楽になるのか」という視点で解説していきます。

監視を正しく設計することで、トラブルに追われる運用から、トラブルを未然に防ぐことができます。

1. 情シスが監視を整える意味

社内のIT基盤を支える情報システム部門にとって、「監視」は単なるオプションではなく、安定運用のための最初の防波堤です。
トラブルはいつ起こるかわからず、検知が遅れるほど復旧コストは大きくなります。
サーバ停止やネットワーク断といった障害において、最も深刻な問題は「異常に気づくのが遅れること」です。

一方で現場では、監視が後回しになっているケースも少なくありません。
・Ping監視のみで状態を判断している
・アラートが過多で実質的に無視されている
・障害発生時に都度手作業で原因を調査している
このような状態では対応が属人化し、運用負荷は増加し続けます。

こうした課題を解消するためには、Zabbixのような統合監視ツールを用いて「監視を設計する」ことが重要です。

監視の整備は、単にアラート通知の仕組みを構築することではありません。
　・障害の兆候を早期に検知する
　・何が問題かを客観的なデータで捉える
　・担当者が変わっても同じ品質で運用できる
　・「なぜ落ちたのか」を説明できるログを残す

こうした仕組みを作ることで、情シスは “トラブル対応に追われる組織” から “事前に不具合を防ぐ組織” へと変わります。

2. Zabbixの全体アーキテクチャ

Zabbixは、監視のために必要な機能をシンプルな構成でまとめた統合監視ツールです。
情報システム部門が社内インフラを監視する際には多くの要素を扱いますが、
Zabbixではそれぞれの役割が明確に分離されており、全体像を理解しやすい設計になっています。

Zabbixの全体アーキテクチャ

1）Zabbix Server（監視の中枢）
監視データの収集・分析・トリガー判定・アラート送信など、Zabbixの中核となる部分です。
情シスの実務では「監視サーバ＝Zabbix Server」と捉えて問題ありません。

2）Zabbix Agent（サーバの状態を送る役）
監視対象のサーバ（Linux／Windows）にインストールし、各種メトリクスをZabbix Serverへ送信します。
主な取得情報は以下の通りです。
・CPU使用率
・メモリ使用率
・ディスク使用率
・プロセス状態
・ログ情報

サーバ監視においては必須となるコンポーネントです。

3）Frontend（Web管理画面）
監視設定やダッシュボード操作を行うGUIです。
日常的な設定変更や状況確認はほとんどこの画面上で完結します。

4）データベース（MariaDB/PostgreSQL）
監視データや履歴、設定を保存する領域です。
監視対象が増えるほど負荷が集中するため、パフォーマンス設計では重要なポイントとなります。
そのため「ZabbixはDBを育てるツール」と言われることもあります。

よくある構成パターン

運用規模に応じて、構成は以下のように変化します。

1）小規模（〜50台）
・Server／DB／Frontendを1台に集約
・各サーバにAgentを導入
→ 構築がシンプルでコストを抑えられる

2）中規模（50〜300台）
・Server（監視中枢）
・DB（別サーバ）
・Proxy（拠点ごとに配置）
→ 負荷分散により安定した運用が可能

3）クラウド・オンプレ混在
・本社：Zabbix Server
・クラウド（AWS／GCP）：VPNや専用線経由で接続
・拠点：Zabbix Proxy
→ 現在の標準的な構成パターン

まとめ

監視の仕組みをブラックボックス化すると、障害対応で確実に行き詰まります。
・どこでデータを収集しているか
・どこで異常を判定しているか
・どこでアラートが発報されているか

この全体像を理解しておくことで、構築・運用の難易度は大きく下がります。

3. 監視すべき「基本の監視項目」

企業のITシステムを安定運用するうえで、「どこから監視を始めるか」は非常に重要です。

監視範囲を広げすぎると設定やアラートが複雑化し、逆に抜け漏れがあると障害の早期発見ができません。

そのため、情報システム部門が最初に整えるべき基本の監視項目は、以下の5つのカテゴリに整理できます。

リソース監視（CPU / メモリ / ディスク）

■ 理由
システム障害の８～９割はリソース枯渇が原因です。
特にディスク容量不足は、サービス停止に直結するため最優先で監視すべき項目です。

■ 具体的に監視すべき項目
　・CPU 使用率（高負荷状態・スパイク検知）
　・メモリ使用率 / スワップ発生量
　・ディスク使用率（閾値80%/90% 過ぎ）
　・ディスク I/O 待ち（遅延の原因）

■ 実務メモ
ディスク使用率は段階的にアラートを設定するのが一般的です。
　例）
80%＝Warning
　90%＝Critical

プロセス監視（サービスの生死）

■ 理由
本番障害の多くは「サービスが停止していた」という単純な原因で発生します。

■ 監視対象例
　・Web サーバ（nginx, Apache）
　・DB サーバ（MySQL, PostgreSQL）
　・バッチ処理サービス
　・社内システムのdaemon
　・AD/DNS/DHCPなどの基盤サービス

■ ポイント
単なる応答確認だけでなく、「プロセスが存在しているか」まで Zabbix Agent上で確認すると検知精度が向上します。

ネットワーク監視（Ping / ポート応答 / 帯域）

■ 理由
回線障害・ネットワーク分断は、オンプレ・クラウド問わず最も多いインシデント。

■ 監視ポイント
　・Ping 監視（死活）
　・TCP ポートの応答（80/443/22など）
　・ネットワーク帯域の利用率
　・インターフェース障害（Up/Down）

■ 社内での定番
　・ルータ / FW / L2SW の死活
　・社内主要サーバの 80/443/22 応答
　・VPN 装置の状態
　・インターネット回線の冗長切替の検知

ログ監視（エラー発生の早期検知）

■ 理由
障害は「ログに必ずヒントがある」ため。
サービス落ちより先にログが異常を吐くケースが多いです。

■ 監視例
　・/var/log/messages
　・/var/log/secure（不正ログイン検知）
　・nginx/apache の error.log
　・アプリケーション独自ログ

■ ポイント
Zabbix のログ監視は特定ワードを拾う → アラート → 自動復旧処理を実行という運用と相性が良いです。

ハードウェア監視（温度/RAID/電源）

■ 理由
ハード故障は予兆が出ることが多く、早期発見できれば夜間障害を大幅に減らせます。

■ 監視ポイント
　・サーバ温度（高温状態）
　・RAID の劣化（degraded）
　・HDD SMART 状態
　・電源異常 / ファン異常

■ 実務メモ
メーカー提供ツール（iLO/iDRAC/IMM）経由のSNMP監視は必須レベル。

まとめ

最初に優先して整えるべき監視は次の3つです。
　1.Pingとポート応答（死活監視）
　2.CPU・メモリ・ディスク（リソース監視）
　3.主要サービスの稼働状態（プロセス監視）

この3つを押さえるだけでも、「障害に気づけない」という最も深刻なリスクは大きく低減できます。

4. 監視テンプレートの選定

Zabbixの監視は、テンプレートの選び方で品質が大きく左右されます。
テンプレートは「監視項目のパッケージ」であり、適切に選定すれば設定の大半は自動化できます。

一方で、過剰にテンプレートを適用すると、監視項目が数百〜数千に膨れ上がり、サーバ負荷の増大やアラートのノイズ増加につながるため注意が必要です。

まずは標準テンプレートから選ぶ

Zabbix6.x/7.xでは、公式テンプレートが充実しており、多くの環境はこれらでカバーできます。

■ OS 監視
　・Template OS Linux by Zabbix agent / agent2
　・Template OS Windows by Zabbix agent
CPU・メモリ・ディスク・プロセス・ログなど、基本的な監視項目が一通り含まれています。
情報システム部門の環境では、まずこれらを適用するのが基本です。

■ ネットワーク機器監視
　・Template Net Cisco SNMP
　・Template Net Fortinet SNMP
　・Template Net Juniper SNMP
　・Template Net Generic SNMP
ベンダー専用テンプレートと汎用SNMPテンプレートを使い分けることで、幅広い機器に対応できます。

テンプレート適用は「最小限」にする

テンプレートを過剰に適用すると、1台あたりの監視項目数が増えすぎ、次のような問題が発生します。

　・監視サーバの負荷増大
　・アラートが多発して運用不能
　・不要なデータがDBに溜まり爆発

特に「Template App○○」系は項目数が多いため、必要なものだけ後から追加する運用が安定します。

アプリケーション監視は段階的に導入する

まずOS監視を安定させ、その後にアプリケーション監視を追加していきます。

■ 例：Web サーバの監視
　・Template App Apache by HTTP
　・Template App Nginx by HTTP

■ 例：データベース監視
　・Template DB MySQL by Zabbix agent
　・Template DB PostgreSQL
　・Template DB SQLServer

■ 例：仮想基盤
　・Template Virt VMware
　・Template Virt Hyper-V

アプリ監視は項目数が増えやすいため、
「段階的に追加 → アラートチューニング」の流れで調整していくことが重要です。

自社システムは“テンプレート自作”が最適解

標準テンプレートが存在しないシステムについては、
専用テンプレートを作成することで運用効率が大きく向上します。

　例）
・自社Webサービス
　・バッチ処理
　・社内独自システム
　・外部APIの応答監視

■ 自作テンプレートの基本ルール
　・OS用とアプリ用を分離した構成にする。
　・アプリ固有の監視は別テンプレートに切り出す。
　・閾値はテンプレート側で統一する。
　・ホストごとに設定を分散させない（再利用性を確保）。

テンプレート選定の最適なフロー

実務での効率的な進め方は以下の通りです。

■ STEP1：OS標準テンプレートを適用
　→ 死活・リソース・ログなど基本監視を網羅します。

■ STEP2：ネットワーク機器にSNMPテンプレートを適用
　→ Cisco/FortiGate等のベンダー公式テンプレートを最優先にします。

■ STEP3：主要アプリケーションを段階的に追加
　→ 主な対象はApache/Nginx/MySQL/ADなどです。

■ STEP4：自社システムは専用テンプレートを作る
　→ 再利用性と運用効率が向上します。

まとめ

テンプレートを適切に選定することで、以下の点が大きく改善されます。
　・設定工数
　・運用負荷
　・アラートの質
　・監視全体の安定性

「標準テンプレートの追加→必要なアプリの段階的追加→独自テンプレートの作成」
この流れが、情シスが最も失敗しない定番アプローチです。

5. アラート設計のポイント

Zabbix導入時に最も多くの現場が直面する課題が、「アラートが多すぎて運用できない」という問題です。
アラート設計は監視の品質と運用負荷を大きく左右する重要な要素であり、「適切な閾値」と「通知先の整理」ができていれば、監視運用は安定します。

ここでは、実務で失敗しないためのアラート設計のポイントを整理します。

まずは“本当に通知が必要なアラート”を絞ります。

よくある失敗は、テンプレートに含まれるすべての項目をアラート通知してしまうことです。これを行うと、監視は破綻します。
　・通知量が膨大になる。
　・アラート疲れで誰も見なくなる。
　・本当に重要なアラートが埋もれる。
まずは「本当に必要なアラート」のみに絞ることが重要です。

最初に設定すべきアラートは以下のとおりです。
　1. サーバの死活（Ping不応答）
　2. 主要ポートの応答（80／443／22／DBなど）
　3. ディスク使用率90％以上
　4. CPU・メモリの高負荷（90％以上が継続）
　5. 主要サービスの停止（Web／DBなど）
この5点を押さえるだけでも、「障害に気づけない」リスクは大きく低減できます。

閾値を“段階分け”します。（Warning / High）

アラートは段階的に分けることで、対応の優先度が明確になります。

　例）ディスク使用率
　　・Warning：80%
　　・High（Critical）：90%

　例）CPU 使用率
　　・Warning：85%（5分継続）
　　・High：95%（5分継続）

なぜ段階分けが重要なのか？
　・早めの対処（Warning）
　・緊急対応（High）
　の切り分けができ、アラートの重要度が一目でわかるためです。

“継続時間”を入れるとノイズが激減します。

Zabbix の初心者が最もハマりやすいのが、CPU使用率やネットワーク遅延などの 一瞬のスパイク で通知されてしまう問題です。

対策：一定時間継続を条件にする

　例）CPU 使用率が 95%
　→ 300秒（5分）以上継続したら通知

　例）ping の遅延
　→ 単発ではなく 3回連続NGで通知

これだけでノイズが大幅に減り、“見る価値のあるアラート”だけが上がる環境になります。

通知先と時間帯を分けます。

実務では通知の「送り先の設計」が非常に重要です。

■ 営業時間内の通知
　・情シス担当者
　・Teams / Slack などのチャット

■ 営業時間外（深夜）の通知
　・重要度Highのみ通知
　・メール通知に絞る
　・可能ならオンコール担当
Zabbix の “メンテナンス機能” を使えば、バックアップ時間帯・バッチ時間帯のアラート抑止が可能です。

アラートメッセージは“対応に必要な情報”を含めます。

通知内容がわかりづらいと、原因特定に毎回ログインする必要が出てきます。

通知メッセージには以下を含めると実務で強い:
　・ホスト名
　・IP アドレス
　・どのサービスか
　・どの閾値に引っかかったか

例：実務向けの通知テンプレート
【Zabbix Alert – High】
ホスト: {HOST.HOST}
IP: {HOST.IP}
トリガー: {TRIGGER.NAME}
発生時刻: {EVENT.DATE} {EVENT.TIME}
現在の値: {ITEM.LASTVALUE}

🚫アラート設計で避けるべき設定
以下の設定は、運用負荷を大きく増加させるため避ける必要があります。
　・テンプレートにある監視を全部有効化する
　・スパイクを拾ってしまう閾値設定（継続条件なし）
　・検知はできるが誰も見ないアラート通知
　・通知が多すぎて “無視される監視” になる