我已经有 EFK（Elasticsearch + Fluentd + Kibana）/ELK 看日志了，查问题也挺方便，为啥还要多搞一套链路追踪？

为什么需要链路追踪？

EFK 是“看文字记录”，链路追踪是“看地图+路线+耗时”。
日志能告诉你“发生了什么”，链路追踪能告诉你“请求怎么走的、谁慢了、谁挂了”。

1. EFK 只能看到“点”，链路追踪能看到“整条线”

假设用户下单失败，你去 EFK 搜日志：

用 EFK 查问题

你只能看到：

订单服务报错了
支付服务也报错了
用户服务好像也有问题

但你完全不知道：

谁先调用谁？
是谁导致谁挂了？
是调用链断在哪一步？

日志是分散的，像一堆散落的纸条。

用链路追踪查问题

直接给你一张完整调用路线图：
网关 → 订单服务 → 库存服务 → 支付服务 → DB
并且标红：支付服务调用超时

瞬间定位根因。

2. EFK 没有“请求串联”能力

微服务里，一个请求会穿过：
5 个服务 + 3 个数据库 + 2 个缓存 + MQ

EFK 里：

订单服务日志：request-id=abc123
支付服务日志：traceId=abc123
用户服务日志：没打任何 ID

你要手动拼、手动搜、手动对应，非常痛苦。

链路追踪天生自带 TraceID，自动把整条链路串起来。
不用你拼，不用你找，系统自动画成图。

3. EFK 看不到耗时分布，只能看到文字

用户说“接口慢”，EFK 能告诉你：

接口执行了
执行成功了

但完全看不到：

哪一步最耗时？
是 DB 慢？HTTP 调用慢？Redis 慢？锁等待？

链路追踪会自动统计：

每个服务耗时
每个 SQL 耗时
每个外部调用耗时

一眼就能看到性能瓶颈。

4. EFK 没有服务拓扑，不知道服务之间的关系

EFK 只是日志存储，它不知道：

A 服务调用 B
B 调用 C
C 又调用 D

链路追踪可以自动画出：
服务拓扑图
谁依赖谁、流量多大、调用比例、异常比例。

5. EFK 日志量大，搜索慢，还可能丢日志

高并发下：

日志疯狂打
EFK 搜索巨卡
有些日志还会丢失

链路追踪是采样上报，轻量、高效、不丢关键信息。

6. 最核心的区别（一定要记住）

EFK/ELK = 记录事件
链路追踪 = 记录调用关系 + 时序 + 耗时 + 依赖

一个是文字记录
一个是请求的完整生命轨迹

最简单的类比

EFK = 医院的检查报告
链路追踪 = 病人的全身 CT + 血流图

你光看报告，不知道病灶在哪；
一看 CT，立刻知道堵塞位置、堵塞程度。

实际工作中的真实场景

用户投诉：下单接口超时。

用 EFK

翻 10 分钟日志，搜 3 个服务，对比时间戳，猜问题。

用链路追踪

打开界面 → 找到这条请求 → 看到：
调用第三方支付接口耗时 4.8s → 超时
直接定位。

最终总结

EFK 不能替代链路追踪，链路追踪也不能替代 EFK。
它们是互补关系：

EFK：看详细日志、错误堆栈、业务日志
链路追踪：看调用链路、性能耗时、服务依赖、根因定位

现代微服务标准架构 = 监控（Prometheus）+ 日志（EFK）+ 链路追踪（SkyWalking/Jaeger）
缺一不可。
维度 Prometheus（指标） EFK（日志）链路追踪（Trace）
数据类型数值（Metrics）文本（Logs）调用关系（Trace）
关注视角面（全局）点（单服务）线（全链路）
核心问题系统好不好？发生了什么？请求怎么走的？
典型场景告警、趋势、容量、大盘查堆栈、Bug、审计、详情分布式慢请求、服务依赖、故障定位
数据量级中等（采样 / 聚合）极大（全量）中等（采样）
查询特点聚合、统计、范围全文检索、关键词按 TraceID 查整条链