云原生可观测性：零侵入是如何做到的

上一篇结尾，OTel 把仪器化的代价压得很低——一次插桩、后端自由——但它留了个尾巴：你仍然要集成 SDK、挂上 agent、为业务逻辑补手写插桩。“很低”，不是”零”。

这最后一篇，要去看云原生给出的那个终极答案：零侵入（zero-instrumentation）。让应用代码一行都不用改，由平台——服务网格、eBPF——在网络层和内核层，替你把遥测数据产出来。这是 仪器化代价那根标尺被推到的终点。它既是云原生范式的收官，也是这整套系列十篇文章的终点——读完它，我们就能回头看清，那架天平从 监控到此刻，到底走过了一段怎样完整的旅程。

一、仪器化的终点：让应用一无所知

OTel 之后，还剩什么负担

OTel 已经很省力了，但把它的落地步骤摊开，仍有几件事必须有人做：在每个服务里引入 SDK 或挂上 auto-instrumentation agent、配置好导出、再为框架覆盖不到的业务逻辑补上手写 span。对一个有几百个服务、十几种语言、还掺着遗留系统的公司来说，“在每个服务里都做好这几件事”，本身就是一项浩大的、永不结束的工程。

问题于是变成：这几件事，能不能连应用都不碰，全部由平台代劳？

零侵入的定义

收紧成定义：零侵入可观测性，是指在不修改、不重新编译、不重启应用的前提下，由应用之外的基础设施自动产出遥测数据。 应用对”自己正在被观测”这件事，完全无感——它该干嘛干嘛，遥测在它脚下、在它周围、在内核里悄悄发生。

仪器化标尺的完整轨迹

把这一路连起来看，仪器化代价这根标尺，走过了一条清晰的下沉轨迹——让”系统开口”的负担，一层层从应用往下沉：

手写 SDK          → 应用亲自打点（03 指标、06 追踪）
框架自动注入       → agent 拦截框架层（09 OTel auto-instrumentation）
内核/网络零侵入    → 基础设施替你看（本篇：服务网格 + eBPF）
   负担：应用代码 → 框架 → 基础设施，越来越低

零侵入是这条轨迹的终点：负担彻底离开了应用，沉到了平台。这一篇就是讲，这”最后一沉”是怎么做到的。

二、三种零侵入手段（各管一段）

零侵入不是一种魔法，是三种各管一段的技术拼起来的。看清它们各自站在哪、能看见什么，是这一篇的骨架。

服务网格：代理层的黄金信号

追踪那篇说过，服务网格（Istio、Linkerd）会给每个服务旁挂一个代理（sidecar，或新一代 Ambient 模式的 ztunnel）。所有进出这个服务的网络流量，都要穿过这个代理——这就给了它一个绝佳的观测位置。

代理在数据穿过时，零代码地采集出黄金信号（golden signals）——延迟、流量、错误、饱和度——以及服务间调用的 L7 追踪（它能解析 HTTP/gRPC，知道是哪个请求、什么方法、什么状态码）。应用完全不知道这一切发生了，因为采集发生在它的进程之外、在代理里。

服务网格看见的，是”服务之间”——谁调用了谁、调用的延迟和成败。这是分布式系统最核心的一张图，而它的获取，对应用零成本。

eBPF：内核路径的全景

服务网格站在代理层，eBPF 则站得更低——内核。一个请求无论走到哪，最终都要经过内核的网络栈、要发起系统调用。eBPF 在这些内核路径上挂探针，于是它能看见网络流、连接、系统调用、L3/L4（也能解析 L7）的一切——而且连 sidecar 都不需要。

这一类工具——Cilium 的 Hubble（网络流可观测性）、Pixie（K8s 全景观测）——比服务网格更底层、开销更低（07 讲过 eBPF 那 1% 的开销），且同样不挑语言、不改应用。eBPF 看见的，是”内核看得见的一切”——网络层面的全景，连那些没接入网格的流量也跑不掉。

自动仪器化：框架层的补充

服务网格看服务之间，eBPF 看内核，但中间有一段它们都看不太清——进程内部、应用框架那一层的语义。比如一次出站的数据库查询，网格看到的是一个到 5432 端口的 TCP 连接，eBPF 看到的是一些字节，但”这是一条 SELECT、查的哪张表”这种框架级语义，得在进程内才看得清。

这正是 OTel 自动仪器化补位的地方——它在进程内拦截框架调用，补上网格和 eBPF 在”应用框架层”的盲区。它要挂 agent，所以不是 100% 零侵入，但仍是零代码改动。

三者如何拼成完整平面

把三者叠起来，就是 Kubernetes 上一张完整的、对应用零代码侵入的可观测性平面：

┌─────────────────────────────────────────────┐
│  自动仪器化（OTel agent）→ 进程内 / 框架层语义   │
├─────────────────────────────────────────────┤
│  服务网格（sidecar/ztunnel）→ 服务之间 / 黄金信号 │
├─────────────────────────────────────────────┤
│  eBPF（Hubble/Pixie）→ 内核 / 网络与系统调用全景  │
└─────────────────────────────────────────────┘
        三层各管一段，应用代码全程一无所知

谁看进程内、谁看服务间、谁看内核——三者分工，拼出一张应用毫不知情的全景图。 这就是”零侵入”在工程上的真实样子：不是一个东西，是三种技术各守一层。

三、零侵入的天花板：技术可见，业务不可见

零侵入听起来近乎完美——白捡的全景可见性。但它有一道根本性的天花板，绕不过去。看清这道天花板，才不会对它抱有错误的期待。

它们看得到的：技术信号

网格和 eBPF，看到的都是技术层面的事实：协议是 HTTP 还是 gRPC、状态码是不是 500、延迟多少毫秒、这个 socket 收发了多少字节、调用了哪个系统调用。这些是通用的、与业务无关的信号——任何系统都有 HTTP 状态码，任何进程都发系统调用。正因为通用，平台才能不懂你的业务就把它们采下来。

它们看不到的：为什么

但恰恰因为它们不懂你的业务，它们答不出最关键的那个字——为什么。

网格能告诉你 POST /checkout 的 500 率从 0.1% 涨到了 8%。但为什么 500？是优惠券校验逻辑有 bug？是某个商品的库存被算成了负数？是新上线的风控规则误杀了一批用户？——这些原因，是业务语义，它们只活在应用的代码和领域概念里。网格看到的是 500，看不到 500 背后那句 if coupon.expired then reject。eBPF 能数清字节，但数不出业务含义。

零侵入采集的是”技术信号”，而很多故障的根因藏在”业务信号”里——这两者之间，隔着一道平台永远跨不过去的墙：平台不懂你的业务。

★ 故障剧场：网格看得见 500，看不见优惠券

把这道天花板演出来。你的结账服务接入了服务网格，黄金信号一应俱全，没写一行可观测性代码。

某天发布后，网格的仪表盘告警：/checkout 的 500 率冲到了 8%。漂亮——零侵入帮你第一时间发现了问题。你打开网格的追踪，看到请求卡在结账服务自己这一跳返回了 500。然后……就没有然后了。网格能告诉你的全部，就是”结账服务在对这些请求返回 500”。至于为什么，它一无所知。

真相是：新版本的优惠券逻辑有个 bug，所有用了某张过期优惠券的请求都会抛异常返回 500。要让可观测性回答出这一点，必须有人在应用代码里，给这个失败埋一个带业务语义的属性——比如在 span 上记一个 checkout.failure_reason="coupon_expired"、coupon.id=...。这一笔，零侵入永远替你做不了，因为”优惠券过期”这个概念，只有你的代码知道。

结论：零侵入不取代手动插桩，是分层

所以这一篇要纠正一个诱人的误解：零侵入不是来取代 OTel 手动插桩的，它们是分层互补的。

• 平台（网格 + eBPF）铺底：零成本地提供技术可见性的全景——黄金信号、网络拓扑、服务依赖。它负责”发现问题”和”定位到哪个服务/哪一跳”。
• 应用（手动插桩）补语义：在关键业务路径上，由开发者补上少量带领域语义的 span 和属性。它负责”理解业务层面的为什么”。

平台铺的是宽而浅的技术底，应用补的是窄而深的业务点。两者加起来，才是既全面、又能回答”为什么”的可观测性。 零侵入降低了门槛，但没有、也不可能消灭”理解你自己业务”这件只有你能做的事。

四、平台化：把可观测性变成默认能力

退一步，从”技术”看到”组织”。零侵入最深远的意义，不在于某种技术多巧妙，而在于它改变了谁来承担可观测性的成本。

谁来承担：从每个团队到平台团队

在零侵入之前，可观测性的负担分散在每个应用团队身上——每个团队各自插桩、各自配置、各自维护。几百个团队，几百份重复的、参差不齐的劳动。

零侵入把这件事集中了：平台团队建好服务网格、部署好 eBPF、搭好数据管道，然后所有应用团队自动获得可观测性——不需要自己动手。这正是 01 那个命题的最后一次、也最大规模的一次落地：把仪器化代价，从”分散在每个团队”转移到”集中在平台团队”。

LGTM 栈：统一交付的可观测性平台

平台团队拿什么把这套东西交付出去？云原生时代沉淀出一套事实标准的组合——LGTM 栈（全部来自 Grafana 生态）：

L — Loki     日志（04 讲过：只索引 label，省钱）
G — Grafana  可视化（统一的查询与展示界面）
T — Tempo    追踪（06 讲过：只按 trace_id 索引，省钱）
M — Mimir    指标（Prometheus 的大规模长期存储）

四个组件覆盖三类信号 + 一个统一界面，作为一套整体部署。加上前面三篇的角色，整张图就完整了：网格/eBPF 零侵入地产出数据 → OTel 统一格式与管道 → LGTM 存储与展示。 平台团队把这一整条链路建好，可观测性就成了公司里像水电一样的默认能力。

数据仍走 OTel

强调一个连贯性：零侵入只是改变了数据怎么被产生（平台代劳，而非应用自插），它产生的数据，依然走 OTel 那套管道——网格和 eBPF 把采集到的信号用 OTLP 吐给 Collector，Collector 处理、治理、扇出到 LGTM。所以零侵入不是 OTel 的替代品，是 OTel 管道的又一种数据来源。09 和 10，是同一条链路的两端。

平台的制度成本：不是免费，是转移

但请务必看清楚：零侵入对应用”免费”，对组织绝不免费。 那笔被”省掉”的成本，没有消失，它转移到了平台团队头上——

• 运维服务网格：sidecar 的资源开销（每个 pod 多一个容器）、控制面的复杂度。
• 维护 eBPF：跟内核版本、处理符号解析、调试那些”在内核里出问题”的疑难杂症。
• 把这一切做成全公司可靠的标准并持续演进。

这是一笔实实在在的制度成本。01 早就说过：可见性没有免费的，你只能选择让谁来付。零侵入的选择是——让平台团队集中地、专业地付这笔账，换来几百个应用团队各自不必再付。 当组织规模足够大时，这笔买卖极其划算；规模不够时，它就是过度投资（下一节）。

五、取舍与边界

网格的代价

服务网格的零侵入不是白来的。Sidecar 模式给每个 pod 注入一个代理，意味着每个 pod 多一份 CPU 和内存开销、每个请求多两次代理跳转的延迟；控制面（管证书、推规则、收遥测）本身也是一套要运维的复杂系统。新一代的 Ambient 模式用 ztunnel 缓解了 sidecar 的部分开销，但复杂度的账依然存在。这套架构的取舍，平台工程 MOC 第 07 篇有完整展开。

eBPF 的代价

eBPF 的零侵入同样有代价：它对内核版本有要求（老内核跑不了新特性）、符号解析在某些语言上很棘手、出了问题在内核层调试远比应用层困难。它强大，但不是没有门槛。它的内核机制——verifier、Maps、安全模型——见 平台工程 MOC 第 06 篇。

规模分水岭

又一次 错配警告：一个十几人、几个服务的团队，上全套服务网格 + eBPF + LGTM，是把平台团队的制度成本，强加给一个根本没有平台团队的组织。对这个规模，几个 Prometheus 指标 + Loki 足够了。零侵入平台化的价值，和你的服务规模、团队数量成正比——它是为”几百个团队”设计的解法，不是为”一个团队”。

内核与网格的机制不在本篇

最后划界：本篇讲的是网格和 eBPF 作为零侵入观测手段的能力与边界。它们自己是怎么工作的——服务网格的控制面/数据面架构、eBPF 在内核的运行原理——那是平台工程的主题，不是可观测性的。完整机制，见 云原生与平台工程 MOC。在这里，它们是观测的工具，不是被观测的主角。

六、小结：坐标与全系列收束

云原生可观测性在五维标尺上的坐标

用 那把尺子给它定位——它把第五根标尺，推到了整个系列的极致：

维度	云原生可观测性的坐标
① 故障预判权	机器事后回答
② 存储汇率	高基数 + LGTM 的省钱存储
③ 信号分工	四类信号统一在一个平台平面上
④ 注意力阀门	复用 SLO
⑤ 仪器化负担	对应用归零——负担彻底转移到平台

第⑤维到此被推到了尽头：仪器化对应用而言，成本为零。这条从 手写检查项一路下沉的标尺，到这里走完了全程。

全系列收束：天平的完整旅程

十篇文章走完了。现在回头，那架天平从经典到云原生的整段迁移，可以一图看尽：

维度	经典范式（02-04）	→	云原生范式（05-10）
① 故障预判权	人预判	→	机器事后回答
② 存储汇率	预聚合、省存储	→	高基数、留下一切
③ 信号分工	布尔 → 数字 → 事件	→	因果 + 代码 + 统一宽事件
④ 注意力阀门	基于原因拍阈值	→	基于症状按 burn rate 分级
⑤ 仪器化负担	手写	→	自动 → 标准化 → 对应用归零

五根标尺，从整体偏向”资源端”，迁移到了整体偏向”提问端”。 这就是 01 那个论题的完整证明——监控、指标、日志、可观测性、追踪、持续分析、SLO、OTel、零侵入，它们不是九种孤立的技术，是同一架天平、在存储变便宜、系统变复杂、人变贵的汇率漂移下，一格一格挪到另一端的连续轨迹。

而驱动这次迁移的，始终是那个不变的命题：运维，是在人与资源之间持续校准。 经典时代资源贵，于是省机器、靠人预判；云原生时代资源贱、人贵、系统繁，于是存下一切、让机器事后回答、把仪器化负担甩给平台。技术换了一茬又一茬，校准这件事本身，从未改变。

故事没完：技术线索的尽头是平台

但请注意上一节那张完整旅程图——它讲的全是”机器如何被看见”。这只是故事的一半。

技术线索的尽头是平台化，可这恰恰引出了另一半被技术叙事遮蔽的东西：这套昂贵的可见性，谁来买单？半夜被它叫醒的人，过得好吗？当机器开始自己协调这一切（AIOps），又会发生什么？ 这些问题，五维标尺答不了——它们属于”人与经济”和”未来”。

• 运维的人与经济：on-call 的人本代价、告警疲劳、遥测成本治理——见 MOC 第五节。它是”人与资源”命题落到组织和账单上的现实回响。
• 前沿雷达 2026：AIOps、成本反噬、WASM 观测——见 MOC 第六节。当人贵到极致、资源开始反噬，这架天平会被推向何方。

十篇文章，画完了那架天平在技术维度上的完整旅程。但运维工程真正的全貌，是技术、人、经济三者的合力。读完这十篇，你掌握了那把尺子；而把尺子用在你自己的系统上、在你自己的汇率里做出判断——那是这套知识真正开始有用的地方。

返回 可观测性与运维工程 MOC ｜ 上一篇 09-OpenTelemetry-三个信号的统一语言 ｜ 全系列完