终端用户体验的监控正在兴起，变化很快。这是业务中最能进行分析、量化的部分，每周都涌现出新的技术。这里有一些需要考虑的问题。

从系统组件转向用户

现代网站运行的堆栈很深，难于排查错误。现在已经不难见到这样的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代理服务。