香港服务器出现 CPU 90% 告警，并不一定代表业务已经故障；带宽达到高利用率，也不等于请求必然失败；磁盘 I/O 忙碌度升高，更不能单独证明存储响应变慢。减少重复告警的关键，不是把阈值简单调高，而是同时设置持续时间、分级告警、恢复边界和关联指标。

一个可执行的起点是：CPU 按“利用率 + 单核情况 + iowait/steal”判断，带宽按实际可用上限分别观察进出方向，磁盘 I/O 同时观察设备忙碌度、I/O 延迟和队列。下面的 70%、85% 等数值只能作为初始配置，不能视为香港服务器的固定性能标准，最终应由业务高峰期的历史基线校准。

先定义告警要解决的问题

监控阈值通常服务于三种不同目的，不能用同一个数字处理：

• 容量预警：资源正在接近上限，需要安排扩容、限流或业务调整。
• 故障告警：资源异常已经伴随请求延迟、错误率或连接失败。
• 趋势观察：指标持续上升，但当前尚未影响业务，用于容量规划。

如果所有告警都直接通知值班人员，短时突发、批处理任务和多个关联指标就会产生大量重复消息。建议将告警分成两级：

• Warning：连续超过阈值一段时间，只进入工单、群组或低优先级通知。
• Critical：超过更高阈值，并且持续时间更短，才触发高优先级通知。

告警条件应尽量使用稳定标签，例如 instance、resource、device 和 direction。不要把当前数值、时间戳或动态描述放进标签，否则同一问题每次数值变化都会被监控系统识别成新的告警。

三类指标的含义和判断方法

CPU：平均利用率不能代替核心级判断

CPU 总利用率可以反映整体压力，但平均值会掩盖单核饱和。例如多核香港服务器上，一个单线程任务持续占满一个核心，整体平均利用率可能仍然不高。

建议同时观察：

• 总体 CPU utilization；
• 单个逻辑核心的最大利用率；
• iowait，判断 CPU 是否在等待磁盘 I/O；
• steal，判断虚拟化环境中是否存在调度等待；
• load average，并按逻辑 CPU 数量归一化。

CPU 利用率持续超过 85%，且业务延迟、队列长度或错误率同步上升，通常比“瞬时达到 95%”更值得升级处理。若只有某个批处理进程在固定时间运行，业务指标正常，可以保留记录但不必立即触发高优先级告警。

带宽：先确认上限，再计算利用率

带宽告警不能脱离实际可用上限。可以使用以下方式计算总体利用率：

带宽利用率 = 8 × (接收速率 + 发送速率) / 可用带宽上限

其中，接收和发送速率应来自同一时间窗口的接口计数器。如果业务或计费规则分别限制进出方向，则应分别计算：

接收利用率 = 8 × 接收速率 / 接收方向上限
发送利用率 = 8 × 发送速率 / 发送方向上限

不要直接把接口名称、标称端口速率或某个历史测试值当作可用上限。应以实际配置的带宽上限、限速策略或经核验的监控资产信息为准。

带宽持续达到 70%～85% 时，通常适合进入容量预警；是否升级为故障告警，还要看丢包、连接失败、请求延迟和业务错误率。带宽高但业务正常，可能只是正常高峰；带宽不高但访问变慢，则可能存在方向判断错误、接口重复统计或其他未被当前指标覆盖的问题。

还要注意虚拟接口、桥接接口和容器接口可能重复计算流量。若同时统计物理接口和其上的虚拟接口，结果会被放大。应先确定纳入统计的接口集合，再固定过滤规则。

磁盘 I/O：忙碌度、延迟和队列要结合

磁盘 I/O 忙碌度表示设备有多长时间处于处理 I/O 的状态，并不等于业务一定变慢。顺序 I/O 可能在较高忙碌度下仍保持稳定响应，而随机 I/O 可能在忙碌度尚未达到很高时就出现延迟。

建议至少观察：

• io_time 或设备 busy ratio；
• 读 I/O 延迟和写 I/O 延迟；
• I/O 请求队列长度；
• 读写 IOPS 与吞吐量；
• iowait 是否同步上升。

磁盘忙碌度超过 70% 可以作为观察信号，超过 85% 且持续存在时进入高优先级候选。但真正触发故障告警，最好增加延迟或队列条件。例如：

设备 busy ratio > 85%
并且
I/O 延迟高于历史高分位基线

延迟阈值不宜直接照搬固定毫秒数。应在相同业务负载下采集基线，例如记录正常高峰期的 P95 延迟，再判断是否持续明显偏离。若磁盘 busy 很高但延迟和业务响应正常，可以先作为容量信号；若 busy 不高但延迟显著升高，则应优先检查采集对象、设备映射和指标完整性。

一组可落地的初始阈值

下表适合用于首次配置，前提是已经确认采样指标、接口范围和业务高峰时间。它不是性能承诺，也不能替代实际基线。

如果业务流量具有明显突发性，可以使用较短的 1 分钟窗口观察峰值，同时用 5～10 分钟窗口决定是否告警。短窗口适合发现突发，长窗口适合抑制抖动，二者不应混为一个条件。

以 Linux 和 Prometheus 为例设置规则

以下示例假定香港服务器运行 Linux，并通过 node_exporter 提供基础指标。不同采集器的指标名称、设备标签和接口标签可能不同，部署前应先确认实际存在的指标，不要仅凭示例名称创建规则。

groups:
  - name: hong-kong-server-resource-recording
    interval: 30s
    rules:
      - record: instance:cpu_utilisation:ratio5m
        expr: |
          1 - avg by (instance) (
            rate(node_cpu_seconds_total{mode="idle"}[5m])
          )

      - record: instance:network_traffic_bps:5m
        expr: |
          sum by (instance) (
            rate(node_network_receive_bytes_total{device!="lo"}[5m])
            +
            rate(node_network_transmit_bytes_total{device!="lo"}[5m])
          ) * 8

      - record: instance:disk_busy:ratio5m
        expr: |
          max by (instance, device) (
            rate(node_disk_io_time_seconds_total{
              device!~"^(ram|loop|fd|sr|dm-).*"
            }[5m])
          )

这里的网络规则只是示范接口流量的计算方式。若服务器存在桥接、虚拟接口或容器接口，应根据实际拓扑修改 device 过滤条件，否则可能重复计算。

带宽告警还需要一个已经核验过的容量指标，例如 server_network_capacity_bps。这个指标应来自资产配置或可靠的监控数据，不能随意填入某个带宽数值。

groups:
  - name: hong-kong-server-resource-alerts
    interval: 30s
    rules:
      - alert: HongKongServerCPUWarning
        expr: instance:cpu_utilisation:ratio5m > 0.70
        for: 10m
        labels:
          resource: cpu
          severity: warning
        annotations:
          summary: "CPU 利用率持续偏高"
          description: "instance={{ $labels.instance }} CPU 利用率已连续超过 70%"

      - alert: HongKongServerCPUCritical
        expr: instance:cpu_utilisation:ratio5m > 0.85
        for: 5m
        labels:
          resource: cpu
          severity: critical
        annotations:
          summary: "CPU 利用率持续过高"
          description: "instance={{ $labels.instance }} CPU 利用率已连续超过 85%"

      - alert: HongKongServerBandwidthCritical
        expr: |
          instance:network_traffic_bps:5m
          / on(instance) server_network_capacity_bps > 0.85
        for: 5m
        labels:
          resource: bandwidth
          severity: critical
        annotations:
          summary: "带宽利用率持续过高"
          description: "instance={{ $labels.instance }} 带宽利用率已连续超过 85%"

      - alert: HongKongServerDiskBusyCritical
        expr: instance:disk_busy:ratio5m > 0.85
        for: 5m
        labels:
          resource: disk_io
          severity: critical
        annotations:
          summary: "磁盘 I/O 忙碌度持续过高"
          description: "instance={{ $labels.instance }} device={{ $labels.device }} 忙碌度已连续超过 85%"

磁盘规则不建议只依赖 busy ratio 直接通知值班人员。实际使用时，可以把它作为父级资源告警，再与 I/O 延迟或队列指标联动；如果监控系统支持条件组合，应优先采用“busy 高且延迟高”的组合条件。

修改规则前，可使用与 Prometheus 版本匹配的工具检查语法：

promtool check rules alert-rules.yml

该命令只做规则检查，不会修改服务器配置。检查通过后，还应在监控页面确认查询确实返回目标实例和设备，避免因标签不匹配导致表达式为空。

通过持续时间和分组减少重复告警

使用 for 过滤短时尖峰

没有 for 的阈值规则会对每次短时波动立即告警。常见的做法是：

• CPU 和带宽短时突发：使用 5～10 分钟持续时间；
• 磁盘 I/O：根据业务写入周期设置，避免把正常批处理当成故障；
• 采集间隔较长时，不要把 for 设置得短于一个合理采样窗口。

for 的作用是减少瞬时触发，但不能解决阈值在临界点上下反复跳变的问题。

使用恢复边界避免反复触发

如果触发阈值是 85%，恢复阈值仍设置为 85%，指标在 84%～86%之间波动时容易反复触发和恢复。支持迟滞设置的监控系统，可以采用：

• Critical 触发：85%；
• 恢复条件：75%；
• Warning 触发：70%；
• Warning 恢复：60%。

如果系统不支持恢复阈值，应通过较长的 for、平滑窗口或记录规则实现，不能简单缩短重复通知间隔。

分组时不要把严重级别作为分组键

可以按实例、资源类型和方向分组，将同一时间窗口内的多条消息合并：

route:
  group_by:
    - instance
    - resource
    - direction
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h

这里的时间值是降低通知噪声的起始建议。生产环境应根据故障响应要求调整。severity 不建议放进 group_by，否则同一实例同一资源的 Warning 和 Critical 会被拆成两组。

对于同一实例上由一个根因引起的多个告警，可以使用抑制关系。例如磁盘 I/O 繁忙同时造成 CPU iowait 升高时，可以将磁盘告警作为主要通知，把关联的 iowait 告警降级为事件记录。但不能无条件合并 CPU、带宽和磁盘告警，否则可能掩盖真正的独立故障。

阈值上线前后的验证

上线前核对采集数据

在 Linux 环境中，以下命令可用于只读检查基础指标，前提是系统已经安装相应工具：

nproc
ip -s link
iostat -xz 5 3

• nproc 用于确认逻辑 CPU 数量，辅助判断平均 CPU 是否掩盖单核压力。
• ip -s link 用于查看接口收发字节、错误和丢包计数。
• iostat -xz 5 3 用于观察设备忙碌度、延迟和队列变化，iostat 通常由 sysstat 提供。

这些命令不会修改配置，但采样结果只代表执行时段，不能证明全天性能。若要据此调整阈值，应记录采样时间、业务负载、目标实例、接口和设备范围。

上线后观察告警质量

阈值变更后，至少应覆盖一个业务高峰和一个低谷，再判断是否需要调整。业务存在明显周期时，建议保留足够长的历史窗口，比较正常高峰的 P95 或 P99，而不是只看一次峰值。

重点观察四项：

1. 原始指标是否真的持续越过阈值。
2. 同一问题是否仍产生多个不同指纹的告警。
3. 告警发生时，业务延迟、错误率或连接数是否同步异常。
4. 恢复后是否只发送一次恢复通知，是否仍不断重复提醒。

如果告警频繁出现但业务完全正常，先确认是否把正常批处理、带宽高峰或设备忙碌度误判为故障，再考虑提高阈值或降低通知级别。如果业务已经变慢而三项资源指标都不高，则不能继续调高阈值，应检查采集对象、标签过滤和当前指标是否覆盖了实际瓶颈。

用什么条件判断需要扩容或改规则

香港服务器的阈值调整可以按以下边界执行：

• 资源指标高、业务指标正常、且只出现在可预期高峰：保留 Warning，继续积累基线，不急于触发故障通知。
• 资源指标持续高，同时延迟、错误或连接失败上升：保留 Critical，并进入容量或故障处理流程。
• 告警数量很多但根因相同：优先调整 for、分组键、抑制关系和恢复边界，而不是盲目提高阈值。
• 业务异常但资源指标不高：先修正接口、设备、方向或采样范围，避免用错误的监控数据作容量判断。

如果需要通过压测或合成流量修订阈值，应同时记录测试节点、目标香港服务器、测试时间、操作系统和采集版本、施加的负载方法、采样周期及样本数量。一次测试只能说明该时间、该环境和该负载模型下的表现，不能直接推导全天候容量，也不能替代真实业务高峰数据。