インフラ

サーバ監視・アラート設計入門｜障害を見逃さない仕組みの作り方

サーバ監視とアラート設計の方法を解説。監視対象の優先順位、通知設計、エスカレーションルールからCloudWatch・Datadog・Zabbixの比較まで紹介します。

サーバ監視アラート設計障害検知運用設計

サーバ監視・アラートの重要性

「サーバーが止まっていることに誰も気づかなかった」「障害発生から3時間後に顧客からの問い合わせで初めて知った」——こうした事態は、中小企業のIT運用でよく耳にします。私がコンサルティングを行う企業でも、監視体制が整っていないことが原因で、ビジネス機会の損失や顧客満足度の低下を招いているケースが少なくありません。

サーバ監視とは、システムの稼働状況を継続的にチェックし、異常を早期に検知する仕組みです。適切な監視とアラート設計により、障害の影響を最小限に抑え、安定したサービス提供が可能になります。

本記事では、サーバ監視の基礎知識から、監視対象の優先順位の付け方、アラート通知の設計、エスカレーションルール、そして代表的な監視ツール（CloudWatch、Datadog、Zabbix）の比較まで、実例を交えて解説します。インフラ設計全般についてはインフラ設計入門もあわせてご覧ください。

サーバ監視の基礎知識

監視の目的と種類

サーバ監視の目的は、大きく分けて以下の3つです。

1. 障害の早期検知 サーバーやアプリケーションの異常を早期に発見し、迅速に対応するための監視です。ダウンタイムを最小限に抑え、ビジネスへの影響を軽減します。

2. パフォーマンスの把握 CPU使用率、メモリ使用率、ディスクI/O、ネットワーク帯域などのリソース状況を継続的に監視し、ボトルネックを特定します。パフォーマンス劣化の予兆を捉えることで、障害が発生する前に対策を講じられます。

3. キャパシティプランニング 長期的なリソース使用状況のトレンドを分析し、将来的なリソース不足を予測します。これにより、計画的なサーバー増強やスケールアップが可能になります。

監視の種類

サーバ監視には、以下のような種類があります。

死活監視（可用性監視） サーバーやサービスが稼働しているかを確認する、最も基本的な監視です。pingによるネットワーク到達性の確認や、特定のポート（HTTP、SSH、DBなど）への接続確認を行います。

リソース監視 CPU、メモリ、ディスク、ネットワークなどのリソース使用状況を監視します。閾値を超えた場合にアラートを発信します。

プロセス監視 特定のプロセス（Webサーバー、データベース、アプリケーションなど）が正常に動作しているかを監視します。プロセスが停止していた場合、自動再起動を試みることもあります。

ログ監視 アプリケーションやシステムのログファイルを監視し、エラーメッセージや特定のパターンを検出します。例えば、Webサーバーのエラーログに「500 Internal Server Error」が頻出していないかをチェックします。

合成監視（シンセティック監視） 実際のユーザー操作をシミュレートして、サービスが正常に動作しているかを確認します。例えば、ECサイトであれば「商品検索 → カート追加 → 購入」という一連の操作を定期的に実行し、正常に完了するかをチェックします。

外形監視 外部から、WebサイトやAPIにアクセスして、応答時間や正常性を確認します。社内ネットワークからの監視だけでは、外部からのアクセス時の問題を検知できないため、外形監視が重要です。

監視の粒度と頻度

監視を実施する際には、「どれくらいの頻度で監視するか」も重要です。

  • 常時監視: 秒単位〜数分単位で監視（死活監視、リソース監視）
  • 定期監視: 時間単位〜日単位で監視（ログ監視、バックアップ確認）
  • 手動監視: 月次や四半期ごとに手動でチェック（セキュリティパッチ適用状況、ディスク使用量のトレンド分析）

頻度が高いほどリアルタイムに異常を検知できますが、監視システムの負荷やアラート通知の頻度も増えます。バランスを考慮して設定してください。

監視対象の優先順位の付け方

全てのサーバー、全てのメトリクスを同じように監視すると、運用負荷が高まり、重要なアラートが埋もれてしまいます。監視対象に優先順位を付け、重要度の高いものから順に監視体制を整えることが重要です。

ビジネスインパクトによる分類

監視対象を、ビジネスへの影響度によって分類します。

重要度: 高（Critical） ビジネスの継続に直結するシステムです。停止すると、売上損失や顧客満足度の低下に直結します。

例：

  • ECサイトのWebサーバー、データベース
  • 基幹業務システム（受発注システム、在庫管理システム）
  • 決済システム

重要度: 中（Warning） 業務に影響があるが、短時間の停止であれば許容できるシステムです。

例：

  • 社内向けファイルサーバー
  • グループウェア（メール、スケジュール管理）
  • 社内Wikiや情報共有ツール

重要度: 低（Info） 停止しても業務への影響が限定的なシステムです。

例：

  • 開発環境、テスト環境
  • 社内向けダッシュボード（参照のみ）
  • ログ集約サーバー（短時間の停止なら問題なし）

この分類をもとに、重要度の高いシステムから優先的に監視を整備します。

監視すべきメトリクスの選定

各サーバーやサービスについて、監視すべきメトリクスを選定します。全てのメトリクスを監視すると、アラートが多すぎて対応できなくなります（アラート疲れ）。以下の観点で絞り込んでください。

1. 障害の兆候を捉えられるか そのメトリクスが異常値を示した場合、実際に障害が発生している、または発生する予兆と言えるかを考えます。

例：

  • CPU使用率が90%を超える → Webサーバーの応答が遅延している可能性
  • ディスク使用率が95%を超える → ログファイルやデータが書き込めなくなる可能性

2. 対応可能か アラートを受け取った際に、具体的な対応アクションが明確かを考えます。対応方法が不明なアラートは、無視されがちです。

例：

  • メモリ使用率が高い → アプリケーションの再起動、メモリの増設
  • ディスク使用率が高い → 不要ファイルの削除、ディスクの拡張

3. ビジネス影響が大きいか そのメトリクスの異常が、ビジネスに大きな影響を及ぼすかを考えます。

例：

  • ECサイトのレスポンスタイムが5秒を超える → 顧客離脱率の上昇
  • データベースの接続数が上限に達する → 新規注文を受け付けられない

最小限の監視項目

IT担当者のリソースが限られる中小企業では、まず以下の項目を監視することをおすすめします。

1. 死活監視

  • サーバーへのping（ICMPエコー）
  • 主要サービスのポート監視（HTTP:80/443、SSH:22、DB:3306/5432など）

2. リソース監視

  • CPU使用率（閾値: 80%以上が5分間継続）
  • メモリ使用率（閾値: 90%以上）
  • ディスク使用率（閾値: 85%以上）

3. プロセス監視

  • Webサーバー（Apache、Nginxなど）
  • データベース（MySQL、PostgreSQLなど）
  • アプリケーションサーバー（Node.js、Javaなど）

4. 外形監視

  • WebサイトのHTTPステータスコード（200 OK以外は異常）
  • レスポンスタイム（閾値: 3秒以上）

これらの項目を監視するだけでも、主要な障害の多くを検知できます。

アラート通知の設計

監視によって異常を検知した後、どのように通知するかを設計します。通知設計が不適切だと、重要なアラートを見逃したり、逆にアラートが多すぎて無視されたりします。

通知手段の選定

アラート通知の手段として、以下のようなものがあります。

メール 最も一般的な通知手段です。詳細な情報を送信でき、記録も残ります。ただし、メールを常時確認していないと、通知に気づくのが遅れる可能性があります。

SMS（ショートメッセージ） 携帯電話番号に直接メッセージを送信します。メールよりも気づきやすく、緊急度の高いアラートに適しています。ただし、コストがかかります（1通あたり数円〜数十円）。

電話（音声通話） 自動音声で通知します。最も確実に気づける手段ですが、コストが高く、頻繁に使うとストレスになります。Critical（最重要）なアラートのみに限定すべきです。

チャットツール（Slack、Microsoft Teams、LINE WORKSなど） チャットツールの特定のチャネルにアラートを投稿します。チーム全体で共有でき、確認状況も可視化できます。最近では、この方法が主流になりつつあります。

監視ダッシュボード 監視ツールのWebダッシュボードで、現在のアラート状況を一覧表示します。通知ではなく、能動的に確認する必要があります。

通知先の設定

通知先は、アラートの重要度によって変えるべきです。

重要度: Critical（緊急）

  • 通知先: IT担当者、場合によっては経営層
  • 通知手段: SMS + チャット + メール
  • 通知タイミング: 即座

重要度: Warning（警告）

  • 通知先: IT担当者
  • 通知手段: チャット + メール
  • 通知タイミング: 即座

重要度: Info（情報）

  • 通知先: IT担当者
  • 通知手段: チャットまたはメール
  • 通知タイミング: まとめて送信（例: 1時間ごと）

例えば、「ECサイトのWebサーバーがダウン」はCritical、「ファイルサーバーのディスク使用率が85%」はWarning、「開発環境のサーバーのCPU使用率が80%」はInfo、といった具合です。

アラート疲れ（Alert Fatigue）の防止

アラートが多すぎると、重要なアラートを見逃したり、全てのアラートを無視するようになったりします。これを「アラート疲れ」と呼びます。

アラート疲れを防ぐための対策

1. 閾値の適切な設定 閾値が低すぎると、軽微な変動でアラートが頻発します。過去のデータをもとに、適切な閾値を設定してください。

2. 複数回の確認 一時的なスパイクでアラートが発火しないよう、「閾値を超えた状態が5分間継続した場合」などの条件を設定します。

3. アラートの集約 同じ原因で複数のアラートが発火する場合、それらを集約して1つの通知にまとめます。例えば、Webサーバーがダウンした場合、「死活監視のアラート」「プロセス監視のアラート」「外形監視のアラート」が同時に発火しますが、これらを1つにまとめます。

4. メンテナンス期間の設定 計画メンテナンス中は、アラート通知を一時的に停止します。誤検知による不要なアラートを防げます。

5. 定期的なレビュー 月次で、どのアラートが発火したか、実際に対応が必要だったかをレビューします。不要なアラートは閾値を見直すか、無効化します。

エスカレーションルールの設計

アラートを受け取った担当者が対応できない場合、または一定時間対応されなかった場合に、自動的に上位者や他の担当者にエスカレーションする仕組みが重要です。

エスカレーションのパターン

時間ベースのエスカレーション アラート発火後、一定時間対応されなかった場合に、次の担当者に通知します。

例：

  1. アラート発火 → IT担当者Aに通知
  2. 15分後も未対応 → IT担当者BとマネージャーCに通知
  3. 30分後も未対応 → 経営層に通知

重要度ベースのエスカレーション アラートの重要度に応じて、通知先を変えます。

例：

  • Critical: IT担当者全員 + マネージャーに即座に通知
  • Warning: IT担当者に通知、30分後に未対応ならマネージャーに通知
  • Info: IT担当者にのみ通知、エスカレーションなし

オンコール（On-call）ローテーション 複数の担当者で、24時間365日の対応体制を組む場合、週ごとや日ごとに担当者を交代します。監視ツールの多くは、オンコールスケジュールを設定し、その時間帯の担当者に自動的に通知する機能を持っています。

中小企業では、IT担当者が1〜2名のことが多く、オンコールローテーションを組むのは難しいかもしれません。その場合は、外部のマネージドサービスや保守契約を活用することを検討してください。

エスカレーションルールの例

以下は、従業員数80名の企業における、ECサイトのエスカレーションルールの例です。

平日 9:00〜18:00（営業時間内）

  1. アラート発火 → IT担当者（Slack + メール）
  2. 10分後も未対応 → IT担当者 + 情報システム部長（SMS + Slack）
  3. 30分後も未対応 → 経営層（電話）

平日 18:00〜翌9:00、休日（営業時間外）

  1. アラート発火 → IT担当者（SMS + Slack + メール）
  2. 15分後も未対応 → 外部保守ベンダー（電話 + メール）
  3. 30分後も未対応 → 経営層（電話）

このように、営業時間内と時間外でルールを変えることで、柔軟な対応が可能になります。

代表的な監視ツールの比較

サーバ監視を実施するには、監視ツールの導入が必要です。ここでは、代表的な3つのツール（CloudWatch、Datadog、Zabbix）を比較します。

AWS CloudWatch

概要 AWS（Amazon Web Services）が提供する監視サービスです。AWSのリソース（EC2、RDS、Lambda、S3など）を監視するための標準的なツールです。

メリット

  • AWSリソースとの統合が容易（設定不要で基本メトリクスを収集）
  • EC2インスタンスのメトリクス（CPU、ネットワーク、ディスクI/Oなど）を自動収集
  • カスタムメトリクスにも対応
  • AWS環境を利用している場合、追加コストが比較的低い

デメリット

  • AWS以外の環境（オンプレミス、他のクラウド）の監視には適さない
  • ダッシュボードのカスタマイズ性がやや低い
  • アラート設定が若干複雑

料金

  • 基本メトリクス: 無料（5分間隔）
  • 詳細メトリクス: 1メトリクスあたり月額$0.30（1分間隔）
  • カスタムメトリクス: 最初の1万メトリクスまで月額$0.30/メトリクス
  • アラーム: 月額$0.10/アラーム

推奨ケース

  • AWSを主に利用している中小企業
  • インフラ構築を簡素化したい場合

詳しくはクラウドコスト最適化の実践ガイドもご覧ください。

Datadog

概要 クラウド型の統合監視プラットフォームです。サーバー、クラウド、アプリケーション、ログなど、あらゆる監視対象を一元管理できます。

メリット

  • マルチクラウド対応（AWS、Azure、GCP、オンプレミス）
  • 豊富なインテグレーション（400種類以上）
  • 直感的で見やすいダッシュボード
  • APM（Application Performance Monitoring）機能で、アプリケーションのパフォーマンスも監視可能
  • ログ収集・分析機能が強力

デメリット

  • 料金が高め（特に大規模環境）
  • 日本語ドキュメントが少ない

料金

  • Infrastructure Monitoring: ホストあたり月額$15〜（Pro）、$23〜（Enterprise）
  • APM: ホストあたり月額$31〜
  • Log Management: 100万イベントあたり月額$0.10〜
  • 14日間の無料トライアルあり

推奨ケース

  • 複数のクラウドやオンプレミスを併用している企業
  • 高度なダッシュボードやログ分析が必要な場合
  • 予算に余裕がある中〜大規模企業

Zabbix

概要 オープンソースの監視ツールです。オンプレミス環境に自前で構築して利用します。

メリット

  • 無料で利用可能（オープンソース）
  • 非常に柔軟なカスタマイズが可能
  • エージェントレス監視（SNMP、IPMI）にも対応
  • テンプレート機能で、一度設定すれば複数サーバーに適用可能
  • 日本語対応が充実

デメリット

  • 初期構築と運用に専門知識が必要
  • クラウド型監視ツールに比べて、導入のハードルが高い
  • UIがやや古く、直感的でない

料金

  • ソフトウェア自体は無料
  • 構築・運用には技術者のリソースが必要
  • 商用サポートは有償（Zabbix LLC）

推奨ケース

  • オンプレミス環境が中心の企業
  • コストを最小限に抑えたい場合
  • IT担当者に技術力があり、自前で構築・運用できる場合

ツール比較まとめ

ツール対象環境料金導入難易度推奨ケース
CloudWatchAWS中心低〜中低AWS環境が中心の中小企業
Datadogマルチクラウド高低複数クラウド併用、高度な監視が必要
Zabbixオンプレミス中心無料（構築コスト別）高オンプレミス中心、コスト重視

監視ツールの導入手順

ここでは、監視ツールを導入する際の基本的な手順を紹介します。

ステップ1: 要件定義

まず、以下の要件を明確にします。

  • 監視対象のサーバー・サービス（台数、OS、ミドルウェア）
  • 監視項目（死活監視、リソース監視、ログ監視など）
  • 通知先（担当者、通知手段）
  • 予算（初期費用、ランニングコスト）

ステップ2: ツール選定

要件に基づき、監視ツールを選定します。前述の比較表を参考にしてください。予算が限られる場合は、まずCloudWatch（AWS環境）やZabbix（オンプレミス）から始めるのがよいでしょう。

ステップ3: エージェントのインストール

多くの監視ツールは、監視対象サーバーに「エージェント」と呼ばれるソフトウェアをインストールする必要があります。エージェントは、サーバーのメトリクスを収集し、監視ツールに送信します。

例：Datadogエージェントのインストール（Linuxの場合）

DD_API_KEY=your_api_key bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)"

ステップ4: 監視項目の設定

監視ツールの管理画面で、監視項目を設定します。

  • 死活監視: 対象サーバーのIPアドレスを登録
  • リソース監視: CPU、メモリ、ディスクの閾値を設定
  • プロセス監視: 監視対象のプロセス名を指定

ステップ5: アラート通知の設定

アラートの通知先（メール、Slack、SMSなど）を設定します。重要度に応じて通知先を変えることを忘れずに。

ステップ6: ダッシュボードの作成

監視状況を一覧できるダッシュボードを作成します。ダッシュボードには、以下のような情報を表示します。

  • 全サーバーの稼働状況（正常/異常）
  • CPU、メモリ、ディスクの使用率グラフ
  • 最近のアラート一覧

ステップ7: 運用開始とチューニング

監視を開始した後、1〜2週間は閾値やアラート設定を見直しながら調整します。誤検知が多い場合は閾値を緩め、逆に見逃しがある場合は閾値を厳しくします。

失敗しやすいポイント

サーバ監視・アラート設計で、中小企業が陥りがちな失敗パターンを紹介します。

1. 監視はしているが、誰も見ていない

監視ツールを導入したものの、ダッシュボードを誰も確認しておらず、アラートメールも読まれていないケースがあります。

対策

  • アラートは、確実に気づける手段（Slack、SMS）で通知
  • ダッシュボードを週次のミーティングで共有する運用を確立
  • 「アラートを受け取ったら30分以内に確認」などのルールを明文化

2. アラートが多すぎて無視される

閾値が低すぎて、軽微な変動で大量のアラートが発生し、全て無視されるようになってしまうケースがあります。

対策

  • 閾値を適切に設定（過去のデータをもとに調整）
  • 複数回の確認条件を設定（例: 閾値超過が5分間継続）
  • 月次でアラートをレビューし、不要なものは無効化

3. 外形監視を行っていない

社内ネットワークからの監視のみで、外部からのアクセスが正常かを確認していないケースがあります。

対策

  • 外部の監視サービス（例: Pingdom、UptimeRobot）を併用
  • クラウド上に監視用のインスタンスを配置し、外部からアクセスをチェック

4. エスカレーションルールが未整備

担当者が不在や対応不能の場合に、誰にも通知されず、障害が放置されるケースがあります。

対策

  • エスカレーションルールを明文化
  • 複数の連絡先を設定（正担当者、副担当者）
  • 外部保守契約を活用

5. メンテナンス時のアラート停止忘れ

計画メンテナンス中にアラートが大量に発火し、不要な通知が送られてしまうケースがあります。

対策

  • メンテナンス期間を事前に監視ツールに登録し、アラートを一時停止
  • メンテナンス完了後、アラートを再開することを忘れずに

導入事例: Datadogによる統合監視の実現

ここでは、Datadogを導入して統合監視を実現した事例を紹介します。

企業プロフィール

業種: SaaS企業（BtoB向けプロジェクト管理ツール） 従業員数: 60名 インフラ構成: AWS（EC2、RDS、S3、CloudFront） IT体制: SRE（Site Reliability Engineer）2名

課題

同社は、急成長に伴いシステムが複雑化し、以下の課題を抱えていました。

  • CloudWatchのみで監視していたが、アプリケーションレベルの監視が不十分
  • 障害発生時に、どのコンポーネントが原因かの特定に時間がかかる
  • ログが各サーバーに分散しており、横断的な分析が困難
  • カスタマーサポートから「サイトが遅い」と報告されても、原因が不明

また、SRE担当者が少ないため、運用負荷を減らしたいという要望もありました。

導入内容

Datadogの全社導入 Infrastructure Monitoring、APM、Log Managementの3つの機能を導入しました。

1. Infrastructure Monitoring（インフラ監視）

  • 全てのEC2インスタンス（Webサーバー、アプリケーションサーバー）にDatadog Agentをインストール
  • CPU、メモリ、ディスクI/O、ネットワーク帯域を監視
  • RDS（データベース）のメトリクス（接続数、スロークエリ、レプリケーション遅延）を監視

2. APM（Application Performance Monitoring）

  • アプリケーションコードに、Datadogのトレーシングライブラリを組み込み
  • API呼び出しのレスポンスタイム、エラー率を可視化
  • データベースクエリのパフォーマンスを分析

3. Log Management（ログ管理）

  • 全サーバーのアプリケーションログ、アクセスログをDatadogに集約
  • エラーログを自動検知し、アラート通知
  • ログをもとに、ユーザーごとの操作履歴を追跡可能に

アラート設計 以下のアラートを設定しました。

  • Critical: Webサーバーのダウン、APIエラー率が5%超過 → Slack + SMS
  • Warning: CPU使用率が80%超過、データベース接続数が上限の80%超過 → Slack
  • Info: ディスク使用率が85%超過 → Slack（週次サマリー）

ダッシュボードの整備 SRE担当者と経営層が確認するダッシュボードを作成しました。

  • リアルタイムダッシュボード: 現在の稼働状況、アクティブユーザー数、API呼び出し数
  • パフォーマンスダッシュボード: APIのレスポンスタイム、エラー率の推移
  • インフラダッシュボード: 各サーバーのリソース使用状況

成果

障害対応時間の短縮 APMにより、API呼び出しのボトルネックが可視化され、原因特定が迅速化しました。以前は障害の原因特定に平均2時間かかっていたのが、30分程度に短縮されました。

例えば、「特定のAPIが遅い」というアラートに対して、APMのトレース画面で該当のAPIを調査すると、「データベースへの特定のクエリが遅い」ことが即座に判明し、インデックスの追加で解決しました。

ログ分析の効率化 以前は、各サーバーにSSHで接続してログをgrepしていましたが、Datadogのログ検索機能により、全サーバーのログを横断的に検索できるようになりました。特定のユーザーIDでフィルタリングして、そのユーザーの操作履歴を追跡することも容易になりました。

プロアクティブな対応 リソース使用率のトレンドをもとに、「来月にはメモリが不足する」という予測が可能になり、事前にEC2インスタンスをスケールアップしました。障害が発生する前に対策を講じられるようになったことが、大きな成果です。

経営層への可視化 経営層向けに、「現在のアクティブユーザー数」「API呼び出し数」「システム稼働率」などのダッシュボードを共有し、ビジネス状況とシステム状況の両方を可視化しました。

運用のポイント

Datadogの導入初期は、アラートが多すぎる問題がありました。そこで、2週間かけて閾値を調整し、本当に対応が必要なアラートのみに絞り込みました。

また、週次でSRE担当者がダッシュボードをレビューし、パフォーマンス劣化の兆候がないかをチェックする運用を確立しました。

まとめ

サーバ監視とアラート設計は、安定したシステム運用に不可欠です。本記事のポイントをまとめます。

監視の基本

  • 死活監視、リソース監視、プロセス監視、ログ監視、外形監視を組み合わせる
  • ビジネスインパクトの高いシステムから優先的に監視

監視対象の絞り込み

  • 全てを監視するのではなく、障害の兆候を捉えられるメトリクスに絞る
  • 最小限の項目から始め、徐々に拡充

アラート設計

  • 重要度に応じて通知先と通知手段を変える
  • アラート疲れを防ぐため、閾値を適切に設定し、定期的にレビュー

エスカレーション

  • 時間ベースまたは重要度ベースでエスカレーションルールを設定
  • 外部保守契約を活用して、24時間対応体制を確保

ツール選定

  • AWS中心ならCloudWatch
  • マルチクラウドや高度な監視が必要ならDatadog
  • オンプレミス中心でコスト重視ならZabbix

中小企業では、IT担当者のリソースが限られています。完璧を目指すのではなく、まず最小限の監視から始めて、運用しながら改善していくアプローチをおすすめします。

関連記事