流量切换是否成功的核心判断依据是错误率与延迟变化，需聚焦突变点和长尾现象，实时对比新旧路径的错误率（5xx/4xx/业务码）、端到端p95/p99延迟、链路成功率三类指标，并按预热期、扩量期、全量期动态调整监控粒度与阈值。
流量切换期间的错误率与延迟变化，是判断切换是否成功、业务是否平稳的核心指标。监控不能只看平均值，而要聚焦“突变点”和“长尾现象”，尤其要覆盖新旧路径的对比维度。
重点盯住三类指标的实时对比
切换不是单点动作，而是新旧链路并行过渡的过程。必须在同一时间轴上对比两套数据：
- 错误率：区分 HTTP 状态码（5xx、4xx）、业务自定义错误码（如订单创建失败 code=2001）、SDK 层超时/重试失败。新路径错误率若比旧路径高 0.5% 以上，且持续 2 分钟，即需告警
- 端到端延迟：从网关入口到业务响应完成的全链路耗时。重点关注 P95 和 P99 延迟，而非平均值——切换后 P99 若跳升 300ms 以上，往往意味着缓存未命中、回源并发失控或跨机房调用增加
- 链路成功率：对有状态服务（如 IM 长连接、支付回调），还需统计建连成功率、消息到达率、ACK 回执率等业务语义级指标，它们比 HTTP 状态更早暴露问题
按阶段设置监控粒度与阈值
不同切换阶段，监控重点应动态调整：
- 预热期（1%～5% 流量）：开启全链路采样（如 SkyWalking 100% trace），重点捕获慢 SQL、Redis 连接池打满、分布式锁等待日志；错误率阈值设为 0.1%，延迟 P95 ≤ 旧路径 + 50ms
- 扩量期（20%→50%）：启用指标聚合告警（如 Prometheus 的 rate(http_requests_total{path=~".*/order/.*"}[5m])），关注错误率环比上升 >20% 或延迟 P99 上升 >100ms；同步检查 Redis miss 率、DB QPS 是否同比放大异常倍数
- 全量期（100%）：叠加业务核心指标（如下单转化率、消息送达时长）做交叉验证；若延迟稳定但转化率下跌，说明可能是前端渲染或 SDK 行为变更导致，需关联前端监控
快速定位异常源头的三个动作
一旦发现错误率或延迟异常，立即执行以下操作，5 分钟内缩小根因范围：
- 查链路追踪中的“热点 Span”：筛选新路径下耗时 Top 10 的 trace，看是否集中在某个中间件（如某次 MySQL 查询平均 800ms）、某个下游服务（如用户中心返回超时）、或某段代码逻辑（如 JSON 序列化卡顿）
- 比对新旧路径的资源水位：查看 CPU、内存、线程池活跃数、Redis 连接数等是否在新路径节点明显升高；特别注意 JVM GC 频率是否突增，这常是对象创建失控或缓存未复用的信号
- 抽样验证关键请求行为：用 curl 或 Postman 模拟一个典型请求（带灰度 header 或 uid），分别发给新旧路径，对比响应体、HTTP 头（如 X-Cache: MISS/HIT）、耗时分解（DNS、TCP、SSL、TTFB、Content），确认是否在某一层出现偏差
避免误判的两个细节
有些波动看似异常，实为正常现象，需提前识别：
- 冷启动抖动：新服务实例首次接收流量时，JIT 编译、连接池填充、本地缓存加载会导致前几十个请求延迟偏高，通常 1～2 分钟后收敛。可通过观察“首分钟错误率”与“第 3 分钟错误率”的衰减趋势来区分
- 客户端缓存残留：若切换涉及域名或接口路径变更，部分终端仍走旧 DNS 缓存或 HTTP 强缓存，导致错误率虚高。此时需结合 Nginx access 日志中的 $upstream_addr 字段，确认真实流向，而非仅看客户端上报
