亚马逊AWS官方博客
新增功能 – Amazon CloudWatch 的真实用户监控
早在 2009 年，我写过一篇题为“Amazon EC2 的新功能：Elastic Load Balancing、Auto Scaling 和 Amazon CloudWatch”的博客文章。在那篇文章中，我谈到了 Amazon CloudWatch 如何帮助您构建具有高度可扩展性和高度可用性的应用程序，并指出，它使您可以经济高效地实时查看指标，而无需进行部署和维护。自那次发布以来，我们为 CloudWatch 增加了许多新功能，所有这些功能都出于同样的目标。例如，去年我向您展示了如何使用 CloudWatch Synthetics 监控站点、API 端点、Web 工作流等。
真实用户监控 (RUM)
下一个重大挑战（也是我们今天要解决的挑战）是监控 Web 应用程序，其目标是了解性能并为用户提供最佳体验。由于涉及的变量很多——浏览器类型、浏览器配置、用户位置、连接性等——综合测试只能到此为止。对您的用户而言，真正重要的是他们获得的体验，这就是我们希望帮助您提供的体验！
Amazon CloudWatch RUM 将帮助您收集指标，为您提供洞察力，帮助您识别、了解和改进这种体验。您只需注册您的应用程序，在每个页面的标题中添加一个 JavaScript 代码段，然后进行部署。该代码段在用户逐步浏览应用程序的每个页面时运行，然后将数据发送到 RUM 进行整合和分析。您可以单独使用此工具，也可以与 Amazon CloudWatch ServiceLens 和 AWS X-Ray 一起使用。
CloudWatch RUM 的实际操作
首先，我打开 CloudWatch 控制台并导航至 RUM。然后，我单击 Add app monitor（添加应用程序监视器）：
我为监视器指定一个名称，然后指定托管我的应用程序的域：
然后我选择要监视和收集的事件，并指定会话的百分比。我的个人博客流量不大，所以我会收集所有的会话。我也可以选择将数据存储在 Amazon CloudWatch Logs 中，以便在 CloudWatch RUM 提供的 30 天以上的时间内保存数据：
最后，我选择创建一个新的 Cognito 身份池，然后添加一个标签。如果我想使用 CloudWatch ServiceLens 和 X-Ray，我可以扩展主动跟踪并启用 XRay。我的应用程序没有发出任何 API 请求，所以我不会这样做。我通过单击 Add app monitor（添加应用程序监视器）完成：
然后，控制台向我展示了我需要插入到应用程序的 <head> 元素中的 JavaScript 代码段。
我保存代码段，单击 Done（完成），然后编辑我的应用程序（此情况下为有关被忽略的我的个人博客）以添加代码段。我使用 Jekyll，并且已将代码段添加到我的博客模板中：
然后，我等待流量到达。当我返回 RUM 控制台时，我可以看到我所有的应用程序监视器。我单击 MonitorMyBlog 以了解详情：
然后，我可以探索聚合时间数据和已收集的其他信息。今天要展示的内容远不止这些，所以请随时自己尝试一下并进行更深入的探究。每个选项卡都包含多个筛选条件和选项，可帮助您放大感兴趣区域：特定页面、位置、浏览器、用户旅程等等。
Performance（性能）选项卡显示了我的应用程序的生命体征，然后是其他信息：
生命体征分为三个级别（积极、可容忍和破坏性）：
上面的屏幕包含一个我不熟悉的指标（最大内容绘制）。正如 Philip Walton 所说，“最大内容绘制 (LCP) 是衡量感知加载速度的一个重要的以用户为中心的指标，因为它在页面加载时间轴上标记页面主要内容可能已加载的时间点。”
我还可以看到浏览器在加载页面时所采取的步骤所花费的时间：
我可以看到一天中不同时间的平均加载时间：
我还可以逐页查看所有这些信息：
Browsers & Devices（浏览器和设备）选项卡还显示了许多有趣且有用的数据。例如，我可以通过逐页选项再次了解用于访问我的博客的浏览器的更多信息：
我还可以通过我的博客查看用户旅程（页面序列）。基于这些信息，我似乎需要更好地将用户从一个页面引导到另一个页面：
正如我之前提到的，这里有很多有趣且有用的信息，您应该自己进行查看。
现已推出
CloudWatch RUM 现已推出，您可以在 10 个 AWS 区域立即开始使用该服务：美国东部（弗吉尼亚北部）、美国东部（俄亥俄）、美国西部（俄勒冈）、欧洲（爱尔兰）、欧洲（伦敦）、欧洲（法兰克福）、欧洲（斯德哥尔摩）、亚太地区（悉尼）、亚太地区（东京）和亚太地区（新加坡）。每收集 10 万个事件，您需要支付 1 美元。
— Jeff；