给出磁盘 I/O 利用率 > 80% 的 PromQL 告警表达式。
解读
国内互联网公司在面试 CouchDB 运维/监控岗位时，常把“如何写一条能真实反映磁盘 I/O 瓶颈的 PromQL”作为**区分“只背指标”与“真做过监控”**的试金石。
面试官想确认三点：
- 你清楚 Linux 下磁盘 I/O 利用率到底指什么（iostat 的 %util，即设备处于“有请求在处理”状态的时间占比）。
- 你知道 CouchDB 进程本质还是 Erlang BEAM，不直接暴露块设备指标，因此必须依赖 Node Exporter 的 node_exporter 采集。
- 你能把“>80%”翻译成一条可在 Alertmanager 里直接使用的 PromQL，并附带标签过滤、挂载点排除、速率平滑等工程化细节，而不是随手抄一条“rate(node_disk_io_time_seconds_total[1m])>0.8”交差。
知识点
- node_disk_io_time_seconds_total：Node Exporter 对每个块设备累计的“忙碌时间”，单位秒。
- irate / rate：irate 取最近两个采样点，灵敏；rate 取整个滑动窗口，适合告警。国内生产环境通常用5m 窗口抑制毛刺。
- 标签过滤：
- device=~“sd.|vd.|nvme.*” 排除 loop、dm 等虚拟设备；
- mountpoint!~“.docker.|.kubelet.” 避免容器挂载点误报。
- 聚合策略：CouchDB 节点多为单机多盘或云盘单盘，需按 instance、device 维度保留标签，方便定位。
- 阈值单位：io_time 是“秒/秒”，80% 即 0.8；写 PromQL 时直接跟 0.8 比较即可。
- 告警持续：国内 SRE 规范通常要求持续 5 分钟才 page，所以表达式里用“> 0.8”即可，Alertmanager 的
for: 5m负责抑制抖动。
答案
# 单设备 I/O 利用率 > 80%
- alert: CouchDB_Node_Disk_IO_Util_High
expr: |
rate(node_disk_io_time_seconds_total{device=~"sd.*|vd.*|nvme.*"}[5m]) > 0.8
for: 5m
labels:
severity: critical
team: dba
annotations:
summary: "CouchDB 节点 {{ $labels.instance }} 设备 {{ $labels.device }} I/O 利用率超 80%"
description: "当前值 {{ $value | humanizePercentage }}，持续 5 分钟，可能影响 CouchDB 视图构建与压缩任务。"
若公司要求按节点聚合（只要有一块盘超阈值就报警），可把表达式改为：
max by (instance) (
rate(node_disk_io_time_seconds_total{device=~"sd.*|vd.*|nvme.*"}[5m])
) > 0.8
拓展思考
-
CouchDB 特殊场景：
当触发大视图压缩或数据库压缩（compaction）时，I/O util 会瞬间飙高。为避免误报，可在表达式里串联 CouchDB 自身指标做降噪：( rate(node_disk_io_time_seconds_total{device=~"sd.*|vd.*|nvme.*"}[5m]) > 0.8 and couchdb_compaction_running == 0 )这样只有“非压缩期间”I/O 高才真正告警，体现业务感知能力。
-
云盘场景：
国内阿里云 ESSD、腾讯云 CBS 的底层限速以吞吐/OPS为准，%util 100% 也不一定代表“慢”。高级方案可再叠加rate(node_disk_read_bytes_total[5m]) + rate(node_disk_written_bytes_total[5m]) > 240MB/s做双条件告警，既看 util 又看吞吐，防止云盘“假忙”。
-
面试加分句：
“如果贵司 CouchDB 跑在 K8s 里，我会用 kube-prometheus-stack 的 ServiceMonitor 把 CouchDB 的 metrics 与 node_exporter 一起采集，然后在 Grafana 里做 multi-window、multi-burn-rate 的 SLO 面板，既看瞬时 util，也看 1h/24h 的 I/O burn rate，实现谷歌 SRE 章节里提到的‘错误预算’。”