终端用户模拟监控，也就是国内俗称的「云拨测」，其低廉的价格以及便捷的部署方法加快了模拟监测的普及速度，但同时也导致了一些误用：很多公司以及用户将模拟监控当做用户的真实访问情况，监控出来的数据很棒，但是用户的投诉却一直不断。

一.前言

最近几年，IT 界人力成本越来越高，并且大数据的到来从某种程度上讲也意味着互联网前期靠人力来进行性能优化的时代已经过去了，于是各种 APM 工具应运而生。

从实际角度讲，只有少数 APM 厂家才具备开发基于真实用户体验的性能监控工具的能力，所以模拟监控一直以来都是 APM 的主流。并且很多情况下，APM 供应商常常会单独出售模拟监控测试工具，并将其完全等同于性能监控，这导致监控方案的买主们常常误解这些技术案例，以为他们就是自己想要的真实用户体验监控。

从根本上说，这是由于用户对「可用性」与「真实用户体验性能监控」的理解有误造成的。

大多数模拟监控更偏重于网站应用的可用性、响应时间等，其当然有自己的重要之处，但是如果要有针对性的进行性能监控优化的话，基于真实用户体验的性能监控是必不可少的。

二.性能监控工具的推广难在哪里？

1.性能监控领域的主要问题

• 模拟监控与测试简单易懂，部署起来很方便，容易实现，不涉及代码权限的问题，但只从这一个渠道获得数据，并用于评定应用性能显然不是正确的视角。

• 虽然真实用户体验监控工具正在优化其部署方法，但，最基本的运维权限甚至修改页面代码的限制，确实制约了其普及的力度。

• 许多公司缺少真实用户监控意识，不了解什么是「真实用户体验」，常常错误地将模拟监控完全等同于应用性能监控管理（APM）。

2.相关建议

• 实施真实用户监控技术，安装包含多种 APM 维度的探针（具体的介绍在文章后面有），如果探针无法安装或风险太大，则部署网络监控。

• 不要为了评定应用性能而部署过多模拟监控，模拟监控主要是从可用性的角度来监测的，好的优化团队应该从真实用户数据中找到可优化点，从而打破检测与监控的循环。

• 控制模拟监控的人员与资金投入，而将资源投入到更有价值的活动中，如真实用户体验监控。

• 将模拟监控用于 SLAs （服务水平协议）基准测试，以及适合的性能监控案例，诸如第三方应用组件、API接口、Ping值的性能测试。

3.战略规划设想

之前在 Gartner 看到过相关数据，未来互联网对应用性能的需求一定会逐渐超过对应用可用性的需求，并且在 2015 年，模拟监控占性能监控使用量的百分比减少 30% ，并且将来会进一步下降。

三.针对现状的分析

1. 了解并使用相关真实用户体验监控技术和工具

任何真实用户体验监控技术和工具的重点通常都是针对终端用户的基础架构或组件的监控。智能化的工具是测量真实用户体验的理想工具，因为它们理解应用的运行情况，会自动基准化性能表现，在几乎不产生干扰的情况下解码并建立应用子组件间的关系。 现阶段，国内外在测量终端用户体验时，主要三种不同的性能监控方法：

1).以网络为基础的探测技术——从数据中心的边缘或环境中的多点调查网络流量，从而确定终端用户响应时间，以及其他应用基础组件的详细信息（比如：数据库，中间件和文档服务器等），这些工具不仅能处理以 Web 为基础的应用，也监测网络中其他应用。

此类服务供应商包括：OneAPM Applicaton Insight、Mobile Insight, AppNeta, Appnomic,BMC Software, Boundary,Compuware, Network Instruments, Net Optics, Niksun, Opnet Technologies, Oracle, Paessler, Riverbed, VMware, WildPackets 等。

2).以浏览器为基础的脚本注入——帮助用户了解运行浏览器的主要终端，包括PC、微信、移动端浏览器、Android webview 等，能满足这点很不容易。一般情况下，这种工具的部署比较简单，主要采用往页面插入 js 代码的方法，但是需要机械性的操作还要有修改代码的权限才行。

未来的移动应用将会包含复合型应用，它们结合了本地应用程序功能与浏览器相关的组件。这种令人期待的应用将支持 JavaScript 的运行，还可以扩平台，而且部署更加简单。现有的某些 APM 工具能检测 DNS 响应时间，数据从终端用户传到服务端的传输时间、CDN 资源监控等，当这些工具与网络或基于服务器的监控结合使用时，就可以瀑布式地细分页面内的各个资源加载耗时等。

此类服务供应商包括：AppDynamics，OneAPM Browser Insight，Arcturus， BMC Software， Cedexis， Compuware， Lucierna， Microsoft， New Relic， Opnet Technologies， Precise， Tracelytics 等。

3).终端部署——用户在终端设备安装探针或部署代码，从而获取终端用户体验，以及应用运行环境的详细信息。这对于控制桌面的企业并不难实现，而对于移动设备监控，则越发重要。移动设备监控允许管理员在设备上（平板、手机）植入探针，或将代码嵌入本地的移动应用，对于不接受消耗巨大的应用的企业，配置也可以部署在应用内部。

此类服务供应商包括：OneAPM ，Aternity, Correlsense, Next Think 等。

由于获取真实用户监控数据的渠道很多，导致数据实现（data implementations）也变得很复杂起来，可以尝试使用探针在服务端植入脚本这类手动 JavaScript 注入方式、在端点设备配置探针或探测网络中可以了解数据包的位置等方法。然而，这类技术的部署不像模拟业务只需弄个 URL 那么简单，因此配置方法的便捷化仍是现期的主要目标。

2.模拟监控技术的不足

现有的模拟监控往往需要脚本或建立在一定时间间隔内执行的多步骤事务。这些脚本与事务在软件改变时也需要维护，从而带来持续的管理成本。

通常情况下，模拟监控取自高速网络连接中的高速服务器，这些交互并不是用户使用应用时真实的用户体验。基于真实用户与模拟测试的数据分析显示，两者之间存在两到三倍的标准差。这种差别是由模拟测试工具运行时的处理、连接以及环境与终端用户实际可得的连接、计算资源的差异造成的。因此，许多公司赖以进行应用性能监控的模拟测试真的只是个「模拟值」，因而带来错误的安全感。

模拟事务的测试数量有些过多，比如多次测试用户可能选择的事务轨迹，或者频繁测试以测量应用的响应情况。当测试过多的情况发生时，会产生较大负载，可能影响用户体验，尤其是当他们运行到应用中资源受限或瓶颈的部分。

大多数现代应用常常会配备缓存机制，如果没有明确指出，常常在软硬件层实施（比如：存储缓存，数据库缓存，应用服务器缓存甚至是 OS 缓存）。这导致一种误解——运行间隔较大的 trace 往往表现不错，而实际的情况可能并非如此。

因此，将来模拟检测的使用百分比的下降定是不言而喻。

模拟交易会导致其他操作上的问题。安全方面，模拟交易可能会涉及模拟凭证或登录，或使用真实用户的证书以测试系统。这会降低整个软件系统的安全度。通过使用真实的交易数据，可以规避这些问题，同时收集到更有意义的数据用于分析，并评定真实终端用户的体验。

四.模拟监测的主要价值——应用可用性

广泛地将模拟测试用于确保应用性能其实是误用，模拟测试主要是抓取重大的应用或组件故障。当模拟测试显示应用响应能力的偏差时，并不能指明真实用户受到的影响，甚至无法判定主要问题出在哪儿，因为用户交互上的不顺利或运行失利往往无法通过该技术检测出来。该技术唯一的正确用途是检查应用或服务的可用性，或系统问题的根本原因分析（root cause analysis，RCA）。尽管模拟测试可用于根本原因分析，APM 技术却能提供粒度更细致的根本原因分析。

模拟交易用于检测可用性与性能的一个理想化案例是测量应用的第三方组件（API 监控）。当代应用引入的组件往往包含社交媒体功能，例如：脸书的点赞按钮，Google+的“+1”按钮或推特的转发功能。这些组件在页面渲染时可能导致缓慢。而缓慢的原因很难使用真实用户监控技术准确定位。

不幸的是，使用真实用户数据测量并建立 SLAs 困难重重，真实用户数据往往受基础架构与运营团队无法控制的因素曲解。相比之下，模拟测试却能清楚反应不可用的应用或服务。

将模拟测试用于 SLA 测量的基准也是很好的使用案例。然而，不要只关注于模拟测量，了解真实用户体验仍是测量应用使用情况最重要的指标。

五.总结

从以上分析可得，真正看重应用性能的公司，应当把时间与金钱更专注于真实终端用户角度，而不是模拟监控能带来的可用性测量，并且模拟事务监控应该用于测量应用与第三方组件或服务的可用性。

模拟监控自然有其巨大价值的存在，并且接下去的一段时间，模拟监测的其他使用案例必定会不断涌现，比如，将模拟测试与其他数据源结合，能实现对应用性能更多维度的理解。这些解决方案的主要目标是使面向大量终端用户的应用程序能顺利交付，而且，应用交付与内容传递在全球范围内的监控对大多数公司而言都至关重要。

注：本文原作者为 Gartner 分析师 Jonah Kowall，由 OneAPM 产品运营编译整理

Browser Insight 是一个基于真实用户的 Web 前端性能监控平台，能够帮大家定位网站性能瓶颈，网站加速效果可视化；支持浏览器、微信、App浏览 HTML 和 HTML5页面。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客