prometheus+alertmanager监控报警需满足三硬性结构：groups为顶层键、group name合法、alert名称仅含字母数字下划线；expr须返回非空瞬时向量；阈值须结合指标含义与采集频率设定，如cpu用rate计算5分钟平均，内存用memavailablebytes；规则生效须确保prometheus.yml正确引用、执行dry-run验证、curl reload重载；alertmanager中group_wait控制首报延迟，repeat_interval控制重发间隔，for字段决定首次触发时机，四道关卡任一出错均致告警异常。
直接上手配置系统监控报警规则，关键不是堆工具，而是让每条规则对应一个明确的故障场景、有可验证的阈值、且通知能真正触达。Prometheus + Alertmanager 是目前最可控的组合，尤其适合从单机起步的运维人员。
写 alert.rules.yml 时必须满足的三个硬性结构
Alertmanager 不会加载格式错误的规则文件，哪怕只错一个空格。规则生效前必须确认以下三点：
-
groups:是顶层键，不能漏；每个 group 必须有name:字段，且值不能含空格或特殊字符（如name: system-alerts合法，name: System Alerts非法） -
alert:名称只能用字母、数字、下划线，不能含点号或连字符（alert: HighDiskUsage合法，alert: disk.usage.high会静默失败） -
expr:表达式必须返回瞬时向量，且结果非空；例如监控根分区使用率超 90%，应写100 - (100 * node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) > 90，而不是直接用node_filesystem_usage（该指标在新版 Node Exporter 中已废弃）
常见指标阈值怎么设才不误报
阈值不是拍脑袋定的，得结合指标含义和采集频率。比如 CPU 使用率，node_cpu_seconds_total 自身是计数器，直接比对无意义，必须用 rate() 或 irate() 计算变化率：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- CPU 超限：用
100 * (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))) > 85—— 取 5 分钟平均，避免秒级毛刺触发告警 - 内存不足：优先看
node_memory_MemAvailable_bytes，而非MemFree；表达式为node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 ，表示可用内存低于总量 10% - 磁盘写满风险：对
/var和/单独监控，避免用通配符匹配所有挂载点；表达式加 label 过滤：100 - (100 * node_filesystem_avail_bytes{mountpoint="/var",fstype=~"ext4|xfs"} / node_filesystem_size_bytes{mountpoint="/var",fstype=~"ext4|xfs"}) > 92
为什么改了 rules 文件，Prometheus 页面里看不到告警
规则没出现在 http://localhost:9090/alerts，大概率是路径或加载环节断了。检查顺序如下：
- 确认
prometheus.yml中rule_files:是数组形式：rule_files: ["/etc/prometheus/alert.rules.yml"]，不能写成字符串rule_files: "/etc/prometheus/alert.rules.yml" - 执行
prometheus --config.file=/etc/prometheus/prometheus.yml --dry-run，返回 0 才说明 YAML 语法和规则结构都通过 - 改完规则后，必须触发重载：
curl -X POST http://localhost:9090/-/reload（需启动时加--web.enable-lifecycle），只改文件不 reload = 白改 - 检查 Prometheus 日志是否有
Loaded configuration和Loaded rules行，若只有前者，说明规则文件未被识别
Alertmanager 的 group_wait 和 repeat_interval 容易配反
这两个参数控制告警聚合与重发节奏，配错会导致“告警不来”或“狂轰滥炸”：
-
group_wait: 30s：收到第一条告警后，等 30 秒，把同一组（相同 labels）的新告警合并发一次。太长会延迟首次通知，太短起不到聚合作用 -
repeat_interval: 4h：上次通知发出后，若问题未恢复，4 小时再发一次。别设成 5m —— 磁盘满这类问题不会 5 分钟自愈，只会刷屏 - 真正决定“第一次什么时候发”的是
for:字段（写在 alert.rules.yml 里），比如for: 5m表示异常持续 5 分钟才触发，它和 Alertmanager 的参数无关
复杂点在于：一条告警要经过 Prometheus 规则判断（for）、Alertmanager 分组（group_wait）、去重抑制（inhibit_rules）、最终发送（repeat_interval）四道关卡。任意一环配置不当，都会让告警消失或变形，调试时得逐层查日志，不能只盯着 alerts 页面。
