4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@zerong-song(Zerong Song)
in

Amazon CloudWatch Logs メトリクスフィルターの Filter Pattern 入門｜実際のログで検証してみた

4
Last updated at Posted at 2026-09-17

はじめに

Amazon CloudWatch Logs のメトリクスフィルター（Metric Filter） を利用すると、条件に一致したログイベントを CloudWatch メトリクスへ変換できます。

CloudWatch Alarm や Amazon SNS と組み合わせることで、次のような監視が可能です。

  • CloudTrail の AccessDenied を通知する
  • Root ユーザーの利用を検知する
  • Lambda のエラーを通知する
  • Web サーバーの HTTP エラーを監視する
  • アプリケーションログの ERROR を監視する

一方で、メトリクスフィルターを設定する際に悩みやすいのが、ログイベントの判定条件を記述する Filter Pattern です。

CloudWatch Logs のメトリクスフィルターでは、Filter Pattern を正しく記述できないと、通知したいログが検知されなかったり、逆に不要なログまで通知されたりします。

CloudWatch コンソールにはサンプルが用意されていますが、「どの Pattern を使えばよいのか」「Regex はどのように書くのか」と迷うことも少なくありません。

フィルターパターンの入力欄とサンプル

そこで本記事では、代表的な Filter Pattern を実際のログを使って検証します。

Filter Pattern の種類

Filter Pattern は、対象となるログの形式に応じて使い分けます。

種類 対象ログ 主な用途
Standalone Pattern プレーンテキストログ ERRORやWARNなどの文字列検索
Space-delimited Pattern スペース区切りログ ApacheやNginxなどのアクセスログ
JSON Pattern JSONログ CloudTrailやLambdaなどのログ

また、Regex（正規表現）は、Standalone Pattern、Space-delimited Pattern、JSON Pattern の中で利用できます。Regex を利用する場合は、正規表現部分を%...% で囲んで記述します。

たとえば、次の Pattern は通常の文字列検索です。

ERROR

%...% で囲むと、Regex として評価されます。

%ERROR%

JSON Pattern でも、次のように Regex を指定できます。

{ $.statusCode = %4[0-9][0-9]% }

本記事では、次の3種類の Pattern を検証します。

  1. Standalone Pattern
  2. Space-delimited Pattern
  3. JSON Pattern

あわせて、それぞれの Pattern で利用できる Regex の記述方法についても確認します。

検証環境

今回は、CloudWatch Logs メトリクスフィルターの作成画面にある 「パターンのテスト」 機能を利用します。

それぞれの Pattern について、次の観点で確認します。

  • どのようなログに利用するのか
  • Filter Pattern をどのように記述するのか
  • どのログが条件に一致するのか

検証① Standalone Pattern

Standalone Pattern とは

Standalone Pattern は、プレーンテキストログから特定の文字列を検索する、最もシンプルな Filter Pattern です。

今回は次のサンプルログを利用します。

INFO Application started
WARN CPU usage is high
ERROR Database connection failed
INFO Shutdown completed

ERROR を含むログだけを検出する場合は、次のように記述します。

ERROR

検証結果 は下表の通りです。

ログ 一致
INFO Application started ❌
WARN CPU usage is high ❌
ERROR Database connection failed ✅
INFO Shutdown completed ❌

期待どおり、ERROR を含むログだけが一致しました。

Standalone Pattern のテスト結果

Standalone Pattern は、アプリケーションログやシステムログから、ERROR、WARN、Exception などを検出する用途に適しています。

Regex を利用する場合

Standalone Pattern では、Regex も利用できます。

%ERROR%

単純な ERROR の検索では通常の文字列検索と大きな違いはありませんが、複数の文字列や一定の規則を持つ文字列を検索する場合に便利です。

Regex の詳しい例は、後半で紹介します。

検証② Space-delimited Pattern

Space-delimited Pattern とは

Space-delimited Pattern は、スペース区切りで出力されるログを対象とした Filter Pattern です。

JSON Pattern のようにキー名を指定するのではなく、各フィールドの位置を定義して条件を指定します。

主に次のようなログで利用できます。

  • Apache Access Log
  • Nginx Access Log
  • スペース区切りのカスタムログ

今回は、Apache のアクセスログを例に検証します。

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326
192.168.10.10 - john [10/Oct/2000:14:02:31 -0700] "GET /login HTTP/1.1" 404 1024
10.0.0.10 - alice [10/Oct/2000:14:05:10 -0700] "POST /login HTTP/1.1" 500 2048

各フィールドは次のように定義できます。

[ip, identity, user, timestamp, request, status_code, size]

ip や status_code などのフィールド名は任意に指定できます。
重要なのは、実際のログにおける各フィールドの順序と、Filter Pattern の定義順を一致させることです。

HTTP 4xx を検出する

HTTP ステータスコードが 4xx のログだけを検出する場合は、次のように記述します。

[ip, identity, user, timestamp, request, status_code = 4*, size]

検証結果 は以下の通りです。

HTTP Status 一致
200 ❌
404 ✅
500 ❌

期待どおり、404 のログだけが一致しました。

HTTP 4xx のテスト結果

ワイルドカードを利用する

評価しないフィールドは、... を使って省略できます。

[..., status_code = 4*, size]

フィールド数が多い場合は、すべてのフィールドを記述するよりも簡潔に記述できます。

... は 1 つの Filter Pattern 内で 1 回だけ利用できます。

たとえば、次のように前後へ同時に指定するとエラーになります。

[..., status_code = 4*, ...]

エラーメッセージ:

Duplicate field '...'

ただし、Space-delimited Pattern はログの構造に依存します。ログ形式やフィールドの順番が変更された場合は、Filter Pattern も見直す必要があります。

検証③ JSON Pattern

JSON Pattern とは

JSON Pattern は、JSON のキーと値を指定してログを検索する Filter Pattern です。

CloudTrail や Lambdaのログ など、多くの AWS サービスが JSON 形式のログを出力するため、AWS 環境では利用する機会が多い Pattern です。

今回は、次の CloudTrail 形式のサンプルログを利用します。

{
  "eventVersion": "1.11",
  "eventTime": "2026-07-30T10:00:00Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "CreateUser",
  "sourceIPAddress": "192.168.12.123",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "alice"
  },
  "errorCode": "AccessDenied",
  "responseElements": null,
  "readOnly": false
}

文字列の完全一致

eventName が CreateUser のイベントだけを検出する場合は、次のように記述します。

{ $.eventName = "CreateUser" }

検証結果 は「一致」です。

文字列の完全一致のテスト結果

CloudTrail の API 名など、特定の値を監視する場合に利用できます。

ネストした JSON を検索する

ネストした項目は、. を使って階層を指定します。

たとえば、userIdentity の中にある userName を検索する場合は、次のように記述します。

{ $.userIdentity.userName = "alice" }

検証結果 は「一致」です。

ネストしたJSONのテスト結果

複数条件を組み合わせる

複数の条件を && で組み合わせることもできます。

{
  ($.eventName = "CreateUser")
  &&
  ($.errorCode = "AccessDenied")
}

この Pattern では、CreateUser API の実行時に AccessDenied が発生したイベントだけが一致します。

検証結果 は「一致」です。

複数条件を組み合わせるテスト結果

存在・Null を判定する

JSON Pattern では、項目の存在や Null も判定できます。

errorCode が存在するイベントを検出する例です。

{ $.errorCode = * }

存在を判定するテスト結果

responseElements が Null のイベントを検出する場合は、次のように記述します。

{ $.responseElements IS NULL }

Nullを判定するテスト結果

キー自体が存在しないイベントは、次の Pattern で検出できます。

{ $.responseElements NOT EXISTS }

NotExistsを判定するテスト結果

IS NULL と NOT EXISTS は意味が異なります。

  • IS NULL：キーが存在し、値が Null
  • NOT EXISTS：キー自体が存在しない

JSON PatternでRegexを利用する

JSON Pattern では、値の条件に Regex を利用することもできます。

Regex は %...% で囲みます。

前方一致

たとえば、sourceIPAddress が 192.168.12. から始まるログを検索する場合は、次のように記述します。

{ $.sourceIPAddress = %^192\.168\.12\.% }
  • ^：文字列の先頭
  • \.：ドットを文字として扱う

検証結果 は「一致」です。

Regexを判定するテスト結果

否定条件

指定した Regex に一致しないログを検出する場合は、!= を利用します。

{ $.sourceIPAddress != %^192\.168\.12\.% }

Regexを判定するテスト結果

この Pattern では、192.168.12. から始まらない IP アドレスが一致します。

特定の送信元 IP アドレスを監視対象から除外する場合などに利用できます。

複数のIPアドレスに一致させる

次の Pattern は、末尾が 120 または 121 の IP アドレスに一致します。

{ $.sourceIPAddress = %^192\.168\.12\.12[0-1]$% }

一致する値は次の2つです。

192.168.12.120
192.168.12.121
  • [0-1]：0または1
  • $：文字列の末尾
    複数のIPアドレスに一致させるテスト結果

Regex利用時の注意点

CloudWatch Logs で Regex を利用する場合は、次の点に注意が必要です。

  • Regex は %...% で囲む
  • . を文字として検索する場合は \. と記述する
  • 利用できる Regex 構文には制限がある
  • 複雑な Pattern は事前にテストする
  • 実際のログ形式や値を確認してから条件を作成する

特に除外条件では、Pattern が想定より広い範囲に一致すると、監視対象となるログまで除外してしまう可能性があります。

設定前に「パターンのテスト」を利用し、一致するログと一致しないログの両方を確認することが重要です。

まとめ

CloudWatch Logs のメトリクスフィルターでは、ログ形式に応じて適切な Filter Pattern を選択することが重要です。

本記事では、3種類の Pattern と Regex の利用方法を実際のログを使って検証しました。

Pattern 対象ログ 主な用途
Standalone Pattern プレーンテキストログ ERRORやWARNなどの文字列検索
Space-delimited Pattern スペース区切りログ HTTPステータスコードなどの検索
JSON Pattern JSONログ キーや値を指定した検索

また、それぞれの Pattern では Regex を利用することで、より柔軟な条件を記述できます。

特に CloudTrail や Lambda のような JSON ログでは、JSON Pattern と Regex を組み合わせることで、AccessDenied の検知や特定 IP アドレスの除外など、柔軟な条件を記述できます。

Filter Pattern を作成する際は、構文だけでなく、対象ログの形式と実際の値を確認することが大切です。

「パターンのテスト」機能を活用し、一致するログと一致しないログの両方を確認しながら調整することをおすすめします。

本記事が、CloudWatch Logs のメトリクスフィルターや Filter Pattern を理解する際の参考になれば幸いです。

参考資料

4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?