可观测性三大支柱日志、指标和分布式追踪，分别对应解决故障定位中的“发生了什么”、“哪里出了问题”和“为什么出问题”三类核心问题，覆盖从单一节点到复杂分布式系统的全链路诊断。
日志支柱：故障排查的“黑匣子”
日志是系统运行过程中输出的离散事件记录,每一行都包含时间戳、级别和上下文信息，它解决的是故障发生后的具体细节还原问题，尤其适合“不知道发生了什么”的模糊场景。
日志解决哪类故障
- 配置错误导致的服务异常：当应用启动报错或功能异常，日志能直接给出错误关键字和堆栈信息，帮助开发者快速定位到配置文件中的笔误或依赖缺失。
- 慢查询与数据库死锁：SQL语句执行超时或锁等待，数据库日志会记录具体的SQL文本、执行计划和锁等待队列，这是指标无法直接提供的细节。
- 安全攻击与异常行为：登录失败、接口异常调用、爬虫扫描等痕迹，日志能保留原始请求参数和来源IP，便于事后审计。
- 版本发布后的异常回滚：灰度发布后出现少量错误，通过对比新旧版本的日志差异，可以快速锁定代码变更带来的副作用。
实操步骤：如何用日志高效排查
- 统一日志格式：采用JSON结构化输出，包含时间戳、服务名、请求ID、业务上下文等字段，避免人工解析混乱。
- 集中采集与索引：部署Filebeat或Fluentd采集日志，写入Elasticsearch，通过Kibana搜索关键字，例如检索
order_service和ERROR，加上时间范围，几秒内定位该服务所有错误日志。 - 设置上下文关联：在日志中添加
trace_id，即使跨服务，也能通过该ID串联所有日志，形成完整调用路径。 - 告警规则：对“连续5分钟内出现10次以上OOM”这类模式设置告警，避免日志量过大导致漏报。
日志的局限性
日志量级常受限于存储成本,且无法直观反映系统当前状态的变化趋势，查询时依赖关键词，如果日志中没有记录异常信息，排查就会陷入盲区，因此它需要和其他支柱配合使用。
指标支柱：性能瓶颈的“仪表盘”
指标是时间序列形式的数据,例如CPU利用率、请求延迟、错误率等，它解决的是“哪里出了问题”，适合监控系统健康状态和发现趋势异常。
指标解决哪类故障
- 资源耗尽引发的服务降级：比如内存使用率持续攀升，指标能显示连续几小时的趋势，提前触发扩容告警，而日志只会在OOM瞬间产生一条错误。
- 响应时间突增但无错误：用户反馈页面卡顿，但日志中无错误记录，通过指标查看P99延迟，能发现某个接口耗时从200ms飙升至2s，判断是上游依赖慢或连接池耗尽。
- 容量规划与预测：通过历史指标数据观察业务增长规律，提前规划节点数，避免因“双十一”等流量洪峰导致故障。
- 应用级健康检查：设置指标如
/health的成功率，当低于阈值时自动摘除不健康节点，这是日志无法触达的实时性场景。
实操步骤：指标落地关键动作
- 定义四类黄金信号：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation），每家服务至少覆盖这四类基础指标。
- 选择合适的数据源：使用Prometheus采集指标，Grafana展示图表，配置时注意打上标签（如
service=payment、region=us-east-1），便于后续分层聚合。 - 设置多维告警：避免单一阈值，采用“最近5分钟平均值超过基线2倍”的规则，减少误报，例如对
http_requests_total的4xx错误率设置告警，比单纯看CPU指标更精准。 - 定期复盘指标：每周回顾仪表盘上的异常波形，分析是否与发布、网络波动、依赖变更等事件相关，逐步优化告警灵敏度。
指标的盲区
指标只能告诉你“某个接口延迟变高了”，但无法解释“为什么变高”，是数据库慢查询，还是下游服务超时，又或是业务逻辑本身复杂？这些细节需要日志和追踪来补充。
追踪支柱：分布式事务的“导航图”
分布式追踪是在一次请求跨越多个服务时,记录每个环节的耗时、调用关系和数据传递，它解决的是
“为什么出问题”，特别适合微服务架构下的跨服务故障诊断。
追踪解决哪类故障
- 分布式请求延迟根源：用户打开一个页面，背后涉及3个服务、5次调用，追踪能展示每个步骤的耗时，例如发现最慢的是
service-b调用数据库的SQL，耗时1.2秒，其他环节正常。 - 错误跨服务传播：服务A调用服务B，B返回500错误，但B的日志显示正常，通过追踪链路发现，B收到A的请求参数不合法，导致序列化异常，追根溯源到A的代码逻辑bug。
- 依赖关系混乱：系统出现循环调用或因拓扑不清晰导致雪崩效应，追踪工具生成的拓扑图能直观展示服务间调用链条，帮助重构依赖关系。
- 事务一致性异常：在分布式事务中，部分操作成功，部分失败，追踪回溯每个分支的状态，定位是哪个参与者未提交或回滚。
实操步骤：追踪集成最佳实践
- 确定采样策略：全量采样会带来极高存储开销，建议采用“头采样+尾采样”结合，对错误链路全量采样，对正常链路按比例采样，确保故障场景不遗漏。
- 注入上下文：在服务间调用时，通过HTTP Header或RPC元数据传递
trace_id和span_id，主流框架如Spring Cloud Sleuth、Jaeger或OpenTelemetry都支持自动注入。 - 可视化链路：部署Jaeger或Zipkin，查看每个请求的火焰图，识别长尾调用，例如花5分钟分析一个慢请求，发现某个Redis缓存未命中，导致查库次数增加，优化后响应时间降低70%。
- 关联日志与指标：在链路详情中嵌入日志链接，点击就能跳转到对应时间窗口的日志查询，实现“指标发现异常→追踪定位环节→日志确认细节”的闭环。
追踪的适用场景
追踪在单体应用或简单架构中价值有限,因为调用链短，日志已能覆盖，它更适合微服务、容器化、分布式架构，尤其是服务数量超过10个的复杂系统。
三大支柱如何协同诊断故障
| 故障类型 | 日志能做什么 | 指标能做什么 | 追踪能做什么 |
|---|---|---|---|
| 应用崩溃、OOM | 记录堆栈和最后状态 | 显示内存趋势 | 不直接作用 |
| 接口响应慢 | 记录慢SQL具体语句 | 显示P99延迟 | 定位慢在哪个环节 |
| 调用链错误 | 各服务独立错误日志 | 错误率上升 | 关联全链路，找到根因 |
| 资源耗尽 | 无直接记录 | 显示CPU、内存趋势 | 无直接作用 |
在实际操作中,推荐先部署指标，建立基础监控告警；再接入日志，用于事后排查；最后在微服务规模下引入追踪。三者并非互斥，而是形成“告警→定位→确认”的排查流水线。
可观测性三大支柱常见问题解答
可观测性三大支柱分别解决什么故障问题？需要全部部署吗？
日志解决“发生了什么”，指标解决“哪里出了问题”，追踪解决“为什么出问题”，不一定要全部部署，如果业务是单体架构或少于5个服务，日志+指标足够覆盖常见故障，随着服务数量增加和依赖复杂，追踪才开始体现价值，建议按阶段逐步引入，而不是一次性全量上马。
日志和指标的区别是什么？何时该用谁？
日志是离散事件,适合查询具体错误详情；指标是聚合数据，适合监控趋势和设置告警，排查一个已知的错误，优先查日志；发现系统异常但不知道原因，先看指标面板，两者结合场景：指标告警触发后，通过日志定位具体错误行。
分布式追踪工具选型要看哪些指标？
主要关注采样能力（支持头采样和尾采样）、存储成本（是否支持降采样）、与现有框架的兼容性（如Spring Cloud、gRPC），国内使用较多的有Jaeger、SkyWalking，以及商业化产品如Datadog，开源方案建议优先选择OpenTelemetry标准的实现，避免厂商锁定。
可观测性三大支柱各有侧重，日志还原事件、指标透视趋势、追踪关联链路，故障排除时，按“指标发现异常→追踪定位环节→日志确认细节”的顺序，能最快定位根因，没有一种工具能解决所有问题，组合使用才是最佳实践。