從系統(tǒng)組件轉(zhuǎn)向用戶
現(xiàn)代網(wǎng)站運行的堆棧很深，難于排查錯誤?，F(xiàn)在已經(jīng)不難見到這樣的Web應(yīng)用:基于分布在多個地點的虛擬機，在本地或全球做負(fù)載均衡，運行在一層又一層的抽象之上?？紤]這樣的云:一個VM，運行J在其上實現(xiàn)Rails，輸出HTML和CSS。在這樣的堆棧上裝備測量工具是很困難的，而設(shè)置有意義的國值簡直是不可能的。
作為應(yīng)對這種復(fù)雜性的方法，許多Web運維開始轉(zhuǎn)而關(guān)注終端用戶體驗，而不再是平臺的健康。這種“自頂向下”的方式依賴于外部監(jiān)控捕捉錯誤、抽取診斷信息，幫助你從錯誤中定位問題。甚至可以建立這樣“點擊這里將錯誤發(fā)送給我們”的一個致歉頁面，將消息發(fā)送給運維團隊，包括適當(dāng)混淆過( obfuscated)的診斷數(shù)據(jù)，譬如，是哪臺服務(wù)器創(chuàng)建的頁面，來自哪個數(shù)據(jù)中心。
以服務(wù)為中心的架構(gòu)
隨著構(gòu)建在Flash、 Silverlight、Java以及AJAX之上的富互聯(lián)網(wǎng)應(yīng)用(RIAs)的流行，越來越多的客戶與服務(wù)器之間的通信都通過網(wǎng)絡(luò)服務(wù)來實現(xiàn)。IT行業(yè)在逐漸地轉(zhuǎn)向面向服務(wù)體系結(jié)構(gòu)(SOA)模式，一方面是操作者可以將服務(wù)從基礎(chǔ)架構(gòu)中分離出來，另一方面也是由于這種方式鼓勵可移植性。少數(shù)大型型服務(wù)器的時代已經(jīng)過去了，已經(jīng)被商品化的硬件所取代，這些硬件運行的是無共享數(shù)據(jù)的架構(gòu)。
這意味著你所負(fù)責(zé)的網(wǎng)站將依賴于大量的第三方服務(wù)，這樣的話，服務(wù)器延遲就主要是由你所依賴的那些服務(wù)提供商所產(chǎn)生的后臺延遲。這意味著你要去監(jiān)控那些不是你所運行的東西一一甚至你都無法控制，這會害死你的。
云與監(jiān)控
對很多創(chuàng)業(yè)公司而言，云計算彈性的、按需提供的計算資源，以效用模式付費降低了進(jìn)入門檻，因為不需要預(yù)先投資。這也讓一些大型企業(yè)可以做更多的試驗，而且一些大型的計算型應(yīng)用，如基因組學(xué)研究、蒙特卡洛模擬以及數(shù)據(jù)挖掘，能夠開放給每一個人。
不要管這些夸耀吧，不管怎么說，云計算還仍然年輕。而這就意味著云計算存在“車頂行李架”的問題。買車的時候，哪些組件應(yīng)該包含(里程計)，哪些組件要到市場上買(車頂行李架)，是很清楚的。云記計算行業(yè)在這些方面還沒有明確的標(biāo)準(zhǔn)，結(jié)果就是，一些曾經(jīng)由第三方廠家提供的監(jiān)控工具，現(xiàn)在也句括在云里了
事情還有更復(fù)雜的，平臺作為服務(wù)的云(如 Google的 Appengine)包括了這樣的測量工具，可以顯示用戶的賬單，而基礎(chǔ)架構(gòu)作為服務(wù)的云(如 Amazon網(wǎng)絡(luò)服務(wù))則將很多裝備測量工具的工作留給了用戶。
APls與RSS消息
越來越多的網(wǎng)站運維人員將他們的內(nèi)容提供給終端用戶和開發(fā)者。我們正處在從創(chuàng)建應(yīng)用程序供用戶訪問向為用戶提供發(fā)布服務(wù)的轉(zhuǎn)變過程中，作為這種轉(zhuǎn)變的結(jié)果，我們就需要對跨越 APIS與傳統(tǒng)機制(如RSS與Atom消息)之間的流量進(jìn)行監(jiān)控。
向其他人提供API
要向他人提供API或RSS消息(fed)，你需要對其進(jìn)行監(jiān)控，并保證其性能。你提供的信息越實時，則一旦變慢或宕掉了，消費該AP或RS8消息的人叫得就越響。結(jié)果，你就要設(shè)置合適的SLAs，而當(dāng)宕機時，要提供及時的信息。注意，宕機時間也能影響其他人對你能有多大流量的看法:像Compete.com、Quantcast.com及Comscore這樣的服務(wù)，在不能訪問你的APls和RSS消息時，也會低報網(wǎng)站的使用模式。
作為服務(wù)提供商，你要和市場營銷部門合作，幫助他們理解基本的API使用模式?？偟膩碚f就是，你要探討下面這些問題:
● 用戶連接上你的API需要多少時間。
● 這個時間對用戶的行為是否有影響。
● 用戶在你的應(yīng)用程序或網(wǎng)站上花的時間，多還是少
● 這是否讓用戶在你的目標(biāo)漏斗中深入下去
● 用戶現(xiàn)在是訪問你的API或者RSS消息，而不是裝備了Javascript的頁面，如何繼續(xù)對用戶進(jìn)行追蹤。
消費別人的API
如果是消費來自服務(wù)提供商的API或RSS消息，你需要對其進(jìn)行測量，以便發(fā)生問題時識別出問題出在哪里。每條RSS消息都跟你自己的服務(wù)器一樣重要，假如這些消息來源中斷了，你能否能優(yōu)雅地處理呢?外部數(shù)據(jù)產(chǎn)生的延遲是多少?你需要依賴服務(wù)提供商提供精確的信息，也需要對這些提供商的服各講行種立吹(hn估F4△福問題時能夠精確定位是的責(zé)任。
多數(shù)綜合監(jiān)控工具都能夠?qū)PIs及RSS消息進(jìn)行監(jiān)控，監(jiān)控網(wǎng)站建設(shè)郵件及短信服務(wù)(SMS)這些外部系統(tǒng)的工具可能要貴一些。因為簡單測試很難察覺數(shù)據(jù)的不一致，而數(shù)據(jù)的不一致常常對高流量的API系統(tǒng)造成困擾，所以需要構(gòu)建自己的監(jiān)控系統(tǒng)，或依賴于能做此事的第三方API代理服務(wù)。
本文地址：http://jiujiu9.com//article/3355.html
