As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Sintaxe e cotas do índice de campo
É possível gerar índices de campo criando políticas de índice de campo. Você pode criar políticas de índice em nível de conta que se aplicam a toda a sua conta, bem como políticas que se aplicam somente a um único grupo de logs. Para políticas de indexação em toda a conta, você pode ter uma que se aplique a todos os grupos de logs da conta. Também é possível criar políticas de índice em nível de conta que se apliquem a um subconjunto de grupos de logs na conta, selecionados pelos prefixos dos nomes dos grupos de logs. Se você tiver várias políticas em nível de conta na mesma conta, os prefixos do nome do grupo de logs para essas políticas não podem se sobrepor. Da mesma forma, você pode criar políticas de índice em nível de conta que se apliquem a uma combinação específica de nome e tipo de fonte de dados. Somente uma política de conta pode ser criada por combinação de nome e tipo de fonte de dados.
As políticas de índice de campo em nível de grupo de registros substituem as políticas de índice de campo em nível de conta: que se aplicam ao grupo de registros como um todo (como políticas em nível de conta sem critérios de seleção ou com critérios de seleção baseados no prefixo do nome do grupo de registros). As políticas em nível de conta que correspondam ao nível do evento de registro (como, por exemplo, para uma determinada combinação de nome e tipo de fonte de dados) serão aplicadas, além das políticas que correspondam ao grupo de registros como um todo. Se você criar uma política de índice em nível de grupo de registros, esse grupo de registros não usará políticas em nível de conta que correspondam ao nível do grupo de registros.
As correspondências de eventos de logs com os nomes dos índices de campo diferenciam maiúsculas de minúsculas. Por exemplo, um índice de campo de RequestId não corresponderá a um evento de logs que contenha requestId.
Você pode ter até 40 políticas de índice em nível de conta. Dessas políticas, 20 podem usar critérios de seleção de prefixo de nome de grupo de log e 20 podem usar critérios de seleção baseados em fonte de dados. Se você tiver várias políticas de índice em nível de conta filtradas para prefixos de nome de grupo de logs, nenhuma delas poderá usar prefixos de nome de grupo de logs iguais ou sobrepostos. Por exemplo, se você tiver uma política filtrada para grupos de logs que começam com my-log, não pode ter outra política de índice de campo filtrada para my-logpprod ou my-logging. Da mesma forma, se você tiver várias políticas de índice em nível de conta filtradas para combinações de nome e tipo de fonte de dados, nenhuma delas poderá usar o mesmo nome e tipo de fonte de dados. Por exemplo, se você tiver uma política filtrada pelo nome amazon_vpc e tipo da fonte de dados, não flow poderá criar outra política com essa combinação.
Se você tiver uma política de índice em nível de conta que não tenha prefixos de nome e se aplique a todos os grupos de registros, nenhuma outra política de índice em nível de conta com filtros de prefixo de nome de grupo de registros poderá ser criada; você pode criar políticas de índice em nível de conta que usem filtros de nome e tipo de fonte de dados.
Cada política de indexação tem as seguintes cotas e restrições:
-
Podem ser incluídos até 20 campos na política.
-
Cada nome de campo pode incluir até 100 caracteres.
-
Para criar um índice de um campo personalizado em seus grupos de logs que comece com
@, você deve especificar o campo com um@extra no início do nome do campo. Por exemplo, se seus eventos de logs incluírem um campo chamado@userId, você deverá especificar@@userIdpara criar um índice para esse campo.
Para políticas de índice em nível de conta com critérios de seleção baseados em nome de fonte de dados e tipo, uma restrição adicional se aplica: todos os campos devem ser tipos de dados primitivos, primitivos aninhados são compatíveis somente com estruturas.
Campos gerados e campos reservados
CloudWatch O Logs Insights gera automaticamente campos do sistema em cada evento de registro. Esses campos gerados são prefixados com @. Para obter mais informações sobre os campos gerados, consulte Logs compatíveis e campos descobertos.
Os seguintes campos gerados são compatíveis para uso como índices de campo:
-
@logStream -
@ingestionTime -
@requestId -
@type -
@initDuration -
@duration -
@billedDuration -
@memorySize -
@maxMemoryUsed -
@xrayTraceId -
@xraySegmentId
Para indexar esses campos gerados, você não precisa adicionar um @ extra ao especificá-los, como é necessário fazer com campos personalizados que começam com @. Por exemplo, para criar um índice de campo para @logStream, basta especificar @logStream como índice de campo.
CloudWatch Os registros fornecem índices de campo padrão para todos os grupos de registros na classe de registros padrão. Os índices de campo padrão ficam disponíveis automaticamente para os seguintes campos:
-
@logStream -
@aws.region -
@aws.account -
@source.log -
@data_source_name -
@data_source_type -
@data_format -
traceId -
severityText -
attributes.session.id
CloudWatch O Logs também fornece índices de campo padrão para determinadas combinações de nome e tipo de fonte de dados. Os índices de campo padrão estão disponíveis automaticamente para as seguintes combinações de nome e tipo de fonte de dados:
| Nome e tipo da fonte de dados | Índices de campo padrão |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Os índices de campo padrão são adicionais aos índices de campo personalizados definidos em sua política. Os índices de campo padrão não são contabilizados em sua cota de índice de campo.
Campos secundários e campos de matriz em logs JSON
Você pode indexar campos que são secundários aninhados ou de matriz em logs JSON.
Por exemplo, você pode criar um índice do campo filho accessKeyId dentro do campo userIdentity desse log:
{ "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" } }] } } }
Para criar esse campo, você se refere a ele usando a notação de ponto (userIdentity.accessKeyId) ao criar o índice do campo e ao especificá-lo em uma consulta. A consulta pode ser como esta:
fields @timestamp, @message | filterIndex userIdentity.accessKeyId = "11112222"
No evento de exemplo anterior, o campo instanceId está em uma matriz em requestParameters.instancesSet.items. Para representar esse campo ao criar o índice de campos e para consultar, indique-o como requestParameters.instancesSet.items.0.instanceId. O 0 se refere ao lugar desse campo no array.
Em seguida, uma consulta para esse campo pode ser:
fields @timestamp, @message | filterIndex requestParameters.instancesSet.items.0.instanceId="i-abcde123"