知识花园

最近更新

可观测性与运维工程 MOC

40分钟阅读

可观测性与运维工程

一个服务变慢了。你打开监控仪表盘：CPU 正常，内存正常，错误率正常。但用户在投诉。

你看着一屏绿色的图表，不知道哪里出了问题。

这是运维工程的核心困境：一个足够复杂的系统，你永远无法”读完它”。你只能通过它主动发出或被动暴露的信号来推断内部状态。但信号不是免费的——每一条指标要存储，每一次告警要打断一个人，每一行仪器化代码要有人来写。

于是真正的问题浮现出来：运维工程的本质，是在”人的注意力”和”机器的资源”这两种稀缺品之间持续校准。 你花多少存储，换多少可见性；你花多少人力，换多少自动化；你在什么时候，才值得叫醒一个工程师。监控、可观测性、SLO、eBPF——所有这些技术，都只是这场校准在不同时代、不同汇率下的成交价。

这个判断是整个系列的地基，单独成篇放在最前面（01-运维的本质-在人与资源之间持续校准）。理解了这个不变的内核，后面三个时代就不再是孤立的工具清单，而是同一个命题的三次重新作答：

  • 经典范式（资源受限的过去）：存储和算力贵、人相对便宜，于是让人去预判故障（预先埋点），让机器省着用（预聚合、阈值告警）。监控、指标、日志，都是这个取舍的产物。
  • 云原生范式（繁盛的现在）：存储变便宜、系统变分布式、人变贵，于是反过来——让机器存下一切（高基数、wide events），把人从预判中解放出来（事后任意提问）。可观测性、追踪、持续分析、SLO、OpenTelemetry，都是这一跳的具象化。
  • 未来范式（推测的方向）：人极贵、资源充裕但成本开始反噬，于是让机器自己协调（AIOps），代价是诞生新的稀缺——成本治理。这部分尚未尘埃落定，放在第六节的雷达里。

这个系列不预设哪代更好。规模不同，汇率不同，答案不同：一个百人团队运营的产品，Prometheus + Alertmanager + Grafana + Loki 完全够用，引入分布式追踪只会增加运维负担；一个日均千亿次服务调用的平台，不用追踪根本无法定位跨服务的性能退化。错配的代价很高——小系统过度投资可观测性，大系统只用监控，都会出问题。

每篇文章不止讲”这个产品怎么用”，还设了一个故障剧场：亲手把它弄坏，看信号如何暴露真相、或如何沉默。可观测性的哲学你读十遍，不如亲手把一条高基数维度从指标里抹掉、再眼睁睁看着自己问不出”哪 1% 的请求慢了”一次——“预聚合的代价”只有在你撞上它时，才会变成判断力。

一、目录

本系列共 10 篇文章。第一篇是统领全系列的思想总论；其余九篇沿历史展开，分两个实体时代——经典范式（02-04，稳定的过去）、云原生范式（05-10，繁盛的现在）。未来不单独成篇，由第六节”前沿雷达”承担。

70-operations/
├── 00-operations-MOC.md                          ← 本文件
│
│  【思想总论 · 统领全系列】
├── 01-运维的本质 - 在人与资源之间持续校准.md        ← 人与资源 / 五个永恒命题
│
│  【经典范式 · 资源受限的过去】
├── 02-监控 - 预知故障的经典范式.md                  ← Nagios / Zabbix / 阈值告警
├── 03-指标 - 时间序列的量化哲学.md                  ← Prometheus / RED·USE / PromQL
├── 04-日志 - 结构化事件的叙事力量.md                ← ELK / Loki / 结构化日志
│
│  【云原生范式 · 繁盛的现在】
│   ├ 信号的扩张
├── 05-可观测性 - 从已知失败到任意提问.md            ← 高基数 / wide events / 探索式分析
├── 06-分布式追踪 - 因果链的精确重建.md              ← Jaeger / Tempo / 采样策略
├── 07-持续分析 - 时间花在哪里的第四类信号.md        ← Continuous Profiling / Parca / 火焰图
│   └ 工程化与标准化
├── 08-SLO-把可靠性变成数学.md                    ← SLI·SLO·SLA / error budget / burn rate
├── 09-OpenTelemetry-三个信号的统一语言.md        ← OTel Collector / OTLP / Exemplar
├── 10-云原生可观测性 - 零侵入是如何做到的.md        ← 服务网格遥测 / eBPF 观测 / LGTM 栈
│
│  【实践伴侣】
└── 11-可观测性工程实验台.md                        ← 实践伴侣 / 给平台"装上眼睛" / 四方案 · 故障剧场

另有两节不对应独立文章，是贯穿全系列的横切维度： 第五节 运维的人与经济 —— on-call / 告警疲劳 / 遥测成本治理（“人与资源”命题在组织和钱上的落地）。 第六节 前沿雷达 2026 —— AIOps / 成本反噬 / WASM 观测（仍在流动的未来方向）。

二、思想总论：运维在协调人与资源

这是整套系列的脊椎。无论经典、云原生还是 AI 时代，运维要回答的核心问题不变——一个你无法读完的系统，你怎么知道它健康、出问题怎么理解它？ 围绕它衍生的五个永恒命题也不变，变的只是每个时代给出的答案。 完整论述见 01-运维的本质-在人与资源之间持续校准；下面是导航速览。

mindmap
  root((运维工程))
    思想内核
      本质 协调人与资源
      已知vs未知 谁来兜底故障
      预聚合vs高基数 存储换提问
      信号的层次 各买一种洞察
      告警的人本成本 注意力最贵
      仪器化的代价 让系统开口
    经典范式 资源受限
      监控 预知故障
      指标 时间序列量化
      日志 结构化事件叙事
    云原生范式 新取舍
      可观测性 任意提问
      分布式追踪 因果链重建
      持续分析 第四类信号
      SLO 可靠性数学化
      OpenTelemetry 三信号统一
      云原生栈 零侵入遥测
    人与经济
      oncall与告警疲劳
      遥测成本治理
    前沿2026
      AIOps
      成本反噬
      WASM观测

五个永恒命题（每个时代都在用不同产品作答，详见 01-运维的本质-在人与资源之间持续校准）：

  • 命题一：已知 vs 未知故障 —— 用人的预判力（预先埋点）还是机器的存储力（事后提问）来兜底故障。经典选前者，云原生选后者。
  • 命题二：预聚合 vs 高基数 —— 花多少存储资源，换多少提问自由。指标在数据落盘前就丢掉了细节，换来极低成本；追踪保留每条请求，换来任意提问的能力。
  • 命题三：信号的层次 —— 指标回答”多少”、日志回答”发生了什么”、追踪回答”为什么”、持续分析回答”时间花在哪里”。每类信号是一笔资源支出，买一种特定洞察，没有哪种全能。
  • 命题四：告警的人本成本 —— 人的注意力是最贵的资源。从”CPU 超 90% 就告警”到”SLO 烧损速率超阈值才告警”，是把告警的紧迫度精确对应到用户影响。衡量告警质量的不是数量，是 actionable rate。
  • 命题五：仪器化的代价 —— 让系统”开口说话”要付出人力与开销。演进方向是成本越来越低、覆盖越来越广：手写 SDK → 框架自动注入 → 内核零侵入。

这条脊椎的意义：后面每一篇文章，读到最后都可以回扣同一个问题——这一步，把人与资源的天平推向了哪一边？ 这是十篇文章共享同一根骨架、而非各讲各话的保证。

三、经典范式：资源受限时代的取舍

这个时代如何作答五命题？ 存储和算力贵（命题二偏向预聚合），于是只能让人预先判断哪里会坏（命题一偏向人的预判），把宝贵的资源花在已知风险点上。这不是落后，是那个资源约束下的最优解——今天在中小规模系统里依然成立。

起点：监控——预知故障的经典范式

核心问题：Nagios / Zabbix 的设计哲学是什么？它们在什么场景下是最优解，在什么场景下开始失效？ 读完之后：理解 agent-based 架构、SNMP、主动/被动检查、阈值告警，理解”预知失败”范式的边界在哪里。 ★ 故障剧场：搭一个 Nagios 检查，制造一次它没预设的故障模式（比如一个不在检查清单里的依赖挂了），看它对着一屏绿色保持沉默——“只能发现你预先知道的故障”第一次具象化。

  • 02-监控-预知故障的经典范式 — Nagios/Zabbix 架构、agent 模型、服务检查、阈值告警 核心问题：一个检查从发现问题到触发告警通知，中间经历了哪些步骤？为什么这个模型在大规模分布式系统里开始失效？ 天平推向：让人预判、让机器省——以人的先见之明，换机器资源的节约。 关联：→ 03-指标-时间序列的量化哲学（指标是对阈值告警的升级，但共享”预知失败”的假设）→ 05-可观测性-从已知失败到任意提问（可观测性是对整个范式的替代，跨时代的那一跳）

信号一：指标——时间序列的量化哲学

核心问题：时间序列数据模型的本质是什么？Prometheus 的 pull 模型和 push 模型各有什么取舍？RED 方法和 USE 方法适用于什么类型的组件？ 读完之后：理解 counter / gauge / histogram / summary 四种类型，理解 PromQL 的查询模型，理解如何用指标定义 SLO 并设计告警规则。 ★ 故障剧场：给一个指标加一个高基数 label（比如 user_id），看 Prometheus 的内存如何爆炸——亲手撞上”预聚合的边界”，理解它为什么便宜、又为什么问不出请求级的问题。

信号二：日志——结构化事件的叙事力量

核心问题：结构化日志和非结构化日志的本质区别是什么？日志级别应该如何设计？Loki 的标签索引模型和 Elasticsearch 的全文索引模型，各自在什么场景下更合适？ 读完之后：理解日志作为”事件流”的设计哲学（12-factor app），理解结构化日志的字段设计，理解日志聚合的管道架构（Promtail/Fluentd → Loki/ES）。 ★ 故障剧场：把同一个故障分别用 printf 文本日志和 JSON 结构化日志记一遍，再尝试聚合分析”过去一小时哪个 user_id 失败最多”——文本版的无能为力，就是结构化的理由。

四、云原生范式：分布式时代的新取舍

这个时代如何作答五命题？ 存储变便宜、系统变成几十上百个微服务、人的认知带宽相对更稀缺——汇率彻底翻转。命题二偏向高基数（存得起原始事件），命题一偏向机器的存储力（不再预判、事后提问），于是诞生了一整套新产品。本节分两层：先是信号的扩张（可观测性/追踪/持续分析把”能看见什么”推到极限），再是工程化与标准化（SLO/OTel/云原生栈把这些能力变成可治理、可迁移、零侵入的基础设施）。

范式转变：可观测性——从已知失败到任意提问

核心问题：为什么分布式系统让监控范式失效？“可被任意提问”意味着什么，技术上需要什么前提？（这一篇承接 01 的元命题，落到”这一次具体变成了什么”——01 讲”为什么会变”，本篇讲”变成了什么”。） 读完之后：理解高基数（high cardinality）和高维度（high dimensionality）为什么是可观测性的核心概念，理解 Honeycomb 的 wide events 模型与 Prometheus 时间序列模型的根本差异。 ★ 故障剧场：制造一个”涌现式”故障——每个组件都正常，但特定组合下整体异常——用指标怎么也定位不到，再用一次 wide events 的探索式下钻问出真相，亲历两代范式的能力鸿沟。

信号三：分布式追踪——因果链的精确重建

核心问题：trace context 是如何在跨进程调用中传播的？采样策略（头部采样 vs 尾部采样）对追踪系统架构有什么影响？为什么追踪无法完全替代指标？ 读完之后：理解 span / trace / context propagation 的数据模型，理解 Jaeger / Tempo 的存储架构，理解采样率对追踪系统成本和完整性的影响。 ★ 故障剧场：在一条跨服务调用链里故意漏传一次 trace context，看追踪在那一跳断裂、因果链残缺——“上下文传播”这件最容易被忽视的事，正是追踪成立的前提。

信号四：持续分析——时间花在哪里

核心问题：持续分析（Continuous Profiling）和追踪、指标的区别是什么？eBPF 如何在不修改应用的情况下采集 CPU 火焰图？Parca 和 Pyroscope 的存储模型有什么差异？ 读完之后：理解 on-CPU / off-CPU profiling 的区别，理解 eBPF perf event 采样的工作原理，理解持续分析如何定位”监控发现异常但追踪找不到原因”的盲区。 ★ 故障剧场：制造一个”每跳 span 都正常、但 P99 升高”的退化（某个函数被高频调用），用追踪一无所获，再用持续分析的火焰图一眼定位到热点函数——这就是第四类信号填补的盲区。

工程化：SLO——把可靠性变成数学

核心问题：SLI、SLO、SLA 三者的关系和区别是什么？error budget 怎么把”可靠性”从感性判断变成可协商的工程资源？为什么 SLO 告警比阈值告警更准确？ 读完之后：理解如何为服务定义有意义的 SLI，理解 error budget burn rate 的计算方式，理解多窗口告警规则的设计逻辑（1h + 6h 窗口组合）。 ★ 故障剧场：给一个服务配一组”基于原因”的阈值告警和一组”基于症状”的 SLO burn rate 告警，制造一次 CPU 飙高但用户无感的事件，看前者误报、后者沉默——亲历命题四”何时才值得叫醒人”的分野。

标准化：OpenTelemetry——三个信号的统一语言

核心问题：OpenTelemetry 解决的是”仪器化”问题还是”后端”问题？Collector 在 OTel 架构里的作用是什么？OTLP 协议相比 Prometheus scrape 有什么本质差异？ 读完之后：理解 OTel 的四层架构（API / SDK / Collector / Exporter），理解 Collector 作为可观测性管道的作用，理解 Exemplar 如何连接指标和追踪，理解 OTel 在仪器化锁定问题上的战略意义。 ★ 故障剧场：用 OTel SDK 仪器化一个服务，然后只改 Collector 配置、不动一行应用代码，把数据从 Jaeger 切到 Tempo、从 Prometheus 切到别的后端——亲手验证”一次仪器化，永远可迁移”。

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

核心问题：当可观测性下沉成平台的”默认能力”，零侵入到底靠什么实现？服务网格、eBPF、自动仪器化各自能看到什么、看不到什么？LGTM 栈如何把指标/日志/追踪统一成一套部署？ 读完之后：理解服务网格在代理层零代码采集黄金信号、eBPF 在内核路径捕获网络与系统调用、自动仪器化拦截框架层——三种零侵入手段的能力边界，以及它们如何在 Kubernetes 上拼成完整的可观测性平面。 ★ 故障剧场：在一个网格里关掉应用自身的任何埋点，只靠 sidecar/eBPF 采集，看黄金信号（延迟、流量、错误、饱和度）依然齐全——再问一个服务内部的业务问题，看零侵入的盲区在哪里现形。

五、运维的人与经济：技术叙事遮蔽的另一半

前面九篇讲”机器如何被看见”，这一维讲”人如何被对待、钱如何被花掉”。它不是附录——它正是第二节”人与资源”命题落到组织和成本上的现实。技术线索的尽头是信号，人与经济线索的尽头是：谁来为这套可见性买单、谁在半夜被它叫醒。

  • on-call 是把可靠性翻译成人的代价：一套漂亮的告警体系，最终兑现为某个工程师的睡眠。on-call 设计（轮值、升级、降噪）的本质，是在”系统的可靠性”和”人的可持续性”之间校准——这正是命题四在组织层面的样子。
  • 告警疲劳：告警太多等于没有告警。工程师习惯性 silence，真正的故障被淹没。衡量告警质量的不是数量，是 actionable rate——每次告警都应该需要且值得人类处理。从”基于原因”到”基于症状（SLO）“的升级（见 08-SLO-把可靠性变成数学），本质是为了提高这个比率。
  • 遥测成本治理：可观测性的隐性账单。高基数和长保留期是真金白银——一个失控的 label、一份全量采样的追踪、一套永不过期的日志，能让可观测性的账单超过它所监控的服务。“存得起一切”不等于”该存一切”；采样、保留期分级、Collector 端的过滤与降采样，是这个时代新的纪律。对应 云原生与平台工程 MOC 的 FinOps 维度——声明式让”要多少”太容易，于是”花多少”太隐蔽。

这条线索的终点：云原生给了你”看见一切”的能力，但没给你为这份可见性买单、也没给你保护被它叫醒的人的纪律。可观测性的成熟，不在于你能看见多少，而在于你为”看见”付出的人力与金钱，是否还配得上它带来的洞察。

六、前沿雷达 2026：仍在流动的未来范式

前五节是已经落地的现在与过去。以下是正在发生、尚未尘埃落定的方向——它们都在回答同一个问题”当人比任何时候都贵、资源比任何时候都充裕（但开始反噬）时，这场校准会走向哪里”。未来可能各自成篇。

  • AIOps：让机器接手协调本身。基于 ML 的异常检测、告警降噪、根因定位自动化——试图把命题四（何时叫醒人）从规则判断升级为模型判断。诚实地说：当前工程成熟度参差，误报与不可解释性仍是主要障碍，离”可信赖的自动根因”还有距离。但方向明确——人贵到一定程度，协调权必然部分让渡给机器。
  • 成本反噬成为一等约束。可观测性数据量的增速开始超过业务本身，“遥测比业务还贵”不再是笑话。预计未来的可观测性平台会把成本作为内建维度（按价值采样、自适应保留期），而不是事后治理。对应第五节的遥测成本治理。
  • WASM / eBPF 把仪器化推向新边界。eBPF 已让零侵入观测成为现实（见 10-云原生可观测性-零侵入是如何做到的）；WASM 作为更轻、更可移植的执行单元，可能让”在数据产生的地方就地处理遥测”成为常态，进一步压低仪器化代价。
  • OpenTelemetry 收敛为唯一标准。Profiling 信号正式纳入 OTel、Collector 成为事实上的遥测数据平面——命题五”仪器化代价”的演进正在定局：一次仪器化、所有信号、所有后端。对应 09-OpenTelemetry-三个信号的统一语言。

这条线索的终点：观察这四个方向有一个统一视角——它们都在把”人与资源的校准”这件事，从人工配置推向系统自治。答案不是”运维消失”，是运维的重心从”配置信号”上移到”治理这套自治系统的成本与可信度”。

七、按场景的阅读路径

不同目的的人，从不同的地方开始。但所有路径都建议先读 01-运维的本质-在人与资源之间持续校准——它是理解后面一切取舍的钥匙。

路径一：第一次系统学可观测性

从思想到历史，建立完整的认识论：

01（思想：运维在协调什么）
  → 02（监控：经典范式的逻辑）
  → 03（指标：量化系统行为）
  → 04（日志：结构化事件）
  → 05（可观测性：范式转变）
  → 06（追踪：分布式系统的新工具）
  → 08（SLO：可靠性的数学化）

路径二：运维 / SRE 工程师

关注告警、可靠性和人的代价：

01（思想：人与资源的命题）
  → 03（指标和告警：日常运维基础）
  → 08（SLO：把告警从阈值升级到症状）
  → 04（日志：故障排查的叙事工具）
  → 05/06（可观测性与追踪：分布式排查）
  → 第五节（运维的人与经济：on-call 与告警疲劳）

路径三：后端开发者（理解系统 / 仪器化）

关注如何让自己的服务被看见：

01（思想：仪器化的代价从哪来）
  → 03（指标：给服务定义 RED 指标）
  → 04（日志：设计结构化日志）
  → 06（追踪：理解跨服务调用）
  → 07（持续分析：定位代码热点）
  → 09（OTel：一次仪器化，后端自由）

路径四：关注新技术方向

关注可观测性的演进前沿：

05（可观测性哲学：理解为什么）
  → 09（OpenTelemetry：信号统一标准）
  → 10（云原生可观测性：零侵入的实现）
  → 07（持续分析：eBPF 第四类信号）
  → 第六节（前沿雷达：AIOps 与成本反噬）

路径五：正在选型（Prometheus 还是 OTel？ELK 还是 Loki？）

01（思想：你的规模决定汇率，先想清楚再选型）
  → 02（监控：Nagios/Zabbix 的适用场景）
  → 03（指标：Prometheus 生态的完整形态）
  → 04（日志：ELK vs Loki 的存储哲学差异）
  → 09（OTel：为什么是长期正确的仪器化选择）
  → 05（可观测性：你的系统规模是否真的需要它）

八、延伸方向

这个系列聚焦于可观测性与运维工程的核心思想与技术形态。以下方向与本系列相关，但各自构成独立的学习领域：

  • 可靠性工程的组织实践（SRE）：事故管理、复盘（postmortem）文化、混沌工程——本系列第五节触及了 on-call 与告警的人本维度，但完整的组织级工程实践见 Google SRE Book 和 SRE Workbook。

  • 云原生可观测性基础设施部署：Kubernetes 上的 Prometheus Operator、Grafana Stack（Loki + Tempo + Mimir）、OTel Operator 的运维——这是平台工程的职责，见 云原生与平台工程 MOC。这套被观测的平台本身怎么”造”出来（容器 → k3s → GitOps → eBPF），见 10-云原生工程实验台——它是本系列 11-可观测性工程实验台 的上游：10 造平台，11 观测同一个平台；两者共用的机器底座由 Terraform 声明，见 09-实验台云底座。

  • eBPF 的内核机制：本系列第 07、10 篇讲 eBPF 作为可观测性手段，其内核原理（verifier、Maps、XDP）和 Cilium/Tetragon 的完整架构见 云原生与平台工程 MOC 第 06 篇。

  • Linux 系统工具基础：perf、ftrace、strace 的内核原理，eBPF 建立的 Linux 基础，见 Linux 系统 MOC。

  • 架构质量属性：SLO 是架构设计的可靠性约束，架构决策（微服务拆分粒度、事件驱动边界）直接影响可观测性代价，见 软件工程与架构 MOC。

  • 安全可观测性：安全事件检测、异常行为分析（SIEM）是安全与可观测性的交叉地带，见 安全工程 MOC。

关系图谱

反向链接