一句话总结
可观测性(Observability)不是"部署一套监控系统",而是一种能力:仅凭系统对外输出的数据(指标,日志,追踪),回答关于系统内部状态的任意问题--尤其是上线时未曾预料到的问题.
本篇建立全局认知地图,后续七篇均围绕此框架展开.
从一个凌晨三点的告警说起
告警消息只有一行:"下单接口 P99 延迟超过 2 秒".系统由十几个微服务组成,调用链路如下:
|
延迟的根因可能存在于任何一个环节:某个服务实例发生 GC 停顿,Redis 连接池耗尽,第三方支付 API 响应异常,某条 SQL 突然走了全表扫描,上游新版本引入了 N+1 查询--可能性有几十种.
在单体架构时代,运维人员通过 SSH 登录唯一的生产服务器,查看日志和系统指标,通常能够定位问题.但在微服务架构下,一次请求跨越十几个进程,多台机器,多个数据库,没有任何一个节点能够展现全貌.这正是可观测性所要解决的根本问题--分布式系统天然不透明,而故障不会提前通知.
这个排障场景会贯穿整个系列
"下单接口变慢了"这个案例会在后续篇章中反复使用:第 02-03 篇用指标发现并量化延迟,第 06-07 篇用追踪定位到具体服务与具体调用跳,第 04-05 篇用日志查明该跳内部发生了什么,第 08 篇将三者串联为一次完整的故障定位流程.
建议带着这个场景阅读后续内容.
监控与可观测性的本质区别
"可观测性"常被视为"监控"的升级版称呼.二者确实相关,但存在一个本质区别,理解这一区别是掌握整个主题的前提.
| 监控(Monitoring) | 可观测性(Observability) | |
|---|---|---|
| 回答的问题 | "预设要观测的那些指标,当前状态如何?" | "这个未曾预料的现象,为什么会发生?" |
| 面向 | 已知的故障模式(CPU,内存,QPS) | 未知的,新出现的故障模式 |
| 前提 | 需要提前确定观测目标并配置仪表盘 | 能够在事后自由探索数据,提出新问题 |
| 类比 | 汽车仪表盘上固定的几个表盘 | 能够拆解引擎,对任意部件连接探针进行检测 |
一个经典的区分维度来自以下两类问题:
- 已知的未知(Known Unknowns):知道某个环节可能出问题,因此提前监控它.例如"CPU 使用率可能过高",于是配置了 CPU 告警.这是监控的领域.
- 未知的未知(Unknown Unknowns):事先完全无法预见的故障.例如"仅在华东区域,Android 客户端,购物车超过 8 件商品的用户,下单才会偶发超时"--这种特定条件组合,没有人会提前为其配置仪表盘.这是可观测性的领域.
监控如同体检套餐:固定检查血压,血糖等若干指标,针对的是已知需要预防的疾病.
可观测性如同配备了一套能够检测任意指标的设备,且保留足够详尽的病历:当出现套餐之外的异常症状时,医生能够现场提出新假设,调取相关数据验证--即使该症状此前从未见过.
这一术语借自控制论(Cybernetics):一个系统被称为"可观测的",是指能否通过其外部输出推断其内部状态.映射到软件领域--服务对外输出的指标,日志,追踪数据,是否足够丰富,使得运维者能够反推出"系统内部到底发生了什么".
重点在于"反推任意问题的能力",而非"输出了多少数据".积累大量无人查看的仪表盘,并不等同于具备了可观测性.
三大支柱:指标,日志,追踪
可观测性数据通常归为三类信号,业界称为"三大支柱(Three Pillars)".它们并非三个孤立的工具,而是观察同一系统的三个互补视角.下表概括了每个支柱的定位--这是本系列最重要的框架性总结:
| 支柱 | 回答的问题 | 本质 | 排障中的角色 |
|---|---|---|---|
| 指标 Metrics | 系统当前是否健康? | 按时间聚合的数值(可计算,可告警) | 发现:"出事了" |
| 追踪 Traces | 本次延迟/错误发生在哪一环节? | 一次请求跨服务的完整调用路径 | 定位:"在这里" |
| 日志 Logs | 该环节内部具体发生了什么? | 离散的,带时间戳的事件记录 | 归因:"因为这个" |
排障主线:发现 → 定位 → 归因
回到凌晨三点的告警场景:指标显示"下单 P99 延迟飙升至 2 秒"(发现);追踪揭示"慢在调用支付服务那一跳,耗时 1.8 秒"(定位);日志记录"支付服务正在重试第三方 API,对方返回了 429 限流状态码"(归因).
三步完成,根因明确.这条主线是后续所有篇章的组织骨架.
指标:低成本,全局视野,但缺乏细节
指标是数值:QPS,错误率,延迟,CPU 使用率等.它们按时间聚合存储,因此开销低且查询高效--存储一年的 QPS 曲线数据也只需要很小的空间.代价是缺乏上下文:指标能告诉你"错误率 5%",但无法回答"哪些请求出错了,为什么出错".
追踪:呈现一次请求的完整路径
追踪记录一次请求在分布式系统中流经的所有服务,以及每个调用跳的耗时.它直接应对"分布式系统无法看到全貌"这一痛点--将散落在十几个服务中的片段,拼接为一条完整的时间线.追踪是连接"全局指标"与"局部日志"的桥梁.
日志:细节最丰富,但成本最高也最杂乱
日志是事件的文本记录,细节最为丰富--能够记录具体的错误堆栈,参数和中间状态.但它也最笨重:海量,非结构化,检索慢,存储成本高.日志适合在已经"缩小了排查范围"之后,用于回答最终那个"为什么".
将数据割裂为三套独立系统(三套工具,三份存储,三种查询语言),会导致排障时在工具之间反复切换,依赖人工进行关联.
更现代的观点(以 Honeycomb 为代表)主张以高基数(High Cardinality)的结构化事件作为统一数据底座,指标和追踪均可由事件派生.本系列仍以三支柱为主线进行讲解(因其最易于入门,生态最成熟),但需要了解:三支柱是当前的工程现实,而非理论终点.第 08 篇将讨论如何将三者关联起来,正是为了缓解这种割裂带来的问题.
为什么是现在:从单体到微服务的必然趋势
可观测性并非凭空出现的概念,而是被架构演进推动产生的需求:
- 单体时代:一个进程,一台机器,日志集中,调用均在进程内完成.出问题时 SSH 登录后基本可以查清.
- 微服务时代:请求横跨十几个服务,几十个实例,实例还随时被 Kubernetes 调度漂移(回顾 Kubernetes 笔记:Pod 是短暂的).任何单个节点只能看到拼图的一小块.
架构将系统拆散,可观测性的任务就是在数据层面将其重新组合为一个可理解的完整视图.微服务,容器,动态调度越普及,可观测性就越是必要的基础能力而非可选项.
本系列的学习地图
基于上述框架,整个学习路线如下.八篇笔记的组织结构:
|
阅读顺序(先 Metrics,再 Logs,最后 Traces + 整合)与实战排障顺序(发现→定位→归因,即指标→追踪→日志)并不相同:阅读按由易到难编排(指标最简单,追踪概念最重),排障按信号的因果链展开.将这两个顺序分开理解,后续便不会困惑.
快速回顾
- 可观测性的定义:仅凭外部输出反推内部状态,回答任意(尤其是预料之外)问题的能力--重点是"能力",而非"部署了多少工具"
- 与监控的区别:监控应对"已知的未知"(预设要观测的指标),可观测性应对"未知的未知"(事先无法预见的故障模式)
- 三大支柱及其排障角色:指标 → 发现"出事了",追踪 → 定位"在哪个环节",日志 → 归因"根本原因是什么"
- 三者的取舍:指标成本低,全局视角但无细节;日志细节最丰富但成本最高,最杂乱;追踪连接全局与局部
- 三支柱框架的局限:数据割裂导致工具间频繁切换,现代趋势是以高基数结构化事件统一底座,但三支柱仍是当前工程现实
- 时代背景:微服务架构将系统拆散,可观测性负责在数据层面将其重新组合为可理解的整体
项目仍为单体架构,是否需要可观测性?
需要,但优先级和投入可以适度降低.单体应用同样会面临"为什么某个接口偶尔变慢""这次报错的根因是什么"等问题,指标和结构化日志(第 02-05 篇)对单体应用同样有价值.分布式追踪(第 06-07 篇)的收益随服务数量增长而提升--单体应用内部调用均在同一进程内,追踪价值有限.按照架构复杂度匹配投入,不必一开始就追求全套方案.
可观测性与 APM(Application Performance Monitoring)是同一概念吗?
有交集但不等同.APM 是更早出现的品类,既有商业产品(New Relic,AppDynamics,Dynatrace)也有开源方案(如 Apache SkyWalking),侧重应用性能(响应时间,慢调用,依赖分析),通常打包了追踪功能和部分指标.可观测性是更宽的理念,涵盖三大支柱,强调"探索未知问题的能力",且更倾向开放标准(OpenTelemetry,见第 06 篇)而非绑定单一厂商方案.可以将现代 APM 视为可观测性的一个子集或落地形态.
动手练习
- 复盘一次线上故障:回顾经历过的一次线上故障,判断它属于"已知的未知"(本可提前监控)还是"未知的未知"(事先无法预见)?当时是通过指标,日志还是追踪定位的?
- 梳理当前可观测性现状:针对负责的某个服务,分别梳理:当前有哪些指标?日志是否为结构化格式?是否有追踪?哪一支柱最为薄弱?
- 用三步主线复盘:用本篇的"发现→定位→归因"主线复盘该次故障:如果三支柱齐备,理想的排障路径应该是怎样的三步?
- 审视无用仪表盘:找一个团队中"无人查看的仪表盘",分析:它属于监控还是可观测性的范畴?它是否真正帮助回答过问题?这有助于理解"数据多 ≠ 可观测"的含义.