CPU、带宽和磁盘告警如何验收？香港服务器监控通知的指标联动与测试方法

单看某一项指标，很容易把正常波动误判成故障：CPU 使用率升高，可能是计算任务增加，也可能是磁盘等待；带宽接近上限，可能是业务流量增长，也可能是备份或日志传输；磁盘空间下降，则不一定代表磁盘 I/O 已经拥堵。因此，香港服务器监控告警验收不能只检查“有没有收到通知”，还要把指标变化、关联指标、告警触发时间、通知内容和恢复状态放在同一时间轴内核对。

可执行的验收标准是：CPU、带宽、磁盘三类指标都能采集到连续数据；达到规则条件后能够触发对应级别的告警；通知中包含主机、指标、当前值、阈值、开始时间和恢复状态；同一事件不会重复轰炸；异常解除后能够收到恢复通知。最后还要通过一次受控复测，确认监控数值和通知结果一致，而不是只用一条手工测试消息证明链路可用。

先定义验收对象和观察窗口

验收前应先确认监控系统实际观察的是什么。CPU、带宽、磁盘通常包含两类不同问题：

• 资源使用量：CPU 百分比、网卡吞吐、磁盘已用空间。
• 资源处理压力：系统负载、运行队列、I/O 等待、磁盘延迟、网络响应时间和错误率。

前者用于发现“用了多少”，后者用于判断“是否已经影响服务”。例如磁盘使用率达到 85%，说明容量风险变高，但不能直接证明磁盘读写已经变慢；CPU 使用率达到 90%，也不能单独证明应用已经不可用。

建立基线

先选取一段没有计划任务、发布、备份或大规模业务波动的正常时间，建议至少观察 30 分钟；如果业务存在明显的日周期，应覆盖一个具有代表性的业务高峰和低谷。记录以下内容：

时间必须统一。香港服务器可以使用香港时间记录，也可以统一使用 UTC，但监控平台、服务器日志、通知渠道和验收记录不能混用时区。每次测试开始前保留一条带时区的时间记录，后续才能准确计算“指标达到条件后过了多久收到通知”。

示例阈值不能替代业务基线

下面的数值可以作为初始验收参考，不代表所有服务器都应使用同一阈值：

CPU 和带宽适合采用“持续时间”条件，避免一次尖峰就触发；磁盘可用空间则要结合增长速度。如果日志正在快速增长，即使当前使用率只有 78%，也可能需要提前告警。

CPU 告警如何验收

CPU 告警验收的重点不是验证某个百分比能否变红，而是确认监控能区分计算密集、系统调用、I/O 等待和应用响应变慢。

正常与异常的判断

例如，某次模拟数据中，CPU 使用率从 42% 升到 88%，用户态占比从 31% 升到 76%，运行队列由 1.2 增加到 6.8，同时接口响应时间由 180 毫秒升到 620 毫秒，错误率从 0.1% 升到 1.4%。这组变化比“CPU 达到 88%”更能说明存在计算资源压力。该数据是用于说明判断方法的示例，不代表某台香港服务器的实测结果。

如果 CPU 使用率达到 90%，但 I/O 等待占比很高、磁盘延迟同步上升，则优先考虑磁盘等待，而不是直接增加 CPU 资源。验收记录中应写明这一点，否则后续可能把 I/O 问题误判为 CPU 告警。

CPU 告警测试方法

CPU 测试可以分成两次：

1. 先测告警链路

在维护窗口内，将测试规则临时调整为容易触发但不会影响生产服务的条件，或者使用监控系统提供的测试告警功能。确认告警名称、级别、接收人、通知内容和恢复消息是否正确。

1. 再测指标采集和持续触发

使用已批准的压测任务或测试业务，在限定的进程数、运行时长和 CPU 占用范围内制造受控负载。不要直接在高峰时段运行无限制的压力命令。测试期间同步记录 CPU、负载、运行队列、响应时间和错误率。

1. 确认持续条件

如果规则设置为“CPU 大于 85% 且持续 5 分钟”，测试期间必须让监控数据连续满足条件，而不是只出现一个高点。若中途降到阈值以下，应确认系统是否按照规则重新计时。

1. 确认恢复条件

停止测试负载后，CPU 应回到基线附近。若恢复规则为“CPU 低于 70% 持续 5 分钟”，则应在恢复条件满足后收到恢复通知，而不是只看到告警状态自动消失。

Linux 服务器上可以使用只读命令辅助对照监控数据。命令是否可用取决于系统已安装的软件包，不能把命令行一次输出直接当成监控平台的连续数据。

date '+%F %T %Z'
uptime
vmstat 1 5

uptime 可查看负载平均值，vmstat 可辅助观察运行队列和 I/O 等待。验收时应比较同一时间段的监控曲线和服务器侧数据，而不是要求两者每个采样点完全相同。采集间隔、统计口径和四舍五入方式不同，出现小幅差异是正常的。

带宽告警如何验收

带宽验收要先确认单位和对象。网卡监控通常显示 Mbps、Gbps 或每秒字节数，流量配额则可能以 GB、TB 统计。MB/s 与 Mbps 不是同一个单位：

• 1 Byte = 8 bit；
• 1 MB/s 约等于 8 Mbps；
• 按十进制估算，1 GB 在 60 秒内传输，对应速率为：1 × 8 × 1000 ÷ 60，约为 133.3 Mbps。

因此，不能看到“每秒 100 MB”就把它记录成“100 Mbps”。验收记录中应写清楚单位、采样周期和入站或出站方向。

带宽告警关注三个关系

第一，比较当前速率与可用能力，而不是只看绝对 Mbps。相同的 200 Mbps，在不同端口能力下代表的风险完全不同。若可用能力为 1 Gbps，200 Mbps 约占 20%；若可用能力为 300 Mbps，则已经接近 67%。

第二，比较入站与出站方向。网站响应、文件分发、备份导出通常会使出站方向上升；大文件上传或同步可能主要提高入站方向。只设置一个“总流量超过阈值”的规则，容易掩盖实际方向。

第三，把带宽曲线和应用结果放在一起看：

例如，模拟数据中，出站速率从 120 Mbps 升至 760 Mbps，接口可用能力按 1 Gbps 估算，利用率约为 76%；如果此时响应时间仍从 200 毫秒升到 900 毫秒、错误率从 0.2%升到 2%，就不应只记录为“流量较大”，而应将其验收为“带宽压力已经影响业务”的联动事件。

带宽测试方法

带宽测试应使用受控数据和明确的停止条件：

1. 先确认测试方向、最大数据量、测试时长和允许的峰值，不要在没有限额的情况下持续传输大文件。
2. 选择业务低峰或专用测试对象，避免测试流量与正常用户请求混在一起。
3. 观察网卡接收速率、发送速率、连接数、响应时间、错误率和告警状态。
4. 让流量持续满足规则要求，例如连续 3 分钟高于参考阈值。
5. 停止传输后，确认带宽曲线回落，并验证告警是否恢复。
6. 在验收记录中标注测试产生的流量，避免以后把这次测试误认为真实业务异常。

如果只是要验证通知路由，不必制造大流量。可以使用临时测试规则或平台的测试事件；如果要验证带宽采集准确性，则必须让接口计数器产生变化，并将监控平台数值与服务器网卡统计进行对照。两者存在采样延迟时，应记录延迟范围，不要简单判定为监控失效。

磁盘告警要分开验收容量和性能

磁盘告警最容易出现“空间告警”和“I/O 告警”混为一谈的情况。文件系统使用率表示还能写入多少数据，I/O 延迟和队列则表示读写请求处理得是否及时。两类告警的触发原因、测试方式和处理优先级并不相同。

容量告警

容量验收至少检查三项：

• 文件系统使用率；
• 可用空间的绝对值；
• inode 使用率。

大量小文件可能导致 inode 接近耗尽，但磁盘容量仍有不少剩余；大型日志或备份文件则可能迅速占满容量。参考规则可以设置为 80% 预警、90% 严重，同时对可用空间设置绝对下限。例如一个容量较小的文件系统，即使使用率尚未达到 80%，剩余空间已经不足以支撑一次正常日志增长，也应提前告警。

只测试“把文件系统写满”并不适合作为常规验收方法，因为可能导致日志无法写入、服务异常或系统进入风险状态。更稳妥的方式是：

• 使用监控平台的阈值模拟或测试事件验证通知链路；
• 在独立测试路径写入明确大小、可删除的测试文件，提前设定停止值；
• 测试对象不能是系统关键目录或数据库数据目录；
• 测试前记录目录和剩余空间，测试后确认文件已清理、空间已恢复；
• 不把根分区写到接近 100%，也不要在生产高峰进行空间制造。

执行任何会写入文件的测试前，应确认备份、影响范围和回滚方式。回滚就是删除测试文件、恢复原有阈值并检查服务状态；如果测试路径属于业务目录，则必须先取得维护授权，不能直接覆盖或删除现有文件。

只读检查可以使用以下命令：

df -hT
df -i

df -hT 用于查看文件系统容量和类型，df -i 用于查看 inode。验收时应核对监控平台中的挂载点是否与命令输出一致，避免监控采集的是某个子目录，而管理员查看的是整个文件系统。

I/O 性能告警

I/O 性能验收重点看以下联动：

• I/O 等待是否升高；
• 磁盘平均延迟是否超过正常基线；
• 队列深度是否持续增加；
• 读写吞吐和 IOPS 是否发生变化；
• 应用响应时间、请求队列和错误率是否同步变差。

典型判断如下：

如果系统安装了 iostat，可以用只读方式辅助观察：

iostat -xz 1 5

该命令是否存在取决于系统是否安装相应工具包。输出中的设备名称、利用率、等待时间和队列数据要与监控平台选择的磁盘设备对应，不能拿系统盘的数据去验证业务数据盘的规则。

I/O 测试应优先使用已有的测试任务或经过批准的压测工具，并限定读写方向、文件大小、并发数和时长。不要在生产数据目录上直接运行未知参数的随机写入测试，也不要为了触发告警而持续制造队列。验收的目标是验证阈值、采集和通知是否匹配，而不是把服务推入不可用状态。

验收通知链路，而不只是发送一条消息

一条合格的监控告警应能还原完整事件。通知内容至少包括：

• 服务器标识和监控对象；
• 指标名称、方向和当前值；
• 触发阈值及持续时间；
• 告警级别；
• 首次触发时间和最近更新时间；
• 关联的 CPU、带宽、磁盘或应用指标；
• 告警唯一编号或指纹；
• 恢复时间和恢复条件；
• 处理入口或监控曲线链接。

通知测试可以按以下顺序执行：

1. 保存当前规则、通知接收人、静默设置和恢复条件。
2. 使用临时测试规则或受控指标变化触发 CPU、带宽、磁盘三类事件。
3. 分别记录监控平台的触发时间、通知服务的发送时间和接收端的到达时间。
4. 检查同一事件是否被重复发送，告警级别是否与规则一致。
5. 让指标恢复，确认恢复通知包含原告警的关联信息。
6. 删除临时规则或恢复原规则，并再次检查规则状态。

如果采集间隔为 60 秒、连续条件为 5 分钟，那么从指标首次达到阈值到收到通知不应简单按“立即”理解。合理的验收目标应拆成两部分：先确认条件持续满足约 5 分钟，再检查采集、计算和消息发送所增加的延迟。可将“触发条件满足后 1～2 个采集周期内收到通知”作为示例目标，具体值应根据平台的采集周期和通知渠道确定。

通知内容中如果只有“CPU 超限”，却没有当前值、阈值、主机和时间，通常不能算完整验收通过。因为接收人无法判断是短时尖峰、持续异常还是恢复中的旧事件。

用测试矩阵形成可复核记录

建议为每次验收建立一张测试矩阵，至少覆盖触发、保持、恢复和异常路由四类结果。

“留证”不等于只截一张通知图片。建议保留同一时间段的监控曲线、服务器侧只读输出、告警事件详情、接收端消息、恢复消息和规则变更前后内容。文件名或记录中包含服务器标识、指标名称、测试开始时间和时区，后续更容易复核。

常见不通过情况及其含义

有曲线，没有通知

可能是通知动作未绑定、接收人配置错误、静默策略生效，或者告警条件实际没有连续满足。先对照告警事件详情，再检查通知路由和抑制设置，不要只重复制造指标波动。

收到通知，但数值和曲线对不上

常见原因包括采集周期不同、平台使用平均值而命令显示瞬时值、监控对象选错、时区不一致或存在聚合延迟。应先统一时间窗口、单位、设备和统计口径，再判断采集异常。

CPU 告警触发，但应用没有变慢

这可能是阈值偏低，也可能是业务仍有足够余量。应检查运行队列、响应时间和错误率。如果关联指标没有变化，不宜直接把它标记为服务故障，但可以将其保留为容量预警。

带宽告警触发，但业务请求没有增加

需要核对出站或入站方向，并查看计划备份、日志传输、更新任务和其他长连接活动。带宽告警说明接口速率达到条件，不自动等于用户访问量增加。

磁盘空间告警正常，但服务仍然变慢

空间与 I/O 性能是不同问题。应查看磁盘延迟、队列、I/O 等待和应用请求队列。如果容量没有接近上限，性能异常可能来自读写争用或其他等待因素，不能只围绕空间阈值反复测试。

只收到触发消息，没有恢复消息

检查恢复阈值是否低于触发阈值、恢复持续时间是否满足、通知模板是否遗漏恢复事件，以及告警是否被手工关闭。没有恢复通知，值班人员无法确认异常是否已经结束，这部分应单独验收。

下一次应同时观察的指标组合

完成一次 CPU、带宽和磁盘验收后，下一轮不要继续孤立地看单项百分比，而应按事件组合建立观察记录：

• CPU 使用率 + 用户态/系统态 + 运行队列 + 响应时间 + 错误率：判断是否为计算资源压力。
• CPU 使用率 + I/O 等待 + 磁盘延迟 + 队列深度 + 请求耗时：区分 CPU 忙碌和磁盘等待。
• 出站带宽 + 入站带宽 + 连接数 + 响应时间 + 超时率：判断带宽压力是否已经影响服务。
• 磁盘使用率 + 可用空间增长速度 + inode + I/O 延迟：同时关注容量耗尽和性能下降。
• 告警触发时间 + 指标达到阈值时间 + 通知到达时间 + 恢复时间：验证监控通知是否真正形成闭环。

当这些指标能够在同一时间轴内相互印证，测试结果、通知内容和恢复状态也能被完整留存时，才能说明香港服务器的监控告警体系不仅“能发消息”，而且具备可判断、可复核和可持续验收的能力。