# 落地与收尾 · 从零到一，以及全专栏回顾

> 五十三章的技术，落地时该按什么顺序？这一章给一条从零开始的路径、一份可执行的检查清单，并回顾整个专栏的主线与几条贯穿始终的原则——为这个专栏画上句号。

- 作者：David（道雾轩）
- 专栏：指标采集与观测（https://daiw.org/manual/observability.md）
- 最后更新：2026-07-15
- 原文：https://daiw.org/manual/observability/observability-recap
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 落地与收尾 · 从零到一，以及全专栏回顾

五十三章，从“[什么是可观测性](https://daiw.org/manual/observability/why-observability)”一路走到“[怎么算这笔账](https://daiw.org/manual/observability/cost-control)”。

最后一章：**把它变成行动**，然后收尾。

## 从零开始：一条务实的路径

<Callout type="info">
  **别想着一步到位。按这个顺序，每一步都能立刻产生价值：**

  **第 1 步：给关键服务上 [RED](https://daiw.org/manual/observability/red-method)**（一周）
  ```
  ✓ 埋一个 histogram(method/route/status,[route 必须是模板!](https://daiw.org/manual/observability/red-method))
  ✓ [桶边界覆盖你的 SLO 区间](https://daiw.org/manual/observability/metric-ranges)
  ✓ 出一个[分层看板](https://daiw.org/manual/observability/grafana-dashboards)的第一层(4 个图)
  ```
  **就这一步，你已经超过了很多团队。**

  **第 2 步：配 `up` 和 [`sample_limit`](https://daiw.org/manual/observability/scrape-loop)**（一天）
  ```
  ✓ [up == 0 告警](https://daiw.org/manual/observability/scrape-loop)(最便宜、最有用的一条)
  ✓ [每个 job 配 sample_limit](https://daiw.org/manual/observability/cardinality)(最便宜的保险)
  ✓ [CardinalityGrowing 告警](https://daiw.org/manual/observability/cardinality)(scrape_series_added)
  ```

  **第 3 步：定第一个 [SLO](https://daiw.org/manual/observability/slo-burn-rate)**（两周，大部分时间在沟通）
  ```
  ✓ 挑**一个**最关键的用户旅程(不是每个微服务!)
  ✓ 和业务方谈定目标(这是[商业决策](https://daiw.org/manual/observability/metric-ranges))
  ✓ [先只看不告警,跑两周看真实燃烧率](https://daiw.org/manual/observability/slo-burn-rate)
  ✓ 然后上[多窗口燃烧率告警](https://daiw.org/manual/observability/slo-burn-rate)
  ```

  **第 4 步：删告警**（一天，但需要勇气）
  ```
  ✓ [用 ALERTS 审计](https://daiw.org/manual/observability/alerting-philosophy):哪条最吵、哪条 90 天没响
  ✓ [每条过那六条筛子](https://daiw.org/manual/observability/alerting-philosophy)
  ✓ **删掉一半**——[这会提升可靠性,不是降低](https://daiw.org/manual/observability/alerting-philosophy)
  ```

  **第 5 步：补 [USE](https://daiw.org/manual/observability/use-method)**（一周）
  ```
  ✓ 列那张表,把[盲区显式化](https://daiw.org/manual/observability/use-method)
  ✓ 优先补**[应用层资源的饱和度](https://daiw.org/manual/observability/use-method)**(连接池/线程池)← 收益最大
  ```

  **第 6 步及以后：追踪、日志关联、[Collector](https://daiw.org/manual/observability/collector-architecture)、成本治理**……

  **注意这个顺序的逻辑：[先骨架后覆盖、先发现后定位、先删后加](https://daiw.org/manual/observability/metrics-methodology)。** 大多数团队反过来做——**先上一堆工具，再想该测什么**，结果是[几百个没人看的面板](https://daiw.org/manual/observability/metrics-methodology)。
</Callout>

## 一份检查清单

<Callout type="info">
  **拿它对照你现在的系统：**

  **指标**
  ```
  □ 关键服务有 [RED](https://daiw.org/manual/observability/red-method) 吗?
  □ route 用的是[模板不是原始 path](https://daiw.org/manual/observability/red-method) 吗?
  □ [桶边界在 SLO 阈值附近](https://daiw.org/manual/observability/metric-ranges)吗?
  □ 延迟看的是[分位数不是平均](https://daiw.org/manual/observability/red-method)吗?
  □ 成功和失败的延迟[分开了](https://daiw.org/manual/observability/four-golden-signals)吗?
  □ 关键资源有[饱和度](https://daiw.org/manual/observability/use-method)吗?(尤其连接池!)
  ```

  **告警**
  ```
  □ page 级告警是[个位数](https://daiw.org/manual/observability/alerting-philosophy)吗?
  □ 每条都[对症状不对原因](https://daiw.org/manual/observability/alert-thresholds)吗?
  □ 每条都有 [runbook](https://daiw.org/manual/observability/alerting-philosophy) 吗?
  □ 阈值是[从 SLO 倒推](https://daiw.org/manual/observability/alert-thresholds)的,还是拍的?
  □ 有 [`for` 防抖](https://daiw.org/manual/observability/alerting-rules)吗?
  □ [90 天没响过的](https://daiw.org/manual/observability/alerting-philosophy)验证过能触发吗?
  ```

  **基数与成本**
  ```
  □ 知道自己有多少 series 吗?([prometheus_tsdb_head_series](https://daiw.org/manual/observability/cardinality))
  □ 有 [CardinalityGrowing 预警](https://daiw.org/manual/observability/cardinality)吗?
  □ 每个 job 有 [sample_limit](https://daiw.org/manual/observability/scrape-loop) 吗?
  □ 算过[账](https://daiw.org/manual/observability/cost-control)吗?
  ```

  **关联**
  ```
  □ 日志是[结构化](https://daiw.org/manual/observability/logs-pillar)的吗?
  □ 日志里有 [trace_id](https://daiw.org/manual/observability/logs-pillar) 吗?
  □ [exemplar](https://daiw.org/manual/observability/exemplars) 配通了吗?(五个环节都对?)
  ```

  **工程化**
  ```
  □ 看板和告警[在 Git 里](https://daiw.org/manual/observability/grafana-dashboards)吗?
  □ [`allowUiUpdates: false`](https://daiw.org/manual/observability/grafana-dashboards) 了吗?
  ```
</Callout>

## 全专栏回顾：十个部分

| 部分 | 主题 | 一句话 |
| --- | --- | --- |
| [0](https://daiw.org/manual/observability/why-observability) | 导论与全景 | [监控答已知，可观测性答未知](https://daiw.org/manual/observability/why-observability)；[三支柱的本质区别是成本曲线](https://daiw.org/manual/observability/three-pillars) |
| [1](https://daiw.org/manual/observability/prometheus-architecture) | Prometheus 采集 | [pull 让“抓取即健康检查”](https://daiw.org/manual/observability/scrape-loop)；[relabel 是可编程的标签机器](https://daiw.org/manual/observability/relabeling) |
| [2](https://daiw.org/manual/observability/metrics-methodology) | **指标体系** | [RED 测服务、USE 测资源](https://daiw.org/manual/observability/use-method)；**[饱和度才是精髓](https://daiw.org/manual/observability/use-method)**；[基数是乘法](https://daiw.org/manual/observability/defining-metrics) |
| [3](https://daiw.org/manual/observability/tsdb-overview) | TSDB 内核 | [时序三先验 → Gorilla 压到 1~2 字节](https://daiw.org/manual/observability/chunk-encoding)；[不可变 → 一切简化](https://daiw.org/manual/observability/tsdb-overview) |
| [4](https://daiw.org/manual/observability/promql-model) | PromQL | [两种向量的降维关系](https://daiw.org/manual/observability/promql-model)；**[`rate()` 其实在外推](https://daiw.org/manual/observability/promql-rate)** |
| [5](https://daiw.org/manual/observability/alerting-rules) | **告警工程** | [`for` 是防抖基石](https://daiw.org/manual/observability/alerting-rules)；**[燃烧率一口气解决六个问题](https://daiw.org/manual/observability/slo-burn-rate)**；[删告警提升可靠性](https://daiw.org/manual/observability/alerting-philosophy) |
| [6](https://daiw.org/manual/observability/otel-overview) | OTel Collector | [标准才是最大价值](https://daiw.org/manual/observability/otel-overview)；[管道是 DAG](https://daiw.org/manual/observability/collector-architecture)；[MutatesData 的精妙](https://daiw.org/manual/observability/consumer-backpressure) |
| [7](https://daiw.org/manual/observability/traces-basics) | 追踪与日志 | [上下文传播最脆弱](https://daiw.org/manual/observability/traces-basics)；[采样的根本矛盾](https://daiw.org/manual/observability/sampling)；**[exemplar 是最巧的桥](https://daiw.org/manual/observability/exemplars)** |
| [8](https://daiw.org/manual/observability/grafana-datasource) | Grafana | [QueryData 窄腰](https://daiw.org/manual/observability/grafana-datasource)；[看板结构该像排障思路](https://daiw.org/manual/observability/grafana-dashboards) |
| [9](https://daiw.org/manual/observability/cardinality) | 工程实践 | [基数是唯一能让监控自杀的东西](https://daiw.org/manual/observability/cardinality)；[砍覆盖面别砍骨架](https://daiw.org/manual/observability/cost-control) |

## 几条贯穿始终的原则

<Callout type="info">
  **读完全部，回头看，有几条原则在三个项目、十个部分里**反复出现**——它们才是这个专栏真正想留下的东西：**

  **① 小接口撑起大生态**

  [Prometheus 的 `Discoverer`（一个方法 → 30 种 SD）](https://daiw.org/manual/observability/service-discovery)、[`storage.Appender`（让 remote write 零成本接入）](https://daiw.org/manual/observability/query-path)、[Collector 的 `consumer`（几百个组件）](https://daiw.org/manual/observability/consumer-backpressure)、[Grafana 的 `QueryData`（所有数据源）](https://daiw.org/manual/observability/grafana-datasource)——**四个不同的项目，同一个答案：接口越小，能塞进去的实现越多。**

  **② 宁可明确失败，不要含糊成功**

  [`sample_limit` 超限就丢整次抓取](https://daiw.org/manual/observability/scrape-loop)、[`MaxSamples` 杀掉查询](https://daiw.org/manual/observability/promql-engine)、[`memory_limiter` 主动拒绝](https://daiw.org/manual/observability/consumer-backpressure)——**三个地方，同一条原则**：一个失控的东西不该有能力打垮全局，而且**半截的数据比没有数据更危险**。

  **③ 约束越强，优化空间越大**

  [时序数据的三个先验 → 12 倍压缩](https://daiw.org/manual/observability/chunk-encoding)；[block 不可变 → 无锁读 + 位级打包 + 秒删](https://daiw.org/manual/observability/tsdb-overview)；[counter 只增非负 → `rate()` 能猜零点](https://daiw.org/manual/observability/promql-rate)。**通用系统不敢做的，专用系统敢——因为它知道自己的数据长什么样。**

  **④ 让调用方申报意图，框架据此优化**

  [`Querier` 的 `sortSeries`/`hints`](https://daiw.org/manual/observability/query-path)、[`consumer` 的 `MutatesData`](https://daiw.org/manual/observability/consumer-backpressure)——**框架不猜，让上层说**。一个 bool 换来整条管道的零冗余复制。

  **⑤ 信噪比是公共资源**

  [告警疲劳](https://daiw.org/manual/observability/alerting-philosophy)、[50 个图的看板](https://daiw.org/manual/observability/grafana-dashboards)、[99% 是噪音的 ERROR 日志](https://daiw.org/manual/observability/logs-pillar)——**同一个病**：每一条噪音都在消耗所有人的注意力，而注意力用完了，**真的那条也就没人看了**。

  **⑥ 保持核心简单，把复杂性推到外层**

  [Prometheus 刻意单机自足，分布式交给 Thanos/Mimir](https://daiw.org/manual/observability/prometheus-architecture)、[分片靠 `hashmod` 而非集群共识](https://daiw.org/manual/observability/relabeling)、[Collector 核心只认接口、组件靠 OCB 组装](https://daiw.org/manual/observability/custom-components)——**监控必须比被监控更可靠，而可靠的前提是简单。**
</Callout>

## 结语

<Callout type="warn">
  **最后说一件这个专栏反复强调、但值得再说一遍的事：**

  **可观测性的目标不是“采集数据”，是“[能回答问题](https://daiw.org/manual/observability/why-observability)”。**

  一个有 500 个指标、100 个面板、80 条告警的系统，可能远不如一个有 [10 个 RED 指标](https://daiw.org/manual/observability/red-method)、[1 个分层看板](https://daiw.org/manual/observability/grafana-dashboards)、[3 条燃烧率告警](https://daiw.org/manual/observability/slo-burn-rate)的系统——**如果后者能让值班的人在 5 分钟内定位根因，而前者不能**。

  **技术只是手段。真正难的是那些判断：**
  - [该测什么](https://daiw.org/manual/observability/metrics-methodology)（而不是能测什么）
  - [什么时候该叫醒人](https://daiw.org/manual/observability/alerting-philosophy)（而不是什么时候能叫醒人）
  - [哪些数据值它的价钱](https://daiw.org/manual/observability/cost-control)
  - [该删掉什么](https://daiw.org/manual/observability/alerting-philosophy)

  **这些问题，源码不会告诉你答案。** 但读懂了源码，你至少知道**每个选择的代价是什么**——而这正是做出好判断的前提。
</Callout>

感谢你走完这五十三章。愿你的系统，在出事的那个凌晨，**是亮的**。

—— 全专栏完 📊

## 参考资料

- [1] 本专栏全 10 个部分（[从导论](https://daiw.org/manual/observability/why-observability)[到成本](https://daiw.org/manual/observability/cost-control)）。
- [2] 源码：[Prometheus 3.13.1 / OTel Collector 0.156.0 / Grafana 13.1.0](https://daiw.org/manual/observability/the-three-projects)。
- [3] Google《SRE Book》/《SRE Workbook》、Charity Majors《Observability Engineering》、Brendan Gregg《Systems Performance》。