OpenClaw技能扩展：nanobot通过webhook对接Zabbix实现告警自动应答

OpenClaw技能扩展：nanobot通过webhook对接Zabbix实现告警自动应答

1. 引言：当告警遇上AI，运维工作迎来新帮手

想象一下这个场景：凌晨三点，你的手机突然被Zabbix的告警短信轰炸。服务器CPU飙到95%，数据库连接池告急，应用响应时间直线上升。你睡眼惺忪地爬起来，一边登录服务器查看日志，一边在群里@相关同事，手忙脚乱地开始排查。

如果这时候，有一个AI助手能自动分析告警，给出初步的排查建议，甚至执行一些简单的修复操作，那该多省心？

今天要介绍的，就是这样一个解决方案：让超轻量级的AI助手nanobot，通过webhook对接Zabbix，实现告警的自动分析和智能应答。这不仅仅是把告警转发到聊天工具那么简单，而是让AI真正参与到运维决策的闭环中。

nanobot是什么？它是一个受OpenClaw启发，但代码量只有其1%的超轻量级个人AI助手。内置了vLLM部署的Qwen3-4B-Instruct-2507模型，通过chainlit提供友好的交互界面。更重要的是，它支持通过配置文件轻松扩展各种消息通道——包括我们今天要用的webhook。

接下来，我会带你一步步实现这个功能扩展，让你的运维工作从此多一个24小时在线的AI同事。

2. nanobot快速上手：先让AI助手跑起来

在开始对接Zabbix之前，我们需要先确保nanobot本身已经正确部署并运行。别担心，这个过程比你想的要简单得多。

2.1 验证模型服务状态

部署完成后，第一件事就是确认模型服务是否正常启动。nanobot使用vLLM来部署大模型，我们可以通过查看日志来确认。

打开终端，运行以下命令：

cat /root/workspace/llm.log 

如果看到类似下面的输出，说明模型服务已经成功启动：

INFO 07-28 10:30:15 llm_engine.py:73] Initializing an LLM engine with config: model='/root/models/Qwen2.5-4B-Instruct', tokenizer='/root/models/Qwen2.5-4B-Instruct', tokenizer_mode=auto, trust_remote_code=True, dtype=torch.float16, ... INFO 07-28 10:30:20 llm_engine.py:158] # GPU blocks: 512, # CPU blocks: 256 INFO 07-28 10:30:25 llm_engine.py:162] KV cache size: 4.00 GB INFO 07-28 10:30:30 llm_engine.py:165] Available sampling params: temperature, top_p, top_k, ... 

关键是要看到模型加载成功的信息，以及GPU内存分配的情况。如果出现错误，通常是模型路径配置问题或者GPU内存不足。

2.2 通过chainlit与nanobot对话

模型服务跑起来后，我们可以通过chainlit这个Web界面来测试nanobot的基本功能。chainlit为nanobot提供了一个类似ChatGPT的交互界面。

在浏览器中打开chainlit的地址（通常是http://你的服务器IP:8000），你会看到一个简洁的聊天界面。现在，让我们问一个运维相关的问题来测试一下：

使用nvidia-smi看一下显卡配置 

nanobot会理解你的指令，并尝试执行相应的命令。如果一切正常，你会看到它返回了显卡的详细信息，包括GPU型号、显存使用情况、温度等。

这个测试很重要，因为它验证了两个关键点：

1. nanobot能够理解自然语言指令
2. nanobot具备执行系统命令的能力（在安全权限内）

2.3 nanobot的核心能力概览

在继续之前，我们先简单了解一下nanobot能做什么：

• 自然语言理解：能够理解你用日常语言描述的运维问题
• 命令执行：在授权范围内执行系统命令进行排查
• 日志分析：帮你分析日志文件，找出关键错误信息
• 配置检查：检查系统配置文件是否正确
• 建议提供：基于最佳实践给出问题解决建议

这些能力正是我们对接Zabbix告警所需要的。当告警触发时，nanobot可以自动分析告警内容，执行相关的检查命令，然后给出初步的排查方向。

3. 配置nanobot接收webhook消息

要让nanobot能够接收Zabbix的告警，我们需要先配置它的webhook功能。webhook是一种常见的系统集成方式，允许一个系统向另一个系统发送HTTP请求来触发某些操作。

3.1 修改nanobot配置文件

nanobot的所有配置都存放在/root/.nanobot/config.json文件中。我们需要在这个文件中添加webhook通道的配置。

用你喜欢的编辑器打开配置文件：

vim /root/.nanobot/config.json 

找到channels配置部分，添加webhook的配置。如果你的配置文件里还没有channels部分，可以直接添加整个部分：

{ "model": { "name": "Qwen2.5-4B-Instruct", "path": "/root/models/Qwen2.5-4B-Instruct", "context_length": 32768 }, "channels": { "webhook": { "enabled": true, "port": 8080, "path": "/webhook", "secret": "your_webhook_secret_here" }, "chainlit": { "enabled": true, "port": 8000 } } } 

让我解释一下这几个关键配置项：

• enabled: 设置为true启用webhook功能
• port: webhook服务监听的端口，这里设置为8080
• path: webhook的接收路径，Zabbix会向这个路径发送POST请求
• secret: 可选的密钥，用于验证请求的合法性，建议设置一个复杂的字符串

3.2 启动nanobot的gateway服务

配置完成后，我们需要启动nanobot的gateway服务。这个服务负责处理所有外部通道的消息，包括webhook。

在终端中运行：

nanobot gateway 

如果一切正常，你会看到类似下面的输出：

INFO 07-28 10:35:45 gateway.py:45] Starting nanobot gateway... INFO 07-28 10:35:45 webhook_server.py:78] Webhook server started on port 8080 INFO 07-28 10:35:45 chainlit_server.py:92] Chainlit server started on port 8000 INFO 07-28 10:35:45 gateway.py:52] All channels initialized successfully 

注意看这两行信息：

• Webhook server started on port 8080 - webhook服务已经在8080端口启动
• All channels initialized successfully - 所有通道都初始化成功

3.3 测试webhook接口

在配置Zabbix之前，我们先手动测试一下webhook接口是否正常工作。这可以避免后续集成时出现问题。

我们可以使用curl命令模拟Zabbix发送一个告警：

curl -X POST http://localhost:8080/webhook \ -H "Content-Type: application/json" \ -d '{ "event_id": "12345", "trigger_name": "CPU usage is too high", "trigger_status": "PROBLEM", "trigger_severity": "High", "host_name": "web-server-01", "item_name": "CPU utilization", "item_value": "95%", "event_time": "2024-07-28 10:40:00", "opdata": "Current value: 95%, threshold: 80%" }' 

如果配置正确，nanobot应该会收到这个请求，并尝试分析这个告警。你可以在gateway服务的日志中看到处理过程：

INFO 07-28 10:40:15 webhook_server.py:112] Received webhook from Zabbix INFO 07-28 10:40:15 agent.py:156] Processing alert: CPU usage is too high on web-server-01 INFO 07-28 10:40:20 agent.py:178] Generated response: 检测到web-server-01的CPU使用率达到95%，超过80%的阈值。建议立即检查：1. 使用top命令查看具体进程 2. 检查是否有异常进程 3. 查看系统日志/var/log/messages 

这个测试验证了webhook接口能够正常接收和处理JSON格式的告警数据。

4. 配置Zabbix发送告警到webhook

现在nanobot已经准备好接收告警了，接下来我们需要配置Zabbix，让它把告警发送到我们的webhook接口。

4.1 在Zabbix中创建报警媒介类型

登录Zabbix Web界面，按照以下步骤操作：

1. 进入 管理 → 报警媒介类型
2. 点击右上角的 创建报警媒介类型
3. 填写以下信息：

基本设置：

• 名称：nanobot webhook
• 类型：Webhook
• 说明：发送告警到nanobot AI助手进行分析

参数设置： Zabbix的webhook需要一些参数来构造请求。点击 添加 来定义参数：

请求体： 在 脚本 区域，我们需要编写JavaScript代码来构造请求体：

try { var request = new HttpRequest(); request.addHeader('Content-Type: application/json'); var data = { event_id: params.event_id, trigger_name: params.trigger_name, trigger_status: params.trigger_status, trigger_severity: params.trigger_severity, host_name: params.host_name, item_name: params.item_name, item_value: params.item_value, event_time: params.event_time, opdata: params.opdata }; var response = request.post('http://你的nanobot服务器IP:8080/webhook', JSON.stringify(data)); if (request.getStatus() !== 200) { throw 'Response code: ' + request.getStatus(); } return JSON.parse(response); } catch (error) { throw 'Failed to send alert to nanobot: ' + error; } 

重要提示：记得把http://你的nanobot服务器IP:8080/webhook替换成你实际的nanobot服务器地址和端口。

4.2 配置报警动作

创建好报警媒介类型后，我们需要创建一个报警动作来使用它：

1. 进入 配置 → 动作
2. 点击 创建动作
3. 在 名称 中输入：发送告警到nanobot
4. 在 条件 中，可以设置触发条件，比如：
   • 触发器严重性 ≥ 警告
   • 或者针对特定的主机组
5. 切换到 操作 标签页
6. 点击 新的 添加操作：
   • 操作类型：发送消息
   • 发送到用户：选择接收通知的用户
   • 仅送到：选择我们刚创建的 nanobot webhook
   • 默认信息：可以使用默认的告警模板
7. 在 恢复操作 中，也可以配置当问题恢复时发送消息给nanobot

4.3 测试Zabbix告警发送

配置完成后，我们需要测试一下整个流程是否正常工作。有几种测试方法：

方法一：手动触发一个测试告警 如果你有测试环境，可以手动让某个监控项触发告警，比如让CPU使用率超过阈值。

方法二：使用Zabbix的测试功能 在报警媒介类型页面，找到我们创建的nanobot webhook，点击 测试：

1. 选择要测试的报警媒介类型
2. 输入测试用的参数值
3. 点击 测试

如果测试成功，你会在nanobot的gateway日志中看到接收到的告警，并且nanobot会生成分析结果。

方法三：模拟一个告警 如果暂时没有真实的告警，可以修改一个监控项的阈值，让它立即触发告警。

5. 定制nanobot的告警处理逻辑

默认情况下，nanobot收到告警后会使用内置的模型进行分析。但我们可以通过定制提示词（prompt）来优化它的回答，让它更符合运维场景的需求。

5.1 理解nanobot的处理流程

当nanobot通过webhook收到告警时，它会：

1. 解析JSON数据，提取关键信息
2. 构造一个提示词发送给大模型
3. 接收模型的回复
4. 将回复记录到日志，或者发送到其他通道（如QQ机器人）

默认的提示词可能不适合专业的运维场景，所以我们需要定制它。

5.2 修改处理告警的提示词

nanobot的提示词配置通常在模型配置文件中。我们需要找到并修改处理webhook消息的提示词模板。

首先，找到提示词配置文件的位置：

find /root -name "*prompt*" -type f | grep -i nanobot 

或者查看nanobot的配置文件，看看提示词模板的路径：

grep -r "prompt" /root/.nanobot/ 

假设我们找到了提示词文件在/root/.nanobot/prompts/webhook_prompt.txt，让我们打开并修改它：

vim /root/.nanobot/prompts/webhook_prompt.txt 

将内容修改为更适合运维告警分析的版本：

你是一个专业的运维专家，正在处理Zabbix监控系统发来的告警。 告警详情： - 事件ID: {event_id} - 告警名称: {trigger_name} - 当前状态: {trigger_status} - 严重级别: {trigger_severity} - 主机名称: {host_name} - 监控项: {item_name} - 当前值: {item_value} - 发生时间: {event_time} - 附加信息: {opdata} 请按照以下步骤分析这个告警： 1. 首先，简要描述这个告警的核心问题 2. 然后，分析可能的原因（列出2-3个最可能的原因） 3. 接着，给出具体的排查步骤（用命令的形式，确保安全可执行） 4. 最后，如果问题持续，建议的后续措施 请用专业但易懂的语言回答，避免使用过于技术化的术语。如果信息不足，请说明需要补充哪些信息。 你的分析： 

这个提示词模板有几个关键改进：

• 明确了AI的角色是"运维专家"
• 提供了结构化的分析框架
• 强调要给出具体的、可执行的命令
• 要求用易懂的语言，避免技术黑话

5.3 添加运维知识库

为了让nanobot的回答更准确，我们还可以为它提供一些运维相关的知识库。这可以通过在配置中指定额外的上下文文件来实现。

创建一个运维知识库文件：

vim /root/.nanobot/knowledge/ops_knowledge.md 

添加一些常见的运维场景和解决方案：

# 运维知识库 ## CPU使用率过高 常见原因： 1. 应用程序bug导致死循环 2. 数据库查询没有索引 3. 系统遭受攻击（如挖矿病毒） 4. 系统资源不足 排查命令： - `top -c` 查看CPU使用率最高的进程 - `ps aux --sort=-%cpu | head -10` 查看前10个CPU使用进程 - `vmstat 1 5` 查看系统整体状态 - `journalctl -xe --since "10 minutes ago"` 查看近期系统日志 ## 内存不足 常见原因： 1. 内存泄漏 2. 应用程序配置不合理 3. 系统缓存占用过多 排查命令： - `free -h` 查看内存使用情况 - `cat /proc/meminfo` 查看详细内存信息 - `ps aux --sort=-%mem | head -10` 查看内存使用前10的进程 ## 磁盘空间不足 常见原因： 1. 日志文件过大 2. 临时文件未清理 3. 业务数据增长 排查命令： - `df -h` 查看磁盘使用情况 - `du -sh /* | sort -rh | head -10` 查看占用空间最大的目录 - `find /var/log -name "*.log" -size +100M` 查找大于100M的日志文件 

然后在nanobot配置中引用这个知识库：

{ "model": { "name": "Qwen2.5-4B-Instruct", "path": "/root/models/Qwen2.5-4B-Instruct", "context_length": 32768 }, "knowledge_base": { "enabled": true, "paths": [ "/root/.nanobot/knowledge/ops_knowledge.md" ] } } 

这样，nanobot在分析告警时，会参考这个知识库中的信息，给出更专业的建议。

6. 实战演示：从告警到智能应答的全流程

现在让我们通过一个完整的例子，看看nanobot如何处理一个真实的Zabbix告警。

6.1 模拟一个真实的告警场景

假设我们有一台Web服务器，Zabbix监控到它的磁盘使用率超过了90%，触发了告警。

Zabbix会发送类似这样的数据到nanobot的webhook：

{ "event_id": "789012", "trigger_name": "Disk space is low on {HOST.NAME}", "trigger_status": "PROBLEM", "trigger_severity": "High", "host_name": "web-server-01", "item_name": "Disk usage on /", "item_value": "92%", "event_time": "2024-07-28 14:30:00", "opdata": "Free disk space on / is less than 20%" } 

6.2 nanobot的处理过程

nanobot收到这个webhook请求后，会：

1. 解析数据：提取出所有关键字段
2. 构造提示词：使用我们定制的提示词模板，填充实际数据
3. 调用大模型：将构造好的提示词发送给Qwen模型
4. 生成回答：模型基于提示词和知识库生成分析结果
5. 记录日志：将完整的交互记录到日志文件

6.3 查看nanobot的分析结果

我们可以在nanobot的日志中查看完整的处理过程：

tail -f /root/workspace/nanobot.log 

会看到类似这样的输出：

INFO 07-28 14:30:05 webhook_server.py:112] Received webhook from Zabbix: Disk space alert INFO 07-28 14:30:05 agent.py:167] Sending to model: 你是一个专业的运维专家，正在处理Zabbix监控系统发来的告警... INFO 07-28 14:30:12 agent.py:189] Model response received INFO 07-28 14:30:12 agent.py:195] Response saved to log 

更详细的分析结果可以在专门的响应日志中查看：

cat /root/workspace/responses/latest_response.txt 

内容可能是这样的：

基于Zabbix告警分析报告： **告警概述** 检测到主机 web-server-01 的根目录(/)磁盘使用率达到92%，已超过预警阈值。这是一个高严重级别的告警，需要立即处理。 **可能原因分析** 1. 日志文件积累过多，特别是/var/log目录下的应用日志 2. 临时文件未及时清理，如/tmp目录 3. 业务数据快速增长，导致存储空间不足 4. 可能有大型文件被误放在根目录 **立即排查步骤** 请按顺序执行以下命令进行排查： 1. 首先查看整体磁盘使用情况： ```bash df -h 

重点关注 / 分区的使用率。

2. 找出占用空间最大的目录：

du -sh /* 2>/dev/null | sort -rh | head -10 

3. 检查日志文件大小：

find /var/log -type f -name "*.log" -size +100M 2>/dev/null 

4. 检查临时文件：

ls -lah /tmp | head -20 

临时缓解措施 如果发现是日志文件过大，可以立即清理：

# 清理系统日志（保留最近7天） find /var/log -name "*.log" -type f -mtime +7 -delete # 或者清空特定的大日志文件 truncate -s 0 /var/log/large_app.log 

长期解决方案建议

1. 设置日志轮转策略，避免单个日志文件过大
2. 监控业务数据增长趋势，提前规划存储扩容
3. 考虑将日志存储到专门的日志服务器或对象存储
4. 定期执行磁盘清理脚本

需要补充的信息 如果以上排查未能找到根本原因，请提供：

• ls -la / 的输出，查看根目录下有哪些大文件
• 业务最近是否有数据量大幅增长
• 是否有新的应用部署

请立即开始排查，并在处理完成后在Zabbix中确认告警状态。

 ### 6.4 实际效果评估 从这个分析结果可以看出，nanobot提供了： 1. **结构化分析**：按照我们提示词要求的步骤进行分析 2. **具体可操作的命令**：给出了可以直接执行的排查命令 3. **安全考虑**：使用了`2>/dev/null`避免权限错误干扰 4. **分层建议**：既有立即执行的命令，也有长期解决方案 5. **信息补充**：明确了如果需要进一步分析需要什么信息 这对于值班的运维人员来说，相当于有了一个经验丰富的同事在旁边指导，大大降低了处理紧急告警时的心理压力和时间成本。 ## 7. 高级功能扩展：让应答更智能 基本的告警应答已经很有用了，但我们还可以让nanobot做得更多。下面介绍几个高级功能的实现思路。 ### 7.1 自动执行安全命令 对于一些安全的、可重复的操作，我们可以让nanobot自动执行。比如自动清理旧的日志文件。 **重要警告**：自动执行命令有风险，必须严格控制权限！只允许执行那些确定安全的命令。 首先，在nanobot配置中开启命令执行权限（谨慎使用）： ```json { "agent": { "allow_execution": true, "allowed_commands": [ "df -h", "du -sh /*", "find /var/log -name \"*.log\" -mtime +30 -delete", "ls -la" ] } } 

然后，在提示词中告诉nanobot可以执行哪些命令：

...如果确定是日志文件过大导致的问题，并且确认可以安全清理30天前的日志，你可以执行： find /var/log -name "*.log" -mtime +30 -delete 

7.2 多步骤复杂分析

对于复杂的告警，nanobot可以进行多轮分析。比如先分析根本原因，然后根据分析结果给出具体的修复方案。

我们可以修改webhook处理逻辑，实现多轮对话：

# 伪代码示例 def handle_zabbix_alert(alert_data): # 第一轮：根本原因分析 cause_analysis = model.ask("分析这个告警的根本原因...") # 第二轮：基于原因给出解决方案 if "磁盘空间" in cause_analysis: solution = model.ask("针对磁盘空间不足的问题，给出具体的解决步骤...") elif "内存泄漏" in cause_analysis: solution = model.ask("针对内存泄漏问题，给出排查和修复方案...") return cause_analysis + "\n\n解决方案：\n" + solution 

7.3 集成到现有工作流

nanobot的分析结果不仅可以记录在日志中，还可以：

1. 发送到钉钉/企业微信：通过webhook将分析结果推送到团队群
2. 创建工单：自动在JIRA、Redmine等系统中创建故障工单
3. 更新CMDB：如果分析发现是配置问题，自动更新配置管理数据库
4. 触发自动化脚本：对于已知的、有固定处理流程的告警，直接触发修复脚本

实现这些集成通常需要在nanobot的响应处理部分添加相应的API调用。

7.4 学习历史处理经验

nanobot可以学习历史告警的处理记录，变得越来越智能。实现思路：

1. 将每次告警的分析结果和最终解决方案保存到数据库
2. 当类似告警再次出现时，从历史记录中寻找相似案例
3. 基于历史案例给出更准确的建议

这需要扩展nanobot的数据存储和检索能力，但可以显著提升应答质量。

8. 总结：AI助手如何改变运维工作方式

通过将nanobot与Zabbix对接，我们实现了一个智能的告警自动应答系统。让我们回顾一下这个方案带来的价值：

8.1 核心价值总结

对值班人员：

• 降低门槛：即使经验不足，也能获得专业的指导
• 节省时间：不用从头开始搜索解决方案
• 减少压力：有明确的排查步骤，心里有底
• 避免遗漏：结构化的分析确保关键步骤不被忽略

对团队：

• 知识沉淀：所有的分析建议都被记录下来，形成知识库
• 处理标准化：确保不同人员处理告警时方法一致
• 效率提升：常见告警可以快速响应，释放人力处理更复杂的问题
• 持续改进：通过分析历史应答，不断优化处理流程

对系统：

• 更快响应：AI可以24小时即时响应告警
• 更准分析：基于大量运维知识给出建议
• 可扩展性：可以轻松集成到现有的运维工具链中

8.2 实践经验与建议

在实际部署和使用过程中，我总结了一些经验：

开始阶段：

1. 从小范围开始：先在一两台测试服务器上试用，验证效果
2. 设置安全边界：严格控制nanobot的执行权限，只允许读取操作
3. 人工复核：初期所有AI建议都经过人工确认后再执行

优化阶段：

1. 持续优化提示词：根据实际效果调整提示词，让回答更符合需求
2. 丰富知识库：将团队的处理经验逐步添加到知识库中
3. 设置反馈机制：让使用人员可以评价AI建议的质量

扩展阶段：

1. 集成到工作流：将AI分析结果自动推送到值班群、工单系统等
2. 实现自动处理：对已知的、低风险的告警实现自动修复
3. 多模型支持：根据告警类型选择最合适的模型进行分析

8.3 注意事项与局限

虽然这个方案很有用，但也要认识到它的局限：

1. 不是万能解：AI基于模式识别和已有知识，对于全新的、复杂的问题可能无法给出正确建议
2. 需要人工监督：特别是涉及系统修改的操作，必须有人工确认
3. 依赖数据质量：分析结果的准确性依赖于告警信息的完整性和准确性
4. 有学习成本：需要时间优化提示词和知识库，才能达到最佳效果
5. 资源消耗：大模型推理需要GPU资源，需要考虑成本

8.4 下一步探索方向

如果你对这个方案感兴趣，可以继续探索：

1. 多监控系统支持：除了Zabbix，还可以对接Prometheus、Nagios等其他监控系统
2. 多模态分析：结合日志、指标、链路追踪等多维度数据进行分析
3. 预测性维护：基于历史数据预测可能发生的问题，提前预警
4. 自动化修复：对于已知问题，实现从分析到修复的完整自动化
5. 团队协作：让AI协助进行故障复盘、文档编写等团队工作

AI在运维领域的应用还处于早期阶段，但已经展现出巨大的潜力。通过nanobot这样的轻量级工具，我们可以以很低的成本开始尝试，逐步积累经验，最终构建出真正智能的运维体系。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 ZEEKLOG星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。