3. 指标(metric)详解：常见监控指标类型与聚合方式
在数据可视化与运维监控体系中，指标（Metric）是描述系统状态、性能与健康度的核心数据单元。报警规则的制定本质上是围绕指标进行的阈值判断与趋势分析。本章将系统讲解常见监控指标类型及其聚合方式，帮助你在工程案例中准确选择与配置指标。
3.1 常见监控指标类型
监控指标按观测对象可分为五大类：CPU、内存、磁盘、网络与业务指标。每类指标都有其特定的采集方式、单位与报警关注点。
核心原则：选择指标时，优先关注能够直接反映用户体验或系统瓶颈的“黄金信号”（延迟、流量、错误、饱和度），而非所有可采集的指标。
3.1.1 CPU 指标
CPU 指标反映处理器的工作负载与效率，是判断系统是否“卡顿”或“过载”的关键依据。
| 指标名称 | 单位 | 说明 | 典型报警阈值 |
|---|---|---|---|
| cpu.utilization | % | CPU 使用率，表示非空闲时间占比 | > 80% 持续 5 分钟 |
| cpu.user | % | 用户态进程占用 CPU 比例 | > 70% |
| cpu.system | % | 内核态（系统调用）占用 CPU 比例 | > 30% |
| cpu.iowait | % | CPU 等待磁盘 I/O 完成的时间占比 | > 20% 提示磁盘瓶颈 |
| cpu.load.1m / 5m / 15m | 无单位 | 系统平均负载，反映等待队列长度 | > CPU 核心数 × 0.7 |
常见误区：CPU 使用率低并不代表系统空闲。高 iowait 或高上下文切换可能导致 CPU 看似空闲但应用响应缓慢。建议同时监控
cpu.iowait 与 context_switches。
3.1.2 内存指标
内存指标关注物理内存与虚拟内存的使用情况，直接影响进程能否正常分配资源。
| 指标名称 | 单位 | 说明 | 典型报警阈值 |
|---|---|---|---|
| mem.used_percent | % | 已用内存占总内存百分比 | > 90% |
| mem.available | bytes | 可用内存（含缓存与缓冲区可回收部分） | < 总内存 10% |
| mem.swap.used_percent | % | 交换分区使用率 | > 0% 即需关注 |
| mem.cached | bytes | 文件系统缓存大小 | 通常不报警，但骤降可能异常 |
工程经验：在容器化环境中（如 Kubernetes），建议监控
container_memory_working_set_bytes 而非 mem.used_percent，因为容器内存限制基于 working set 计算。
3.1.3 磁盘指标
磁盘指标包括存储空间使用率与 I/O 性能，是数据库、日志系统等有状态服务的核心关注点。
| 指标名称 | 单位 | 说明 | 典型报警阈值 |
|---|---|---|---|
| disk.used_percent | % | 磁盘分区使用率 | > 85% 警告，> 95% 严重 |
| disk.io.read_bytes | bytes/s | 磁盘每秒读取字节数 | 与基线对比，突增或突降 |
| disk.io.write_bytes | bytes/s | 磁盘每秒写入字节数 | 与基线对比 |
| disk.io.util | % | 磁盘 I/O 繁忙时间占比 | > 80% 提示 I/O 瓶颈 |
| disk.inode.used_percent | % | inode 使用率（Linux 文件系统） | > 80% |
3.1.4 网络指标
网络指标衡量数据包传输的速率、错误率与连接状态，对分布式系统与微服务架构尤为重要。
| 指标名称 | 单位 | 说明 | 典型报警阈值 |
|---|---|---|---|
| net.bytes_in / net.bytes_out | bytes/s | 网络接口入/出流量速率 | > 带宽 80% |
| net.packets_dropped | count/s | 丢弃的数据包数 | > 0 持续 1 分钟 |
| net.tcp.connection_count | count | 当前 TCP 连接数 | > 最大连接数 80% |
| net.tcp.retransmit | count/s | TCP 重传率 | > 1% |
3.1.5 业务指标
业务指标直接反映应用层健康度与用户体验，通常由应用代码主动上报。
- 请求量（QPS/RPS）：每秒请求数，反映流量压力。
- 错误率（Error Rate）：HTTP 5xx 或业务错误码占比。
- 响应延迟（Latency）：P50、P95、P99 分位延迟。
- 活跃用户数（Active Users）：当前在线或操作中的用户数。
- 订单/交易成功率：核心业务流程完成比例。
业务指标报警建议：优先使用“错误率”与“P99 延迟”作为核心报警指标，而非平均值。平均值容易掩盖少数慢请求对整体体验的影响。
3.2 指标聚合方式
原始采集的指标数据通常是高频率的时间序列点。在报警规则中，我们需要通过聚合函数将原始数据转换为有意义的统计值，才能与阈值进行比较。常见的聚合方式包括：avg、max、min、sum、count。
3.2.1 聚合方式对比
| 聚合函数 | 含义 | 适用场景 | 示例 |
|---|---|---|---|
| avg | 在时间窗口内取平均值 | CPU 使用率、内存使用率等平稳指标 | avg(cpu.utilization[5m]) > 80 |
| max | 在时间窗口内取最大值 | 峰值检测、延迟上限、突发流量 | max(http.latency_ms[1m]) > 500 |
| min | 在时间窗口内取最小值 | 空闲检测、连接池耗尽前兆 | min(mem.available[5m]) < 1e9 |
| sum | 在时间窗口内求和 | 请求总量、错误总数、流量累计 | sum(http.requests_total[1h]) > 100000 |
| count | 在时间窗口内统计数据点数量 | 数据缺失检测、心跳检测、实例数量 | count(up == 1) < 3 |
3.2.2 聚合窗口与步长
聚合函数必须配合时间窗口使用。窗口大小决定了聚合的平滑程度与报警灵敏度。
- 短窗口（30s ~ 1m）：适合检测瞬时突增或毛刺，但容易产生抖动报警。
- 中窗口（5m ~ 15m）：平衡灵敏度与稳定性，适用于大多数资源指标。
- 长窗口（30m ~ 1h）：用于趋势分析或慢速增长检测，如磁盘使用率。
避坑指南：不要对
count 或 sum 使用过短的窗口（如 10s），否则可能因采集间隔不一致导致数据点数量波动，引发误报。建议窗口至少为采集间隔的 3 倍以上。
3.3 指标聚合与报警规则设计 SVG 架构图
下图展示了从原始指标采集到报警触发的完整数据流，以及不同聚合方式在其中的作用位置。
3.4 聚合方式选择实战案例
以下通过一个实际场景说明如何选择聚合方式：
场景：某电商平台核心交易接口，需要配置报警规则监控其健康度。
- 接口错误率：使用
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01，聚合方式为 sum + rate，窗口 5 分钟。 - 接口 P99 延迟：使用
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 2.0，本质是 max 思想，检测极端延迟。 - 服务器 CPU 使用率：使用
avg(cpu_utilization[5m]) > 85，聚合方式为 avg，避免短时毛刺误报。 - 磁盘空间不足：使用
min(disk_free_bytes[1h]) < 1e10，聚合方式为 min，确保在窗口内任何时候都不会低于阈值。
关键结论：聚合方式的选择取决于你想要检测的“行为特征”。平稳行为用 avg，极端行为用 max/min，累计行为用 sum，存在性检测用 count。没有一种聚合方式适合所有场景，需要根据指标特性与业务目标灵活组合。
3.5 常见聚合错误与避坑
| 错误做法 | 后果 | 正确做法 |
|---|---|---|
对 counter 类型指标直接使用 avg |
数值持续增长，avg 无意义 | 先使用 rate() 或 increase() 转换为速率 |
| 窗口过小导致数据点不足 | 聚合结果为空或抖动剧烈 | 窗口至少为采集间隔的 3~5 倍 |
对 gauge 类型使用 sum 跨实例聚合 |
多实例求和后阈值难以解释 | 使用 avg 或按实例单独报警 |
| 忽略聚合前的数据清洗 | 异常值污染聚合结果 | 在查询中增加 offset 或使用 quantile 剔除极端值 |