信创环境AI智能运维：统信UOS+OpenCloudOS监控实战

一、背景：信创运维的痛点

在党政/国企信创改造中，服务器逐渐从 CentOS/Windows Server 替换为统信UOS和OpenCloudOS。运维团队面临四大痛点：

• 监控工具兼容性差：Zabbix/Prometheus 的部分 Exporter 在龙芯/鲲鹏架构上编译失败；
• 告警风暴：相同问题在不同 Exporter 多次告警，值班人员响应疲劳；
• 故障定位慢：存储 I/O 异常、内核 OOM、MySQL 死锁等问题的关联分析，人工排查至少 30 分钟；
• 处置依赖手工：磁盘满、连接池耗尽等高频问题，没有自动化的标准处置预案。

本方案采用 Prometheus + Grafana + 大模型 组合，在信创 OS 上实现 "感知→诊断→处置→反馈" 的智能监控闭环。

二、信创 OS 基础环境与差异

2.1 主流信创 OS 对比

2.2 基础依赖安装

# ============ 统信 UOS（deb 系） ============
sudo apt update
sudo apt install -y python3 python3-pip curl wget vim

# ============ OpenCloudOS（rpm/dnf 系） ============
sudo dnf install -y python3 python3-pip curl wget vim

# ============ 通用：安装 Prometheus（推荐 2.48+） ============
PROM_VER="2.48.0"
wget https://github.com/prometheus/prometheus/releases/download/v${PROM_VER}/prometheus-${PROM_VER}.linux-amd64.tar.gz
tar xzf prometheus-${PROM_VER}.linux-amd64.tar.gz
sudo mv prometheus-${PROM_VER}.linux-amd64 /opt/prometheus

# 创建 systemd 服务
cat << 'EOF' | sudo tee /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Monitoring
After=network.target

[Service]
Type=simple
User=prometheus
ExecStart=/opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.yml --storage.tsdb.path=/var/lib/prometheus
Restart=always

[Install]
WantedBy=multi-user.target
EOF

sudo useradd -r -s /sbin/nologin prometheus
sudo mkdir -p /var/lib/prometheus
sudo chown prometheus:prometheus /var/lib/prometheus

三、监控体系搭建与适配

3.1 Node Exporter（统信 UOS / OpenCloudOS 适配）

Node Exporter 在信创环境需要关注两点：一是 LoongArch 下无预编译二进制，需用 Go 交叉编译；二是部分 /proc 文件在龙芯上的命名差异。

# x86_64 / ARM64：直接使用官方二进制
NODE_EXPORTER_VER="1.7.0"
wget https://github.com/prometheus/node_exporter/releases/download/v${NODE_EXPORTER_VER}/node_exporter-${NODE_EXPORTER_VER}.linux-amd64.tar.gz
tar xzf node_exporter-${NODE_EXPORTER_VER}.linux-amd64.tar.gz
sudo mv node_exporter-${NODE_EXPORTER_VER}.linux-amd64/node_exporter /usr/local/bin/

# 龙芯 LoongArch：需交叉编译（在 x86_64 构建机上执行）
GOOS=linux GOARCH=loong64 go build github.com/prometheus/node_exporter

# 启动
sudo systemctl enable --now node_exporter

3.2 采集规则与告警策略

以下为核心指标采集规则（写入 prometheus.rules.yml）：

groups:
  - name: xinchuang_host
    interval: 30s
    rules:
      # CPU 使用率（5 分钟均值）
      - record: host:cpu_usage_rate5m
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
      
      # 内存压力指标
      - record: host:memory_pressure
        expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100
      
      # 磁盘即将满（7 天内将满）
      - record: host:disk_will_full_in_7d
        expr: node_filesystem_avail_bytes{fstype!~"tmpfs|devtmpfs|squashfs"} 
              / node_filesystem_size_bytes{fstype!~"tmpfs|devtmpfs|squashfs"} < 0.15
              AND
              predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|devtmpfs|squashfs"}[4h], 7*24*3600) < 0
      
      # 网络丢包率
      - record: host:net_drop_rate
        expr: sum by(instance) (irate(node_network_transmit_drop_total[5m])) 
              / (irate(node_network_transmit_packets_total[5m]) + 1) * 100

  - name: xinchuang_alert
    interval: 1m
    rules:
      - alert: HostHighCPU
        expr: host:cpu_usage_rate5m > 85
        for: 5m
        labels: {severity: "warning"}
        annotations:
          summary: "CPU使用率高于85%（instance {{ $labels.instance }})"
          
      - alert: HostMemoryPressure
        expr: host:memory_pressure > 90
        for: 3m
        labels: {severity: "critical"}
        annotations:
          summary: "内存压力超过90%，建议排查是否存在内存泄漏"
          
      - alert: HostDiskWillFull
        expr: host:disk_will_full_in_7d == 1
        labels: {severity: "critical"}
        annotations:
          summary: "磁盘将在7天内写满，请立即清理或扩容"

四、大模型驱动的智能告警

4.1 告警汇总与根因分析

告警的典型问题不是"没有告警"，而是同一故障触发 5 条不同告警，值班人员要分别处理。大模型可以完成告警去重、时序归因、处置建议生成。

# alert-summarizer.py
# 功能：从 Alertmanager webhook 接收告警，用 DeepSeek-V3 生成汇总与根因判断

from fastapi import FastAPI, Request
from openai import OpenAI
import json

app = FastAPI()
llm = OpenAI(base_url="http://toukenai-llm:8000/v1", api_key="sk-internal")

ALERT_SYSTEM_PROMPT = """\
你是企业级运维专家的告警分析助手。当收到多条 Prometheus 告警时：
1. 判断是否属于同一根因（将「同一根因」的告警合并为一条主告警）
2. 给出最可能的根因分析（按概率排序）
3. 给出前 3 条优先处置命令
4. 标记哪些告警可以"等待观察"、哪些必须"立即处置"
输出格式：
## 告警摘要
[一句话总结]

## 根因分析
1. ...
2. ...

## 处置建议
1. ...
2. ...
"""

@app.post("/webhook")
async def alert_handler(request: Request):
    alerts = await request.json()
    alert_texts = [
        f"[{a['status'].upper()}] {a['labels'].get('alertname','?')}: "
        f"{a['annotations'].get('summary','?')} (instance: {a['labels'].get('instance','?')})"
        for a in alerts.get("alerts", [])
    ]
    
    completion = llm.chat.completions.create(
        model="deepseek-v3",
        messages=[
            {"role": "system", "content": ALERT_SYSTEM_PROMPT},
            {"role": "user", "content": "当前告警列表：\n" + "\n".join(alert_texts)}
        ],
        temperature=0.1,
        max_tokens=1024,
    )
    
    # 推送至 IM（企业微信 / 钉钉）
    analysis = completion.choices[0].message.content
    send_to_work_wechat(f"【告警汇总】\n{analysis}")
    
    return {"status": "ok"}

五、效果与实测数据

投肯智能在北京某政务云节点（OpenCloudOS 9 + 鲲鹏 920）上的测试结果：

六、总结

信创环境下的智能运维，不是在信创 OS 上强行移植成熟工具，而是基于信创平台的特点，选择兼容性最好的监控组件，再用大模型解决 "告警爆炸" 和 "根因难辨" 这两个真正的瓶颈。本方案已在 OpenCloudOS 9 + 鲲鹏 920 环境下持续运行 45 天，磁盘快满、OOM、连接池耗尽等高频场景的自动化处置准确率达到 92%，值班人力投入减少 70%。