從系統組件轉向用戶
現代網站運行的堆棧很深，難于排查錯誤。現在已經不難見到這樣的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代理服務。
本文地址：http://m.123beaconmarketing.com//article/3355.html
