引言：服务网格时代的“两只眼睛”
2017 年 Uber 开源了一个分布式追踪系统 Jaeger，并在 2019 年将其捐赠给 CNCF。两年后，Istio 社区推出了 Kiali 作为官方的可视化控制台，专为服务网格设计。这两个 CNCF 项目在可观测性领域各有侧重，但常常被混为一谈。
一条线上故障的排查路径通常是这样的：你从 Kiali 的服务拓扑图中看到“订单服务”的请求成功率从 99.9% 突然掉到了 85%，发红的节点指示了问题的范围。你点击受影响的流量边，Kiali 提供了直达 Jaeger 的追踪链接。你进入 Jaeger UI，找到一条超时超过 3 秒的 trace，火焰图中一眼就看到风控服务的“查询信用分”独占耗时 2.8 秒——问题出在哪里、为什么出问题，以及牵动了哪些上下游，全部一清二楚。
这不是个案。某出海物流电商公司接入 Jaeger 后，高峰期每秒写入量达到 80000 条 trace，存储成本极高。他们用 GreptimeDB 替换 Elasticsearch 后，存储成本降低了 45 倍。另一家金融公司将 Jaeger 集成到 CI/CD 管道后，生产事故平均解决时间（MTTR）从 4.3 小时降至 27 分钟。
Kiali 告诉你“哪里出了问题”，Jaeger 告诉你“为什么出问题”。这不是二选一，而是 1 + 1 > 2 的工程配合。
本文将从项目定位、架构设计、核心能力、生产配置和实践经验等多个维度，深入剖析这两个工具的本质差异与协同价值。
第一章 定位差异：Kiali 与 Jaeger 的根本不同
Kiali 和 Jaeger 虽然都属于分布式系统可观测性工具，但它们回答的是两个完全不同的问题。这个问题可
