模擬監控和真實用戶體驗監測，選哪一個？

終端用戶模擬監控，也就是國內俗稱的「雲撥測」，其低廉的價格以及便捷的部署方法加快了模擬監測的普及速度，但同時也致使了一些誤用：不少公司以及用戶將模擬監控當作用戶的真實訪問狀況，監控出來的數據很棒，可是用戶的投訴卻一直不斷。

一.前言

最近幾年，IT 界人力成本愈來愈高，而且大數據的到來從某種程度上講也意味着互聯網前期靠人力來進行性能優化的時代已通過去了，因而各類 APM 工具應運而生。

從實際角度講，只有少數 APM 廠家才具有開發基於真實用戶體驗的性能監控工具的能力，因此模擬監控一直以來都是 APM 的主流。而且不少狀況下，APM 供應商經常會單獨出售模擬監控測試工具，並將其徹底等同於性能監控，這致使監控方案的買主們經常誤解這些技術案例，覺得他們就是本身想要的真實用戶體驗監控。

從根本上說，這是因爲用戶對「可用性」與「真實用戶體驗性能監控」的理解有誤形成的。

大多數模擬監控更偏重於網站應用的可用性、響應時間等，其固然有本身的重要之處，可是若是要有針對性的進行性能監控優化的話，基於真實用戶體驗的性能監控是必不可少的。

二.性能監控工具的推廣難在哪裏？

1.性能監控領域的主要問題

• 模擬監控與測試簡單易懂，部署起來很方便，容易實現，不涉及代碼權限的問題，但只從這一個渠道得到數據，並用於評定應用性能顯然不是正確的視角。

• 雖然真實用戶體驗監控工具正在優化其部署方法，但，最基本的運維權限甚至修改頁面代碼的限制，確實制約了其普及的力度。

• 許多公司缺乏真實用戶監控意識，不瞭解什麼是「真實用戶體驗」，經常錯誤地將模擬監控徹底等同於應用性能監控管理（APM）。

2.相關建議

• 實施真實用戶監控技術，安裝包含多種 APM 維度的探針（具體的介紹在文章後面有），若是探針沒法安裝或風險太大，則部署網絡監控。

• 不要爲了評定應用性能而部署過多模擬監控，模擬監控主要是從可用性的角度來監測的，好的優化團隊應該從真實用戶數據中找到可優化點，從而打破檢測與監控的循環。

• 控制模擬監控的人員與資金投入，而將資源投入到更有價值的活動中，如真實用戶體驗監控。

• 將模擬監控用於 SLAs （服務水平協議）基準測試，以及適合的性能監控案例，諸如第三方應用組件、API接口、Ping值的性能測試。

3.戰略規劃設想

以前在 Gartner 看到過相關數據，將來互聯網對應用性能的需求必定會逐漸超過對應用可用性的需求，而且在 2015 年，模擬監控佔性能監控使用量的百分比減小 30% ，而且未來會進一步降低。

三.針對現狀的分析

1. 瞭解並使用相關真實用戶體驗監控技術和工具

任何真實用戶體驗監控技術和工具的重點一般都是針對終端用戶的基礎架構或組件的監控。智能化的工具是測量真實用戶體驗的理想工具，由於它們理解應用的運行狀況，會自動基準化性能表現，在幾乎不產生干擾的狀況下解碼並創建應用子組件間的關係。

現階段，國內外在測量終端用戶體驗時，主要三種不一樣的性能監控方法：

1).以網絡爲基礎的探測技術——從數據中心的邊緣或環境中的多點調查網絡流量，從而肯定終端用戶響應時間，以及其餘應用基礎組件的詳細信息（好比：數據庫，中間件和文檔服務器等），這些工具不只能處理以 Web 爲基礎的應用，也監測網絡中其餘應用。

此類服務供應商包括：OneAPM Applicaton Insight、Mobile Insight, AppNeta, Appnomic,BMC Software, Boundary,Compuware, Network Instruments, Net Optics, Niksun, Opnet Technologies, Oracle, Paessler, Riverbed, VMware, WildPackets 等。

2).以瀏覽器爲基礎的腳本注入——幫助用戶瞭解運行瀏覽器的主要終端，包括PC、微信、移動端瀏覽器、Android webview 等，能知足這點很不容易。通常狀況下，這種工具的部署比較簡單，主要採用往頁面插入 js 代碼的方法，可是須要機械性的操做還要有修改代碼的權限才行。

將來的移動應用將會包含複合型應用，它們結合了本地應用程序功能與瀏覽器相關的組件。這種使人期待的應用將支持 JavaScript 的運行，還能夠擴平臺，並且部署更加簡單。現有的某些 APM 工具能檢測 DNS 響應時間，數據從終端用戶傳到服務端的傳輸時間、CDN 資源監控等，當這些工具與網絡或基於服務器的監控結合使用時，就能夠瀑布式地細分頁面內的各個資源加載耗時等。

此類服務供應商包括：AppDynamics，OneAPM Browser Insight，Arcturus， BMC Software， Cedexis， Compuware， Lucierna， Microsoft， New Relic， Opnet Technologies， Precise， Tracelytics 等。

3).終端部署——用戶在終端設備安裝探針或部署代碼，從而獲取終端用戶體驗，以及應用運行環境的詳細信息。這對於控制桌面的企業並不難實現，而對於移動設備監控，則愈加重要。移動設備監控容許管理員在設備上（平板、手機）植入探針，或將代碼嵌入本地的移動應用，對於不接受消耗巨大的應用的企業，配置也能夠部署在應用內部。

此類服務供應商包括：OneAPM ，Aternity, Correlsense, Next Think 等。

因爲獲取真實用戶監控數據的渠道不少，致使數據實現（data implementations）也變得很複雜起來，能夠嘗試使用探針在服務端植入腳本這類手動 JavaScript 注入方式、在端點設備配置探針或探測網絡中能夠了解數據包的位置等方法。然而，這類技術的部署不像模擬業務只需弄個 URL 那麼簡單，所以配置方法的便捷化還是現期的主要目標。

2.模擬監控技術的不足

現有的模擬監控每每須要腳本或創建在必定時間間隔內執行的多步驟事務。這些腳本與事務在軟件改變時也須要維護，從而帶來持續的管理成本。

一般狀況下，模擬監控取自高速網絡鏈接中的高速服務器，這些交互並非用戶使用應用時真實的用戶體驗。基於真實用戶與模擬測試的數據分析顯示，二者之間存在兩到三倍的標準差。這種差異是由模擬測試工具運行時的處理、鏈接以及環境與終端用戶實際可得的鏈接、計算資源的差別形成的。所以，許多公司賴以進行應用性能監控的模擬測試真的只是個「模擬值」，於是帶來錯誤的安全感。

模擬事務的測試數量有些過多，好比屢次測試用戶可能選擇的事務軌跡，或者頻繁測試以測量應用的響應狀況。當測試過多的狀況發生時，會產生較大負載，可能影響用戶體驗，尤爲是當他們運行到應用中資源受限或瓶頸的部分。

大多數現代應用經常會配備緩存機制，若是沒有明確指出，經常在軟硬件層實施（好比：存儲緩存，數據庫緩存，應用服務器緩存甚至是 OS 緩存）。這致使一種誤解——運行間隔較大的 trace 每每表現不錯，而實際的狀況可能並不是如此。

所以，未來模擬檢測的使用百分比的降低定是不言而喻。

模擬交易會致使其餘操做上的問題。安全方面，模擬交易可能會涉及模擬憑證或登陸，或使用真實用戶的證書以測試系統。這會下降整個軟件系統的安全度。經過使用真實的交易數據，能夠規避這些問題，同時收集到更有意義的數據用於分析，並評定真實終端用戶的體驗。

四.模擬監測的主要價值——應用可用性

普遍地將模擬測試用於確保應用性能實際上是誤用，模擬測試主要是抓取重大的應用或組件故障。當模擬測試顯示應用響應能力的誤差時，並不能指明真實用戶受到的影響，甚至沒法斷定主要問題出在哪兒，由於用戶交互上的不順利或運行失利每每沒法經過該技術檢測出來。該技術惟一的正確用途是檢查應用或服務的可用性，或系統問題的根本緣由分析（root cause analysis，RCA）。儘管模擬測試可用於根本緣由分析，APM 技術卻能提供粒度更細緻的根本緣由分析。

模擬交易用於檢測可用性與性能的一個理想化案例是測量應用的第三方組件（API 監控）。當代應用引入的組件每每包含社交媒體功能，例如：臉書的點贊按鈕，Google+的「+1」按鈕或推特的轉發功能。這些組件在頁面渲染時可能致使緩慢。而緩慢的緣由很難使用真實用戶監控技術準肯定位。

不幸的是，使用真實用戶數據測量並創建 SLAs 困難重重，真實用戶數據每每受基礎架構與運營團隊沒法控制的因素曲解。相比之下，模擬測試卻能清楚反應不可用的應用或服務。

將模擬測試用於 SLA 測量的基準也是很好的使用案例。然而，不要只關注於模擬測量，瞭解真實用戶體驗還是測量應用使用狀況最重要的指標。

五.總結

從以上分析可得，真正看重應用性能的公司，應當把時間與金錢更專一於真實終端用戶角度，而不是模擬監控能帶來的可用性測量，而且模擬事務監控應該用於測量應用與第三方組件或服務的可用性。

模擬監控天然有其巨大價值的存在，而且接下去的一段時間，模擬監測的其餘使用案例一定會不斷涌現，好比，將模擬測試與其餘數據源結合，能實現對應用性能更多維度的理解。這些解決方案的主要目標是使面向大量終端用戶的應用程序能順利交付，並且，應用交付與內容傳遞在全球範圍內的監控對大多數公司而言都相當重要。

注：本文原做者爲 Gartner 分析師 Jonah Kowall，由 OneAPM 產品運營編譯整理

Browser Insight 是一個基於真實用戶的 Web 前端性能監控平臺，可以幫你們定位網站性能瓶頸，網站加速效果可視化；支持瀏覽器、微信、App瀏覽 HTML 和 HTML5頁面。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客