Zabbix运维监控系统与AI大模型交互实践分享

从Zabbix到大模型：一次运维监控智能化的真实落地记录

运维监控这事，干久了就知道，平台再强大，也离不开人。问题是人不可能24小时盯着大屏，最现实的解法是——当真正出问题的时候，系统能把事儿说清楚，甚至告诉你该怎么办。

这篇内容，就是围绕“Zabbix+大模型”这个组合，从一个具体实践的角度，把环境怎么搭、脚本怎么写、坑在哪里，一步步展开。不追求面面俱到，但求每一步都有据可查。

先说几个核心判断：本地大模型+Zabbix这条路完全走得通，但资源消耗、安全风险、信息质量这三个问题，一个都不能跳过。下面我们逐层展开。

---

引言

企业数据中心的运维工作，基础设施复杂、监控难度大，这几乎是所有运维团队的共识。此前有文章详细介绍了基于Zabbix+Grafana构建统一监控平台的落地案，包括架构设计、数据展示和关键步骤的解法。但一个更根本的问题是——用户不可能一直盯着监控屏。更合理的思路是，当异常真正发生时，系统能主动通知到人。

事件通知本身就是Zabbix的核心能力。而随着AI技术的快速成熟，将其与Zabbix的告警机制结合，就可以实现对告警的实时解读和反馈。这是一种典型的“如虎添翼”。当然，技术上的兴奋点背后，资源、安全、可靠性等一系列问题也随之浮现。下面，就把整个交互实践的设计思路、配置方法、运维经验，以及过程中遇到的坑，逐一拆开来讲。

一、Zabbix告警发送联动大模型的设计

Zabbix的事件通知配置非常灵活，可以针对特定事件、特定级别、特定主机等属性定义通知动作。通知方式包括语音电话、微信、钉钉、邮件等，直接触达业务管理员，有效缩短响应时间。

Zabbix原生支持以下四种告警媒介：

• 电子邮箱
• 信息
• 自定义报警脚本
• Webhook

日常运维中，用得最多的是自定义报警脚本。通过Zabbix调用bash脚本，可以高度自由地连接云语音平台或Webhook服务。这些脚本实际运行在Zabbix服务器上，需要放在AlertScriptsPath目录下并赋予可执行权限。

借一张图说明架构：

图：告警媒介使用脚本类型，调用服务器上存放的信息发送脚本

我们尝试的交互方式，就是基于报警脚本与大模型的API接口进行交互——报警信息先被发送给大模型进行解读，再返回分析结果，最后通过微信Webhook推送到群。这里有一个前提：大模型尤其是本地部署的，对显卡显存要求非常高，硬件配置必须提前评估好。

图：Zabbix监控系统架构图

图：监控平台联动大模型流程图

二、环境配置

本地大模型虚拟机配置

8C
16G
100G
NVIDIA GeForce RTX 4090 24G显存
Ubuntu 24.04 LTS
0.1.41
gemma:7b

Zabbix Server 虚拟机配置

16C
24G
300G
CentOS Linux 8

资源使用情况分析

在本地环境中，显卡的并行计算能力和显存带宽是大模型性能的基石。启动大模型时，主要依赖磁盘读性能将模型数据加载到显存。运行过程中，大模型会持续驻留显存——Ollama默认闲置5分钟后卸载，但可以通过设置OLLAMA_KEEP_ALIVE控制存活时间。调大这个值之后，大模型不用反复从磁盘加载，响应速度明显提升。

运行中的大模型，主要消耗的是GPU计算资源和显存，对CPU和系统内存的依赖并不高。CPU虽然通用性强，但在处理大规模并行计算时，效率远不如GPU。

图：最近7天本地大模型服务器的资源使用率记录

图：DeepSeek-r1:14b启动过程中的磁盘IO记录

图：本地 deepseek-r1:14b大模型服务器的显卡资源使用率

图：本地同时运行 deepseek-r1:14b与gemma:7b服务器的显卡资源使用率

显存与内存运行本地大模型的差异

专门为图形处理设计，带宽高、延迟低。大模型运行时，显存能快速传输数据给GPU进行并行计算，适合对实时性要求高的场景。

速度相对较慢，CPU从内存读取数据的周期长，容易成为性能瓶颈。

容量通常较小，消费级显卡8-24GB常见，更大容量需要专业卡，成本显著上升。

容量大且价格便宜，16GB或32GB很常见，适合小规模或优化过的模型。

依赖GPU，需支持CUDA的NVIDIA显卡等硬件。适合对性能有高要求的企业级应用。

主要依赖CPU，硬件门槛低。适合个人学习、简单测试或资源受限的环境。

本地大模型推荐使用Ubuntu操作系统

Ubuntu是机器学习领域最主流的系统之一，文档和社区支持极为丰富。

NVIDIA对Ubuntu的驱动、CUDA、cuDNN等生态支持非常完善。

apt包管理器让安装和维护变得高效。

Ubuntu 22.04 LTS 或 24.04 LTS，长期支持版，稳定性有保障。

需要使用NVIDIA CUDA。通常情况下，物理服务器直接安装Ubuntu并运行CUDA会很顺利；但如果使用虚拟化平台直通显卡到虚拟机，会遇到各种配置问题，最终能否解决取决于显卡型号与平台的兼容性。当nvidia-smi能正常显示显卡信息时，才说明显卡已正常工作。

三、配置步骤

3.1 大模型运行

安装Ollama环境：

curl -fsSL https://ollama.com/install.sh | sh

拉取gemma:7b并测试运行：

ollama pull gemma:7b
ollama run gemma:7b

退出对话窗口后，大模型会自动停止运行。常用模型仓库：https://ollama.com/library?sort=featured

3.2 对外提供接口服务

Ollama默认只允许本地访问。如果需要外网访问，需修改环境变量，监听所有IP地址并放行防火墙。

vi /etc/systemd/system/ollama.service

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=..."
Environment="OLLAMA_KEEP_ALIVE=24h"
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_HOST=0.0.0.0:11434"

systemctl daemon-reload
systemctl restart ollama

如果不想暴露Ollama接口，也可以通过Flask写一个Web Service做转发，将指定的POST请求转发到本地大模型接口。

from flask import Flask, request, jsonify
import requests

app = Flask(__name__)

@app.route('/predict', methods=['POST'])
def predict():
    input_data = request.json
    response = requests.post('http://localhost:11434', json=input_data)
    return jsonify(response.json())

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

3.3 身份定义与内容格式定义

Prompt是大模型最关键的输入。它决定了输出的方向和内容质量。好的Prompt需要满足：

越明确，输出越可控。

可以尝试不同表述，找到最优解。

细微差异可能带来完全不同的输出。

下面是我们目前使用的Prompt，对模型做了身份、场景和输出格式的明确定义：

vi Modelfile
FROM gemma
SYSTEM """使用中文对话，你是医院的数据中心维护人员，拥有专业的信息系统运维技术，现在有一些数据中心发生的故障需要你给出处理建议，每一个故障事件相互独立，处理建议应简要，且围绕问题出发。回答的内容使用固定的话术模板"故障概述：，故障描述：，可能原因：，可能影响：，解决方案：，下一步：。" """

# 创建自定义模型
ollama create gemma -f /usr/share/ollama/Modelfile

3.4 大模型持续运行

退出会话后，大模型会停止。为了解决这个问题，有两种常见方案：

• nohup：
  让命令在后台持续运行，不受终端关闭影响。

• screen：
  创建虚拟终端，可以后台运行、随时切换。

我们采用了screen方案，方便测试和切换。

screen -S model   # 创建并进入会话
Ctrl + a + d      # 离开会话（保持后台）
screen -r model   # 恢复会话
screen -list      # 查看会话列表

3.5 Zabbix调用大模型分析脚本

脚本将告警信息发送给大模型处理，并把原始告警与AI响应一起通过企业微信机器人推送到群。脚本中包含了调试日志开关（DEBUG_MODE），调试完成后务必关闭。

#!/bin/bash

# 企业微信机器人 webhook URL
WEBHOOK_URL='https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=此处换成自己的KEY'

# 对话 AI 工具的配置
API_HOST="x.x.x.x"
API_PORT="11434"
MODEL="gemma"

# 调试开关
DEBUG_MODE=false

# 打印调试信息
function debug_log() {
    if [ "$DEBUG_MODE" = true ]; then
        echo "[DEBUG] $1"
    fi
}

# 函数：处理格式并确保不包含引号
function process_format() {
    local input_text="$1"
    local processed_text="$input_text"
    processed_text=$(echo "$processed_text" | sed 's/[“”‘’]/ /g')
    echo "$processed_text"
}

# 函数：发送请求到 AI 服务并获取响应
function get_ai_response() {
    local alert_summary="$1"
    local alert_type="$2"
    
    # 提取字段
    local severity_level=$(echo "$alert_summary" | grep -oP '严重级别:K[^,]*' | tr -d ' ')
    local host_name=$(echo "$alert_summary" | grep -oP '故障主机:K[^,]*' | tr -d ' ')
    local fault_name=$(echo "$alert_summary" | grep -oP '故障名称:K[^,]*' | tr -d ' ')
    local start_time=$(echo "$alert_summary" | grep -oP '故障开始于:K[^,]*' | tr -d ' ')
    local resolved_time=""
    
    if [ "$alert_type" == "resolved" ]; then
        resolved_time=$(echo "$alert_summary" | grep -oP '故障在[^已]*已解决' | tr -d ' ')
        resolved_time=${resolved_time#故障在}
        resolved_time=${resolved_time%已解决}
    fi
    
    local processed_summary=$(process_format "$alert_summary")
    debug_log "Sending preprocessed alert summary to AI: $processed_summary"
    
    local response=$(curl -s -X POST "http://${API_HOST}:${API_PORT}/api/generate" \
        -H "Content-Type: application/json" \
        -d "{\"model\":\"${MODEL}\",\"prompt\":\"$processed_summary\",\"stream\":false}")
    
    debug_log "AI response: $response"
    local ai_response=$(echo "$response" | jq -r '.response')
    echo "$ai_response"
}

# 发送告警信息到企业微信
function send_alert_to_wechat() {
    local party_id=$1
    local ai_response=$2
    local alert_summary=$3
    
    local complete_message="告警信息：\n$alert_summary\n\nAI解读：\n$ai_response"
    local escaped_message=$(jq -Rn --arg msg "$complete_message" '$msg')
    
    local wechat_response=$(curl -s -X POST "$WEBHOOK_URL" \
        -H 'Content-type:application/json' \
        -d "{\"msgtype\":\"text\",\"text\":{\"content\":$escaped_message}}")
    
    debug_log "WeChat response: $wechat_response"
}

# 主逻辑
if [[ $# -ne 2 ]]; then
    echo "Usage: $0  "
    exit 1
fi

PARTY_ID=$1
ALERT_SUMMARY=$2
debug_log "Script started with PartyID: $PARTY_ID and alert_summary: $ALERT_SUMMARY"

ALERT_TYPE="triggered"
if echo "$ALERT_SUMMARY" | grep -q "已解决"; then
    ALERT_TYPE="resolved"
fi

AI_RESPONSE=$(get_ai_response "$ALERT_SUMMARY" "$ALERT_TYPE")
if [ -z "$AI_RESPONSE" ]; then
    echo "Failed to get AI response."
    exit 1
fi

send_alert_to_wechat "$PARTY_ID" "$AI_RESPONSE" "$ALERT_SUMMARY"
debug_log "Alert sent to WeChat successfully."

3.6 企业微信接收大模型分析结果

企业微信群聊机器人Webhook的配置网上有详细教程，需要管理员权限。最终效果是，当告警发生时，微信群内直接收到包含大模型解读的完整信息。

图：Zabbix的告警信息大模型解读

四、存在的问题

4.1 大模型没有内置环境配置信息

大模型处理告警时，缺乏对实际环境的深入了解。它完全依赖用户输入的告警信息进行分析，如果信息中没有包含网络拓扑、系统版本、硬件配置等关键细节，分析结果就可能偏离实际。

一种改进思路是：在告警信息中加入更多的环境元数据，或者通过额外脚本收集并整合这些信息。但这会增加脚本的复杂度，也可能导致数据量过大、处理延迟。同时，不同环境的配置结构可能不同，如何统一标准化也是一个需要解决的问题。

4.2 命名规范问题

实际运维中，主机名可能是缩写，告警名称可能模糊不清。例如“系统错误”远不如“CPU占用率超过90%”来得清晰。大模型面对这种信息，容易产生不准确的分析。

解决方案是推动整个Zabbix系统实施统一的命名规范。比如主机命名采用“[系统类型]-[位置]-[编号]”结构，告警命名采用“[故障组件]-[故障现象]-[严重程度]”结构。

告警越详细，大模型的分析质量越高。“服务器故障”这样的信息几乎没价值，而“服务器故障：CPU核心1和2在过去5分钟内持续100%占用，服务响应延迟超过30秒”才能让大模型给出有参考意义的建议。

这意味着运维人员需要对告警平台做精细化维护，在生成告警信息时尽可能包含故障发生时的详细状态。这可能需要开发额外脚本来收集更多现场数据。

错误示例：这就是告警被大模型解读错误的情况——实际上只是存储发送了SNMP Trap，并未发生连接失败，需要人工确认。

图：Zabbix的告警信息被大模型错误解读

4.3 性能和资源消耗

当大量告警同时到达，大模型可能成为处理瓶颈。特别是在本地部署环境下，处理速度可能无法满足实时性要求。

不同模型在性能和资源需求上差异很大。大模型准但慢，小模型快但可能表现不够。选择时需要权衡，需要根据业务需求和硬件条件做取舍。

另外，处理长文本或复杂故障时，模型效率可能下降。可能需要优化算法或对输入信息进行裁剪压缩。

4.4 安全和隐私问题

告警信息可能包含服务器IP、关键配置等敏感数据。传输过程中需要加密（如HTTPS），本地部署时要做好访问控制和加密存储。如果使用第三方模型，还要评估服务商的数据安全策略。

大模型基于海量数据训练，告警信息中可能包含组织内部的敏感业务数据。建议对发送给模型的信息做匿名化处理，确保不泄露隐私的同时，仍保留足够的信息用于分析。

结语

从设计思路到环境配置，从脚本开发到问题分析，Zabbix与大模型的交互实践虽然已经跑通，但远没有到“拿来即用”的程度。资源规划要算清楚，命名规范要统一，告警内容要精细化，安全红线不能碰。每一步都扎实走下去，这套系统才能真正成为运维的得力助手。