前端監控 (又叫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）前端監控系介紹