前几篇我们一直在折腾"机器"：装 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 渲染和前端报错——那属于浏览器合成监控的活。另外探针部署在哪很关键，你从机房探外网门户，测出来的不是用户体验。
到这里，"机器能用"和"业务能用"就都盯上了。
支付宝微信扫一扫，打赏作者吧～本文链接：https://www.kinber.cn/post/6818.html 转载需授权！
推荐本站淘宝优惠价购买喜欢的宝贝:
您阅读本篇文章共花了： 
