MENU
AWSを中心としたクラウドインフラ技術サイト
  1. ホーム
  2. その他
  3. 【CloudWatch】メトリクス監視、イベント監視、ログ監視の設定手順

【CloudWatch】メトリクス監視、イベント監視、ログ監視の設定手順

その他

目次

全体構成

メトリクス監視、イベント監視、ログ監視を組み合わせた監視設定の全体構成は以下のようになります。

【メトリクス監視】

AWS/EC2 標準メトリクス
CWAgent カスタムメトリクス
  ↓
CloudWatch Alarm
  ↓
共通SNS
  ↓
Amazon Q Developer
  ↓
Slack


【イベント監視】

AWS Healthイベント
EC2インスタンス状態変更イベント
  ↓
EventBridge
  ↓
共通SNS
  ↓
Amazon Q Developer
  ↓
Slack


【ログ監視】

EC2上のログ
  ↓
CloudWatch Agent
  ↓
CloudWatch Logs
  ↓
メトリクスフィルター
  ↓
カスタムメトリクス
  ↓
CloudWatch Alarm
  ↓
共通SNS
  ↓
Amazon Q Developer
  ↓
Slack

特徴としては以下になります。

  • メトリクス監視とログ監視は、CloudWatch Alarm が判定・発報
  • イベント監視は、EventBridge がイベントを検出して直接 SNS へ送信
  • SNS は監視や判定をせず、通知を配送するだけ

CloudWatch については以下でも詳しく解説しています。

AWSインフラ研究所
Amazon CloudWatch
https://go-journey.club/archives/14878
Amazon CloudWatch の特徴Amazon CloudWatch は、AWS 環境やアプリケーションの状態を監視するためのサービスです。一言で表すと、AWS 環境の「計器盤・監視カメラ・警報装置」をまとめたサービスです。CloudWatch は、シンプルに CPU 使用率などを見るだけのサービスではありません。主に次の情報を扱います。数値としての状態：メトリクス文字としての記録：ログ異常を判定する仕組み：アラーム状態を一覧表示する画面：ダッシュボードアプリケーションやインフラの可観測性：APM、トレース、異常検知などCloudWatch はメトリクス、...

想定する EC2 インスタンス

以下の EC2 インスタンスを監視する想定です。

リソースNameインスタンスID例
EC2prod-app-01i-0123456789abcdef
EC2prod-app-02i-abcdef1234567890

メトリクス監視

EC2のメトリクス監視は、大きく2種類あります。

EC2 標準メトリクス

エージェントなしで取得できます。

CPUUtilization
StatusCheckFailed_System
StatusCheckFailed_Instance
StatusCheckFailed_AttachedEBS
NetworkIn
NetworkOut
DiskReadBytes
DiskWriteBytes

CloudWatch Agent メトリクス（カスタムメトリクス）

CloudWatch Agent を EC2 に導入すると取得できます。このメトリクスは標準ではないので「カスタムメトリクス」になります。

mem_used_percent
disk_used_percent
swap_used_percent
processes_running

CloudWatch Agent は、EC2 標準監視では取得できない OS 内部のメモリ、ディスク使用率などを追加収集できます。ログ収集にも同じ統合 CloudWatch Agent を使用できます。

今回は、各EC2について次の6個を監視する構成にします。

メトリクス目的カテゴリ
CPUUtilizationCPU高騰標準メトリクス
StatusCheckFailed_SystemAWS基盤側の障害標準メトリクス
StatusCheckFailed_InstanceOS・ネットワーク設定などインスタンス内部の異常標準メトリクス
StatusCheckFailed_AttachedEBSアタッチされたEBSの異常標準メトリクス
mem_used_percentメモリ不足カスタムメトリクス
disk_used_percentディスク容量不足カスタムメトリクス

標準メトリクスとカスタムメトリクスの違い

標準メトリクスとカスタムメトリクスの違いは、「誰が、何をCloudWatchへ送信するか」です。

標準メトリクス

AWS があらかじめ用意し、自動的に CloudWatch へ送信するメトリクスです。

AWSが以下を決めています。

  • 名前空間
  • メトリクス名
  • 単位
  • ディメンション
  • 値の計算方法

AWSサービスの名前空間は、通常 AWS/サービス名 という形式です。例えば EC2 の場合は、AWS/EC2 になります。

以下が主要な AWS/EC2の標準メトリクスです。EC2 を起動すると、AWS が自動的に CloudWatch へ送信するメトリクスです。CloudWatch Agent をインストールしなくても取得できます。

CPUUtilization
DiskReadOps
DiskWriteOps
DiskReadBytes
DiskWriteBytes
MetadataNoToken
MetadataNoTokenRejected

例えば、CPU 使用率を監視する場合は CloudWatch Agent を導入せずに、CPUUtilizationへ直接 CloudWatch Alarm を設定できます。

EC2 のカスタムメトリクス

EC2 内部に CloudWatch Agent をインストールし、OS から取得して CloudWatch へ送信するメトリクスです。CloudWatch Agent のデフォルトの名前空間は CWAgent です。Agent が収集するメトリクスは、EC2 が標準で提供するメトリクスに追加されます。

代表例は次のとおりです。

メトリクス例確認できる内容
mem_used_percentメモリ使用率
disk_used_percentファイルシステムのディスク使用率
swap_used_percentswap使用率
processes_totalプロセス数
netstat_tcp_established確立済みTCP接続数

構成は次のようになります。

EC2内部のOS
  ↓
CloudWatch Agent
  ↓
CWAgent カスタムメトリクス
  ↓
CloudWatch Alarm
  ↓
SNS

たとえば、ルートディスクの使用率が80％を超えたら通知する場合は、次の流れです。

Linuxのディスク使用率
  ↓ CloudWatch Agentが取得
disk_used_percent
  ↓
CloudWatch Alarm
  ↓
SNS

標準メトリクスとカスタムメトリクスの構成まとめ

今回のEC2監視をまとめると、次の構成になります。

【標準メトリクス】
EC2 → AWS/EC2 → CloudWatch Alarm → SNS
・CPUUtilization
・NetworkIn / NetworkOut
・StatusCheckFailed

【カスタムメトリクス】
EC2 OS → CloudWatch Agent → CWAgent → CloudWatch Alarm → SNS
・mem_used_percent
・disk_used_percent
・swap_used_percent

基本モニタリングと詳細モニタリングとの違い

モニタリングには基本モニタリングと詳細モニタリングがあります。

CloudWatch での基本モニタリングと詳細モニタリング

EC2 の「詳細モニタリング」を有効にしても、メモリやディスク使用率が取得できるようになるわけではありません。

基本モニタリング
AWS/EC2標準メトリクスを主に5分間隔で取得

詳細モニタリング
AWS/EC2標準メトリクスを主に1分間隔で取得

CloudWatch Agent
メモリやディスク使用率など、OS内部の情報を取得

詳細モニタリングは、標準メトリクスの取得間隔を細かくする機能です。カスタムメトリクスを追加する機能ではありません。

コストが変わるので注意

種類メトリクス間隔メトリクス料金
基本モニタリング原則5分間隔無料
詳細モニタリング1分間隔メトリクスごとに課金

メトリクス監視（CPUUtilization）アラーム設定

メトリクスを選択する

AWSコンソールで以下のように設定します。

メトリクス名は CPUUtilization にして、統計は 平均値、期間は5分に設定します。

例えば、以下の例では期間を5分に設定しているので、

直近25分のデータポイント5個を確認し、
その3個がしきい値違反ならALARM

となります。3回は連続している必要はありません。

ちなみに Evaluation とは、日本語で 「評価」「判定」 という意味です。

CloudWatchの Evaluation periods は、アラーム判定のために確認するデータポイントの数 を表します。

用語意味
Evaluation periods評価対象にするデータポイント数
Datapoints to alarmそのうち異常である必要がある個数

通知を設定する

SNS トピックを新規で作成して通知の設定をします。

最後にアラーム名を設定して完了です。

CloudWatch の画面上では下図のようになります。

EC2 の状態変更（State Change）イベント検知

EC2インスタンス2台
  ↓ 状態が変わる
Amazon EventBridge
  ↓ 条件に一致
Amazon SNS
  ↓
Amazon Q Developer in chat applications
  ↓
Slack

イベント ID がない EC2 インスタンスの場合

例えば、DMS タスクなどは固定のイベント ID があります。

DMS-EVENT-0069：タスク開始
DMS-EVENT-0078：タスク失敗
DMS-EVENT-0079：タスク停止

EventBridgeイベントでは、次のようにdetail.eventIdに入ります。

{
  "detail": {
    "eventId": "DMS-EVENT-0078",
    "detailMessage": "Replication task has failed."
  }
}

EC2 インスタンスの場合は、JSON で 確認すると id はありますが、固定された イベント ID がありません。

{
  "id": "7bf73129-1428-4cd3-a780-95db273d1602",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "detail": {
    "instance-id": "i-1234567890abcdef0",
    "state": "stopped"
  }
}

このidはイベントが1回発生するごとに生成される一意な UUID です。次に同じ EC2 が再びstoppedになった場合は、別のidになります。固定のイベント種別コードではありません。

項目DMS の detail.eventIdEC2のトップレベル id
例DMS-EVENT-0078UUID
値は固定かイベント種類ごとに固定発生するたびに変わる
何を表すかタスク失敗などのイベント種類そのイベント発生自体の識別子
EventBridgeの絞り込みdetail.eventId通常は使用しない

DMSでは次のようにイベントIDで種類を指定できます。

{
  "detail": {
    "eventId": [
      "DMS-EVENT-0078",
      "DMS-EVENT-0079"
    ]
  }
}

一方、EC2では固定イベントIDがないため、次のフィールドを組み合わせて判定します。

{
  "source": [
    "aws.ec2"
  ],
  "detail-type": [
    "EC2 Instance State-change Notification"
  ],
  "detail": {
    "instance-id": [
      "i-0123456789abcdef0"
    ],
    "state": [
      "stopped",
      "terminated"
    ]
  }
}

EC2状態変更イベントでは、detail-typeで「EC2の状態変更イベント」であることを指定し、detail.stateでrunning、stopped、terminatedなどの変更後の状態を指定します。

DMS
detail-type：DMS Replication Task State Change
detail.eventId：DMS-EVENT-0078
→ タスク失敗を表す固定コード

EC2
detail-type：EC2 Instance State-change Notification
detail.state：stopped
→ 停止状態への変更を表す

EC2では、DMSのイベントIDに近い役割を担うのは、厳密には1項目ではなく、

detail-type ＋ detail.state

の組み合わせです。

EC2 の状態変更（State Change）の監視条件

次の2つだけを監視します。

stopped
terminated

イベントパターン

{
  "source": [
    "aws.ec2"
  ],
  "detail-type": [
    "EC2 Instance State-change Notification"
  ],
  "detail": {
    "instance-id": [
      "i-0123456789abcdef0",
      "i-0abcdef1234567890"
    ],
    "state": [
      "stopped",
      "terminated"
    ]
  }
}

このパターンでは、以下の場合にルールが実行されます。

  • instance-id で指定した2台のいずれか
  • stoppedまたはterminatedになった場合

EC2の状態変更イベントには、detail.instance-idとdetail.stateが含まれます。

通知の設計

今回の状態変更（State Change）通知経路は次のようにします。

EventBridgeルール
  ↓
SNSトピック：prod-monitoring-alerts
  ↓
Amazon Q Developer
  ↓
Slack

EventBridge は「どのイベントを通知するか」を判定します。

SNSは、EventBridge から渡された通知を Amazon Q やメールなどに配送します。

Amazon Q Developer in chat applications を利用する場合、SNSトピックを Slack チャネル設定に関連付けます。EventBridge の入力トランスフォーマーを使うと、EC2イベントを Amazon Q のカスタム通知形式へ変換できます。

EventBridgeルールの作成

「ルールを作成」をクリックしてルールを作成します。

ビルダーモードは「アドバンストビルダー」を選択します。イベントソースは「その他」を選択します。「その他」を選択する理由としては、次のイベントパターンで JSON で設定するからとなります。

イベントパターンの設定

イベントパターンで「カスタムパターン（JSON エディタ）」を選択して、JSON をコピペします。

{
  "source": [
    "aws.ec2"
  ],
  "detail-type": [
    "EC2 Instance State-change Notification"
  ],
  "detail": {
    "instance-id": [
      "i-0123456789abcdef0",
      "i-0abcdef1234567890"
    ],
    "state": [
      "stopped",
      "terminated"
    ]
  }
}

「プレフィックスマッチング」の項目が見えますが、これは現在のイベントパターン全体がプレフィックスマッチングになっているという意味ではありません。これは、JSONエディタへ比較条件を挿入するための補助機能です。「挿入」ボタンをクリックすると、比較条件が挿入されますが、今回はすでに JSON を作っているので無視で良いです。

ターゲットの設定

ターゲットを選択します。今回はすでに作成済みの SNS トピックを利用します。

ロールの設定

必要な場合はタグを設定します。

最後は下図のようにルールが作成されます。

EventBridge の 入力トランスフォーマー を設定する（メールや Slack への通知）

EventBridge の入力トランスフォーマーは、EventBridgeが受け取ったイベントを、SNSトピックへ渡す前に必要な項目だけ取り出して、通知用の分かりやすい形式に加工する機能です。入力トランスフォーマーを使用しない場合は、EC2 から送られてきたイベント全体が、ほぼそのまま SNS へ渡されます。

元イベントの値を JSON パスで変数化し、入力テンプレートによってターゲットへ渡す内容を組み立てる仕組みです。入力テンプレート内では<変数名>として使用します。

EC2で状態変更が発生
        ↓
EventBridgeがEC2イベントを受信
        ↓
イベントパターンで対象か判定
        ↓
入力トランスフォーマーで内容を整形
        ↓
SNSトピックへ送信
        ↓
Amazon Q Developer in chat applications
        ↓
Slackへ通知
設定役割
イベントパターンどのイベントを通知するか
入力トランスフォーマー通知内容をどのような形式にするか
ターゲットどこへ送信するか
SNSトピック通知を各サブスクライバーへ配信する

入力トランスフォーマーは「追加設定」をクリックして展開し、「ターゲット入力を設定」で次を選びます。

入力トランスフォーマー

サンプルイベントを選択

確認のためサンプルイベントを選択します。

今回の場合は、EC2 インスタンスの停止や終了イベントなので以下のように設定します。

  • サンプルイベントタイプ：AWS イベント
  • サンプルイベント：EC2 Instance State-change Notification

上記設定すると下図のようにサンプルイベントが自動的に入力されます。

入力パス

今回の EC2 インスタンスの場合の入力パスは以下になります。

{
  "eventId": "$.id",
  "instanceId": "$.detail.instance-id",
  "state": "$.detail.state",
  "time": "$.time",
  "region": "$.region",
  "resource": "$.resources[0]"
}

それぞれ次の値を取り出します。

変数取得する値
eventIdEventBridgeイベントID
instanceIdEC2インスタンスID
state変更後の状態
time状態変更時刻
regionAWSリージョン
resourceEC2インスタンスARN

メール通知向けの入力テンプレート

SNSからメール通知するだけなら、次のようなシンプルなJSONにできます。

{
  "title": "EC2 instance state changed",
  "instanceId": "<instanceId>",
  "state": "<state>",
  "region": "<region>",
  "time": "<time>",
  "resource": "<resource>"
}

Slack通知向けの入力テンプレート

Amazon Q Developer を通して Slack へ送る場合は、Amazon Q のカスタム通知形式に変換します。

{
  "version": "1.0",
  "source": "custom",
  "id": "<eventId>",
  "content": {
    "textType": "client-markdown",
    "title": ":warning: EC2インスタンスの状態が変更されました",
    "description": "*Instance ID:* `<instanceId>`\n*State:* `<state>`\n*Region:* `<region>`\n*Time:* `<time>`",
    "nextSteps": [
      "EC2コンソールで対象インスタンスを確認する",
      "CloudTrailでStopInstancesまたはTerminateInstancesを確認する",
      "CloudWatchでステータスチェックメトリクスを確認する"
    ],
    "keywords": [
      "EC2",
      "StateChange"
    ]
  },
  "metadata": {
    "threadId": "<instanceId>",
    "summary": "EC2 <instanceId> changed to <state>",
    "enableCustomActions": false
  }
}

Amazon Qのカスタム通知では、versionは1.0、sourceはcustomを指定します。descriptionが通知本文で、同じthreadIdを指定した通知はSlack上でスレッドとしてまとめられます。

Slackでは、次のような通知になります。

⚠️ EC2インスタンスの状態が変更されました

Instance ID: i-0123456789abcdef0
State: stopped
Region: ap-northeast-1
Time: 2026-07-26T00:15:00Z

Next steps
・EC2コンソールで対象インスタンスを確認する
・CloudTrailでStopInstancesまたはTerminateInstancesを確認する
・CloudWatchでステータスチェックメトリクスを確認する

最後にどのように出力されるのか確認します。

Nameタグが通知に含まれない点に注意

標準のEC2状態変更イベントには、インスタンスIDは含まれますが、次のNameタグは含まれません。

prod-app-01
prod-app-02

標準イベントに含まれる主なEC2固有情報は、インスタンスIDと変更後の状態です。

Nameタグを表示する方法には以下のようにインスタンスごとにルールを分ける方法があります。他にも Lambda で Name タグを取得する方法もあります。

prod-ec2-app-01-state-change
prod-ec2-app-02-state-change

SNS トピックポリシーを確認する

EventBridgeからSNSへ通知するには、SNS側でEventBridgeによるPublishを許可する必要があります。

SNSトピックポリシーのStatementに、次の許可を追加します。

{
  "Sid": "AllowEventBridgePublish",
  "Effect": "Allow",
  "Principal": {
    "Service": "events.amazonaws.com"
  },
  "Action": "sns:Publish",
  "Resource": "arn:aws:sns:ap-northeast-1:123456789012:prod-monitoring-alerts"
}

現在の SNS トピックのアクセスポリシー

ちなみにデフォルトの SNS トピックのアクセスポリシーは以下です。

※Principalは"AWS": "*"なのでかなり広くなっています。

{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "__default_statement_ID",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "SNS:GetTopicAttributes",
        "SNS:SetTopicAttributes",
        "SNS:AddPermission",
        "SNS:RemovePermission",
        "SNS:DeleteTopic",
        "SNS:Subscribe",
        "SNS:ListSubscriptionsByTopic",
        "SNS:Publish"
      ],
      "Resource": "arn:aws:sns:ap-northeast-1:295332586563:prod-ec2-monitoring-alerts-topic",
      "Condition": {
        "StringEquals": {
          "AWS:SourceOwner": "295332586563"
        }
      }
    }
  ]
}

EventBridge が SNS トピックをターゲットにする場合、events.amazonaws.comに対するsns:Publish許可を SNS のリソースポリシーへ設定できます。既存ポリシー全体を上書きせず、既存のStatement配列に追加します。

この段階で1度動作確認

まだすべて完了していませんが、この段階で一度 EC2 インスタンスを停止して動作確認をします。

EventBridge のモニタリングからイベントが発生したことが確認できます。

メールは下図のようになります。

ログ監視（CloudWatch Logs）の設定

最も簡単に環境を作る場合は、Windows 上にテスト用のテキストログを作り、CloudWatch Agent でその1ファイルを CloudWatch Logs へ転送する方法です。

今回は次の構成にします。

Windows EC2
C:\CloudWatchTest\app.log
        ↓
CloudWatch Agent
        ↓
CloudWatch Logs
ロググループ：/ec2/windows/test
ログストリーム：EC2インスタンスID

CloudWatch Logs 側ではインスタンス ID ごとにログストリームを分けます。CloudWatch Agent は Windows Server に対応し、通常のテキストファイルや Windows イベントログを CloudWatch Logs へ送信できます。今回は検証しやすいテキストファイルを使用します。

EC2 に IAM ロールを設定する

CloudWatch Agent が CloudWatch Logs へ書き込むには、EC2 インスタンスに IAM ロールが必要です。

IAMロールを新規作成する場合

以下の構成で IAM ロールを作成します。

項目設定
信頼されたエンティティAWSのサービス
ユースケースEC2
許可ポリシーCloudWatchAgentServerPolicy
ロール名EC2-CloudWatchAgent-Role

ポリシーをアタッチすると、下図のようになります。

EC2 インスタンス（Windows）でテスト用ログファイルを作成する

PowerShell を起動し、次のコマンドを実行します。

New-Item -ItemType Directory -Path "C:\CloudWatchTest" -Force

"$(Get-Date -Format o) INFO CloudWatch Logs test started." |
    Out-File -FilePath "C:\CloudWatchTest\app.log" -Encoding utf8 -Append

ファイルの内容を確認します。

Get-Content "C:\CloudWatchTest\app.log"

CloudWatch Agentをインストールする

PowerShell で次を実行します。

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

$msiPath = "$env:TEMP\amazon-cloudwatch-agent.msi"

Invoke-WebRequest `
    -Uri "https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi" `
    -OutFile $msiPath

Start-Process msiexec.exe `
    -Wait `
    -ArgumentList "/i `"$msiPath`" /qn"

インストールされたか確認します。

Test-Path "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1"

CloudWatch Agentの設定ファイルを作る

次の設定では、

  • C:\CloudWatchTest\app.logを収集
  • ロググループを/ec2/windows/testにする
  • ログストリーム名をEC2インスタンスIDにする
  • ログの保持期間を7日にする

という設定を行います。

PowerShellで次を実行します。

$configDirectory = "$env:ProgramData\Amazon\AmazonCloudWatchAgent"
$configPath = "$configDirectory\amazon-cloudwatch-agent.json"

New-Item -ItemType Directory -Path $configDirectory -Force

$config = @'
{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "C:\\CloudWatchTest\\app.log",
            "log_group_name": "/ec2/windows/test",
            "log_stream_name": "{instance_id}",
            "retention_in_days": 7
          }
        ]
      }
    },
    "force_flush_interval": 5
  }
}
'@

$config | Set-Content -Path $configPath -Encoding ASCII

内容を確認します。

Get-Content $configPath

CloudWatch Agentを起動する

次のコマンドを実行します。

$configPath = "$env:ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.json"

& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" `
    -a fetch-config `
    -m ec2 `
    -s `
    -c "file:$configPath"

Agentの状態を確認します。次を実行します。

& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" `
    -a status `
    -m ec2

CloudWatch Logs で確認する

数十秒程度待ってから、AWSコンソールで次を確認します。

CloudWatch
→ ログ
→ ロググループ
→ /ec2/windows/test

中にEC2インスタンスIDのログストリームが作成されます。

ERROR ログを追加して動作確認する

後でメトリクスフィルターを作成できるよう、ERRORを含むログを追加します。

"$(Get-Date -Format o) ERROR This is a CloudWatch Logs test error." |
    Out-File `
        -FilePath "C:\CloudWatchTest\app.log" `
        -Encoding utf8 `
        -Append

ファイルを開いて内容を確認します。

CloudWatch Logsを確認します。

ここからエラーログを SNS トピックに通知する流れ

更にここからエラーログを SNS トピックへ通知するまでの流れです。

Windows EC2のログ
  ↓
CloudWatch Logs
  ↓ 「ERROR」を検出
メトリクスフィルター
  ↓ 1件を数値の1に変換
カスタムメトリクス
  ↓ 1分間の合計が1以上か判定
CloudWatch Alarm
  ↓ ALARMへ変化
共通SNSトピック
項目設定例
ロググループ/ec2/windows/test
フィルターパターン“ERROR”
フィルター名WindowsErrorFilter
メトリクス名前空間Custom/EC2LogMonitoring
メトリクス名ErrorCount
アラーム名prod-windows-ec2-error-log-detected
通知先既存の共通SNSトピック

メトリクスフィルター

CloudWatch Logsに入ってくるログから、指定した文字列や形式に一致するログを探します。

今回の条件は、

"ERROR"

です。

たとえば、次のログは一致します。

2026-07-26T09:30:00+09:00 ERROR This is a CloudWatch Logs test error.

メトリクスフィルターは、ログを直接アラームにするものではありません。一致したログを、後段で監視できる数値データへ変換します。CloudWatch Logsのメトリクスフィルターは、ロググループへ到着するログから条件に一致するイベントを探し、それをCloudWatchメトリクスに変換します。

カスタムメトリクス

ログにERRORが1件あった場合、次の数値を出力します。

ErrorCount = 1

同じ1分間に3件あった場合、Sumで集計すると、

ErrorCount = 3

になります。

CloudWatch Alarm

カスタムメトリクスの値を、しきい値と比較します。

今回は、

1分間のErrorCount合計が1以上

になったら ALARM にします。

SNS

CloudWatch Alarm がOKからALARMへ変わったとき、共通 SNS トピックへ通知を送ります。

SNS は異常を判断するものではなく、CloudWatch Alarm から受け取った通知を、メールや Amazon Q などの購読先へ配信する役割です。CloudWatch Alarm では、ALARM・OK・INSUFFICIENT_DATA など、指定した状態への遷移時に SNS 通知を設定できます。

メトリクスフィルターを作成する

AWS コンソールで次の順に進みます。

CloudWatch
  → ログ
  → ロググループ
  → /ec2/windows/test

ログストリームではなく、ロググループ名を開きます。

その後、次のどちらかから作成画面を開きます。

アクション
  → メトリクスフィルターを作成

または、

メトリクスフィルター タブ
  → メトリクスフィルターを作成

メトリクスフィルターはログストリーム単位ではなく、ロググループに対して作成します。

「メトリクスフィルター」タブをクリックして「メトリクスフィルターを作成」をクリックします。

フィルターパターンに次を入力します。

"ERROR"

次に「パターンをテスト」または「テストするログデータを選択」で、現在のロググループを選びます。

テスト結果に一致件数が表示されれば、フィルターパターンは正常です。

次に カスタムメトリクス を設定します。「次へ」を押すと、メトリクスの割り当て画面になります。

フィルター名

WindowsErrorFilter

フィルター名は、このメトリクスフィルター自体を識別する名前です。

メトリクス名前空間

Custom/EC2LogMonitoring

名前空間は、関連するメトリクスをまとめるフォルダーのようなものです。

今回作成されるメトリクスは、CloudWatch の次の場所に表示されます。

CloudWatch
  → メトリクス
  → すべてのメトリクス
  → カスタム名前空間
  → Custom/EC2LogMonitoring

この名前は自分で決めるもので、AWS側であらかじめ決まっている名前ではありません。

メトリクス名

ErrorCount

最終的なメトリクスは、名前空間とメトリクス名の組み合わせで識別されます。

名前空間：Custom/EC2LogMonitoring
メトリクス名：ErrorCount

メトリクス値

1

これは、1つのログイベントがパターンに一致するたびに、メトリクスへ1を出力するという意味です。

ERRORログ1件
→ 1

ERRORログ3件
→ 1 + 1 + 1
→ Sumで3

デフォルト値

0

デフォルト値は、ログが取り込まれたものの、ERRORに一致するログがなかった期間に出力する値です。

INFOログは到着した
ERRORログは0件
→ ErrorCount = 0

疎（まば）らなメトリクスになることを防ぐため、デフォルト値として0を設定します。ただし、その1分間にログ自体が1件も取り込まれなかった場合は、デフォルト値も出力されず、データポイントは欠落します。

単位

今回のメトリクス値は、ERRORログ1件につき1を出す設定なのでカウントを指定します。

カウント

ディメンション

今回は設定しません。

ディメンション：なし

最も簡単なプレーンテキストログによる監視では、ディメンションを使わず、ロググループ全体のエラー件数を1つのメトリクスとして集計します。

設定を整理すると、次のようになります。

設定項目設定値
フィルター名WindowsErrorFilter
フィルターパターン“ERROR”
メトリクス名前空間Custom/EC2LogMonitoring
メトリクス名ErrorCount
メトリクス値1
デフォルト値0
単位カウント
ディメンションなし

下図のようになります。

実際に通知をテストする

ここまで設定したら、通知を確実にテストします。最初にアラームをOKにしてから、新しい ERROR ログを出します。

CloudWatch Alarm の SNS アクションは、基本的に状態が変化したときだけ実行されます。

OK → ALARM
→ SNS通知あり

ALARM → ALARM
→ 通常、SNS通知なし

アラーム状態が長時間続いても、同じ SNS 通知が毎分繰り返されるわけではありません。アラームアクションは、原則として状態遷移時にだけ実行されます。

INFOログを出す

まず、ERROR ではないログを出します。

"$(Get-Date -Format o) INFO Alarm normal-state test." |
    Out-File `
        -FilePath "C:\CloudWatchTest\app.log" `
        -Encoding utf8 `
        -Append

これにより、ログは取り込まれますが、ERRORには一致しないため、

ErrorCount = 0

が出力されます。

CloudWatch Alarm がOKになるまで待ちます。

ERRORログを出す

アラームがOKになったら、次を実行します。

"$(Get-Date -Format o) ERROR Metric filter test $(Get-Random)" |
    Out-File `
        -FilePath "C:\CloudWatchTest\app.log" `
        -Encoding utf8 `
        -Append

数分待ってメトリクス画面を更新する

ログが CloudWatch Logs に到着した後、次を確認します。

CloudWatch
  → メトリクス
  → すべてのメトリクス
  → カスタム名前空間
  → Custom/EC2LogMonitoring

下図のようになります。

「グラフ化したメトリクス」タブを開き、以下のように設定します。

項目設定値
統計合計（Sum）
期間1分
その他

関連記事