【AWS】CloudWatchで実現する実践的な監視設計 — アラーム設計からダッシュボード構築まで

システムを構築したら次に必要なのが監視です。AWSではCloudWatchが監視の中核を担いますが、「何を」「どう」監視すればいいか迷う方は多いはず。この記事では実務で使える監視設計のパターンを紹介します。

監視の3層モデル

監視は3つのレイヤーで考えると整理しやすいです。まずインフラ層（CPU、メモリ、ディスク）、次にアプリケーション層（レスポンスタイム、エラーレート）、最後にビジネス層（処理件数、売上金額）です。CloudWatchはこの3層すべてをカバーできます。

EC2の必須メトリクス

EC2のデフォルトメトリクスにはメモリ使用率とディスク使用率が含まれていません。CloudWatch Agentをインストールして取得する必要があります。

# CloudWatch Agent設定ファイル例
{
  "metrics": {
    "namespace": "CustomMetrics/EC2",
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": ["disk_used_percent"],
        "resources": ["/"],
        "metrics_collection_interval": 60
      }
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/httpd/error_log",
            "log_group_name": "/ec2/httpd/error",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

アラーム設計のコツ

アラームの閾値は「本当に対応が必要なとき」だけ発火するように設計します。CPU使用率80%で即アラームではなく、「80%以上が5分間連続した場合」のように条件を絞ることで、一時的なスパイクによるノイズアラートを防げます。

resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  alarm_name          = "ec2-cpu-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 3
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 300
  statistic           = "Average"
  threshold           = 80

  dimensions = {
    InstanceId = aws_instance.web.id
  }

  alarm_actions = [aws_sns_topic.alerts.arn]
}

CloudWatch Logsのコスト管理

CloudWatch Logsは取り込み量に応じて課金されるため、DEBUGログをそのまま流すとコストが跳ね上がります。本番環境ではログレベルをWARN以上に設定し、保持期間も30〜90日に設定するのが現実的です。長期保存が必要なログはS3にエクスポートしましょう。

ダッシュボードの構築

ダッシュボードは「見たい情報がひと目で分かる」ことが大切です。おすすめの構成は、上段にアラーム状態のサマリ、中段にレスポンスタイムとエラーレート、下段にリソース使用率（CPU、メモリ、ディスク）を配置するレイアウトです。

まとめ

監視は「入れて終わり」ではなく、運用しながら閾値やアラート先を調整し続けるものです。最初は必要最小限のメトリクスとアラームから始めて、インシデントの経験をもとに拡充していきましょう。