跳转至

监控:系统的眼睛和报警器

1. 这一章讲什么

DevOps 八阶段的最后一环。前面所有阶段产出软件,监控回答两个问题:它现在好不好? 以及 用户用得顺不顺? 答案又回流到 Plan 阶段,闭环完成。本章上半是概念框架(监控什么、怎么采、什么数据形态),下半是一个工具的完整解剖——Prometheus,云原生监控的事实标准。

2. 顶层全景

  监控对象四类:  基础设施(机器/容器) | 应用(API/响应/错误率) | 网络(延迟/丢包/带宽) | 用户行为(点击/转化/流失)
  采集两派:      push(被监控方主动推)  vs  pull(监控方定期来抓,如 Prometheus 每 15s 抓一次 /metrics)
  数据四种:      时序(带时间戳的数值) | 日志(逐条记录) | 事件(部署/告警等离散事) | 追踪(跨服务的请求链)
  工具铁三角:    Prometheus(抓+存+查+告警规则) → Alertmanager(分组去重路由通知) + Grafana(画图)

3. 核心原理

3.1 监控什么:四块,且互相牵连

书里强调四块不是并列的清单,而是因果链1:应用跑在基础设施上——CPU 内存耗尽,应用必慢;网络再健康,高延迟丢包也让系统不可用;用户行为数据给性能指标「提供上下文」——弃购率飙升,往回查往往是响应时间变差。单看任何一块都会误诊,合看才是全貌1。

3.2 采集两派:push 与 pull

Push(代理式):被监控系统上装个小代理(agent),定期把数据推给中央系统。例:成百上千台 IoT 设备每 5 秒向 InfluxDB 推温度、电量;StatsD、collectd、Telegraf 都是这一路2。优点:实时性好、适配短命/不可寻址的目标(容器、IoT)、代理主动外连便于穿防火墙。缺点:中央被海量推送打爆的风险、推送端各自为战难集中管控、传输中可能被伪造。

Pull(无代理式):监控方主动定期来抓取——被监控方只暴露一个端点(如 /metrics),监控工具按间隔 scrape。例:Kubernetes 里每个微服务暴露 /metrics,Prometheus 每 15 秒抓一遍;Nagios 也是拉派3。优点:集中控制采集节奏、无代理易管理、只开监控方的连接更安全、服务发现(新服务自动被发现)。缺点:短命任务可能在两次抓取间隙跑完,漏采;目标多了中央轮询压力大。

书里的结论:没有银弹,生产里常用混合模型4——Prometheus 主拉,配 Pushgateway 和 exporter 兼容推的场景。

另一对维度:合成监控(synthetic) vs 真实用户监控(RUM)。合成 = 用脚本定期假装用户操作(登录、搜索、加购),没人用时也在测,提供基线(正常表现参照值)和可用性判断;RUM = 被动收集真实用户的加载时间、点击、会话,反映真实体验但不可预测。例:Swiggy 用合成监控每几分钟从多个城市模拟下单;RUM 能告诉你老款安卓用户加载慢5。

3.3 四种数据模型

四种数据形态各配一个书里的 JSON/表格实例6:

  • 时序:带时间戳的数值(CPU%、延迟),适合画趋势图。例:VM101 每小时一个 CPU 值。
  • 日志:半结构化条目(时间戳/级别/服务/请求ID……)。例:结账服务一条「Payment gateway timeout, 504」。
  • 事件:离散发生的事(部署、告警)。日志记「一直在发生什么」,事件记「特定时刻发生了什么」。
  • 追踪(trace):一个请求跨服务的完整路径,由嵌套的 span 组成。例:HTTP GET /product/123(前端)→ FetchProductDetails(产品服务)→ SQL SELECT product(数据库),靠 traceId 串起来,能定位慢在哪一环6。

3.4 Prometheus 解剖(本章重头)

起步三条命令(书里给的 Docker 方式7):写 prometheus.yml(配 scrape_interval: 15s 和目标 localhost:9090)→ docker run -p 9090:9090 -v ~/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus → 浏览器开 localhost:9090。

架构五件8:

  1. Prometheus Server:抓取引擎(按配置对目标发 HTTP GET 拉 /metrics)+ 内嵌时序数据库(本地磁盘,按「指标名 + 标签」组织)+ 内置 HTTP 服务和 Web UI。
  2. Targets:数据源。静态的在 yml 里写死;动态的靠服务发现。
  3. Service Discovery(SD):自动发现目标——手动改配置不现实。静态列表、file_sd(指向一个 JSON 文件,文件一变 Prometheus 用 inotify 自动重载,不用重启)、http_sd(从 HTTP 端点拉目标列表),还有 kubernetes_sd、ec2_sd 等9。
  4. Alertmanager:独立组件。Prometheus 触发规则后 HTTP POST 给它,它去重、分组、路由(按 severity、team 等标签)到邮件/Slack/PagerDuty/webhook;还能配置抑制规则(某个 critical 告警在时,压掉同类 warning)10。
  5. 可视化:自带 UI 只能跑查询看简图;画图交给 Grafana(它自己不采数,接 Prometheus 当数据源,做实时仪表板和告警)11。

MySQL 监控五步走(主线例子12):Prometheus 每 20 秒 GET localhost:9104/metrics → 装在同一台机器上的 mysqld_exporter 用专用账号连 MySQL 查内部表(连接数、缓存命中率、复制延迟)→ 转成 Prometheus 文本格式 → 带标签(库实例、job 名)返回 → Prometheus 存进 TSDB,供 PromQL/告警/Grafana 用。书附常用 exporter 表:node_exporter(9100,机器指标)、blackbox_exporter(9115,外部探测)、cAdvisor(8080,容器)等13。

四种指标类型,这是 Prometheus 的精华14:

类型 行为 例子
Counter 只增不减(重启归零) http_requests_total 总请求数
Gauge 可增可减,表示瞬时值 当前内存用量、活跃会话数
Histogram 把观测值分桶计数(+总数+总和) 请求时长 ≤1s 有 2 个、≤2.5s 共 4 个
Summary 客户端直接算好分位数 延迟的 95 分位

PromQL 四板斧15:裸查指标名(全部时序)→ 花括号过滤({device="eth0"})→ offset 1h 回看 → 聚合函数(count(...))。告警规则写在单独 yml 里被 rule_files 引用,五个字段:alert(名)、expr(PromQL 触发条件)、for(持续多久才算)、labels(severity 分类)、annotations(给人看的说明)——书里的例子:CPU 使用率超 90% 持续 2 分钟触发 critical 告警16。注意书里那句提醒:规则触发≠人能收到,Alertmanager 没配好,告警只躺在网页上16。

3.5 缺口与 AI

书里自己点的三个现代监控缺口17:高基数标签(给百万用户各记一条 http_requests_total{user_id=...} 会把内存撑爆、查询拖死);告警疲劳(CPU 一冒尖就告警,一天几十条,真故障淹在噪声里——例:阈值 80% 太敏感);时序数据磁盘膨胀、仪表盘设计糟糕误导排障。

AI 的用场:异常自动检测、故障预测(「磁盘按趋势三天后满」)、告警聚合降噪(Moogsoft、Dynatrace Davis AI、Splunk ITSI),目标是从事后响应走向事前预警18。

4. 作者的判断与证据

有出处的:push/pull、四种指标类型、PromQL、Alertmanager 行为均与官方文档一致,且给出可复现的 Docker 安装与 MySQL exporter 实例712。事故与场景例子(Netflix 告警进 Slack、Paytm 封暴力破解 IP)为说明性示例。

作者的判断:「混合模型常用」「AI 是监控的下一步」是行业趋势判断,无对照数据;对商业工具 vs 开源的取舍(省钱但要自己养)描述公允。

我们的补充:「可观测性(observability)」这一业界热词本章参考文献出现了(Observability Engineering 一书)但正文未展开 metrics/logs/traces 三位一体的现代框架(补充,不在书里)。

5. 边界与局限

  • 只演示了 Prometheus + Grafana 的最小闭环;集群级高可用(Thanos、Cortex/Mimir)、长期存储未提。
  • Kubernetes 内部监控(service monitor、operator 模式)未展开。
  • 追踪只在数据模型一节给概念,Jaeger/Zipkin 只在存储清单露名。
  • AI 监控为产品列举式。

6. 可带走的

  1. 监控四类对象:基础设施/应用/网络/用户行为,四者因果相连,单看一块会误诊1。
  2. push 适合短命目标与实时告警,pull 适合集中管控与服务发现;生产常用混合234。
  3. 数据四种形态:时序/日志/事件/追踪,排查问题常常要四种合看6。
  4. Prometheus = 抓取 + 时序库 + PromQL + 告警规则;Alertmanager 管通知,Grafana 管画图811。
  5. 服务发现让「目标列表」不用手写;file_sd 改文件即生效9。
  6. 指标选型:累计用 Counter,瞬时用 Gauge,延迟分布用 Histogram/Summary14。
  7. 告警规则五字段:alert/expr/for/labels/annotations;阈值加 for 持续时间,是防告警疲劳的第一招16。
  8. exporter 是翻译官:MySQL、机器、容器都有现成 exporter,装上即暴露 /metrics13。

7. 原文地图

主题 原书章 原文位置
监控阶段定位与四大焦点 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:51(搜「Monitoring phase in DevOps」) · text/15-ch10-10-monitoring-in-devops.txt:62(搜「Application Performance Monitoring」)
监控的重要性五条 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:101(搜「Visibility」)
监控目标(可用性 99.99%) 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:138(搜「High availability」)
四类监控对象与互相牵连 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:161(搜「What to monitor」) · text/15-ch10-10-monitoring-in-devops.txt:231(搜「applications run on infrastructure」)
push vs pull 机制与对照 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:257(搜「Push (Agent)-based」) · text/15-ch10-10-monitoring-in-devops.txt:299(搜「Comparison of push-based」)
合成监控 vs RUM 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:347(搜「prescripted transactions」)
指标清单表 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:401(搜「CPU utilization」)
四种数据模型(含 trace 例) 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:393(搜「the time-series data model, log data」) · text/15-ch10-10-monitoring-in-devops.txt:492(搜「storing end-to-end request」)
工具三类与三巨头 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:561(搜「three main types」) · text/15-ch10-10-monitoring-in-devops.txt:596(搜「originally developed by SoundCloud」)
Prometheus 安装三步 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:639(搜「scrape_interval: 15s」)
架构五件 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:659(搜「Architecture overview」)
MySQL exporter 五步 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:753(搜「mysqld_exporter」)
四种指标类型 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:814(搜「only increases over time」)
PromQL 四板斧 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:842(搜「node_network_receive_bytes_total」)
服务发现(file_sd inotify) 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:875(搜「file_sd_configs」)
告警规则五字段 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:926(搜「HighCPUUsage」)
缺口与 AI 10 - Monitoring in DevOps text/15-ch10-10-monitoring-in-devops.txt:984(搜「Gaps need to be filled」)

  1. 出处:「10 - Monitoring in DevOps」第 226–239 段(text/15-ch10-10-monitoring-in-devops.txt:231,搜「applications run on infrastructure」)。 ↩↩↩

  2. 出处:「10 - Monitoring in DevOps」第 257–282 段(text/15-ch10-10-monitoring-in-devops.txt:262,搜「every 5 sec」)。 ↩↩

  3. 出处:「10 - Monitoring in DevOps」第 284–334 段(text/15-ch10-10-monitoring-in-devops.txt:291,搜「scrapes metrics every 15 s」)。 ↩↩

  4. 出处:「10 - Monitoring in DevOps」第 336–340 段(text/15-ch10-10-monitoring-in-devops.txt:337,搜「hybrid model」)。 ↩↩

  5. 出处:「10 - Monitoring in DevOps」第 342–382 段(synthetic :363 搜「Swiggy」;RUM :372 搜「passive and reactive」)。 ↩

  6. 出处:「10 - Monitoring in DevOps」第 391–525 段(日志 :460 搜「Payment gateway timeout」;追踪 :497 搜「traceId」)。 ↩↩↩

  7. 出处:「10 - Monitoring in DevOps」第 627–657 段(text/15-ch10-10-monitoring-in-devops.txt:639,搜「scrape_interval: 15s」)。 ↩↩

  8. 出处:「10 - Monitoring in DevOps」第 659–750 段(server :666 搜「retrieval engine」;Grafana :739 搜「visualization」)。 ↩↩

  9. 出处:「10 - Monitoring in DevOps」第 690–707、854–908 段(Kubernetes SD :696;file_sd :893 搜「inotify」)。 ↩↩

  10. 出处:「10 - Monitoring in DevOps」第 707–732 段(text/15-ch10-10-monitoring-in-devops.txt:711,搜「group them, silence similar alerts」)。 ↩

  11. 出处:「10 - Monitoring in DevOps」第 734–749 段(text/15-ch10-10-monitoring-in-devops.txt:740,搜「Grafana, like state-of-the-art visualization tools, shines」)。 ↩↩

  12. 出处:「10 - Monitoring in DevOps」第 752–796 段(text/15-ch10-10-monitoring-in-devops.txt:756,搜「every 20 sec」)。 ↩↩

  13. 出处:「10 - Monitoring in DevOps」表 10.6(text/15-ch10-10-monitoring-in-devops.txt:780,搜「Node exporter」)。 ↩↩

  14. 出处:「10 - Monitoring in DevOps」第 798–837 段(Counter :814;Gauge :819;Histogram :824;Summary :835)。 ↩↩

  15. 出处:「10 - Monitoring in DevOps」第 839–852 段(text/15-ch10-10-monitoring-in-devops.txt:842,搜「node_network_receive_bytes_total」)。 ↩

  16. 出处:「10 - Monitoring in DevOps」第 910–943 段(text/15-ch10-10-monitoring-in-devops.txt:926,搜「HighCPUUsage」;:942 搜「cannot receive any notification」)。 ↩↩↩

  17. 出处:「10 - Monitoring in DevOps」第 984–993 段(text/15-ch10-10-monitoring-in-devops.txt:987,搜「millions of users」;:989 搜「hundreds of irrelevant notifications」)。 ↩

  18. 出处:「10 - Monitoring in DevOps」第 994–1003 段(text/15-ch10-10-monitoring-in-devops.txt:997,搜「Moogsoft」)。 ↩