可观测性详解:和监控的区别、三大支柱(Metrics/Logs/Traces)与 OpenTelemetry 落地

先说结论:可观测性(Observability)不是"更高级的监控",它俩回答的根本是两个问题——监控回答"系统有没有出事",可观测性回答"为什么出事"。前者盯着你预先设好的指标看红绿灯,后者让你能从系统对外吐出的数据,反推内部到底发生了什么,去查那些你根本没预料到的问题。

这两年招聘里"可观测性"几乎是 SRE / 运维开发的标配要求,薪资也给得高。这篇把它讲透:和监控差在哪、靠哪三样东西撑起来、怎么判断一条调用正不正常、一套开源栈怎么落地、以及最容易扯皮的——运维和研发各干什么。

一、可观测性 vs 监控:差在哪

  • 监控(Monitoring):你提前定好一批指标(CPU、QPS、错误率…),它盯着这些已知指标,超阈值就告警。本质是"对预设问题的红绿灯"——能告诉你"挂没挂",但只能发现你想到过的问题。
  • 可观测性(Observability):借来自控制论的概念,指能否从系统对外的输出,推断出它内部的状态。它不预设问题,而是把足够丰富的数据留下来,让你在出事后能自由地提问、下钻,查那些事先没设过告警的"未知的未知"。

一句话:监控回答"有没有事",可观测性回答"为什么"。 监控是可观测性的一个子集,不是对立面——你仍然需要告警,只是光有告警不够。

二、三大支柱:Metrics、Logs、Traces

可观测性靠三类数据撑起来,业界叫"三大支柱":

  • Metrics(指标):可聚合的数值,带时间戳,看趋势。比如 QPS、p99 延迟、错误率。省存储、适合大盘和告警,但只有数字、没有上下文。
  • Logs(日志):一条条离散事件的文字记录,信息最全,但量大、难聚合。
  • Traces(链路追踪):把一次请求跨多个服务的完整路径串起来。这里有个词叫 span——span 就是链路里的一个环节(一次函数调用、一次数据库查询、一次 RPC);很多 span 按父子关系串成一棵树,就是一条完整的 trace。

三者怎么打通?靠 trace_id

光有三样数据、各看各的没用,关键是打通。打通靠一个东西:trace_id——它是贯穿一次请求的唯一标识。请求一进来就生成一个 trace_id,然后顺着调用链一路传下去,沿途的指标、日志、每个 span 都带上同一个 trace_id。

于是排障就成了一条线索:指标大盘看到 p99 飙高 → 拿到对应的 trace_id → 跳到这条 trace 看是哪段慢 → 再用同一个 trace_id 去捞那一段的日志看具体报错。从"哪儿慢"一路追到"为什么慢"。

三、怎么看一条 trace 正不正常

打开一条 trace,四步快速判断:

  1. 看总耗时:和 p95 基线比。p95 的意思是:把所有请求的耗时排序,95% 的请求都比这个值快——它盯的就是最慢的那 5% 长尾。这条 trace 的总耗时超过 p95,就算慢。
  2. 看有没有报错的 span:状态标红 / error 的 span,就是出问题的环节。
  3. 看瀑布图找瓶颈:trace 通常画成瀑布图(每个 span 一条横条,按时间排开),哪一条最长,哪段就是瓶颈——往往是某个慢查询或外部调用。
  4. 看有没有重复调用:同一个查询出现几十上百次,多半是 N+1(本该一次批量查,结果在循环里一条条查)。

四、怎么落地:一套开源栈

落地不用从零造轮子,一套成熟开源栈就能起步。下面这张图是它的分工——分采集、存储、看板三层:

可观测性落地架构:采集/存储/看板三层分工

  • 采集层:OpenTelemetry(简称 OTel)。它是厂商中立的标准,负责在应用侧统一采集指标、日志、链路,并给每条数据打上同一个 trace_id。接它一套 SDK,三类数据一起出。
  • 存储层:各存各的——指标进 Prometheus,日志进 Loki(或 ELK),链路进 Jaeger。它们各自擅长一类数据的存储和查询。
  • 看板 / 告警层:Grafana 一个面板把三样拼到一起看,点一下就能从指标跳到日志、链路;Prometheus 这边顺带用 Alertmanager 做告警。

一句话记住:OTel 采、三件套各存各的、Grafana 统一看。

五、运维和研发怎么分工

可观测性落地最容易扯皮的不是工具,是"埋点谁做"。分工其实很清楚:

  • 研发(Dev)负责让系统"可被观测":在代码里接 OTel SDK、给关键路径加 trace、写带 trace_id 的结构化日志、暴露业务指标。原则是谁的代码谁埋点——只有写代码的人知道哪些是关键路径、哪些字段值得记。
  • 运维 / SRE 负责"把平台搭好用好":部署运维 Prometheus / Loki / Jaeger / Grafana 这一套,定下采集规范(指标命名、标签、采样率),配大盘和告警规则,出故障时主导排查。
  • 两边一起的:定 SLO(Service Level Objective,服务可靠性的量化目标,比如"99.9% 的请求在 200ms 内返回")、做故障复盘。

记住一句:研发负责让系统能被观测,运维负责把观测平台搭好用好。

六、落地的几个关键方案

架构搭起来只是开始,真正落地还有几个绕不开的方案选择:

1. 埋点:自动 + 手动结合

  • 自动埋点:OpenTelemetry 提供各语言的自动注入(Java 用 agent、Python 用 opentelemetry-instrument 命令包一层),框架级的 HTTP / gRPC / 数据库调用不改业务代码就自动出 trace 和指标——接入成本最低,先把这层铺上。
  • 手动埋点:业务关键路径再用 SDK 手动开 span、记业务属性(订单号、用户 ID),把"黑盒"里那段补全。
  • trace_id 怎么跨服务传:走 W3C Trace Context 标准——请求头里带一个 traceparent 字段,OTel SDK 在出站时自动注入、入站时自动提取,跨服务就自动续上同一条 trace,不用自己手搓。

2. 采样:别全量存,贵

trace 全量存,又贵又没必要。两种采样方案:

  • 头部采样(Head sampling):请求一进来就按固定比例(如 10%)掷骰子决定采不采。简单、省,但可能正好把出错那条丢了。
  • 尾部采样(Tail sampling):在 OTel Collector 等整条 trace 结束后再决定——出错的、慢的全留,正常的按比例留。更聪明,但要 Collector 把 span 缓存起来等齐,成本高一些。生产上常见组合:尾部采样保关键、头部采样兜底。

3. 告警:用 SLO,别拍脑袋设固定阈值

固定阈值(CPU > 80%)最容易又误报又漏报。更稳的是基于 SLO 的告警:先定目标(如"99.9% 的请求 200ms 内返回"),它对应一份错误预算(允许 0.1% 不达标);再用燃尽率(burn rate)告警——只有当错误预算烧得太快时才报警。好处是平时不吵、真出事才响,既少打扰又抓得住大问题。

4. 关联下钻:让三样数据真能互相跳

"打通"不只是都带上 trace_id,还得在工具里把跳转配好,否则还是各看各的:

  • 指标 → 链路:Prometheus 的 Exemplar(在指标数据点上挂一个代表性的 trace_id),配好后在 Grafana 里点一下延迟尖刺,直接跳到那条 trace。
  • 日志 → 链路:Loki 的 derived fields(衍生字段),把日志里的 trace_id 自动提取成可点击的链接,一点就跳到 Jaeger / Tempo 看链路。

5. 选型:几条主流路线

可观测性的开源栈不止一种,主流有三条路线 + SaaS:

  • Grafana 系(开源自建):Prometheus + Loki + Jaeger(或 Grafana Tempo)+ Grafana。轻量、省钱、可控,Loki 只按标签索引日志(便宜),代价是全套自己部署运维。
  • Elastic Stack(ELK 系):Elasticsearch + Logstash / Beats + Kibana,再加 Elastic APM 就是日志 + 指标 + 链路的全套观测平台——ELK 不只是日志方案,Elastic 本身就主打可观测性。强项是日志全文检索(任意关键词秒搜)和成熟生态;代价是 Elasticsearch 吃内存、吃磁盘、运维偏重。日志量大、要强检索的团队常选它。
  • Grafana LGTM 全家桶:Loki(日志)+ Grafana(看板)+ Tempo(链路)+ Mimir(指标),同一家、集成顺,运维负担小一些。
  • SaaS(Datadog、观测云等):开箱即用、几乎不用运维,但单价高、数据要出公网,合规和成本都要先算账。

Loki vs ELK 怎么选:Loki 轻量省钱(只索引标签、不做全文)、和 Grafana 一家;ELK 检索强、生态全,但 ES 资源重。日志量不大、看重成本 → Loki;要强全文检索 / 已经在用 ES → ELK。
整体口诀:预算紧、要可控 → Grafana 系;日志重、要强检索 → ELK 系;想省心同生态 → LGTM;不差钱、团队小 → SaaS。

快速参考

监控 vs 可观测性

监控 可观测性
回答 有没有事 为什么
数据 预设指标 指标+日志+链路
能查 已知问题 未知的未知

三大支柱:Metrics(数值趋势)/ Logs(具体事件)/ Traces(请求全路径,由 span 组成)——靠 trace_id 打通。

看一条 trace:① 总耗时 vs p95 基线 ② 有没有报错 span ③ 瀑布图找最长的 = 瓶颈 ④ 有没有 N+1 重复调用。

开源栈分工:OpenTelemetry 采集+传 trace_id → Prometheus(指标)/ Loki(日志)/ Jaeger(链路)→ Grafana 统一看板+告警。

团队分工:研发埋点(谁的代码谁埋)/ 运维搭平台+配告警 / SLO 和复盘两边一起。

常见术语:trace_id=贯穿一次请求的唯一标识;span=链路里一个环节;p95=95% 请求都比它快(盯长尾);SLO=可靠性量化目标;N+1=本该一次批量查、却在循环里查了 N 次。

posted @ 2026-06-23 17:59  Hello_worlds  阅读(158)  评论(0)    收藏  举报