可观测性概述

说实话，我第一次接触「可观测性」这词儿的时候，心里也挺嘀咕的。

不就是监控换了个马甲吗？

后来在几个大型项目里摸爬滚打，才慢慢咂摸出味来——这事儿还真不一样。

从传统监控到可观测性

传统监控的核心思路是什么？

是你提前把所有可能出问题的地方都定义好，然后盯着这些阈值看。

CPU超了80%就告警，内存不够了就发通知。

但现实很骨感。我遇到过多少次了——监控面板全是绿的，用户那边却炸了锅。

可观测性 就不一样了。

它不预设你一定会遇到什么问题。它让你有能力随时问系统：「你现在到底怎么了？」

说白了，就是通过你从系统里拿到的各种数据，直接推理出系统的内部状态。

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

这个概念最早是Google的工程师提出来的。我个人觉得，这个框架特别好理解，也特别实用。

它们就像是系统的三种「打开方式」，很多时候你需要三者结合，才能看清全貌。

支柱	核心价值	典型工具
指标（Metrics）	告诉你「有没有问题」	Prometheus, Grafana
日志（Logs）	告诉你「具体发生了什么」	ELK, Loki
链路（Traces）	告诉你「问题到底出在哪」	Jaeger, Zipkin

指标（Metrics）

指标是数字化的、可聚合的数据。它的特点是轻量、高效、能长期保存。

我习惯把指标分成四种类型：

• Counter（计数器）：只增不减。比如请求总数、错误总数。
• Gauge（仪表盘）：可增可减。比如当前内存使用量、在线用户数。
• Histogram（直方图）：观察数据的分布。比如请求延迟的P50、P99。
• Summary（摘要）：类似直方图，但可以计算分位数。

日志（Logs）

日志是带时间戳的文本记录。它最详细，但也是最「重」的。

结构化是日志的王道。你看下面这两段对比：

# 非结构化日志（别这么干）
2024-10-27 10:00:00 ERROR user 123 login failed password mismatch

# 结构化日志（推荐）
{
  "timestamp": "2024-10-27T10:00:00Z",
  "level": "ERROR",
  "service": "user-service",
  "user_id": "123",
  "action": "login",
  "reason": "password_mismatch",
  "duration_ms": 45
}

结构化之后，你用查询语言（比如LogQL）就能秒级定位到所有特定用户、特定操作的失败记录。这在排查问题的时候体验极好。

链路（Traces）

微服务架构下，一个请求会经过十几个服务。哪一步慢了？哪一步失败了？

链路追踪就是来解决这个问题的。它会给每个请求分配一个全局唯一的 TraceID。

你可以通过这个 TraceID，把一个请求在所有服务上的「足迹」串起来看。

与传统监控的区别

你想想看，传统监控和可观测性到底差在哪？

我列了个表格，对比一下：

对比维度	传统监控	可观测性
核心方式	预设规则 + 阈值告警	数据探索 + 按需查询
响应模式	被动：等告警来了再查	主动：随时可以问系统「现在怎样」
数据关联	指标、日志、工具各自独立	三者关联，可跨维度交叉分析
处理未知问题	几乎没办法	有能力探索未知原因

说白了，传统监控是「等你告诉我出了什么事」，可观测性是「我自己就能看出来出了什么事」。

这两个维度不冲突，是互补关系。你上线初期可以先搭基础监控，系统复杂了再逐步引入完整的可观测性能力。