2.趋势预测

Kinger2026/7/23大约 4 分钟

线性回归算法实现流量预警

修改Prometheus的配置文件添加告警规则

1. 修改后的 prometheus.yml（/usr/local/prometheus/prometheus.yml）

建议直接按照以下结构更新你的配置文件：

global:
  scrape_interval: 15s     # 抓取间隔，用于 predict_linear 计算斜率
  evaluation_interval: 15s # 规则评估频率

# 1. 核心：加载趋势预警规则文件
rule_files:
  - "rules/*.yml"

# 2. 核心：定义告警发送目的地（Alertmanager）
alerting:
  alertmanagers:
    - static_configs:
        - targets: ["localhost:9093"]

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "dmz_cluster"
    static_configs:
      - targets: 
          - "localhost:9100"       # 136 堡垒机节点
          - "192.168.31.130:9100"  # Web 1
          - "192.168.31.131:9100"  # Web 2
          - "192.168.31.132:9100"  # 业务节点
          - "192.168.31.133:9100"  # 待救治节点
          - "192.168.31.135:9100"  # 业务节点

2. 第二阶段：趋势预警规则实现

在刚才建议你创建的 /usr/local/prometheus/rules/（新建） 目录下，新建 predict_rules.yml：

groups:
  - name: HostStatusPrediction
    rules:
      # 1. 磁盘趋势预测 (你原有的逻辑，保留)
      - alert: DiskSpaceWillFillIn4Hours
        expr: predict_linear(node_filesystem_free_bytes{mountpoint="/"}[1h], 4 * 3600) < 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "磁盘预警: {{ $labels.instance }}"
          description: "预计4小时后磁盘耗尽。"

      # 2. 动态 CPU 负载预警 (新增：智能识别凌晨备份)
      - alert: HostCPULoadAbnormal
        # 逻辑：当前 1 分钟负载 > (过去 7 天平均值 + 3 * 过去 7 天标准差)
        # 这种算法会自动把“每天凌晨都发生的备份高峰”包含在正常范围内
        expr: |
          node_load1 > (
            avg_over_time(node_load1[7d]) 
            + 3 * stddev_over_time(node_load1[7d])
          )
        for: 2m
        labels:
          severity: critical
          source: "ZH-Kinger-AI"
        annotations:
          summary: "CPU 异常偏离: {{ $labels.instance }}"
          description: "当前负载 {{ $value | printf \"%.2f\" }} 已显著超过 7 天基线水平，非周期性波动，建议 AI 介入。"

应用配置

查看Prometheus的Systemd 配置文件

systemctl status prometheus

修改 Systemd 配置文件

出现 "Lifecycle API is not enabled" 的原因是 Prometheus 出于安全性考虑，默认关闭了可以通过 HTTP 请求远程控制服务状态的接口。

在 Prometheus 的设计中，像 /-/reload（热加载配置）或 /-/quit（安全退出）这类操作具有较高的权限。如果默认开启且你的 136 堡垒机 9090 端口暴露在公网或不安全的内网中，任何人都可以通过简单的 curl 命令干扰你的监控系统

vi /usr/lib/systemd/system/prometheus.service

在 ExecStart 这一行的末尾添加 --web.enable-lifecycle 参数。修改后的内容应该类似这样：

[Unit]
Description=Prometheus
After=network.target

[Service]
Type=simple
# 核心修改：增加了 --web.enable-lifecycle 开启热加载 API
ExecStart=/usr/local/prometheus/prometheus \
  --config.file=/usr/local/prometheus/prometheus.yml \
  --storage.tsdb.path=/usr/local/prometheus/data \
  --web.enable-lifecycle
Restart=on-failure

[Install]
WantedBy=multi-user.target

执行生效与验证

修改完成后，按照以下步骤操作，确保你的趋势预警逻辑（predict_linear）成功加载：

重载 Systemd 并重启：

systemctl daemon-reload
systemctl restart prometheus

验证 API 是否开启：执行刚才报错的命令，如果不再提示 Lifecycle API is not enabled，则说明配置成功：

curl -X POST http://localhost:9090/-/reload

检查规则加载状态: 登录 http://192.168.31.136:9090/alerts，确认你刚才通过 promtool 检查通过的 2 条预警规则（磁盘和内存预测）已经显示在列表中。

3. 第二阶段：多渠道告警配置思路

由于你打算接入钉钉/企业微信 Webhook，你还需要在 136 堡垒机上启动 alertmanager 程序。

分类路由：在 alertmanager.yml 中，将 severity: warning 的告警发给“运维通知群”，将 severity: critical 的告警直接推送到你的个人终端。
消除抖动：配置 group_wait 和 repeat_interval，防止在 133 这种不稳定节点恢复时产生告警风暴。

Alertmanager安装

官方下载与安装指令

你可以直接在堡垒机执行以下命令进行快速部署：

# 1. 下载 Alertmanager 0.27.0 (目前最稳定的版本之一)
wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz

# 2. 解压文件
tar -xvf alertmanager-0.27.0.linux-amd64.tar.gz

# 3. 移动到你的规范路径
mv alertmanager-0.27.0.linux-amd64 /usr/local/alertmanager

配置systemed管理

执行 vi /etc/systemd/system/alertmanager.service，写入以下内容：

[Unit]
Description=Alertmanager
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml --storage.path=/usr/local/alertmanager/data
Restart=on-failure

[Install]
WantedBy=multi-user.target

启动服务

systemctl start alertmanager
systemctl enable alertmanager
systemctl status alertmanager

修改alertmanager.yml配置文件

修改配置文件vi /usr/local/alertmanager.alertmanager.yml添加预警方式

global:
  # 邮件服务器配置（以 QQ 邮箱为例，网易/Gmail 同理）
  smtp_smarthost: 'smtp.qq.com:465'
  smtp_from: '你的邮箱@qq.com'
  smtp_auth_username: '你的邮箱@qq.com'
  smtp_auth_password: '你的授权码' # 注意：不是登录密码，是 SMTP 授权码
  smtp_hello: 'prometheus'
  smtp_require_tls: false # 465 端口通常设为 false，587 设为 true

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'email-receiver' # 默认走邮件
  routes:
    # 扩展接口预留：未来可以根据 severity 过滤到不同的 Webhook
    - match:
        severity: critical
      receiver: 'email-receiver'

receivers:
- name: 'email-receiver'
  email_configs:
  - to: '你的接收邮箱@xxx.com'
    send_resolved: true # 故障恢复后也发一封邮件通知
    headers:
      subject: "【ZH-Kinger 预警】{{ .CommonAnnotations.summary }}"

检查语法

使用 Alertmanager 自带工具检查刚才的 YAML 缩进：

./amtool check-config alertmanager.yml

重启服务

systemctl restart alertmanager