1. 全链路监控概述：从单点监控到全链路监控的演进
大家好，我是你们的老朋友。今天咱们聊聊全链路监控。
说实话，我入行那会儿，监控这事儿特别简单。服务器挂了？Nagios 弹个告警。CPU 飙了？Zabbix 画个折线图。那时候大家觉得，监控嘛，不就是盯着几个指标别出红线吗？
但后来我发现，事情没那么简单。
1.1 从单点监控说起
单点监控，说白了就是「各自为政」。每个组件自己管自己，互不干扰。
- 基础设施监控：CPU、内存、磁盘、网络。工具如 Zabbix、Prometheus node_exporter。
- 应用监控：进程是否存活、端口是否监听、日志是否有 ERROR。
- 数据库监控：慢查询、连接数、QPS。
听起来挺全的，对吧？但问题来了——这些监控之间没有关联。
一个真实案例：我曾经接手过一个电商系统。用户反馈下单慢，运维说服务器负载正常，DBA 说数据库没慢查询，开发说代码没报错。三方数据都对，但用户就是卡。最后查了三天，发现是 Redis 连接池耗尽导致请求排队——而 Redis 监控根本没接入告警系统。
这就是单点监控的致命伤：每个点都正常，但整体就是不行。
1.2 为什么需要全链路监控？
你想想看，一个请求从用户浏览器出发，经过 CDN、负载均衡、网关、微服务 A、微服务 B、缓存、数据库、消息队列……这一路下来，少则十几个节点，多则上百个。
任何一个环节慢 100ms，用户感知就是「这网站卡死了」。但单点监控只能告诉你「每个节点都正常」，它没法告诉你问题到底出在哪一跳。
全链路监控要解决的核心问题就三个：
- 请求去哪儿了？——调用链追踪，把一次请求的完整路径串起来。
- 慢在哪一步？——每个环节的耗时分布，一眼看出瓶颈。
- 谁影响了谁？——数据血缘关系，搞清楚依赖拓扑。
我的习惯：每次接手新系统，第一件事不是看告警规则，而是先画一张全链路拓扑图。把每个服务、每个中间件、每条调用关系都标出来。这张图就是你的「监控地图」，没有它，你就是在黑夜里开车。
1.3 数据血缘：不只是调用链
很多人把全链路监控等同于调用链追踪（Distributed Tracing），其实不对。调用链只是「骨架」，数据血缘才是「血肉」。
数据血缘描述的是数据从哪里来、经过哪些处理、最终流向哪里。在监控场景下，它回答的是：
- 这个告警指标是从哪些原始数据聚合来的？
- 这个业务指标依赖哪些上游服务的输出？
- 如果某个数据源挂了，会影响哪些下游报表和告警？
举个例子。你看到「订单成功率」跌了 5%。没有数据血缘，你只能一个个服务去查日志。有了数据血缘，你直接看到：订单成功率依赖「支付回调服务」和「库存扣减服务」，而「库存扣减服务」又依赖「Redis 缓存」——好，直接去看 Redis 是不是挂了。
我曾经踩过的坑：有一次线上告警说「用户登录失败率飙升」。我花了两个小时排查认证服务、数据库、网络……最后发现是前端改了接口参数格式，后端没兼容。如果当时有数据血缘图，一眼就能看到「登录接口的入参来源是前端 SDK」，直接找前端对质就行了。嗯，从那以后我强制团队所有新服务必须注册数据血缘关系。
1.4 SLA：监控的终极目标
监控不是为了看数据，而是为了保障服务质量。SLA（Service Level Agreement）就是那把尺子。
常见的 SLA 指标：
| 指标 | 含义 | 典型目标 |
|---|---|---|
| 可用性 | 服务正常响应的时间占比 | 99.9% ~ 99.999% |
| 延迟 | 请求从发出到收到响应的耗时 | P99 < 200ms |
| 吞吐量 | 单位时间内处理的请求数 | 根据业务定 |
| 错误率 | 失败请求占总请求的比例 | < 0.1% |
但 SLA 不是拍脑袋定的。你得先有全链路监控数据，才能知道当前能做到多少，然后跟业务方商量承诺多少。
我个人习惯把 SLA 拆成两层：
- 技术 SLA：每个微服务、每个中间件的内部指标。这是运维和开发自己看的。
- 业务 SLA：用户真正感知的端到端体验。比如「下单成功率」、「首页加载时间」。这是给老板和业务方看的。
没有全链路监控，你连业务 SLA 都算不出来——因为你不知道用户那端的真实体验是什么。
1.5 全链路监控的核心逻辑
说了这么多，咱们用一张图把核心逻辑串起来。
这张图是我做全链路监控架构时的标准分层。从下往上，数据从采集到血缘，再到 SLA 计算，最后落到根因分析。每一层都依赖下一层的数据质量。
关键认知：全链路监控不是一套工具，而是一种数据驱动的问题定位方法论。工具只是载体，核心是「把一次请求的完整生命周期串起来，并且能量化它对业务的影响」。
1.6 从单点到全链路：演进路径
很多团队问我：我们该不该一步到位上全链路监控？我的建议是——别急，一步步来。
我见过太多团队，一上来就部署 Jaeger + SkyWalking + Prometheus + Grafana，结果数据是有了，但没人看得懂，最后变成一堆「监控僵尸」——数据在跑，没人看。
合理的演进路径是这样的：
- 阶段一：单点监控补齐——先把基础设施、数据库、中间件的监控做全。这一步是地基。
- 阶段二：统一指标平台——把所有指标拉到同一个 Prometheus 或 Thanos 集群，用 Grafana 统一看板。
- 阶段三：调用链接入——选择一套分布式追踪系统（我推荐 Jaeger 或 OpenTelemetry），先接入核心服务。
- 阶段四：数据血缘建设——建立服务依赖图和指标血缘关系，这一步开始「全链路」了。
- 阶段五：SLA 量化与告警——基于血缘数据计算端到端 SLA，设置燃烧率告警。
- 阶段六：根因分析自动化——利用调用链和血缘数据，自动定位故障根因。
我的建议：大多数团队卡在阶段三到阶段四之间。调用链数据有了，但不知道怎么跟业务指标关联。这时候别急着上 AIOps，先把「订单成功率下降时，关联的调用链样本是什么」这个基础能力做扎实。数据血缘不是一步到位的，先做核心链路的血缘，再逐步扩展。
1.7 本章小结
全链路监控不是银弹，但它确实是现代分布式系统运维的必需品。从单点监控到全链路，本质上是从「看局部」到「看全局」的思维转变。
记住三个关键词：
- 调用链——把请求串起来。
- 数据血缘——把依赖理清楚。
- SLA——把质量量化出来。
后面的章节，我会带你一步步搭建这套体系。咱们先从调用链追踪讲起——这是全链路监控的起点。