亚马逊AWS官方博客
使用 Amazon CloudWatch Lambda 见解提高运营可见性
为了平衡成本，同时确保满足业务需求所需的服务级别，一些客户选择持续监控和优化其 AWS Lambda 函数。他们收集和分析指标和日志以监控性能，并隔离错误以进行故障排除。此外，他们还试图通过测量函数持续时间、CPU 使用率和内存分配来调整函数配置的大小。使用各种工具和数据源来完成此操作可能非常耗时，有些甚至要构建自己的自定义控制面板来显示和分析这些数据。
去年 10 月，我们宣布推出 Amazon CloudWatch Lambda Insights 作为 公开预览版，旨在让客户对 Lambda 函数的行为获得更深入的运营监督和可见性。今天，我很高兴地宣布 CloudWatch Lambda Insights 现已正式推出。CloudWatch Lambda Insights 通过在预先构建的控制面板中自动整理和汇总 Lambda 性能指标、错误和日志，为函数提供更清晰和更简单的操作可见性，从而使您免于执行耗时的人工工作。
一旦在您的函数上启用后，CloudWatch Lambda Insights 即会自动开始收集和汇总性能指标和日志，并且通过便捷的控制面板让您可以一键式深入了解 Lambda 函数请求的指标和错误，从而简化分析和故障排除。
探索 CloudWatch Lambda Insights
要开始使用，我需要在函数上启用 Lambda Insights。在 Lambda 控制台中，导航至我的函数列表，然后通过单击函数名称选择我想要为 Lambda Insights 启用的函数。然后，我从函数的配置视图中，滚动至 Monitoring tools（监控工具）面板，点击 Edit（编辑），启用 Enhanced monitoring（增强监控），然后单击 Save（保存）。如果您想要为很多函数启用增强监控功能，您会发现使用 AWS 命令行界面 (CLI)、AWS Tools for PowerShell 或 AWS CloudFormation 方法更加方便。请注意，启用增强监控后，数据可能需要几分钟才能在开始在 CloudWatch 中显示。
在 Amazon CloudWatch 控制台中，我首先选择导航面板中的 Lambda Insights 下的 Performance monitoring（性能监控）。这将带我进入多函数视图。视图中显示了我启用了 Lambda Insights 的所有函数的指标。页面底部还有一个列出函数的表格，汇总了图表中的一些数据并添加了冷启动。通过这个表格，我可以根据我感兴趣的指标对数据进行排序。
这个页面上还有一个有趣的图表，那就是函数成本，尤其是当您试图平衡成本与性能时。该图表以兆字节毫秒 (MB-MS) 为单位显示了函数的直接成本，这就是 Lambda 计算函数调用的财务费用的方式。将鼠标悬停在特定时间点的图表上可以显示更多详细信息。
下面我们来进一步检查我的 ExpensiveFunction。移动到页面底部的摘要列表，我单击函数名称，然后被带到单一函数视图中（从这里我可以使用页面顶部的控件切换到我的其他函数，而无需返回到多函数视图）。这些图表显示了调用和错误、持续时间、限制以及所选函数上的内存、CPU 和网络使用情况的指标，为了添加到可用的详细信息中，表格还列出了最近的 1000 次调用，我可以根据需要对它们进行排序。
单击调用列表中某个请求的 Trace（跟踪）列中的 View（视图），我将进入 Service Lens（服务剖析）跟踪视图，其中显示了我的函数将时间花在了那个特定调用请求的什么地方。我可以用它来确定函数的业务逻辑更改是否可以通过缩短函数持续时间来提高性能，这将对成本产生直接影响。如果我正在进行故障排除，我可以使用 View logs（查看日志）按钮查看函数的 Application（应用程序）或 Performance logs（性能日志）。应用程序日志是在函数上启用 Lambda Insights 之前就已存在的日志，而性能日志是则是 Lambda Insights 在我启用的所有函数中整理的日志。日志视图使我能够运行查询，并且在性能日志的情况下，我可以对账户中所有已启用的函数运行查询，例如执行 Top-N 分析以确定最昂贵的函数，或者查看一个函数与另一个函数的比较情况。
以下介绍我如何通过检查内存分配变化对函数成本的影响在尝试调整函数大小时使用 Lambda Insights 来检查我是否在向正确的方向“移动指针”。我的 ExpensiveFunction 的起点是 128MB。通过从 128MB 移动到 512MB，数据向我显示，函数成本、持续时间和并发性都减少了——如图表中的 (1) 所示。从 512MB 移动到 1024MB (2) 对函数成本没有影响，但它将持续时间进一步缩短 50%，同时也影响着最大并发性。我进一步进行了两个实验，首先是从 1024MB 移动到 2048MB (3)，这导致持续时间进一步缩短，但函数成本开始增加，因此指针开始朝错误的方向摆动。最后，从 2048MB 移至 3008MB (4)，这显著增加了成本，但对持续时间没有影响。在 Lambda Insights 的帮助下，我可以推断这个函数的最有效点（假设延迟不是考虑因素）在 1024MB 和 2048MB 之间。所有这些实验都在下图中显示（并发图稍微滞后，随着配置更改的发生，之前的调用正在完成）。
CloudWatch Lambda Insights 提供简单方便的运营监督以及对 AWS Lambda 函数的可见性，现已在提供 AWS Lambda 的所有区域推出。
有关 Amazon CloudWatch Lambda Insights 的更多信息，请参阅文档，立即开始使用。