很多工具可以帮助开发人员设置日志转发，以监视错误和异常。

作为开发人员,通常喜欢Lambda函数。它们使开发人员能够专注于功能的目的，并节省了编写和部署代码的大量时间。同时，在生产中使用Lambda函数的最大挑战之一是问题的故障排除。这是由于代码与用户如何体验应用程序之间的可见性差距，以及缺少专门解决无服务器环境中此关键问题的监视工具所致。

当然，亚马逊公司的监视工具CloudWatch提供了一种跟踪功能指标并深入日志进行调试的方法。但是，梳理日志并不是开发人员要调试问题的方式，它需要几个小时。

很多工具可以帮助开发人员设置日志转发，以监视错误和异常。它们通常的工作方式如下：

使用预先配置的Cloud Formation堆栈来设置环境中的云资源和权限。

使用CloudWatch API将经过过滤的日志流化（通常使用Kinesis+Firehose）到自己的工具中。

将格式应用于摄取的日志，以更易用的方式显示错误和异常。

这个过程很棒。开发人员能够在几分钟内设置错误监控，而无需更改代码。另外，现在有了堆栈跟踪和有趣的函数详细信息，例如：

•功能存储器使用。

•函数调用时间。

•执行lambda函数的成本。

挑战性

现在，这是该方法面临的挑战：开发人员不喜欢该工具可以控制其AWS帐户，因为该工具正在使用假定角色来访问帐户信息。

堆栈跟踪仍然很难阅读。这是一个例子：

许多运行时场景都丢失了，例如其他线程以及配置其他参数的能力。看不到跟踪或事务，以便能够调试整个应用程序中的问题以关联前端和后端行为。

因此，尽管从CloudWa。tch进行日志转发比使用CloudWatch本身要好，但这并非没有缺陷。

通过代码检测报告错误

接下来，尝试通过代码检测报告错误。为了进行试用，使用了开源工具Sentry。

Sentry正在使用运行时检测来突出显示异常，而不是在我的帐户上使用假定角色来设置日志转发。这消除了为第三方工具提供对开发人员AWS账户访问权限的担忧。

开发人员拥有所有函数场景，包括request_id和执行时间。可以使用aws_request_id之类的参数来了解该错误的下游影响。

深度链接到CloudWatch日志可节省搜索正确的日志流和时间窗口的时间。

缺点是使用这种方法无法获得内存使用或函数调用时间，但是无论如何都无法移动这些数字。

运行时仪器的另一个未来好处是，它使开发人员可以监视分布式跟踪，以便确定哪些特定部分正在减慢其函数执行速度。因此，能够确保更好的用户体验并节省AWS成本。

无服务器承诺为开发团队带来更少的管理负担，但是故障排除的局限性会抵消所节省的时间。重要的是要考虑提供功能场景而不增加风险和成本的监视工具。CloudWatch和Sentry之间的比较突出了这些因素及其重要性。