HQY

我把小时候那条街的街机厅，搬进了浏览器

Tue, 03 Nov 2026 15:13:34 +0800

你有没有过这种时刻：

刷到一段《拳皇 97》的对战录像，手指跟着记忆动起来——八神的鬼步、不知火舞的扇子、一套连招打完手心出汗。你心想，就玩一把。

然后你打开搜索引擎，下载了一个叫不出名字的模拟器压缩包，解压之后是二十几个看不懂的文件夹。你照着教程把 BIOS 放进某个目录，双击启动，黑屏。换个版本，能进去了，但手柄没反应。再装一个映射工具，键盘和手柄开始抢键位，1P 一动 2P 跟着动。

折腾两小时，游戏没进去，耐心先没了。

我受够了这件事，于是自己写了一个——打开网页就能玩的街机厅。

它叫 Allen 街机大厅。不用装任何东西，不用找驱动，不用学配置。打开网址，登录，选游戏，开始。键盘、手柄、摇杆都能用，按键全自己说了算，还能开房间拉朋友联机。

这篇文章，我把它是怎么做出来的、解决了哪些具体问题、以及一件我必须说清楚的事，原原本本讲一遍。

一句话：一个跑在浏览器里的街机厅，带后台、带会员、能建房联机。

· · ·

一、它到底是个什么

站点设置——站点名、副标题、公告、维护模式、模拟器内核路径、联机信令地址，全在界面上改。还有配置的导入导出，换机器直接搬 JSON。

· · ·

四、联机：换了个思路，反而做成了

浏览器里做联机，最容易想到的是"两边各跑一个模拟器，帧同步"。

说实话，这条路我放弃了。真正的帧同步（rollback netplay）需要为每个模拟器内核单独实现确定性回滚，浏览器端不具备这个条件，硬做的代价是：为每一个机种单独适配，且大概率不稳定。

我换了个更符合真实场景的思路：房主权威。

房主的浏览器跑模拟器，其他人的按键通过 WebRTC 数据通道实时传给房主并注入进去，延迟通常不到 50ms；剩下的人看房主的画面直播。

这个形态意外地贴合街机厅的真实玩法——车轮战。房主可以一键"把操作权交给 TA"，输了换人，旁边人看直播等着上。小时候街机厅就是这个样子：一个人打，一圈人围观，输了把摇杆让给下一位。

技术上信令通道给了三种：不配置就走浏览器本地通道（同机器多标签页可直接演示）、填一个 ws:// 地址就走自带的零依赖信令服务器（跨设备跨网络）、或者接云服务走数据库轮询。

· · ·

五、有件事我必须说清楚QS

这个程序不内置、也不分发任何商业游戏的 ROM 和 BIOS。

一个 ROM 文件，是别人花了几年做出来的作品。把它打包进程序里分发Q，就是侵权。哪怕有人说"我有授权"，我也没法替他核实、更没法代为分发。

所以程序里一个游戏都没有。取而代之的是一条"导入即玩"的链路：你自己合法取得的文件（比如自己买过、备份下来的卡带和基板转储，或者作者明确允许自由分发的自制游戏）拖进后台，自动识别机种、匹配内核、生成卡片。文件只存在你自己浏览器的本地存储里，不上传服务器，也不随程序分发。

这件事让产品"开箱即用"打了折扣，我知道。但有些方便是不能用别人的劳动换的。

也正因为此，它天然适合一类用法：企业内网、展会体验区、线下街机吧、或者你自己那台放着一堆老卡带的机器——文件来源清晰，用起来才踏实。

· · ·

六、做下来最有价值的一个判断

整个项目做完，回头看，最有价值的不是某个功能，而是一个取舍：

能配置化的，绝不写死。

套餐、额度、权益、站点名、内核路径、信令地址……凡是运营过程中一定会变的东西，全部放进后台，界面上改。代码里只留默认值。

代价是前期多写了不少"配置读写"的活儿。收益是：运营同学想调个价格，三十秒搞定，不用等我。

技术人的价值，不是把需求实现一次，而是让需求下次变更的时候不需要再找你。

· · ·

七、它还差什么

我不想把它吹成成品，说几个真实的边界：

支付目前是模拟的。正式运营必须换成你自己的商户后端，在服务端校验支付成功之后再发权益，前端只负责下单展示——这一步偷懒，等于白送会员。
账号、订单、房间现在存在浏览器本地，清缓存就没了。要正式跑，得接云端真实账号体系。
存档读档依赖模拟器内核是否暴露接口，不支持的时候会提示用内核自带的菜单。
跨域加载的模拟器内核读不到画布，截图和画面推流会退化；自托管内核能解决。
后台的权限校验目前只在前端，接了服务端之后要在数据库层面再做一层。

把半成品说成成品，是技术人最容易犯、也最不该犯的错。

· · ·

最后

我做这个的初衷很小：就是想再打一把《合金弹头》，不想再装两个小时东西。

做着做着发现，真正难的不是让游戏跑起来——那部分模拟器内核早就解决了。难的是让一个普通人从"想玩"到"玩上"之间，不要有任何一道需要查教程的坎。

好的工具不是功能多，是让人忘记它的存在。

你小时候在游戏厅最常玩的是哪一台？评论区说说，我看看要不要给它单独做个键位预设。

99元！闲鱼大量流出6年前政F采购平板，1080P屏、4G运存，部分还能插卡带GPS

Mon, 02 Nov 2026 20:18:52 +0800

不知道有没有在关注iOS移植的情况，我看到有消息说，目前已经有项目已经攻克GPU渲染的问题，这么看来某某某真的要崛起了。

感觉好久没买垃圾平板来玩了，今天搜了下，闲鱼上又有新玩具了。

它是一家深圳的科技公司生产的，型号为---希科普 SP1099X，多由地政F教育机构采购，也常见于中国移动等定制机，由于批次不同，配置也有点差异。

目前闲鱼上流出来的这批机器，配置算是不错的，10.1英寸IPS大屏幕，主打护眼，分辨率为1920x1200（少数为1280x800），处理器为联发科MT6762，4GB RAM+32GB（少数64GB）组合，安卓版本基本为Android 9，部分批次支持全网通，电池容量一般为7000mAh，所有版本支持内存卡拓展。

对了，它是Type-C口充电的，支持最大18W快充。

这款平板最早似乎是淮南那边的政F采购的学生终端，采购于2020年时间，目前为止，时间也就6年，还挺热乎的，好处就是电池挺不错，有卖家描述，在最高亮度的情况下，视频可以播放6小时左右。

分析下性能，这种低端平板，肯定安装TV版的软件（就是家里电视上装的App，对性能要求低），4GB运行内存肯定够用，1080P的屏幕显示也够用，就是这个联发科的处理器有点弱。

MT6762，就是我们常说联发科P22，八核心设计，工艺是12nm，用的是A53的架构，有点弱，GPU是IMG PowerVR GE8320，支持1080P H.264（HEVC）硬解，属于看个视频够用的档次。

我看到有一个卖家描述，为了拍照，膜都是刚刚撕掉，整体嘎嘎新

不知道这么平板能不能用Diplay，能用上的话，身价又得涨一些。

这平板卖的比我想象中快太多了，隔一个晚上，有一个商家居然卖完下架了。

目前这个平板在小黄鱼上的售价普遍在百元出点头，我之前说的卖完的商家卖98元，还剩一个卖99元的，剩下的个人卖家普遍价格在130元左右，有个卖家有电池测试的，不想碰运气的可以多花前买个省心。

还挺想弄一个来玩玩串流的。

用了这么多 Windows 集成环境，最后还是选了 FlyEnv

Tue, 27 Oct 2026 15:14:29 +0800

作为一个老程序员，以前用 Mac 的时候还好，各种开发环境基本都可以通过 Brew 管理。

换了 Windows 之后，搞环境真的是太痛苦了，所以集成环境也就成了不二之选！

这些年，我用过不少集成环境，像 phpStudy、FlyEnv、ServBay、Laragon，基本都折腾过。

先说说 phpStudy。

这应该算是比较古老的集成环境了，也是我用得最多的一个，真的是让我又爱又恨。

版本残缺、扩展支持少、操作复杂、配置难管理，界面还丑。

好在它支持不少古老版本，而且相关资源也确实好找。尤其是维护一些老项目的时候，还真离不开它。

至于 Laragon，这一言难尽的玩意儿，我就不说它了……

ServBay 其实也确实不错。界面相当漂亮时尚，功能也贼全，还支持多平台。但就是占用内存太高了，那家伙一启动，机器磁磁响，受不了一点。

当然，也可以通过修改配置，减少一些服务的启动，达到优化内存的效果。

但问题是，我都用集成环境了，不就是图个方便吗？还让我配这配那，我还用啥集成环境呢？

最后说说 FlyEnv，目前我觉得最合适的一个。

首先是界面。清新、简洁，完全长在了我的审美上。毕竟我连车都喜欢毛坯 Y的人，对这种简洁的设计确实没什么抵抗力。

其次是功能，也足够全面。Web 服务器除了常见的 Nginx、Apache，还支持 Caddy。

数据库就不用多说了，缓存、队列啥的都有，甚至连对象存储也支持。容器、AI 啥的，现在这些集成环境基本也都开始支持了。

语言环境同样比较全面，像 PHP、Python、Bun、Node.js、Go、Java、Flutter，以及 Swoole 等常用开发环境和扩展，基本都能覆盖。其他乱七八糟的开发工具也有不少。

不过，这些其实还不是最吸引我的。最关键的是，它支持添加自定义版本。

比如 PHP 5.2，FlyEnv 本身没有提供，但 phpStudy 有啊！我可以直接把对应的版本导入进来使用。

还有数据库也是一样。之前使用 phpStudy 搭建的数据库环境，重新迁移、配置比较麻烦，我干脆直接添加进来继续用。

这个功能就很舒服了。

尤其是我们这种经常需要维护老项目的程序员，不用为了某个特殊版本，再去装一套集成环境。

另外，它还可以直接在操作列添加环境变量。这个功能我也特别喜欢。

Windows 添加环境变量麻烦得要死，不像 Mac，本来就比较简单，还可以直接通过 ln 或 alias 来处理一些命令路径问题。而在 FlyEnv 里，基本点几下就能搞定，不用再去系统设置里翻来翻去。

对于 PHP 开发者来说，还有一个非常实用的地方。可以直接在操作列编辑 php.ini，添加扩展、禁用扩展，操作起来也贼方便。

不用到处找配置文件，也不用记各种目录路径。说到底，我选择集成环境，就是为了少折腾环境，把时间花在真正的开发上。

至于性能、资源占用、功能完整度，每个人的需求不同，实际体验肯定也不一样。但就我目前的使用体验来说，FlyEnv 确实是最符合我习惯的一个。

所以后面如果不换回 Mac，我大概就只推荐 FlyEnv 了。

Grafana Alerting 实战：主机异常自动通知到企微群

Fri, 23 Oct 2026 16:34:57 +0800

导读：前几篇我们把 Zabbix 的主机和 MySQL 指标搬进了 Grafana 大屏。但大屏再漂亮，也得有人"盯着"才算数——值班同学不可能 7×24 盯着墙。这篇补上闭环的关键一块：Grafana Alerting 告警链路。CPU 飙了、磁盘满了、MySQL 延迟超阈值，Grafana 自动把告警卡片推到企微群，30 秒内 @ 到人。全程 5 步配置，附每一步的高清截图。

为什么不用 Zabbix 自带告警？

Zabbix 的 Trigger + 动作体系很成熟，但当你已经把展示层统一到 Grafana之后，告警也放进 Grafana 有三个实打实的好处：

对比项	Zabbix Trigger	Grafana Alerting
与大盘的关系	两套体系，图表在 Grafana、告警在 Zabbix	同一个系统里，点告警直接跳大屏
告警条件表达力	函数语法门槛高	Reduce + Threshold 拼积木式配置
路由灵活度	动作条件里写逻辑	按 Label 树状路由，改群不改规则
消息内容定制	宏组合，调试繁琐	模板变量直取查询结果值

当然，Zabbix 侧的告警可以继续保留作为"老保底"，两者并存互不影响。

先看全链路：一条告警是怎么流到企微群的

Zabbix 指标（API）
↓ Grafana 定时查询（每 30s 评估）
↓ Alert Rule：last() of CPU load IS ABOVE 阈值
↓ 打上 Label（severity=critical）
↓ Notification Policy 按 Label 匹配路由
↓ Contact Point：Webhook → 企微群机器人
↓ ✔ 运维告警群收到告警卡片

记住这条链路的四个关卡：规则（何时响）→ 标签（我是谁）→ 策略（发给谁）→ 渠道（怎么发）。下面逐步打通。

第一步：创建告警规则（Alert rules）

进入 Alerting → Alert rules → + New alert rule。核心是把"CPU 负载过高"翻译成三段式条件：

查询 A
：Zabbix 数据源，Group: Linux servers → Host: $host → Item: CPU load (1m)；
表达式 B
：Reduce → last()，取最近一个采样点；
表达式 C
：Threshold → IS ABOVE 阈值。超过即 Firing。

▲ 告警规则编辑：查询 A + Reduce（last）+ Threshold 三段拼装，Firing 状态一目了然

三处细节决定告警好不好用：

评估间隔
：Rule group 里设 30s，越短发现越快，但别低于采集周期；
Labels
：打上 severity=critical、team=sre——这是后面路由的"钥匙"；
Annotations
：用 {{$host}} 1分钟负载={{$values.B}} 把具体数值写进消息，收到告警不用再翻系统。

踩坑提醒：新装的 Grafana 如果 Alerting 菜单里没有 unified alerting 相关页面，检查 ngalert 是否启用（Grafana 9+ 默认开启，7.0 升级上来的老实例需要手动开）。另外规则保存后默认暂停评估的实例极少见，但首次建议点 Preview 看一眼条件预览再保存。

第二步：配置企微群通知渠道（Contact points）

先在企微群里建机器人：群设置 → 群机器人 → 添加机器人，复制拿到的 Webhook 地址（形如 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx）。

然后进入 Alerting → Contact points → + Add contact point：

Integration
：选 Webhook；
URL
：填中继服务地址（直连企微群机器人的方案见下方提醒）；
HTTP Method
：POST，Content type 选 application/json；
保存后点 Test，群里出现一条测试消息即为打通。

▲ Contact points：企微运维告警群设为 Default 兜底渠道，Body 由中继转成企微 markdown 卡片

关键认知（少走 2 小时弯路）：企微群机器人只认它自己的报文格式（msgtype: markdown），而 Grafana 的通用 Webhook 发的是自己的 payload，直连会 400。三个解法：
① 写一个 10 行的轻量中继（Nginx + Lua / 一个 Flask 脚本），把 Grafana payload 转成企微格式——常用；
② 用 Grafana OnCall，自带企微集成，还能做认领、升级；
③ 保留 Zabbix 侧企微告警媒介，Grafana 只做大屏——不推荐，链路分裂。

第三步：通知策略（Notification policies）— 谁的告警进谁的群

这是 Alerting 里非常关键的一层。进入 Alerting → Notification policies，树状结构一目了然：

Default policy
：兜底渠道设为「企微运维告警群」，没匹配到规则的告警都发这里；
子策略 1
：Matcher severity = critical → 企微运维告警群，并设置 Group by: host（同一主机的多条告警合并，5 分钟内不重复轰炸）；
子策略 2
：Matcher team = dba → 企微 DBA 群；
子策略 3
：Matcher severity = warning → 监控静默群（只在工作时间 @）。

▲ Notification policies 树：Label 是钥匙，换群、加群只动策略，一条规则都不用改

这样"值班"语义就出来了：critical 进值班群实时 @，warning 进静默群白天看，DBA 的数据库告警单独走自己的群，运维群里不再被 MySQL 告警刷屏。

实战效果：告警长什么样

压测把 web-prod-01 的 CPU 拉高，30 秒内告警进入 Firing。回到 Alerting → Alert list，触发中、待定、已恢复的状态和趋势尽收眼底：

▲ Alert list：3 条 critical 触发中，恢复时长（MTTR）也有了量化数据

与此同时，企微群里收到两张 markdown 卡片——标题红色、主机、级别、当前值、持续时长、直达 Grafana 的链接一应俱全：

▲ 运维告警群实况：Grafana 机器人推送的告警卡片，点链接直接跳到对应大屏

指标回落并持续一段时间后，同一条消息会自动补充"Resolved 已恢复"，告警有始有终，值班同学不用手工关单。

进阶技巧：让告警更"懂事"

Pending 缓冲，拒绝抖动
：Condition 里的 for 2m（Alert Evaluation Behavior → Set alert state if error / pending）让条件持续 2 分钟才 Firing，瞬时毛刺不再半夜叫人；
按主机合并轰炸
：子策略里 Group by host，同一主机批量告警合并成一条 markdown，加上 Mute timings 设定免打扰时段；
消息里带数值
：Annotations 用 {{$values.B}}（人类可读）与 {{$value}}（原始值），配合 {{$labels.host}}，卡片信息量拉满；
Keep Last State
：数据源短暂断连时（评估失败）保持最后状态不发"Unknown 风暴"，避免半夜被假告警吵醒；
Silence 静默窗口
：变更窗口前在 Alerting → Silences 里按 host=xxx 静默 2 小时，发版不告警；
告警即代码
：规则支持导出 YAML（Alert rules → Export），放进 Git 走 CI 同步，多套环境一键复制。

常见问题（FAQ）

现象	排查方向
规则显示 Firing，企微群没消息	① Contact point 是否被策略引用（用了自定义策略但 Default 没兜住）；② 中继服务日志有没有收到请求；③ 机器人 Webhook key 是否过期/被限流（每机器人 20 条/分钟）
Test 能发，真实告警不发	Test 不走 Notification policies，只测渠道本身；检查策略 Matcher 与规则 Label 是否拼写一致（区分大小写）
告警风暴，群被刷屏	开启 Group by host + group interval（默认 5m）；检查是否有规则缺 `for` 持续条件
消息显示 No data / Unknown	查询返回空：确认 $host 变量取值、Zabbix 数据源账号 API 权限、Item 处于 Supported 状态
恢复通知不出现	Contact point / 策略里开启了 "Only send notifications when alert fires" 类选项的关掉；或策略层 resolve 被覆盖

写在最后

到这里，Zabbix × Grafana 系列的监控闭环就完整了：采集（Zabbix）→ 展示（Grafana 大屏）→ 告警（Alerting）→ 送达（企微群）。监控的价值不在图好看，而在"出事有人知道、多快知道、知道得够不够多"。一条带数值、带链接、自动恢复的企微卡片，往往比任何大屏都更能体现监控体系的成熟度。

Zabbix 7自动发现与 LLD 批量纳管配置指导

Fri, 23 Oct 2026 16:25:11 +0800

本文是《Zabbix 7.0 安装部署实战系列》的进阶篇。前几篇我们把平台装好、中文化、做了运维告警大屏。这一篇来解决一个更"生产级"的问题：几百台服务器、上千个网口、几百块磁盘，难道要一台台点、一个个加监控项？

答案是：当然不。Zabbix 有两大批量利器——自动发现（Network Discovery） 和 LLD（Low-Level Discovery，低级发现）。一个管"批量把主机请进门"，一个管"进门后把每个房间自动看一遍"。说实话，能不能玩转这两样，是 Zabbix 从"玩具"变"生产平台"的分水岭。

先把两个概念掰清楚（很多人都现在都没搞懂）

这两个词经常被混为一谈，但它们解决的是两个完全不同层面的问题。

维度	自动发现 Network Discovery	LLD 低级发现 Low-Level Discovery
解决什么	主机从哪来（批量加主机）	监控项怎么批量建（批量加 Item/Trigger/Graph）
触发时机	Server 主动扫描网络	已纳管主机上定时执行 discovery key
典型场景	一个网段里 200 台 Linux 自动入网	一台机器上有 20 个挂载点、8 块网卡自动监控
配置位置	数据采集 → 自动发现	模板里的"发现规则"（Discovery）
输入	IP 段 + 检查项（Agent/ICMP/SNMP）	一个返回 JSON 的 discovery key

一句话总结：自动发现负责"把机器请进门"，LLD 负责"进门后自动把每个房间都看一遍"。 两者配合，才构成完整的"批量纳管"。

自动发现（Network Discovery）实战

2.1 原理


Zabbix Server 按计划扫描 IP 段
      │  对每个 IP 执行"检查项"（如连 10050 取 system.uname）
      ▼
命中检查 → 产生 Discovery Event
      │
      ▼
匹配"自动发现动作"（Action）的条件
      │
      ▼
执行操作：加主机 + 链接模板 + 加入主机组

换句话说，你只要告诉 Server"去扫哪段、用什么检查、命中后套什么模板"，剩下的全自动。

2.2 我这套平台里，其实已经自带了一套

翻了下我这台 7.0.31 的环境，默认就有现成的配置，正好：

① 发现规则 Local network（druleid=2）

字段	值
名称	Local network
IP 范围	`172.16.88.0/23`
更新间隔（delay）	`1h`
检查项类型	Zabbix 客户端（type=9）
键值	`system.uname`
端口	`10050`

② 动作 Auto discovery. Linux servers.（actionid=2，已启用）

条件：收到值(A)AND主机元数据含 "Linux"(B)AND检查类型=Zabbix agent(C)
操作：链接模板 10001（Linux by Zabbix agent）+ 加入主机组 2（Linux servers）

你看，官方默认动作已经把"加主机→套模板→分组"这条链路搭好了。你只需要在前端数据采集 → 自动发现里按自己的网段改一下 IP 范围，就能直接用。

2.3 自己从零配一条

如果你要新建，字段如下（事件源必须选"自动发现"）：

发现规则：名称自定义；IP 范围填你的网段（如 10.0.0.0/24）；检查项加一条"Zabbix 客户端"，键值 system.uname，端口 10050。
动作（事件源=自动发现）：
• 条件建议加严：除了"收到值"，再加一条 主机元数据包含 Linux，避免把打印机、路由器也收进来。
• 操作加三项：添加主机（operationtype=2）→ 链接模板（如 Linux by Zabbix agent）→ 加入主机组。

⚠️ 我的经验：IP 范围别一上来就写 /16、delay 别设成 1m。Server 会真的去扫每一个 IP，范围太大或太频繁会把自己 CPU 打爆。先用一个 /24 试点，观察 zabbix_server 负载再扩。

LLD（低级发现）实战

3.1 原理

LLD 的核心是：一个 discovery key 返回一个 JSON 数组，Zabbix 用数组里的宏（如 {#FSNAME}）去实例化一批"原型"。


discovery key 返回：
[{"{#FSNAME}":"/","{#FSTYPE}":"ext4"},
 {"{#FSNAME}":"/home","{#FSTYPE}":"ext4"}]

        │  提取宏 {#FSNAME}
        ▼
自动生成（每个挂载点一份）：
  监控项原型  →  Free disk space on {#FSNAME}
  触发器原型  →  {#FSNAME} is full (>80%)
  图形原型    →  Disk usage {#FSNAME}

这就是为什么你套上 Linux by Zabbix agent 模板后，不用配任何磁盘监控项，所有挂载点的空间告警就自动来了。

3.2 内置 LLD（真实清单，来自模板 10001）

我直接查了 Linux by Zabbix agent 模板里的发现项，至少有这三个开箱即用的：

discovery key	名称	用途
`vfs.fs.dependent.discovery`	Mounted filesystem discovery	自动发现所有挂载点
`net.if.discovery`	Network interface discovery	自动发现所有网卡
`vfs.dev.discovery`	Block devices discovery	自动发现所有块设备

也就是说，一台新机器只要被自动发现纳管并套了这个模板，它的网卡、磁盘、块设备监控会瞬间自动铺满。这就是"批量纳管"的威力。

3.3 自定义 LLD（进阶，业务系统常用）

内置的不够用时，自己写一个 discovery 脚本即可。比如自动发现 Nginx 的虚拟主机：


#!/bin/bash
# /etc/zabbix/scripts/nginx_vhosts.sh  —— 返回 JSON 数组
vhosts=$(nginx -T 2>/dev/null | grep -oP 'server_name\s+\K[^\s;]+' | sort -u)
echo'{"data":['
first=1
for v in$vhosts; do
  [ $first -eq 0 ] && echo','
printf'{"{#VHOST}":"%s"}'"$v"
  first=0
done
echo']}'

然后在 Agent 配置里暴露它：


# /etc/zabbix/zabbix_agent2.conf 或 zabbix_agentd.conf
UserParameter=nginx.vhost.discovery,/etc/zabbix/scripts/nginx_vhosts.sh

前端在模板里建一条发现规则，类型选"Zabbix 客户端"，键值 nginx.vhost.discovery，再建监控项原型用 {#VHOST} 宏，完事。

⚠️ 两个常见坑：① JSON 数组里每一项至少要含一个宏，且宏名必须和原型里 {#XXX} 完全一致、大小写敏感；② 返回的必须是合法 JSON，别带多余 echo 日志，否则 Zabbix 解析失败整个 LLD 罢工。

3.4 用过滤器收敛噪声

docker 环境下一台机器可能扫出几十个 docker0、vethxxx 网卡，全监控纯属浪费。用 LLD 的 过滤器（Filter） 按宏排除即可，例如正则 ^docker|^veth|^lo$ 直接忽略。

两者怎么配合：完整的"批量纳管"闭环

这是最关键的一张图，也是整套机制的价值所在：


新 Linux 机器上电
      │
      ▼
① 自动发现扫描命中 → Action 把它加为"主机"并套 Linux by Zabbix agent 模板
      │
      ▼
② 模板里的 LLD 立即工作：自动发现这台机器的所有网卡 / 挂载点 / 块设备
      │
      ▼
③ 监控项原型 + 触发器原型被实例化 → 磁盘满了会告警、网卡掉了会告警
      │
      ▼
零手工，一台生产机的完整监控就绪 ✅

你看，"加主机"和"加监控项"这两件最累的活，被一条自动发现规则 + 一个带 LLD 的模板一次性包圆了。200 台机器？把 IP 范围写对，喝杯咖啡回来就齐了。

避坑指南

扫描范围过大 / 间隔过短 → Server 性能雪崩。/24 起步，delay 别低于 30m（首次发现可临时调快，平时调回）。
动作条件太宽 → 把同事电脑、打印机、路由器全纳管了。务必加 主机元数据包含 Linux 或限定检查类型。
LLD 宏名大小写不一致 → {#Fsname} 和 {#FSNAME} 不是一回事，原型不生效还不报错，排查半天。
自定义脚本带多余输出 → LLD 只认纯 JSON，脚本里 echo "debug..." 会直接让 discovery 失效。
噪声太多 → docker / 虚拟网卡 / loopback 用过滤器排除，否则监控项爆炸、采集变慢。
自动发现加的主机默认只采集 Agent 数据 → 想要端口、Web、证书等深度监控，还是得靠模板里的 LLD + 普通监控项组合，或像前面 OA/官网那样单独配。

Zabbix 8.0 前瞻：7→8 跨越与部署实战

Fri, 23 Oct 2026 16:22:29 +0800

说实话，用什么版本真的那么重要吗？不一定

用的好用的稳定才是第一位，但是确实可以聊一下，因为做技术的还是很好奇。现在8.0 LTS官宣计划 2026 年 11 月发布。所以我们先把 7 和 8 的核心区别一次性讲清楚。

先说结论：Zabbix 8 不是 7 的小修小补，而是从"指标监控系统"向"全栈可观测平台"的跨越。最关键的三个词——OpenTelemetry、复杂事件处理（CEP）、官方移动 App。懂行的已经知道分量了。

Zabbix 7.0 LTS 是 2024 年 6 月发布的长期支持版，主打异步 poller、Proxy 高可用、浏览器合成监控、原生 SLA 等，把传统基础设施监控做到了成熟稳定。而 8.0 的目标，按官方路线图的说法，是"把 Zabbix 进化为现代化的开放可观测平台"。

本文内容基于 Zabbix 官方 8.0 what's new 文档与产品路线图（功能均标注 Ready），8.0 正式发布后，个别包名/参数请以官方文档为准（文末已标注）。如果你的生产还在 7.0，别慌——7.0 LTS 仍有数年支持周期，看完这篇你再决定什么时候升。

技术详解

Zabbix 7 vs 8：核心区别全景

维度	Zabbix 7.0 LTS	Zabbix 8.0 LTS
监控范式	以指标为主（CPU/内存/磁盘/SNMP/JMX）	全栈可观测：指标 + 日志 + 链路（APM）
OpenTelemetry	OTel 指标经 agent/collector 采集，无原生链路	原生支持 OTel Traces 与 Logs，专属 APM 视图
事件管理	触发器关联 + 基础去重	复杂事件处理（CEP）：滑动时间窗、去重、自动关闭、JS 富化、SIEM 级关联
移动端	无官方 App	官方 iOS/Android App，推送通知 + 问题管理
AI 能力	无	官方 MCP Server，AI Agent 可用自然语言管监控
数据结构	结构化数据支持有限	原生 JSON 数据类型 + Shared Data
前端体验	改进但偏复杂	深蓝主题、内联校验、仪表盘导入导出、散点图
后端/性能	MySQL/PostgreSQL	新增 ClickHouse 历史后端；百万级每秒采集

下面挑重点逐条讲，不然光看表没感觉。

1. 从"看指标"到"看全栈"：OpenTelemetry 原生化

7.0 时代，Zabbix 主要是拉指标的——Agent、SNMP、JMX、Prometheus 这些。微服务、容器、Serverless 这类动态环境，要么靠额外的 Jaeger 看链路、靠 Elastic Stack 看日志，Zabbix 管不全。

8.0 直接把 OpenTelemetry 收编进来了：Proxy 新增 APM 监听（OTLP/gRPC），能接收应用或 OTel Collector 发来的遥测数据；前端新增 APM 菜单和链路追踪可视化视图；后台还能接 ClickHouse 作为遥测/历史数据存储。一句话，Previously 你要三件套，现在一个 Zabbix 顶上。

2. 复杂事件处理（CEP）：告别告警风暴

这是我个人最看重的升级。7.0 的告警强，但大规模环境里"同一个故障刷出几十条"的告警疲劳很难根治。8.0 引入 CEP 引擎，基于"滑动时间窗"做规则化事件处理：

把同一根因的相关事件归组，标记首因为"因"、其余为"果"（症状）；
设定事件存活期（TTL），过期自动关闭；
限制某类事件数量，或对"某时段内发生太多次/一次都没发生"做通知；
事件进入/离开时间窗时可做富化：升降级严重度、加标签、抑制，甚至用自定义 JavaScript 处理；
官方明确说这能支撑欺诈检测、安全监控（SIEM）、事件关联等场景。

说白了，8.0 的事件引擎已经摸到商业 AIOps 的门槛了。

3. 官方移动 App：NOC 装进口袋

7.0 被吐槽最多的就是"没有官方手机端"。8.0 补上了：iOS/Android 原生 App，支持推送通知、查看问题详情、更新问题状态。配套新增了一个 Bridge adapter 组件负责 Server 和 App 通信（配置项 BridgeAdapterURL、EnableMobileDevices），以及名为 Push notification 的媒介类型。以后半夜告警，手机上就能 ack，不用爬起来开电脑。

4. MCP Server：用大白话问监控

8.0 新增官方 MCP Server，通过 Model Context Protocol 把 AI Agent 接到 Zabbix。你可以用自然语言问："数据库服务器上还有哪些未确认的问题？""为什么 web-01 今早一直报问题？""今晚 22:00 到 02:00 把 Linux servers 组置为维护"。Agent 用 Zabbix API Token 鉴权，权限与审计都跟着 Token 所有者走。这是把 AI 真正接进运维闭环的一步。

5. JSON 数据类型与 Shared Data

以前 JSON 只能当文本采集，限 64KB，还不能校验。8.0 支持原生 JSON 值类型，上限 128MiB，还会拒绝非法 JSON。配合 Shared Data（多个监控项共享一次采集结果，比如一次性拿到 API token 给几百个项用），在容器化、动态环境里能省大量重复采集。

6. 前端与性能安全的一堆"体感"升级

新增深蓝主题，可在用户配置里设默认；
内联表单校验、仪表盘跨系统导入导出、新增散点图部件、图表 Y 轴可反转、问题列表等表格视图可自定义列；
性能上"百万级数据点每秒"、SNMP 采集更快、Server 启动更快、PostgreSQL 支持多主机故障转移、SNMPv3 EngineID 缓存复用；
安全上：代理/代理组可按用户组授权、SAML 证书可 UI 直接上传、支持 HashiCorp Vault AppRole、审计日志可导出 CSV、Agent 新增 AllowKeyRegexp/DenyKeyRegexp 正则管控。

Zabbix 8.0 安装部署实战（Ubuntu 22.04）

下面这套以 Ubuntu 22.04 LTS 为环境、后端 MySQL 8.0、前端 Nginx + PHP-FPM，整体链路和 7.0 一致，我把 8.0 的新组件单独拎出来讲。

环境准备与数据库


sudo apt update && sudo apt upgrade -y
sudo apt install -y mysql-server
sudo systemctl enable --now mysql
sudo mysql_secure_installation


CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'Zabbix@Strong2026';
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';
SET GLOBAL log_bin_trust_function_creators = 1;  -- 导入函数需要，导入后关回 0
FLUSH PRIVILEGES;

添加 8.0 仓库并安装组件


# 包名/修订号以 8.0 正式发布时官方下载页为准（有待验证）
wget https://repo.zabbix.com/zabbix/8.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_8.0-1+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_8.0-1+ubuntu22.04_all.deb
sudo apt update
sudo apt install -y zabbix-server-mysql zabbix-frontend-php zabbix-nginx-conf zabbix-sql-scripts zabbix-agent2

导入数据库（和 7.0 一样，单文件合并版）：


zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix


SET GLOBAL log_bin_trust_function_creators = 0;  -- 用完关回

配置 Server 与前端

/etc/zabbix/zabbix_server.conf 填库密码：DBPassword=Zabbix@Strong2026；PHP 时区在 /etc/zabbix/php-fpm.conf 把 Europe/Riga 改成 Asia/Shanghai。官方 Nginx 默认仍监听 8080，访问地址 http://IP:8080/zabbix。


sudo systemctl enable --now zabbix-server zabbix-agent2 nginx php8.1-fpm

Web 向导与首台主机：浏览器打开 http://IP:8080/zabbix 走 4 步向导；默认 Admin/zabbix，登录先改密码、顺手在 User settings 里把语言切中文。被监控机装 zabbix-agent2、改 Server/ServerActive/Hostname 三项，systemctl 拉起后，在 Web 配置 → 主机 → 创建主机链接 Linux by Zabbix agent 2 模板即可。

8.0 三个新组件（按需启用，非必须）

ClickHouse 遥测后端：超大规模/海量链路日志场景才需要，普通部署用 MySQL/PostgreSQL 即可；启用需在 Administration > Data source 配 ClickHouse，详见官方 ClickHouse 配置文档。
移动 App Bridge：要上手机端，就配 BridgeAdapterURL、EnableMobileDevices=1，并在前端配 Push notification 媒介。
MCP Server：想接 AI，安装官方 zabbix-mcp 包、用 API Token 启动，具体参数以 8.0 正式文档为准（有待验证）。

我个人认为，Zabbix 8 的战略意义在于把"监控"升级为"可观测 + 智能运维中枢"。对已经在用 7.0 的团队，CEP 和移动 App 是立刻能降本增效的两块；对还在 6.0/老版本的朋友，8.0 是一个"一步到位"的升级目标——反正都要升，不如直接规划到 8.0 LTS。

代价也得说清楚：8.0 能力更强，但 ClickHouse、MCP、CEP 这些新模块都意味着更高的学习与运维复杂度，小环境未必用得上全部。

我的经验是先把核心监控跑稳，新特性按需点亮，别一上来全开。

建议

新装直接等 8.0 LTS，存量别急着动：生产在 7.0 的，等 8.0 GA 后灰度验证再升；全新环境建议直接上 8.0 LTS，省一轮升级。
发布前核对官方包名：8.0 正式发布时，zabbix-release 的修订号、PHP 最低版本（前端要求以官方为准，有待验证）可能微调，照官方文档执行最稳妥。
数据库独立 + 定期备份：无论 7 还是 8，mysqldump 备份 zabbix 库 + /etc/zabbix/ 目录是保命操作；上 ClickHouse 后备份策略要重新设计。
优先 agent2 + 主动模式：跨网段/云安全组用 ServerActive，agent 只出方向连 10051，减少入站暴露。
CEP 规则从小处试起：先拿一两类高频告警做去重/自动关闭，跑顺了再铺开，避免规则写错把真告警吞了。

到这儿，Zabbix 7 与 8 的区别、以及 8.0 的部署路径你应该心里有数了。8.0 把监控的边界从"指标"推到了"指标+日志+链路+AI"，是个值得等的版本。等 11 月正式发布，我可以再出一篇"7.0 平滑升级 8.0"的实战，把升级里的坑提前给你排了。

本文信息截至 2026-10-17，功能以 Zabbix 官方 8.0 LTS 文档为准；个别未 GA 的包名/参数已标注"有待验证"。

Zabbix7告警之钉钉企微告警配置指导

Fri, 23 Oct 2026 16:20:06 +0800

我们前几篇把吐槽最多的坑补齐了，并且机器也纳管进来了，大屏也投上了。但是，有个重点的事情每有做-有效的监控没有做。

我的邮箱里至今躺着几千封告警邮件，删都没删过，但也没怎么看过。真正让监控产生价值的那一刻，是告警日志发送到运维同事的手机上、并且他愿意点开。

所以这篇讲的是：怎么把 Zabbix 的告警精准送到钉钉群和企业微信群里。我会给你可复制的 Webhook 脚本、逐项的参数表、路由矩阵，以及一张我整理的排错清单。

Zabbix 到 IM 群，一共三跳

整条链路就这五步，每一步都可能断：

触发器亮红灯 → 2. 动作（Action）匹配成功 → 3. 媒介类型（Media type）被调用 → 4. HTTP 请求打到机器人 → 5. 群里出现消息

我见过最多的问题是：第 2 步没配、第 4 步签名错、第 5 步把自己限流了。下面逐个拆。

先说清楚一条红线，钉钉和企微都一样：每个机器人每分钟最多 20 条消息。钉钉超了限流 10 分钟，企微直接给你 45009 api freq out of limit。注意，限流恰恰发生在故障最密集、你最需要它的那一刻——这条决定了下面所有的设计思路。

方案选型：三条路，我推荐第二条

方案	做法	优点	缺点
邮件转发	发到 QQ/163 再走邮件提醒	零配置	送达慢、易被当作垃圾邮件、基本没人看
Webhook 媒介类型（推荐）	Zabbix 7.0 原生 JS 脚本，界面里填	不用往服务器放文件、界面可维护、自带测试按钮	JS 环境是 Duktape，有些库没有
自定义告警脚本	Python 脚本放 `AlertScriptsPath`	完全可控，能做代理、重试、落盘日志、消息合并	要管文件权限、属主、SELinux

我个人推荐 Webhook 媒介类型：媒介类型在数据库里跟着备份走，不用 ssh 上去找脚本文件；需要复杂逻辑（比如代理、重试、聚合）再走 Python 脚本方案，文章后面也给了。

（我现在用的很多企业为微信的消息推送，也是webhook，这个是最简单的方式，只需要提供接口和需要传输的信息就好了，个人认为很方便。）

第一站：把机器人建出来

钉钉：群 > 群设置 > 智能群助手 > 添加机器人 > 自定义

上图是钉钉的webhook设置页面

创建完给两样东西，都存好：

Webhook 地址：形如 https://oapi.dingtalk.com/robot/send?access_token=xxxxx
加签密钥：SEC 开头的一串（只显示一次，关了就再也看不到）

安全设置有三种，选型建议一并给你：

方式	说明	我的评价
自定义关键词	消息里必须含某个词	不推荐，知道了 URL 就能伪造
加签	HMAC-SHA256 签名	推荐，不依赖固定 IP
IP 白名单	只允许指定出口 IP	出口 IP 固定的话可以叠加用

企业微信：群 > 右上角「三个点」> 消息推送 > 添加

官方现在叫「消息推送」（早些年的名字是"群机器人"），拿到形如 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxx 的地址。

企微这边有几个硬约束要提前知道：外部群不支持添加，必须是纯企业微信群；Markdown 不支持表格和图片；没有加签机制，所以 Webhook 地址本身就是凭证，别截图发群里、别提交到代码仓库。

Zabbix 侧的 Webhook 媒介类型

路径：告警 → 媒介 → 创建媒介类型（部分版本在「管理 → 报警媒介类型」）。

类型选 Webhook，参数按下表填（顺序无所谓，名字要对得上）：

钉钉脚本（带加签，可直接复制）


try {
    Zabbix.Log(4, '[DingTalk] webhook value: ' + value);

    var params = JSON.parse(value),
        req = new HttpRequest(),
        resp;

    // 1) 加签：把 timestamp + "\n" + secret 做 HMAC-SHA256
    var timestamp = Date.now().toString();
    var stringToSign = timestamp + '\n' + params.secret;

    // 坑点：Zabbix 的 hmac() 返回的是十六进制字符串，钉钉要的是 Base64
    var hexDigest = hmac('sha256', params.secret, stringToSign);
    var bin = '';
    for (var i = 0; i < hexDigest.length; i += 2) {
        bin += String.fromCharCode(parseInt(hexDigest.substr(i, 2), 16));
    }
    var sign = encodeURIComponent(btoa(bin));

    // 2) 拼接签名后的 URL
    var url = params.webhook_url + '&timestamp=' + timestamp + '&sign=' + sign;

    // 3) 组装 markdown 消息
    var data = {
        msgtype: 'markdown',
        markdown: { title: params.subject, text: params.message },
        at: { atMobiles: [], isAtAll: false }
    };
    if (params.at_mobiles) {
        var mobiles = params.at_mobiles.split(','),
            atText = '';
        for (var j = 0; j < mobiles.length; j++) {
            atText = atText + ' @' + mobiles[j];
        }
        data.at.atMobiles = mobiles;
        data.markdown.text = params.message + '\n\n' + atText;
    }

    req.addHeader('Content-Type: application/json');
    resp = req.post(url, JSON.stringify(data));

    Zabbix.Log(4, '[DingTalk] HTTP ' + req.getStatus() + ' resp: ' + resp);

    if (req.getStatus() < 200 || req.getStatus() > 299) {
        throw 'HTTP status ' + req.getStatus();
    }
    // HTTP 200 也可能是业务失败，必须看 errcode
    var ret = JSON.parse(resp);
    if (ret.errcode !== 0) {
        throw 'DingTalk errcode ' + ret.errcode + ': ' + ret.errmsg;
    }
    return JSON.stringify({ tags: { result: 'ok' } });
} catch (error) {
    Zabbix.Log(4, '[DingTalk] send failed: ' + error);
    throw 'DingTalk send failed: ' + error;
}

这里有两个坑我一并说了：一是 hmac() 返回十六进制而钉钉要 Base64，必须转换，不然永远返回 310000；二是时间戳要求毫秒级，而且服务器时间漂太多签名会失效，务必给 Zabbix 服务器配上 NTP。

企业微信脚本（无需加签）


try {
    Zabbix.Log(4, '[WeCom] webhook value: ' + value);

    var params = JSON.parse(value),
        req = new HttpRequest(),
        data = {
            msgtype: 'markdown',
            markdown: { content: '### ' + params.subject + '\n' + params.message }
        };

    // 需要 @ 人时填手机号（多个用英文逗号分隔）
    if (params.at_mobiles) {
        data.markdown.mentioned_mobile_list = params.at_mobiles.split(',');
    }
    req.addHeader('Content-Type: application/json');
    var resp = req.post(params.webhook_url, JSON.stringify(data));

    Zabbix.Log(4, '[WeCom] HTTP ' + req.getStatus() + ' resp: ' + resp);

    var ret = JSON.parse(resp);
    if (ret.errcode !== 0) {
        throw 'WeCom errcode ' + ret.errcode + ': ' + ret.errmsg;
    }
    return JSON.stringify({ tags: { result: 'ok' } });
} catch (error) {
    Zabbix.Log(4, '[WeCom] send failed: ' + error);
    throw 'WeCom send failed: ' + error;
}

注：企微 @ 人的字段名（mentioned_mobile_list / mentioned_list）以官方文档为准，如有变化请自行调整。

配完别急着闭环，媒介类型列表那一行右侧有个「测试」按钮，点它会让你填参数，能当场看到返回值——这是排查问题最快的方式。

消息模板别再写ABC

切到媒介类型的「消息模板」标签页，分别给 Problem（故障）、Problem recovery（恢复）、Problem update（更新）配内容。

故障标题：


故障 ｛TRIGGER.SEVERITY｝：｛HOST.NAME｝ ｛TRIGGER.NAME｝

故障正文（Markdown）：


**【告警】｛EVENT.SEVERITY｝**
> 主机：｛HOST.NAME｝
> 时间：｛EVENT.DATE｝ ｛EVENT.TIME｝
> 详情：｛TRIGGER.NAME｝
> 当前值：｛ITEM.LASTVALUE｝
> 事件ID：｛EVENT.ID｝
> 处理：到 监测-问题 里按事件ID检索

（文中为了避开渲染，宏用了全角花括号，实际请换成英文半角的 { }）

恢复正文照猫画虎，但一定要带上 持续时长 宏，方便事后复盘 MTTR。

Actions 才是"精准"的关键

前面全是"怎么发"，这一段才是"发给谁"。

路径：告警 → 动作 → 触发器动作 → 创建动作。

参考这张路由矩阵去配多条动作：

具体怎么落地，我给你一套规则：

条件（Conditions）怎么组合

场景	条件写法
只要核心业务	`主机组等于 Linux-Payment`
只要中等级以上	`触发器严重性大于等于 Average`
按业务线路由	`标签名等于 scope` + `标签值等于支付`
排除演练机	`主机名称包含 test` 取反

前提是你在主机上打好了标签（主机 → 标签），比如 scope: 支付、owner: 张三。标签是这套精准路由的地基，前面几篇纳管主机时顺手打上最省事。

操作（Operations）三个都不能漏

Operations：发给对应媒介/用户组。同时打开阶梯升级，比如「步骤 1-2 每 10 分钟发一次给值班群；步骤 3-5 发给组长并 @ 手机号」——Zabbix 会在没被确认的情况下自动升级。
Recovery operations：这条 90% 的人忘配，结果就是只报不复，群里永远看不到"好了"。
Update operations：有人认领（Acknowledge）时同步到群里，避免两个人同时去处理同一台机器。

抑制与降噪的三个开关

动作里把 Maintenance status: Pause operations during maintenance 勾上，计划维护期别刷屏；
只把 Average 及以上送 IM，Warning 以下攒成日报；
用依赖关系（Host/Trigger dependencies）把"交换机挂了导致下面 50 台主机全红"收敛成一条。

这几件事做完，你把 20 条/分钟的红线从"天天踩"变成"基本不碰"。

排错清单：出问题先查这张表


现象	大概率原因	怎么验
返回 `310000`	加签算错：时间戳非毫秒、密钥错、没做 Base64 或 URL 编码	看服务端日志 `grep DingTalk /var/log/zabbix/zabbix_server.log`
企微返回 `45009`	超过 20 条/分钟	降噪或拆机器人分流
HTTP 200 但群里没消息	漏判了响应体里的 `errcode`（如关键词不匹配 `310000` 之外的错误）	看返回体 JSON
脚本方案完全没反应	脚本不在 `AlertScriptsPath` 或没执行权限	`grep AlertScriptsPath /etc/zabbix/zabbix_server.conf` ；`chmod +x`
权限报错	脚本属主不是 zabbix 用户	`chown zabbix:zabbix`
中文乱码	脚本未声明 UTF-8	Python 首行加 `# -- coding: utf-8 --`
签名时好时坏	服务器时间漂移	`timedatectl status` ，确认 chrony/NTP 在跑
恢复消息收不到	没配 Recovery operations	回到动作里补

告警链路的工程难度不高，但它是整个监控体系唯一真正被人感知的部分。前面做纳管、做大屏、做高可用 Proxy，最后一段没打通，前面所有的努力都是摩尔定律级别的浪费。

我的经验是：宁可少发、不要多发。一条精准的 @ 你的 High 级告警，比五十条没人看的 Warning 有价值得多。

本文配置基于 Zabbix 7.0 LTS，界面文案与宏名称请以你实际版本的官方文档为准；第三方机器人接口的限流与安全策略可能调整，使用前建议再核一次官方公告。

Zabbix 7添加Windows主机：Agent2安装步骤

Fri, 23 Oct 2026 15:54:16 +0800

聊完业务探活和网络设备，回到最常见的场景：Windows 服务器怎么纳管。国内不少业务系统还跑在 Windows 上——AD 域控、IIS 站点、SQL Server、各种行业软件，这些机器不上监控，出了事就只能靠人喊。

这篇以 Zabbix 7为例，从下载安装包到出图告警，把 Windows 主机纳管走一遍。全程大概十分钟一台。

Agent 还是 Agent 2？先把这个搞清

Zabbix 有两个采集端：老的是 C 写的 Zabbix agent，新的是 Go 写的 Zabbix agent 2。7.0 上我强烈建议直接上 agent 2：内置指标更全（Windows 服务、性能计数器、内置的插件体系），并发采集能力也更好，官方模板都是按它优化的。

还有个概念得先厘清：被动模式 vs 主动模式。

被动：Zabbix Server 主动连被监控主机的 10050 端口取数据，要求 Server 能访问主机；
主动：主机自己把数据推到 Server 的 10051 端口，方向反过来了。

主机少用被动无所谓，主机上百台就一定要用主动——否则 Server 的采集进程会先扛不住，而且跨网段、跨防火墙时，只开一个出站端口比开一堆入站端口省事得多。

一步步来：安装 → 配置 → 纳管 → 验证

第 1 步：下载安装

去官方下载页拿 Windows 安装包（选 agent 2、对应架构；文件名会带版本号，如 7.0.31 版本对应同版本号安装包，以官网下载页实际提供的资产为准，有待验证），然后静默安装：


msiexec /i "zabbix_agent2-7.0.31-windows-amd64-openssl.msi" /qn ^
  HOSTNAME=WIN-SRV-01 ^
  SERVER=10.0.0.10 ^
  SERVERACTIVE=10.0.0.10 ^
  LISTENPORT=10050

几个参数解释一下：HOSTNAME 必须和你在 Zabbix 里建的主机名完全一致；SERVER 是被动模式允许谁来取数；SERVERACTIVE 填上才算启用主动模式。/qn 是静默安装，批量部署时可以直接塞进组策略或 Ansible。

第 2 步：配置文件与防火墙

装完配置文件在 C:\Program Files\Zabbix Agent 2\zabbix_agent2.conf，核心三行确认一遍：


Server=10.0.0.10
ServerActive=10.0.0.10
Hostname=WIN-SRV-01

防火墙这块：被动模式要放行入站 TCP 10050；主动模式只需主机能出站访问 Server 的 10051。很多"装完了没数据"都是栽在防火墙这一步。

第 3 步：在 Zabbix 里建主机

数据采集 → 主机 → 创建主机，主机名填 WIN-SRV-01（与上面一致），接口写 agent 类型 + 10050；然后链接模板。被动模式选 Windows by Zabbix agent，主动模式选带 active 的那个版本——模板和模式必须匹配，混用会一路红灯，这是新手最常踩的坑。

第 4 步：当场验证

别等界面刷新，直接在机器上验一把：


"C:\Program Files\Zabbix Agent 2\zabbix_agent2.exe" -t system.uptime

能返回开机时长，说明 agent 本身没问题。如果 Server 侧能连通，也可以从服务端执行 zabbix_get -s 10.0.0.20 -k agent.ping，返回 1 就是通的。界面侧看"最新数据"里有没有指标进来，绿灯亮起就算成功。

影响与意义

Windows 主机纳管带来的最直接变化是：IIS 应用池崩了、服务的状态变了、磁盘满了，都能在告警里看到，而不是等业务方打电话。

我个人的体会是，Windows 上真正值钱的监控项不是 CPU 内存——那玩意常年不动——而是服务状态、应用池回收、磁盘空间和事件日志。尤其事件日志，配好了能提前发现一堆"还没爆但快了"的问题。

挑战主要在运维层面：Windows 主机往往在域里，批量部署要走域策略；生产环境不敢随便重启，安装窗口要排期；再加上性能计数器名字长、容易填错。

三条建议

统一规划主机命名，比如"业务-角色-序号"，并让 Zabbix 主机名与 agent 的 HOSTNAME 严格一致，能省掉大量"主机找不到"的排查；
超过 20 台就上主动模式，只开 10051 出站，网络安全和性能双赢；
优先把服务状态和磁盘告警配起来，比盯 CPU 有用得多。

Windows 这一篇就到这吧，你们生产上 Windows 主机还有多少台？

Zabbix 7添加网络设备：SNMP监控上手

Fri, 23 Oct 2026 15:53:35 +0800

对于交换机、路由器、防火墙，这类设备有个硬性特点——你装不了 agent，厂商封闭系统，不可能让你塞个采集程序进去。所以网络设备的监控，基本只有一条路：SNMP。

这也是很多人的卡点：agent 装惯了，一到网络设备就不知道从哪下手。这篇以 Zabbix 7.0.31 为例，从设备侧准备到出图，把 SNMP 这条路走通。

SNMP 是个什么东西

简单说，SNMP 是一套"设备自报家底"的标准协议：设备内部维护一棵编号树（OID），你按编号去问，它就回答。比如 1.3.6.1.2.1.1.1 是设备描述，1.3.6.1.2.1.2 是接口信息。Zabbix 内置了大量 SNMP 模板，你连模板、填 community，接口流量、CPU、内存、温度就全出来了。

版本上要拎清：v1/v2c 用明文的 community 串当"密码"，抓包就能看见，安全上基本等于裸奔；v3 支持用户认证（auth）+ 加密（priv）。我的经验是：内网老设备用 v2c 可以理解，但凡能上 v3 就上 v3，尤其是跨网段和互联网专线场景——这已经不是技术问题，是合规问题。

对谁有用：管机房、管分支网络的运维；要给"网络出口有没有丢包堵死"提供依据的团队。

实操：设备准备 → 添加主机 → 批量纳管

第 1 步：设备侧准备（最容易漏）

开 SNMP：snmp-server community <只读串> RO（华为/思科大体类似，语法以厂商为准）；
限制来源：ACL 只允许 Zabbix 服务器 IP 访问 UDP 161——别对全网开放；
上 v3 的话：建只读用户，安全级别选 authPriv，认证 SHA、加密 AES；
打通链路：中间有防火墙的，放行 UDP 161。

在 Zabbix 服务器上先手动验证一把，能出结果再进界面：


# SNMPv2c
snmpwalk -v2c -c 你的只读串 10.0.0.1 1.3.6.1.2.1.1.1

# SNMPv3（authPriv）
snmpwalk -v3 -l authPriv -u zbxuser -a SHA -A '认证密码' -x AES -X '加密密码' 10.0.0.1 1.3.6.1.2.1.1.1

能吐出设备描述，说明设备没问题，接下来全是 Zabbix 里的事。

第 2 步：在 Zabbix 添加主机

数据采集 → 主机 → 创建主机，注意两个地方别填错：

接口类型选 SNMP，端口 161，版本选 v2c 或 v3；v3 要在"SNMP 版本"旁边填安全名、认证协议/密码、加密协议/密码；
宏：v2c 场景下，把社区串填到主机的宏 {$SNMP_COMMUNITY} 里（模板里的监控项都引用这个宏），而不是硬编码；

然后去模板页签链接模板。通用设备可以从 Template Module Generic SNMP 起步，接口流量用 Template Module Interfaces SNMPv2；主流品牌有现成的网络设备模板（如 Cisco、华为等的 SNMP 模板），模板名称以你版本内置列表为准（有待验证）。

第 3 步：两个必调的参数

开启批量请求（Use bulk requests）：接口页签里勾上，SNMP 一次拿一批 OID。设备多、接口多的时候吞吐差别很大，这个不勾采集会很慢；
降低采集频率：交换机的接口流量不用 10 秒一次，60 秒足够。有些交换机 CPU 弱，SNMP 问太勤会把管理面 CPU 顶满——我踩过这个坑，表现为"监控一开设备就卡"。

第 4 步：几十台设备怎么办（自动发现）

手点几十台交换机不现实。用自动发现：数据采集 → 自动发现 → 创建发现规则，IP 范围填网段，检查项选 SNMP（对 1.3.6.1.2.1.1.2 做探测）；再到动作里配置"发现后自动添加主机、关联模板、加入主机组"。跑一晚，整个网段的设备就自己进来了。

把网络设备纳管进来，监控才真正形成闭环：业务不通时，能一眼分清是服务器的事还是网络的事。我个人的经验是，网络设备监控最值钱的不是流量图，而是接口 up/down 和光衰告警——一次核心链路抖动提前发现，省下的就是一次故障时长。

挑战也很实际：设备型号杂、模板适配有工作量大；SNMP 采集对老旧设备有性能开销；再加上 v2c 的安全债。所以这事得循序渐进：先纳管核心交换机和出口设备，再铺接入层。

可执行建议

先用 snmpwalk 验证连通再进界面，能省掉 80% 的"为什么没数据"排查时间；
能上 SNMPv3 就上，v2c 至少配合 ACL 限制来源；
大批量设备一定走自动发现 + 动作，别手工点，后期维护成本差十倍。

到这里，Zabbix 的"网络侧"就打通了。

Zabbix 7实战：用Web场景监控业务系统

Fri, 23 Oct 2026 15:52:27 +0800

前几篇我们一直在折腾"机器"：装 Zabbix、纳管 Linux、搭大屏。但说实话，CPU 曲线一条平的、内存也正常，业务却打不开——这种事我遇到过不止一次。因为机器活着，不等于业务能用。

通过使用Zabbix 7的Web 场景（Web scenario），从用户视角把业务系统端到端探活。装完你就能回答一个更值钱的问题：不是"服务器活着吗"，而是"用户能打开吗"。

Web 场景到底是什么

Zabbix 的 Web 监控不是简单 ping 一下端口。它内部用 libcurl 按顺序请求一串 URL，能带 Cookie、能跟随跳转、能校验返回内容和状态码——等于替你模拟一遍真实用户的访问链路：打开首页、登录、进入订单页。

为什么必须补这一层？因为服务器侧监控有几个盲区它天生看不见：HTTP 200 但页面里写着"系统异常"、登录接口返回 500、SSL 证书过期、跳转链断开、CDN 回源失败。这些在 agent 视角里全都"正常"。

对谁有用：门户网站、OA、ERP、自研 SaaS 的运维和开发；要做可用率报表、SLA 考核的团队。

一步步配：场景 + 步骤 + 触发器

第 1 步：创建场景

数据采集 → 主机 → 新建主机

选中你的主机（建议专门建一台"业务系统"主机，而不是挂在 Web 服务器上）→ Web → 右上角"创建 Web 场景"。关键几项：

名称：如"官网首页可用性"；
更新间隔：生产建议 1m，别 10s 一次，容易给自己招来风控；
尝试次数：3 次。单次失败就告警会产生大量误报，多试两次能过滤网络抖动；
Agent：选一个 User-Agent，有些站点会拦截默认 UA。

第 2 步：添加步骤（Steps）

一个场景由多个步骤组成，按顺序执行，前一步的 Cookie 自动带入下一步——这就是它能测"登录后页面"的原理。每步要填：

URL：完整地址；
要求状态码：默认 200，接口类可填 200,201；
要求字符串：这是精髓，填页面上必然出现的关键字，比如"欢迎回来"。只要关键字不在返回内容里就算失败，专治"200 但内容报错"；
超时 / 跟随重定向：登录类场景通常要保持 Cookie 和跟随跳转。

因为我现在不需要登录，只需要监测页面能不能打开，所以比较简单：

填写状态码：

此时就添加好了：

第 3 步：让它会告警

场景建好后，Zabbix 会自动生成监控项，不需要你手写：web.test.fail[场景]（失败步骤数）、web.test.time[场景,步骤]（每步耗时）、web.test.rspcode[场景,步骤]（响应码）、web.test.error[场景]（错误信息）。

系统不会自动给你建触发器，这一步得自己补。创建一个触发器，表达式写成"失败步骤数大于 0 就报警"：


{HOST:web.test.fail[官网首页可用性].last()}<>0

再基于 web.test.time 加一条"页面响应超过 3 秒"的告警，业务的"慢"和"挂"就都覆盖了。

我个人认为，Web 场景是 Zabbix 里性价比最高的一块功能。它不依赖业务方改造，不用装任何东西，几行配置就把监控从"基础设施视角"拉到了"用户体验视角"，还能直接喂给大屏和 SLA 报表。

当然它也有边界，得说清楚：它测的是探针到目标的链路，测不了浏览器里的 JS 渲染和前端报错——那属于浏览器合成监控的活。另外探针部署在哪很关键，你从机房探外网门户，测出来的不是用户体验。

到这里，"机器能用"和"业务能用"就都盯上了。