Web监控的将来

终端用户体验的监控正在鼓起，变革很快。这是营业中最能进行阐明、量化的部分，每周都涌现出新的手艺。这里有一些需求思索的问题。
从零碎组件转向用户
现代网站运转的仓库很深，难于排查毛病。此刻已经不难见到如许的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代理服务。