监控告警规则的脚本如何写

wen 实用脚本 2026-07-08 2

实战指南与最佳实践

目录导读

为什么需要脚本化监控告警规则？
监控告警脚本的核心架构设计
主流监控系统脚本编写实战（Prometheus + Zabbix + 自研）
告警规则中的常见陷阱与避坑指南
问答环节：专家解答高频问题
总结与下一步行动

监控告警规则的脚本如何写

为什么需要脚本化监控告警规则？

在运维和SRE工作中，监控告警是保障系统稳定性的第一道防线，很多团队停留在手动配置告警规则、或者使用系统自带的简单阈值模式，导致告警覆盖面不足、误报率高、维护成本大。

核心痛点：

静态阈值无法应对业务流量波动（如电商大促时的正常CPU飙升被误报）
多环境（开发/测试/生产）规则重复配置，更新困难
复杂逻辑（如多指标联合判断、时间窗口分析）依赖固定模板

脚本化优势：

灵活性：支持数学运算、正则匹配、历史数据对比等动态逻辑
可维护性：规则存为代码文件，可通过Git版本控制
复用性：通过参数化实现环境差异化（${ENV}_threshold）

真实案例： 某电商公司将200多条静态告警规则改为PromQL脚本后，误报率下降60%，告警响应时间缩短42%。

监控告警脚本的核心架构设计

一个健壮的告警脚本通常包含以下模块：

monitor_alert_rules/
├── config/          # 环境配置、阈值定义
│   ├── dev.yaml
│   └── prod.yaml
├── rules/           # 告警规则脚本
│   ├── cpu_usage.rule
│   ├── disk_full.rule
│   └── custom_check.rule
├── lib/             # 公共函数库
│   ├── math_utils.py
│   └── time_utils.rb
├── output/          # 告警输出格式
│   └── alert_template.json
└── main.sh          # 调度入口

关键设计原则：

分离配置与逻辑：阈值、实例列表等变化频繁的字段放入配置文件，脚本只处理业务逻辑
标准输入输出：脚本输出统一为JSON格式，便于下游告警平台（如PagerDuty、飞书、钉钉）解析
幂等性与重试机制：多次执行同一脚本不产生副作用，网络超时需自动重试

示例伪代码（Python）：

def evaluate_custom_rule(metric_name, current_value, threshold_config):
    # 从配置读取动态阈值
    base_threshold = threshold_config['base']
    offset = threshold_config['business_peak_offset']  # 高峰期偏移
    effective_threshold = base_threshold + offset * is_peak_time()
    if current_value > effective_threshold:
        return {
            "status": "firing",
            "severity": threshold_config['severity'],
            "message": f"{metric_name} exceeds {effective_threshold}"
        }
    return {"status": "ok"}

主流监控系统脚本编写实战

1 Prometheus告警规则脚本

Prometheus使用PromQL作为查询语言，规则文件通常为YAML格式,但可通过脚本生成规则：

示例：动态内存使用率告警

# 基础规则文件
groups:
- name: memory_alert
  rules:
  - alert: HighMemoryUsage
    expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > {{ .Values.memory_threshold }}
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Host {{ $labels.instance }} memory usage > {{ $value }}%"

脚本生成器（Bash）：

#!/bin/bash
# 根据实例类型动态调整阈值
if [[ "$INSTANCE_TYPE" == "memory_optimized" ]]; then
    threshold=90
else
    threshold=80
fi
cat <<EOF > /etc/prometheus/rules/generated_cpu.rules
groups:
- name: cpu_alert
  rules:
  - alert: HighCPUUsage
    expr: (100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > ${threshold}
    for: 10m
    annotations:
      summary: "CPU usage critical on {{ \$labels.instance }}"
EOF

2 Zabbix告警脚本开发

Zabbix的告警脚本主要用于自定义动作和外部检查，以下为一个场景：监控日志文件中特定错误码的出现频率。

触发逻辑脚本（Python）：

# log_alert.py
import json
import sys
def main():
    # 从Zabbix接收参数：日志路径、错误码、时间窗口
    log_path = sys.argv[1]
    error_code = sys.argv[2]
    window_minutes = int(sys.argv[3])
    # 模拟日志分析逻辑
    with open(log_path) as f:
        tail_lines = f.readlines()[-100:]  # 取最近100行
    error_count = sum(1 for line in tail_lines if error_code in line)
    # 输出结果给Zabbix (0=正常, 1=告警)
    if error_count > 3:
        print(json.dumps({"value": 1, "msg": f"Found {error_count} errors in {window_minutes}min"}))
    else:
        print(json.dumps({"value": 0}))

Zabbix前端配置：

键值: log_alert["/var/log/app/error.log","500",5]
告警表达式: {hostname:log_alert.last("value")}=1

3 自研监控脚本框架

当使用通用监控系统受限时,可自建轻量级脚本框架：

核心思想：

使用cron定期执行脚本
脚本通过HTTP API推送告警

示例：多条件联合告警脚本

#!/bin/bash
# multi_condition_alert.sh
# 检查：同时满足 CPU>80% 且 连接数>5000 且 时间>5分钟
CHECK_CPU=$(python3 -c "import psutil; print('1' if psutil.cpu_percent()>80 else '0')")
CHECK_CONN=$(ss -t | grep ESTAB | wc -l)
START_TIME=$(date +%s)
if [[ "$CHECK_CPU" == "1" ]] && [[ "$CHECK_CONN" -gt 5000 ]]; then
    # 记录第一次触发时间
    if [[ ! -f /tmp/alert_trigger ]]; then
        echo "$START_TIME" > /tmp/alert_trigger
    else
        TRIGGER_TIME=$(cat /tmp/alert_trigger)
        ELAPSED=$(( (START_TIME - TRIGGER_TIME) / 60 ))
        if [[ "$ELAPSED" -ge 5 ]]; then
            # 发送告警
            curl -X POST http://alertmanager.example.com/api/v1/alerts \
                 -H "Content-Type: application/json" \
                 -d '{"labels":{"alertname":"MultiCondition","severity":"critical"}, "annotations":{"summary":"CPU high and connections high for 5min"}}'
            rm -f /tmp/alert_trigger  # 避免重复告警
        fi
    fi
else
    rm -f /tmp/alert_trigger  # 状态恢复时清除标记
fi

告警规则中的常见陷阱与避坑指南

陷阱类型	现象	解决方案
瞬时抖动误报	秒级cpu突刺触发告警	加入`for: 5m`时间窗口，或使用`avg_over_time(metric[5m])`
重复告警风暴	同一问题连续触发100条告警	实现去重机制：相同fingerprint的告警在2小时内只发一次
依赖缺失	子监控系统挂掉导致误报	加入“心跳检查”：如果主机不汇报数据超过3分钟，静默所有该主机告警
环境差异	开发环境阈值与生产相同	使用模板引擎（如Jinja2）根据环境变量生成不同规则文件