

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# フィールドインデックスの構文とクォータ
<a name="CloudWatchLogs-Field-Indexing-Syntax"></a>

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

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

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

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

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

各インデックスポリシーには、次のクォータと制限があります。
+ 最大 20 個のフィールドをポリシーに含めることができます。
+ 各フィールド名には最大 100 文字を含めることができます。
+ `@` で始まるロググループにカスタムフィールドのインデックスを作成するには、フィールド名の先頭に `@` を追加してフィールドを指定する必要があります。例えば、ログイベントに `@userId` という名前のフィールドが含まれている場合は、`@@userId` を指定してこのフィールドのインデックスを作成する必要があります。

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

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

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

これらの生成されたフィールドのうち、フィールドインデックスとして使用するために以下がサポートされています。
+ `@logStream`
+ `@ingestionTime`
+ `@requestId`
+ `@type`
+ `@initDuration`
+ `@duration`
+ `@billedDuration`
+ `@memorySize`
+ `@maxMemoryUsed`
+ `@xrayTraceId`
+ `@xraySegmentId`

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

CloudWatch Logs は、標準ログクラスのすべてのロググループにデフォルトのフィールドインデックスを提供します。デフォルトのフィールドインデックスは、次のフィールドで自動的に使用できます。
+ `@logStream`
+ `@aws.region`
+ `@aws.account`
+ `@source.log`
+ `@data_source_name`
+ `@data_source_type`
+ `@data_format`
+ `traceId`
+ `severityText`
+ `attributes.session.id`

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


| データソース名とタイプ | デフォルトのフィールドインデックス | 
| --- | --- | 
| `amazon_vpc.flow` | `action`<br />`logStatus`<br />`region`<br />`flowDirection`<br />`type` | 
| `amazon_route53.resolver_query` | `query_type`<br />`transport`<br />`rcode` | 
| `aws_waf.access` | `action`<br />`httpRequest.country` | 
| `aws_cloudtrail.data`<br />` aws_cloudtrail.management` | `eventSource`<br />`eventName`<br />`awsRegion`<br />`userAgent`<br />`errorCode`<br />`eventType`<br />`managementEvent`<br />`readOnly`<br />`eventCategory`<br />`requestId` | 

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

**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"
```