亚马逊AWS官方博客

使用自然语言查询 Amazon CloudWatch 日志和指标(预览版)



为方便您用好运营数据,Amazon CloudWatch 今天推出了适用于 Logs 和 Metrics Insights 的自然语言查询生成功能。借助这种由生成式人工智能(AI)支持的功能,您只需用英语描述所需要的见解,然后系统将自动为您生成 Logs 或 Metrics Insights 查询。

此功能主要包含三种有关 CloudWatch Logs 和 Metrics Insights 的能力:

  • 可根据描述或问题生成新的查询,从而方便您快速开始使用。
  • 可提供有助您学习该语言的查询说明,包括更多高级功能。
  • 可使用引导式迭代优化现有查询。

下面让我们通过几个示例来了解这项新功能的实践运用。我将先介绍日志,然后介绍指标。

使用自然语言生成 CloudWatch Logs Insights 查询
CloudWatch 控制台中,我在日志部分选择了 Log Insights。然后,我选择需要调查的 AWS Lambda 函数对应的日志组。

我选择查询生成器按钮来打开一个新的提示字段,然后在其中使用自然语言输入我需要的内容:

Tell me the duration of the 10 slowest invocations

然后,我选择生成新查询。系统自动生成了以下 Log Insights 查询:

fields @timestamp, @requestId, @message, @logStream, @duration 
| filter @type = "REPORT" and @duration > 1000
| sort @duration desc
| limit 10

控制台屏幕截图。

我选择运行查询来查看结果。

控制台屏幕截图。

我发现现在输出中的信息太多了。我希望只看到我需要的数据,因此我在提示中输入以下语句,然后选择更新查询

Show only timestamps and latency

然后系统根据我的输入更新了查询,只返回了时间戳和持续时间信息:

fields @timestamp, @duration 
| filter @type = "REPORT" and @duration > 1000
| sort @duration desc
| limit 10

我运行更新后的查询,得到的结果更方便我阅读。

控制台屏幕截图。

现在,我想知道日志中是否记录了错误。我在提示符中输入下面这句话并生成新的查询:

Count the number of ERROR messages

生成的查询正按照请求计算包含 ERROR 字符串的消息:

fields @message
| filter @message like /ERROR/
| stats count()

我运行该查询,发现错误比我预料的要多。我需要更多信息。

控制台屏幕截图。

我使用下面的提示来更新查询,以便更好地了解错误的分布情况:

Show the errors per hour

更新后的查询使用 bin() 函数,以一小时的间隔时间对结果进行分组。

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

下面来看一个关于内存使用情况的更高级查询。我选择了几个 Lambda 函数的日志组,然后键入以下语句:

Show invocations with the most over-provisioned memory grouped by log stream

在生成查询之前,我选择了齿轮图标来切换选项,以将我的提示和说明作为注释包括在其中。获得的结果如下(为便于阅读,我将说明分成多行):

# Show invocations with the most over-provisioned memory grouped by log stream

fields @logStream, @memorySize/1000/1000 as memoryMB, @maxMemoryUsed/1000/1000 as maxMemoryUsedMB, (@memorySize/1000/1000 - @maxMemoryUsed/1000/1000) as overProvisionedMB 
| stats max(overProvisionedMB) as maxOverProvisionedMB by @logStream 
| sort maxOverProvisionedMB desc

# This query finds the amount of over-provisioned memory for each log stream by
# calculating the difference between the provisioned and maximum memory used.
# It then groups the results by log stream and calculates the maximum
# over-provisioned memory for each log stream.Finally, it sorts the results
# in descending order by the maximum over-provisioned memory to show
# the log streams with the most over-provisioned memory.

现在,我获得了所需的信息来了解这些错误。此外,我还有一些 EC2 工作负载。这些实例的运行情况如何? 让我们来看看一些指标。

使用自然语言生成 CloudWatch Metrics Insights 查询
CloudWatch 控制台中,我在指标部分选择了所有指标。然后在查询选项卡中,我使用了编辑器。需要时也可以使用生成器中的查询生成器

与以前一样,我选择了查询生成器。然后,我用通俗易懂的英语输入我需要的信息:

Which 10 EC2 instances have the highest CPU utilization?

我选择生成新查询并使用 Metrics Insights 语法获取结果。

SELECT AVG("CPUUtilization")
FROM SCHEMA("AWS/EC2", InstanceId)
GROUP BY InstanceId
ORDER BY AVG() DESC
LIMIT 10

我选择了运行以查看图表。

控制台屏幕截图。

嗯,看起来我的 EC2 实例不太繁忙。该结果显示了实例的 CPU 利用情况,存储方面呢? 我在提示中输入了下面的内容并选择了更新查询

How about the most EBS writes?

更新后的查询不再返回平均 CPU 利用率,而是写入挂载到实例的所有 EBS 卷的字节数总和。该查询保留了仅显示前 10 个结果的限制。

SELECT SUM("EBSWriteBytes")
FROM SCHEMA("AWS/EC2", InstanceId)
GROUP BY InstanceId
ORDER BY SUM() DESC
LIMIT 10

我运行了查询,通过查看结果,我更好地了解了我的 EC2 实例的存储使用情况。

您可以尝试输入一些请求,然后运行针对日志和指标生成的查询,以使用您自己的数据来了解该功能。

注意事项
Amazon CloudWatch 自然语言日志和指标查询生成功能已在美国东部(弗吉尼亚州北部)和美国西部(俄勒冈州)AWS 区域推出预览版。

预览开放期间使用自然语言查询生成功能不会产生额外费用。您只需按照 CloudWatch 定价支付运行查询的费用即可。

查询将由生成式人工智能生成,具体取决于多种因素,包括您账户中选择和可用的数据。由于这些原因,实际结果可能会有所不同。

生成查询时,您可以将原始请求和查询说明作为注释包含在其中。为此,请选择查询编辑窗口右下角的齿轮图标,并切换这些选项。

您可以借助此新功能来生成和更新日志和指标查询,从而节省时间和精力。该功能有利于工程团队放心扩大运营规模,无需关心是否具备具体的数据知识或查询专业知识。

使用自然语言来分析 Amazon CloudWatch 日志和指标。

Danilo