你的監(jiān)控?cái)?shù)據(jù)去哪了？廣告攔截器正在吃掉它

你有沒有遇到過這種情況：后臺(tái)顯示用戶活躍度正常，但前端監(jiān)控儀表盤上的頁面瀏覽量卻低得離譜？一位AWS工程師最近就碰上了這茬——排查半天發(fā)現(xiàn)，uBlock Origin把CloudWatch RUM的數(shù)據(jù)請(qǐng)求全攔了。

這不是個(gè)例。隨著廣告攔截器滲透率飆升，越來越多的"合法"遙測(cè)數(shù)據(jù)正在被誤殺。而解決方案出人意料地簡(jiǎn)單：把AWS的監(jiān)控端點(diǎn)藏進(jìn)你自己的域名。

一、問題：RUM的"隱身"盲區(qū)

CloudWatch RUM（真實(shí)用戶監(jiān)控）是AWS里被低估的寶藏服務(wù)。頁面加載時(shí)間、JavaScript報(bào)錯(cuò)、HTTP失敗、Web Vitals核心指標(biāo)——這些直接影響用戶體驗(yàn)的數(shù)據(jù)，它都能抓。

但有個(gè)致命盲區(qū)。

RUM默認(rèn)把數(shù)據(jù)發(fā)往dataplane.rum.*.amazonaws.com。廣告攔截器的規(guī)則庫(kù)不區(qū)分"好遙測(cè)"和"壞追蹤"：凡是第三方域名往外傳數(shù)據(jù)，一律按可疑處理。工程師打開DevTools時(shí)看到的一幕很說明問題——uBlock Origin安安靜靜地屏蔽了每一條RUM請(qǐng)求，儀表盤對(duì)這部分用戶完全失明。

原文作者的原話是：「Our real user monitoring was blind to a non-negligible portion of our actual traffic.」

翻譯過來：非 negligible（不可忽略）的流量，正在從你的監(jiān)控視野里消失。對(duì)于依賴數(shù)據(jù)做產(chǎn)品決策的團(tuán)隊(duì)，這是系統(tǒng)性偏差。

二、原理：為什么域名成了命門

廣告攔截器的判斷邏輯很粗暴：看域名。你的業(yè)務(wù)代碼跑在myapp.example.com，RUM數(shù)據(jù)卻飛向amazonaws.com——跨域、第三方、Telemetry，三重標(biāo)簽疊加，觸發(fā)攔截幾乎是必然的。

這背后的用戶心理也合理：普通用戶裝廣告攔截器，本就不打算區(qū)分"Google Analytics"和"CloudWatch RUM"。他們要的是清凈，不是技術(shù)考古。

但代價(jià)轉(zhuǎn)嫁給了開發(fā)者。你以為是用戶流失，其實(shí)是監(jiān)控失效；你優(yōu)化了性能，卻看不到真實(shí)用戶的加載體驗(yàn)。數(shù)據(jù)缺口會(huì)扭曲所有下游決策。

三、解法：用CloudFront做一層代理

修復(fù)方案的核心思路是域名歸一化：讓RUM請(qǐng)求看起來像你網(wǎng)站的一部分。

具體架構(gòu)：

1. 在CloudFront上加一個(gè)行為路徑/rum/*

2. 這個(gè)路徑代理到RUM的真實(shí)數(shù)據(jù)平面端點(diǎn)

3. 前端SDK不再直連AWS，而是指向https://yourdomain.com/rum/

廣告攔截器掃域名時(shí)，看到的是同源請(qǐng)求，放行概率大幅提升。

實(shí)現(xiàn)上，作者用的是AWS CDK，但CloudFormation、Terraform、控制臺(tái)手動(dòng)配置都能跑通。關(guān)鍵是理解這個(gè)代理層的作用：它不是繞開用戶選擇，而是消除"誤傷"——你的RUM數(shù)據(jù)對(duì)業(yè)務(wù)運(yùn)維是必要的，不該和廣告追蹤混為一談。

四、落地：身份池與權(quán)限的坑

RUM的授權(quán)機(jī)制依賴Amazon Cognito身份池。瀏覽器端是未認(rèn)證用戶，需要顯式開啟allowUnauthenticatedIdentities: true。

權(quán)限鏈條要串好：

- 身份池 → IAM角色（WebIdentityPrincipal）

- 角色策略 → rum:PutRumEvents動(dòng)作

- 資源范圍限定到具體App Monitor ARN

作者貼出的CDK代碼里有個(gè)細(xì)節(jié)：Cognito角色的信任策略要匹配amr: unauthenticated，這是瀏覽器匿名訪問的憑證來源。漏了這一環(huán)，前端SDK會(huì)報(bào)授權(quán)失敗，但錯(cuò)誤提示往往模糊成"網(wǎng)絡(luò)問題"，排查起來很耗時(shí)間。

配置參數(shù)建議：

- sessionSampleRate: 1.0 全量采集（小流量場(chǎng)景）

- enableXRay: true 開啟分布式追蹤聯(lián)動(dòng)

- telemetries 數(shù)組按需選性能、錯(cuò)誤、HTTP三類

五、延伸：這場(chǎng)貓鼠游戲的邊界

代理方案不是銀彈。極端情況下，廣告攔截器可以進(jìn)化到檢查請(qǐng)求體內(nèi)容、分析流量模式。但在當(dāng)前生態(tài)里，域名白名單仍是主流策略，同源代理的通過率顯著高于第三方直連。

更深的問題是誰來定義"合法遙測(cè)"。RUM收集的是性能數(shù)據(jù)，不含個(gè)人身份信息，但用戶沒有技術(shù)能力分辨。攔截器的粗粒度規(guī)則是效率與誤傷的權(quán)衡，開發(fā)者的應(yīng)對(duì)則是技術(shù)層面的精細(xì)化規(guī)避。

這對(duì)產(chǎn)品團(tuán)隊(duì)的啟示是：監(jiān)控基礎(chǔ)設(shè)施的設(shè)計(jì)，必須前置考慮客戶端環(huán)境的不確定性。等數(shù)據(jù)缺口暴露再補(bǔ)，損失已經(jīng)發(fā)生了。

原文作者最后沒說的潛臺(tái)詞：如果你還在用默認(rèn)端點(diǎn)，你的RUM儀表盤可能正在系統(tǒng)性地低估真實(shí)流量。檢查一遍DevTools的網(wǎng)絡(luò)面板，看看有沒有紅色的攔截標(biāo)記——這五分鐘，值得花。