终端用户体验的监控正在鼓起，变更很快。这是营业中最能进行剖析、量化的部门，每周都出现出新的技巧。这里有一些须要斟酌的问题。

从体系组件转向用户

现代网站运行的客栈很深，难于排查毛病。如今已经不难见到如许的Web运用:基于散布在多个所在的虚拟机，在当地或全球做负载平衡，运行在一层又一层的抽象之上。斟酌如许的云:一个VM，运行J在其上实现Rails，输出HTML和CSS。在如许的客栈上设备测量对象是很艰苦的，而设置有意义的國值的确是弗成能的。

作为应对这种庞杂性的办法，很多Web运维开端转而存眷终端用户体验，而不再是平台的健康。这种“自顶向下”的方法依附于外部监控捕获毛病、抽取诊断信息，赞助你从毛病中定位问题。甚至可以树立如许“点击这里将毛病发送给我们”的一个道歉页面，将新闻发送给运维团队，包含恰当混杂过(obfuscated)的诊断数据，譬如，是哪台办事器创立的页面，来自哪个数据中间。

以办事为中间的架构

跟着构建在Flash、Silverlight、Java以及AJAX之上的富互联网运用(RIAs)的风行，越来越多的客户与办事器之间的通讯都经由过程收集办事来实现。IT行业在逐渐地转向面向办事系统构造(SOA)模式，一方面是操作者可以将办事从基本架构平分离出来，另一方面也是因为这种方法勉励可移植性。少数年夜型型办事器的时期已经由去了，已经被商品化的硬件所代替，这些硬件运行的是无共享数据的架构。

这意味着你所负责的网站将依附于年夜量的第三方办事，如许的话，办事器延迟就重要是由你所依附的那些办事供给商所发生的后台延迟。这意味着你要去监控那些不是你所运行的器械一一甚至你都无法掌握，这会害逝世你的。

云与监控

对许多创业公司而言，云盘算弹性的、按需供给的盘算资本，以效用模式付费下降了进入门槛，因为不须要预先投资。这也让一些年夜型企业可以做更多的实验，并且一些年夜型的盘算型运用，如基因组学研讨、蒙特卡洛模仿以及数据发掘，可以或许开放给每一小我。

不要管这些炫耀吧，不管怎么说，云盘算还仍然年青。而这就意味着云盘算存在“车顶行李架”的问题。买车的时刻，哪些组件应当包括(里程计)，哪些组件要到市场上买(车顶行李架)，是很清晰的。云记盘算行业在这些方面还没有明白的尺度，成果就是，一些曾经由第三方厂家供给的监控对象，如今也句括在云里了

工作还有更庞杂的，平台作为办事的云(如Google的Appengine)包含了如许的测量对象，可以显示用户的账单，而基本架构作为办事的云(如Amazon收集办事)则将许多设备测量对象的工作留给了用户。

APls与RSS新闻

越来越多的网站运维人员将他们的内容供给给终端用户和开辟者。我们正处在从创立运用法式供用户拜访向为用户供给宣布办事的改变进程中，作为这种改变的成果，我们就须要对跨越APIS与传统机制(如RSS与Atom新闻)之间的流量进行监控。

向其他人供给API

要向他人供给API或RSS新闻(fed)，你须要对其进行监控，并包管其机能。你供给的信息越及时，则一旦变慢或宕失落了，花费该AP或RS8新闻的人叫得就越响。成果，你就要设置适合的SLAs，而当宕机时，要供给实时的信息。留意，宕机时光也能影响其他人对你能有多年夜流量的意见:像Compete.com、Quantcast.com及Comscore如许的办事，在不克不及拜访你的APls和RSS新闻时，也会低报网站的应用模式。

作为办事供给商，你要和市场营销部分合作，赞助他们懂得根本的API应用模式。总的来说就是，你要商量下面这些问题:

● 用户衔接上你的API须要若干时光。

● 这个时光对用户的行动是否有影响。

● 用户在你的运用法式或网站上花的时光，多照样少

● 这是否让用户在你的目的漏斗中深刻下去

● 用户如今是拜访你的API或者RSS新闻，而不是设备了Javascript的页面，若何持续对用户进行追踪。

花费别人的API

假如是花费来自办事供给商的API或RSS新闻，你须要对其进行测量，以便产生问题时辨认出问题出在哪里。每条RSS新闻都跟你本身的办事器一样主要，假如这些新闻起源中止了，你可否能优雅地处置呢?外部数据发生的延迟是若干?你须要依附办事供给商供给准确的信息，也须要对这些供给商的服各讲行种立吹(hn估F4△福问题时可以或许准确定位是的义务。

多半综合监控对象都可以或许对APIs及RSS新闻进行监控，监控网站扶植邮件及短佩服务(SMS)这些外部体系的对象可能要贵一些。因为简略测试很难察觉数据的纷歧致，而数据的纷歧致经常对高流量的API体系造成困扰，所以须要构建本身的监控体系，或依附于能做此事的第三方API署理办事。