終端用戶體驗(yàn)的監(jiān)控正在興起，變化很快。這是業(yè)務(wù)中最能進(jìn)行分析、量化的部分，每周都涌現(xiàn)出新的技術(shù)。這里有一些需要考慮的問(wèn)題。

從系統(tǒng)組件轉(zhuǎn)向用戶

現(xiàn)代網(wǎng)站運(yùn)行的堆棧很深，難于排查錯(cuò)誤?，F(xiàn)在已經(jīng)不難見(jiàn)到這樣的Web應(yīng)用:基于分布在多個(gè)地點(diǎn)的虛擬機(jī)，在本地或全球做負(fù)載均衡，運(yùn)行在一層又一層的抽象之上?？紤]這樣的云:一個(gè)VM，運(yùn)行J在其上實(shí)現(xiàn)Rails，輸出HTML和CSS。在這樣的堆棧上裝備測(cè)量工具是很困難的，而設(shè)置有意義的國(guó)值簡(jiǎn)直是不可能的。



作為應(yīng)對(duì)這種復(fù)雜性的方法，許多Web運(yùn)維開(kāi)始轉(zhuǎn)而關(guān)注終端用戶體驗(yàn)，而不再是平臺(tái)的健康。這種“自頂向下”的方式依賴于外部監(jiān)控捕捉錯(cuò)誤、抽取診斷信息，幫助你從錯(cuò)誤中定位問(wèn)題。甚至可以建立這樣“點(diǎn)擊這里將錯(cuò)誤發(fā)送給我們”的一個(gè)致歉頁(yè)面，將消息發(fā)送給運(yùn)維團(tuán)隊(duì)，包括適當(dāng)混淆過(guò)( obfuscated)的診斷數(shù)據(jù)，譬如，是哪臺(tái)服務(wù)器創(chuàng)建的頁(yè)面，來(lái)自哪個(gè)數(shù)據(jù)中心。

以服務(wù)為中心的架構(gòu)

隨著構(gòu)建在Flash、 Silverlight、Java以及AJAX之上的富互聯(lián)網(wǎng)應(yīng)用(RIAs)的流行，越來(lái)越多的客戶與服務(wù)器之間的通信都通過(guò)網(wǎng)絡(luò)服務(wù)來(lái)實(shí)現(xiàn)。IT行業(yè)在逐漸地轉(zhuǎn)向面向服務(wù)體系結(jié)構(gòu)(SOA)模式，一方面是操作者可以將服務(wù)從基礎(chǔ)架構(gòu)中分離出來(lái)，另一方面也是由于這種方式鼓勵(lì)可移植性。少數(shù)大型型服務(wù)器的時(shí)代已經(jīng)過(guò)去了，已經(jīng)被商品化的硬件所取代，這些硬件運(yùn)行的是無(wú)共享數(shù)據(jù)的架構(gòu)。

這意味著你所負(fù)責(zé)的網(wǎng)站將依賴于大量的第三方服務(wù)，這樣的話，服務(wù)器延遲就主要是由你所依賴的那些服務(wù)提供商所產(chǎn)生的后臺(tái)延遲。這意味著你要去監(jiān)控那些不是你所運(yùn)行的東西一一甚至你都無(wú)法控制，這會(huì)害死你的。

云與監(jiān)控

對(duì)很多創(chuàng)業(yè)公司而言，云計(jì)算彈性的、按需提供的計(jì)算資源，以效用模式付費(fèi)降低了進(jìn)入門檻，因?yàn)椴恍枰A(yù)先投資。這也讓一些大型企業(yè)可以做更多的試驗(yàn)，而且一些大型的計(jì)算型應(yīng)用，如基因組學(xué)研究、蒙特卡洛模擬以及數(shù)據(jù)挖掘，能夠開(kāi)放給每一個(gè)人。

不要管這些夸耀吧，不管怎么說(shuō)，云計(jì)算還仍然年輕。而這就意味著云計(jì)算存在“車頂行李架”的問(wèn)題。買車的時(shí)候，哪些組件應(yīng)該包含(里程計(jì))，哪些組件要到市場(chǎng)上買(車頂行李架)，是很清楚的。云記計(jì)算行業(yè)在這些方面還沒(méi)有明確的標(biāo)準(zhǔn)，結(jié)果就是，一些曾經(jīng)由第三方廠家提供的監(jiān)控工具，現(xiàn)在也句括在云里了

事情還有更復(fù)雜的，平臺(tái)作為服務(wù)的云(如 Google的 Appengine)包括了這樣的測(cè)量工具，可以顯示用戶的賬單，而基礎(chǔ)架構(gòu)作為服務(wù)的云(如 Amazon網(wǎng)絡(luò)服務(wù))則將很多裝備測(cè)量工具的工作留給了用戶。

APls與RSS消息

越來(lái)越多的網(wǎng)站運(yùn)維人員將他們的內(nèi)容提供給終端用戶和開(kāi)發(fā)者。我們正處在從創(chuàng)建應(yīng)用程序供用戶訪問(wèn)向?yàn)橛脩籼峁┌l(fā)布服務(wù)的轉(zhuǎn)變過(guò)程中，作為這種轉(zhuǎn)變的結(jié)果，我們就需要對(duì)跨越 APIS與傳統(tǒng)機(jī)制(如RSS與Atom消息)之間的流量進(jìn)行監(jiān)控。

向其他人提供API

要向他人提供API或RSS消息(fed)，你需要對(duì)其進(jìn)行監(jiān)控，并保證其性能。你提供的信息越實(shí)時(shí)，則一旦變慢或宕掉了，消費(fèi)該AP或RS8消息的人叫得就越響。結(jié)果，你就要設(shè)置合適的SLAs，而當(dāng)宕機(jī)時(shí)，要提供及時(shí)的信息。注意，宕機(jī)時(shí)間也能影響其他人對(duì)你能有多大流量的看法:像Compete.com、Quantcast.com及Comscore這樣的服務(wù)，在不能訪問(wèn)你的APls和RSS消息時(shí)，也會(huì)低報(bào)網(wǎng)站的使用模式。

作為服務(wù)提供商，你要和市場(chǎng)營(yíng)銷部門合作，幫助他們理解基本的API使用模式?？偟膩?lái)說(shuō)就是，你要探討下面這些問(wèn)題:

● 用戶連接上你的API需要多少時(shí)間。

● 這個(gè)時(shí)間對(duì)用戶的行為是否有影響。

● 用戶在你的應(yīng)用程序或網(wǎng)站上花的時(shí)間，多還是少

● 這是否讓用戶在你的目標(biāo)漏斗中深入下去

● 用戶現(xiàn)在是訪問(wèn)你的API或者RSS消息，而不是裝備了Javascript的頁(yè)面，如何繼續(xù)對(duì)用戶進(jìn)行追蹤。

消費(fèi)別人的API

如果是消費(fèi)來(lái)自服務(wù)提供商的API或RSS消息，你需要對(duì)其進(jìn)行測(cè)量，以便發(fā)生問(wèn)題時(shí)識(shí)別出問(wèn)題出在哪里。每條RSS消息都跟你自己的服務(wù)器一樣重要，假如這些消息來(lái)源中斷了，你能否能優(yōu)雅地處理呢?外部數(shù)據(jù)產(chǎn)生的延遲是多少?你需要依賴服務(wù)提供商提供精確的信息，也需要對(duì)這些提供商的服各講行種立吹(hn估F4△福問(wèn)題時(shí)能夠精確定位是的責(zé)任。

多數(shù)綜合監(jiān)控工具都能夠?qū)PIs及RSS消息進(jìn)行監(jiān)控，監(jiān)控網(wǎng)站建設(shè)郵件及短信服務(wù)(SMS)這些外部系統(tǒng)的工具可能要貴一些。因?yàn)楹?jiǎn)單測(cè)試很難察覺(jué)數(shù)據(jù)的不一致，而數(shù)據(jù)的不一致常常對(duì)高流量的API系統(tǒng)造成困擾，所以需要構(gòu)建自己的監(jiān)控系統(tǒng)，或依賴于能做此事的第三方API代理服務(wù)。