云 / 系统
我想进一步了解自己的网站在真实浏览器中的运行情况。服务器日志可以显示请求，并帮助估算可能来自真人的页面浏览量，但它们无法完整反映访客设备上的实际体验。
因此，我着手准备了 Amazon CloudWatch Real User Monitoring（RUM，真实用户监测）。这个名称听起来比数据本身更确定，所以有必要说清楚这套方案能说明什么、不能说明什么。
少量、经同意后收集的信号
计划中的浏览器集成刻意保持精简。网站会先征求同意；只有访客选择“允许”后，AWS 客户端才会加载。拒绝后不会发送任何 RUM 数据。选择会保存在浏览器中，访客之后也可以撤回同意。
在同意的会话中，只会抽取一部分：5%。这是抽样设置，并不意味着一定会统计到 5% 的人。抽样具有概率性；未同意的访客完全不会出现在 RUM 数据中。
配置重点收集页面浏览和会话事件。会话回放、RUM Cookie、X-Ray，以及错误、HTTP 和性能采集器均已禁用。AWS 会在美国东部（北弗吉尼亚）区域保留事件 30 天。网络请求必然会暴露 IP 地址；事件数据还可能包含页面路径、时间戳、浏览器和设备的技术信息，以及假名化的会话标识符或 Cognito 标识符。页面路径不包含查询参数。
这不是访客人数
5% 抽样再加上主动同意，只能得到稀疏且有选择性的信号。它无法代表每位访客，也无法确定有多少独立个人使用了网站。浏览器会话、服务器端页面浏览量和 CDN 请求是不同的测量方式，各有盲点。
我会把这些指标分开看。RUM 或许能帮助我了解抽样选中的浏览器活动。现有服务器端计数仍然只是依据请求过滤规则得出的估算，并非经过身份验证的人数。CDN 请求总量还包括静态资源和自动化流量。把它们合成一个“访客数”，只会让结果失真，而不会更有用。
成本保护措施有其局限
RUM 事件和配套 AWS 服务可能产生费用。5% 的会话抽样可以降低预期流量，但它不是配额：获准的客户端可以被直接调用，攻击者也可能绕过浏览器端的抽样逻辑发送事件。
这套设计包含一个监控事件摄取量激增的告警，以及一个会向访客角色添加显式 IAM 拒绝规则的 Lambda 函数。告警触发且 IAM 变更生效后，我可以借此阻止后续数据摄取。但它无法撤回已经被接受的事件，而且监控与关闭措施都存在传播延迟。这是一道保护措施，不是保证支出上限的机制。
我也保留了网站现有的账户级月度变更停止机制，并要求在进行 AWS 变更前重新评估成本。这些控制很有用，但都无法保证实时得出精确账单。告警作出响应之前，突发流量仍可能产生更多费用。这种剩余风险是决策的一部分，不能靠一张令人安心的仪表板消除。
已启用，仍需收集证据
网站上已经部署了征求同意的客户端和本地化隐私说明。客户端会先征求访客同意；只有访客选择“允许”后，才会加载 AWS SDK。激活运行手册记录，范围受限的 RUM 数据摄取权限已于 2026 年 11 月 11 日解锁。5% 的会话抽样只适用于已同意的会话，并不代表所有访客的统计结果。
这说明数据通道已经开放，但还不能说明线上信号实际是什么样子。我尚未确认真实浏览器事件是否已产生，也未核实因此产生的账单。我也没有对告警阈值进行线上测试。已配置的熔断机制会监控 60 秒内至少摄取 20 个事件的情况，并请求 Lambda 函数向访客角色添加 IAM 拒绝规则。它无法移除已经接收的事件；监控、通知和 IAM 变更都需要时间传播生效。停止措施生效前，突发流量仍可能产生更多费用。
这道熔断机制是一种响应措施，不是硬性的支出上限。账户的月度安全停止机制会在达到阈值时阻止代理继续进行变更；它无法保证账单金额精确，也不会停止现有服务。特别是在真实事件量和费用仍未核实的情况下，这些限制应与任何 RUM 结果一并说明。
我希望这项测量保持克制、易于理解：先征求同意，只对少量已同意会话进行抽样，把现有服务器端和 CDN 指标分开，并明确说明数据和保护措施无法保证什么。