Syntaxe et quotas d'index de champs

Vous créez des index de champs en créant des politiques d'index de champs. Vous pouvez créer des politiques d'index au niveau du compte qui s'appliquent à l'ensemble de votre compte, et vous pouvez également créer des politiques qui ne s'appliquent qu'à un seul groupe de journaux. Pour les politiques d'indexation applicables à l'ensemble du compte, vous pouvez en définir une qui s'applique à tous les groupes de journaux du compte. Vous pouvez également créer des politiques d'index au niveau du compte qui s'appliquent à un sous-ensemble de groupes de journaux du compte, sélectionnés par les préfixes de leurs noms de groupes de journaux. Si vous avez plusieurs politiques au niveau du compte dans le même compte, les préfixes des noms de groupes de journaux associés à ces politiques ne peuvent pas se chevaucher. De même, vous pouvez créer des politiques d'index au niveau du compte qui s'appliquent à une combinaison de nom et de type de source de données spécifique. Une seule politique de compte peut être créée par combinaison de nom et de type de source de données.

Les politiques d'index de champs au niveau du groupe de journaux remplacent les politiques d'index de champs au niveau du compte : elles s'appliquent au groupe de journaux dans son ensemble (par exemple, les politiques au niveau du compte sans critères de sélection ou avec des critères de sélection basés sur le préfixe du nom du groupe de journaux). Les politiques au niveau du compte qui correspondent au niveau des événements du journal (par exemple, pour une combinaison de nom et de type de source de données donnée) s'appliqueront en plus des politiques correspondant au groupe de journaux dans son ensemble. Si vous créez une politique d'index au niveau du groupe de journaux, ce groupe de journaux n'utilise pas de politiques au niveau du compte qui correspondent au niveau du groupe de journaux.

Les correspondances entre les événements du journal et les noms des index de champs distinguent les majuscules et minuscules. Par exemple, un index de champ de RequestId ne correspondra pas à un événement de journal contenantrequestId.

Vous pouvez avoir jusqu'à 40 politiques d'index au niveau du compte, dont 20 peuvent utiliser des critères de sélection du préfixe du nom du groupe de journaux et 20 peuvent utiliser des critères de sélection basés sur les sources de données. Si plusieurs politiques d'index au niveau du compte sont filtrées en fonction des préfixes de nom de groupe de journaux, aucune d'entre elles ne peut utiliser les mêmes préfixes de nom de groupe de journaux ou des préfixes qui se chevauchent. Par exemple, si vous avez une politique filtrée pour enregistrer les groupes commençant parmy-log, vous ne pouvez pas filtrer une autre politique d'index de champs sur my-logpprod oumy-logging. De même, si plusieurs politiques d'index au niveau du compte sont filtrées en fonction des combinaisons de nom et de type de source de données, aucune d'entre elles ne peut utiliser le même nom et le même type de source de données. Par exemple, si vous avez une politique filtrée selon le nom amazon_vpc et le type de source de données de la source de données, flow vous ne pouvez pas créer une autre politique avec cette combinaison.

Si votre politique d'index au niveau du compte ne comporte aucun préfixe de nom et s'applique à tous les groupes de journaux, aucune autre politique d'index au niveau du compte avec des filtres de préfixes de nom de groupe de journaux ne peut être créée ; vous pouvez créer des politiques d'index au niveau du compte qui utilisent des filtres de nom et de type de source de données.

Chaque politique d'indice comporte les quotas et restrictions suivants :

Pour les politiques d'indexation au niveau du compte avec le nom de la source de données et les critères de sélection basés sur le type, une restriction supplémentaire s'applique : tous les champs doivent être des types de données primitifs, les primitives imbriquées ne sont prises en charge que pour les structures.

Champs générés et champs réservés

CloudWatch Logs Insights génère automatiquement des champs système pour chaque événement de journal. Ces champs générés sont préfixés par. @ Pour plus d'informations sur les champs générés, consultezJournaux pris en charge et champs découverts.

Parmi ces champs générés, les suivants sont pris en charge pour être utilisés comme index de champs :

Pour indexer ces champs générés, il n'est pas nécessaire d'en ajouter un @ autre lorsque vous les spécifiez, comme vous devez le faire pour les champs personnalisés commençant par@. Par exemple, pour créer un index de champ pour@logStream, il suffit de le spécifier @logStream comme index de champ.

CloudWatch Logs fournit des index de champs par défaut pour tous les groupes de journaux de la classe de journaux standard. Les index de champs par défaut sont automatiquement disponibles pour les champs suivants :

CloudWatch Logs fournit également des index de champs par défaut pour certaines combinaisons de noms et de types de sources de données. Les index de champs par défaut sont automatiquement disponibles pour les combinaisons de nom et de type de source de données suivantes :

Les index de champs par défaut s'ajoutent aux index de champs personnalisés que vous définissez dans votre politique. Les index de champs par défaut ne sont pas pris en compte dans votre quota d'index de champs.

Champs enfants et champs de tableau dans les journaux JSON

Vous pouvez indexer des champs qui sont des champs enfants ou des champs matriciels imbriqués dans les journaux JSON.

Par exemple, vous pouvez créer un index du champ accessKeyId enfant dans le userIdentity champ de ce journal :

{
    "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"
                }
            }]
        }
    }
}

Pour créer ce champ, vous devez y faire référence à l'aide de la notation par points (userIdentity.accessKeyId) à la fois lors de la création de l'index du champ et lors de sa spécification dans une requête. La requête pourrait ressembler à ceci :

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

Dans l'exemple précédent, le instanceId champ se trouve dans un tableau dans requestParameters.instancesSet.items Pour représenter ce champ à la fois lors de la création de l'index du champ et lors de l'interrogation, appelez-le car requestParameters.instancesSet.items.0.instanceId le 0 fait référence à la place de ce champ dans le tableau.

Une requête pour ce champ peut alors être la suivante :

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