從這點來看，RUM會告訴你系統是否出問題了，因為你可以通過RUM發現問題以及速度變慢的情況，這些情況你沒有進行測試，從而也就不知道是否存在。
何時使用RUM
RUM工具生成兩種報表，每種都可以幫助你測量性能及診斷問題。
單個訪客報表
有了這樣的報表，就像每個訪客都有 Firebug一樣，你可以對用戶的訪問進行回放，復查每個頁面和每個對象，也可以針對單個錯誤生成報警(例如，“假如用戶得到了一個HTP500錯誤，則給我發郵件”)。
集合報表
這些報表針對所有訪客顯示發生了什么一哪些頁面最慢、哪些對象出現的錯誤最多等。可以基于聚合數據和時間段生成報警(例如，“如果5分分鐘之內平均頁面延遲時間間超過5秒鐘，則發送一個SNMP陷阱”)。
常見的RUM用例包括
● 復查問題會話，以診斷網站的技術問題。
● 對網站真實訪客生成服務水平報表，特別是在運行一個軟件作為服務(Sas)的系統時。識別出那些可能需要更多規范監控的部分。
● 對于無法使用綜合方式進行測量的部分，如付款頁面等，測測量其健康狀況
遇到問題即時報警，而不是采用間隔方式，到點兒才報。
RUM的局限
雖然綜合工具都大同小異，但客戶端的RUM工具，和服務器端的相比，是有很大區別的。前者依賴于AAX腳本或者嵌入的代理代碼(agent code)，在終端用戶訪問網站時，采集他們的信息；后者使用服務器日志、負載均衡器或者網絡竊聽器從數據中心收集訪客信息。
客戶端RUM在瀏覽器中觀察用戶體驗，所以能夠測量像客戶端渲染等的延遲。可惜的是，由于只有在頁面成功加載并且在瀏覽器上運行的時候，客戶端RUM才能夠加載，所以就無法檢測導致其自身無法加載這樣的錯誤，而且也可能與某些客戶端不兼容。更進一步說，因為RUM是在瀏覽器的沙箱里運行的，所以也就無法看到更為低層的數據，像包丟失情況，也無法計算用戶訪問第一個頁面時的主機延遲。
服務器端的RUM的問題正相反。因為獨立于瀏覽器，所以能看到發生的任何事情的詳細情況一一甚至是失敗的TCP連接次數，然而卻看不到瀏覽器中發生的情況。或許更重要的是，因為服務器端的RUM需要訪問網絡與日志，以及某些情況下的各個物理網絡，所以對于托管或基于云計算的環境，就無法部署了。許多商業化的RUM解決方案結合了客戶端及服務器端的采集方式來解決這個問題。
配置RUM
有兩個基本步驟來配置RUM工具。首先，訓練工具以理解網站的流量模式，然后告訴工具監視哪些重要的內容。
按照定義，一個RUM工具應該能捕提所有進出服務器的流量。對工具進行訓練是必要的，因為每個網站都是不同的。對工具進行訓練涉及到下面的步驟。
1.剔除不需要的流量。
某些流量你可能不需要。像網站機器人(bots)、其他的監控工具、網絡服務調用以及防火墻之內的流量，所有這些都會讓你曲解終端用戶的體驗。
2.告訴系統如何追蹤單個用戶。
所有網站都會使用某種東西來識別單個訪客，不管是會話 cookie還是URL參數，甚至是IP地址。但在某些RUM實現中一一特別是那些使用客戶端腳本的一這些是不需要的，因為腳本實例運行在每個訪客的瀏覽器中。
3.告訴系統如何組裝頁面。
知道一個頁面在哪里結束以及另一個頁面在哪里開始，是需要技巧的。有些頁面在加載以后可能還會有異步通信(如 Google Suggest，用戶在搜索框中輸入內容時， Google Suggest會基于這些內容顯示建議)。RUM工具需要知道什么東西組成了頁面的開始與結束，這對于合理地計時以及計算頁面數都很重要
4.識別錯誤。
雖然每個網站都有一些基本的錯誤類型(如HTTP500)，但也會有一些定制的頁面，看起來跟正常頁面一樣，但卻是出錯頁面。
一旦工具理解了怎樣才算是一次訪問，以及如何測量延遲，你就可以告訴它要監視些什么。多數RUM工具在開始時都會有默認的參數:頁面、用戶、城市以及服務器都是用來切割數據的好方法，都會向你顯示哪些最慢，或者哪些出錯最多。
由于RUM工具要處理大量信息，所以往往只向你顯示高層次的數據，除非你特別要求做鉆取，例如，進入到網站建設的剛剛發布的那部分，或者顯示一個特定的高價值客戶。一般來說，每個數據區段都可以用來生成報告，以及產生報警或郵件通知。
本文地址：http://knowyourextract.com//article/3345.html
