在微服务架构中，当线上接口变慢或报错时，你首先会打开监控面板，但面对链路追踪（Distributed Tracing）和APM（Application Performance Monitoring）两套工具，常常会犹豫：到底该看哪个？它们有什么区别？又该如何选择？本文将从实际故障排查场景出发，帮你理清思路。
从一次线上故障说起：链路追踪与APM各自能做什么
假设你的订单服务响应时间突然飙升至5秒，用户开始投诉。此时，你手上有两套系统：一套是APM，显示订单服务的平均响应时间、错误率、CPU使用率等指标；另一套是链路追踪，能展示一次请求从网关到订单服务、再到数据库的完整调用链。
首先，你会打开APM面板，确认订单服务确实存在性能问题，比如响应时间从200ms升至5秒，错误率从0.1%涨到10%。这能帮你快速定位到问题服务，但APM无法告诉你这次请求具体经过了哪些服务、每个环节耗时多少。而链路追踪则能展示一次请求的完整路径：网关耗时50ms，订单服务耗时4.5秒，其中数据库查询耗时4秒。这样你就能立刻知道瓶颈在数据库查询。
从这个场景可以看出，链路追踪与APM的侧重点不同：APM关注应用的整体性能和健康状态，而链路追踪关注请求在分布式系统中的完整路径和耗时分布。它们的数据模型和实现方式也不同。
链路追踪与APM的核心区别
链路追踪与APM的区别主要体现在以下几个方面：
数据模型
APM通常基于指标（Metrics）数据模型，例如Prometheus收集的就是时间序列数据，即带时间戳的数值，并附有标签（labels）。Prometheus官方文档指出，指标是数值测量，例如Web服务器的请求时间、数据库的活动连接数等。APM工具会聚合这些指标，展示趋势和告警。
链路追踪基于Trace数据模型，一条Trace由多个Span组成，每个Span代表一个操作，包含开始时间、结束时间、服务名、操作名等信息。Trace能够还原一次请求的完整调用链。
技术栈
传统APM工具往往需要安装代理（Agent）或修改代码，且通常与特定厂商绑定。而链路追踪则越来越标准化，例如OpenTelemetry提供了统一的API和SDK，可以生成、收集和导出Trace、Metrics和Logs，并且是厂商中立的，支持超过90个可观测性厂商。这意味着你可以用OpenTelemetry生成数据，然后导出到任意支持的后端。
部署方式
APM工具通常以SaaS形式提供，或者需要自建一套完整的监控平台。链路追踪同样可以自建或使用云服务，但基于OpenTelemetry等开源标准，你可以更灵活地组合工具，例如用Jaeger或Zipkin作为后端。
典型场景一：快速定位跨服务性能瓶颈
假设你接到反馈，用户下单很慢，但不知道是哪个服务导致的。此时，你可以按照以下步骤操作：
- 打开链路追踪面板，输入订单ID或用户ID，找到对应的Trace。
- 查看Trace的瀑布图，找出耗时最长的Span。例如，如果订单服务的Span耗时4秒，而数据库查询的Span耗时3.8秒，那么瓶颈就在数据库。
- 进一步查看数据库查询的详细信息，比如SQL语句、参数等，判断是否需要优化索引或增加缓存。
在这个过程中，APM只能告诉你订单服务整体变慢，但无法告诉你具体是哪个下游依赖导致。因此，在跨服务性能问题中，链路追踪是更直接的工具。
典型场景二：监控服务整体健康状态
当你需要监控所有服务的整体健康状态，比如CPU使用率、内存占用、请求量、错误率等，APM或指标监控工具更合适。例如，Prometheus可以收集这些指标，并通过Grafana展示仪表盘。你可以设置告警规则，当错误率超过阈值时触发告警。
链路追踪虽然也能提供一些统计信息，但它的重点在于单次请求的路径，而非整体聚合。如果你需要了解系统的整体负载和趋势，APM或指标监控是首选。
典型场景三：从单体架构迁移到微服务时的监控选型
假设你正在将单体应用拆分为微服务，需要重新设计监控方案。此时，你可能会面临以下选择：
- 如果团队规模小，希望快速上手，可以选择商业APM方案，如Datadog、New Relic等，它们通常开箱即用，但成本较高。
- 如果团队有开源偏好，且希望避免厂商锁定，可以选择基于OpenTelemetry + Prometheus + Jaeger的组合。OpenTelemetry负责生成和导出数据，Prometheus负责指标监控，Jaeger负责链路追踪。
- 如果团队有足够的运维能力，可以自建这些开源工具，但需要考虑存储和扩展性。
在选择时，你需要权衡成本、运维复杂度和功能需求。例如，Prometheus虽然功能强大，但需要自己管理存储和告警；而商业APM则提供了更完整的解决方案，但成本较高。
如何选择适合的监控方案
选择监控方案时，可以从以下几个维度考虑：
团队规模和运维能力
如果团队只有两三个人，且没有专职运维，商业APM可能更合适，因为部署和维护成本低。如果团队有较强的运维能力，开源方案更灵活，且可以节约成本。
技术栈和现有工具
如果你们已经使用了Kubernetes和云原生技术，那么Prometheus和OpenTelemetry是自然的选择，因为它们都是CNCF项目，与云原生生态集成良好。OpenTelemetry官方文档强调它是行业标准，被超过90个可观测性厂商支持，这意味着你可以在不同后端之间切换而不需要重新埋点。
故障排查需求
如果你们的服务依赖关系复杂，经常需要排查跨服务性能问题，那么链路追踪是必须的。如果主要关注服务整体健康状态，那么APM或指标监控就足够了。
常见误区与失败条件
在选择和使用监控方案时，有一些常见误区需要注意：
- 误区一：认为链路追踪可以替代APM。实际上，链路追踪和APM侧重点不同，通常需要两者结合才能获得完整的可观测性。
- 误区二：过度依赖自动埋点。虽然OpenTelemetry等工具支持自动埋点，但某些业务逻辑可能无法被自动埋点覆盖，需要手动添加Span来记录关键操作。
- 误区三：忽略采样策略。在高并发场景下，如果对所有请求都进行追踪，会产生海量数据，导致存储成本高昂。因此，需要设置合理的采样策略，比如只追踪错误请求或一定比例的请求。
- 失败条件：如果后端存储不足，可能会导致Trace数据丢失；如果埋点不规范，会导致Trace不完整，无法定位问题。
参考资料
延伸阅读