Google Cloud ULL流量镜像白名单正式可用：采集范围与重复包计数需要一起核对

2026年9月30日，Google Cloud宣布ULL Packet Mirroring以白名单方式正式可用，面向获批的交易所参与者，可把ULL VPC流量副本送往收集实例分析。ULL方案此前公布的私有可用区为us-south1-d与us-south1-e；这不是面向所有普通VPC账户的无条件开放。

AI概念配图，非真实界面/产品。

同一个包可能出现在两个观察点

官方文档说明，服务在可用区网卡的发送和接收点采集，每个包会被镜像两次。底层默认镜像符合条件的流量，但收集器若没有附加过滤规则，不会收到镜像流量。收集器的活动状态、过滤规则和实际接收结果需要分别理解。

本文认为，新增观察能力最先要求团队明确“在数什么”。若直接把所有镜像记录相加当成业务发送量，结果可能与应用统计不一致。分析前应定义记录代表观察事件还是独立数据包，并保留观察位置，避免把同一路径上的两次观察混成异常重复发送。

一个可行的试验是生成一段容易辨认的小流量，记录发送端、接收端和采集端各自看见的数量。让这些数字在同一时间窗口内比较，再解释预期差异。这里是本站建议的验证方式，不能代替厂商对具体工作负载的支持说明。

采集成功与分析正确是两件事

部署时建议先检查规则是否选中了真正需要观察的流，再检查收集实例是否能持续处理流量。入口能收到数据，只表示链路已经连通；如果处理程序在高峰时丢弃记录，后面的统计仍可能失真。

延迟分析也应写清测量点与时钟来源。应用写日志的时间、网络观察到包的时间和分析系统入库的时间，回答的是不同问题。把它们混在一条曲线上，容易把采集排队误认成业务网络延迟。

对镜像数据的保存，本文建议按实际排障目的决定字段和留存期，并明确谁能够查询。把更多流量收集下来不等于每个人都需要看到全部内容。测试完成后，应核查试验期间临时开放的分析权限是否仍有用途。

先建立可复核的观察基线

新闻公告对性能影响作出厂商层面的说明，用户仍应在自己的负载下建立基线。可以比较启用相关收集配置前后的业务指标，同时观察采集端的处理情况。若没有足够样本，不宜把一次短测外推成长时间运行结论。

这次发布更适合已有ULL接入资格、且需要精细网络证据的团队评估。初步验收至少应回答三件事：选中了哪些流量，同一数据包如何对应多个观察记录，以及采集数据能否解释一个真实问题。把这些答案写清楚，镜像流量才能成为排障材料。

运维交接时，可以留下一段已知输入及预期采集结果作为参考。后续修改规则或更换收集实例后，先用同样样本复查，有助于判断观察链路本身是否发生变化。

来源与核验

ULL官方发布记录（2026-09-30）。

ULL官方文档：Packet Mirroring（2026-10-01核验）。

本文于北京时间2026年10月1日核验。新闻事实来自上述官方资料，文中使用判断与实施建议为本站独立分析，后续状态以官方更新为准。