通过 Amazon CloudWatch ServiceLens 可视化和监视高度分布式应用程序

越来越多分布式应用程序以及数千个指标和数万亿字节日志，对于可视化和监视来说可能是一项挑战。要获得对这些应用程序及其依赖关系的端到端洞察，以快速准确地确定性能瓶颈、操作问题和客户影响，往往需要使用多个专用工具，这些工具每个都显示特定的信息面。反过来，这会导致数据提取更加复杂，需要手动整合各种见解才能确定整体性能，并且维护多个解决方案会提高成本。

Amazon CloudWatch ServiceLens 于今天宣布推出，它是一种新的完全托管式可观察性解决方案，有助于在一个位置可视化和分析高度分布式应用程序的运行状况、性能和可用性，包括这些应用程序对基于无服务器和容器技术的依赖性。通过让您轻松隔离遇到问题的终端节点和资源，并分析相关指标、日志和应用程序跟踪数据，CloudWatch ServiceLens 可以使用一张服务地图将所有这些数据整合到一个位置，从而缩短解决问题的平均时间 (MTTR)。通过这张地图，您可以了解应用程序内的关系和依赖性，并通过单个工具深入了解各种日志、指标和跟踪数据，从而帮助您快速隔离故障。节省了通过各种工具关联指标、日志和跟踪数据的关键时间，从而缩短了最终用户的停机时间。

开始使用 Amazon CloudWatch ServiceLens
让我们来了解一下如何充分利用 Amazon CloudWatch ServiceLens 来诊断应用程序中触发警报的根本原因。我的示例应用程序使用 AWS Lambda 函数对 Amazon DynamoDB 表中的交易数据执行读取和写入操作。Amazon API Gateway 是我的应用程序前端，通过 GET 和 PUT 请求资源，将流量导向对应的 GET 和 PUT Lambda 函数。API Gateway 资源和 Lambda 函数已启用 AWS X-Ray 跟踪，并且从 Lambda 函数对 DynamoDB 的 API 调用已使用 AWS X-Ray SDK 封装。您可以阅读开发人员指南，以更详细地了解如何检测代码和使用 AWS X-Ray。

错误条件已在我的应用程序中触发了警报，因此，我的第一站是 Amazon CloudWatch 控制台，并单击其中的警报链接。我可以看到，我的一个或多个 API 网关资源存在可用性问题。

让我们深入了解可能发生的情况。首先，我想要获取运行应用程序的概述，因此，单击左侧导航窗格中 ServiceLens 下的服务地图。该地图将显示不同节点，代表我的应用程序中的分布式资源。节点的相对大小代表每个节点接收的请求流量，节点之间链接的厚度也是如此。我可以在显示请求模式或延迟模式之间切换地图。此外，我还可以使用同一下拉菜单切换选项，以更改节点的相对大小。请求模式或延迟模式下显示的数据可以帮助我隔离需要首先会审的节点。此外，还可以通过单击查看连接来协助完成此过程，因为它可以帮助我了解传入和传出呼叫及其对各个节点的影响。

我已经关闭了屏幕快照中的地图图例，以便我们更好地查看所有节点，以下供参考。

从地图上，我可以立即看到我的前端网关是触发警报的来源。节点上的红色指示器显示存在与资源关联的 5xx 故障，并且指示器相对于周长的长度可以让我了解到与成功请求相比故障请求的数量。第二，我可以看到通过 API 处理 PUT 请求的 Lambda 函数显示 4xx 错误。最后，我可以看到 DynamoDB 表上的紫色指示器，表示出现限制。此时此刻，我已经很好地了解了可能发生的情况，但是，让我们更深入地了解一下 CloudWatch ServiceLens 可以帮助我证明哪些内容。

除了地图视图之外，我还可以切换列表视图。这使我能够快速了解所有节点的平均延迟、故障和单位时间内的请求数信息，并且在默认情况下，该视图按照故障率降序（按警报中的警报数降序排列，按节点名称升序排列）进行特殊排序，将“最差”节点排在最前面。

返回到地图视图，将我的鼠标悬停在代表 API 前端的节点上后，我同样也可以了解节点特定的流量和故障请求百分比。

若要查看更多数据，单击任何节点将会在地图下面打开一个抽屉，其中包括该资源的图形数据。在下面的屏幕截图中，我单击了 ApiGatewayPutLambdaFunction 节点。

通过每个资源的抽屉，我可以跳至查看资源日志（查看日志）、跟踪（查看跟踪）或仪表板（查看仪表板）。下面，我已为相同 Lambda 函数单击了查看仪表板。滚动浏览为该资源提供的数据后，我注意到执行持续时间并不长，而所有调用却相继出现错误。

返回到显示警报的 API 前端后，我想看看请求跟踪数据，因此我单击节点以打开抽屉，然后单击查看跟踪。我已经从地图上知道，在通过传入我的应用程序的 PUT 请求选择的代码路径中生成了 5xx 和 4xx 状态代码，因此，我将筛选条件类型切换为状态代码，然后在列表中选择 502 和 504 条目，最后单击添加到筛选条件。跟踪视图将切换，向我显示这些错误节点中出现的跟踪数据、响应时间分布以及一组跟踪数据。

好的，现在我们越来越近了！ 单击第一个跟踪 ID，我获得了大量数据，包括与请求相关的异常消息，这比我在单个屏幕截图中显示的更多！ 例如，我可以看到作为请求一部分跟踪的每个分段的时间线。

进一步向下滚动浏览后，我可以查看异常详细信息（在这下面我还可以看到跟踪特定的日志消息），这里给我提供了答案，从而确认了我在原始地图中看到的限制指示器。此外， 我还可以在页面底部显示的特定于此跟踪的日志数据中看到此异常消息。以前，我必须浏览整个应用程序的日志才有望找到此消息，现在，可以通过地图深入了解，这大大节省了时间。

现在，我知道如何修复问题并解决警报，从而提高表格的写入预置！

与 CloudWatch ServiceLens 结合使用后，Amazon CloudWatch 也启用了 CloudWatch Synthetics 预览，帮助使用全天候运行的警报器监视终端节点，从而快速提醒我客户遇到的问题。这些同样也可以在服务地图中看到，就像我在上面所做的一样，我可以深入了解跟踪数据，以查看源自警报器的交易。越快地能够深入分析运行故障或警报的整合视图，就能越快地找到问题的根本原因，帮助缩短解决问题和减轻客户影响的时间。

Amazon CloudWatch ServiceLens 现已在所有商业 AWS 区域推出。

– Steve