观测点怎么布
单点抓包只能看到链路的一段，能够形成证据链的是多点采集：通常在客户端、接入网关、服务入口、服务实例四类位置按需布点。布点方案要说清每一项：位置、采集工具与粒度、持续时间、时钟源，以及责任人。点位命名与时钟源必须统一，否则时间线拼不起来。点位也不是越多越好，每增加一个点就多一份噪声与对齐成本，先按最小集采集，确认差异之后再逐步扩展。
基本信息
| 点位类型 | 客户端、接入网关、服务入口、服务实例 |
|---|---|
| 方案要素 | 位置、工具与粒度、时长、时钟源、责任人 |
| 时钟要求 | 各点统一时间源，否则无法拼接时间线 |
| 扩展策略 | 先最小集，再按需增加点位 |
| 主要成本 | 点位越多，噪声与对齐工作量越大 |
典型使用场景
- 复杂故障定位：需要证明问题发生在哪一段链路时
- 责任界定：给网络与应用双方提供可对照的数据
- 采集规划：明确每个点使用什么工具、持续多长时间
- 时钟核对：抓包前确认各点时间是否对齐
- 复盘留档：记录点位与过滤条件以便复现
点位清单骨架
点位清单骨架
# 名称 | 位置 | 采集工具 | 时长 | 时钟源
# 客户端点：抓包工具，短时采集
# 入口点：长时间环形缓冲
# 实例点：按需临时启用
# 每点都要记录过滤条件与抓包工具版本点位选择
| 点位 | 能看到什么 | 常见用途 |
|---|---|---|
| 客户端 | 用户侧真实体验与网络质量 | 判断本地网络问题 |
| 接入网关 | 网络边界的转发情况 | 定位丢包与策略影响 |
| 服务入口 | 请求进入服务前的状态 | 判断入口设备是否改写 |
| 服务实例 | 应用实际收发情况 | 排除网络后归因应用 |
点位时钟不统一会让时间线拼接失败，开抓之前先核对各点时间源——这是最容易被忽略、代价却最高的一步。
忘记记录点位与过滤条件会导致回放时无法复现，采集说明应当与抓包文件一起归档，而不是事后凭记忆补。