CloudWatch に Log Alarm が登場、メトリクスフィルターなしでログから直接アラームを作れるようになった

はじめに

「ログに ERROR が何件か出たらアラートしたい」というとき、これまでの CloudWatch ではメトリクスフィルターでログをカスタムメトリクスに変換し、そのメトリクスに対してアラームを張る、という 2 段構えが必要でした。

2026 年 7 月のアップデートで、Logs Insights のクエリを直接アラームにできる「Log Alarm」が追加されたようです。

本記事では Log Alarm を作成し、ERROR ログを流し込んで実際に ALARM 状態に遷移するところまでを軽く試してみます。

忙しい人のための要約

• Logs Insights のクエリ結果を直接しきい値評価する新しいアラームタイプ「Log Alarm」が追加された
• メトリクスフィルターやカスタムメトリクスを経由せず、filter @message like /ERROR/ のようなクエリがそのままアラームになる
• 裏側では AWS 管理の Scheduled Query が自動作成され、スケジュール実行される
• count(*) by serviceName のような集計で、サービスごとに独立評価するマルチコントリビューターアラームも作れる
• 料金は標準アラーム料金に加えて、クエリのスキャン量課金(東京: $0.0076/GB)が実行のたびにかかる点に注意

Log Alarmとは

Log Alarmは、Logs Insightsクエリをスケジュール実行し、その集計結果をしきい値と比較して状態遷移するアラームです。従来のメトリクスフィルター方式との違いはこんなイメージです。

普段 Logs Insights でアドホックに叩いているクエリを、ほぼそのまま監視に転用できるのがうれしいところかと思います。メトリクスフィルターのパターン構文と Insights のクエリ構文を使い分ける必要がなくなりますし、複数ロググループ横断のクエリも 1 つのアラームにできます。

やってみた

東京リージョンで、ERROR ログの件数を 1 分ごとに監視する Log Alarm を AWS CLI から作成してみます。CLI バージョンは 2.35.21 です。

手順1: ロググループと実行ロールの作成

Log Alarm には、CloudWatch Logs が Scheduled Query を実行するための IAM ロールが必要です。信頼するプリンシパルは logs.amazonaws.com です。

# 検証用ロググループ
aws logs create-log-group --log-group-name /log-alarm-verify

# Scheduled Query 実行ロール
aws iam create-role --role-name LogAlarmQueryRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "logs.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

# クエリ実行に必要な最小権限
aws iam put-role-policy --role-name LogAlarmQueryRole --policy-name query-policy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": [
        "logs:StartQuery",
        "logs:StopQuery",
        "logs:GetQueryResults",
        "logs:DescribeLogGroups"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/log-alarm-verify:*"
    }]
  }'

手順2: Log Alarmの作成

新設の put-log-alarm コマンドを使います。クエリ本体・対象ロググループ・集計式・スケジュールを --scheduled-query-configuration にまとめて渡す構造です。

aws cloudwatch put-log-alarm \
  --alarm-name log-alarm-verify \
  --comparison-operator GreaterThanThreshold \
  --threshold 0 \
  --query-results-to-evaluate 1 \
  --query-results-to-alarm 1 \
  --treat-missing-data notBreaching \
  --scheduled-query-configuration '{
    "QueryString": "fields @timestamp, @message | filter @message like /ERROR/",
    "LogGroupIdentifiers": ["/log-alarm-verify"],
    "ScheduledQueryRoleARN": "arn:aws:iam::123456789012:role/LogAlarmQueryRole",
    "AggregationExpression": "count(*)",
    "ScheduleConfiguration": {
      "ScheduleExpression": "rate(1 minute)",
      "StartTimeOffset": 300
    }
  }'

手順3: ERROR ログを流して ALARM 遷移を確認

ERROR を含むログを 2 件投入します。

aws logs create-log-stream --log-group-name /log-alarm-verify --log-stream-name test-stream
aws logs put-log-events --log-group-name /log-alarm-verify \
  --log-stream-name test-stream \
  --log-events \
    timestamp=$(($(date +%s)*1000)),message="ERROR: payment failed for order 1001" \
    timestamp=$(($(date +%s)*1000+1000)),message="ERROR: payment failed for order 1002"

アラーム状態は describe-alarms で確認できますが、--alarm-types LogAlarm を指定しないと Log Alarm は返ってこない点に注意です(デフォルトはメトリクスアラームのみ)。

aws cloudwatch describe-alarms --alarm-names log-alarm-verify \
  --alarm-types LogAlarm \
  --query 'LogAlarms[0].{State:StateValue,Reason:StateReason}'

30 秒おきにポーリングしたところ、状態は次のように遷移しました。

[20:49:00] State=INSUFFICIENT_DATA   # 作成直後は評価データ不足
[20:50:31] State=OK                  # 初回クエリはログ取り込み前で count(*)=0
[20:51:33] State=ALARM               # 2回目のクエリでERROR 2 件を検知

ALARM 時の StateReason はこうなっていました。投入した2件が 2.0 として評価されているのが分かります。

{
    "State": "ALARM",
    "Reason": "Threshold Crossed: 1 out of the last 1 query results [2.0 (14/07/26 11:49:58)] was greater than the threshold (0.0) (minimum 1 datapoint for OK -> ALARM transition)."
}

途中で一度 OK になっているのは、ログ投入直後の初回クエリ実行時点ではまだログが取り込まれておらず count(*)=0(0 は欠落データではなく有効なデータポイント)と評価されたためのようです。

取り込み遅延が気になるケースでは、EndTimeOffset でクエリ範囲の終端を少し過去にずらすことがドキュメントでも推奨されています。

検証後は aws cloudwatch delete-alarms --alarm-names log-alarm-verify とロググループ・ロールの削除で片付けられます。アラームを消すと管理対象の Scheduled Query も自動で消えます。

気をつけるポイント

• 料金は標準アラーム料金($0.10/月)に加えて、Logs Insightsのスキャン量課金(東京: $0.0076/GB)がクエリ実行のたびにかかります。rate(1 minute) で大きなロググループを広い時間範囲でスキャンすると積み上がるので、filter をクエリの先頭に置く・StartTimeOffset を必要最小限にするのが良さそうです
• アカウント内の Scheduled Query の同時実行は 100 までという制限があります。Log Alarm を大量に作る場合はスケジュールをずらす配慮が必要です

参考リンク

• What's New: Amazon CloudWatch log alarms
• Alarming on logs - Amazon CloudWatch
• Log alarms - Amazon CloudWatch
• Scheduled Queries - Amazon CloudWatch Logs
• Amazon CloudWatch pricing