波仔
☁️ 第五章 驱动云服务的技术
📄 一句话概括

监控系统干的事可以拆成三步：采集（按间隔取数）、判定（比对阈值产生事件）、通知（按升级策略找人）。教材举 Zabbix 作例子，是因为它把这三步都做成了开源产品。而监控里最容易被忽略、也最容易出事的一点是：告警太多等于没有告警——把该响的阈值设准，比多装几套监控工具重要得多。

📝 本节和前面几节的关系

上一节讲【管理这套流程怎么转】，这一节讲流程要靠什么数据来驱动——因为【有没有出事】这件事，不能靠人去看。

它接着 控制大量服务器的机制：那一节讲管理工具要做六件事（台账、监控、批量下发、远程控制台、固件统一、告警聚合），这一节把其中的【监控】那一项展开了。它也回应 5-6——服务台要先知道出事了才能受理，而它知道的方式就是监控。

一、监控的三步，缺一步都不成立

步骤 做什么 例子
采集 按固定间隔去被监控对象那里取数 每 60 秒读一次 CPU 使用率
判定 拿模板里的阈值比对，超了就产生事件 使用率 > 90% 持续 5 分钟
通知 按升级策略发给对应的人 先发值班，30 分钟没人接再升级

三步里最容易做错的是第二步和第三步：

本节 Demo 里那句【持续 5 分钟】的条件，就是为解决第二种情况设计的：一次瞬时尖峰（比如一个批处理任务刚启动）不该叫醒人，持续超标才说明有问题。这一个条件就能砍掉大半的无效告警。

二、动手 Demo：100 台服务器的数据量账

看到什么算成功：

==================================================================================================
【Demo 7】大量服务器的管理：Zabbix
==================================================================================================
  监控系统干的事可以拆成三步：采集、判定、通知。
  Zabbix 是这三步都做成开源产品的那一类里用得最广的一个。

  【一】三步各自在做什么

  步骤        做什么                                  例子
  --------------------------------------------------------------------------------------------
  采集        按固定间隔去被监控对象那里取数          每 60 秒读一次 CPU 使用率
  判定        拿模板里的阈值比对，超了就产生事件      使用率 > 90% 持续 5 分钟
  通知        按升级策略发给对应的人                  先发值班，30 分钟没人接再升级

  关键在【持续 5 分钟】这种条件：没有它，一次尖峰就会叫醒人。
  告警太多 = 没人看告警，这是监控系统最常见的死法。

  【二】算一笔数据量的账（100 台服务器，每台 50 个监控项）
    监控项总数 = 100 x 50 = 5,000 个

  采集间隔        每天数据点            每天占用        一年占用
  ----------------------------------------------------------------------------------
  60 秒           7,200,000 个          432 MB          157.7 GB
  300 秒          1,440,000 个          86 MB           31.5 GB

  （按每条历史约 60 字节估。真实库会再压缩，但量级就是这样。）
  所以监控的成本不在软件许可，在【你打算存多久、采多细】。
  常见做法：原始数据留 7 ~ 30 天，之后只留每小时或每天的平均值。

  【三】2026 现状
    Zabbix 8.0 LTS 计划于 2026 年 10 月发布（官方路线图），
    这一版的三个重点：接入 OpenTelemetry（把日志和链路追踪一起收进来）、
    官方手机 App、以及事件关联引擎（自动合并重复告警）。
    当前仍在维护的 LTS 是 7.0，短期版本是 7.4 系列。
    方向很清楚：从【指标监控】走向【可观测性】。

读结果：

三、从「指标监控」到「可观测性」

本节 Demo 第三段的那句话，说的是这个领域正在发生的一次转变。用一张表看得最清楚：

阶段 主要采集什么 能回答什么问题
指标监控 数字（CPU、内存、流量） 有没有出事、什么时候开始
日志监控 文本（程序输出的记录） 出事时程序说了什么
链路追踪 一次请求经过哪些环节 慢在哪一环

这三样合起来叫【可观测性】，它的关键词是【合起来】——过去它们常常是三套系统，各查各的。

为什么必须合起来：一个请求变慢了，指标告诉你【这台机器 CPU 高】，日志告诉你【这里报了个超时】，链路追踪告诉你【慢在第三个服务调用】——只有把三样对上，才能定位到原因。只有指标的时候，你只知道【谁病了】，不知道【病在哪】。

这也是 2026 年监控工具都在往一个方向走的原因：Zabbix 这版的重点之一就是接入 OpenTelemetry（一个统一的采集标准），把日志和链路追踪一起收进来——从【监控某台机器】变成【观察整个系统】。

30 秒实验

打开你们公司（或任意一家云服务商）的监控面板，做两件事：

  1. 找出【监控项总数】（Zabbix 的面板上直接有这个数字，其他工具也有类似的）。
  2. 看默认的采集间隔是多少秒。

做完这个，你可以自己算一遍本节的两张表：把监控项总数乘以（86400 ÷ 采集间隔），就是每天的原始数据点数量。这个数字很有用——它让你能预判【监控数据库能撑多久】，也让你在需要优化时知道该动哪几个采集项，而不是笼统地说【监控太重了】。

常见误区

  1. 错误：监控项当然是越多越好，什么都采集起来。——纠正：采集是有成本的，而且成本落在两处：存储（本节算过，100 台机器按 60 秒采集就是一年 157.7 GB）和人的注意力（多一个监控项就多一条可能报警的规则）。真正有用的监控项，是【与业务指标直接相关的那几十个】——CPU、内存、磁盘、网络这些是基础项，但真正要精心设置的，是【这个服务正常工作时应该是什么样】。 采集一堆没人看的指标，只是让报表变长。

  2. 错误：告警应该是【越灵敏越好】。——纠正：告警的价值在于【被响应】，不在【被发出】。一天发五百条告警的系统，实际效果等于没装——因为所有人都会自动忽略它，真正的那一条也淹在里面。所以正确的方向是反向的：先把告警数量降到人能处理的程度（本节 Demo 里的【持续 5 分钟】就是把瞬时波动过滤掉），再让剩下的每一条都值得看。

  3. 错误：装了监控软件，出事就能第一时间发现。——纠正：监控只能发现【你事先想到要监控的东西】。如果某个业务指标从来没被采集过，它坏了监控也不会响——你会从用户那里得知。所以监控系统真正的功夫在设置阶段：想清楚【这个服务正常的样子是什么、坏掉的时候哪个数字会变】。没有这一步，装多少工具都只是摆设。

  4. 错误：监控数据当然是留得越久越好，说不定以后要用。——纠正：保留期是一个明确的成本决定（本节算的那两张表就是依据）。而且时间越久的数据，被用到的概率越低、需要的精度也越低——三个月前某一秒的 CPU 使用率，几乎没有人会去查；但三个月前【每天的平均值】可能在做容量规划时很有用。所以标准做法是分层保留：近期留原始粒度，远期只留聚合值。这跟备份策略里的【全量 + 增量】是同一个思路。

自测三问（点开对答案） 1. 为什么【持续 5 分钟】这样的条件能大幅减少无效告警？ —— 因为**它把【瞬时波动】和【持续异常】区分开了**。系统在正常运行时，CPU 会因为一个批处理任务、一次垃圾回收而瞬间冲高——**这是正常现象，不需要人处理**。但如果是真正的问题（内存泄漏、死循环、流量被打），**它不会只持续一秒，而会一直维持在异常水平**。所以加上【持续 N 分钟】这个条件，**等于给告警加了一道【这是不是一个真问题】的过滤**——代价是发现时间晚了几分钟，换来的是告警可信。 2. 为什么说监控的成本不在软件许可，而在【存多久、采多细】？ —— 因为**软件本身（比如 Zabbix）是开源的，不花钱**，而**数据是要落盘的**。本节算过：100 台机器 × 50 个监控项，按 60 秒采集，一年就是 157.7 GB——**这还只是 100 台**。到了几千台的规模，**存储和查询的开销会变成一笔实实在在的支出**。而且这笔钱**不是一次性的**：数据一直存着，就一直占着磁盘、也一直拖慢查询。所以监控设计里【保留策略】比【装什么软件】重要。 3. 为什么【指标、日志、链路追踪】要合起来看，光有指标不够？ —— 因为**它们回答的是不同层的问题，而定位故障需要把这几层串起来**。指标告诉你【哪台机器、什么时候不对劲】（发现问题），日志告诉你【程序当时说了什么】（看到现象），链路追踪告诉你【这次请求卡在哪一环】（定位环节）。**只有指标的时候，你知道【谁病了】但不知道【病在哪】**——于是排查只能靠猜和试。合起来看的意义就是**把【发现问题】和【定位原因】这两步连起来**，缩短从告警到修复的时间（也就是 5-6 里说的 MTTR）。

相关笔记