可观测性基础：从“黑盒”到“白盒”

说实话，刚入行那几年，我对“可观测性”这个词挺不屑的。不就是监控换个马甲吗？直到有一次深夜被电话叫醒——线上服务挂了，日志全是空指针，指标曲线断崖式下跌，可链路追踪呢？压根没装。我盯着屏幕上孤零零的报警短信，脑子里只有一句：“到底哪里出了问题？”

那次之后我才真正明白：可观测性不是监控的升级版，而是一种完全不同的思考方式。它回答的不是“系统挂了吗”，而是“系统为什么挂”以及“接下来会发生什么”。

到底什么是可观测性？

控制理论里有个经典定义：一个系统是可观测的，当且仅当你能通过它的外部输出，推断出系统内部的状态。翻译成人话——你不用重启或者登录机器，光看数据就能知道系统内部发生了什么。

我自己的理解更直白：可观测性是一种设计能力。它不是事后补的，而是从一开始就想着“我怎么知道这个模块在干嘛”。比如写个新服务，顺手把关键路径的日志、请求量指标、调用链埋点加进去，而不是等上线出问题了再去加。

三大支柱：日志、指标、链路追踪

这几个词你肯定听过，但很多人把它们当成三件独立的工具。我刚开始也这么想，后来踩了坑才知道：它们是三根绳子，得拧在一起才能拉起整个系统。

日志（Logs）

日志是最古老的观测手段。每一行日志记录一个离散事件，带时间戳和上下文。说白了就是“发生了什么”。

我在项目中遇到过最头疼的事：日志打了一堆，但全是没有结构的字符串，连个trace_id都没有。排查问题时只能grep，然后对着时间戳手动脑补执行顺序。嗯，效率极低。

• 结构化日志：JSON格式，字段名清晰，方便自动化解析。
• 级别控制：DEBUG/INFO/WARN/ERROR，不要生产环境打DEBUG。
• 上下文注入：请求ID、用户ID、服务名，缺一不可。

// 好的日志示例（Go语言片段）
log.WithFields(log.Fields{
  "service": "payment",
  "trace_id": "abc123",
  "amount": 99.8,
  "status": "success",
}).Info("charge completed")

// 坏的日志示例
log.Println("charge completed: 99.8")

指标（Metrics）

指标描述的是系统在某个时刻的聚合状态，比如QPS、延迟P99、CPU使用率。它不关心单个请求，只关心“整体如何”。

有个经典误区：以为指标能代替日志。其实它们分工完全不同。指标适合做预警和趋势分析，日志适合做根因定位。

指标类型	常见例子	用途
计数器	http_requests_total	统计总量
直方图	http_request_duration_seconds	观察分布，比如P99
仪表盘	memory_usage_bytes	持续测量当前值

链路追踪（Traces）

链路追踪是最年轻、也最能拉平复杂分布式系统的手段。它把一次请求跨多个服务的调用串起来，形成一棵树。每个节点叫span，记录服务名、开始时间、耗时、状态。

我曾经遇到过一个诡异的慢请求：客户端等5秒才超时。查日志，每个服务都返回200；看指标，CPU也不高。最后靠链路追踪才发现，中间某个服务调了另一个外部网关，那个网关自己又重试了三次——总共花了4.8秒。如果没有追踪，这种“分布式黑洞”根本捉不到。

• 不侵入代码：现在的OpenTelemetry SDK大多支持自动埋点。
• 采样策略：全量采集性能压力大，建议头部采样+尾部采样结合。
• 上下文传播：HTTP请求头里带上trace_id和parent_span_id，不能断链。

可观测性与监控的区别

这个区分曾经让我困惑很久。直接说结论：监控是已知问题已知答案，可观测性是未知问题也能探索。

举个例子：监控告诉你“CPU超过90%”，你知道该加机器；可观测性允许你问“为什么CPU突然飙高？哪个请求导致的？”——你不需要提前定义好所有怀疑点，靠数据反推就行。

维度	监控	可观测性
目标	已知故障的告警	未知问题的探索
数据	预定义的指标和阈值	高基数、多维度的原始数据
工具	Prometheus + Grafana 仪表盘	日志分析 + 链路追踪 + 指标组合查询
典型问题	“服务器挂了吗？”	“接口慢在哪一段？”
思维	被动响应	主动探测

但别误会，两者不是非此即彼。我自己的做法：线上所有服务先上好基础监控（CPU、内存、磁盘、核心QPS），然后逐步叠加日志结构和链路追踪，最后把这些数据关联到一个统一查询界面里。这样既有“守夜人”又有“侦探”。

这张图我画过很多次，其实就是可观测性的核心流程：先通过三大支柱收集数据，再关联起来做分析，最后推动行动。没有哪个支柱能独自完成闭环。

好了，第一章就到这。可观测性不是银弹，但当你拥有它之后，处理线上事故时的底气和效率会完全不一样。后面我会一步步带你搭建实战平台，把理论变成真正能用的东西。