6.1 指标日志链路三维可观测

6.1 指标日志链路三维可观测

本节摘要：可观测性（Observability）有三个支柱——指标（Metrics）、日志（Logs）、链路（Traces），它们各自看系统的不同侧面，配合起来才能完整洞察。本节讲三者各自的特性和采集方式，重点是怎么配合形成从发现异常到定位根因的高效闭环：指标告诉你“出事了”，日志告诉你“发生了什么”，链路告诉你“卡在哪”。三者缺一，排障就会卡壳。

学习目标

阅读完本节，你应当能够：

1. 说清指标、日志、链路各自的特性和适用场景
2. 区分监控（Monitoring）和可观测性（Observability）的差别
3. 设计三支柱配合的排障流程
4. 理解分布式链路追踪的原理和价值
5. 搭一个覆盖核心链路的可观测体系

一、问题与直觉

高并发系统出故障时，最折磨人的不是“系统挂了”，而是“系统慢了但不知道哪慢”。一个接口的 P99 突然从 100 毫秒飙到 2 秒，你打开监控看，CPU 正常、内存正常、数据库正常——到底哪出了问题？

没有可观测性的系统，排障基本靠猜和重启。猜对了算运气，猜不对就重启大法，重启好了也不知道为什么好的，下次还犯。这种排障方式在高并发系统里根本行不通——故障每分钟都在造成损失，没时间慢慢猜。

可观测性就是为了解决这个问题：它让你能从系统外部的行为，推断出系统内部的状态。指标、日志、链路三者配合，让你能快速回答“出事了吗、什么事、卡在哪”，把排障时间从小时压到分钟。

二、核心原理

2.1 三支柱各自的特性

可观测性的三大支柱，各自看系统的不同侧面，特性互补。

指标（Metrics）：聚合的数值数据，按时间序列存储。比如 QPS、RT、错误率、CPU 利用率。指标的特点是聚合——它不关心单个请求，关心的是整体趋势。指标适合做监控和告警（数值超阈值就报警），因为它紧凑、查询快、能长期保留。短板是它看不出单个请求的细节。

日志（Logs）：离散的事件记录，每条日志记录一个具体事件（一个请求、一次错误、一次状态变更）。日志的特点是详细——它带上下文，能还原具体发生了什么。日志适合排障时看细节（这个失败的请求当时的参数是什么、走到了哪一步）。短板是量大、查询慢（要在海量日志里找相关的那几条）。

链路（Traces）：一个请求在分布式系统里经过所有服务的完整路径。链路的特点是贯穿——它把一个请求经过的每个服务、每段耗时串起来，让你看清请求在分布式系统里怎么流转。链路适合定位跨服务调用的瓶颈（这个慢请求到底卡在哪个服务）。短板是实现复杂（要给每个请求打标记并贯穿所有服务）。

2.2 三者配合：排障的黄金流程

三个支柱单用都有短板，但配合起来形成高效的排障流程。

第一步指标发现异常：监控指标（如错误率、P99 RT）偏离正常范围，触发告警，告诉你“出事了”。指标是第一道眼线，它持续监控，异常第一时间暴露。

第二步链路定位范围：打开慢请求或错误请求的链路追踪，看这个请求经过了哪些服务、每段耗时多少，定位是哪个服务、哪段调用慢了或错了。链路把范围从“整个系统”缩小到“某个服务的某次调用”。

第三步日志看根因：进入定位到的那个服务，看相关时间段的日志，看那次调用的具体细节——参数是什么、报了什么错、走到哪一步失败的。日志给你根因。

这个流程的价值在于：它把排障从“在海量信息里捞针”变成“按图索骥”。指标缩小到时间范围，链路缩小到服务范围，日志缩小到事件细节，每一步都在缩小范围，几分钟就能定位根因。

2.3 分布式链路追踪的原理

三个支柱里，链路追踪是最难实现的，值得单独讲讲原理。

在单体应用里，一个请求的处理都在一个进程里，加个日志打点就能看耗时。但分布式系统里，一个请求要经过几十个服务，每个服务自己记日志，没法把它们串起来——不知道哪条日志属于哪个请求。

链路追踪的解法是给每个请求分配一个唯一的追踪 ID（Trace ID），这个 ID 在请求经过的每个服务间传递，每个服务记录自己这段处理（Span）时带上这个 Trace ID。这样，所有带上同一个 Trace ID 的 Span，就能拼出这个请求的完整路径。

实现上靠的是上下文传递——通常通过请求头（如 HTTP 头）把 Trace ID 从调用方传给被调用方。服务网格（Service Mesh）能自动完成这个传递，不用应用代码关心，这是它对可观测性的一大贡献。

三、工程实践要点

3.1 监控 vs 可观测性

监控（Monitoring）和可观测性（Observability）常被混用，但有差别。监控是你预先定义“要看哪些指标”，系统按定义采集和告警——它只能回答你预先想到的问题。可观测性是系统对外充分暴露内部状态，使你能探究“没预先想到的问题”——它让你能临时探究新问题。

高并发系统复杂多变，预先定义的监控永远不够（总会出新问题），所以要从“监控”升级到“可观测性”——不只采集预定义指标，还要保留足够的日志和链路，使你能临时探究。这就是为什么三支柱都要全。

3.2 告警要分级，别淹没

可观测体系会暴露大量指标，如果每个异常都告警，运维会被淹没，产生“告警疲劳”——告警太多看不过来，最后全忽略。所以告警要分级：严重告警（系统不可用）立即打电话通知，一般告警（某个指标偏高）发工单，低级告警（接近阈值）只记录不通知。

告警的阈值也要精心设——设太敏感天天误报，设太迟钝出大事才报。要基于历史数据设动态阈值（正常波动范围之外的才报），而不是死阈值。

⚠️ 常见坑：配了几百条告警规则，每天告警几千条，运维麻木了全部忽略，真严重故障的告警也被淹没。告警贵精不贵多，每条告警都应该可 actionable（能触发具体行动），不能 actionable 的告警删掉。

3.3 可观测性要覆盖全链路

可观测性最大的坑是“只覆盖了一部分”——核心服务有监控，但某个依赖的中间件没有；应用层有链路，但数据库调用没串进去。结果故障出在没覆盖的地方，可观测体系根本看不到。所以可观测性要覆盖全链路——从入口到数据库的每个环节都要有埋点。

💡 关键直觉：可观测性的投资回报率极高。一套好的可观测体系，能把平均故障恢复时间（MTTR）从小时压到分钟，每次故障省下的损失远超建设成本。它是高并发系统里最该早投入、最不该省的基础设施。

本节要点回顾

• 三支柱：指标（聚合趋势，监控告警）、日志（离散事件，排障细节）、链路（请求全路径，定位跨服务瓶颈）。
• 配合流程：指标发现异常→链路定位服务→日志看根因，逐级缩小范围。
• 链路追踪原理：Trace ID 贯穿请求经过的所有服务，拼出完整路径，服务网格能自动传递。
• 监控vs可观测：监控答预想问题，可观测性能探究新问题，后者更全面。
• 告警分级：严重打电话、一般发工单、低级只记录，避免告警疲劳。
• 全链路覆盖：每个环节都要埋点，漏一处就成盲区。

下一节讲怎么把可观测数据转化为容量规划决策，形成从洞察到行动的闭环。

三板数据的留存与成本策略

可观测性三板的数据量随流量指数增长，成本问题迟早会来，提前规划比事后救火从容。指标的留存可以分层：分钟级精度存九十天覆盖大部分排障需求，小时级聚合存两年支撑容量规划，原始秒级只在高敏感期保留。日志的成本大头在无差别采集，治理手段是分级采样：错误日志全量、警告日志抽样一半、信息日志只留关键链路，配合按服务的重要性差异化配置。链路追踪天然适合采样，头部采样保成功率、尾部采样重点抓错误和慢请求，两者结合能用百分之一的存储成本覆盖最有价值的样本。

还有一个实践要点是三维数据的关联标识：同一次请求的指标、日志、链路要能靠 trace 标识串联，这个标识要从接入层生成并贯穿所有异步链路。没有关联的三个维度是三座孤岛，有了关联才是一个可下钻的整体。日志框架的埋点规范要统一（时间戳格式、字段命名、脱敏规则），各团队自由发挥的日志格式会让集中检索的成本翻倍——这类规范宜早不宜迟，晚统一一天，历史数据的清洗就多一天的工作量。

再给一个自建与采购的对比结论：可观测性栈的自建（开源组件拼装）可控且无厂商锁定，但要投入专人维护升级与容量；商业方案省心、集成度高，但深度定制和成本透明度受限。团队规模十人以内的，选托管方案把精力留给业务；有专职平台的，自建加二次定制的上限更高。这个决策三到五年不用重做，但每次流量上台阶时值得重新评估一次——昨天的性价比结论，今天可能已经反转。

再补一个日志规范的具体模板供参考：每条日志至少包含时间戳、级别、trace 标识、服务名、事件码和结构化字段六要素，事件码用"模块加数字"的格式（如支付模块 1001 表示下游超时），错误码集中登记不允许各服务私造。这套规范的价值在半年后显现：新成员靠事件码手册就能独立排障，跨服务的问题定位从翻代码变成查表。规范的执行用日志采集端的校验兜底，格式不对的日志在采集时就报警，别等到检索时才发现半年白采。