一、运维管理到底管什么

系统上线之后，运维的工作可以归成两句话：让系统保持在可用状态，并且让它一直能被改。 落到具体动作上分四大类：

• 运行管理——盯状态、看告警、处理异常。这是日常最花时间的一块。
• 变更管理——装补丁、改配置、上新版本，并且每次都留记录， 因为出事时要能回答【最近改过什么】。
• 容量管理——看资源还剩多少，提前加而不是等着被打满。
• 故障管理——出事了怎么发现、怎么定位、怎么恢复、怎么复盘。

这四块有一个共同前提：你得先有数据。 没有监控数据的运维就是【等用户打电话来告诉你网站挂了】—— 而那时候已经过去太久了。

二、盯什么：六类指标和它们的报警线

监控的对象不多，但每一样都要定一个报警线，不然告警就没有意义：

• CPU——使用率、等待占比；持续超过 90% 就该报。
• 内存——可用量、交换分区使用；交换分区开始被大量占用就是危险信号。
• 磁盘——剩余空间、读写延迟；剩余不足一成要提前报。
• 网络——带宽占用、丢包、重传；接近链路上限就要报。
• 服务——端口通不通、接口返回码；连续两次探测失败就报。
• 日志——错误条数、异常登录；按业务自己定基线。

这里有一个很容易踩的坑：只看机器，不看业务。 CPU 和内存全绿，但用户下单一直失败——这种情况只有业务层的探测能发现。 所以监控要分两层：基础资源层和业务接口层，两层都要有。

三、工具的分界线：传统服务器还是容器

监控工具很多，但选择逻辑其实只有一条：你的服务器是传统形态还是容器形态。

Zabbix 是传统 IT 里被选得最多的那一个：

• 采集方式——被监控端主动上报（agent 模式），也支持 SNMP、IPMI、JMX。
• 配置方式——官方模板，7000 多个模板开箱即用，接一台新机器几乎是填个地址。
• 自带可视化——有，够用；不用另配一套出图系统。
• 最适合——物理机、虚拟机、网络设备混在一起的环境。

Prometheus 加 Grafana 是云原生那一侧事实上的标准：

• 采集方式——服务端定时去拉（pull 模式），天生适配会随时生灭的容器。
• 配置方式——要先理解几个组件怎么串，入门成本更高。
• 可视化——几乎全靠 Grafana，好处是社区有成千上万个现成面板。
• 最适合——Kubernetes 集群和微服务。

两句话总结：物理机多的选 Zabbix，容器多的选 Prometheus。 两者并存也很常见——基础资源交给 Zabbix，容器内部指标交给 Prometheus。

四、Zabbix 为什么还是被选得最多

尽管新工具层出不穷，Zabbix 的位置反而更稳了。几个可以查证的口径：

• 在一份 36 款监控工具的横评排名里，Zabbix 以 9.0 分排第一， 后面是 Datadog 8.4、Netdata 7.9、Dynatrace 7.9、Prometheus 7.4。
• 在金融与制造业这两个保守行业，市场占有率保持在 35% 以上。
• 官方模板数量 7000 多个——不用改业务代码就能接进来，这条是它最大的护城河。
• 新版本内置了异常检测，厂商口径的误报率下降约 40%。

为什么【不用改代码】这么重要？因为一旦要改业务代码才能监控， 这件事就得排进研发的迭代里，而运维排不动研发的期。 能不改代码就接进来，是这类工具在传统企业里活下来的关键。

还有一个现实因素：合规。越来越多的法规要求【能拿出运行记录和时间线】， 监控系统从【方便调试的工具】变成了审计要看的证据来源。

五、动手 Demo：把巡检频次和探测窗口算一遍

监控的巡检频次、以及不同参数下能多快发现故障，是可以直接算的：

n = 24 * 60 // 5
print("  每 5 分钟巡检一次 = 每天 %d 次，每年约 %d 次" % (n, n * 365))
print("  连续 3 次超过阈值：最多 %.0f 分钟发现" % (3 * 5))
print("  探测间隔 15 秒 + 阈值 2 次 = 约 %d 秒判定失联" % (15 * 2))
print("  36 款工具横评：Zabbix 9.0 对 Prometheus 7.4")

实跑输出：

--------------------------------------------------------------------
上线之后，靠什么盯着
--------------------------------------------------------------------
  系统上线不是终点。运行之后的管理分两块：设备本身的状态，和服务的存活。

  盯什么     典型指标                   报警线
  -------------------------------------------------------------
  CPU        使用率、等待占比           持续超过 90%
  内存       可用量、交换分区使用       交换分区开始被大量占用
  磁盘       剩余空间、读写延迟         剩余不足一成
  网络       带宽占用、丢包、重传       接近链路上限
  服务       端口通不通、接口返回码     连续两次探测失败
  -------------------------------------------------------------

  工具上有一条清晰的分界线，看你的服务器是传统形态还是容器形态：

                 Zabbix                       Prometheus + Grafana
  -------------------------------------------------------------------
  采集方式       被监控端主动上报             服务端定时去拉
  配置方式       官方模板，开箱即用           写配置目标、用查询语言
  自带可视化     有，够用                     靠 Grafana 出图
  最适合         物理机、虚拟机、网络设备     容器与微服务集群
  入门成本       低                           要先理解几个组件怎么串
  -------------------------------------------------------------------

  Zabbix 到现在仍然是传统 IT 里被选得最多的那一个：

  口径                   数值                  备注
  -------------------------------------------------------------------------
  七类工具的横评排名     第 1 名（9.0 分）     Datadog 8.4，Prometheus 7.4
  金融与制造业市占       35% 以上              IDC 口径
  官方模板数量           7000 多个             不用改业务代码就能接
  新版本 AI 能力         误报降约 40%          内置异常检测
  -------------------------------------------------------------------------

  小算例：巡检脚本每 5 分钟跑一次，一天 = 24 × 60 ÷ 5 = 288 次；
  把阈值从【CPU 超过 90%】改成【连续 3 次超过 85%】，误报会明显下来，
  代价是发现时间从 5 分钟变成 15 分钟以内。基准值不是拍出来的，是调出来的。

第一行的 288 次说明了监控这条路的代价：它本身就是一笔持续的负载。 第二、三行讲的是同一个权衡——报得越快，误报越多。 把探测间隔和阈值次数调小，发现更快，代价是网络抖一下就报一次假警。 报警线的数字不是拍出来的，是在误报和漏报之间调出来的。

30 秒实验

1. 在你自己的电脑上装一个 Uptime Kuma，加一个网站做监控，看它怎么判断【挂了】。
2. 看一眼你电脑的任务管理器，找出当前占用 CPU 最高的进程，这就是最朴素的监控。
3. 把单位的关键系统列出来，问一句：它们挂了，我们多久能知道？

常见误区

1. 错误：监控就是看 CPU 和内存。——纠正：还要看业务层——CPU 全绿但下单一直失败的情况很常见，基础资源层和业务接口层都要探。
2. 错误：Zabbix 是过时的老工具。——纠正：它在 36 款工具的横评里排第一（9.0 分），在金融与制造业市占 35% 以上，7000 多个模板不用改代码就能接。
3. 错误：报警线定得越严越好。——纠正：报警线太严只会让人把告警静音；告警被忽略比没有告警更危险。

• ☐ 下一节（9-8 服务器的性能管理：检查使用率、修改进程的优先级）

相关笔记

• 穿透DMZ后的防守 —— 上一节说的日志分析，就是这一节运维管理的原料
• 服务器的性能管理 —— 有了监控数据，下一节讲怎么调
• 运营管理的框架（CFIA、ITIL） —— 运维管理的方法论体系
• 性能与更新（性能管理、WSUS、故障命令） —— 监控与补丁在服务器课里的讲法
• 集中管理能提高防御效果 —— 集中监控为什么也是安全措施
• 🕸️ Web技术原理 · 索引