翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
フィルターパターンを使用した JSON ログイベントの語句の一致
ログが JSON 形式で構造化されている場合は、JSON フィルターパターンを使用します。これらのパターンにより、JSON オブジェクト内の特定のフィールドと値をターゲットにできるため、以下に最適です。
アプリケーションログ: ターゲット固有のイベントタイプ、ユーザー IDs、またはエラーコード
AWS サービスログ: CloudTrail、VPC フローログ、またはその他の構造化 AWS ログをフィルタリングする
マイクロサービス: 構造化 JSON を出力するコンテナ化されたアプリケーションをモニタリングする
たとえば、 { $.eventType = "UpdateTrail" }
を使用して特定の CloudTrail イベントを検索したり、予期しない IP 範囲からのトラフィックを識別{ $.sourceIPAddress != 123.123.* }
したりできます。
以下のセクションを展開し、タブを参照して、基本的な単一条件パターンから複雑な複合式まで、一般的なモニタリングシナリオの JSON フィルターパターンを作成する方法を示す例を確認します。
次の例は、一般的なモニタリングおよびトラブルシューティングシナリオで JSON ログイベントでフィルターパターンを使用する方法を示しています。各例には、フィルターパターン構文と適用する実用的なユースケースが含まれています。
これらのパターンは、アプリケーション、 AWS サービス、コンテナ、またはカスタムシステムからの JSON 形式のログで機能します。メトリクスフィルターを使用して CloudWatch メトリクス、他の サービスにログをルーティングするサブスクリプションフィルター、または Live Tail を使用してログをリアルタイムでモニタリングできます。
例の JSON ログイベントを使用して例のフィルターパターンをテストする場合、例の JSON ログを 1 行で入力する必要があります。
テスト用のサンプル JSON ログイベント:
{
"eventType": "UpdateTrail",
"sourceIPAddress": "111.111.111.111",
"arrayKey": [
"value",
"another value"
],
"objectList": [
{
"name": "a",
"id": 1
},
{
"name": "b",
"id": 2
}
],
"SomeObject": null,
"cluster.name": "c"
}
- Monitor application events by type
-
JSON アプリケーションログ内の特定のイベントタイプを追跡して、システム動作をモニタリングします。
フィルターパターン:
{ $.eventType = "UpdateTrail" }
ユースケース:
アプリケーションモニタリング: 特定のユーザーアクションまたはシステムイベントを追跡する
ビジネス分析: 特定のイベントタイプの出現をカウントする
トラブルシューティング: 問題を調査する際に特定のオペレーションに焦点を当てる
このパターンは、次のような eventType フィールドを含む JSON ログで機能します。
アプリケーションログ: {"eventType": "UserLogin", "userId": "123"}
システムログ: {"eventType": "ConfigUpdate", "component": "database"}
API ログ: {"eventType": "UpdateTrail", "source": "cloudtrail"}
- Block suspicious IP addresses
-
セキュリティモニタリングで予想される IP アドレスパターンと一致しないトラフィックを特定します。
フィルターパターン:
{ $.sourceIPAddress != 123.123.* }
ユースケース:
- Track specific application events
-
JSON 配列の特定の値をモニタリングして、アプリケーションの動作とユーザーアクションを追跡します。
フィルターパターン:
{ $.arrayKey[0] = "value" }
ユースケース:
ユーザー動作の追跡: アプリケーションログで特定のユーザーアクションをモニタリングする
機能の使用状況: 特定のアプリケーション機能がいつ使用されているかを追跡する
エラー分析: 配列内の特定のエラーカテゴリを持つログを検索する
- Find events using pattern matching
-
正規表現パターンを使用して、フィールド値に柔軟に一致するイベントを検索します。
フィルターパターン:
{ $.eventType = %Trail% }
ユースケース:
柔軟なイベント追跡: 特定のテキストパターンを含むすべてのイベントを検索する
API モニタリング: 正確な名前を指定せずに API ファミリーを追跡する
ログ分析: イベント名または説明の部分一致を検索する
- Monitor application data with wildcards
-
ワイルドカードと正規表現を使用して、配列要素の特定のパターンを検索します。
フィルターパターン:
{ $.arrayKey[*] = %val.{2}% }
ユースケース:
データ検証: 特定のパターンに一致する値を含む配列を検索する
コンテンツフィルタリング: 特定のパターンについてユーザー生成コンテンツをモニタリングする
品質保証: アプリケーションログ間のデータ形式のコンプライアンスを追跡する
- Track network traffic patterns
-
正規表現パターンとワイルドカードを使用して、特定の範囲内の IP アドレスをモニタリングします。
フィルターパターン:
{ $.* = %111\.111\.111\.1[0-9]{1,2}% }
ユースケース:
ネットワークモニタリング: 特定の IP サブネットからのトラフィックを追跡する
セキュリティ分析: 特定のネットワーク範囲からのアクセスをモニタリングする
ロードバランシング: IP 範囲間のトラフィック分散を分析する
クォータ
プロパティセレクターでは 1 つのワイルドカードセレクターしか使用できません。
- Handle JSON properties with special characters
-
名前にピリオドやその他の特殊文字を含む JSON プロパティにアクセスします。
フィルターパターン:
{ $.['cluster.name'] = "c" }
ユースケース:
Kubernetes モニタリング: コンテナログでクラスター名を追跡する
設定の追跡: ドット付きのプロパティ名を使用して設定をモニタリングする
サードパーティー統合: 特別な命名規則を使用してシステムからのログを処理する
- Find null or missing values
-
アプリケーションの問題を示す可能性のある欠落データや null 値をモニタリングします。
フィルターパターン:
{ $.SomeObject IS NULL }
ユースケース:
データ品質モニタリング: 必須フィールドが欠落しているレコードを検索する
アプリケーションのデバッグ: 予想されるデータが存在しない場合に追跡する
エラー検出: 不完全な API レスポンスまたはデータベースクエリをモニタリングする
- Detect missing configuration fields
-
予想されるフィールドが完全に欠落しているログを検索します。これは、設定の問題を示している可能性があります。
フィルターパターン:
{ $.SomeOtherObject NOT EXISTS }
ユースケース:
設定の検証: すべての必須フィールドがログに存在することを確認します。
API モニタリング: 不完全なリクエストまたはレスポンスを追跡する
データパイプラインのモニタリング: 予想されるスキーマフィールドがないレコードを検索する
変数 IS NOT
および EXISTS
は現在サポートされていません。
論理演算子 AND ("&") と OR ("||") を使用して複数の条件を組み合わせる必要がある場合は、複合式を使用します。これらのパターンは、複数の条件を満たす必要がある、または複数の条件のいずれかでトリガーする必要がある高度なモニタリングルールを作成するのに役立ちます。
複合式は括弧 (「()」) をサポートし、オペレーションの標準的な順序に従います。() > && > ||。これらのパターンは、単純な単一条件フィルターがモニタリングニーズに十分でない場合に使用します。
テスト用のサンプル JSON ログイベント:
{
"user": {
"id": 1,
"email": "John.Stiles@example.com"
},
"users": [
{
"id": 2,
"email": "John.Doe@example.com"
},
{
"id": 3,
"email": "Jane.Doe@example.com"
}
],
"actions": [
"GET",
"PUT",
"DELETE"
],
"coordinates": [
[0, 1, 2],
[4, 5, 6],
[7, 8, 9]
]
}
- Monitor specific user actions
-
ユーザー識別とアクションモニタリングを組み合わせて、特定のユーザーが特定のアクションを実行するタイミングを追跡します。
フィルターパターン:
{ ($.user.id = 1) && ($.users[0].email = "John.Doe@example.com") }
ユースケース:
セキュリティ監査: 特定の管理者ユーザーが機密リソースにアクセスするタイミングを追跡する
コンプライアンスモニタリング: 特定のユーザーが承認されたアクションのみを実行するようにする
ユーザー動作分析: ユーザー属性とアクションの相関関係をモニタリングする
- Alert on any suspicious activity
-
いくつかの関連する条件のいずれかが発生したときにトリガーする広範なモニタリングを作成します。
フィルターパターン:
{ $.user.email = "John.Stiles@example.com" || $.coordinates[0][1] = "nonmatch" && $.actions[2] = "nonmatch" }
ユースケース:
セキュリティモニタリング: 特定のユーザーがアクティブな場合、または異常なデータパターンが発生した場合に警告する
システムの状態: いくつかの異なるエラー条件のいずれかをモニタリングする
柔軟なアラート: さまざまなシナリオに対応するキャッチオールルールを作成する
- Require multiple conditions for alerts
-
アラートをトリガーする前に複数の特定の条件を満たす必要があるため、誤検出を減らします。
フィルターパターン:
{ ($.user.email = "John.Stiles@example.com" || $.coordinates[0][1] = "nonmatch") && $.actions[2] = "nonmatch" }
ユースケース:
高信頼性アラート: 複数の疑わしい指標が一致する場合にのみアラート
複雑なビジネスルール: 複数の基準を必要とするシナリオをモニタリングする
ノイズ削減: 単一の独立したイベントからのアラートの防止
クォータ
プロパティセレクターではワイルドカードセレクターを 1 つしか使用できません。また、複合式を含むフィルターパターンでは最大 3 つのワイルドカードセレクターを使用することができます。
- Monitor failed correlation attempts
-
データフィールド間の予想される関係が一致しない場合を追跡します。これは、データ品質の問題を示している可能性があります。
フィルターパターン:
{ ($.user.id = 2 && $.users[0].email = "nonmatch") || $.actions[2] = "GET" }
ユースケース: