一、可观测性概述：从监控到可观测性的演进

大家好，我是你们的老朋友。今天咱们聊聊可观测性这个老生常谈、但又总让人头疼的话题。

说实话，我刚开始做运维那会儿，压根没听过「可观测性」这个词。那时候我们管它叫「监控」。嗯，就是那种机器报警了、页面挂了、用户投诉了，我们才后知后觉去查日志的日子。你想想看，是不是很被动？

后来随着微服务、容器化、PaaS平台这些东西铺开，我发现传统的监控思路完全不够用了。为什么？因为系统太复杂了。一个请求从用户端打到后端，中间可能经过十几个服务、几十个容器、上百个实例。出了问题，你根本不知道从哪查起。

所以，可观测性这个概念就应运而生了。它跟监控的区别在哪？我个人的理解是：监控是「我知道你出问题了」，可观测性是「我知道你为什么出问题」。说白了，就是多了一层「为什么」的追问。

1.1 从监控到可观测性的演进

咱们先简单回顾一下这个演进过程。我把它分成三个阶段：

• 阶段一：黑盒监控 —— 只看外部指标，比如端口通不通、CPU高不高。出了问题只能靠猜。
• 阶段二：白盒监控 —— 开始采集内部数据，比如JVM内存、数据库连接数。但数据是孤立的，各看各的。
• 阶段三：可观测性 —— 把日志、指标、链路追踪这三类数据打通，形成一个完整的「数据拼图」。你能从任意一个维度切入，快速定位根因。

我在项目中遇到过这样一个场景：有一次线上告警说某个接口响应时间飙升。按老办法，我先去看CPU、内存，都正常；再看日志，发现一堆超时异常；最后查链路追踪，才发现是下游的一个Redis集群出了故障。你看，如果只有监控，我可能还在那傻傻地看CPU呢。

1.2 三大支柱：日志、指标、链路追踪的关系

说到可观测性，就绕不开那三个老伙计：日志、指标、链路追踪。很多人把它们割裂开来看，其实它们是一个整体。我打个比方：

• 日志 就像案件的「笔录」—— 记录了每个细节，但信息量太大，查起来费劲。
• 指标 就像案件的「统计报表」—— 告诉你案发频率、趋势变化，但缺少具体细节。
• 链路追踪 就像案件的「时间线」—— 把每个环节串起来，告诉你整个流程是怎么走的。

这三者缺一不可。你想想看，光有指标，你只知道系统慢了，但不知道慢在哪；光有日志，你看到一堆错误，但不知道它们之间的关联；光有链路追踪，你看到请求路径，但不知道每个节点的资源消耗情况。

我个人习惯的做法是：先用指标发现异常，再用链路追踪定位到具体服务，最后用日志深挖根因。 这个流程我用了好多年，屡试不爽。

下面这张表可以帮你快速理解三者的区别：

维度	日志	指标	链路追踪
数据形态	文本、非结构化	数值、时间序列	Span、Trace ID
典型工具	ELK、Loki	Prometheus、Grafana	Jaeger、Zipkin
查询方式	全文搜索	聚合、降采样	Trace ID 关联
主要用途	根因分析、审计	告警、趋势分析	请求路径、性能瓶颈
存储成本	高	中	中

1.3 PaaS平台为什么需要可观测性？

好，咱们回到PaaS平台这个场景。你可能会问：我做个普通的Web应用，搞个监控不就行了？为什么非要上可观测性？

嗯，这里有个关键点：PaaS平台天然就是多租户、多服务、多实例的。 你想想看，一个PaaS平台上可能跑着几十个业务、几百个微服务、几千个容器。出了问题，你连是哪个租户的哪个服务出的问题都搞不清楚。

我举个例子。有一次我们平台的某个租户反馈说他们的应用响应很慢。我第一反应是去看平台整体的CPU和内存，结果一切正常。后来通过链路追踪才发现，原来是这个租户自己的一个服务调用了另一个服务，而那个服务因为代码bug导致死循环。你看，如果没有链路追踪，我可能还在那排查平台层面的问题呢。

PaaS平台需要可观测性，具体来说有这几个原因：

• 快速定位租户问题 —— 租户报障时，你能在几分钟内给出根因，而不是说「我们再观察一下」。
• 资源容量规划 —— 通过指标趋势，提前预判资源瓶颈，避免「半夜扩容」的悲剧。
• 安全审计 —— 日志记录了所有操作行为，出了问题可以追溯。
• 服务依赖梳理 —— 链路追踪能帮你画出服务调用拓扑图，搞清楚谁依赖谁。

最后，我想说一句：可观测性不是银弹。它不能帮你解决所有问题，但它能让你在出问题的时候，少走弯路。嗯，这就是我这些年最深的体会。

下一章，咱们聊聊日志体系怎么搭建。到时候我会分享一些我在ELK和Loki之间反复横跳的经验，敬请期待。