落地与收尾 · 从零到一，以及全专栏回顾
五十三章的技术，落地时该按什么顺序？这一章给一条从零开始的路径、一份可执行的检查清单，并回顾整个专栏的主线与几条贯穿始终的原则——为这个专栏画上句号。
落地与收尾 · 从零到一，以及全专栏回顾
最后一章：把它变成行动，然后收尾。
从零开始：一条务实的路径
别想着一步到位。按这个顺序，每一步都能立刻产生价值：
第 1 步：给关键服务上 RED（一周）
✓ 埋一个 histogram(method/route/status,[route 必须是模板!](/manual/observability/red-method))
✓ [桶边界覆盖你的 SLO 区间](/manual/observability/metric-ranges)
✓ 出一个[分层看板](/manual/observability/grafana-dashboards)的第一层(4 个图)就这一步，你已经超过了很多团队。
第 2 步：配 up 和 sample_limit（一天）
✓ [up == 0 告警](/manual/observability/scrape-loop)(最便宜、最有用的一条)
✓ [每个 job 配 sample_limit](/manual/observability/cardinality)(最便宜的保险)
✓ [CardinalityGrowing 告警](/manual/observability/cardinality)(scrape_series_added)第 3 步：定第一个 SLO（两周，大部分时间在沟通）
✓ 挑**一个**最关键的用户旅程(不是每个微服务!)
✓ 和业务方谈定目标(这是[商业决策](/manual/observability/metric-ranges))
✓ [先只看不告警,跑两周看真实燃烧率](/manual/observability/slo-burn-rate)
✓ 然后上[多窗口燃烧率告警](/manual/observability/slo-burn-rate)第 4 步：删告警（一天，但需要勇气）
✓ [用 ALERTS 审计](/manual/observability/alerting-philosophy):哪条最吵、哪条 90 天没响
✓ [每条过那六条筛子](/manual/observability/alerting-philosophy)
✓ **删掉一半**——[这会提升可靠性,不是降低](/manual/observability/alerting-philosophy)第 5 步：补 USE（一周）
✓ 列那张表,把[盲区显式化](/manual/observability/use-method)
✓ 优先补**[应用层资源的饱和度](/manual/observability/use-method)**(连接池/线程池)← 收益最大第 6 步及以后：追踪、日志关联、Collector、成本治理……
注意这个顺序的逻辑：先骨架后覆盖、先发现后定位、先删后加。 大多数团队反过来做——先上一堆工具，再想该测什么，结果是几百个没人看的面板。
一份检查清单
拿它对照你现在的系统：
指标
□ 关键服务有 [RED](/manual/observability/red-method) 吗?
□ route 用的是[模板不是原始 path](/manual/observability/red-method) 吗?
□ [桶边界在 SLO 阈值附近](/manual/observability/metric-ranges)吗?
□ 延迟看的是[分位数不是平均](/manual/observability/red-method)吗?
□ 成功和失败的延迟[分开了](/manual/observability/four-golden-signals)吗?
□ 关键资源有[饱和度](/manual/observability/use-method)吗?(尤其连接池!)告警
□ page 级告警是[个位数](/manual/observability/alerting-philosophy)吗?
□ 每条都[对症状不对原因](/manual/observability/alert-thresholds)吗?
□ 每条都有 [runbook](/manual/observability/alerting-philosophy) 吗?
□ 阈值是[从 SLO 倒推](/manual/observability/alert-thresholds)的,还是拍的?
□ 有 [`for` 防抖](/manual/observability/alerting-rules)吗?
□ [90 天没响过的](/manual/observability/alerting-philosophy)验证过能触发吗?基数与成本
□ 知道自己有多少 series 吗?([prometheus_tsdb_head_series](/manual/observability/cardinality))
□ 有 [CardinalityGrowing 预警](/manual/observability/cardinality)吗?
□ 每个 job 有 [sample_limit](/manual/observability/scrape-loop) 吗?
□ 算过[账](/manual/observability/cost-control)吗?关联
□ 日志是[结构化](/manual/observability/logs-pillar)的吗?
□ 日志里有 [trace_id](/manual/observability/logs-pillar) 吗?
□ [exemplar](/manual/observability/exemplars) 配通了吗?(五个环节都对?)工程化
□ 看板和告警[在 Git 里](/manual/observability/grafana-dashboards)吗?
□ [`allowUiUpdates: false`](/manual/observability/grafana-dashboards) 了吗?全专栏回顾：十个部分
| 部分 | 主题 | 一句话 |
|---|---|---|
| 0 | 导论与全景 | 监控答已知，可观测性答未知；三支柱的本质区别是成本曲线 |
| 1 | Prometheus 采集 | pull 让“抓取即健康检查”；relabel 是可编程的标签机器 |
| 2 | 指标体系 | RED 测服务、USE 测资源；饱和度才是精髓；基数是乘法 |
| 3 | TSDB 内核 | 时序三先验 → Gorilla 压到 1~2 字节；不可变 → 一切简化 |
| 4 | PromQL | 两种向量的降维关系；rate() 其实在外推 |
| 5 | 告警工程 | for 是防抖基石；燃烧率一口气解决六个问题；删告警提升可靠性 |
| 6 | OTel Collector | 标准才是最大价值；管道是 DAG；MutatesData 的精妙 |
| 7 | 追踪与日志 | 上下文传播最脆弱；采样的根本矛盾；exemplar 是最巧的桥 |
| 8 | Grafana | QueryData 窄腰；看板结构该像排障思路 |
| 9 | 工程实践 | 基数是唯一能让监控自杀的东西；砍覆盖面别砍骨架 |
几条贯穿始终的原则
读完全部，回头看，有几条原则在三个项目、十个部分里反复出现**——它们才是这个专栏真正想留下的东西：**
① 小接口撑起大生态
Prometheus 的 Discoverer（一个方法 → 30 种 SD）、storage.Appender（让 remote write 零成本接入）、Collector 的 consumer（几百个组件）、Grafana 的 QueryData（所有数据源）——四个不同的项目，同一个答案：接口越小，能塞进去的实现越多。
② 宁可明确失败，不要含糊成功
sample_limit 超限就丢整次抓取、MaxSamples 杀掉查询、memory_limiter 主动拒绝——三个地方，同一条原则：一个失控的东西不该有能力打垮全局，而且半截的数据比没有数据更危险。
③ 约束越强，优化空间越大
时序数据的三个先验 → 12 倍压缩；block 不可变 → 无锁读 + 位级打包 + 秒删；counter 只增非负 → rate() 能猜零点。通用系统不敢做的，专用系统敢——因为它知道自己的数据长什么样。
④ 让调用方申报意图，框架据此优化
Querier 的 sortSeries/hints、consumer 的 MutatesData——框架不猜，让上层说。一个 bool 换来整条管道的零冗余复制。
⑤ 信噪比是公共资源
告警疲劳、50 个图的看板、99% 是噪音的 ERROR 日志——同一个病：每一条噪音都在消耗所有人的注意力，而注意力用完了，真的那条也就没人看了。
⑥ 保持核心简单，把复杂性推到外层
Prometheus 刻意单机自足，分布式交给 Thanos/Mimir、分片靠 hashmod 而非集群共识、Collector 核心只认接口、组件靠 OCB 组装——监控必须比被监控更可靠，而可靠的前提是简单。
结语
感谢你走完这五十三章。愿你的系统，在出事的那个凌晨，是亮的。
—— 全专栏完 📊
参考资料
- [1] 本专栏全 10 个部分（从导论到成本）。
- [2] 源码：Prometheus 3.13.1 / OTel Collector 0.156.0 / Grafana 13.1.0。
- [3] Google《SRE Book》/《SRE Workbook》、Charity Majors《Observability Engineering》、Brendan Gregg《Systems Performance》。