遥测采集点：为什么是 Sidecar 而不是业务进程

传统应用监控靠业务里埋软件开发工具包来打点，缺点很明显：每个服务都要改代码、统一埋点规范、处理上报失败。服务网格把采集点挪到 Sidecar 代理，代理在协议层终结 TCP 连接、解析 HTTP 或 gRPC 协议，天然知道每一次请求的来向、去向、状态码、耗时、重试次数、熔断状态。

在 bookinfo 里，产品页面服务调用评论服务、评论服务调用评分服务，每一跳的进出流量都经过两端 Pod 的代理。因此评论服务调用评分服务的成功率这个指标，不需要在评论服务的代码里加计数器，而是由评论服务 Pod 的出站代理和评分服务 Pod 的入站代理共同上报、在后端按服务与子集聚合出来的。这种采集方式有三个工程收益：业务无侵入；指标口径统一，不会因不同语言实现的差异而漂移；采集点固定，升级业务版本不影响遥测连续性。

代理上报不是把原始请求发去监控后端，而是先在本地按响应码计数、按耗时分桶统计、按追踪头组装调用片段，再周期性地推给指标后端、追踪后端、日志聚合系统。控制面只管下发采什么、报哪里、采样率多少，不碰具体请求。

指标维度：从总览到子集切片

网格默认采集的指标里，和 bookinfo 最相关的是请求数、错误数、响应时间分布、流量字节数。这些指标都带有维度标签：源服务、源子集、目的服务、目的子集、响应码、响应类型、协议。

维度标签的价值在灰度场景里最明显。评论服务有三个版本子集，产品页面流量进来后，按目的子集拆开，就能同时看到去不同版本的请求量、各自错误率、各自响应时间分布。不需要在评论服务进程里区分版本打点，标签是 Sidecar 根据路由结果自动打的——请求被规则导到某个版本，出站代理就把目的子集标成对应的版本。

除了默认指标，网格允许通过遥测资源配置自定义指标，比如带特定请求头的评论请求计数。但 bookinfo 演示通常不需要走到这一步，默认标签已经够回答哪个版本稳不稳。

响应时间指标在网格里以分布形式存在，查询时再算典型值和尾部值。这点对 bookinfo 很关键：旧版本不调用评分服务，延迟分布集中；新版本调用评分服务，尾部延迟受下游影响。只看平均值会掩盖差异，看分布才能暴露架构代价。

分布式追踪与访问日志的定位差异

指标回答有多少、多快、错多少，追踪回答这一次请求是怎么走过来的，日志回答代理当时说了什么。

bookinfo 的追踪链路是产品页面到评论服务再到评分服务，一共三跳。Sidecar 在入口处生成追踪标识，注入到请求头里传给下一跳，下一跳代理接着上下文继续扩展追踪片段。最终在追踪后端里，一次浏览器刷新对应一条完整的调用树，点开能看到评论服务这一跳耗时多少、其中调用评分服务占了多久、评分服务自身处理多久。灰度时对比不同版本的追踪树，能直观看到新版本多出一跳评分服务调用的耗时构成。

访问日志则是代理按格式打印的每行请求记录，包含时间、源目的、状态码、耗时、路由命中规则名。它不像指标那样聚合，也不像追踪那样串联，更适合排障时翻某个时间点那次奇怪错误是哪边返回的。生产环境常把访问日志采样或按错误级开关，避免全量日志把磁盘打满。

三者互补：大盘看指标，慢请求下钻追踪，异常个案查日志。

路由原语：分组与分发的分工

bookinfo 的路由策略由两个原语承担。分组规则负责后端怎么分组和怎么对待分组——它给评论服务定义多个版本子集，绑定 Pod 标签；给子集配负载均衡算法、连接池、异常点检测。它本身不决定流量去哪，只决定如果去某个版本，那个版本内部怎么挑实例、出错怎么踢。

分发规则负责流量怎么分——挂在评论服务上，写匹配条件与目的地。匹配可以按请求路径前缀、按请求头、按权重、按查询参数。命中后路由到评论服务加对应子集。多条匹配按顺序求值，第一条命中即停，最后留一条无匹配的兜底路由。

这两个资源在控制面被翻译成代理的配置，通过标准协议推到每个相关 Sidecar。因此你在 bookinfo 里改一条分发规则，产品页面 Pod 的出站代理和网关代理几乎同时生效，不需要重启任何业务容器。这也是网格路由和传统入口路由的本质区别：前者是七层、按服务身份、动态下发；后者通常只到域名和路径级别。

重试、超时、故障注入也写在分发规则里。比如给评分服务设超时和重试次数，重试条件覆盖连接失败与错误响应；给评分服务注入固定延时或错误比例做混沌测试。这些动作对评论服务业务代码完全透明——评论服务只知道自己调用评分服务有时慢了、有时重试成功了。

遥测与路由的协同：用数据驱动策略

遥测不是路由的旁观者，而是路由策略的输入源。虽然网格原生不把指标直接接回分发规则做自动调权，但工程闭环是：遥测面板发现新版本错误率抬头，人工或自动分析器判不达标，调低分发规则里新版本的权重或把请求头规则收窄，控制面下发新配置，遥测再观察。这一圈里，遥测提供事实，路由提供杠杆。

bookinfo 演示里常做的一件事：先下分发规则把所有流量锁旧版本，页面无星星；再下一条按特定用户命中新版本的规则，登录该用户看到彩色星星，其他人仍无星星；最后换成权重规则，大部分旧版本小部分新版本，随机刷新偶遇彩色星星。每一步切换后，都去遥测面板看对应子集的请求量是否按预期比例走、错误率是否零漂移。如果权重配了但新版本曲线没起来，先怀疑子集标签不对、再怀疑分发规则没下发到网关、最后才查业务。

这种策略—观测—修正的回路，比单次发布可靠得多。它也解释了为什么网格场景里可观测性不是附加功能，而是路由策略能安全生效的前提。

排障视角：遥测与路由交叉定位

bookinfo 跑起来后常见几类怪象，靠单看一边查不出来。

页面偶尔报错但产品页面 Pod 日志干净：大概率是评论服务或评分服务某一跳的代理返回了错误，去看评分服务子集的成功率和代理访问日志，比翻产品页面业务日志快。

权重配了但彩色星星出现频率明显偏低：检查总流量是否太小导致随机分布偏差，或检查匹配规则里是否有更靠前的请求头规则把部分流量截走。

新版本的响应时间比旧版本高一大截：先确认是不是评分服务边的响应时间同步抬高，是则说明下游代价不是新版本回归；若评分服务平稳则查新版本自身渲染逻辑。

路由改了不生效：确认命名空间注入标签在、分发规则的域名字段写的是评论服务而非带后缀、控制面与集群网络连通。

遥测维度里看不到子集标签：说明流量没按预期进子集，分组规则的标签选择器与部署配置的标签不一致，或子集名拼写错。

结语

bookinfo 在天翼云应用服务网格里跑起来后，遥测数据收集和路由策略是同一套 Sidecar 机制的两面：代理在每一次重定向进来的流量上，既数了数、记了时、采了链、写了日志，又查了控制面刚推下来的路由表决定往哪转。开发工程师理解这套机制，不需要背具体端口和配置字段，而要把握三条主线：采集点在代理、维度靠标签、策略分两层。把这三条和 bookinfo 的四服务调用链对上号，你就能在灰度时看懂面板上的每条曲线为什么动，在排障时知道该去哪一层翻证据——遥测告诉你事实，路由给你改事实的把手，两者合起来才是网格化微服务真正比传统埋点架构高明的地方。