【编者按】本文作者 Dan Kuebrich 是 AppNeta 公司应用性能产品主管，在本文中，作者通过分析两种终端用户监控方式的利弊，结合具体情况为监控的选择提出建议，本文系 OneAPM 工程师编译整理。
终端用户的性能大多是企业判断 Web 应用程序的标准，也就是说应用程序的响应是否能满足企业的标准。研究表明，在用户需求不断增长的同时，页面平均访问量也与日俱增——相对于 2010 来说已经增长了一倍。结合市场的频繁发布和更新，当下优化的步伐永远都无法及时跟上。
因此从终端用户的角度出发，对应用性能进行持续监控已成为关键。随着更多监控方法的涌现，用户又应该如何挑选最好的方法呢？
真实用户监控
尽管 Web 应用服务器端的性能可以通过数据中心的 HTTP 请求进行观察测量，但整页加载时的 CDN 静态内容下载、页面渲染、执行 JavaScript 等数据却无法很好的监测。现实世界中，真实用户监控通常利用 JavaScript 脚本嵌入到 web 页面，在浏览器上收集终端用户在浏览过程中的性能数据。
这种监控有助于提升对应用性能的业务理解。收集的数据显示了页面加载的全部时间，基于世界各地的不同浏览器。这种监控适用于桌面、移动端和平板电脑的浏览器。
衡量实际数据的最大优势是不需要对重要用例的预定义。在每个用户体验应用时，真实用户监控捕捉所有数据，所以无论用户看到什么页面，都能为监控提供有效的性能数据。对于功能和内容不断变化的大型网站或者复杂应用，这些数据非常重要。
随着浏览器 API 的研究深入，如 Navigation Timing API，真实用户监控数据的细节也远胜以往。它可以将浏览器返回时间细致地划分为构建 DOM 的时间和到渲染内容完成之前的时间。这是一个很好的开端，尤其是能对全面捕捉的用户数据进行很好的分类。如果一个页面加载缓慢，那是什么原因导致的呢？但尽管真实用户监控提供这个切入点，也并不一定能精确定位。此外，「单页面应用程序」，也就是那些不会执行完全页面加载的应用也会对收集有效的真实用户监控数据造成阻碍，如 GMail 和 Facebook。
整体水准的提高也可能改善当前的状况，如 Resource Timing API，而现在真实用户监控也非常适用于识别应用程序中是否存在问题。它甚至还提供了一些高级分类——是网络问题、应用服务器问题或终端环境问题？但是在这个基础上，真实用户监控还无法区分流量下降还是网络未连接。其次，真实用户监控中的延迟还可能表示后端性能退化，或者只是相对缓慢的报告生成功能造成使用过程中的暂时增长。而真实用户监控针对此问题所提供的信息还远远不够。
模拟性能监控
模拟性能监控，有时也被称为主动监控，通过外部代理在 Web 应用上运行脚本事务。这些脚本模拟典型的用户行为，比如搜索、查看产品、登录、注销等步骤来评估用户的真实体验。通常情况下，综合监控可以由轻量的低级别代理实现，但随着 Web 应用的复杂化，越来越有必要将这些代理在完整的 Web 浏览器上运行，才能处理页面加载过程中的 JavaScrip、CSS 和 AJAX 调用。
与真实用户监控不同，模拟监控不跟踪真实的用户会话，有其重要的意义。首先，因为脚本在已知位置按规律进行一系列步骤，所以它的性能是可预测的。这意味着它比冗杂的真实用户监控数据更有助于检测警报。其次，由于它预见性地在应用外部执行，所以在评估网站的可用性和网络问题方面，模拟监控比真实用户监控更为突出，尤其是集成网络监控之后。
实际上很多公司都会在生产之前采用模拟监控，与 Selenium 集成测试的形式。模拟事务在生产中可以重用相同的脚本（只要不改变数据）。随着应用程序越来越复杂，代理指标如负载或服务器可用性在服务器正常运行时变得不那么有用。在生产环境中运行 Selenium 脚本不再是代理指标；它精确地测量正常运行时间，如果模拟事务完成将是一个很好的参考。
最后，由于模拟监控可以完全控制客户端（不像 sandboxed JS 驱动的真实用户监控），可以收集足够的细节——完整的图表、资源调配的性能，甚至是页面加载的截屏/视频等。就目前来说，这种细节检测是了解单页应用状态转换性的最好途径。
谁更好？
再三思索一下的模拟监控和真实用户监控之间的区别，权衡其中的利弊。似乎是各有所长，那到底哪种方式更好？
或许，两者之间并非竞争，更像是互补关系。模拟监控提供详情、可靠性和可用性，而真实用户监控会提供真实的用户体验。基于这个原因，这里显然需要将模拟监控和真实用户监控相结合才能实现更好的应用监测。
模拟 + 真实 = 绝配
使用真实用户监控 + 模拟监控，用户可以描绘出一段时间内的真正用户流量，了解不同区域、浏览器和不同综合脚本下的性能差异。
在这里，机构既可以将模拟监控立足于真实用户数据，也在全新的跨区域的真实环境中观测综合性能，从而在 Web 应用的全方位监测上更进一步。
