Zabbix AI技能实战：基于MCP协议实现自然语言监控运维自动化

1. 项目概述如果你和我一样在运维Zabbix监控系统超过五年那你一定经历过这样的场景凌晨三点被告警电话吵醒登录Zabbix Web界面手忙脚乱地点击一个又一个菜单试图搞清楚到底是哪个主机的哪个触发器出了问题背后又是什么指标异常。或者当需要给一批新上线的服务器批量添加监控模板时你得在Web界面上重复几十次“选择主机-链接模板-保存”的机械操作。更别提那些复杂的维护窗口设置、模板升级对比、问题根因分析——每一项都需要你对Zabbix API有深入的理解并且能熟练地编写脚本或手动组合多个API调用。这些重复、繁琐且容易出错的操作消耗了我们大量本该用于优化系统和保障稳定性的宝贵时间。这就是为什么当我第一次接触到initMAX/zabbix-ai-skills这个项目时我感到眼前一亮。它不是一个全新的监控平台也不是一个要替代Zabbix的复杂系统。相反它是一个极其聪明的“翻译官”和“自动化执行器”。简单来说它把我们在Zabbix运维中那些高频、复杂但又有固定模式的操作封装成一个个可以直接用自然语言调用的“技能”。你不再需要记忆host.get或trigger.update的API参数也不需要写Python脚本去串联多个查询。你只需要像跟同事对话一样告诉AI助手“帮我看看现在有哪些严重问题”或者“给web-prod集群创建一个两小时的维护窗口”剩下的工作AI会通过背后的Zabbix MCP Server自动完成。这个项目的核心价值在于它通过Model Context Protocol这座桥梁将强大的大语言模型与成熟的Zabbix API工具库连接起来。MCP可以理解为AI助手与外部工具这里是Zabbix通信的标准协议。而zabbix-ai-skills则是在这个协议之上定义了一套“最佳实践工作流”。每个技能Skill都是一个精心编写的Markdown提示词里面包含了完成某个特定任务如调查主机、升级模板所需的完整逻辑步骤。AI助手读取这个提示词后就知道该按什么顺序、调用哪些Zabbix MCP工具并最终将结果组织成清晰、可读的报告呈现给你。无论你是每天都要处理上百条告警的资深运维工程师还是刚刚接手Zabbix、对API还不甚熟悉的新手这个项目都能显著提升你的工作效率。它特别适合以下几类场景日常巡检与状态概览、批量配置与变更管理、复杂问题诊断与根因分析、以及合规审计与报告生成。接下来我将带你深入拆解这个项目的设计思路、核心技能的使用方法并分享我在实际部署和扩展过程中的一些实战经验与避坑指南。2. 核心架构与设计思路拆解要真正用好zabbix-ai-skills不能只停留在“会敲命令”的层面。理解其背后的架构设计和运作原理能帮助你在遇到复杂场景时举一反三甚至定制属于自己的专属技能。这套系统的设计非常巧妙它清晰地分为了三层交互层、编排层和执行层。2.1 三层架构解析第一层交互层AI客户端这是你直接打交道的界面。它可以是Claude Code、VS Code Copilot、Cursor或者任何支持MCP协议的AI应用。你的所有指令无论是输入/zabbix-status这样的快捷命令还是用自然语言描述“帮我分析一下db-01为什么CPU告警”都在这一层被AI模型接收和理解。这一层的关键在于“理解意图”AI需要将你模糊的人类语言转化为明确、可执行的“任务目标”。第二层编排层Skills 技能库这是整个项目的智慧核心也是zabbix-ai-skills仓库所提供的主要内容。每一个.md文件都是一个独立的“技能剧本”。我们以/zabbix-investigate这个技能为例拆开它的剧本看看# 深度调查主机 ## 目标 全面诊断指定主机的健康状况包括当前问题、近期事件、关键指标趋势及配置关联性。 ## 步骤 1. 使用 mcp__zabbix__host_get 工具根据用户提供的主机名或IP获取主机的完整信息包括主机ID、所属群组、已链接的模板。 2. 使用 mcp__zabbix__problem_get 工具传入上一步获得的主机ID查询该主机上所有未恢复的问题按严重性排序。 3. 对于每一个活跃问题使用 mcp__zabbix__trigger_get 获取触发器的详细表达式并使用 mcp__zabbix__item_get 获取关联监控项的最新值进行表达式解读。 4. 使用 mcp__zabbix__history_get 工具获取该主机关键性能指标如CPU、内存、磁盘、网络过去24小时的历史数据用于绘制趋势图或判断基线。 5. 使用 mcp__zabbix__event_get 工具获取主机近期的事件日志辅助判断问题发生前后的其他关联事件。 6. 综合以上所有信息生成一份结构化报告先概述主机状态然后列出并分析每个活跃问题原因、当前值、阈值接着展示关键指标趋势最后给出诊断结论和行动建议。这个“剧本”没有一行真正的执行代码它全部是给AI看的“指导手册”。它告诉AI要完成“调查主机”这个任务你需要按顺序执行A、B、C、D、E这五个步骤每个步骤调用哪个工具工具的参数从哪里来上一步的结果如何传递给下一步最终的报告应该包含哪些部分。AI就像一个经验丰富的导演严格按照剧本调度各个“演员”MCP工具出场表演。第三层执行层Zabbix MCP Server这是干脏活累活的“工人”。Zabbix MCP Server是一个独立的后端服务它封装了超过220个Zabbix API方法并将它们暴露为标准的MCP工具。当编排层的AI发出指令“调用mcp__zabbix__host_get参数是filter: {host: [“web-01”]}”时MCP Server就会接管工作它负责与真实的Zabbix Server建立API连接处理认证API Token发送格式正确的JSON-RPC请求解析Zabbix返回的复杂数据并将其整理成AI和人类都能理解的简洁格式返回。为什么选择MCP而不是直接调用API这是设计上的关键决策。直接让AI生成和调用Zabbix API代码是危险且低效的。API参数复杂错误处理繁琐且AI可能生成不安全的代码。MCP提供了一个安全、标准化的沙箱。AI只需要知道工具的名称和简单描述无需关心底层HTTP调用和JSON解析。这大大降低了AI出错的概率也使得技能可以跨不同的AI客户端Claude, ChatGPT等通用因为它们都遵循同一套MCP协议来调用工具。2.2 技能的设计哲学从“怎么做”到“要什么”传统自动化脚本关注“怎么做”How写死流程处理异常。而AI技能关注“要什么”What和“为什么”Why。技能剧本只定义目标和逻辑步骤具体的执行路径、参数填充、甚至简单的条件判断比如“如果找不到主机就询问用户”都交给AI的推理能力去完成。这种设计带来了巨大的灵活性。例如在/zabbix-add-host技能中剧本会要求AI“询问用户主机名然后查询现有群组和模板列表供用户选择”。AI在执行时会先调用mcp__zabbix__hostgroup_get和mcp__zabbix__template_get获取实时数据动态生成选项列表呈现给用户。这种“交互式向导”体验是静态脚本难以实现的。2.3 安全性与权限模型安全性是运维自动化的生命线。zabbix-ai-skills本身不存储任何Zabbix凭证它完全依赖底层的Zabbix MCP Server进行认证和授权。这意味着权限继承AI技能拥有的权限就是配置给MCP Server的那个API Token所拥有的权限。如果你只给Token只读权限那么所有技能都无法执行创建、删除等写操作。这符合最小权限原则。操作可审计所有通过AI技能执行的操作最终都会通过MCP Server的API调用记录在Zabbix的审计日志中操作者会显示为持有该API Token的用户便于事后追溯。输入验证虽然AI会尝试理解用户意图但关键的、可能产生破坏性操作的指令如删除主机、关闭触发器在技能剧本中通常会设计确认环节或者依赖于MCP Server端进行二次校验。理解了这个三层架构你就明白了zabbix-ai-skills不是一个“黑魔法”而是一个设计精良的、将人类自然语言意图转化为安全可靠自动化操作的“翻译与执行框架”。接下来我们看看如何亲手搭建这个框架并让它为你工作。3. 环境搭建与核心组件配置实战纸上得来终觉浅绝知此事要躬行。要让zabbix-ai-skills真正跑起来需要完成几个核心组件的部署和联调。别被“AI”、“MCP”这些词吓到整个搭建过程其实非常清晰只要按步骤来半小时内就能看到效果。我会基于最常见的场景——在Linux服务器上为团队部署一套共享环境——来详细说明。3.1 基础环境准备首先你需要一个已经安装好的Zabbix Server版本最好在6.0以上以确保API的完整性和稳定性。同时准备一台用于运行Zabbix MCP Server的机器这台机器需要能通过网络访问你的Zabbix Server API。这台机器可以是单独的服务器也可以是你本地的工作站。操作系统与依赖我推荐使用 Ubuntu 22.04 LTS 或 Rocky Linux 9 这类有长期支持的发行版。确保系统已安装Python 3.9这是运行MCP Server的必需环境。Git用于克隆代码仓库。Docker可选但推荐如果你希望环境隔离且部署简单用Docker是最佳选择。3.2 核心引擎部署 Zabbix MCP Server这是整个体系的“发动机”必须首先安装。官方提供了多种方式这里我强烈推荐使用Docker Compose它能一键解决依赖和环境问题。步骤一获取部署文件在你的服务器上创建一个工作目录例如/opt/zabbix-mcp然后进入该目录。mkdir -p /opt/zabbix-mcp cd /opt/zabbix-mcp curl -O https://raw.githubusercontent.com/initMAX/zabbix-mcp-server/main/docker-compose.yml这个docker-compose.yml文件已经定义好了MCP Server服务及其配置。步骤二配置连接信息接下来创建一个环境变量文件.env来存放你的Zabbix连接密钥避免敏感信息泄露。cat .env EOF # 你的Zabbix Server地址确保MCP Server容器能访问到 ZABBIX_URLhttps://your-zabbix-server.example.com/api_jsonrpc.php # 在Zabbix Web界面【管理】-【一般】-【API令牌】中创建的Token # 注意根据你希望AI拥有的权限为这个Token分配合适的角色如只读、管理员等 ZABBIX_TOKENyour_super_long_api_token_here # MCP Server监听的端口默认8080可按需修改 MCP_PORT8080 EOF关键提示关于API Token的权限这是安全配置的重中之重。切勿直接使用“超级管理员”角色的Token。根据AI技能的使用范围创建专属Token并赋予最小必要权限。例如如果只用于查询状态和问题就创建一个只有“读”权限的角色。如果需要创建维护窗口则额外添加“主机组”和“维护”的写权限。遵循最小权限原则即使Token泄露也能将损失降到最低。步骤三启动服务使用Docker Compose启动服务。docker-compose up -d使用docker-compose logs -f zabbix-mcp-server查看启动日志确认没有报错并且看到类似“Server started on port 8080”的消息。步骤四验证服务通过一个简单的curl命令测试MCP Server是否正常工作并列出可用的工具。curl -X POST http://localhost:8080/mcp \ -H Content-Type: application/json \ -d {jsonrpc:2.0, method:tools/list, id:1} | jq .如果返回一个包含大量工具如mcp__zabbix__host_get,mcp__zabbix__problem_get的列表恭喜你MCP Server已经成功部署并连接到了Zabbix3.3 技能库部署与AI客户端配置“发动机”准备好了现在来安装“自动驾驶程序”——也就是技能库。步骤一克隆技能库在MCP Server同一台机器或你的本地工作机上克隆技能仓库。git clone https://github.com/initMAX/zabbix-ai-skills.git cd zabbix-ai-skills这个skills/目录下就是所有预定义的技能Markdown文件。步骤二配置AI客户端以Claude Code为例不同的AI客户端配置方式不同但核心都是两点1. 告诉客户端MCP Server在哪2. 告诉客户端技能库在哪。这里以目前体验最好的Claude Code为例。在你的项目根目录或者用户家目录下创建或编辑.claude/settings.json文件{ mcpServers: { zabbix: { command: docker, args: [ run, -i, --rm, --networkhost, -v, /path/to/your/.env:/app/.env, initmax/zabbix-mcp-server:latest ] } }, skills: { directory: /absolute/path/to/zabbix-ai-skills/skills } }配置详解mcpServers.zabbix: 这里没有使用上一步的HTTP服务模式而是直接让Claude Code启动Docker容器。这样做的好处是客户端自动管理MCP Server的生命周期无需手动维护后台服务。--networkhost让容器使用主机网络方便连接本地的Zabbix如果Zabbix也在本机。-v参数将你的.env配置文件挂载到容器内。skills.directory: 这里必须填写技能库skills/文件夹的绝对路径。这样Claude Code才能扫描到所有技能并将它们注册为可用的/slash命令。步骤三验证技能加载重启你的Claude Code编辑器或IDE。在聊天窗口中输入/你应该能看到一个以zabbix-开头的命令列表例如/zabbix-status,/zabbix-investigate等。如果能看到说明技能库已成功加载。至此整个技术栈已经搭建完毕。你拥有了一个随时待命的Zabbix AI助手。接下来我们通过几个最核心的技能来看看它如何颠覆我们日常的运维工作流。4. 核心技能深度解析与实战应用技能库提供了三十多个开箱即用的技能覆盖了监控运维的方方面面。我不可能面面俱到但我会挑出几个最能体现其价值、也是我日常使用频率最高的核心技能带你进行深度实操演练并分享一些从官方文档里看不到的细节和技巧。4.1 日常运维的“驾驶舱”/zabbix-status与/zabbix-health这两个技能是你每天打开电脑后第一个应该运行的命令它们能让你在30秒内对整个监控系统的健康状况了如指掌。/zabbix-status问题态势总览当你输入/zabbix-status后AI会执行一系列操作调用problem.get获取所有未恢复的问题。调用host.get和hostgroup.get来丰富问题信息比如主机所属的业务组。按严重性灾难、严重、一般、警告对问题进行分组和排序。高级操作尝试关联问题将可能由同一根因引发的多个告警归类在一起。实战输出示例与解读 /zabbix-status 正在分析当前告警态势... 灾难 (2个问题): • [数据库集群] db-master-01: MySQL服务宕机 (持续 15分钟) 影响: 主库失联所有写操作中断。 • [网络核心] core-switch-01: BGP会话丢失 (持续 8分钟) 影响: 机房B网络隔离。 严重 (5个问题): • [Web服务器] web-01, web-02: CPU使用率 95% (持续 5分钟) 模式: 同一负载均衡组下两台服务器同时告警疑似应用层问题。 • [存储] nfs-01: 磁盘响应时间 200ms (持续 20分钟) 影响: 所有依赖此存储的服务性能下降。 一般 (12个问题): (主要为磁盘空间不足、内存使用率高等) 警告 (7个问题): (主要为日志量增长、连接数偏高等) 统计摘要: • 总计: 26个未恢复问题 • 涉及主机: 18台 • 涉及业务组: 6个 • 最旧问题: “磁盘空间不足” on backup-01 已持续 3天 (建议优先处理)这个报告的价值在于它不仅仅是列表而是做了初步的聚合与关联分析。它告诉你“数据库”和“网络”有灾难级问题需要立刻处理同时指出web服务器的CPU告警具有关联性可能指向同一个应用发布。最后它甚至能提醒你那些持续了很久但严重性不高的问题比如3天的磁盘告警这些往往是容易被忽视的隐患。/zabbix-health基础设施健康度检查如果说status关注“事件”那么health则关注“组件”。它检查的是Zabbix自身的运行状态以及被监控对象的可达性。 /zabbix-health Zabbix 基础设施健康检查报告 ✅ Zabbix Server 状态: • 版本: 7.0.4 • 运行时间: 45天 12小时 • 队列: 正常 (0项延迟) • 缓存命中率: 98.7% (健康) ✅ Zabbix Proxy 状态 (3个): • proxy-beijing: 在线 最后心跳 30秒前 监控 152台主机 • proxy-shanghai: 在线 最后心跳 25秒前 监控 98台主机 • proxy-guangzhou: ⚠️ 延迟 最后心跳 5分钟前 监控 67台主机 (建议检查网络) 被监控节点状态: • 总计主机: 587台 • 可达主机: 562台 (95.7%) • 不可达主机: 25台 (4.3%) • 无数据主机: 8台 (过去1小时无数据上报) 性能指标: • 每秒处理数值 (NVPS): 1250 • 配置缓存使用率: 67% • 历史数据写入延迟: 1秒这个报告帮你一眼看清监控系统本身的负载、代理节点的健康状况以及整体网络的连通性。proxy-guangzhou的延迟和那25台不可达主机就是你需要立即跟进的任务项。实操心得设置定时自动化巡检你可以将这两个技能结合创建一个自动化日报。利用Cron任务或CI/CD工具定时如每天上午9点在某个AI客户端中执行这两个技能并将输出结果发送到团队群聊或邮件。这样每天晨会前整个团队对系统状态就有了统一、清晰的认知。4.2 故障排查的“手术刀”/zabbix-investigate当status命令告诉你web-01CPU告警时传统的排查需要你1. 点开主机2. 找到最新数据3. 查看触发器表达式4. 查看历史图表5. 关联其他事件……而/zabbix-investigate将这个多步骤、跨页面的操作压缩成一条命令。深度实战调查一个复杂问题假设我们收到告警“Application latency on web-01 is too high”。 /zabbix-investigate web-01 深度调查报告web-01 (10.0.1.101) 主机概览: • 群组: Production/Web Servers • 模板: Linux by Zabbix agent active, Nginx by HTTP, Custom App Monitor • 代理: Zabbix agent (活跃式), 最后数据接收: 2分钟前 活跃问题 (1个): • 问题: Application latency on web-01 is too high • 严重性: 严重 • 持续时间: 45分钟 • 触发器表达式: {web-01:app.resp.time.last()} 2 • 解读: 监控项“应用响应时间”的最新值大于2秒即触发。 • 当前值: 3.8秒 (已超过阈值 90%) 关键指标现状 (最近值): • CPU 使用率: 78% (用户态 65% 系统态 13%) • 内存使用率: 64% (可用内存 2.1 GB) • 系统负载 (load15): 4.2 • 磁盘 I/O 等待: 15% (偏高) • 网络入流量: 85 Mbps 出流量: 120 Mbps 历史趋势分析 (过去2小时): • 应用响应时间: 从平均 0.8秒 在45分钟前开始陡升至 3.8秒。 • CPU使用率: 与响应时间上升曲线高度吻合同时从40%升至78%。 • 磁盘I/O等待: 在响应时间上升前5分钟开始增长峰值达25%。 • 网络流量: 无明显异常波动。 关联事件: • 40分钟前: “High disk I/O wait time on web-01” (警告级别) • 38分钟前: “Nginx active connections over limit on web-01” (一般级别) ️ 诊断假设: 1. **根因可能性 (高)**: 磁盘I/O性能瓶颈。I/O等待率先升高导致应用处理请求变慢进而引起CPU使用率上升和响应时间延长。 2. **关联影响**: 慢请求堆积可能导致Nginx连接数超过阈值。 3. **初步建议**: a. 立即登录 web-01使用 iostat -x 1 或 iotop 命令确认磁盘I/O状况检查是哪个进程或分区导致高负载。 b. 检查应用日志确认是否有大量磁盘读写操作。 c. 考虑将 /zabbix-investigate 目标扩展到同一存储集群的其他主机如 nfs-01进行关联排查。这份报告的价值是颠覆性的。它不再是孤立的数据点而是一个有逻辑、有时序、有假设的侦探报告。它明确指出了I/O问题是可能的原因并给出了具体的命令行排查建议。这相当于一个经验丰富的SRE坐在你旁边帮你完成了初步分析。4.3 配置管理的“流水线”/zabbix-template-upgrade手动升级Zabbix官方模板是件苦差事要去官网找对应版本下载YAML对比差异处理依赖然后导入。/zabbix-template-upgrade将这个流程完全自动化。实战一键升级“Linux by Zabbix agent active”模板 /zabbix-template-upgrade “Linux by Zabbix agent active” 开始升级模板: Linux by Zabbix agent active 1. **版本检测**: 检测到您的Zabbix Server版本为 7.0.4 将使用官方仓库的 release/7.0 分支。 2. **获取模板**: 从 git.zabbix.com 成功获取最新模板文件。 3. **差异对比**: [对比结果] 新增监控项: 2个 - system.cpu.util[guest_nice] (监控Guest nice CPU时间) - vfs.file.cksum[/etc/passwd] (监控关键文件完整性) 修改监控项: 1个 - system.cpu.util[,idle] 的更新间隔从 1m 调整为 30s 新增触发器: 1个 - “CPU guest nice time is high” (当guest_nice CPU时间超过20%时告警) 修改宏: 1个 - {$CPU.UTIL.CRIT}: 阈值从 90 调整为 95 4. **影响评估**: 此模板当前链接到 **48台** 主机。升级将影响这些主机的监控配置。 5. **安全备份**: 已自动将当前模板导出备份至 backups/linux_by_zabbix_agent_active_2023-10-27.yaml。 6. **执行升级**: 确认导入新模板并自动处理了依赖的“Linux by Zabbix agent”父模板。 ✅ 升级完成 • 模板: Linux by Zabbix agent active • 来源: git.zabbix.com (release/7.0) • 变更已应用: 2项新增 1项更新 1个新触发器 • 所有48台主机将在下次配置同步后生效。这个技能不仅自动化了流程更重要的是它提供了透明的变更预览和自动备份。你知道即将发生什么变化并且有回滚的资本。这对于生产环境的变更管理至关重要。避坑指南处理自定义修改官方模板升级最大的风险是覆盖本地自定义修改。这个技能在导入前会进行对比但如果你在官方模板上直接修改过监控项或触发器升级可能会丢失这些修改。最佳实践是永远不要直接修改官方模板。应该创建一个继承自官方模板的“自定义模板”并在子模板上进行修改。这样升级父模板时你的自定义内容会得到保留。/zabbix-template-upgrade技能会智能地处理这种继承关系。4.4 批量操作的“瑞士军刀”/zabbix-mass-update批量操作是体现自动化价值的另一个核心场景。想象一下安全团队要求给所有生产环境的服务器加上一个Security: Baseline的标签。传统方式写脚本或者更糟在Web界面上一台台点选。AI技能方式 /zabbix-mass-update add tag “Security:Baseline” to group “Production Servers” 开始批量添加标签操作... 1. **确认目标**: 您希望为群组 “Production Servers” 下的所有主机添加标签 Security:Baseline。 2. **范围确认**: 该群组下共有 **127台** 主机。是否确认执行(输入 yes/no) yes 3. **执行更新**: • 批次处理: 每批20台主机共7批。 • 进度: [████████████████████] 100% (127/127) • 结果: 成功为127台主机添加标签。0台失败主机可能已被删除或无权限。 4. **验证**: 随机抽样检查了5台主机确认标签已添加成功。 ✅ 批量操作完成这个技能内部会处理API的批量限制、错误重试和结果验证。你只需要用一句自然语言描述意图。同样的模式适用于批量链接/解链接模板、修改主机接口、调整监控间隔等。通过以上四个核心技能的深度演练你应该能深刻感受到zabbix-ai-skills如何将复杂的运维知识封装成简单的对话指令。但这还不是全部在真正大规模使用中你会遇到各种边界情况和挑战下一章我们就来聊聊这些“坑”以及如何跨过去。5. 高级技巧、问题排查与自定义技能开发当你熟练使用基础技能后自然会想探索更高效的用法、解决遇到的问题甚至创造符合自己团队需求的专属技能。这一章我将分享一些进阶的实战技巧、常见问题的排查思路并手把手带你编写第一个自定义技能。5.1 高级使用技巧与模式技巧一技能组合与串联真正的威力来自于技能的串联。AI的上下文记忆能力允许你将多个操作组合成一个连贯的工作流。场景新服务器上线监控全流程。操作流/zabbix-add-host添加主机并链接基础模板。等待几分钟让Zabbix agent开始上报数据/zabbix-investigate 新主机名验证监控数据是否正常采集。/zabbix-mass-update add tag “Env:Production” to host 新主机名打上环境标签。/zabbix-maintenance create如果需要为其安排一个初始维护窗口进行调试。你可以在一个对话会话中依次执行这些命令AI会记住之前的上下文让后续操作更顺畅比如自动填充主机名。技巧二利用自然语言进行模糊查询技能不只是为了执行精确命令更能理解模糊意图。你可以问“帮我找找最近一周经常告警但又自动恢复的主机。”AI可能会组合调用event.get(筛选触发器事件)、problem.get(筛选已恢复的问题) 和host.get然后给出一个频繁“抖动”的主机列表。你可以说“对比一下生产环境和测试环境中‘Linux by Zabbix agent’模板的监控项有什么区别。”AI可以分别获取两个模板并生成一个差异对比表格。技巧三结果输出格式优化默认的输出是Markdown文本但你可以指导AI进行格式化。“把 /zabbix-status 的结果用表格形式列出来按持续时间排序。”“将 /zabbix-inventory 的结果生成一个CSV格式方便我导入Excel。”“把 /zabbix-capacity 的预测结果画一个简单的ASCII趋势图。”AI会根据你的要求对MCP工具返回的原始数据进行二次处理和格式化。5.2 常见问题与排查实录即使设计再完善在实际网络和系统环境中也会遇到问题。这里记录几个我踩过的坑和解决方案。问题一执行技能时报错 “Failed to call tool mcp__zabbix__xxx”可能原因1MCP Server连接或配置错误。排查首先在终端用curl命令测试MCP Server的/mcp端点是否可达工具列表是否能返回。如果失败检查MCP Server的Docker容器日志 (docker-compose logs)。解决确认.env文件中的ZABBIX_URL和ZABBIX_TOKEN正确无误且Token未过期。确保网络连通性。可能原因2API Token权限不足。排查技能执行到某个写操作如host.create,maintenance.create时失败。查看MCP Server日志通常会返回Zabbix API的详细错误信息如“Permission denied.”。解决在Zabbix Web界面中为该API Token所属的用户角色添加相应的操作权限如“配置主机”、“添加维护周期”。问题二技能执行缓慢或无响应可能原因1查询范围过大。现象执行/zabbix-status或/zabbix-top时AI“思考”时间很长。排查这些技能默认可能会查询全量主机或监控项。如果你的Zabbix实例规模很大上万台主机一次性获取所有数据会非常慢。解决在技能命令中指定范围。例如/zabbix-status group “Web Servers”(如果技能支持参数)。或者在调用技能后立即用自然语言补充“只分析‘Production’群组下的主机”。AI会在后续的MCP调用中自动添加筛选条件。可能原因2AI客户端上下文过长或网络延迟。解决对于非常复杂的技能AI可能需要调用十几次MCP工具每次交互都有延迟。可以尝试在性能更好的机器上运行AI客户端和MCP Server或者将超大型任务拆分成多个小技能依次执行。问题三技能输出的结果不准确或不符合预期可能原因1AI对技能剧本的理解有偏差。排查仔细阅读对应技能.md文件里的步骤描述。有时AI可能会跳过一个步骤或误解参数。解决在对话中明确纠正AI。例如“不对请先用hostgroup.get确认群组ID再用host.get。” AI会从错误中学习并在本次会话中调整。可能原因2Zabbix数据本身的问题。现象/zabbix-anomaly报告大量异常但实际是业务高峰。解决这是算法局限性。可以指导AI调整基线计算窗口例如“使用过去30天的数据作为基线并忽略每天20:00-22:00的业务高峰时段进行计算。” 这需要你后续开发更精细的自定义技能。5.3 开发你的第一个自定义技能官方技能库已经很丰富但每个团队都有独特的工作流。创建自定义技能是终极的赋能。让我们创建一个简单的技能/zabbix-find-similar-host用于根据现有主机的配置模板、标签快速找到类似的主机方便进行批量操作参考。步骤一创建技能文件在skills/目录下新建一个文件例如find-similar-host.md。技能文件由YAML头信息和Markdown步骤说明组成。--- name: zabbix-find-similar-host description: 根据指定主机的配置模板、标签查找具有相似配置的其他主机。 args: hostname user_invocable: true --- # 查找配置相似的主机 ## 目标 给定一个主机名分析其配置已链接的模板、标签然后在Zabbix中查找具有相同或高度相似配置的其他主机。用于批量操作前的范围确认或配置审计。 ## 步骤 1. **获取目标主机配置** * 使用 mcp__zabbix__host_get 工具通过 filter: { host: [“hostname”] } 参数获取目标主机的详细信息。 * 从返回结果中提取两个关键字段parentTemplates (模板ID列表) 和 tags (标签列表)。 2. **获取所有主机进行对比** * 使用 mcp__zabbix__host_get 工具设置 output: [“hostid”, “host”, “name”, “parentTemplates”, “tags”]获取所有主机的精简配置信息。 3. **计算相似度并筛选** * 遍历所有主机对每一台主机计算其与目标主机的“配置相似度”。 * **相似度算法简单版** * 模板匹配分计算两台主机共有的模板ID数量。权重较高例如每匹配一个模板得3分。 * 标签匹配分计算共有的标签键值对均相同数量。每个匹配的标签得1分。 * 总相似度分 模板匹配分 标签匹配分。 * 筛选出相似度分数大于阈值例如总分 2的主机。排除目标主机自身。 4. **呈现结果** * 将筛选出的主机按相似度分数降序排列。 * 以表格形式输出包含列主机名、可见名称、相似度分数、共有模板数量、共有标签数量。 * 在表格下方列出目标主机所使用的模板和标签作为参考。 ## 输出示例目标主机 [web-prod-01] 的配置 • 模板: Linux by Zabbix agent active, Nginx by HTTP • 标签: Env:Production, Role:WebServer找到 4 台配置相似的主机主机名可见名称相似度共有模板共有标签web-prod-02Web Server 02721 (Env:Production)web-staging-01Staging Web 0141 (Linux)1 (Role:WebServer)api-prod-01API Server 0131 (Linux)1 (Env:Production)lb-prod-01Load Balancer 01202 (Env:Production, Role:WebServer)步骤二使用你的技能将文件保存到skills/目录。在Claude Code中重新加载技能通常重启IDE或等待其自动扫描。输入/zabbix-find-similar-host web-prod-01。AI会读取你写的“剧本”逐步执行先获取web-prod-01的模板和标签再拉取所有主机进行计算和筛选最后格式化输出。自定义技能开发心得从简单开始先实现核心逻辑比如只匹配模板。成功后再增加标签、宏等更复杂的匹配维度。描述要清晰AI完全依赖你的步骤描述。指令越清晰、越无歧义执行结果就越准确。多用“首先”、“然后”、“从结果中提取X字段”这样的连贯词。利用AI的推理能力你不需要写出完美的匹配算法代码只需要用自然语言描述计算规则。AI能理解“计算共有的模板ID数量”这样的逻辑。测试与迭代用一个测试主机进行多次尝试根据输出结果调整步骤描述或评分权重。通过开发自定义技能你可以将团队内部的最佳实践、例行检查点、甚至是复杂的故障诊断树都固化成可重复、可分享的AI工作流。这标志着你的运维自动化水平从“使用工具”迈向了“创造工具”的新阶段。