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

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

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



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

以服務為中心的架構

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

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

云與監(jiān)控

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

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

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

APls與RSS消息

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

向其他人提供API

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

作為服務提供商，你要和市場營銷部門合作，幫助他們理解基本的API使用模式。總的來說就是，你要探討下面這些問題:

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

● 這個時間對用戶的行為是否有影響。

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

● 這是否讓用戶在你的目標漏斗中深入下去

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

消費別人的API

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

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