RUM的工作名副其实:它观察的是网站的真实访客,记录访客打开页面的速度,然后生成报表。
从这点来看,RUM会告诉你系统是否出问题了,因为你可以通过RUM发现问题以及速度变慢的情况,这些情况你没有进行测试,从而也就不知道是否存在。
何时使用RUM
RUM工具生成两种报表,每种都可以帮助你测量性能及诊断问题。
单个访客报表
有了这样的报表,就像每个访客都有Firebug一样,你可以对用户的访问进行回放,复查每个页面和每个对象,也可以针对单个错误生成报警(例如,“假如用户得到了一个HTP500错误,则给我发邮件”)。
集合报表
这些报表针对所有访客显示发生了什么一哪些页面最慢、哪些对象出现的错误最多等。可以基于聚合数据和时间段生成报警(例如,“如果5分分钟之内平均页面延迟时间间超过5秒钟,则发送一个SNMP陷阱”)。
常见的RUM用例包括
●复查问题会话,以诊断网站的技术问题。
●对网站真实访客生成服务水平报表,特别是在运行一个软件作为服务(Sas)的系统时。识别出那些可能需要更多规范监控的部分。
●对于无法使用综合方式进行测量的部分,如付款页面等,测测量其健康状况
遇到问题即时报警,而不是采用间隔方式,到点儿才报。
RUM的局限
虽然综合工具都大同小异,但客户端的RUM工具,和服务器端的相比,是有很大区别的。前者依赖于AAX脚本或者嵌入的代理代码(agentcode),在终端用户访问网站时,采集他们的信息;后者使用服务器日志、负载均衡器或者网络窃听器从数据中心收集访客信息。
客户端RUM在浏览器中观察用户体验,所以能够测量像客户端渲染等的延迟。可惜的是,由于只有在页面成功加载并且在浏览器上运行的时候,客户端RUM才能够加载,所以就无法检测导致其自身无法加载这样的错误,而且也可能与某些客户端不兼容。更进一步说,因为RUM是在浏览器的沙箱里运行的,所以也就无法看到更为低层的数据,像包丢失情况,也无法计算用户访问第一个页面时的主机延迟。
服务器端的RUM的问题正相反。因为独立于浏览器,所以能看到发生的任何事情的详细情况一一甚至是失败的TCP连接次数,然而却看不到浏览器中发生的情况。或许更重要的是,因为服务器端的RUM需要访问网络与日志,以及某些情况下的各个物理网络,所以对于托管或基于云计算的环境,就无法部署了。许多商业化的RUM解决方案结合了客户端及服务器端的采集方式来解决这个问题。
配置RUM
有两个基本步骤来配置RUM工具。首先,训练工具以理解网站的流量模式,然后告诉工具监视哪些重要的内容。
按照定义,一个RUM工具应该能捕提所有进出服务器的流量。对工具进行训练是必要的,因为每个网站都是不同的。对工具进行训练涉及到下面的步骤。
1.剔除不需要的流量。
某些流量你可能不需要。像网站机器人(bots)、其他的监控工具、网络服务调用以及防火墙之内的流量,所有这些都会让你曲解终端用户的体验。
2.告诉系统如何追踪单个用户。
所有网站都会使用某种东西来识别单个访客,不管是会话cookie还是URL参数,甚至是IP地址。但在某些RUM实现中一一特别是那些使用客户端脚本的一这些是不需要的,因为脚本实例运行在每个访客的浏览器中。
3.告诉系统如何组装页面。
知道一个页面在哪里结束以及另一个页面在哪里开始,是需要技巧的。有些页面在加载以后可能还会有异步通信(如GoogleSuggest,用户在搜索框中输入内容时,GoogleSuggest会基于这些内容显示建议)。RUM工具需要知道什么东西组成了页面的开始与结束,这对于合理地计时以及计算页面数都很重要
4.识别错误。
虽然每个网站都有一些基本的错误类型(如HTTP500),但也会有一些定制的页面,看起来跟正常页面一样,但却是出错页面。
一旦工具理解了怎样才算是一次访问,以及如何测量延迟,你就可以告诉它要监视些什么。多数RUM工具在开始时都会有默认的参数:页面、用户、城市以及服务器都是用来切割数据的好方法,都会向你显示哪些最慢,或者哪些出错最多。
由于RUM工具要处理大量信息,所以往往只向你显示高层次的数据,除非你特别要求做钻取,例如,进入到网站建设的刚刚发布的那部分,或者显示一个特定的高价值客户。一般来说,每个数据区段都可以用来生成报告,以及产生报警或邮件通知。
>>> 查看《如何进行网站的真实用户监控(RUM)?》更多相关资讯 <<<
本文地址:http://tcgq.cn/news/html/3345.html