監視は「死活監視 → リソース監視 → ログ監視」の順で段階的に導入します。Uptime Robotで外部監視を始め、Azure Monitor or Zabbixでサーバー監視を追加。アラート設計はCritical/Warning/Infoの3段階で「アラート疲れ」を防ぎましょう。
なぜ監視が必要か
「サーバーが止まった」「ネットワークが遅い」——障害にユーザーより先に気づくことが監視の目的です。障害が発生してからユーザーに報告されるまでの間に、情シスが検知して初動対応を始められれば、ダウンタイムを最小化できます。
- 障害の早期検知：サーバーダウン、ディスク容量逼迫、メモリリーク等を即座に検知
- 予兆の把握：CPU使用率の緩やかな上昇、ディスク空き容量の減少傾向を事前にキャッチ
- 原因分析：障害発生時の状況をログ・メトリクスから振り返り、根本原因を特定
- キャパシティプランニング：リソースの使用傾向から、増強のタイミングを予測
監視の種類
| 種類 | 対象 | 方法 | 検知できること |
|---|---|---|---|
| 死活監視（Ping監視） | サーバー、ネットワーク機器 | ICMP Pingで応答を確認 | サーバーダウン、ネットワーク断 |
| リソース監視 | CPU、メモリ、ディスク、ネットワーク帯域 | エージェント or SNMP | 過負荷、容量逼迫、メモリリーク |
| サービス監視 | HTTP、HTTPS、SMTP、DNS等 | ポート監視、URL監視 | Webサイトダウン、メール障害 |
| ログ監視 | Windowsイベントログ、syslog、アプリログ | ログ収集・パターンマッチ | エラーの発生、不正アクセスの兆候 |
| APM（アプリ性能監視） | Webアプリの応答時間、エラー率 | APMエージェント | アプリの性能劣化、エラー率上昇 |
Windows Server 2016は2027年1月12日にサポート終了。オンプレ更改・Azure移行・ESUの3択を費用と期間で比較し、現状診断から本番切替までご支援します。
Windows Server 移行支援 を見る →監視ツール比較
| ツール | 種別 | 費用 | 特徴 | 適したケース |
|---|---|---|---|---|
| Zabbix | OSS（オンプレ） | 無料（自前運用） | 高い拡張性、エージェント/SNMP対応、テンプレート豊富 | オンプレサーバーが多い企業 |
| Datadog | SaaS | $15〜/ホスト/月 | クラウドネイティブ、700+インテグレーション、APM統合 | クラウド中心の企業 |
| Azure Monitor | SaaS（Azure） | 従量課金 | Azure環境と完全統合、Log Analytics、Application Insights | Azure利用企業 |
| Mackerel | SaaS（国産） | ¥1,833〜/ホスト/月 | 日本語UI・サポート、はてな運営 | 国内企業、日本語サポート重視 |
| Uptime Robot | SaaS | 無料〜$7/月 | 外部からのURL監視・ポート監視に特化 | Webサイトの死活監視のみ |
| PRTG | オンプレ/クラウド | 100センサーまで無料 | SNMPに強い、ネットワーク機器の監視に最適 | ネットワーク機器が多い企業 |
まずはUptime Robot（無料）でWebサイト・SaaSの外部監視を始め、次にAzure MonitorまたはZabbixでサーバーのリソース監視を追加するのが、コストを抑えた段階的アプローチです。
監視設計のポイント
- 何を監視するかを決める：全部監視しようとせず、ビジネスインパクトの高い対象から優先（メールサーバー、基幹システム、VPN等）
- ベースラインの取得：正常時のCPU使用率、メモリ使用量、ディスクI/Oを1週間計測し、閾値設定の基準にする
- 監視間隔：死活監視は1〜5分、リソース監視は5分、ログ監視はリアルタイムが基本
- データ保持期間：メトリクスは最低90日、ログは最低30日保持。コンプライアンス要件があれば1年以上
アラート設計
監視ツール導入後の最大の課題は「アラート疲れ」です。重要でないアラートが大量に飛ぶと、本当に重要なアラートを見逃します。
| レベル | 条件例 | 通知先 | 対応 |
|---|---|---|---|
| Critical（緊急） | サーバーダウン、ディスク使用率95%以上 | 電話＋SMS＋メール | 即時対応 |
| Warning（警告） | CPU 80%以上が10分継続、ディスク80%以上 | メール＋Slack | 当日中に確認 |
| Info（情報） | バッチ処理完了、バックアップ成功 | ダッシュボード記録のみ | 対応不要 |
- 閾値は段階的に設定：Warning → Criticalの2段階で通知
- フラッピング防止：閾値を行ったり来たりする状態で連続アラートが飛ばないようヒステリシス（復旧閾値）を設定
- メンテナンス時間の設定：計画メンテナンス中はアラートを抑制
外部監視サービス
自前で監視ツールを運用するリソースがない場合、外部のMSP（Managed Service Provider）に監視を委託する選択肢もあります。月額5〜15万円程度でサーバー・ネットワークの24時間監視と一次対応を委託できます。
よくある質問
なぜ監視が必要なのですか？
サーバーダウン・ディスク容量逼迫・メモリリークを即座に検知する障害の早期発見、CPU使用率の緩やかな上昇やディスク空き容量の減少傾向を事前に掴む予兆の把握、障害発生時の状況をログ・メトリクスから振り返る原因分析のためです。
監視にはどんな種類がありますか？
ICMP Pingで応答を確認する死活監視（サーバーダウン、ネットワーク断）、エージェントやSNMPでCPU・メモリ・ディスク・帯域を見るリソース監視（過負荷、容量逼迫、メモリリーク）、そしてサービス監視です。
どのツールを選べばよいですか？
オンプレサーバーが多い企業には無料で拡張性の高いZabbix（OSS、自前運用）、クラウドネイティブ環境には700以上のインテグレーションとAPM統合を持つDatadog（$15〜/ホスト/月）が向きます。
アラートはどう設計しますか？
Critical（サーバーダウン、ディスク使用率95%以上）は電話＋SMS＋メールで即時対応、Warning（CPU 80%以上が10分継続、ディスク80%以上）はメール＋Slackで当日中に確認、Info（バッチ処理完了、バックアップ結果）は記録のみ、という3段階が基本です。
まとめ
監視は「死活監視 → リソース監視 → ログ監視」の順で段階的に導入します。Uptime Robotで外部監視を始め、Azure Monitor or Zabbixでサーバー監視を追加。アラート設計はCritical/Warning/Infoの3段階で「アラート疲れ」を防ぎましょう。