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

引言

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

Zabbix 事件通知的配置可以细致到对特定事件所要通知的对象和时间进行规则定义，根据多种属性，例如告警主机、事件级别、事件标记、事件名称等属性去定义需要执行的通知发送动作，采用不同级别的通知方式，包括语音电话、微信信息通知、钉钉信息通知与邮件等方式，直接通知到业务管理员，提升异常事件处理效率。

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

• 电子邮箱

• 短信

• 自定义报警脚本

• Webhook

我们在日常运维中最常用的是自定义的报警脚本方式，通过 Zabbix 调用自定义编写的bash脚本，高度自由地连接云语音平台或 webhook 通知服务。告警脚本在 Zabbix 服务器上执行。这些脚本需要放置于服务器配置文件 zabbix_server.conf 中定义的 AlertScriptsPath 目录下，并具有可执行权限。

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

我们所尝试的 Zabbix 与大模型的交互也是基于报警脚本与大模型 API 接口进行交互，实现报警信息的解读与反馈，最终再发送到微信 webhook 。需要注意的是， 大模型通常需要较高的计算资源，特别是显卡（GPU）显存资源。在尝试部署本地大模型前，需要确保硬件配置足以支持所选择的大模型。

图：Zabbix监控系统架构图

二、环境配置

• 本地大模型虚拟机配置

CPU：8C

内存：16G

磁盘：100G

直通显卡：NVIDIA GeForce RTX 4090 24G显存

OS：Ubuntu 24.04 LTS

Ollama version：0.1.41

本地大模型：gemma:7b

• ZabbixServer虚拟机配置

CPU：16C

内存：24G

磁盘：300G

OS：CentOS Linux 8

• 资源使用情况分析

在本地环境中，显卡的强大并行计算能力、高效的显存以及完善的生态系统，使其成为大模型运行时的主要资源依托。

在此集群中，大模型的启动过程主要依赖磁盘读性能，将大模型数据加载到显存中。运行中的大模型会在显存中持续存放， ollama 默认设置大模型闲置5分钟会被释放，可通过设置OLLAMA_KEEP_ALIVE控制大模型的存活时间，大模型不需要反复从磁盘加载，可以快速响应服务请求。

运行中的大模型，主要占用显卡计算资源与显存资源，对系统 CPU、内存与 SWAP 空间等资源的依赖不高。CPU 虽然通用性强，但核心数量相对较少，在处理这种大规模并行计算任务时效率远低于 GPU。显卡能够充分发挥其并行计算优势，大幅提升计算速度，满足大模型对计算资源的高需求

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

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

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

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

速度性能方面

• 显存：专门为图形处理和高速数据读写设计，带宽高、延迟低。大模型运行时，显存能快速传输数据给 GPU 进行计算，尤其在处理大规模矩阵运算等任务时， 能显著提升推理和训练速度，适合对实时性要求高的场景。例如运行复杂的图像生成大模型，显存可让生成过程更流畅快速。

• 内存：速度相对显存较慢，数据读写速度和带宽不如显存。当大模型运行在内存时， CPU 从内存读取数据进行计算，传输速度限制可能导致计算等待数据时间长，影响整体运行效率。

容量和成本方面

• 显存：容量通常相对较小，常见的消费级显卡显存为 8GB - 24GB 等，专业级显卡显存可达更高，但价格昂贵。大模型参数量和数据量大时，显存可能不够用，需使用多张显卡或更高端显卡，成本大幅增加。

• 内存：容量相对较大且价格相对较低，常见电脑内存有 16GB、32GB 甚至更高，能满足一些规模较小或经过优化的大模型运行需求。

硬件依赖和适用场景方面

• 显存：依赖GPU，需要有支持 CUDA 等计算平台的 NVIDIA 显卡等硬件环境。适合有强大 GPU 硬件且对性能要求高的场景，如专业的 AI 研究、企业级大模型推理应用等。

• 内存：主要依赖 CPU，只要计算机有合适的 CPU 和足够内存即可运行。适用于对性能要求不特别高、硬件资源有限或模型规模较小的场景，如个人学习和简单测试等。

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

优点：

• 广泛使用：Ubuntu是机器学习和数据科学领域使用最广泛的操作系统之一，拥有大量的文档和教程。

• NVIDIA支持：NVIDIA 提供对 Ubuntu的良好支持，包括驱动、CUDA和cuDNN的安装包和文档。

• 软件包管理：apt包管理器使得软件安装和管理变得容易。

版本建议：Ubuntu 22.04 LTS 或 24.04 LTS：长期支持版本，具有较长的支持周期和稳定性。

三、配置步骤

3.1 大模型运行

安装本地大模型运行环境

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

拉取gemma:7b模型并运行，进行运行测试

ollama pull gemma:7bollama run gemma:7b#此时离开大模型对话窗口会自动关闭大模型的运行

附录：常用大模型

模型仓库：https://ollama.com/library?sort=featured

3.2 对外提供接口服务

ollama默认只能localhost访问。

如果需要允许外网访问，需要修改环境变量，采用11434监听本机的所有IP地址，配置防火墙放行后即可通过其他IP地址访问大模型接口。

vi /etc/systemd/system/ollama.service[Service]ExecStart=/usr/local/bin/ollama serveUser=ollamaGroup=ollamaRestart=alwaysRestartSec=3Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"Environment="OLLAMA_KEEP_ALIVE=24h"Environment="OLLAMA_NUM_PARALLEL=4"Environment="OLLAMA_HOST=0.0.0.0:11434"#保存
#重启ollama服务使生效systemctl daemon-reloadsystemctl restart ollama

如果不想对外开放大模型接口，也可以使用Web Service，采用接口转发的方式，将指定的http post请求发送到本地大模型接口，并进行响应。

参考代码：

cd /opt/datacenter_assistant/python3 app.py
from flask import Flask, request, jsonifyimport 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 越明确，大模型的输出越可能符合用户期望。模糊的 prompt 可能导致大模型的输出难以满足用户需求。

• 多样性：可以尝试不同的 prompt 表达方式，因为大模型对不同表述的理解可能有所差异，通过尝试找到最能满足需求的表述。

• 实验性：由于大模型的输出会因 prompt 的细微差异而不同，所以对于一些复杂任务，可以多尝试不同的 prompt 来获取最佳效果。

对本地大模型设置恰当的 prompt 可以提升大模型的交互质量，下面是目前我在用的prompt，对大模型进行了身份定义，场景定义，返回内容格式的定义。

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

3.4 大模型持续运

大模型准备就绪后，还需要解决持续运维的问题，就像前文提到的，退出大模型的会话后，不会在后台继续运行大模型提供服务。

基于运维经验，我们要保证大模型的会话进程不被中断时，可以采用 nohup 保证进程在后台运行，或者 screen 创建一个后台运行的会话。

• nohup 是一个 Unix/Linux 命令，全称为“no hang up”。它用于在后台运行命令或程序，并且使该程序在用户注销或终端关闭后继续运行，不会受到挂断信号（SIGHUP）的影响。

• screen 是一个 Unix/Linux 下的终端多路复用器，它允许用户在单个终端会话中创建多个独立的虚拟终端，这些虚拟终端可以运行不同的程序或命令。使用 screen 可以方便地在多个任务之间切换，同时可以将这些任务在后台运行，并且在终端断开连接或退出登录后继续运行。

本次我们采取了 screen 方案，会话切换更便于进行大模型的测试。

以下是 screen 命令需要用的指令，具体的操作思路是：

1、创建一个运行大模型的会话，运行大模型，然后离开会话。

2、查看 screen 会话列表，确认大模型会话存在即可，此时大模型在后台运行不会因当前会话的注销而关闭。

Linux screen命令用于多重视窗管理程序。

screen可以保证在断开与服务器的连接之后程序依然运行。

screen -S model 创建会话，并进入会话环境ctrl + a + d   离开会话（保持后台运行）screen -r model   恢复会话screen -list 查看会话列表

3.5 Zabbix调用大模型分析脚本，得到结果，发送给信息媒介

完成大模型服务器的调试后，回到 Zabbix Server服务器，开始进行大模型调用脚本的配置，以下是我的大模型调用脚本。该脚本基于企业微信群聊 Webhook 机器人进行编写，相对于钉钉的 Webhook API 限流，企业微信目前仍然免费提供 Webhook API 接口。

注意，运行该脚本的服务器应具有互联网访问权限。

下面这个脚本是通过大模型进行调试与编写的，过程中嵌入了多处调试信息输出，可通过 DEBUG_MODE=true 开启输出调试日志，完成调试后一定要关闭debug功能。

weixin_robot_AI.sh 脚本主要用于处理告警信息。它接收两个命令行参数，一个是 PartyID ，另一个是 alert_summary ，将 alert_summary 发送给 AI 服务进行处理，并将原始的告警信息和 AI 的响应一起作为消息通过企业微信机器人发送出去。

• WEBHOOK_URL:

  这是企业微信机器人的 Webhook 地址，用于发送消息。你需要将 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=此处换成自己的KEY 中的此处换成自己的KEY 替换为你自己的企业微信机器人的 Key，以便消息能够正确发送到相应的机器人。

• API_HOST、API_PORT 和MODEL：

  这些是与 AI 服务相关的配置信息。

  API_HOST 是 AI 服务的 IP 地址。

  API_PORT 是 AI 服务监听的端口号，这里设置为 11434，需要确保该端口号与你实际使用的 AI 服务匹配。

  MODEL 是使用的 AI 模型名称，这里是 gemma，同样需要确保它与你使用的 AI 服务所支持的模型相匹配。

• DEBUG_MODE:

  这是一个调试开关，默认为false，可以将其设置为 true 以打印更多的调试信息。

[root@appliance alertscripts]# cat weixin_robot_AI.sh#!/bin/bash
# 企业微信机器人 webhook URLWEBHOOK_URL='https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=此处换成自己的KEY'
# 对话 AI 工具的配置API_HOST="x.x.x.x"API_PORT="11434"# 请确保这个端口号与您的 AI API 服务器匹配MODEL="gemma"# 请确保这个模型名与您的 AI API 服务器匹配
# 调试开关DEBUG_MODE=false
# 打印调试信息functiondebug_log() {if [ "$DEBUG_MODE" = true ]; thenecho"[DEBUG] $1"fi}
# 函数：处理格式并确保不包含引号functionprocess_format() {local input_text="$1"local processed_text="$input_text"  processed_text=$(echo"$processed_text" | sed 's/[“”‘’]/ /g')  # 移除双引号echo"$processed_text"}
# 函数：发送请求到 AI 服务并获取响应functionget_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"
# 发送请求到 AI 服务并获取响应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"
# 提取 AI 的响应文本local ai_response=$(echo"$response" | jq -r '.response')
# 返回提取的响应文本echo"$ai_response"}
# 发送告警信息到企业微信functionsend_alert_to_wechat() {local party_id=$1local ai_response=$2local alert_summary=$3
# 构建完整的消息内容local complete_message="告警信息：$alert_summary
AI解读：$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 ]]; thenecho"Usage: $0 <PartyID> <alert_summary>"exit 1fi
# 读取参数PARTY_ID=$1ALERT_SUMMARY=$2
# 打印调试信息debug_log "Script started with PartyID: $PARTY_ID and alert_summary: $ALERT_SUMMARY"
# 确定告警类型ALERT_TYPE="triggered"ifecho"$ALERT_SUMMARY" | grep -q "已解决"; then  ALERT_TYPE="resolved"fi
# 获取 AI 的响应AI_RESPONSE=$(get_ai_response "$ALERT_SUMMARY""$ALERT_TYPE")
# 检查 AI 响应是否成功if [ -z "$AI_RESPONSE" ]; thenecho"Failed to get AI response."exit 1fi
# 发送告警信息和 AI 解读到企业微信send_alert_to_wechat "$PARTY_ID""$AI_RESPONSE""$ALERT_SUMMARY"
# 打印调试信息debug_log "Alert sent to WeChat successfully."

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

此处配置用于在企业微信创建群聊机器人 Webhook。

参考网上配置教程即可完成，需要企业微信管理员权限进行操作。

此处展示最终效果，加入对应微信群聊即可接收相应的告警信息。

四、存在的问题

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

大模型在处理 Zabbix 告警信息时，缺乏对实际环境的深入了解，这可能会对其分析结果的准确性和实用性产生影响。由于大模型本身不具备内置的环境配置信息，完全依赖用户提供的告警信息进行分析，这就要求用户在输入的告警信息中尽可能详尽地描述故障场景。然而，目前的情况是，告警信息可能无法涵盖所有关键的环境细节，例如网络拓扑、系统软件版本、硬件的具体配置细节（如存储设备的类型和容量、网络设备的型号和配置等）以及相关服务的详细参数。

为了提高大模型分析的准确性，一种可行的改进方法是将更多的环境信息作为大模型的输入。可以在告警信息中添加一些预定义的环境元数据，或者通过额外的脚本将这些信息收集起来并整合到发送给大模型的 prompt 中。但这样做会增加脚本的复杂性，并且可能会使发送给大模型的数据量增大，导致性能下降或处理时间延长。此外，在构建包含更多环境信息的 prompt 时，需要确保数据的准确性和安全性，避免泄漏敏感信息。

另一个潜在的问题是，不同环境下的配置信息可能具有不同的结构和命名规范，如何统一和标准化这些信息，以便大模型能够更好地理解和处理，是一个需要解决的问题。目前大模型在处理不同结构和格式的数据时可能会产生混淆，因为它对信息的理解基于其训练数据和算法，对于未经过良好训练的特定环境信息，可能无法给出最佳的分析结果。

4.2 命名规范问题

• 主机名称和告警名称不规范

• 在实际的运维环境中，经常会出现主机名称或问题告警名称不规范的情况。例如，主机名称可能是简单的缩写（如 srv1 而不是 server001），或者告警名称使用模糊的术语（如“系统错误”而不是“ CPU 占用率超过 90% ”）。这种不规范的命名会导致大模型接收到的信息不够清晰，使其分析偏离实际情况。大模型可能会因为这些模糊的信息而产生不准确或不相关的分析结果，因为它无法明确具体的故障位置和故障类型。

• 不规范的命名还可能导致大模型无法识别不同告警之间的关联或相似性，例如对于名称相似但实际上表示不同系统或组件的主机，大模型可能会错误地将它们视为同一对象。为了避免这种情况，需要在整个 Zabbix 系统中实施统一的命名规范，确保主机名称和告警名称具有明确的含义和足够的信息。可以采用结构化的命名规则，例如 [系统类型]-[位置]-[编号] 的主机命名方式（如 webserver-datacenter01-001）和[故障组件]-[故障现象]-[严重程度] 的告警命名方式（如 CPU-overload-high ）。

• 告警内容的详细程度影响分析结果

• 告警内容的详细程度对大模型的分析质量有着显著影响。过于简洁的告警信息可能无法为大模型提供足够的上下文，导致大模型只能给出笼统的、泛化的分析结果，其参考价值大打折扣。例如，一个简单的告警信息“服务器故障”远不如“服务器故障：CPU 核心 1 和 2 在过去 5 分钟内持续处于 100% 占用状态，导致服务响应延迟超过 30 秒”能让大模型做出准确的分析。

• 为了提高大模型的分析质量，运维人员需要对告警平台进行精细化维护，在生成告警信息时，不仅要包括故障的基本信息（如故障的时间、涉及的主机和组件），还要尽可能包含故障发生时的详细状态信息（如性能指标、错误日志的关键部分、相关服务的状态等）。这对告警平台的信息收集和整理功能提出了更高的要求，可能需要开发额外的脚本来收集更多的故障现场信息，并将其合理地整合到告警信息中。

错误示例：此告警实为存储发送了 SNMP Trap信息通知给 Zabbix 监控平台，并未发生 SNMP连接失败的情况，需要人工查看Trap信息确认事件内容。

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

4.3 性能和资源消耗

• 大模型性能问题

当大量的 Zabbix 告警信息同时发送给大模型进行分析时，大模型的性能可能会成为瓶颈。特别是在本地部署的情况下，大模型的处理速度可能无法满足实时告警分析的需求。这可能会导致告警信息的处理延迟，影响整个运维流程的及时性。

不同的大模型在性能上存在差异，对于资源的需求也不同。一些较大的模型可能需要更多的计算资源和更长的处理时间，而较小的模型虽然速度较快，但可能在分析的准确性和深度上有所欠缺。选择合适的大模型需要综合考虑性能和分析质量的平衡，同时需要根据实际的业务需求和硬件资源进行调整。

此外，大模型在处理较长的告警信息或复杂的故障场景时，其性能也可能会下降。这可能是由于大模型的架构和算法限制，在处理较长的文本序列时效率降低，需要进一步优化大模型的算法或对输入信息进行合理的裁剪和压缩，以确保在不丢失关键信息的前提下提高处理速度。

4.4 安全和隐私问题

• 数据安全

在将 Zabbix告警信息发送给大模型进行分析时，可能涉及敏感的业务和系统信息，如服务器的 IP 地址、服务的关键配置信息等。这些信息可能会在传输过程中被窃取或泄露，因此需要确保数据传输的安全性。可以使用加密的通信协议（如 HTTPS）来保护数据在网络上的传输，防止数据在传输过程中被拦截和窃取。

此外，大模型本身也可能存储和使用这些信息，需要评估大模型服务提供商的数据安全策略，确保其符合组织的安全要求。对于本地部署的大模型，需要采取措施防止数据存储和处理过程中的安全漏洞，如使用安全的存储系统、实施访问控制和加密存储等。

• 隐私问题

结语

本文分享了 Zabbix 运维监控系统与AI大模型交互的设计思路、环境配置，以及具体的配置步骤，并分析了可能产生的问题与风险，通过对以上这些问题的深入认识和逐步解决，可以进一步完善 Zabbix 运维监控平台与大模型的联动，提高整个监控和告警处理系统的效率、准确性和可靠性，同时确保系统的安全性和隐私性，以更好地服务于信息系统运维工作。