如何使用AWS日志洞察从AWS服务日志中查询仪表板指标

每个AWS服务都将其处理过程记录在云监控日志组中的文件中。这些日志组通常以服务本身命名，以便更容易识别。默认情况下，服务的系统消息或常见状态信息会写入这些日志文件中。

但是，您可以在默认日志的基础上添加自定义日志消息信息。如果明智地创建这些日志，它们可以用于创建有用的云监控仪表板。

通过指标和结构化信息提供有关作业处理的额外详细信息。它们不仅可以包含关于服务的类似系统的标准小部件信息。您还可以将其扩展为自己的内容，并将其聚合到自定义小部件或指标中。

查询日志文件

AWS云监控日志洞察允许您实时搜索和分析来自AWS资源的日志数据。您可以将其视为数据库视图。您在仪表板上定义查询，仪表板会在您访问它或在过去的指定时间窗口内根据您在仪表板视图中定义的方式选择它。

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

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

日志文件查询示例

让我们看一些基本的查询以了解这个概念。

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

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] 警告/错误：”。

或者您可以通过“[全量/增量]”前缀将全量数据作业与增量数据作业分开，以仅选择与具体数据处理相关的消息。

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

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

在所有的AWS资源上使用一致的日志格式，以便更容易使用CloudWatch Insights查询搜索和过滤日志数据。

这与前一点相关，但事实是，日志格式标准化得越多，使用日志数据就越容易。开发人员可以依赖该格式，甚至可以直观地使用它。

残酷的事实是，大多数项目都不关心日志记录的任何标准。更糟糕的是，很多项目根本不创建任何自定义日志。这令人震惊，但也是如此常见。

我甚至无法告诉你有多少次我想知道人们如何在没有任何错误处理方法的情况下生活在这里。如果有人作出努力以某种错误处理作为异常，则他们做错了。

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

#3. 包含相关元数据

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

#4. 启用日志轮转

启用日志轮转，以防止日志数据变得过大，并更容易使用CloudWatch Insights查询搜索和过滤日志数据。

没有日志数据是一回事，但是没有结构的过多日志同样令人绝望。如果您无法使用数据，那就像没有数据一样。

#5. 使用CloudWatch日志代理

如果您无法自助，并且拒绝构建自定义的日志系统，那么至少使用CloudWatch日志代理。它们会自动将您的AWS资源的日志数据发送到CloudWatch日志。这样可以更容易地使用CloudWatch Insights查询搜索和过滤日志数据。

更复杂的Insights查询示例

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

fields @timestamp, @message
| filter @message like /ERROR/
| filter @message not like /404/
| parse @message /.*[(?[^]]+)].*"(?[^s]+)s+(?[^s]+).*" (?d+) (?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应用程序的性能并解决问题。

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

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

• 该查询选择包含字符串“REST.API.REQUEST”的日志事件。
• 然后解析日志消息以提取HTTP方法、路径、状态码和响应时间。
• 它计算每个HTTP方法、路径和状态码的平均响应时间和日志事件数，并按计数降序排序结果。
• 将输出限制为前20个结果。

您可以使用此查询的输出在CloudWatch仪表板中创建折线图，显示每个HTTP方法、路径和状态码随时间变化的平均响应时间。

构建仪表板

要从CloudWatch Insights日志查询的输出中填充CloudWatch仪表板中的指标和可视化内容，您可以转到CloudWatch控制台，并按照仪表板向导的步骤构建内容。

然后，以下是由CloudWatch Insights查询数据填充的CloudWatch仪表板代码：

{
    "widgets": [
        {
            "type": "metric",
            "x": 0,
            "y": 0,
            "width": 12,
            "height": 6,
            "properties": {
                "metrics": [
                    [
                        "AWS/EC2",
                        "CPUUtilization",
                        "InstanceId",
                        "i-0123456789abcdef0",
                        {
                            "label": "CPU利用率",
                            "stat": "Average",
                            "period": 300
                        }
                    ]
                ],
                "view": "timeSeries",
                "stacked": false,
                "region": "us-east-1",
                "title": "EC2 CPU利用率"
            }
        },
        {
            "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": "应用程序错误"
            }
        }
    ]
}

此CloudWatch仪表板包含两个小部件：

1. 一个指标小部件，显示EC2实例的平均CPU利用率随时间变化的情况。CloudWatch Insights查询填充了该小部件。它选择特定EC2实例的CPU利用率数据，并以5分钟间隔进行聚合。
2. 一个日志小部件，显示随时间变化的应用程序错误数量。它选择包含字符串“ERROR”的日志事件，并按小时进行聚合。

这是一个具有仪表板和度量定义的格式文件。它还包含（作为属性）洞察查询本身。

您可以获取代码并将其部署到您需要的任何AWS帐户。假设所有AWS帐户和阶段上的服务和日志消息都是一致的，仪表板将在所有帐户上工作，而无需更改仪表板的源代码。

最后的话

建立一个坚实的日志结构始终是对系统可靠性未来的良好投资。现在它可以作为一个更大的目的。通过这一方式，您可以获得有用的带有指标和可视化效果的仪表板。

只需要进行一次必要操作，并进行少量额外工作，开发团队、测试团队和生产用户都可以从同一解决方案中受益。

接下来，请查看最佳的AWS monitoring tools。