你的監控數據正在"被消失"：AWS RUM與廣告攔截器的攻防戰

「幾周前，我發現CloudWatch RUM的頁面瀏覽量低得可疑。打開瀏覽器開發者工具一看：uBlock Origin正在靜默攔截所有發往dataplane.rum.eu-west-1.amazonaws.com的請求。」——一位AWS用戶的真實排查記錄。

這不是個例。當你以為自己在用CloudWatch RUM（真實用戶監控）完整追蹤用戶體驗時，廣告攔截器可能正在系統性地抹除你的數據。更諷刺的是，這個架構缺陷的修復方案，AWS文檔里幾乎沒提。

為什么你的RUM數據會"失蹤"

CloudWatch RUM是AWS被低估的服務之一。頁面加載時間、JavaScript錯誤、HTTP失敗、Web Vitals——這些真實用戶體驗指標，它都能抓。開箱即用的儀表盤長這樣：

問題出在數據流向。RUM的SDK默認把遙測數據直發往dataplane.rum.*.amazonaws.com，而廣告攔截器的規則庫把這個域名歸類為"第三方追蹤"。uBlock Origin、AdGuard、Pi-hole——它們不區分"用戶體驗監控"和"廣告追蹤"，一律攔截。

結果是：你的RUM儀表盤看到的用戶，只是沒被攔截的那部分。技術團隊基于殘缺數據做優化決策，產品團隊對著偏低的轉化率困惑——沒人意識到樣本已經失真。

修復方案：用你自己的域名做"特洛伊木馬"

核心思路很簡單：既然*.amazonaws.com被拉黑，那就讓數據走你自己的域名。CloudFront（內容分發網絡）本來就是前端標配，多加一條路徑規則就行。

架構變成這樣：

1. CloudFront新增行為：/rum/*路徑代理到RUM數據平面

2. 客戶端SDK指向https://yourdomain.com/rum/，而非默認AWS端點

3. 廣告攔截器看到的是同源請求，放行

工具鏈不限定。作者用AWS CDK演示，但CloudFormation、Terraform、控制臺手動配置都能實現。

第一步：搭建身份認證體系

RUM需要Cognito身份池（身份認證池）授權瀏覽器發送遙測。關鍵配置：允許未認證訪問（unauthenticated access），因為用戶不會為了被監控而登錄。

代碼邏輯分四層：

創建身份池 → 配置未認證角色 → 綁定角色到身份池 → 創建RUM應用監控器

角色權限只給最小必要：rum:PutRumEvents。這是AWS的常規操作，但新手常在這里卡殼——IAM策略寫錯，瀏覽器控制臺報403，數據死活進不來。

應用監控器的配置項值得細看：

- allowCookies: true：跨會話追蹤用戶旅程

- enableXRay: true：關聯分布式追蹤

- sessionSampleRate: 1.0：100%采樣，生產環境通常調低

- telemetries：按需勾選performance/errors/http

第二步：CloudFront做流量中轉

這是整個方案的靈魂。CloudFront行為配置的關鍵字段：

- 路徑模式：/rum/*

- 源：RUM數據平面的Regional端點（如dataplane.rum.eu-west-1.amazonaws.com）

- 緩存策略：禁用緩存，每次請求直通源站

- 源請求策略：透傳必要頭部

這里有個陷阱：RUM數據平面是Regional服務，選錯區域，延遲飆升。作者沒明說，但代碼里硬編碼了eu-west-1——如果你的用戶主要在亞太，得改成ap-southeast-1之類。

同源策略（Same-Origin Policy）的繞過是意外收獲。瀏覽器對yourdomain.com/rum/的請求不帶額外戒備，CORS（跨源資源共享）問題也少了。

第三步：客戶端SDK改配置

aws-rum-web SDK的初始化參數里，endpoint字段默認留空（走AWS全局端點）。現在要顯式指定：

endpoint: 'https://yourdomain.com/rum/'

其余配置不變。Telemetry配置、身份池ID、應用監控器名稱——這些從AWS控制臺復制粘貼。

部署后驗證：打開瀏覽器開發者工具，Network面板里應該只看到對yourdomain.com/rum/...的請求，狀態碼200，響應體是RUM的確認格式。如果還能看到dataplane.rum.*.amazonaws.com的請求，說明SDK配置沒生效，緩存沒清干凈。

這個方案沒說的三件事

作者的技術博客到此為止，但生產環境還有坑：

成本。CloudFront的請求費用 + 數據傳輸費用，對比RUM本身的按事件計費，這筆賬沒人幫你算。小規模應用可以忽略，日活百萬級得做壓力測試。

延遲。CloudFront多了一跳，RUM數據是異步批量發送的，用戶體驗監控本身對實時性要求不高——但如果你是用來做實時告警觸發，得評估這條鏈路的P99延遲。

攔截器的進化。廣告攔截器的規則庫是動態的。今天你用自己的域名繞過去了，明天規則庫加入"已知監控路徑模式匹配"，又可能失效。這是貓鼠游戲的本質。

為什么這件事值得所有技術團隊自檢

數據完整性是監控系統的生命線。RUM的賣點是"真實用戶數據"，但如果樣本被廣告攔截器系統性過濾，它就不再真實——它偏向"不用廣告攔截器的那類用戶"，而這群人的技術素養、付費意愿、使用習慣，可能和你的整體用戶群差異巨大。

這個修復方案的價值，不在于技術多復雜，而在于AWS沒把它做成默認。官方文檔讓你直連接dataplane.rum.*.amazonaws.com，仿佛廣告攔截器不存在。這種"假設理想環境"的產品設計，在2024年的互聯網生態里，是一種失職。

如果你在用CloudWatch RUM，現在就該打開瀏覽器開發者工具，裝個uBlock Origin，看看自己的數據平面請求是不是紅的。