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

從系統組件轉向用戶(hù)

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



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

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

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

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

云與監控

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

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

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

APls與RSS消息

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

向其他人提供API

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

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

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

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

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

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

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

消費別人的API

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

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