經過頁面埋點作監控卻不影響性能？解密ARMS前端監控數據上報技術內幕

摘要： 本文將爲您介紹，在採集多類日誌數據的狀況下，阿里雲業務實時監控服務（ARMS）以前端監控如何優化日誌上報

前端監控 (又叫UEM，User Experience Management, 用戶體驗管理) 通常幫助用戶定位頁面性能瓶頸、復現用戶端的偶發問題。其監控的主要功能包括但不限於：

• 日誌採集
• 日誌上報
• 數據分析
• 平臺展現
• 異常報警

使用前端監控平臺時，用戶最關心的問題每每首先是：

• 平臺能夠監控哪些數據？
• 會不會影響業務性能？

這就涉及到前端監控的監控指標和日誌上報。帶着這兩個問題，本文就爲您介紹一下，在採集多類日誌數據的狀況下，阿里雲業務實時監控服務（ARMS）以前端監控（如下簡稱爲阿里雲前端監控）如何優化日誌上報，讓上報速度快、更快、無比快！

文章主要分爲兩個部分：第一部分"監控指標介紹"解釋前端監控通常須要上報哪些數據；第二部分"日誌上報優化祕笈"解釋前端監控如何針對這些數據上報進行優化。

監控指標介紹

阿里雲前端監控專一於 Web 端真實用戶體驗數據監控，從訪問速度、頁面運行穩定性和服務調用成功率三個方面監控前端的健康度。另外，阿里雲前端監控還提供針對輕量級交互行爲的實時統計功能，可幫助您及時發現業務問題。

阿里雲前端監控的指標以下：

1. 頁面是否正常響應

• 頁面性能日誌 — 實時統計與頁面相關的 12 個關鍵性能指標，幫助您迅速準確地定位性能瓶頸：

  • DNS 解析耗時
  • TCP 鏈接耗時
  • SSL 安全鏈接耗時
  • 網絡請求耗時
  • DOM 解析耗時
  • 資源加載耗時
  • 首包時間
  • 白屏時間
  • 首次可交互時間
  • DOM Ready 時間
  • 頁面徹底加載時間
  • ……
• 訪問統計日誌 — 統計 PV、UV 數據。短期內斷崖式的變化很容易反映業務問題。

2. 頁面運行是否穩定

• 頁面穩定性日誌 — 阿里雲前端監控以 JS 錯誤率衡量頁面運行穩定性，會採集因頁面加載和頁面交互產生的 JS Error 報錯文件、錯誤堆棧的詳細信息，快速定位用戶訪問時發生的錯誤問題。

3. API 請求是否正常響應

• API 調用日誌 — 提供 API 調用結果、耗時及相關信息，快速發現並定位 API 問題。

4. 業務相關日誌

• 自定義上報日誌 — 某些業務邏輯的結果、速度、統計值等自定義內容可幫助您發現業務問題。

若是前端業務複雜、訪問量級較大，那麼相應地，前端監控上報的日誌類型及日誌量也會快速增加。前端監控的最基本原則是日誌獲取和日誌上報不能影響業務性能，因此在這種狀況下，日誌上報性能尤其重要。

接下來，咱們就介紹一下阿里雲前端監控平臺的日誌上報優化祕笈。只要學會了這幾種新姿式，即使日誌量不斷增加，您也能遊刃有餘！

日誌上報優化祕笈

第一招：HTTP No Content

日誌上報只關心日誌有沒有上報，並不關心上報請求的返回內容，甚至徹底能夠不須要返回內容。因此使用 HTTP HEAD 的方式上報，而且返回的響應體爲空，可避免響應體傳輸形成的資源損耗。只須要設置一個 nginx 服務器來記錄日誌內容並返回 200 狀態碼便可。

fetch(`${url}?t=perf&page=lazada-home&load=1168`, {mode:'no-cors',method:'HEAD'})

第二招：HTTP 2.0

HTTP/2 頭部壓縮

每次 HTTP 請求都會傳輸一系列的請求頭來描述請求的資源及其特性，然而實際上每次請求都有不少相同的值，如 Host:、user-agent:、Accept 等。這些數據會佔用 300-800 byte 的傳輸量，若是攜帶大的 cookie，請求頭甚至會佔據 1 kb 的空間，而實際真正須要上報的日誌數據僅有 10~50 byte。在 HTTP 1.x 中，每第二天志上報請求頭都攜帶了大量的重複數據致使性能浪費。

HTTP/2 頭部壓縮採用 Huffman Code 壓縮請求頭，並用動態表更新每次請求不一樣的數據，從而將每次請求的頭部壓縮到很小。

HTTP/1.1 效果

HTTP/2.0 效果

壓縮頭部後，每條日誌請求都大幅縮小，響應的速度也相應提高。

HTTP/2 多路複用

用戶瀏覽器和日誌服務器之間產生屢次 HTTP 請求，而在 HTTP/1.1 Keep-Alive 下，日誌上報會以串行的方式傳輸，並讓後面的日誌上報延時。經過 HTTP/2 的多路複用來合併上報，可爲您節省網絡鏈接的開銷。

第三招：HTTP POST 合併

POST 請求由於 request body 能夠有更大施展空間，相比一條日誌一次 HTTP HEAD 請求的方式，在 HTTP POST 中一次包含多條日誌的內容更加經濟。

在 HTTP POST 的基礎上，能夠順便解決用戶關掉或者切換頁面形成的漏報問題。

之前常見的解決方式是監聽頁面的 unload 或者 beforeunload 事件，並以經過同步的 XMLHttpRequest 請求或者構造一個特定 src 的 <img> 標籤來延遲上報。

window.addEventListener("unload", uploadLog, false);
function uploadLog() {
  var xhr = new XMLHttpRequest();
  xhr.open("POST", "/r.png", false); // false表示同步
  xhr.send(logData);
}

這種上報方式的弊端是會影響下一個頁面的性能。更優雅的方式是使用 navigator.sendBeacon()，它可以異步發送日誌數據。

window.addEventListener("unload", uploadLog, false);

function uploadLog() {
  navigator.sendBeacon("/r.png", logData);
}

合併前

合併後（navigator.sendBeacon）

理想狀況下，合併 N 個日誌上報耗費的總時間可縮減至原來的 1/N。

總結

阿里雲前端監控的日誌上報總體優化流程以下：

通過這幾步優化後，日誌上報性能明顯提高：

• 日誌上報的傳輸量可大幅下降至原來的 1/10 左右
• 日誌上報響應時間可提速 80% 左右

實際大促業務場景在線上的驗證結果代表，業務性能不會受到影響。因此，即使您的業務訪問量級較大或者性能要求較高，也無需擔憂接入後的性能問題，可放心接入使用。

附：阿里雲業務實時監控服務（ARMS）前端監控系介紹

• 業務實時監控服務（ARMS）
• 應用監控
• 前端監控
• 自定義監控

原文連接