产品实测··Sevion Xia
RST AI Copilot for Zabbix 实战测评
核心交换机一个上联口开始丢帧，Zabbix 先报下游的连库超时和丢包，根因告警晚到 5 分钟：看 RST AI Copilot for Zabbix 如何依据触发器依赖找出根因，并在一分钟内查到端口物理层故障。
版本 v1.0 · 2026-10 · 测评环境：RST AI Copilot for Zabbix 2.0.3 · Zabbix 7.0.31 LTS（server · web · Agent 2，PostgreSQL 16）· 模型 MiniMax-M3
摘要
核心交换机 core-sw-01 通往订单系统接入交换机的上联口 Gi1/0/1 开始劣化，光路双向丢帧，核心侧收端持续计错包。此后十分钟里，Zabbix 先报订单服务连库超时，接着是三台订单主机的 ICMP 丢包，5 分钟后才报出根因：一条「警告」级的接口错包率告警。又过 4 分钟，订单门户健康检查失败，成为整屏唯一的「严重」级告警。同一屏里还有一条无关的 /etc/passwd 变更提示。
本次测评在 11 台主机的 Docker 实验网中进行，Agent 2、SNMP、ICMP、Web 场景均真实采集，模板为 Zabbix 官方模板；故障用 tc netem 在交换机上真实注入（双向 20% 丢帧，可复现）。交换机由 net-snmp 模拟，接口错包计数按「收到的包数 × 丢帧率」合成，这是全文唯一的合成数字。告警之后的研判与调查由 RST AI Copilot for Zabbix 完成，以下数据均来自 2026-10-13 的同一次实跑：
- 研判：9.6 秒内将 8 条 Problem 事件归为 7 组。依据 Zabbix 触发器依赖识别出 1 起告警风暴，根因为 core-sw-01（置信度 90%），下游 3 台订单主机的 5 组告警收进根因，处置队列只剩两行：根因排第一，无关的账号变更排第二。
- 调查：对根因发起自主调查，16 次只读调用、42.2 秒，查到 Gi1/0/1 入向错包 8/s、出向为 0，排除拥塞和接口抖动，横向对比显示同类交换机中只有 core-sw-01 在出错，判定为该端口物理层（光模块或线缆）故障。
- 护栏：调查只能调用 Zabbix 的
*.get只读接口，查询范围由网关固定在选定主机组；每次调用最多返回 20 条，数据脱敏后才提交给模型；每次调查受轮数、时限和 token 预算约束。
Zabbix 负责采集和告警，RST AI Copilot for Zabbix 在一分钟内给出这屏告警背后的根因，并附上取证过程。处置由人决定。
一、序章
测评网络是 IDC-A 机房的一段实验网，共 11 台被监控主机。核心交换机 core-sw-01 下联两台接入交换机：access-sw-03 接订单系统（门户 ord-web-01/02、订单应用 ord-app-01、缓存 ord-cache-01），access-sw-04 接库存系统（inv-web-01、inv-db-01）。订单数据库 ord-db-01 和备份服务器 bak-01 在核心侧。另有一个容器持续访问两个业务，让链路上有真实流量。三台交换机为 Cisco IOS 设备（net-snmp 模拟），其余主机为真实运行的容器。
01:33:32，core-sw-01 Gi1/0/1（接 access-sw-03 的上联）开始双向丢帧，核心侧收端每秒计 6 到 8 个错包。订单应用到数据库的连接要经过这段链路，01:34 起出现连库超时；01:37 起三台订单主机的 ICMP 丢包时有时无；01:39 接口错包率告警触发；01:43 订单门户健康检查失败。库存系统走 Gi1/0/2，未受影响。
01:44，值班工程师打开 Zabbix「问题」页：
时间窗内共 8 条 Problem：门户健康检查失败（严重）、订单服务连库超时（一般严重）、core-sw-01 接口错包率（警告）、三台订单主机 ICMP 丢包（警告，其中两条已恢复）、bak-01 的 /etc/passwd 变更（信息）。图中有两条告警的恢复时间显示为 16:51、持续 15 小时：实验机在本次测评完成后约 01:46 停机，当天 16:51 重新启动，这两条告警在重启后才恢复。工程师需要回答三个问题：
- 先处理哪条？ 最响的是门户，最早的是连库超时；根因所在的接口告警和三条丢包告警一样是「警告」。
- 哪些属于同一事件？ 连库超时、门户失败、几台主机的丢包是否同源，账号变更是否相关。
- 根因是什么？ 应用连不上库，可能是数据库、应用本身或中间网络的问题，需要逐台翻图形、登录交换机看计数器。
RST AI Copilot for Zabbix 部署在 Zabbix 之上，通过 Zabbix API 读取问题、事件、触发器和历史数据，不替代采集和告警，负责告警之后的研判与调查。同一时刻，它的「告警」页按严重度和时间汇总了这些 Problem：
二、双线复盘
下表左侧是链路上实际发生的事件，右侧是 Zabbix 是否告警，以及 RST AI Copilot for Zabbix 补充的信息。
时间为本地时间；告警时刻取 Zabbix 事件时间。
| 时间 | 实际事件 | Zabbix 告警 | RST AI Copilot for Zabbix 补充 |
|---|---|---|---|
| 01:13 | bak-01 上新建了一个系统账号（无关） |  /etc/passwd has been changed · 信息（01:28:16，校验和每 15 分钟比对一次） | 单独成组，严重度只上调一级到「低」，排第二 |
| 01:33:32 | core-sw-01 Gi1/0/1 双向约 20% 丢帧，核心侧收端开始计错包 |  无（模板要求错包率连续 5 分钟大于 2/s） | 调查查到 Gi1/0/1 入向错包 8/s、出向 0 |
| 01:34:01 | 订单应用到 ord-db-01 的连接跨过这段链路，开始超时 | Order service: DB connection timeouts · 一般严重（第一条告警） | 收进根因，不单列 |
| 01:37:33 至 01:37:36 | 经这段链路 ping 订单主机，丢包 | High ICMP ping loss · 警告 ×3（ord-web-01、ord-app-01、ord-web-02） | 收进根因（下游 3 台），不单列 |
| 01:39:02 | 错包率满 5 分钟 | Interface Gi1/0/1(uplink-access-sw-03): High error rate · 警告（比第一条症状晚 5 分钟） | 依据触发器依赖判为风暴根因（置信度 90%），排第一 |
| 01:43:03 | 门户 /health 依赖应用连库，返回 503 | Order portal: health check failed · 严重（01:44:03 恢复） | 收进根因，不单列 |
| 全程 | access-sw-03 经这段链路丢包 | 无（丢包未达触发条件） | 订单主机的触发器依赖 access-sw-03，access-sw-03 依赖 core-sw-01；中间一跳没有告警，关联沿依赖链继续向上找到 core-sw-01 |
| 全程 | ord-db-01 本身正常，故障在到它的路径上 | 无 | 未列入 |
| 全程 | 库存系统经 Gi1/0/2，链路正常 | 无 | 调查横向对比：access-sw-04 错包为 0 |
两类行值得注意。一类是没有告警的行：链路劣化后的前 5 分钟，Zabbix 没有任何指向链路的告警，接入交换机 access-sw-03 全程没有告警。另一类是根因那一行：它比第一条症状晚 5 分钟，级别与三条丢包告警相同，在「问题」页里排在门户的严重告警之后。
core-sw-01 Gi1/0/1 的入向错包在 01:33 之后上升，稳定在每秒 6 到 8 个（最后一个采集点 01:45:02，之后的平线是 Zabbix 对缺数据的连线）：
同一时段，订单服务每分钟连库超时次数越过触发阈值 5：
Zabbix 中已按链路配置触发器依赖：订单主机的 ICMP / Agent 触发器依赖 access-sw-03 的「ICMP 不可达」，access-sw-03 依赖 core-sw-01。这是 RST AI Copilot for Zabbix 判断根因的依据：
11 台主机均在线，采集正常：
三、研判
工程师在「告警收敛」页选择主机组 IDC-A，时间窗 30 分钟，点击「开始收敛」。产品拉取时间窗内的 Problem 事件（之前开始、仍未恢复的也包括在内），先按触发器依赖、LLDP 邻居、同组同时爆发三种依据识别告警风暴和根因，再按（触发器，主机）分组，附上设备台账中的厂商、型号和角色，由模型完成评级、排序、误报判断和处置建议。
01:44:23 点击，01:44:33 出结果，用时 9.6 秒。8 条 Problem 事件归为 7 组，识别出 1 起风暴，5 组下游告警收进根因，其余 2 组全部评分，无降级。严重度：高 1 组、低 1 组，没有一组被判为误报。
风暴卡片列出根因设备 core-sw-01、依据「触发器依赖」、置信度 90%，影响设备 4 台、收敛故障 6 条、事件 7 条，下游设备为 ord-app-01、ord-web-01、ord-web-02：
| 优先级 | 严重度 | 判断 / 设备 | 故障数 | 研判要点 |
|---|---|---|---|---|
| #1 | 高 | 网络异常 · 根因 · 下游 3 台 · core-sw-01 | 1 | 查 Gi1/0/1 的 CRC / error / drop 计数与 SFP 光功率，必要时切换备用上联或更换 SFP；恢复后下游 3 台主机、6 条告警应随之消除 |
| #2 | 低 | 可疑操作 · bak-01 | 1 | 核对 /etc/passwd 变更记录与变更工单，检查登录与 sudo 日志 |
在 Zabbix 中级别为「警告」的接口告警排在第一。门户健康检查失败是整屏唯一的「严重」告警，作为根因的下游症状收进风暴，没有单列。
研判结果是给工程师的起点，落地前建议核对几处细节：
- #2 的定性：模型把账号变更判为「可疑操作」，并建议按安全事件排查。它在 Zabbix 中是「信息」级，产品只将其上调一级到「低」，排在根因之后；是否属于正常变更，以变更工单为准。
- 下游范围：风暴卡片列出的是时间窗内有告警的 3 台主机。ord-cache-01 同样挂在 access-sw-03 下，本次没有告警，排查影响面时应一并考虑。
四、调查
工程师对排第一的根因组点击「深入调查」。
调查分两步：
- 初始语境：模型介入前，服务端准备好 Problem 本身（脱敏，并作为不可信数据隔离）、设备台账中的厂商、型号和角色，以及由网关固定的查询范围（主机组 IDC-A）。
- 自主检索：模型从 10 个网络工具（错包、抖动、流量、ICMP、重启、设备健康、路由邻居、邻居问题、同类对比、变更信号）和一个通用只读调用
zabbix_call中挑选工具，每次调用先经网关校验再执行，按返回结果决定下一步。默认最多 6 轮模型调用、180 秒，每轮可发起多次调用。
本次调查共 16 次只读调用、42.2 秒，置信度 high，无降级（报告头部显示为「AGENTIC 16 轮」）。
链路取证：入向错包 8/s，排除拥塞与抖动
模型先看核心交换机和故障端口本身：
| 次序 | 工具 · 对象 | 返回 |
|---|---|---|
| 1 | net_icmp · core-sw-01 | 丢包 0%，时延 0.1 ms |
| 2 | net_interface_errors · core-sw-01 Gi1/0/1 | 入向错包 8/s，出向 0，无丢弃 |
| 3 | net_interface_flaps · Gi1/0/1，24 小时 | 无 up/down 记录 |
| 4 | net_interface_traffic · Gi1/0/1，6 小时 | 峰值 104 Kbps，10G 端口，利用率约 0% |
| 5 | net_change_signals · core-sw-01 | 一次重启信号（实验网前一天重建留下），与错包时间不吻合 |
| 6 | net_device_health · core-sw-01 | 无 CPU / 内存 / 温度监控项 |
| 15 | net_interface_traffic · Gi1/0/1，24 小时 | 同第 4 次，拉长窗口确认不是拥塞 |
| 16 | net_routing_neighbors · core-sw-01 | 无 BGP / OSPF 监控项 |
错包只出现在入向，接口没有抖动，流量远低于端口带宽，排除拥塞和路由震荡。
横向对比：同类交换机中只有 core-sw-01 出错，42.2 秒出结论
模型接着查对端和周边：
| 次序 | 工具 · 对象 | 返回 |
|---|---|---|
| 7 | net_icmp · access-sw-03 | 查询时刻丢包 0% |
| 8、12 | net_interface_errors · access-sw-03（Gi1/0/1、GigabitEthernet1/0/1） | 无匹配接口，对端上联实际为 Gi1/0/48 |
| 9 | net_neighbor_problems · core-sw-01 | 同组其他主机的 6 条问题 |
| 10、11、13 | zabbix_call · problem.get | 参数不合法，Zabbix 返回错误，模型改用网络工具 |
| 14 | net_peer_compare · 同模板设备的 ifInErrors | core-sw-01 为 8，排名第一；access-sw-03 为 0，access-sw-04 为 0 |
第 14 次的横向对比是关键证据：同模板的三台交换机中只有 core-sw-01 的入向错包不为 0。第 10、11、13 次是模型直接调用 problem.get 时参数写法不被 Zabbix 接受，错误作为结果返回给模型，没有中断调查，也没有计入证据。
结论（置信度高，非误报）：
core-sw-01 的 Gi1/0/1（uplink-access-sw-03）出现持续入向错误（in_errors≈8/s，无输出错误/丢弃），接口未抖动、流量极低（峰值 0% 利用率），且与同组其它接入交换机（errors=0）相比为个例，提示该链路物理层/SFP 或对端 access-sw-03 端口存在入向 CRC/编码类问题，并非拥塞导致。
报告给出 5 条处置建议：在 core-sw-01 上查看 Gi1/0/1 的 transceiver 和 counters errors；在 access-sw-03 对应上行口核对收光功率；光功率异常则更换光模块或跳线，并观察 15 分钟 in_errors 是否归零；仍未归零则收集 show tech-support 提交厂商。
复核要点
阅读报告时建议核对以下几处：
- 下游症状的归属：报告的影响链将订单主机的丢包和连库超时写为「同主机组另一独立事件」，并建议另开工单；依据是第 1、7 次查询时 core-sw-01 和 access-sw-03 丢包为 0。间歇丢包在单个时刻可能显示为 0，而研判的风暴卡片已依据触发器依赖将这 5 组告警收进根因。两处说法不一致时，以依赖关系推出的风暴卡片为准。
- 时间线第一条：「core-sw-01 检测到一次重启」来自实验网前一天的重建，与本次故障无关；该条时间以 UTC 显示，「约 31 小时前」应为约 23 小时。2.0.3 已将变更信号的时间改为按浏览器时区输出。
- 对端检查：模型两次猜错对端接口名，没有拿到 access-sw-03 Gi1/0/48 的错包计数，「单向故障」的判断依据是横向对比。处置建议中已包含对端收光检查。
所有研判和调查都归档在「分析记录」中，可回看复核：
五、护栏
让模型自行选择查询，需要防止越权、越界和内网信息外泄。本次调查受以下机制约束：
- 只读与校验：调查和对话中的每次 Zabbix 调用都经网关校验，只放行
*.get，create、update、delete一律拒绝。产品的写操作只有确认 / 关闭告警、维护窗口等，按角色授权，且需人工确认，研判和调查不会触发。本次 16 次调用全部为只读；其中 3 次problem.get参数不合法，被 Zabbix 拒绝后以错误返回给模型。 - 主机组范围：查询范围由网关注入为选定的主机组（本次为 IDC-A），模型无法改写。
- 返回上限与脱敏：每次调用最多返回 20 条；发给模型前按模式脱敏，云端模型模式下 IP 截到 /24，邮箱打码，口令、令牌、Cookie 替换为占位符。本次使用云端模式。Problem 名称、标签、主机描述等进入提示词时用随机边界标记隔开，作为不可信数据处理。
- 预算：每次调查最多 6 轮模型调用、180 秒，可另设 token 预算；超限返回降级结果并明确标注。本次 42.2 秒完成，无降级。
- 严重度约束：模型最多把 Zabbix 触发器的原级别上调一级，只有风暴根因组不受此限；处置队列先按根因、再按最终严重度排序。本次 bak-01 的「信息」级告警只上调到「低」。
- 证据留存：报告附调用轨迹和每条结论的依据，研判和调查结果归档在分析记录中，工程师可以逐条对照。
六、价值与结论
运维团队的主要人力成本在告警之后：读懂一屏 Problem、判断哪些同源、逐台排查。这个过程慢、因人而异，且依赖资深工程师。
更快：8 条 Problem 的关联、排序和处置建议 9.6 秒完成；从接口告警查到端口物理层故障 42.2 秒。
可复现、可审计：关联依据是 Zabbix 中已配置的触发器依赖，每次结果一致；调查的每次调用、返回和结论依据都留存在分析记录中。
降低经验门槛：「门户告警最响，但应先看核心交换机的错包」原本依赖资深工程师的判断；配置好触发器依赖后，一线工程师点击「开始收敛」和「深入调查」即可得到同样的排序和取证过程。
| 环节 | 人工 | RST AI Copilot for Zabbix |
|---|---|---|
| 排优先级 | 按 Zabbix 严重度查看，门户告警排在最前，根因告警与丢包告警混在一起 | 9.6 秒识别告警风暴，根因排第一，5 组下游症状收进根因 |
| 区分噪声 | 无关告警与故障告警在同一屏，逐条判断 | 账号变更单独成组，只上调一级，排在根因之后 |
| 根因定位 | 逐台查看图形，登录交换机比对计数器 | 16 次只读调用、42.2 秒，排除拥塞、抖动、路由，横向对比定位到单台设备 |
| 处置建议 | 依赖个人经验 | 5 条具体到设备和接口的排查步骤 |
| 数据安全 | 无专门约束 | 只读调用、主机组范围、返回上限、出网脱敏 |
本次实跑中，Zabbix 完成了每台主机、每个服务的采集和告警；RST AI Copilot for Zabbix 在 9.6 秒内把一条「警告」级、比第一条症状晚 5 分钟的接口告警识别为风暴根因并排在第一，把 5 组下游症状收进根因，又在 42.2 秒内将其定位到 core-sw-01 Gi1/0/1 的物理层。
每条结论都附带实际执行过的调用和返回结果，工程师可以对照证据复核后再动手。产品不自动处置，更换光模块、切换上联等决定仍由人做出。告警交给 Zabbix，研判交给 RST AI Copilot for Zabbix，决策留给人。