Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Sintaxis y cuotas del índice de campos
Los índices de campos se crean mediante la creación de políticas de índices de campos. Se pueden crear políticas de indexación a nivel de cuenta que se apliquen a toda la cuenta y también se pueden crear políticas que se apliquen solo a un grupo de registros. Para las políticas de indexación para toda la cuenta, se puede tener una que se aplique a todos los grupos de registro de la cuenta. También se pueden crear políticas de indexación a nivel de cuenta que se apliquen a un subconjunto de grupos de registros de la cuenta, seleccionados por los prefijos de sus nombres de grupos de registros. Si se tienen varias políticas a nivel de cuenta en la misma cuenta, los prefijos de los nombres de los grupos de registros de estas políticas no pueden superponerse. Del mismo modo, puede crear políticas de indexación a nivel de cuenta que se apliquen a una combinación de nombre y tipo de fuente de datos específica. Solo se puede crear una política de cuenta por combinación de nombre y tipo de fuente de datos.
Las políticas de indexación de campos a nivel de grupo de registros anulan las políticas de índice de campos a nivel de cuenta, que se aplican al grupo de registros en su conjunto (por ejemplo, las políticas a nivel de cuenta sin criterios de selección o con criterios de selección basados en el prefijo del nombre del grupo de registros). Las políticas a nivel de cuenta que coincidan a nivel de eventos de registro (por ejemplo, para una combinación de nombre y tipo de fuente de datos determinada) se aplicarán además de las políticas que coincidan con el grupo de registro en su conjunto. Si crea una política de índice a nivel de grupo de registros, ese grupo de registros no utilizará políticas a nivel de cuenta que coincidan a nivel de grupo de registros.
Las coincidencias de los eventos de registro con los nombres de los índices de campo distinguen mayúsculas de minúsculas. Por ejemplo, un índice de campo de RequestId no coincidirá con un evento de registro que contenga requestId.
Puede tener hasta 40 políticas de indexación a nivel de cuenta, de las cuales 20 pueden usar criterios de selección de prefijos de nombres de grupos de registros y 20 pueden usar criterios de selección basados en la fuente de datos. Si se tienen varias políticas de indexación a nivel de cuenta filtradas para incluir prefijos de nombres de grupos de registros, ninguna de ellas podrá utilizar prefijos de nombres de grupos de registros iguales o superpuestos. Por ejemplo, si se tiene una política filtrada para registrar los grupos que comienzan por my-log, no se puede tener otra política de indexación de campos filtrada a my-logpprod o my-logging. Del mismo modo, si tiene varias políticas de indexación a nivel de cuenta filtradas por combinaciones de nombre y tipo de fuente de datos, ninguna de ellas podrá utilizar el mismo nombre y tipo de fuente de datos. Por ejemplo, si tiene una política filtrada por el nombre amazon_vpc y el tipo de fuente de datos, no flow podrá crear otra política con esta combinación.
Si tiene una política de indexación a nivel de cuenta que no tiene prefijos de nombre y se aplica a todos los grupos de registros, no se puede crear ninguna otra política de indexación a nivel de cuenta con filtros de prefijos de nombres de grupos de registros; puede crear políticas de índice a nivel de cuenta que utilicen filtros de nombre y tipo de fuente de datos.
Cada política de indexación dispone de las siguientes cuotas y restricciones:
-
Se pueden incluir hasta 20 campos en la política.
-
Cada nombre de campo puede incluir hasta 100 caracteres.
-
Para crear un índice de un campo personalizado en sus grupos de registros que comience por
@, se debe especificar el campo con un@extra al principio del nombre del campo. Por ejemplo, si los eventos de registro incluyen un campo denominado@userId, se debe especificar@@userIda fin de crear un índice para este campo.
En el caso de las políticas de indexación a nivel de cuenta con criterios de selección basados en el nombre y el tipo de la fuente de datos, se aplica una restricción adicional: todos los campos deben ser tipos de datos primitivos; las primitivas anidadas solo se admiten para las estructuras.
Campos generados y campos reservados
CloudWatch Logs Insights genera automáticamente los campos del sistema en cada evento de registro. Estos campos generados llevan el prefijo @. Si se desea obtener más información sobre los campos generados, consulte Registros y campos detectados compatibles.
De estos campos generados, se admiten los siguientes para su uso como índices de campos:
-
@logStream -
@ingestionTime -
@requestId -
@type -
@initDuration -
@duration -
@billedDuration -
@memorySize -
@maxMemoryUsed -
@xrayTraceId -
@xraySegmentId
Para indexar estos campos generados, no es necesario añadir un @ extra cuando se los especifica, como ocurre con los campos personalizados que comienzan por @. Por ejemplo, para crear un índice de campos @logStream, basta con especificar @logStream como índice de campo.
CloudWatch Logs proporciona índices de campos predeterminados para todos los grupos de registros de la clase de registro estándar. Los índices de campo predeterminados están disponibles automáticamente para los siguientes campos:
-
@logStream -
@aws.region -
@aws.account -
@source.log -
@data_source_name -
@data_source_type -
@data_format -
traceId -
severityText -
attributes.session.id
CloudWatch Los registros también proporcionan índices de campo predeterminados para determinadas combinaciones de nombres y tipos de fuentes de datos. Los índices de campo predeterminados están disponibles automáticamente para las siguientes combinaciones de nombre y tipo de fuente de datos:
| Nombre y tipo de fuente de datos | Índices de campo predeterminados |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Los índices de campos predeterminados se suman a cualquier índice de campo personalizado que defina en su política. Los índices de campo predeterminados no se incluyen en la cuota de índices de campo.
Campos secundarios y campos de matriz en los registros JSON
Se pueden indexar campos que sean secundarios anidados o campos de matriz en los registros JSON.
Por ejemplo, se puede crear un índice del campo accessKeyId secundario dentro del campo userIdentity de este registro:
{ "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" } }] } } }
Si se desea crear este campo, utilice la notación de puntos (userIdentity.accessKeyId) tanto al crear el índice de campos como al especificarlo en una consulta. La consulta tendría el siguiente aspecto:
fields @timestamp, @message | filterIndex userIdentity.accessKeyId = "11112222"
En el caso del ejemplo anterior, el campo instanceId está en una matriz dentro de requestParameters.instancesSet.items. Para representar este campo tanto al crear el índice de campos como al realizar consultas, consúltelo como requestParameters.instancesSet.items.0.instanceId. El 0 se refiere a la posición de ese campo en la matriz.
Por lo tanto, una consulta para este campo podría ser la siguiente:
fields @timestamp, @message | filterIndex requestParameters.instancesSet.items.0.instanceId="i-abcde123"