可观测性三大支柱指标日志链路分别指什么？简单说，指标回答“系统是否出问题”，日志回答“问题具体是什么”，链路追踪回答“问题出在哪个环节”，三者缺一不可，共同构成现代云原生架构下系统可观测性的完整拼图。
越来越多的团队在建设监控体系时,会把目光从传统的“监控告警”转向“可观测性”，你会发现，无论是讨论Prometheus、ELK还是Jaeger，业内总会提到这三个词，但很多刚接触的开发者容易混淆：指标、日志、链路追踪，到底谁负责什么？是不是有了日志就不需要其他两个了？
今天这篇文章,我就用通俗的语言，把这三兄弟的分工、联系以及落地时的常见坑讲清楚。
可观测性三大支柱是什么？一文理清指标日志链路追踪的关系
要理解这三者的关系,你得先明白一个场景：你的线上服务突然变慢了，用户开始投诉，这时候你打开电脑，第一件事是看什么？
很多人的第一反应是看日志,但日志往往多而杂，在海量信息里捞针效率太低，更合理的顺序是：先看指标大盘，确认是CPU飙升还是接口延迟变大，然后根据指标异常的维度，去捞那段时间的日志定位报错详情，如果涉及跨服务调用，再打开链路追踪，看看请求到底卡在了哪个下游服务。
这就引出了三者的核心定位：
- 指标（Metrics）：一系列聚合后的数值，比如QPS、错误率、响应时间，它的特点是“可压缩、可聚合、存储成本相对低”。
- 日志（Logs）：一条条离散的事件记录，包含时间戳和具体内容，它的特点是“信息量最大，但也最复杂”。
- 链路追踪（Traces）：一次请求从入口到出口的完整生命旅程，记录了经过的每一个服务和耗时，它的特点是“横跨多个服务，能还原调用拓扑”。
行业共识认为,这三者不是替代关系，而是互补关系，只看指标，你只能知道“坏了”；只看日志，你很难快速定位“哪里坏了”；只看链路，你又会忽略那些没有请求触发的后台任务问题。
指标（Metrics）：系统的“体温计”和“血压计”
指标是所有监控体系的基石,它的本质是对系统状态进行周期性采样，然后用数值表达。
指标的核心价值：快、准、省
指标最大的优势在于存储成本低，相比日志和链路，指标可以以很低的采样频率存储数年之久，比如你服务器的CPU使用率，以15秒间隔采集一个点，一天也就5760个点，压缩后占用的空间微乎其微。
在告警场景中,指标起着不可替代的作用，当某个服务的错误率在5分钟内从0.1%飙升到10%，告警必须立刻触发，而指标正是触发告警最直接的信号源。
常见的指标类型与采集方式
如果你想亲手实践,按照以下思路来搭建最基础的指标监控：
- 使用Prometheus作为指标存储和查询引擎，它是目前云原生领域的事实标准。
- 通过node_exporter采集服务器层面的指标（CPU、内存、磁盘、网络）。
- 通过JMX Exporter或Micrometer采集Java应用层的指标（JVM堆内存、GC次数、线程数）。
- 为你的业务代码埋点,统计关键接口的调用量和延迟分布。
落地实操中,有一点需要提醒：指标虽然很重要，但它回答不了“为什么”，当CPU飙到99%，指标能告诉你哪台机器出了问题，但无法告诉你是因为一段死循环代码还是因为GC频繁，这时候，你就得去看日志了。
日志（Logs）：最“啰嗦”但最真实的现场目击者
日志是系统运行留下的原始记录,它不像指标那样做过聚合，也不像链路那样有严格的拓扑结构，它只是忠实地记下“发生了什么”。
日志在排障中的不可替代性
指标告诉你系统病了,日志则告诉你病因，比如你在日志里看到这样一行：
2026-06-18 14:23:01 ERROR - Connection pool closed. Timeout: 3000ms这一条记录里包含的信息量,往往比十张折线图还要大，它精确指出了错误类型是“连接池关闭”，报错时间是精确到毫秒的，甚至给出了超时阈值，这种细节，指标是给不了的。
日志采集与检索的实操路径
很多团队在日志管理上踩过坑,最常见的问题有两个：一是日志没有集中收集，排障时要登录好几台服务器去翻文件；二是日志量太大，ES存储成本过高。
一个相对合理的日志体系建设路径如下：
- 统一采集：在所有节点部署Filebeat，将日志上报到Kafka或直接写入Elasticsearch。
- 结构化改造：不要只记纯文本，尽量输出JSON格式，包含traceId、userId、接口名等关键字段，这一点非常关键，结构化日志是后续做日志分析的基础。
- 冷热分离：热日志保留近7天在SSD存储，冷日志归档到对象存储，据统计，多数情况下热数据只占全部日志量的不到20%。
需要指出的是（此处使用粗体标注），日志量越大，你检索时就越需要技巧，比如你在Kibana里搜关键字，记得加上时间范围过滤，避免全量扫描。
链路追踪（Traces）：分布式系统中的“全局视角”
前面提到的指标和日志,解决的是单机视角的问题，但在微服务架构下，一个请求往往要经过API网关、用户服务、订单服务、支付服务等五六个节点，这时候，指标和日志就比较吃力了。
日志A在服务1报了一个错,但导致这个错的根源可能在服务3返回了超时，如果没有链路追踪，你需要登录三台服务器去比对时间戳，非常痛苦。
链路追踪的工作原理：TraceId与Span
链路追踪的核心思想很简单：在请求入口处生成一个全局唯一的TraceId，然后把这个TraceId透传到所有下游服务，每一个服务处理这个请求的过程，被定义为一个Span。
- Trace：一次完整的请求旅程。
- Span：旅程中的每一段，包含服务名、操作名、开始时间、结束时间、父子关系。
比如你调用订单接口,链路图会显示出“订单服务 - 耗时200ms”下面挂着“数据库查询 - 耗时150ms”和“调用支付服务 - 耗时50ms”，哪个环节慢，一目了然。
开源链路追踪技术选型参考
目前主流的开源方案有以下几个：
| 方案 | 特点 | 适合场景 |
|---|---|---|
| Jaeger | CNCF毕业项目，支持ELK等后端 | 中小团队快速上手 |
| Zipkin | 老牌方案，功能较为基础 | 与Spring Cloud集成方便 |
| SkyWalking | 国产开源，自带UI和告警 | 不需要额外搭建展示层 |
| OpenTelemetry | 可观测性标准协议 | 未来主流趋势 |
三大支柱如何协同工作？搭建可观测性平台的关键要点
理解了单项技术之后,更重要的困惑是：我到底该怎么把它们组合起来用？
很多团队在建设可观测性体系时容易走向两个极端,一种极端是只做了指标监控，日志靠上服务器翻，链路完全没有；另一种极端是上了很多系统，但各看各的，互相割裂。
理想中的可观测性平台,应该是用指标筛选范围，用日志定位原因，用链路串起上下文。
具体联动场景操作演示
假设你的支付服务P99延迟从200ms涨到了2000ms：
- 指标层：在Prometheus或Grafana里，你看到
pay_service_http_seconds这个Histogram指标的P99分位数明显上涨。 - 日志层：你捞取延迟上涨时间段内的错误日志，发现大量出现“Redis read timed out”。
- 链路层：打开Jaeger，搜索对应的支付请求Trace，发现请求在Redis调用这个Span上耗时高达1800ms，说明问题出在Redis连接或Redis服务器本身。
这三步走下来,问题的定位通常不超过5分钟，如果只看指标，你只知道系统慢了，如果只看日志，你可能要翻几千条才能找到那条关键的，如果只看链路，你发现不了那些没有User请求的后台定时任务异常。
统一绑定TraceId是协同的关键
要想让日志和链路真正联动,你必须在日志里打印TraceId，Java应用里使用Logback时，可以通过配置%X{traceId}来把当前线程上下文中的TraceId注入日志，这一步是做可观测性改造时性价比最高的动作。
可观测性平台怎么选？成本与架构的权衡
很多中小团队在选型时很纠结,这里提供一些参考思路。
按团队规模划分的方案建议
- 单机应用或小规模微服务：使用Prometheus + Grafana做指标，使用ELK做日志，链路追踪先用简单的Zipkin即可，这个组合的特点是组件成熟、资料多、踩坑成本低。
- 中大型团队且已有Kubernetes底座：建议优先考虑OpenTelemetry作为埋点标准，配合企业级的APM厂商产品或自研系统，OpenTelemetry的组件支持链路与指标联动，能有效减少未来的迁移成本。
关于成本控制的一点思考
日志存储和链路采样是成本大头,很多团队会担心数据量太大导致成本失控，建议采用以下策略：
- 链路追踪采用采样策略，默认保留10%的请求，错误追踪模式则100%保留。
- 日志按级别分级存储,INFO及以下日志存储3天，WARN和ERROR存储30天。
指标日志链路追踪区别对比：一张表看懂
为了帮你彻底理清三者区别,这里做一张最直白的对比表：
| 维度 | 指标（Metrics） | 日志（Logs） | 链路追踪（Traces） |
|---|---|---|---|
| 回答的问题 | 系统是否健康 | 系统发生了什么 | 请求经历了什么 |
| 数据形态 | 数值序列 | 文本记录 | 树状结构 |
| 核心优势 | 存储成本低、查询快 | 信息量最丰富 | 跨服务串联能力强 |
| 核心劣势 | 无法解释原因 | 噪音多、检索慢 | 采样率低则失去意义 |
| 典型工具 | Prometheus、Grafana | ELK、Loki | Jaeger、Zipkin、SkyWalking |
| 告警友好度 | 高 | 低（适合搜索不适合告警） | 中 |
常见问题解答：可观测性建设过程中的高频疑问
日志管理平台和链路追踪工具可以合并吗？
目前业界有统一趋势,即All-in-One可观测性平台，比如Grafana Cloud、国内云厂商的ARMS服务，但从落地角度看，中小团队无需一步到位，建议先以Prometheus + Loki + Tempo的组合试点，这套方案与Grafana深度集成，能在一个界面里完成指标、日志、链路的切换查看，减少学习成本。
我们的系统还在用单体架构，需要做链路追踪吗？
单体应用通常不需要完整的分布式链路追踪,但如果你的单体应用依赖外部MySQL、Redis、MQ等中间件，并且出现了性能瓶颈，可以使用OpenTelemetry针对这些依赖做埋点，能帮助排查到底是应用自身代码慢，还是下游中间件响应慢。
如何降低日志存储成本？
降低日志成本最有效的三个手段是：第一，在采集端做日志过滤，比如去掉DEBUG级别的重复日志；第二，使用日志存储压缩率更高的方案，比如Loki比Elasticsearch的存储成本低不少；第三，对冷数据做归档，比如超过30天的日志打包存储到对象存储（如S3、OSS）中，成本仅为热存储的十分之一左右，也可以考虑按需采样，保留完整错误堆栈，对INFO日志采样存储。