日志负责还原离散事件的上下文，指标负责捕捉趋势与阈值异常，链路追踪负责定位跨服务调用中的具体故障节点，三者组合才能覆盖绝大多数线上故障。
可观测性三大支柱分别是什么
可观测性不是某个单一工具，而是一套组合能力，业内专家指出，现代分布式系统的可观测性由日志、指标、链路追踪三部分构成，日志记录离散事件，指标聚合数值变化，链路追踪串联调用关系。
理解这三者的分工，是排查故障效率翻倍的前提，很多人遇到线上告警只会翻日志，结果越查越乱,就是因为没把合适的支柱用在合适的故障类型上。
日志：解决“报错但不知道上下文”类故障
日志最擅长处理的，是那种“系统抛了异常，但光看异常信息不知道前因后果”的问题。
典型故障场景
- 用户下单失败，接口返回500，但不知道是库存扣减失败还是支付超时。
- 定时任务突然中断，错误堆栈只显示空指针，不显示触发数据是什么。
- 服务启动后偶发崩溃，监控曲线没有明显波动，只能靠日志还原崩溃前的操作序列。
这类故障的共同特征是：异常已经发生，但缺少事件发生前后的上下文信息，日志通过记录时间戳、线程、类名、方法入参和堆栈,把离散事件拼接成一条完整时间线。
实操排查路径
以Linux环境为例，先用时间范围过滤：
```
grep "2026-05-20 14:3" /var/log/application.log | grep "ERROR"
```
再根据报错线程ID追查同一线程的前序操作：
```
grep "thread-23" /var/log/application.log | tail -n 50
```
多数情况下，空指针的根因不是空指针本身，而是上游方法传入了未校验的参数，日志能帮你把“谁调用了这个方法、传了什么值”还原出来。
指标：解决“资源突然飙高但难以定位趋势”类故障
指标擅长的是趋势性、阈值性故障，比如CPU使用率突然从30%跳到95%，或者内存缓慢增长直到OOM，这类故障用日志很难查，因为日志里可能没有任何报错，但资源已经撑不住了。
典型故障场景
- 数据库连接池耗尽，但业务日志没有异常，只有连接等待时间变长。
- JVM堆内存每小时增长200MB，三天后必然Full GC频繁。
- 某个接口的P99延迟每天下午三点准时升高，但调用量没有变化。
指标通过聚合计算，把一段时间内的数值变化压缩成曲线，它不会告诉你某个具体请求发生了什么，但能告诉你哪段时间、哪个维度出现了异常。
指标告警设置建议
不要只盯着单点阈值，更有效的做法是组合告警：
- CPU使用率持续5分钟超过85%，且load1大于核数。
- 内存使用率超过90%，且GC耗时占比连续3个周期上升。
- 接口错误率超过1%，且调用量没有下降。
以Prometheus为例,一条组合查询可以写成：
rate(http_server_requests_seconds_count{status=~"5.."}[5m]) / rate(http_server_requests_seconds_count[5m]) > 0.01这条表达式能直接定位“错误率突增但流量没变”的场景,比翻日志快得多。
链路追踪：解决“微服务调用链中某一跳延迟”类故障
当一次请求要经过网关、订单服务、库存服务、支付服务、消息队列等五六个节点时，日志和指标都很难回答“到底慢在哪一跳”，这正是链路追踪的主场。
典型故障场景
- 用户反馈页面加载要8秒，但前端资源加载正常，后端接口总耗时4秒。
- 订单创建接口P99延迟突然恶化，但各服务自身CPU、内存都正常。
- 消息消费堆积，但生产端和消费端日志都没有报错，只是中间网络抖动。
链路追踪给每个请求分配一个全局唯一的TraceID，并在跨服务调用时传递，每个服务处理完后，把Span信息（开始时间、结束时间、调用方、被调方、状态）上报,这样一条完整调用链就能被还原成瀑布图。
TraceID贯穿调用链的方法
在Java微服务中，通常用OpenTelemetry或SkyWalking自动埋点，如果是手动排查，先把TraceID从响应头或日志中取出来：
```
curl -I https://api.example.com/order/create | grep trace-id
```
拿到TraceID后，在追踪平台搜索，就能看到每一跳的耗时占比，多数情况下，延迟集中在某两个服务之间的网络调用，或者某个SQL查询突然变慢。
日志指标链路追踪区别：三类故障的边界在哪
很多团队把三者混在一起用，反而增加排查成本，日志指标链路追踪区别，本质上在于它们回答的问题不同。
| 对比维度 | 日志 | 指标 | 链路追踪 |
|---|---|---|---|
| 数据形态 | 离散文本事件 | 聚合数值 | 带上下文的Span |
| 回答的问题 | 发生了什么、为什么发生 | 哪里变慢了、是否异常 | 调用链中哪一跳出问题 |
| 擅长故障 | 空指针、参数错误、业务异常 | 资源耗尽、趋势突变、阈值告警 | 跨服务延迟、依赖故障、消息积压 |
| 排查方式 | grep、tail、上下文还原 | PromQL、Grafana面板、告警规则 | TraceID检索、Span瀑布图 |
一个实用的判断方法是：先看指标有没有异常，再看追踪定位到具体节点，最后用日志还原该节点内部发生了什么,这个顺序能避免在大量日志里大海捞针。
国内可观测性工具选型：不同故障优先级如何匹配
国内可观测性工具选型，不能只看功能列表，要结合团队最常遇到的故障类型。
如果团队以单体应用为主，故障集中在代码逻辑和资源使用，那么日志加指标基本够用，ELK套件或Loki处理日志，Prometheus加Grafana处理指标，建设成本低,排查效率高。
如果团队已经微服务化，调用链复杂，那么必须引入链路追踪，SkyWalking、Pinpoint在国内使用较广，原因是中文文档完善、Agent接入简单，简米云ARMS、酷番云TAM等商业方案,则适合不想自己维护追踪集群的团队。
关于可观测性平台收费贵吗这个问题，没有统一答案，开源方案本身免费，但需要投入人力维护，商业SaaS按数据量或节点数收费，小型团队一年几万元是常见区间，大型集群可能更高，选择时先评估日志量、指标数量和Span上报频率,再对比价格。
把三类故障交给对应的支柱
排查线上故障最忌讳一把抓，资源类问题查日志，代码逻辑问题看指标，跨服务延迟问题翻追踪，方向错了再努力也低效。
可观测性三大支柱相关问答
可观测性三大支柱分别解决哪一类故障问题？
日志解决离散事件上下文缺失类故障，指标解决趋势突变和资源阈值类故障，链路追踪解决分布式调用链中某一跳延迟或依赖故障，三类故障定位方式不同，组合使用才能覆盖完整。
微服务故障定位慢怎么解决？
先确认是否存在全局TraceID透传，若没有，优先补齐追踪埋点，再检查各服务的指标面板是否覆盖了黄金信号：延迟、流量、错误、饱和度，最后保证日志中能打印TraceID和SpanID，这样从追踪跳到日志只需一次查询。
日志指标链路追踪区别是什么？
日志是离散事件，回答“发生了什么”；指标是聚合数值，回答“哪里变慢了”；链路追踪是带上下文的Span，回答“调用链中哪一跳出问题”，三者数据形态不同，擅长故障类型不同，不能互相替代。