第 10 章 · 可观测性与监控

第 10 章 · 可观测性与监控

系统上线后，一切正常吗？出问题时，到底发生了什么？响应变慢，慢在哪一环？这是可观测性要回答的三个问题。本节从"监控"到"可观测性"的认知升级讲起，建立三大支柱与 SLI/SLO/错误预算的量化框架，再进入 Prometheus、Grafana、日志与 APM 的工程实践。

学习目标

• 区分监控与可观测性，说出三大支柱各自回答的问题
• 用 SLI/SLO/错误预算量化可靠性，判断发布是否应冻结
• 描述 Prometheus 拉取模型、四种指标类型与告警链路
• 说清 Grafana 的定位与局限，理解 ELK 与 APM 的组成

一、从监控到可观测性

监控（Monitoring） 是"你提前知道要问什么问题，然后持续检查答案"：预先定义一组指标（CPU、错误率、延迟），盯着仪表盘看它们是否越界。可观测性（Observability） 则允许你提出事先不知道的问题——通过系统对外暴露的信号（指标、日志、链路追踪），在任何异常发生后反向推断出内部状态。

一句话区分：监控回答"它是否坏了"，可观测性回答"它为什么坏、坏在哪里"。监控是手段，可观测性是能力。

可观测性的三大支柱各有分工，通常协同使用：

定位故障的标准打法：先看指标发现异常（"错误率上升"），再看日志找到报错细节（"数据库连接超时"），最后用链路追踪定位慢调用发生在哪个服务（"订单服务 → 库存服务耗时 3 秒"）。三大支柱是互补关系，不是互相替代。

二、SLI、SLO 与错误预算

要让可靠性可度量、可管理，需要一套量化体系：

• SLI（Service Level Indicator，服务水平指标）：衡量服务质量的具体数值，如可用性（成功请求/总请求）、延迟（P99 响应时间）、错误率。
• SLO（Service Level Objective，服务水平目标）：为 SLI 设定的目标值，如"可用性 ≥ 99.9%"或"P99 延迟 ≤ 200ms"。SLO 是承诺的边界，不是越高越好——越高的 SLO 意味着越大的成本与运维投入。
• 错误预算（Error Budget）：允许失败的空间，等于 100% 减去 SLO。若 SLO 为 99.9%，错误预算就是 0.1%，即每月（约 30 天）允许的不可用时间约 43 分钟（30 × 24 × 60 × 0.1% ≈ 43 分钟）。

错误预算的工程价值在于它把"可靠性"变成了可花的预算：只要预算还有剩余，团队就可以大胆发布新功能；一旦预算耗尽，立即冻结发布，优先修复稳定性。这化解了"开发要快"与"运维要稳"的天然矛盾——用同一个数字说话，而不是靠争吵。

实践中注意：SLA（Service Level Agreement）是对外签署的合同承诺，通常比内部 SLO 更宽松（SLA ≥ SLO 才有缓冲），违反 SLA 要承担赔偿等后果。SLO 是内部的工程目标，SLA 是外部的契约。

三、Prometheus：指标采集与告警

Prometheus 是云原生领域的事实标准监控系统，核心设计是拉取模型（Pull）：Prometheus 服务器主动、周期性地从目标（应用暴露的 /metrics 端点）抓取指标，而不是应用主动上报。拉取模型的好处：监控端掌控节奏、目标宕机立刻可见（数据消失本身就是告警信号）、无需在应用侧维护推送通道。

四种指标类型是面试与实操的高频考点：

Prometheus 与告警的完整链路：exporter/应用 /metrics → Prometheus 拉取并存储 → 告警规则（Alerting Rules）在 Prometheus 内评估 → 触发时发给 Alertmanager → Alertmanager 去重、分组、抑制、静默后按路由发给接收方（邮件、钉钉、Slack、Webhook 等）。

Alertmanager 的四项核心能力：分组（同类告警合并成一条通知，避免告警风暴）、抑制（上级故障时抑制下级冗余告警）、静默（维护窗口内主动屏蔽某类告警）、路由（按标签把不同告警分发到不同接收方）。

场景题：短任务（批处理、定时 Job）在拉取模型下可能"活不到下一次被抓取"，此时用 Pushgateway 让任务结束后主动推送一次指标。它只适合这种生命周期短暂的任务，不适合常规服务。

四、Grafana：可视化层

Grafana 是流行的可视化平台，最关键的认知是：Grafana 不存储数据。它只负责连接数据源（Data Source）、查询并渲染图表。常见数据源包括 Prometheus（指标）、Loki（日志）、Elasticsearch、MySQL、InfluxDB 等。

• 默认端口 3000
• 基本单位是面板（Panel），多个面板组成仪表盘（Dashboard）
• 仪表盘可以整体导出为 JSON，实现配置即代码，纳入版本管理
• 支持告警功能，但生产环境通常仍由 Prometheus + Alertmanager 承担告警主力

界面题常问的组件流：数据源 → 查询（PromQL）→ 面板 → 仪表盘。

五、日志与 APM

日志解决"发生了什么"的问题。经典方案是 ELK 栈：Elasticsearch（存储与检索）+ Logstash（采集、解析、转换）+ Kibana（可视化）。云原生场景更轻量的替代是 Loki：只索引日志的标签与元数据，不全文索引日志内容，成本低得多，与 Grafana 无缝集成。采集侧常用 Filebeat、Fluentd、Fluent Bit 等轻量 agent。

APM（Application Performance Monitoring，应用性能监控） 聚焦应用层性能，典型代表是 Datadog、New Relic、SkyWalking。APM 通常采集四类数据：Metrics（性能指标）、Logs（日志）、Events（部署、配置变更等事件）、Traces（链路追踪）。其中 Events 常被忽略但价值很高——"为什么性能突然下降？因为 10 分钟前发了一次新版本"。

以 Datadog 为例的部署形态：每台主机上运行 Datadog Agent，agent 采集宿主机指标与日志，应用通过 SDK 上报自定义指标与链路，所有数据打上 Tags（如 env:prod、service:orders）便于按维度聚合过滤。它本质上是"托管的 Prometheus + Grafana + 日志 + 追踪"全家桶，按主机数与用量计费。

小结

• 监控回答"是否坏了"，可观测性回答"为什么坏"；三大支柱是：指标（是否正常）、日志（发生了什么）、链路追踪（慢在哪里）
• SLO 定目标，错误预算 = 100% − SLO（99.9% ≈ 每月 43 分钟），预算耗尽即冻结发布
• Prometheus 是拉取模型，Counter 只增、Gauge 可增可减、Histogram 可聚合求近似分位数、Summary 客户端算分位不可聚合；短任务用 Pushgateway
• 告警链路：规则评估 → Alertmanager（分组/抑制/静默/路由）→ 接收方
• Grafana 只做可视化不存数据；ELK/Loki 管日志；APM 采集 Metrics/Logs/Events/Traces 四类数据

下一节预告

可观测性解决了"看得见"，接下来要解决"存得下"：数据库的核心概念——SQL 与 NoSQL 如何选型？ACID 与 CAP 到底在讲什么？索引、分片、范式这些高频概念背后的取舍是什么？下一节《数据库核心概念》将建立数据侧的完整认知地图。