Zabbix 监控 Lighttpd 实战：App Lighttpd by Zabbix Agent 模板（ModStatus 数据源）深度解析-平芜编程栈

【免费下载链接】community-templates

Zabbix Community Templates repository

项目地址：https://gitcode.com/gh_mirrors/co/community-templates

本指南以 Zabbix Community Templates 仓库中的 App Lighttpd by Zabbix Agent 模板为核心，系统讲解如何借助 Lighttpdmod_status模块的 JSON 状态页，用 Zabbix Agent 实现对 Lighttpd 进程、请求量、流量、内存与可用性的完整监控。读完本文，你将掌握该模板的 5 个宏变量、16 个采集项的采集链路与预处理逻辑、5 个触发器的告警语义，并能独立完成 Lighttpd 侧配置、模板导入、主机关联与参数调优。

模板速览：轻量而完整的 Lighttpd 监控方案

该模板由 Dave Humphrey（dave@uesp.net）编写，定位是 "a very simple Zabbix Agent template for monitoring Lighttpd using the ModStatus module"——即一个专门基于 Lighttpdmod_status模块的、面向 Zabbix Agent 的轻量监控模板。

在仓库中，该模板以三个版本目录形式存在，定义内容完全一致、仅导出格式不同：

版本目录	导出格式	对应 Zabbix 版本
5.0	XML	Zabbix 5.0
5.4	YAML	Zabbix 5.4
6.0	YAML	Zabbix 6.0

模板归属于Templates/Applications模板组，模板内部名称为App Lighttpd by Zabbix Agent。它没有使用模板链接（Template links），也没有发现规则（Discovery rules），属于纯静态定义的监控模板。

工作原理：一条主采集链驱动全部统计项

整个模板的数据采集围绕一个"主采集项 + 依赖项"的星型结构展开，这是理解该模板的关键。

主采集项Lighttpd: Get status使用 Zabbix Agent 内置键web.page.get拉取 Lighttpd 状态页：

web.page.get["{$LIGHTTPD.STATUS.HOST}","{$LIGHTTPD.STATUS.PATH}","{$LIGHTTPD.STATUS.PORT}"]

默认情况下，它请求http://127.0.0.1:80/server-status?json，即 Lighttpdmod_status提供的机器可读 JSON 格式状态页（模板在采集项描述中明确引用了 Lighttpd 官方 ModStatus 文档）。由于返回的是整个 HTML 页面，模板为它配置了 REGEX 预处理步骤，用正则\n\s?\n((?:.|[[:space:]])*)将匹配结果替换为\1，即丢弃状态页中 JSON 之前的 HTML 部分、只保留 JSON 主体，供后续解析。

其余 9 个统计项全部是 Dependent item（依赖项），以web.page.get为主采集项（master_item），更新间隔为0（即跟随主采集项每次更新而更新），并通过 JSONPath 预处理从 JSON 状态页中提取对应字段。整条数据链路为：

Lighttpd mod_status (?json) │ web.page.get（1m 轮询，REGEX 提取 JSON） ▼ 主采集项：Get status（原始 JSON 文本） │ JSONPath 提取各字段 ▼ 9 个依赖项：请求数、流量、uptime、busy/idle 线程等

这一设计把"网络请求"只做一次，其余指标全部本地解析，既减少了状态页的访问频率，也让各指标的计算逻辑清晰可控。

模板宏变量：五个可调参数

模板共定义了 5 个宏（在 YAML 定义中均有对应描述），类型均为 Text macro：

宏名称	描述	默认值
`{$LIGHTTPD.PROCESS_NAME}`	Lighttpd 服务进程名	`lighttpd`
`{$LIGHTTPD.RESPONSE_TIME.MAX.WARN}`	触发器中允许的最大响应时间（秒）	`10`
`{$LIGHTTPD.STATUS.HOST}`	Lighttpd 状态页的主机名或 IP	`127.0.0.1`
`{$LIGHTTPD.STATUS.PATH}`	Lighttpd 状态页的 URL 路径	`server-status?json`
`{$LIGHTTPD.STATUS.PORT}`	Lighttpd 状态页的端口	`80`

各宏的实际作用：

{$LIGHTTPD.PROCESS_NAME}决定进程相关监控键（proc.num、proc.cpu.util、proc.mem）匹配哪个进程，默认lighttpd。若你的 Lighttpd 以自定义名称运行，需同步修改。
{$LIGHTTPD.STATUS.HOST}/{$LIGHTTPD.STATUS.PORT}/{$LIGHTTPD.STATUS.PATH}共同决定状态页拉取地址。默认绑定127.0.0.1:80，这要求 Lighttpd 状态页仅对本地开放（推荐的安全姿势）；若状态页部署在非标准端口或需要远程访问，应覆盖这三个宏。
{$LIGHTTPD.RESPONSE_TIME.MAX.WARN}直接参与响应时间触发器的阈值比较（见下文触发器章节），默认 10 秒。

采集项全景：16 个监控指标

模板共定义了 16 个采集项，其中 7 个由 Zabbix Agent 直接采集（进程与端口层面），9 个为依赖状态页 JSON 的统计项。

面向 Zabbix Agent 的直采项（7 个）

这些项更新间隔均为 1 分钟，不依赖 Lighttpd 状态页，负责监控进程与服务的"存活"与"资源"：

采集项名称	键	说明
Lighttpd: Get status	`web.page.get["{$LIGHTTPD.STATUS.HOST}","{$LIGHTTPD.STATUS.PATH}","{$LIGHTTPD.STATUS.PORT}"]`	拉取状态页 JSON 文本，`TEXT`类型，历史保留 1h、不存趋势（trends: 0），是所有统计项的数据源
Lighttpd: Service ping	`net.tcp.service[http,"{$LIGHTTPD.STATUS.HOST}","{$LIGHTTPD.STATUS.PORT}"]`	TCP/HTTP 服务连通性探测，返回 0/1；配置了`DISCARD_UNCHANGED_HEARTBEAT`10m 预处理，即数值连续 10 分钟无变化时丢弃，配合心跳检测判断数据新鲜度
Lighttpd: Service response time	`net.tcp.service.perf[http,"{$LIGHTTPD.STATUS.HOST}","{$LIGHTTPD.STATUS.PORT}"]`	HTTP 连接与响应耗时，`FLOAT`类型，单位为秒
Lighttpd: Number of processes running	`proc.num["{$LIGHTTPD.PROCESS_NAME}"]`	匹配进程名的存活进程数
Lighttpd: CPU utilization	`proc.cpu.util["{$LIGHTTPD.PROCESS_NAME}"]`	进程 CPU 利用率百分比，`FLOAT`类型，单位为`%`（未显式指定 mode 参数，按 Zabbix 默认取 1 分钟平均值）
Lighttpd: Memory usage (rss)	`proc.mem["{$LIGHTTPD.PROCESS_NAME}",,,,rss]`	进程常驻内存（RSS），单位字节
Lighttpd: Memory usage (vsize)	`proc.mem["{$LIGHTTPD.PROCESS_NAME}",,,,vsize]`	进程虚拟内存（VSZ），单位字节

proc.mem键的第 5 个参数（rss/vsize）指定内存类型，模板同时采集两者，并在图形中叠加展示。

依赖主采集项的统计项（9 个）

以下依赖项均以web.page.get[...]为主采集项，更新间隔为0（随主项刷新），通过 JSONPath 从状态页 JSON 中提取对应字段：

采集项名称	键	JSONPath 取值	预处理与单位
Lighttpd: Total Requests	`lighttpd.requests.total`	`$["RequestsTotal"]`	自服务启动以来的累计请求数
Lighttpd: Requets per second	`lighttpd.requests.rate`	`$["RequestsTotal"]`	先 JSONPath 取值，再叠加`CHANGE_PER_SECOND`求每秒变化率（注意模板原 README 中此名称拼写为 "Requets"，为原文档写法）
Lighttpd: Request Rate 5 sec	`lighttpd.requests.average5s`	`$["RequestAverage5s"]`	状态页记录的最近 5 秒平均请求速率，单位`req/sec`
Lighttpd: Total bytes	`lighttpd.bytes`	`$["TrafficTotal"]`	自重启以来累计传输字节数，`FLOAT`，单位`B`
Lighttpd: Bytes per second	`lighttpd.bytes.rate`	`$["TrafficTotal"]`	JSONPath +`CHANGE_PER_SECOND`，每秒字节变化率，单位`Bps`
Lighttpd: Traffic Average 5 sec	`lighttpd.traffic.average5s`	`$["TrafficAverage5s"]`	JSONPath 后叠加`MULTIPLIER`1024 将 KiB/s 折算为`B/sec`，单位`B/sec`
Lighttpd: Uptime	`lighttpd.uptime`	`$["Uptime"]`	服务运行时长（秒），单位为`uptime`，由 Zabbix 自动格式化为可读时长
Lighttpd: Busy servers	`lighttpd.servers.busy`	`$["BusyServers"]`	当前正在处理请求的 Lighttpd 线程数
Lighttpd: Idle servers	`lighttpd.servers.idle`	`$["IdleServers"]`	空闲等待请求的 Lighttpd 线程数

BusyServers与IdleServers合起来可以直观反映线程池饱和度：当 Busy 长期接近线程上限而 Idle 趋近于 0 时，通常意味着并发处理能力即将耗尽。而CHANGE_PER_SECOND、MULTIPLIER等预处理步骤在 YAML 定义中均有明确体现。

触发器与告警依赖：源码中隐藏的告警体系

值得特别指出：模板 README 的 "Triggers" 一节写着 "There are no triggers in this template"，但实际导出的模板 YAML 中定义了5 个触发器——README 未同步更新。以模板定义文件为准，完整告警体系如下：

触发器名称	表达式	优先级	说明
Lighttpd: Process is not running	`last(/App Lighttpd by Zabbix Agent/proc.num["{$LIGHTTPD.PROCESS_NAME}"])=0`	HIGH	进程数为 0，进程级最高优先告警
Lighttpd: Service is down	`last(/App Lighttpd by Zabbix Agent/net.tcp.service[http,"{$LIGHTTPD.STATUS.HOST}","{$LIGHTTPD.STATUS.PORT}"])=0`	AVERAGE	服务探测失败；依赖 "Process is not running"（进程先挂则不重复告警）
Lighttpd: Service response time is too high	`min(/App Lighttpd by Zabbix Agent/net.tcp.service.perf[http,"{$LIGHTTPD.STATUS.HOST}","{$LIGHTTPD.STATUS.PORT}"],5m)>{$LIGHTTPD.RESPONSE_TIME.MAX.WARN}`	WARNING	5 分钟内最小响应时间超过`{$LIGHTTPD.RESPONSE_TIME.MAX.WARN}`秒；依赖进程与服务告警
Lighttpd: has been restarted	`last(/App Lighttpd by Zabbix Agent/lighttpd.uptime)<10m`	INFO	uptime 小于 10 分钟，提示服务刚重启过
Lighttpd: Failed to fetch status page	`nodata(/App Lighttpd by Zabbix Agent/web.page.get["{$LIGHTTPD.STATUS.HOST}","{$LIGHTTPD.STATUS.PATH}","{$LIGHTTPD.STATUS.PORT}"],30m)=1`	WARNING	状态页连续 30 分钟无数据；依赖进程与服务告警

这套触发器通过依赖关系（dependencies）做了合理的告警降噪：Service is down、Service response time is too high、Failed to fetch status page三个触发器都依赖Process is not running，前两者还互相依赖。当 Lighttpd 进程退出时，只触发 HIGH 的进程告警，其余均被抑制，避免告警风暴。所有触发器均设置了manual_close: YES（需人工确认关闭）。

预置图形：开箱即用的可视化

模板自带 2 个图形，导入后即可直接用于监控面板：

Lighttpd: Memory usage：叠加展示 vsize（绿色1A7C11）与 rss（蓝色2774A4）两条内存曲线；
Lighttpd: Requests per second：展示lighttpd.requests.rate请求速率曲线。

（图形定义见 YAML 定义的graphs段。）

Lighttpd 侧配置要点

模板的数据来源是mod_status模块的 JSON 状态页，因此被监控的 Lighttpd 必须启用该模块并开放状态页访问。结合模板默认值，配置时需要满足：

加载mod_status模块（模板描述中即指明依赖 ModStatus module）；
状态页路径可访问且支持?json机器可读输出，模板默认请求路径为server-status?json，与宏{$LIGHTTPD.STATUS.PATH}对应；
访问端口与模板默认的{$LIGHTTPD.STATUS.PORT}=80一致（或通过宏覆盖）；
建议仅允许监控来源访问状态页（默认127.0.0.1即为本地回环，安全且典型）。

具体模块加载与访问控制语法以 Lighttpd 官方 ModStatus 文档为准，模板层面只需保证"状态页可被web.page.get拉取并返回 JSON"这一前提成立。

部署与使用步骤

导入模板：在 Zabbix 前端"配置 → 模板 → 导入"中，按你的 Zabbix 版本选择对应文件导入：
- Zabbix 5.0 导入 template_lighttpd.xml；
- Zabbix 5.4 导入 template_lighttpd.yaml；
- Zabbix 6.0 导入 template_lighttpd.yaml。
确认 Lighttpd 状态页可用：在被监控主机上执行curl "http://127.0.0.1:80/server-status?json"，确认返回 JSON（含RequestsTotal、TrafficTotal、BusyServers、Uptime等字段）。
关联模板：将模板App Lighttpd by Zabbix Agent链接到目标主机，主机需运行 Zabbix Agent（被动模式）且能访问web.page.get所需的状态页地址。
按需覆盖宏：若状态页不在本机 80 端口，在主机级宏中覆盖{$LIGHTTPD.STATUS.HOST}、{$LIGHTTPD.STATUS.PORT}、{$LIGHTTPD.STATUS.PATH}；进程名不同则覆盖{$LIGHTTPD.PROCESS_NAME}；响应时间阈值可调{$LIGHTTPD.RESPONSE_TIME.MAX.WARN}。
验证数据：在"监测 → 最新数据"中确认Get status及各依赖项有值，Service ping为 1，并检查Lighttpd: Memory usage、Lighttpd: Requests per second图形是否正常出图。

注意事项与已知细节

README 与模板定义不一致：README 声明"无触发器"，但实际 YAML 内含 5 个触发器；排查告警时应以 template_lighttpd.yaml 为准。
Update: 0的含义：依赖项的更新间隔为 0，表示它们不独立轮询，而是随主采集项web.page.get的每次更新同步刷新，因此实际数据频率即主项频率（默认 1 分钟）。
数值类型差异：请求数、uptime 等计数类项未显式声明value_type，按 Zabbix 默认的无符号数值处理；速率类项（请求速率、字节速率）显式声明为FLOAT，保证小数精度。
告警抑制：多个触发器互相依赖，进程挂掉时只报 HIGH 级进程告警，属预期行为，不必误认为其他告警丢失。
模板无发现规则：该模板不依赖 LLD 自动发现，所有监控项静态定义，结构简单、适合快速部署。

至此，你可以基于 README.md 与模板定义快速落地一套 Lighttpd 监控，并依据本文对数据链路、预处理和告警语义的理解进行二次调优。