一、可观测性概述：什么是可观测性、三大支柱、与传统监控的区别
大家好，我是你们的老朋友。今天咱们聊聊可观测性这个热门话题。
说实话，我刚入行那会儿，压根没听过这个词。那时候大家聊的都是监控——Zabbix、Nagios、Prometheus 早期版本。但这些年，系统越来越复杂，微服务一拆就是几十上百个，光靠监控已经不够用了。
可观测性，说白了就是——你能从系统外部，推断出系统内部到底发生了什么。不需要你登录机器，不需要你打断业务，光靠系统吐出来的数据，就能定位问题。
嗯，这里要注意：可观测性不是某个工具，而是一种能力。
1.1 什么是可观测性
这个概念最早来自控制理论。一个系统是可观测的，意味着你可以通过它的输出，反推出它的内部状态。
放到云原生环境里，意思就是：你的应用能不能让你问出“为什么”。
举个例子：
- 用户说“页面加载慢” —— 你能回答“慢在哪一步”吗？
- 半夜报警说“错误率飙升” —— 你能回答“是哪个服务、哪个版本、哪个用户群体”吗？
- 上线新功能后 —— 你能回答“对下游依赖的影响”吗？
如果都能，恭喜你，你的系统具备可观测性。如果不行，那你只是在“看监控数字”而已。
核心观点：可观测性 = 你能在不预知问题的情况下，快速找到根因。它不是“我提前配好了告警”，而是“我随时能问系统任何问题”。
1.2 三大支柱：日志、指标、链路追踪
聊可观测性，绕不开这三大件。我习惯把它们比作侦探破案的工具：
- 日志 —— 案发现场的详细记录。谁、什么时间、做了什么、结果如何。
- 指标 —— 案发地点的统计数据。每分钟多少人经过、平均响应时间、错误率。
- 链路追踪 —— 嫌疑人的行动路线。从进门到出门，每一步花了多久，在哪停留了。
三者缺一不可。光有日志，你在大海里捞针；光有指标，你知道出事了但不知道哪出的；光有链路，你看到路径但不知道具体细节。
日志（Logs）
日志是最传统的手段。每一行日志，记录了一个离散的事件。
我个人习惯把日志分成三个级别：
- 结构化日志 —— JSON 格式，带时间戳、级别、请求ID、业务字段。方便机器解析。
- 上下文日志 —— 带上 trace_id、span_id，能和链路关联起来。
- 采样日志 —— 高流量场景下，全量日志成本太高，按规则采样。
避坑指南：我曾经在一个高并发项目里，日志打得太随意，结果磁盘写满，服务直接挂了。后来我强制要求：所有日志必须带级别，ERROR 级别必须告警，DEBUG 级别默认关闭。嗯，血的教训。
指标（Metrics）
指标是聚合后的数据。它告诉你“现在怎么样”，但不告诉你“为什么”。
常见的指标类型：
- 计数器（Counter） —— 只增不减，比如请求总数、错误总数。
- 仪表盘（Gauge） —— 可增可减，比如当前连接数、内存使用率。
- 直方图（Histogram） —— 分布统计，比如请求延迟的 P50、P99。
你想想看，指标最大的好处是什么？存储成本低，查询速度快。Prometheus 就是靠这个吃饭的。
链路追踪（Tracing）
这是微服务时代的刚需。一个请求经过 A、B、C、D 四个服务，每个服务花了多少时间？哪一步最慢？
链路追踪的核心概念：
- Trace —— 一次完整的请求，从入口到出口。
- Span —— Trace 里的一个步骤，比如“调用服务B”。
- Context Propagation —— 上下文传播，把 trace_id 透传到每个服务。
我记得有一次线上故障，用户反馈下单特别慢。指标看 CPU、内存都正常，日志也没报错。最后靠链路追踪发现，是某个下游服务的 Redis 连接池满了，请求在排队。没有链路，这问题得排查半天。
1.3 与传统监控的区别
很多人问我：可观测性和监控到底有啥区别？
我一般这么回答：监控是“我知道我会遇到什么问题”，可观测性是“我不知道我会遇到什么问题”。
| 维度 | 传统监控 | 可观测性 |
|---|---|---|
| 目标 | 已知问题的告警 | 未知问题的探索 |
| 数据 | 指标为主 | 日志 + 指标 + 链路 |
| 查询 | 预定义仪表盘 | 即席查询，自由探索 |
| 场景 | “CPU 高了” | “为什么 CPU 高了” |
| 工具 | Zabbix、Nagios | Prometheus + Grafana + Jaeger + Loki |
说白了，传统监控是“被动响应”——等告警来了再处理。可观测性是“主动探索”——你随时可以问系统任何问题。
注意：可观测性不是要取代监控。监控是可观测性的子集。你仍然需要告警，仍然需要仪表盘。但你需要更多——需要能回答“为什么”的能力。
1.4 为什么云原生时代更需要可观测性
原因很简单：系统太复杂了。
- 服务数量多 —— 一个请求可能经过几十个服务。
- 基础设施动态 —— Pod 随时创建、销毁，IP 不固定。
- 调用关系复杂 —— 同步调用、异步消息、定时任务混在一起。
- 故障模式多样 —— 网络抖动、资源争抢、慢查询、死锁……
你想想看，在这种环境下，光靠几个指标仪表盘，能定位问题吗？很难。
我经历过一个案例：某次大促，订单量突然下降。指标看所有服务都正常，CPU、内存、网络都没问题。最后靠链路追踪发现，是某个中间件的连接池配置错误，导致请求在等待连接时超时。没有链路，这问题可能排查到活动结束都找不到原因。
1.5 小结
这一章我们聊了：
- 可观测性的本质 —— 从外部推断内部状态的能力。
- 三大支柱 —— 日志、指标、链路追踪，各有各的用处，缺一不可。
- 与传统监控的区别 —— 从“被动告警”到“主动探索”。
下一章，我会带大家深入日志体系，聊聊结构化日志怎么落地、怎么避免日志成为性能瓶颈。咱们下期见。