本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 在摄取期间转换日志 通过日志转换和充实，在将所有日志摄入日志时，您可以将所有日志标准化为一致且上下文丰富的格式。 CloudWatch [您可以为常见 AWS 服务（例如 AWS WAF 和 Amazon Route 53）使用预先配置的模板为日志添加结构，也可以使用 Grok 等原生解析器构建自定义转换器。](CloudWatch-Logs-Transformation-Configurable.md#CloudWatch-Logs-Transformation-Grok)您还可以重命名现有属性，并向日志添加其他元数据（例如，账户 ID 和区域）。 日志转换有助于简化和缩短应用程序中的日志查询，并有助于简化在日志上创建警报的过程。此功能通过主要 AWS 日志源（如 VPC 流日志、Route 53 和）的 out-of-the-box转换模板为常见日志类型提供转换 Amazon RDS for PostgreSQL。您可以使用预配置的转换模板，也可以创建自定义转换器以满足您的需求。 日志转换可帮助您管理从格式和属性名称差异很大的源发出的日志。 创建转换器后，摄取的日志事件将以标准格式转换和存储。您可以利用这些转换后的日志，通过以下功能加速您的分析体验： + [字段索引](CloudWatchLogs-Field-Indexing.md) + [CloudWatch 日志见解已发现字段](CWL_AnalyzeLogData-discoverable-fields.md) + 使用[指标筛选条件](MonitoringLogData.md)灵活地设置警报 + 通过[订阅筛选条件](Subscriptions.md)进行转发 + 使用 [Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) 从日志事件创建指标数据，您可以选择让 Contributor Insights 规则在转换日志事件之前或之后对其进行评估。 转换仅在日志摄取期间进行。您无法转换已摄取的日志事件。转换操作不可逆。原始日志和转换后的日志都存储在具有相同保留策略的 CloudWatch 日志中。日志转换和丰富功能包含在现有的标准日志类摄取价格中。日志存储成本将根据转换后的日志大小计算，这可能会超过原始日志量。 **重要** 转换日志事件后，您必须使用 Lo CloudWatch gs Insights 查询来查看转换后的日志版本。[ GetLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_GetLogEvents.html)和[ FilterLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_FilterLogEvents.html)操作仅返回日志事件在转换之前的原始版本。 **重要** 尽管单个日志事件最多 PutLogEvents 允许 1MB，但日志转换只能处理大小小于 512kb 的日志事件。任何大于 512kb 的日志事件都将在转换中失败并发出错误。的总大小仍然 PutLogEvents 可以超过 512kb。 除了转换为不同的格式外，您还可以使用其他上下文（例如，账户 ID、区域和关键字）丰富日志。这些信息是从日志组名称和静态关键字中提取的。 日志转换可帮助您处理从格式和属性名称差异很大的源发出的日志。 仅标准日志类中的日志组支持日志转换和丰富功能。 您可以为单个日志组创建转换器，也可以创建适用于账户中所有或多个日志组的账户级转换器。如果某个日志组具有日志组级转换器，则该转换器会覆盖原本适用于该日志组的任何账户级转换器。 **Topics** + [创建和管理日志转换器](CloudWatch-Logs-Transformation-Create.md) + [可配置的解析器类型处理器](CloudWatch-Logs-Transformation-Configurable.md) + [用于 AWS 出售日志的内置处理器](CloudWatch-Logs-Transformation-BuiltIn.md) + [字符串变异处理器](CloudWatch-Logs-Transformation-StringMutate.md) + [JSON 变异处理器](CloudWatch-Logs-Transformation-JSONMutate.md) + [数据类型转换器处理器](CloudWatch-Logs-Transformation-Datatype.md) + [转换指标和错误](Transformation-Errors-Metrics.md) # 创建和管理日志转换器 日志转换器包括一个或多个一起处于逻辑管线中的*处理器*。每个处理器都按照它们在转换器配置中列出的顺序依次应用于日志事件。 有些处理器属于*解析器*类型。每个转换器必须至少有一个解析器，并且转换器中的第一个处理器必须是解析器。 有些解析器是针对特定类型的 AWS 公开发布的日志进行了配置的内置解析器。 其他处理器类型包括字符串变异器、JSON 变异器和数据处理器。 您可以为单个日志组创建转换器，也可以创建适用于账户中所有或多个日志组的账户级转换器。如果某个日志组具有日志组级转换器，则该转换器会覆盖原本适用于该日志组的任何账户级转换器。在您的账户中，一个区域最多可以有 20 个账户级转换器。 在创建转换器时，必须遵循以下准则： + 如果您为某种类型的已 AWS 售日志包含预配置的解析器，则该解析器必须是转换器中列出的第一个处理器。只能在转换器中包含一个此类处理器。 + 只能在转换器中包含一个 `grok` 处理器。 + 转换器必须至少包含一个解析器类型的处理器。最多可以包含五个解析器类型的处理器。此五个限制包括内置解析器和可配置的解析器。 + 转换器最多可包含 20 个处理器。 + 只能在转换器中包含一个 **addKeys** 处理器。 + 只能在转换器中包含一个 **copyValue** 处理器。 + 每个转换器最多可以从日志事件中提取 200 个字段。 + 每个日志事件**必须**低于 512KB。日志事件的总大小仍然可以超过 512KB。 **Topics** + [创建账户级转换器策略](CloudWatchLogs-Transformer-CreateAccountLevel.md) + [编辑或删除账户级转换器策略](CloudWatchLogs-Transformer-EditAccountLevel.md) + [从头开始创建对 log-group-level数转换器](CloudWatch-Logs-Transformation-CreateNew.md) + [通过复制现有的 log-group-level变压器来创建变压器](CloudWatch-Logs-Transformation-Copy.md) + [编辑变 log-group-level压器](CloudWatch-Logs-Transformation-Edit.md) + [删除变 log-group-level压器](CloudWatch-Logs-Transformation-Delete.md) # 创建账户级转换器策略 请按照本节中的步骤创建适用于账户中的所有日志组或者日志组名称以相同字符串（前缀）开头的多个日志组的转换器策略。一个区域中最多可以有 20 个账户级转换器策略。 您不能在同一区域创建两个使用相同前缀或一个前缀包含在另一个前缀中的转换器策略。例如，如果您为字符串前缀 `/aws/lambda` 创建了一个转换器策略，则不能再使用前缀 `/aws` 创建另一个转换器策略。但是，您可以为 `/aws/lambda` 创建一个转换器策略，而为 `/aws/waf` 创建另一个转换器策略 **创建账户级转换器策略** 1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。 1. 在左侧导航窗格上，选择**设置**，然后选择**日志**选项卡。 1. 在**账户的转换器策略**部分，选择**创建转换器策略**。 1. 对于**转换器策略名称**，输入新策略的名称。 1. 对于**选择日志组**，请执行下列操作之一： + 选择**所有标准日志组**，将转换器策略应用于账户中的所有标准类日志组。 + 选择**按前缀匹配选择日志组**，将策略应用于名称以相同字符串开头的日志组子集。然后，在**选择标准**中输入这些日志组的前缀。 1. 在**选择解析器**区域中，使用**解析器**选择要包含在转换器中的解析器。 如果它是预先配置的解析器，则无需为其指定任何配置。 AWS 如果是其他解析器，则需要指定其配置。有关更多信息，请参阅[可配置的解析器类型处理器](CloudWatch-Logs-Transformation-Configurable.md)中该处理器的相关信息。 1. 要添加其他处理器，请选择**选择处理器**。然后在**处理器**框中选择所需的处理器，并填写配置参数。 请记住，处理器会按照您将日志事件添加到转换器的顺序对其进行操作。 1. （可选）要添加其他处理器，请选择 **\$1 处理器**并重复上一步。 1. （可选）您可以随时测试迄今为止您根据示例日志事件构建的转换器。为此，请在**转换器预览**部分执行以下操作之一： + 在**选择日志组**中最多选择五个日志组，然后选择**加载最新的日志事件**。然后选择**测试转换器**。 + 将日志事件直接复制到**示例日志事件**中，然后选择**测试转换器**。 随后会显示日志的转换后版本。 1. 添加完处理器并对示例日志的测试感到满意后，请选择**保存**。 1. 完成后，选择**创建**。 # 编辑或删除账户级转换器策略 请按照本部分中的步骤编辑或删除账户级转换器策略。 **编辑或删除账户级转换器策略** 1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。 1. 在左侧导航窗格上，选择**设置**，然后选择**日志**选项卡。 1. 在**转换器账户策略**部分中，选择**管理**。 1. 选择要管理的转换器策略旁边的按钮，然后选择**编辑**或**删除**。 如果您正在编辑策略，请参阅[可配置的解析器类型处理器](CloudWatch-Logs-Transformation-Configurable.md)中的步骤 5-11 以查看您的选项。 # 从头开始创建对 log-group-level数转换器 使用这些步骤从头开始创建 log-group-level变压器。 **使用控制台为日志组创建日志转换器** 1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。 1. 在导航窗格中，依次选择**日志**和**日志组**。 1. 选择要为其创建转换器的日志组。 1. 选择**转换器**选项卡。您可能需要向右滚动选项卡列表才能看到它。 1. 选择**创建转换器**。 1. 在**选择解析器**框中，选择要包含在转换器中的解析器。 如果它是预先配置的解析器，则无需为其指定任何配置。 AWS 如果是其他解析器，则需要指定其配置。有关更多信息，请参阅[可配置的解析器类型处理器](CloudWatch-Logs-Transformation-Configurable.md)中该处理器的相关信息。 1. 要添加其他处理器，请选择 **\$1 添加处理器**。然后在**选择处理器**框中选择所需的处理器，并填写配置参数。 请记住，处理器会按照您将日志事件添加到转换器的顺序对其进行操作。 1. （可选）您可以随时测试迄今为止您根据示例日志事件构建的转换器。为此，请执行以下操作： 1. 在**转换预览**部分，选择**加载示例日志**以从此转换器适用的日志组加载示例日志事件，或者将日志事件粘贴到文本框中。 选择**测试转换器**。随后会显示日志的转换后版本 1. 添加完处理器并对示例日志的测试感到满意后，请选择**保存**。 **使用从头 AWS CLI 开始创建对数转换器** + 使用 `aws logs put-transformer` 命令。当使用 `parseJSON` 作为第一个处理器时，您必须使用 `@message` 作为源字段来解析整个日志事件。在初始 JSON 解析后，您可以在后续处理器中操作特定字段。以下示例创建了一个包含 `parseJSON` 和 `addKeys` 处理器的转换器： ``` aws logs put-transformer \ --transformer-config '[{"parseJSON":{"source":"@message"}},{"addKeys":{"entries":[{"key":"metadata.transformed_in","value":"CloudWatchLogs"},{"key":"feature","value":"Transformation"}]}},{"trimString":{"withKeys":["status"]}}]' \ --log-group-identifier my-log-group-name ``` # 通过复制现有的 log-group-level变压器来创建变压器 您可以使用控制台复制现有转换器的 JSON 配置。然后，您可以使用该代码创建相同的转换器 AWS CLI，也可以先修改配置。 **通过复制现有日志转换器来创建日志转换器** 1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。 1. 在导航窗格中，依次选择**日志**和**日志组**。 1. 选择包含要复制的转换器的日志组。 1. 选择**转换**选项卡。您可能需要向右滚动选项卡列表才能看到它。 1. 选择**管理转换器**。 1. 选择**复制转换器**。此时会将转换器 JSON 复制到剪贴板。 1. 创建一个文件并粘贴转换器配置。在此示例中，我们将调用文件 `CopiedTransformer.json` 1. 使用创建具有 AWS CLI 该配置的新变压器。 ``` aws logs put-transformer --log-group-identifier my-log-group-name \ --transformer-config file://CopiedTransformer.json ``` # 编辑变 log-group-level压器 请按照以下步骤编辑现有的日志转换器。 **编辑日志转换器** 1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。 1. 在导航窗格中，依次选择**日志**和**日志组**。 1. 选择包含要编辑的转换器的日志组。 1. 选择**转换**选项卡。您可能需要向右滚动选项卡列表才能看到它。 1. 选择**管理转换器**。 1. 在**解析器**和**处理器**部分，进行更改。 1. 要添加其他处理器，请选择 **\$1 添加处理器**。然后在**处理器**框中选择所需的处理器，并填写配置参数。 请记住，处理器会按照您将日志事件添加到转换器的顺序对其进行操作。 1. （可选）您可以随时测试迄今为止您根据示例日志事件构建的转换器。为此，请执行以下操作： 1. 在**转换预览**部分，选择**加载示例日志**以从此转换器适用的日志组加载示例日志事件，或者将日志事件粘贴到文本框中。 选择**测试转换**。随后会显示日志的转换后版本 1. 添加完处理器并对示例日志的测试感到满意后，请选择**保存**。 # 删除变 log-group-level压器 请按照以下步骤删除日志转换器。 **删除日志转换器** 1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。 1. 在导航窗格中，依次选择**日志**和**日志组**。 1. 选择包含要编辑的转换器的日志组。 1. 选择**转换**选项卡。您可能需要向右滚动选项卡列表才能看到它。 1. 选择**删除**。 1. 在确认框中，选择**删除策略**。 # 可配置的解析器类型处理器 本节包含有关可在日志事件转换器中使用的可配置数据解析器处理器的信息。 **Contents** + [parseJSON](#CloudWatch-Logs-Transformation-parseJSON) + [grok](#CloudWatch-Logs-Transformation-Grok) + [Grok 示例](#Grok-Examples) + [示例 1：使用 grok 从非结构化日志中提取字段](#Grok-Example1) + [示例 2：搭配使用 grok 和 parseJSON 从 JSON 日志事件中提取字段](#Grok-Example3) + [示例 3：FIELD\$1NAME 中带有点注释的 Grok 模式](#Grok-Example4) + [支持的 Grok 模式](#Grok-Patterns) + [常见日志格式示例](#Common-Log-Examples) + [Apache 日志示例](#Apache-Log-Example) + [NGINX 日志示例](#NGINX-Log-Example) + [Syslog 协议（RFC 5424）日志示例](#syslog5424-Log-Example) + [csv](#CloudWatch-Logs-Transformation-csv) + [parseKeyValue](#CloudWatch-Logs-Transformation-parseKeyValue) ## parseJSON **parseJSON** 处理器解析 JSON 日志事件，并将提取的 JSON 键值对插入到目标位置。如果没有指定目标位置，则处理器会将键值对放置在根节点下。当使用 `parseJSON` 作为第一个处理器时，您必须使用 `@message` 作为源字段来解析整个日志事件。在初始 JSON 解析后，您可以在后续处理器中操作特定字段。 原始 `@message` 内容不变，新键会添加到消息中。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | source | 日志事件中待解析字段的路径。请使用点表示法访问子字段。例如，store.book | 否 | `@message` | 最大长度：128 最大嵌套键深度：3 | | destination | 已解析 JSON 的目标字段 | 否 | `Parent JSON node` | 最大长度：128 最大嵌套键深度：3 | **示例** 假设摄取的日志事件如下所示： ``` { "outer_key": { "inner_key": "inner_value" } } ``` 如果我们有此 **parseJSON** 处理器： ``` [ { "parseJSON": { "destination": "new_key" } } ] ``` 转换后的日志事件将如下所示。 ``` { "new_key": { "outer_key": { "inner_key": "inner_value" } } } ``` ## grok 使用 grok 处理器通过模式匹配来解析和构造非结构化数据。此处理器还可以从日志消息中提取字段。 | 字段 | 说明 | 必填？ | 默认 | 限制 | 注意 | | --- | --- | --- | --- | --- | --- | | source | 要应用 Grok 匹配的字段路径 | 否 | `@message` | 最大长度：128 最大嵌套键深度：3 | | match | 要与日志事件匹配的 grok 模式 | 是 | | 最大长度：512 最大 grok 模式：20 某些 grok 模式类型有单独的使用限制。以下模式可以任意组合使用，最多可使用五次：\$1URI, URIPARAM, URIPATHPARAM, SPACE, DATA, GREEDYDATA, GREEDYDATA\$1MULTILINE\$1 Grok 模式不支持类型转换。 对于常见的日志格式模式（APACHE\$1ACCESS\$1LOG、NGINX\$1ACCESS\$1LOG、 SYSLOG5424），仅支持在常见日志模式之后包含 DATA、GREEDYDATA 或 GREEDYDATA\$1MULTILINE 模式。 | [查看所有支持的 Grok 模式](#Grok-Patterns) | **Grok 模式的结构** 下面是支持的 grok 模式结构： ``` %{PATTERN_NAME:FIELD_NAME} ``` + **PATTERN\$1NAME**：指用于匹配特定类型数据的预定义正则表达式。仅支持预定义的 [grok 模式](#Grok-Patterns)。不允许创建自定义模式。 + **FIELD\$1NAME**：为提取的值分配名称。`FIELD_NAME` 是可选的，但是如果您不指定此值，则提取的数据将从转换后的日志事件中删除。如果 `FIELD_NAME` 使用点表示法（例如“parent.child”），则将其视为 JSON 路径。 + **类型转换**：不支持显式类型转换。使用 p [TypeConverter ro](CloudWatch-Logs-Transformation-Datatype.md#CloudWatch-Logs-Transformation-typeConverter) cessor 转换由 grok 提取的任何值的数据类型。 要创建更复杂的匹配表达式，您可以组合多个 grok 模式。最多可以组合 20 个 grok 模式来匹配一个日志事件。例如，可以使用此模式组合 `%{NUMBER:timestamp} [%{NUMBER:db} %{IP:client_ip}:%{NUMBER:client_port}] %{GREEDYDATA:data}` 从 Redis 慢日志条目中提取字段，如下所示： `1629860738.123456 [0 127.0.0.1:6379] "SET" "key1" "value1"` ### Grok 示例 #### 示例 1：使用 grok 从非结构化日志中提取字段 日志示例： ``` 293750 server-01.internal-network.local OK "[Thread-000] token generated" ``` 使用的转换器： ``` [ { "grok": { "match": "%{NUMBER:version} %{HOSTNAME:hostname} %{NOTSPACE:status} %{QUOTEDSTRING:logMsg}" } } ] ``` 输出： ``` { "version": "293750", "hostname": "server-01.internal-network.local", "status": "OK", "logMsg": "[Thread-000] token generated" } ``` 日志示例： ``` 23/Nov/2024:10:25:15 -0900 172.16.0.1 200 ``` 使用的转换器： ``` [ { "grok": { "match": "%{HTTPDATE:timestamp} %{IPORHOST:clientip} %{NUMBER:response_status}" } } ] ``` 输出： ``` { "timestamp": "23/Nov/2024:10:25:15 -0900", "clientip": "172.16.0.1", "response_status": "200" } ``` #### 示例 2：搭配使用 grok 和 parseJSON 从 JSON 日志事件中提取字段 日志示例： ``` { "timestamp": "2024-11-23T16:03:12Z", "level": "ERROR", "logMsg": "GET /page.html HTTP/1.1" } ``` 使用的转换器： ``` [ { "parseJSON": {} }, { "grok": { "source": "logMsg", "match": "%{WORD:http_method} %{NOTSPACE:request} HTTP/%{NUMBER:http_version}" } } ] ``` 输出： ``` { "timestamp": "2024-11-23T16:03:12Z", "level": "ERROR", "logMsg": "GET /page.html HTTP/1.1", "http_method": "GET", "request": "/page.html", "http_version": "1.1" } ``` #### 示例 3：FIELD\$1NAME 中带有点注释的 Grok 模式 日志示例： ``` 192.168.1.1 GET /index.html?param=value 200 1234 ``` 使用的转换器： ``` [ { "grok": { "match": "%{IP:client.ip} %{WORD:method} %{URIPATHPARAM:request.uri} %{NUMBER:response.status} %{NUMBER:response.bytes}" } } ] ``` 输出： ``` { "client": { "ip": "192.168.1.1" }, "method": "GET", "request": { "uri": "/index.html?param=value" }, "response": { "status": "200", "bytes": "1234" } } ``` ### 支持的 Grok 模式 下表列出了 `grok` 处理器支持的模式。 **常规 grok 模式** | Grok 模式 | 说明 | 最大模式限制 | 示例 | | --- | --- | --- | --- | | USERNAME 或 USER | 匹配一个或多个字符，可以包括小写字母（a-z）、大写字母（A-Z）、数字（0-9）、点（.）、下划线（\$1）或连字符（-） | 20 | 输入：`user123.name-TEST` 模式：`%{USERNAME:name}` 输出：`{"name": "user123.name-TEST"}` | | INT | 匹配可选的加号或减号，后跟一个或多个数字。 | 20 | 输入：`-456` 模式：`%{INT:num}` 输出：`{"num": "-456"}` | | BASE10NUM | 匹配带有可选符号和小数点的整数或浮点数 | 20 | 输入：`-0.67` 模式：`%{BASE10NUM:num}` 输出：`{"num": "-0.67"}` | | BASE16NUM | 匹配带有可选符号（\$1 或 -）和可选 0x 前缀的十进制和十六进制数字 | 20 | 输入：`+0xA1B2` 模式：`%{BASE16NUM:num}` 输出：`{"num": "+0xA1B2"}` | | POSINT | 匹配不带前导零的正整数，由一个或多个数字组成（1-9 后跟 0-9） | 20 | 输入：`123` 模式：`%{POSINT:num}` 输出：`{"num": "123"}` | | NONNEGINT | 匹配任何整数（由一个或多个数字 0-9 组成），包括零和带前导零的数字。 | 20 | 输入：`007` 模式：`%{NONNEGINT:num}` 输出：`{"num": "007"}` | | WORD | 匹配由一个或多个单词字符（\$1w）组成的完整单词，包括字母、数字和下划线 | 20 | 输入：`user_123` 模式：`%{WORD:user}` 输出：`{"user": "user_123"}` | | NOTSPACE | 匹配一个或多个非空格字符。 | 5 | 输入：`hello_world123` 模式：`%{NOTSPACE:msg}` 输出：`{"msg": "hello_world123"}` | | SPACE | 匹配零个或多个空格字符。 | 5 | 输入：`" "` 模式：`%{SPACE:extra}` 输出：`{"extra": " "}` | | DATA | 匹配任意字符（换行符除外）零次或多次，不贪婪。 | 5 | 输入：`abc def ghi` 模式：`%{DATA:x} %{DATA:y}` 输出：`{"x": "abc", "y": "def ghi"}` | | GREEDYDATA | 匹配任意字符（换行符除外）零次或多次，贪婪。 | 5 | 输入：`abc def ghi` 模式：`%{GREEDYDATA:x} %{GREEDYDATA:y}` 输出：`{"x": "abc def", "y": "ghi"}` | | GREEDYDATA\$1MULTILINE | 匹配任意字符（包括换行符）零次或多次，贪婪。 | 1 | 输入： `abc` `def` `ghi` 模式：`%{GREEDYDATA_MULTILINE:data}` 输出：`{"data": "abc\ndef\nghi"}` | | QUOTEDSTRING | 将带引号的字符串（单引号或双引号）与转义字符匹配。 | 20 | 输入：`"Hello, world!"` 模式：`%{QUOTEDSTRING:msg}` 输出：`{"msg": "Hello, world!"}` | | UUID | 匹配标准 UUID 格式：8 个十六进制字符，后跟三组 4 个十六进制字符，以 12 个十六进制字符结尾，全部用连字符分隔。 | 20 | 输入：`550e8400-e29b-41d4-a716-446655440000` 模式：`%{UUID:id}` 输出：`{"id": "550e8400-e29b-41d4-a716-446655440000"}` | | URN | 匹配 URN（统一资源名称）语法。 | 20 | 输入：`urn:isbn:0451450523` 模式：`%{URN:urn}` 输出：`{"urn": "urn:isbn:0451450523"}` | **AWS Grok 图案** | 模式 | 说明 | 最大模式限制 | 示例 | | --- | --- | --- | --- | | 进行筛选 | 匹配 AWS Amazon 资源名称 (ARNs)，捕获分区（`aws``aws-cn`、或`aws-us-gov`）、服务、区域、账户 ID 以及最多 5 个由斜杠分隔的分层资源标识符。它与冒号之间缺少 ARNs 的信息不匹配。 | 5 | 输入：`arn:aws:iam:us-east-1:123456789012:user/johndoe` 模式：`%{ARN:arn}` 输出：`{"arn": "arn:aws:iam:us-east-1:123456789012:user/johndoe"}` | **联网 grok 模式** | Grok 模式 | 说明 | 最大模式限制 | 示例 | | --- | --- | --- | --- | | CISCOMAC | 匹配 4-4-4 十六进制格式的 MAC 地址。 | 20 | 输入：`0123.4567.89AB` 模式：`%{CISCOMAC:MacAddress}` 输出：`{"MacAddress": "0123.4567.89AB"}` | | WINDOWSMAC | 将十六进制格式的 MAC 地址与连字符匹配 | 20 | 输入：`01-23-45-67-89-AB` 模式：`%{WINDOWSMAC:MacAddress}` 输出：`{"MacAddress": "01-23-45-67-89-AB"}` | | COMMONMAC | 将十六进制格式的 MAC 地址与冒号匹配。 | 20 | 输入：`01:23:45:67:89:AB` 模式：`%{COMMONMAC:MacAddress}` 输出：`{"MacAddress": "01:23:45:67:89:AB"}` | | MAC | 匹配 CISCOMAC、WINDOWSMAC 或 COMMONMAC grok 模式之一 | 20 | 输入：`01:23:45:67:89:AB` 模式：`%{MAC:m1}` 输出：`{"m1":"01:23:45:67:89:AB"}` | | IPV6 | 匹配 IPv6 地址，包括压缩表单和 IPv4映射 IPv6 地址。 | 5 | 输入：`2001:db8:3333:4444:5555:6666:7777:8888` 模式：`%{IPV6:ip}` 输出：`{"ip": "2001:db8:3333:4444:5555:6666:7777:8888"}` | | IPV4 | 匹配 IPv4 地址。 | 20 | 输入：`192.168.0.1` 模式：`%{IPV4:ip}` 输出：`{"ip": "192.168.0.1"}` | | IP | 匹配% \$1IPv6\$1 支持 IPv4 的地址或% \$1IPv4\$1 支持的地址 IPv6 | 5 | 输入：`192.168.0.1` 模式：`%{IP:ip}` 输出：`{"ip": "192.168.0.1"}` | | HOSTNAME 或 HOST | 匹配域名，包括子域 | 5 | 输入：`server-01.internal-network.local` 模式：`%{HOST:host}` 输出：`{"host": "server-01.internal-network.local"}` | | IPORHOST | 匹配主机名或 IP 地址 | 5 | 输入：`2001:db8:3333:4444:5555:6666:7777:8888` 模式：`%{IPORHOST:ip}` 输出：`{"ip": "2001:db8:3333:4444:5555:6666:7777:8888"}` | | HOSTPORT | 匹配 %\$1IPORHOST\$1 模式支持的 IP 地址或主机名，后跟冒号和端口号，并将端口号捕获为输出中的“PORT”。 | 5 | 输入：`192.168.1.1:8080` 模式：`%{HOSTPORT:ip}` 输出：`{"ip":"192.168.1.1:8080","PORT":"8080"}` | | URIHOST | 匹配 %\$1IPORHOST\$1 模式支持的 IP 地址或主机名，可后跟冒号和端口号，并将端口捕获为“port”（如果存在）。 | 5 | 输入：`example.com:443 10.0.0.1` 模式：`%{URIHOST:host} %{URIHOST:ip}` 输出：`{"host":"example.com:443","port":"443","ip":"10.0.0.1"}` | **Path grok 模式** | Grok 模式 | 说明 | 最大模式限制 | 示例 | | --- | --- | --- | --- | | UNIXPATH | 匹配 URL 路径，可能包含查询参数。 | 20 | 输入：`/search?q=regex` 模式：`%{UNIXPATH:path}` 输出：`{"path":"/search?q=regex"}` | | WINPATH | 匹配 Windows 文件路径。 | 5 | 输入：`C:\Users\John\Documents\file.txt` 模式：`%{WINPATH:path}` 输出：`{"path": "C:\\Users\\John\\Documents\\file.txt"}` | | 路径 | 匹配 URL 或 Windows 文件路径 | 5 | 输入：`/search?q=regex` 模式：`%{PATH:path}` 输出：`{"path":"/search?q=regex"}` | | TTY | 匹配终端和伪终端的 Unix 设备路径。 | 20 | 输入：`/dev/tty1` 模式：`%{TTY:path}` 输出：`{"path":"/dev/tty1"}` | | URIPROTO | 匹配字母，可后跟加号（\$1）字符和其他字母或加号（\$1）字符 | 20 | 输入：`web+transformer` 模式：`%{URIPROTO:protocol}` 输出：`{"protocol":"web+transformer"}` | | URIPATH | 匹配 URI 的路径组件 | 20 | 输入：`/category/sub-category/product_name` 模式：`%{URIPATH:path}` 输出：`{"path":"/category/sub-category/product_name"}` | | URIPARAM | 匹配 URL 查询参数 | 5 | 输入：`?param1=value1¶m2=value2` 模式：`%{URIPARAM:url}` 输出：`{"url":"?param1=value1¶m2=value2"}` | | URIPATHPARAM | 匹配 URI 路径，可后跟查询参数 | 5 | 输入：`/category/sub-category/product?id=12345&color=red` 模式：`%{URIPATHPARAM:path}` 输出：`{"path":"/category/sub-category/product?id=12345&color=red"}` | | URI | 匹配完整的 URI | 5 | 输入：`https://user:password@example.com/path/to/resource?param1=value1¶m2=value2` 模式：`%{URI:uri}` 输出：`{"path":"https://user:password@example.com/path/to/resource?param1=value1¶m2=value2"}` | **日期和时间 grok 模式** | Grok 模式 | 说明 | 最大模式限制 | 示例 | | --- | --- | --- | --- | | MONTH | 将完整的或缩写的英文月份名称匹配为完整单词 | 20 | 输入：`Jan` 模式：`%{MONTH:month}` 输出：`{"month":"Jan"}` 输入：`January` 模式：`%{MONTH:month}` 输出：`{"month":"January"}` | | MONTHNUM | 匹配 1 到 12 之间的月份数字，个位数月份可选择使用前导零。 | 20 | 输入：`5` 模式：`%{MONTHNUM:month}` 输出：`{"month":"5"}` 输入：`05` 模式：`%{MONTHNUM:month}` 输出：`{"month":"05"}` | | MONTHNUM2 | 匹配 01 到 12 之间的两位数月份数字。 | 20 | 输入：`05` 模式：`%{MONTHNUM2:month}` 输出：`{"month":"05"}` | | MONTHDAY | 匹配月份中的日期，从 1 到 31，可选择使用前导零。 | 20 | 输入：`31` 模式：`%{MONTHDAY:monthDay}` 输出：`{"monthDay":"31"}` | | YEAR | 匹配两位或四位数的年份 | 20 | 输入：`2024` 模式：`%{YEAR:year}` 输出：`{"year":"2024"}` 输入：`24` 模式：`%{YEAR:year}` 输出：`{"year":"24"}` | | DAY | 匹配完整或缩写的日期名称。 | 20 | 输入：`Tuesday` 模式：`%{DAY:day}` 输出：`{"day":"Tuesday"}` | | HOUR | 以 24 小时制格式匹配小时，可选择使用前导零 (0)0-23。 | 20 | 输入：`22` 模式：`%{HOUR:hour}` 输出：`{"hour":"22"}` | | MINUTE | 匹配分钟（00-59）。 | 20 | 输入：`59` 模式：`%{MINUTE:min}` 输出：`{"min":"59"}` | | SECOND | 匹配代表秒 (0)0-60 的数字，可后跟小数点或冒号，以及一个或多个数字表示小数分钟 | 20 | 输入：`3` 模式：`%{SECOND:second}` 输出：`{"second":"3"}` 输入：`30.5` 模式：`%{SECOND:minSec}` 输出：`{"minSec":"30.5"}` 输入：`30:5` 模式：`%{SECOND:minSec}` 输出：`{"minSec":"30:5"}` | | TIME | 将时间格式与小时、分钟和秒匹配，格式为 (H)H:mm:(s)s。秒包括闰秒 (0)0-60。 | 20 | 输入：`09:45:32` 模式：`%{TIME:time}` 输出：`{"time":"09:45:32"}` | | DATE\$1US | 以 (M)M/(d)d/(yy)yy 或 (M)M-(d)d-(yy)yy 格式匹配日期。 | 20 | 输入：`11/23/2024` 模式：`%{DATE_US:date}` 输出：`{"date":"11/23/2024"}` 输入：`1-01-24` 模式：`%{DATE_US:date}` 输出：`{"date":"1-01-24"}` | | DATE\$1EU | 以 (d)d/(M)M/(yy)yy、(d)d-(M)M-(yy)yy 或 (d)d.(M)M.(yy)yy 格式匹配日期。 | 20 | 输入：`23/11/2024` 模式：`%{DATE_EU:date}` 输出：`{"date":"23/11/2024"}` 输入：`1.01.24` 模式：`%{DATE_EU:date}` 输出：`{"date":"1.01.24"}` | | ISO8601\$1时区 | 将 UTC 偏移量“Z”或时区偏移量与可选冒号进行匹配，格式为 [\$1-](H)H(:)mm。 | 20 | 输入：`+05:30` 模式：`%{ISO8601_TIMEZONE:tz}` 输出：`{"tz":"+05:30"}` 输入：`-530` 模式：`%{ISO8601_TIMEZONE:tz}` 输出：`{"tz":"-530"}` 输入：`Z` 模式：`%{ISO8601_TIMEZONE:tz}` 输出：`{"tz":"Z"}` | | ISO8601\$1SECOND | 匹配代表秒 (0)0-60 的数字，可后跟小数点或冒号，以及一个或多个数字表示小数秒 | 20 | 输入：`60` 模式：`%{ISO8601_SECOND:second}` 输出：`{"second":"60"}` | | 时间戳\$1 ISO8601 | 将 ISO8601 日期时间格式 (yy) yy-(M) M-(d) dT (H) H: mm: (s) (Z\$1 [\$1-] (H) H: mm) 与可选的秒数和时区进行匹配。 | 20 | 输入：`2023-05-15T14:30:00+05:30` 模式：`%{TIMESTAMP_ISO8601:timestamp}` 输出：`{"timestamp":"2023-05-15T14:30:00+05:30"}` 输入：`23-5-1T1:25+5:30` 模式：`%{TIMESTAMP_ISO8601:timestamp}` 输出：`{"timestamp":"23-5-1T1:25+5:30"}` 输入：`23-5-1T1:25Z` 模式：`%{TIMESTAMP_ISO8601:timestamp}` 输出：`{"timestamp":"23-5-1T1:25Z"}` | | DATE | 使用 %\$1DATE\$1US\$1 匹配美国格式的日期，或者使用 %\$1DATE\$1EU\$1 匹配欧盟格式的日期 | 20 | 输入：`11/29/2024` 模式：`%{DATE:date}` 输出：`{"date":"11/29/2024"}` 输入：`29.11.2024` 模式：`%{DATE:date}` 输出：`{"date":"29.11.2024"}` | | DATESTAMP | 匹配 %\$1DATE\$1，后跟 %\$1TIME\$1 模式，用空格或连字符分隔。 | 20 | 输入：`29-11-2024 14:30:00` 模式：`%{DATESTAMP:dateTime}` 输出：`{"dateTime":"29-11-2024 14:30:00"}` | | TZ | 匹配常见的时区缩写（PST、PDT、MST、MDT、CST CDT、EST、EDT、UTC）。 | 20 | 输入：`PDT` 模式：`%{TZ:tz}` 输出：`{"tz":"PDT"}` | | 日期戳\$1 RFC822 | 按以下格式匹配日期和时间：日 MonthName (D) D (YY) YY (H) H: mm: (s) s 时区 | 20 | 输入：`Monday Jan 5 23 1:30:00 CDT` 模式：`%{DATESTAMP_RFC822:dateTime}` 输出：`{"dateTime":"Monday Jan 5 23 1:30:00 CDT"}` 输入：`Mon January 15 2023 14:30:00 PST` 模式：`%{DATESTAMP_RFC822:dateTime}` 输出：`{"dateTime":"Mon January 15 2023 14:30:00 PST"}` | | 日期戳\$1 RFC2822 | 匹配 RFC2822 日期时间格式：日，(d) d (yy) yy MonthName (H) H: mm: (s) s Z\$1 [\$1-] (H) H: mm | 20 | 输入：`Mon, 15 May 2023 14:30:00 +0530` 模式：`%{DATESTAMP_RFC2822:dateTime}` 输出：`{"dateTime":"Mon, 15 May 2023 14:30:00 +0530"}` 输入：`Monday, 15 Jan 23 14:30:00 Z` 模式：`%{DATESTAMP_RFC2822:dateTime}` 输出：`{"dateTime":"Monday, 15 Jan 23 14:30:00 Z"}` | | DATESTAMP\$1OTHER | 按格式匹配日期和时间：日 MonthName (d) d (H) H: mm: (s) s 时区 (yy) yy | 20 | 输入：`Mon May 15 14:30:00 PST 2023` 模式：`%{DATESTAMP_OTHER:dateTime}` 输出：`{"dateTime":"Mon May 15 14:30:00 PST 2023"}` | | DATESTAMP\$1EVENTLOG | 匹配不带分隔符的紧凑日期时间格式：(yy)yyMM(d)d(H)Hmm(s)s | 20 | 输入：`20230515143000` 模式：`%{DATESTAMP_EVENTLOG:dateTime}` 输出：`{"dateTime":"20230515143000"}` | **日志 grok 模式** | Grok 模式 | 说明 | 最大模式限制 | 示例 | | --- | --- | --- | --- | | LOGLEVEL | 匹配不同大小写和缩写形式的标准日志级别，包括：Alert/ALERT、Trace/TRACE、Debug/DEBUG、Notice/NOTICE、Info/INFO、Warn/Warning/WARN/WARNING、Err/Error/ERR/ERROR、Crit/Critical/CRIT/CRITICAL、Fatal/FATAL、Severe/SEVERE、Emerg/Emergency/EMERG/EMERGENCY | 20 | 输入：`INFO` 模式：`%{LOGLEVEL:logLevel}` 输出：`{"logLevel":"INFO"}` | | HTTPDATE | 匹配日志文件中经常使用的日期和时间格式。格式：(d) d/MonthName/(yy) yy :( H) H: mm: (s) s 时区：匹配完整或缩写的英文月份名称（例如 MonthName：“一月” 或 “一月”）时区：匹配% \$1INT\$1 grok 模式 | 20 | 输入：`23/Nov/2024:14:30:00 +0640` 模式：`%{HTTPDATE:date}` 输出：`{"date":"23/Nov/2024:14:30:00 +0640"}` | | SYSLOGTIMESTAMP | 将日期格式与 MonthName (d) d (H) H: mm :( s) s 匹配完整或缩写的英文月份名称（例如 MonthName：“Jan” 或 “January”） | 20 | 输入：`Nov 29 14:30:00` 模式：`%{SYSLOGTIMESTAMP:dateTime}` 输出：`{"dateTime":"Nov 29 14:30:00"}` | | PROG | 匹配由字母、数字、点、下划线、正斜杠、百分号和连字符组成的程序名称。 | 20 | 输入：`user.profile/settings-page` 模式：`%{PROG:program}` 输出：`{"program":"user.profile/settings-page"}` | | SYSLOGPROG | 匹配 PROG grok 模式，可后跟方括号中的进程 ID。 | 20 | 输入：`user.profile/settings-page[1234]` 模式：`%{SYSLOGPROG:programWithId}` 输出：`{"programWithId":"user.profile/settings-page[1234]","program":"user.profile/settings-page","pid":"1234"}` | | SYSLOGH | 匹配 %\$1HOST\$1 或 %\$1IP\$1 模式 | 5 | 输入：`2001:db8:3333:4444:5555:6666:7777:8888` 模式：`%{SYSLOGHOST:ip}` 输出：`{"ip": "2001:db8:3333:4444:5555:6666:7777:8888"}` | | SYSLOGFACILITY | 匹配十进制格式的 syslog 优先级。该值应括在尖括号（<>）中。 | 20 | 输入：`<13.6>` 模式：`%{SYSLOGFACILITY:syslog}` 输出：`{"syslog":"<13.6>","facility":"13","priority":"6"}` | **常见的 log grok 模式** 您可以使用预定义的自定义 grok 模式来匹配 Apache、NGINX 和 Syslog 协议（RFC 5424）日志格式。使用这些特定模式时，它们必须是匹配配置中的第一个模式，并且不能有其他模式位于它们之前。此外，后面只有跟有一个 **DATA**。**GREEDYDATA** 或 **GREEDYDATA\$1MULTILINE** 模式。 | Grok 模式 | 说明 | 最大模式限制 | | --- | --- | --- | | APACHE\$1ACCESS\$1LOG | 匹配 Apache 访问日志 | 1 | | NGINX\$1ACCESS\$1LOG | 匹配 NGINX 访问日志 | 1 | | SYSLOG5424 | 匹配 Syslog 协议（RFC 5424）日志 | 1 | 下面展示了使用这些常见日志格式模式的有效和无效示例。 ``` "%{NGINX_ACCESS_LOG} %{DATA}" // Valid "%{SYSLOG5424}%{DATA:logMsg}" // Valid "%{APACHE_ACCESS_LOG} %{GREEDYDATA:logMsg}" // Valid "%{APACHE_ACCESS_LOG} %{SYSLOG5424}" // Invalid (multiple common log patterns used) "%{NGINX_ACCESS_LOG} %{NUMBER:num}" // Invalid (Only GREEDYDATA and DATA patterns are supported with common log patterns) "%{GREEDYDATA:logMsg} %{SYSLOG5424}" // Invalid (GREEDYDATA and DATA patterns are supported only after common log patterns) ``` #### 常见日志格式示例 ##### Apache 日志示例 日志示例： ``` 127.0.0.1 - - [03/Aug/2023:12:34:56 +0000] "GET /page.html HTTP/1.1" 200 1234 ``` 转换器： ``` [ { "grok": { "match": "%{APACHE_ACCESS_LOG}" } } ] ``` 输出： ``` { "request": "/page.html", "http_method": "GET", "status_code": 200, "http_version": "1.1", "response_size": 1234, "remote_host": "127.0.0.1", "timestamp": "2023-08-03T12:34:56Z" } ``` ##### NGINX 日志示例 日志示例： ``` 192.168.1.100 - Foo [03/Aug/2023:12:34:56 +0000] "GET /account/login.html HTTP/1.1" 200 42 "https://www.amazon.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36" ``` 转换器： ``` [ { "grok": { "match": "%{NGINX_ACCESS_LOG}" } } ] ``` 输出： ``` { "request": "/account/login.html", "referrer": "https://www.amazon.com/", "agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36", "http_method": "GET", "status_code": 200, "auth_user": "Foo", "http_version": "1.1", "response_size": 42, "remote_host": "192.168.1.100", "timestamp": "2023-08-03T12:34:56Z" } ``` ##### Syslog 协议（RFC 5424）日志示例 日志示例： ``` <165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource= "Application" eventID="1011"][examplePriority@32473 class="high"] ``` 转换器： ``` [ { "grok": { "match": "%{SYSLOG5424}" } } ] ``` 输出： ``` { "pri": 165, "version": 1, "timestamp": "2003-10-11T22:14:15.003Z", "hostname": "mymachine.example.com", "app": "evntslog", "msg_id": "ID47", "structured_data": "exampleSDID@32473 iut=\"3\" eventSource= \"Application\" eventID=\"1011\"", "message": "[examplePriority@32473 class=\"high\"]" } ``` ## csv **csv** 处理器将日志事件中的逗号分隔值（CSV）解析为列。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | source | 日志事件中待解析字段的路径 | 否 | `@message` | 最大长度：128 最大嵌套键深度：3 | | 分隔符 | 用于分隔原始逗号分隔值日志事件中的每列的字符 | 否 | `,` | 最大长度：1，除非值为 `\t` 或 `\s` | | quoteCharacter | 用作单列数据的文本限定符的字符 | 否 | `"` | 最大长度：1 | | 列 | 转换后的日志事件中列要使用的名称列表。 | 否 | `[column_1, column_2 ...]` | CSV 最大列数：100 最大长度：128 最大嵌套键深度：3 | | destination | 放置转换后的键值对的父字段 | 否 | `Root node` | 最大长度：128 最大嵌套键深度：3 | 将 `delimiter` 设置为 `\t` 将使用制表符分隔每列，`\t` 将使用单个空格字符分隔每列。 **示例** 假设摄取的部分日志事件如下所示： ``` 'Akua Mansa':28:'New York: USA' ``` 假设我们仅使用 **csv** 处理器： ``` [ { "csv": { "delimiter": ":", "quoteCharacter": "'" } } ] ``` 转换后的日志事件将如下所示。 ``` { "column_1": "Akua Mansa", "column_2": "28", "column_3": "New York: USA" } ``` **示例 2** 假设摄取的日志事件如下所示： ``` { "timestamp": "2024-11-23T16:03:12Z", "type": "user_data", "logMsg": "'Akua Mansa':28:'New York: USA'" } ``` 假设我们将事件解析为 JSON，他们使用 cs **v** 处理器解析一个 JSON 字段，指定列名和目标： ``` [ { "parseJSON": {} }, { "csv": { "source": "logMsg", "delimiter": ":", "quoteCharacter": "'", "columns":["name","age","location"], "destination": "msg" } } ] ``` 转换后的日志事件将如下所示。 ``` { "timestamp": "2024-11-23T16:03:12Z", "logMsg": "'Akua Mansa':28:'New York: USA'", "type": "user_data", "msg": { "name": "Akua Mansa", "age": "28", "location": "New York: USA" } } ``` ## parseKeyValue 使用**parseKeyValue**处理器将指定字段解析为键值对。您可以使用以下选项自定义处理器以解析字段信息。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | source | 日志事件中待解析字段的路径 | 否 | `@message` | 最大长度：128 最大嵌套键深度：3 | | destination | 要将提取的键值对放入的目标字段 | 否 | | 最大长度：128 | | fieldDelimiter | 在原始日志事件的键值对之间使用的字段分隔符字符串 | 否 | `&` | 最大长度：128 | | keyValueDelimiter | 在转换后的日志事件中每对的键和值之间使用的分隔符字符串 | 否 | `=` | 最大长度：128 | | nonMatchValue | 当键值对未成功拆分时要在结果的值字段中插入的值。 | 否 | | 最大长度：128 | | keyPrefix | 如果要为所有转换后的键添加前缀，请在此处指定。 | 否 | | 最大长度：128 | | overwriteIfExists | 如果目标键已存在，是否覆盖该键 | 否 | `false` | | **示例** 以以下日志事件为例： ``` key1:value1!key2:value2!key3:value3!key4 ``` 假设我们使用下面的处理器配置： ``` [ { "parseKeyValue": { "destination": "new_key", "fieldDelimiter": "!", "keyValueDelimiter": ":", "nonMatchValue": "defaultValue", "keyPrefix": "parsed_" } } ] ``` 转换后的日志事件将如下所示。 ``` { "new_key": { "parsed_key1": "value1", "parsed_key2": "value2", "parsed_key3": "value3", "parsed_key4": "defaultValue" } } ``` # 用于 AWS 出售日志的内置处理器 本节包含有关内置处理器的信息，您可以将这些处理器与 AWS 提供日志的服务一起使用。 **Contents** + [parseWAF](#CloudWatch-Logs-Transformation-parseWAF) + [parsePostgres](#CloudWatch-Logs-Transformation-parsePostGres) + [parseCloudfront](#CloudWatch-Logs-Transformation-parseCloudFront) + [parseRoute53](#CloudWatch-Logs-Transformation-parseRoute53) + [parseVPC](#CloudWatch-Logs-Transformation-parseVPC) + [parseToOCSF](CloudWatch-Logs-Transformation-parseToOCSF.md) ## parseWAF 使用此处理器来解析 AWS WAF 出售的日志，它获取每个标头名称的内容`httpRequest.headers`并使用相应的值创建 JSON 密钥。它还会对 `labels` 执行相同的操作。这些转换可以使查询 AWS WAF 日志变得更加容易。有关 AWS WAF 日志格式的更多信息，请参阅 [Web ACL 流量的日志示例](https://docs.aws.amazon.com/waf/latest/developerguide/logging-examples.html)。 此处理器仅接受 `@message` 作为输入。 **重要** 如果您使用此处理器，则它必须是转换器中的第一个处理器。 **示例** 以以下日志事件为例： ``` { "timestamp": 1576280412771, "formatVersion": 1, "webaclId": "arn:aws:wafv2:ap-southeast-2:111122223333:regional/webacl/STMTest/1EXAMPLE-2ARN-3ARN-4ARN-123456EXAMPLE", "terminatingRuleId": "STMTest_SQLi_XSS", "terminatingRuleType": "REGULAR", "action": "BLOCK", "terminatingRuleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "HEADER", "matchedData": ["10", "AND", "1"] } ], "httpSourceName": "-", "httpSourceId": "-", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [], "httpRequest": { "clientIp": "1.1.1.1", "country": "AU", "headers": [ { "name": "Host", "value": "localhost:1989" }, { "name": "User-Agent", "value": "curl/7.61.1" }, { "name": "Accept", "value": "*/*" }, { "name": "x-stm-test", "value": "10 AND 1=1" } ], "uri": "/myUri", "args": "", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "rid" }, "labels": [{ "name": "value" }] } ``` 处理器配置如下所示： ``` [ { "parseWAF": {} } ] ``` 转换后的日志事件将如下所示。 ``` { "httpRequest": { "headers": { "Host": "localhost:1989", "User-Agent": "curl/7.61.1", "Accept": "*/*", "x-stm-test": "10 AND 1=1" }, "clientIp": "1.1.1.1", "country": "AU", "uri": "/myUri", "args": "", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "rid" }, "labels": { "name": "value" }, "timestamp": 1576280412771, "formatVersion": 1, "webaclId": "arn:aws:wafv2:ap-southeast-2:111122223333:regional/webacl/STMTest/1EXAMPLE-2ARN-3ARN-4ARN-123456EXAMPLE", "terminatingRuleId": "STMTest_SQLi_XSS", "terminatingRuleType": "REGULAR", "action": "BLOCK", "terminatingRuleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "HEADER", "matchedData": ["10", "AND", "1"] } ], "httpSourceName": "-", "httpSourceId": "-", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [] } ``` ## parsePostgres 使用此处理器来解析 Amazon RDS for PostgreSQL 出售的日志、提取字段并将其转换为 JSON 格式。有关 RDS for PostgreSQL 日志格式的更多信息，请参阅 [RDS for PostgreSQL 据库日志文件](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.PostgreSQL.html#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix)。 此处理器仅接受 `@message` 作为输入。 **重要** 如果您使用此处理器，则它必须是转换器中的第一个处理器。 **示例** 以以下日志事件为例： ``` 2019-03-10 03:54:59 UTC:10.0.0.123(52834):postgres@logtestdb:[20175]:ERROR: column "wrong_column_name" does not exist at character 8 ``` 处理器配置如下所示： ``` [ { "parsePostgres": {} } ] ``` 转换后的日志事件将如下所示。 ``` { "logTime": "2019-03-10 03:54:59 UTC", "srcIp": "10.0.0.123(52834)", "userName": "postgres", "dbName": "logtestdb", "processId": "20175", "logLevel": "ERROR" } ``` ## parseCloudfront 使用此处理器来解析 Amazon CloudFront 出售的日志、提取字段并将其转换为 JSON 格式。对编码的字段值进行解码。整数和双精度值按此方法处理。有关 Amazon CloudFront 日志格式的更多信息，请参阅[配置和使用标准日志（访问日志）](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html)。 此处理器仅接受 `@message` 作为输入。 **重要** 如果您使用此处理器，则它必须是转换器中的第一个处理器。 **示例** 以以下日志事件为例： ``` 2019-12-04 21:02:31 LAX1 392 192.0.2.24 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit SOX4xwn4XV6Q4rgb7XiVGOHms_BGlTAC4KyHmureZmBNrjGdRLiNIQ== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - - ``` 处理器配置如下所示： ``` [ { "parseCloudfront": {} } ] ``` 转换后的日志事件将如下所示。 ``` { "date": "2019-12-04", "time": "21:02:31", "x-edge-location": "LAX1", "sc-bytes": 392, "c-ip": "192.0.2.24", "cs-method": "GET", "cs(Host)": "d111111abcdef8.cloudfront.net", "cs-uri-stem": "/index.html", "sc-status": 200, "cs(Referer)": "-", "cs(User-Agent)": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36", "cs-uri-query": "-", "cs(Cookie)": "-", "x-edge-result-type": "Hit", "x-edge-request-id": "SOX4xwn4XV6Q4rgb7XiVGOHms_BGlTAC4KyHmureZmBNrjGdRLiNIQ==", "x-host-header": "d111111abcdef8.cloudfront.net", "cs-protocol": "https", "cs-bytes": 23, "time-taken": 0.001, "x-forwarded-for": "-", "ssl-protocol": "TLSv1.2", "ssl-cipher": "ECDHE-RSA-AES128-GCM-SHA256", "x-edge-response-result-type": "Hit", "cs-protocol-version": "HTTP/2.0", "fle-status": "-", "fle-encrypted-fields": "-", "c-port": 11040, "time-to-first-byte": 0.001, "x-edge-detailed-result-type": "Hit", "sc-content-type": "text/html", "sc-content-len": 78, "sc-range-start": "-", "sc-range-end": "-" } ``` ## parseRoute53 使用此处理器来解析 Amazon Route 53 Public Data Plane 出售的日志、提取字段并将其转换为 JSON 格式。对编码的字段值进行解码。此处理器不支持 Amazon Route 53 Resolver 日志。 此处理器仅接受 `@message` 作为输入。 **重要** 如果您使用此处理器，则它必须是转换器中的第一个处理器。 **示例** 以以下日志事件为例： ``` 1.0 2017-12-13T08:15:50.235Z Z123412341234 example.com AAAA NOERROR TCP IAD12 192.0.2.0 198.51.100.0/24 ``` 处理器配置如下所示： ``` [ { "parseRoute53": {} } ] ``` 转换后的日志事件将如下所示。 ``` { "version": 1.0, "queryTimestamp": "2017-12-13T08:15:50.235Z", "hostZoneId": "Z123412341234", "queryName": "example.com", "queryType": "AAAA", "responseCode": "NOERROR", "protocol": "TCP", "edgeLocation": "IAD12", "resolverIp": "192.0.2.0", "ednsClientSubnet": "198.51.100.0/24" } ``` ## parseVPC 使用此处理器来解析 Amazon VPC 公开发布的日志、提取字段并将其转换为 JSON 格式。对编码的字段值进行解码。 此处理器仅接受 `@message` 作为输入。 **重要** 如果您使用此处理器，则它必须是转换器中的第一个处理器。 **示例** 以以下日志事件为例： ``` 2 123456789010 eni-abc123de 192.0.2.0 192.0.2.24 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK ``` 处理器配置如下所示： ``` [ { "parseVPC": {} } ] ``` 转换后的日志事件将如下所示。 ``` { "version": 2, "accountId": "123456789010", "interfaceId": "eni-abc123de", "srcAddr": "192.0.2.0", "dstAddr": "192.0.2.24", "srcPort": 20641, "dstPort": 22, "protocol": 6, "packets": 20, "bytes": 4249, "start": 1418530010, "end": 1418530070, "action": "ACCEPT", "logStatus": "OK" } ``` # parseToOCSF `parseToOCSF` 处理器将日志转换为开放式网络安全架构框架（OCSF）事件。OCSF 是一种开放标准，它为安全数据提供了通用架构，从而能够在不同安全工具和平台之间实现更好的互操作性和分析。 该处理器对于安全分析工作流程特别有用，在这些工作流程中，您需要将来自各种 AWS 服务的日志格式标准化为一致的架构以进行下游分析。 **参数** `eventSource`（必需） 指定生成要转换的日志事件的 AWS 服务或进程。有效值为： + `CloudTrail`- CloudTrail 日志 + `Route53Resolver`：Route 53 Resolver 日志 + `VPCFlow`：Amazon VPC 流日志 + `EKSAudit`：Amazon EKS 审计日志 + `AWSWAF`- AWS WAF 日志 `ocsfVersion`（必需） 指定用于转换后的日志事件的 OCSF 架构版本。目前支持的版本：`V1.1, V1.5` `mappingVersion`（可选） 指定 OCSF 转换映射版本。控制在将日志转换为 OCSF 格式时应用哪种转换逻辑。如果未指定，则在创建策略时使用最新的可用版本。发布新的映射版本时，现有策略不会自动升级。当前最新版本:`v1.5.0`. **注意：**在支持时`ocsfVersion`不支持`V1.1`。 `source`（可选） 要解析的日志事件中字段的路径。如果省略，则解析整条日志消息。 **示例** 以下示例展示了如何使用 `parseToOCSF` 将 VPC 流日志转换为 OCSF 格式： ``` { "parseToOCSF": { "eventSource": "VPCFlow", "ocsfVersion": "V1.1" } } ``` 以下示例说明如何为一致的转换行为指定特定的映射版本： ``` { "parseToOCSF": { "eventSource": "CloudTrail", "ocsfVersion": "V1.5", "mappingVersion": "v1.5.0" } } ``` # 字符串变异处理器 本节包含有关可与日志事件转换器配合使用的字符串变异处理器的信息。 **Contents** + [lowerCaseString](#CloudWatch-Logs-Transformation-lowerCaseString) + [upperCaseString](#CloudWatch-Logs-Transformation-upperCaseString) + [splitString](#CloudWatch-Logs-Transformation-splitString) + [substituteString](#CloudWatch-Logs-Transformation-substituteString) + [trimString](#CloudWatch-Logs-Transformation-trimString) ## lowerCaseString `lowerCaseString` 处理器会将字符串转换为其小写版本。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | withKeys | 要转换为小写的键列表 | 是 | | 最多条目数：10 | **示例** 以以下日志事件为例： ``` { "outer_key": { "inner_key": "INNER_VALUE" } } ``` 转换器配置如下，将 `lowerCaseString` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "lowerCaseString": { "withKeys":["outer_key.inner_key"] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": { "inner_key": "inner_value" } } ``` ## upperCaseString `upperCaseString` 处理器会将字符串转换为其大写版本。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | withKeys | 要转换为大写的键列表 | 是 | | 最多条目数：10 | **示例** 以以下日志事件为例： ``` { "outer_key": { "inner_key": "inner_value" } } ``` 转换器配置如下，将 `upperCaseString` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "upperCaseString": { "withKeys":["outer_key.inner_key"] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": { "inner_key": "INNER_VALUE" } } ``` ## splitString `splitString` 处理器是一种字符串变异处理器，它使用分隔字符将字段拆分为数组。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | entries | 条目数组。数组中的每个项目都必须包含 source 和 delimiter 字段。 | 是 | | 最多条目数：10 | | source | 要拆分的字段值的键 | 是 | | 最大长度：128 | | 分隔符 | 用于拆分字段值的分隔符字符串 | 是 | | 最大长度：128 | **示例 1** 以以下日志事件为例： ``` { "outer_key": { "inner_key": "inner_value" } } ``` 转换器配置如下，将 `splitString` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "splitString": { "entries": [ { "source": "outer_key.inner_key", "delimiter": "_" } ] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": { "inner_key": [ "inner", "value" ] } } ``` **示例 2** 用于拆分字符串的分隔符可以包含多个字符。 以以下日志事件为例： ``` { "outer_key": { "inner_key": "item1, item2, item3" } } ``` 转换器配置如下： ``` [ { "parseJSON": {} }, { "splitString": { "entries": [ { "source": "outer_key.inner_key", "delimiter": ", " } ] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": { "inner_key": [ "item1", "item2", "item3" ] } } ``` ## substituteString `substituteString` 处理器是一种字符串变异处理器，它将键的值与正则表达式进行匹配，并将所有匹配项替换为替换字符串。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | entries | 条目数组。数组中的每个项目都必须包含 source、from 和 to 字段。 | 是 | | 最多条目数：10 | | source | 要修改的字段的键 | 是 | | 最大长度：128 最大嵌套键深度：3 | | from | 要替换的正则表达式字符串。特殊正则表达式字符（例如 [ 和 ]）在使用双引号时必须使用 \$1\$1 进行转义，在使用单引号时或通过 AWS 管理控制台配置时必须使用 \$1 进行转义。有关更多信息，请参阅 Oracle 网站上的 [Class Pattern](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/regex/Pattern.html)。 您可以将模式封装在 `(...)` 中以创建带编号的捕获组，并创建可在 `to` 字段中引用的 `(?P...)` 命名捕获组。 | 是 | | 最大长度：128 | | 修改为 | 对于捕获组的 from 反向引用的每个匹配项，可以使用要替换的字符串。对编号组使用 \$1n 形式（如 \$11），对命名组使用 \$1\$1group\$1name\$1（如 \$1\$1my\$1group\$1）。 | 是 | | 最大长度：128 反向引用最大数量：10 重复反向引用最大数量：2 | **示例 1** 以以下日志事件为例： ``` { "outer_key": { "inner_key1": "[]", "inner_key2": "123-345-567", "inner_key3": "A cat takes a catnap." } } ``` 转换器配置如下，将 `substituteString` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "substituteString": { "entries": [ { "source": "outer_key.inner_key1", "from": "\\[\\]", "to": "value1" }, { "source": "outer_key.inner_key2", "from": "[0-9]{3}-[0-9]{3}-[0-9]{3}", "to": "xxx-xxx-xxx" }, { "source": "outer_key.inner_key3", "from": "cat", "to": "dog" } ] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": { "inner_key1": "value1", "inner_key2": "xxx-xxx-xxx", "inner_key3": "A dog takes a dognap." } } ``` **示例 2** 以以下日志事件为例： ``` { "outer_key": { "inner_key1": "Tom, Dick, and Harry", "inner_key2": "arn:aws:sts::123456789012:assumed-role/MyImportantRole/MySession" } } ``` 转换器配置如下，将 `substituteString` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "substituteString": { "entries": [ { "source": "outer_key.inner_key1", "from": "(\w+), (\w+), and (\w+)", "to": "$1 and $3" }, { "source": "outer_key.inner_key2", "from": "^arn:aws:sts::(?P\\d{12}):assumed-role/(?P[\\w+=,.@-]+)/(?P[\\w+=,.@-]+)$", "to": "${account_id}:${role_name}:${role_session_name}" } ] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": { "inner_key1": "Tom and Harry", "inner_key2": "123456789012:MyImportantRole:MySession" } } ``` ## trimString `trimString` 处理器会移除键开头和结尾的空格。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | withKeys | 要剪裁的键列表 | 是 | | 最多条目数：10 | **示例** 以以下日志事件为例： ``` { "outer_key": { "inner_key": " inner_value " } } ``` 转换器配置如下，将 `trimString` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "trimString": { "withKeys":["outer_key.inner_key"] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": { "inner_key": "inner_value" } } ``` # JSON 变异处理器 本节包含有关可用于日志事件转换器的 JSON 变异处理器的信息。 **Contents** + [addKeys](#CloudWatch-Logs-Transformation-addKeys) + [deleteKeys](#CloudWatch-Logs-Transformation-deleteKeys) + [moveKeys](#CloudWatch-Logs-Transformation-moveKeys) + [renameKeys](#CloudWatch-Logs-Transformation-renameKeys) + [copyValue](#CloudWatch-Logs-Transformation-copyValue) + [listToMap](#CloudWatch-Logs-Transformation-listToMap) ## addKeys 使用 `addKeys` 处理器向日志事件添加新的键值对。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | entries | 条目数组。数组中的每个项目都可以包含 key、value 和 overwriteIfExists 字段。 | 是 | | 最多条目数：5 | | 键 | 要添加的新条目的键 | 是 | | 最大长度：128 最大嵌套键深度：3 | | 值 | 要添加的新条目的值 | 是 | | 最大长度：256 | | overwriteIfExists | 如果您将其设置为 true，而事件中已存在 key，则现有值会被覆盖。默认值为 false。 | 否 | false | 无限制 | **示例** 以以下日志事件为例： ``` { "outer_key": { "inner_key": "inner_value" } } ``` 转换器配置如下，将 `addKeys` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "addKeys": { "entries": [ { "key": "outer_key.new_key", "value": "new_value" } ] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": { "inner_key": "inner_value", "new_key": "new_value" } } ``` ## deleteKeys 使用 `deleteKeys` 处理器从日志事件中删除字段。这些字段可以包含键值对。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | withKeys | 要删除的键列表。 | 是 | 无限制 | 最多条目数：5 | **示例** 以以下日志事件为例： ``` { "outer_key": { "inner_key": "inner_value" } } ``` 转换器配置如下，将 `deleteKeys` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "deleteKeys": { "withKeys":["outer_key.inner_key"] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": {} } ``` ## moveKeys 使用 `moveKeys` 处理器将键从一个字段移动到另一个字段。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | entries | 条目数组。数组中的每个项目都可以包含 source、target 和 overwriteIfExists 字段。 | 是 | | 最多条目数：5 | | source | 要移动的键 | 是 | | 最大长度：128 最大嵌套键深度：3 | | target | 要移动至的键 | 是 | | 最大长度：128 最大嵌套键深度：3 | | overwriteIfExists | 如果您将其设置为 true，而事件中已存在 key，则现有值会被覆盖。默认值为 false。 | 否 | false | 无限制 | **示例** 以以下日志事件为例： ``` { "outer_key1": { "inner_key1": "inner_value1" }, "outer_key2": { "inner_key2": "inner_value2" } } ``` 转换器配置如下，将 `moveKeys` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "moveKeys": { "entries": [ { "source": "outer_key1.inner_key1", "target": "outer_key2" } ] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key1": {}, "outer_key2": { "inner_key2": "inner_value2", "inner_key1": "inner_value1" } } ``` ## renameKeys 使用 `renameKeys` 处理器重命名日志事件中的键。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | entries | 条目数组。数组中的每个项目都可以包含 key、target 和 overwriteIfExists 字段。 | 是 | 无限制 | 最多条目数：5 | | 键 | 要重命名的键 | 是 | 无限制 | 最大长度：128 | | target | 新的键名称 | 是 | 无限制 | 最大长度：128 最大嵌套键深度：3 | | overwriteIfExists | 如果您将其设置为 true，而事件中已存在 key，则现有值会被覆盖。默认值为 false。 | 否 | false | 无限制 | **示例** 以以下日志事件为例： ``` { "outer_key": { "inner_key": "inner_value" } } ``` 转换器配置如下，将 `renameKeys` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "renameKeys": { "entries": [ { "key": "outer_key", "target": "new_key" } ] } } ] ``` 转换后的日志事件将如下所示。 ``` { "new_key": { "inner_key": "inner_value" } } ``` ## copyValue 使用 `copyValue` 处理器复制日志事件中的值。您还可以通过将以下元数据键的值复制到日志事件中，来使用此处理器向日志事件添加元数据：`@logGroupName`、`@logGroupStream`、`@accountId`、`@regionName`。以下示例对此进行了说明。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | entries | 条目数组。数组中的每个项目都可以包含 source、target 和 overwriteIfExists 字段。 | 是 | | 最多条目数：5 | | source | 要复制的键 | 是 | | 最大长度：128 最大嵌套键深度：3 | | target | 将值复制到的键 | 是 | 无限制 | 最大长度：128 最大嵌套键深度：3 | | overwriteIfExists | 如果您将其设置为 true，而事件中已存在 key，则现有值会被覆盖。默认值为 false。 | 否 | false | 无限制 | **示例** 以以下日志事件为例： ``` { "outer_key": { "inner_key": "inner_value" } } ``` 转换器配置如下，将 `copyValue` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "copyValue": { "entries": [ { "key": "outer_key.new_key", "target": "new_key" }, { "source": "@logGroupName", "target": "log_group_name" }, { "source": "@logGroupStream", "target": "log_group_stream" }, { "source": "@accountId", "target": "account_id" }, { "source": "@regionName", "target": "region_name" } ] } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": { "inner_key": "inner_value" }, "new_key": "inner_value", "log_group_name": "myLogGroupName", "log_group_stream": "myLogStreamName", "account_id": "012345678912", "region_name": "us-east-1" } ``` ## listToMap `listToMap` 处理器获取包含键字段的对象列表，并将其转换为目标键的映射。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | source | 中的密钥 ProcessingEvent 包含将要转换为地图的对象列表 | 是 | | 最大长度：128 最大嵌套键深度：3 | | 键 | 要在生成的映射中提取为键的字段的键 | 是 | | 最大长度：128 | | valueKey | 如果指定此项，则将从 source 对象中提取您在此参数中指定的值，并将其放入生成的映射的值中。否则，源列表中的原始对象将放入生成的映射的值中。 | 否 | | 最大长度：128 | | target | 将保存生成的映射的字段的键 | 否 | 根节点 | 最大长度：128 最大嵌套键深度：3 | | flatten | 一个布尔值，指示列表是扁平化为单个项目，还是生成的映射中的值将是列表。 默认情况下，匹配键的值将以数组表示。请将 `flatten` 设置为 `true`，以根据 `flattenedElement` 的值将数组转换为单个值。 | 否 | false | | | flattenedElement | 如果将 flatten 设置为 true，则使用 flattenedElement 指定要保留哪个元素（first 或 last）。 | 在 `flatten` 设置为 `true` 时是必需的 | | 值只能是 first 或 last | **示例** 以以下日志事件为例： ``` { "outer_key": [ { "inner_key": "a", "inner_value": "val-a" }, { "inner_key": "b", "inner_value": "val-b1" }, { "inner_key": "b", "inner_value": "val-b2" }, { "inner_key": "c", "inner_value": "val-c" } ] } ``` **使用案例 1 的转换器：**`flatten` 是 `false` ``` [ { "parseJSON": {} }, { "listToMap": { "source": "outer_key" "key": "inner_key", "valueKey": "inner_value", "flatten": false } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": [ { "inner_key": "a", "inner_value": "val-a" }, { "inner_key": "b", "inner_value": "val-b1" }, { "inner_key": "b", "inner_value": "val-b2" }, { "inner_key": "c", "inner_value": "val-c" } ], "a": [ "val-a" ], "b": [ "val-b1", "val-b2" ], "c": [ "val-c" ] } ``` **使用案例 2 的转换器：**`flatten` 是 `true`，`flattenedElement` 是 `first` ``` [ { "parseJSON": {} }, { "listToMap": { "source": "outer_key" "key": "inner_key", "valueKey": "inner_value", "flatten": true, "flattenedElement": "first" } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": [ { "inner_key": "a", "inner_value": "val-a" }, { "inner_key": "b", "inner_value": "val-b1" }, { "inner_key": "b", "inner_value": "val-b2" }, { "inner_key": "c", "inner_value": "val-c" } ], "a": "val-a", "b": "val-b1", "c": "val-c" } ``` **使用案例 3 的转换器：**`flatten` 是 `true`，`flattenedElement` 是 `last` ``` [ { "parseJSON": {} }, { "listToMap": { "source": "outer_key" "key": "inner_key", "valueKey": "inner_value", "flatten": true, "flattenedElement": "last" } } ] ``` 转换后的日志事件将如下所示。 ``` { "outer_key": [ { "inner_key": "a", "inner_value": "val-a" }, { "inner_key": "b", "inner_value": "val-b1" }, { "inner_key": "b", "inner_value": "val-b2" }, { "inner_key": "c", "inner_value": "val-c" } ], "a": "val-a", "b": "val-b2", "c": "val-c" } ``` # 数据类型转换器处理器 本节包含有关可与日志事件转换器配合使用的数据类型转换器处理器的信息。 **Contents** + [typeConverter](#CloudWatch-Logs-Transformation-typeConverter) + [datetimeConverter](#CloudWatch-Logs-Transformation-datetimeConverter) ## typeConverter 使用 `typeConverter` 处理器可以将与指定的键关联的值类型转换为指定的类型。它是一个转换处理器，可以更改指定字段的类型。值可以转换为以下数据类型之一：`integer`、`double`、`string` 和 `boolean`。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | entries | 条目数组。数组中的每个项目都必须包含 key 和 type 字段。 | 是 | | 最多条目数：10 | | 键 | 要转换为其他类型的键和值 | 是 | | 最大长度：128 最大嵌套键深度：3 | | 类型 | 要转换为的类型。有效值包括 integer、double、string 和 boolean。 | 是 | | | **示例** 以以下日志事件为例： ``` { "name": "value", "status": "200" } ``` 转换器配置如下，将 `typeConverter` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "typeConverter": { "entries": [ { "key": "status", "type": "integer" } ] } } ] ``` 转换后的日志事件将如下所示。 ``` { "name": "value", "status": 200 } ``` ## datetimeConverter 使用 `datetimeConverter` 处理器可以将日期时间字符串转换为您指定的格式。 | 字段 | 说明 | 必填？ | 默认 | 限制 | | --- | --- | --- | --- | --- | | source | 对其应用日期转换的键。 | 是 | | 最多条目数：10 | | matchPatterns | 与 source 字段匹配的模式列表 | 是 | | 最多条目数：5 | | target | 用于存储结果的 JSON 字段。 | 是 | | 最大长度：128 最大嵌套键深度：3 | | targetFormat | 用于目标字段中的转换后数据的日期时间格式。 | 否 | ` yyyy-MM-dd'T'HH:mm:ss.SSS'Z` | 最大长度：64 | | sourceTimezone | 源字段的时区。 有关可能值的列表，请参阅 [Java Supported Zone Ids and Offsets](https://howtodoinjava.com/java/date-time/supported-zone-ids-offsets/#3-java-supported-zone-ids-and-offsets)。 | 否 | UTC | 最小长度：1 | | 目标时区 | 目标字段的时区。 有关可能值的列表，请参阅 [Java Supported Zone Ids and Offsets](https://howtodoinjava.com/java/date-time/supported-zone-ids-offsets/#3-java-supported-zone-ids-and-offsets)。 | 否 | UTC | 最小长度：1 | | locale | 源字段的区域设置。 有关可能值的列表，请参阅 [Java 中的 Locale getAvailableLocales () 方法和示例](https://www.geeksforgeeks.org/locale-getavailablelocales-method-in-java-with-examples/)。 | 是 | | 最小长度：1 | **示例** 以以下日志事件为例： ``` {"german_datetime": "Samstag 05. Dezember 1998 11:00:00"} ``` 转换器配置如下，将 `dateTimeConverter` 和 `parseJSON` 结合使用： ``` [ { "parseJSON": {} }, { "dateTimeConverter": { "source": "german_datetime", "target": "target_1", "locale": "de", "matchPatterns": ["EEEE dd. MMMM yyyy HH:mm:ss"], "sourceTimezone": "Europe/Berlin", "targetTimezone": "America/New_York", "targetFormat": "yyyy-MM-dd'T'HH:mm:ss z" } } ] ``` 转换后的日志事件将如下所示。 ``` { "german_datetime": "Samstag 05. Dezember 1998 11:00:00", "target_1": "1998-12-05T17:00:00 MEZ" } ``` # 转换指标和错误 CloudWatch 日志将转换指标发布到 CloudWatch。这些指标包括 `TransformedLogEvents`、`TransformedBytes` 和 `TransformationErrors`。有关更多信息，请参阅 [日志转换器指标和维度](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md#CloudWatchLogs-Transformer-Metrics)。 每当 Lo CloudWatch gs 尝试转换日志事件但失败时，它都会向该日志事件添加一个`@transformationError`系统字段。运行 CloudWatch Logs Insights 查询时，您将在转换失败的所有日志事件中看到此字段。您可以使用一个查询来查询此字段，例如 `filter ispresent(@transformationError)` 可查找所有失败的转换事件。