フィールドインデックスの構文とクォータ

フィールドインデックスを作成するには、フィールドインデックスポリシーを作成します。アカウント全体に適用されるアカウントレベルのインデックスポリシーを作成できます。また、単一のロググループのみに適用されるポリシーを作成することもできます。アカウント全体のインデックスポリシーでは、アカウント内のすべてのロググループに適用されるインデックスポリシーを設定できます。ロググループ名のプレフィックスによって選択された、アカウントのロググループのサブセットに適用されるアカウントレベルのインデックスポリシーを作成することもできます。同じアカウントに複数のアカウントレベルのポリシーがある場合、これらのポリシーのロググループ名のプレフィックスを重複させることはできません。同様に、特定のデータソース名とタイプの組み合わせに適用されるアカウントレベルのインデックスポリシーを作成できます。データソース名とタイプの組み合わせごとに作成できるアカウントポリシーは 1 つだけです。

ロググループレベルのフィールドインデックスポリシーは、アカウントレベルのフィールドインデックスポリシーを上書きします。このポリシーは、ロググループ全体に適用されます (選択基準のないアカウントレベルのポリシーや、ロググループ名のプレフィックスベースの選択基準を持つアカウントレベルのポリシーなど）。ログイベントレベルで一致するアカウントレベルのポリシー (特定のデータソース名とタイプの組み合わせなど) は、ロググループ全体に一致するポリシーに加えて適用されます。ロググループレベルのインデックスポリシーを作成する場合、そのロググループは、ロググループレベルで一致するアカウントレベルのポリシーを使用しません。

ログイベントとフィールドインデックスの名前の一致では、大文字と小文字が区別されます。例えば、RequestId のフィールドインデックスは、requestId を含むログイベントと一致しません。

最大 40 のアカウントレベルのインデックスポリシーを持つことができ、そのうち 20 はロググループ名のプレフィックス選択基準を使用し、20 はデータソースベースの選択基準を使用できます。ロググループ名のプレフィックスに対してフィルタリングされた複数のアカウントレベルのインデックスポリシーがある場合、同じまたは重複するロググループ名のプレフィックスを 2 つ使用することはできません。例えば、my-log で始まるロググループに対してフィルタリングされたポリシーが 1 つある場合、別のフィールドインデックスポリシーを my-logpprod または my-logging に対してフィルタリングすることはできません。同様に、データソース名とタイプの組み合わせにフィルタリングされた複数のアカウントレベルのインデックスポリシーがある場合、2 つのポリシーで同じデータソース名とタイプを使用することはできません。たとえば、1 つのポリシーをデータソース名amazon_vpcとデータソースタイプにフィルタリングした場合flow、この組み合わせで別のポリシーを作成することはできません。

名前プレフィックスがなく、すべてのロググループに適用されるアカウントレベルのインデックスポリシーがある場合、ロググループ名プレフィックスフィルターを持つ他のアカウントレベルのインデックスポリシーを作成することはできません。データソース名とタイプフィルターを使用するアカウントレベルのインデックスポリシーを作成できます。

各インデックスポリシーには、次のクォータと制限があります。

データソース名とタイプベースの選択基準を持つアカウントレベルのインデックスポリシーでは、追加の制限が適用されます。すべてのフィールドはプリミティブデータ型でなければならず、ネストされたプリミティブは 構造体でのみサポートされます。

生成されたフィールドと予約されたフィールド

CloudWatch Logs Insights は、各ログイベントにシステムフィールドを自動的に生成します。これらの生成されたフィールドには @ のプレフィックスが付きます。生成されたフィールドの詳細については「サポートされるログと検出されるフィールド」を参照してください。

これらの生成されたフィールドのうち、フィールドインデックスとして使用するために以下がサポートされています。

これらの生成されたフィールドをインデックス付けするには、@ で始まるカスタムフィールドに対して行う必要があるため、それらを指定するときに @ を追加する必要はありません。例えば、@logStream のフィールドインデックスを作成するには、@logStream をフィールドインデックスとして指定します。

CloudWatch Logs は、標準ログクラスのすべてのロググループにデフォルトのフィールドインデックスを提供します。デフォルトのフィールドインデックスは、次のフィールドで自動的に使用できます。

CloudWatch Logs は、特定のデータソース名とタイプの組み合わせのデフォルトのフィールドインデックスも提供します。デフォルトのフィールドインデックスは、次のデータソース名とタイプの組み合わせで自動的に使用できます。

デフォルトのフィールドインデックスは、ポリシー内で定義した任意のカスタムフィールドインデックスに追加されます。デフォルトのフィールドインデックスは、フィールドインデックスクォータにはカウントされません。

JSON ログの子フィールドと配列フィールド

JSON ログのネストされた子フィールドまたは配列フィールドであるフィールドにインデックスを作成できます。

例えば、このログ内の userIdentity フィールド内に accessKeyId 子フィールドのインデックスを作成できます。

{
    "eventVersion": "1.0",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "EXAMPLE_PRINCIPAL_ID",
        "arn": "arn: aws: iam: : 123456789012: user/Alice",
        "accessKeyId": "11112222",
        "accountId": "123456789012",
        "userName": "Alice"
    },
    "eventTime": "2014-03-06T21: 22: 54Z",
    "eventSource": "ec2.amazonaws.com",
    "eventName": "StartInstances",
    "awsRegion": "us-east-2",
    "sourceIPAddress": "192.0.2.255",
    "userAgent": "ec2-api-tools1.6.12.2",
    "requestParameters": {
        "instancesSet": {
            "items": [{
                "instanceId": "i-abcde123",
                "currentState": {
                    "code": 0,
                    "name": "pending"
                },
                "previousState": {
                    "code": 80,
                    "name": "stopped"
                }
            }]
        }
    }
}

このフィールドを作成するには、フィールドインデックスを作成する時とクエリでそれを指定する時の両方で、ドット表記 (userIdentity.accessKeyId) を使用して参照します。クエリは次のようになります。

fields @timestamp, @message 
| filterIndex userIdentity.accessKeyId = "11112222"

前の例のイベントの場合、instanceId フィールドは requestParameters.instancesSet.items 内の配列にあります。フィールドインデックスの作成時とクエリ時の両方でこのフィールドを表すには、requestParameters.instancesSet.items.0.instanceId として参照します。0 は配列内のそのフィールドの場所を参照します。

すると、このフィールドのクエリは次のようになります。

fields @timestamp, @message 
| filterIndex requestParameters.instancesSet.items.0.instanceId="i-abcde123"