如何利用 AWS Logs Insights 从 AWS 服务日志中查询控制面板指标

每个 AWS 服务都会将其处理记录到 CloudWatch 日志组下组织的文件中。日志组通常以服务本身命名，以便于识别。默认情况下，服务的系统消息或通用状态信息将写入这些日志文件中。

但是，您可以在默认日志消息信息的基础上添加自定义日志消息信息。如果明智地创建此类日志，它们可用于创建有用的 CloudWatch 控制面板。

使用指标和结构化信息，提供有关作业处理的更多详细信息。它们不仅可以包含标准小部件，其中包含有关服务的类似系统的信息。您可以使用自己的内容进行扩展，并聚合到您的自定义小部件或指标中。

查询日志文件

借助 AWS CloudWatch Log Insights，您可以实时搜索和分析 AWS 资源中的日志数据。您可以将其视为数据库视图。在仪表板上定义查询，当您访问它时或在过去指定的时间窗口（在仪表板视图中定义查询时），仪表板将选择它。

它使用名为 CloudWatch Logs Insights 的查询语言来搜索和分析日志数据。查询语言基于 SQL 语言的子集。它允许您搜索和筛选日志数据。您可以搜索特定日志事件、自定义日志文本或关键字，并根据特定字段筛选日志数据。最重要的是，将日志数据聚合到一个或多个日志文件中，以生成汇总的指标和可视化效果。

当您运行查询时，CloudWatch Log Insights 会搜索日志组中的日志数据。然后，它返回与查询条件匹配的文件生成的文本。

日志文件查询示例

让我们看一下一些基本查询来理解这个概念。

默认情况下，每个服务都会记录一些关键的服务错误。即使您没有为此类错误事件创建专用的自定义日志。然后，通过一个简单的查询，您可以计算过去一小时内应用程序日志中的错误数：

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)

或者，以下是如何监控 API 在过去一天的平均响应时间：

fields @timestamp, @message
| filter @message like /API response time/
| stats avg(response_time) by bin(1d)

由于默认情况下，CPU 利用率是服务记录到 CloudWatch 中的信息，因此您也可以收集此类指标：

fields @timestamp, @message
| filter @message like /CPUUtilization/
| stats avg(value) by bin(1h)

这些查询可以自定义以适合您的特定使用案例，并可用于在 CloudWatch 控制面板中创建自定义指标和可视化效果。如何做到这一点的方法是将小部件放在仪表板上，并将代码放在小部件中以定义要选择的内容。

以下是一些可在 CloudWatch 控制面板中使用并由 Log Insights 中的内容填充的小组件：

• 文本小组件 – 显示基于文本的信息，例如 CloudWatch Insights 查询的输出。

• 日志查询小部件 – 显示 CloudWatch Insights 日志查询的结果，例如应用程序日志中的错误数。

如何为仪表板创建有用的日志信息

为了在 CloudWatch 控制面板中有效地使用 CloudWatch Insights 查询，在为您在系统中使用的每项服务创建 CloudWatch 日志时，最好遵循一些最佳实践。以下是一些提示：

#1。 使用结构化日志记录

应坚持使用使用预定义架构以结构化格式记录数据的日志记录格式。这样可以更轻松地使用 CloudWatch Insights 查询搜索和筛选日志数据。

这基本上意味着在架构平台中跨不同服务标准化日志。在开发标准中定义它有很大帮助。

例如，您可以定义与特定数据库表相关的每个问题都将记录为起始消息：“[TABLE_NAME] 警告/错误：<message>”。

或者，您可以通过前缀（如“[FULL/DELTA]”）将完整数据作业与增量数据作业分开，以仅选择与具体数据进程相关的消息。

您可以定义在处理来自特定源系统的数据时，系统名称将是每个相关日志条目的前缀。之后，从日志文件中筛选此类消息并基于它们构建指标要容易得多。

#2。 使用一致的日志格式

在所有 AWS 资源中使用一致的日志格式，以便更轻松地使用 CloudWatch Insights 查询搜索和筛选日志数据。

这与上一点有很大关系，但事实是日志格式越标准化，日志数据就越容易使用。然后，开发人员可以依赖该格式，甚至可以直观地使用它。

残酷的事实是，大多数项目都不考虑任何关于伐木的标准。更重要的是，许多项目甚至根本不创建任何自定义日志。这令人震惊，但同时也很常见。

我甚至不知道有多少次我发现自己想知道人们如何在没有任何错误处理方法的情况下生活在这里。如果有人试图将某种错误处理作为例外，他们就做错了。

因此，一致的日志格式是一项强大的资产。没有多少人拥有它们。

#3。 包括相关元数据

在日志数据中包含元数据，例如时间戳、资源 ID 和错误代码，以便更轻松地使用 CloudWatch Insights 查询搜索和筛选日志数据。

#4。 启用日志轮换

启用日志轮换可防止日志数据变得过大，并更轻松地使用 CloudWatch Insights 查询搜索和筛选日志数据。

没有日志数据是一回事，但有太多没有结构的日志数据同样令人绝望。如果你不能使用你的数据，就像根本没有数据一样。

#5。 使用 CloudWatch Logs 代理

如果您身不由己，只是拒绝构建自定义日志系统，那么至少使用 CloudWatch Logs 代理。它们会自动将日志数据从您的 AWS 资源发送到 CloudWatch Logs。这样可以更轻松地使用 CloudWatch Insights 查询搜索和筛选日志数据。

更复杂的见解查询示例

CloudWatch Insights 查询可能比只有两行语句更复杂。

fields @timestamp, @message
| filter @message like /ERROR/
| filter @message not like /404/
| parse @message /.*[(?<timestamp>[^]]+)].*"(?<method>[^s]+)s+(?<path>[^s]+).*" (?<status>d+) (?<response_time>d+)/
| stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status
| sort count desc
| limit 20

此查询执行以下操作：

1. 选择包含字符串“ERROR”但不包含“404”的日志事件。
2. 解析日志消息，提取时间戳、HTTP 方法、路径、状态码、响应时间。
3. 计算 HTTP 方法、路径、状态代码和小时的每个组合的平均响应时间和日志事件计数。
4. 按降序计数对结果进行排序。
5. 将输出限制为前 20 个结果。

此查询可识别应用程序中最常见的错误，并跟踪 HTTP 方法、路径和状态代码的每种组合的平均响应时间。您可以使用这些结果在 CloudWatch 控制面板中创建自定义指标和可视化，以监控 Web 应用程序的性能并排查问题。

查询 Amazon S3 服务消息的另一个示例：

fields @timestamp, @message
| filter @message like /REST.API.REQUEST/
| parse @message /.*"(?<method>[^s]+)s+(?<path>[^s]+).*" (?<status>d+) (?<response_time>d+)/
| stats avg(response_time) as avg_response_time, count() as count by bin(1h), method, path, status
| sort count desc
| limit 20

• 查询选择包含字符串“REST.应用程序接口。请求“。
• 然后解析日志消息，提取HTTP方法、路径、状态码和响应时间。
• 它计算 HTTP 方法、路径和状态代码的每个组合的平均响应时间和日志事件计数，并按计数降序对结果进行排序。
• 将输出限制为前 20 个结果。

您可以使用此查询的输出在 CloudWatch 控制面板中创建折线图，该折线图显示 HTTP 方法、路径和状态代码的每种组合随时间推移的平均响应时间。

构建仪表板

要从 CloudWatch Insights 日志查询的输出中填写 CloudWatch 控制面板中的指标和可视化效果，您可以导航到 CloudWatch 控制台并按照控制面板向导构建内容。

之后，CloudWatch 控制面板的代码如下所示，其中包含由 CloudWatch Insights 查询数据填充的指标：

{
    "widgets": [
        {
            "type": "metric",
            "x": 0,
            "y": 0,
            "width": 12,
            "height": 6,
            "properties": {
                "metrics": [
                    [
                        "AWS/EC2",
                        "CPUUtilization",
                        "InstanceId",
                        "i-0123456789abcdef0",
                        {
                            "label": "CPU Utilization",
                            "stat": "Average",
                            "period": 300
                        }
                    ]
                ],
                "view": "timeSeries",
                "stacked": false,
                "region": "us-east-1",
                "title": "EC2 CPU Utilization"
            }
        },
        {
            "type": "log",
            "x": 0,
            "y": 6,
            "width": 12,
            "height": 6,
            "properties": {
                "query": "fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)
",
                "region": "us-east-1",
                "title": "Application Errors"
            }
        }
    ]
}

This CloudWatch Dashboard contains two widgets:

1. A metric widget that displays the average CPU utilization of an EC2 instance over time. CloudWatch Insights Query populates the widget. It selects the CPU utilization data for a specific EC2 instance and aggregates it at 5-minute intervals.
2. A log widget that displays the number of application errors over time. It selects log events that contain the string “ERROR” and aggregates them by the hour.

它是一个 JSON 格式文件，其中包含仪表板和指标的定义。它还包含（作为属性）见解查询本身。

您可以获取代码并将其部署到所需的任何 AWS 账户。假设服务和日志消息在您的所有 AWS 账户和阶段上保持一致，则控制面板将在所有账户上运行，而无需更改控制面板的源代码。

最后的话

建立稳固的日志记录结构始终是对系统可靠性未来的良好投资。现在它可以服务于一个更伟大的目的。您可以拥有有用的仪表板，其中包含指标和可视化效果，作为其副作用。

由于只需要做一次，只需做一点额外的工作，开发团队、测试团队和生产用户都可以从同一个解决方案中受益。

如何利用 AWS Logs Insights 从 AWS 服务日志中查询控制面板指标 (geekflare.com)