Zabbix 监控 Junos Space 关键服务：template_junos_space 模板逐项解析与部署指南-开发者社区

【免费下载链接】community-templates

Zabbix Community Templates repository

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

导读

本文围绕 Zabbix 官方社区模板库中的Junos Space监控模板展开，完整解析其基于proc.num进程探测的 8 个关键服务监控项、告警触发器设计，以及从 Zabbix 5.0 XML 到 6.0 YAML 的版本演进细节。读者读完本文将掌握：如何理解该模板每条 item key 的进程匹配逻辑、如何将其导入并关联到 Junos Space 网络管理系统主机，以及如何在此基础上做告警阈值与监控范围的扩展。

模板概览：为 Junos Space NMS 打造的关键服务探针

Junos Space 是瞻博网络（Juniper Networks）推出的网络管理平台（NMS），承载网络设备的编排、配置与监控能力。该平台本身由一组常驻服务进程构成，任何关键进程异常退出，都可能直接影响网络管理业务的可用性。本模板正是针对这一场景，通过 Zabbix agent 对 Junos Space 服务器上的关键服务进程做"存在性"探测。

模板在仓库中的位置为 Applications/Monitoring_System/template_junos_space/，共维护了三个 Zabbix 版本：

版本目录	模板文件格式	说明
5.0/	`template_junos_space.xml`	Zabbix 5.0 导入格式
5.4/	`template_junos_space.yaml`	Zabbix 5.4 导入格式
6.0/	`template_junos_space.yaml`	Zabbix 6.0 导入格式

模板元信息在 6.0/template_junos_space.yaml 中定义：

模板名称：Junos Space
模板所属组：Templates NMS
模板描述：monitor critical services for Junos Space monitoring system（监控 Junos Space 监控系统的关键服务）
作者：Dmitry Lavrukhin（README 中署名）
数据采集方式：全部为Zabbix agent（被动检查）

同时，6.0/README.md 明确指出本模板不含宏（Macros）、不含模板链接（Template links）、不含自动发现规则（Discovery rules）。也就是说，这是一个"零配置、纯进程探测"的轻量模板——导入后直接绑定主机即可生效，非常适合作为快速接入监控的起点。

监控项设计：8 个关键服务的进程计数

模板的核心是一组进程计数监控项，全部基于 Zabbix 内置的proc.num键。在 6.0/template_junos_space.yaml 中共定义了 8 个 item，统一设置：

更新间隔（delay）：60秒
历史保留（history）：7d
标签（tags）：Application: NMS

汇总如下（与 README 中 Items collected 表格一致）：

监控项名称	Item Key	探测目标
service nma count	`proc.num[httpd,root,,nma]`	root 用户下、命令行匹配`nma`的 httpd 进程
service heartbeat count	`proc.num[heartbeat,root,,master]`	root 用户下、命令行匹配`master`的 heartbeat 进程
service httpd count	`proc.num[httpd,root,," "]`	root 用户下、命令行含空格的 httpd 进程（即带参数的 httpd）
service opennms count	`proc.num[java,opennms]`	opennms 用户运行的 java 进程
service postgreSQL count	`proc.num[postmaster,postgres,,pgsql]`	postgres 用户下、命令行匹配`pgsql`的 postmaster 进程
service jmp-watchdog count	`proc.num[perl,root,,jmp-watchdog]`	root 用户下、命令行匹配`jmp-watchdog`的 perl 进程
service jboss count	`proc.num[sh,jboss,,--host-config=host.xml.master]`	jboss 用户下、命令行含`--host-config=host.xml.master`的 sh 进程
service mysql count	`proc.num[mysqld,mysql]`	mysql 用户运行的 mysqld 进程

proc.num 的四个参数：理解每条 key 的匹配逻辑

要正确使用这个模板，必须理解 Zabbixproc.num键的参数语义。其完整语法为：

proc.num[process,user,type,cmdline]

各参数作用如下：

参数位	含义	本模板中的用法
`process`	进程名（必须与`/proc/<pid>/stat`中可执行文件名一致）	`httpd`、`heartbeat`、`java`、`postmaster`、`perl`、`sh`、`mysqld`
`user`	进程运行用户，用于区分不同身份启动的同名进程	`root`、`opennms`、`postgres`、`jboss`、`mysql`
`type`	进程类型过滤（all/regular/kernel 等），留空即默认匹配所有类型	本模板均留空
`cmdline`	命令行正则匹配，用于精确定位"同进程名中的特定实例"	`nma`、`master`、`" "`、`pgsql`、`jmp-watchdog`、`--host-config=host.xml.master`

从源码结构看，本模板充分利用了user + cmdline 双维度过滤来区分同一可执行文件下的不同业务实例，这是其设计上最值得借鉴的点：

httpd 家族：Junos Space 平台中既有通用 Web 服务（httpd），又有 NMA（Network Management Application）模块，二者同为httpd可执行文件，因此模板用cmdline参数区分——proc.num[httpd,root,,nma]只统计命令行含nma的实例，而proc.num[httpd,root,," "]通过匹配"命令行中含空格"来统计那些带参数启动、属于常规 Web 服务进程的实例；
heartbeat 主备进程：proc.num[heartbeat,root,,master]只统计命令行匹配master的 heartbeat 主进程，避免把备用实例误计入内；
JBoss 域控制器：proc.num[sh,jboss,,--host-config=host.xml.master]通过--host-config=host.xml.master精确锁定以 master 主机配置启动的 JBoss 实例；
数据库层：PostgreSQL 用postmaster进程名 +pgsql命令行过滤，MySQL 则直接匹配mysqld进程，二者分别以postgres、mysql系统用户运行。

触发器设计：进程计数归零即告警

模板为每个监控项配套了对应的进程存活触发器。在 6.0/template_junos_space.yaml 中可以看到，每个 item 都内嵌一个触发器，逻辑统一为"最近一次采集到的进程数为 0"：

last(/Junos Space/proc.num[<key>])=0

触发器名称	监控项	优先级
service jmp-heartbeat down	proc.num[heartbeat,root,,master]	HIGH
service httpd down	proc.num[httpd,root,," "]	HIGH
service nma down	proc.num[httpd,root,,nma]	HIGH
service opennms down	proc.num[java,opennms]	HIGH
service mysqld down	proc.num[mysqld,mysql]	HIGH
service jmp-watchdog down	proc.num[perl,root,,jmp-watchdog]	HIGH
service postgreSQL down	proc.num[postmaster,postgres,,pgsql]	HIGH
service jboss down	proc.num[sh,jboss,,--host-config=host.xml.master]	HIGH

所有触发器优先级均为HIGH（高），语义直接明了：任一关键服务进程数为 0，即判定该服务宕机并触发告警。这种"进程在 → 服务健康，进程消失 → 立即告警"的二元模型非常适合对 NMS 这种单体依赖重的系统做兜底监控。

值得注意的细节是触发器表达式的版本差异：

在 5.0/template_junos_space.xml 中，表达式写作简写形式{last()}=0，依赖 item 自身上下文解析；
在 5.4/template_junos_space.yaml 与 6.0 版本中，表达式已改写为显式引用形式last(/Junos Space/proc.num[...])=0，直接通过模板名 + key 定位监控项，可读性和跨版本兼容性更强。

从 5.0 到 6.0：模板格式与元数据的演进

对比三个版本，可以看到 Zabbix 官方模板在这两年间的标准化轨迹：

导出格式变化：5.0 为 XML（template_junos_space.xml），5.4 起转为 YAML（5.4 与 6.0），这是 Zabbix 5.4 引入 YAML 导入导出格式后的直接体现；
uuid 标识：5.4/6.0 YAML 中每个 template、item、trigger 都带uuid字段，用于跨版本、跨实例的模板同步与冲突检测（如模板 uuid 为b9c41e92ca944ab0a24c28ce7d37b9a7）；
应用（application）→ 标签（tags）：5.0 XML 使用<applications><application>NMS</application></applications>将监控项归入名为NMS的应用；5.4/6.0 则改用tags: Application: NMS键值对标签，这是 Zabbix 5.4 后推荐的分组方式；
导出日期一致：三个版本文件的导出时间均为2021-11-21T21:52（见 6.0 YAML 头部），说明三个目录是同一模板针对不同 Zabbix 主版本维护的平行副本，监控项与触发器内容完全一致。

部署实操：导入、关联与验证

第一步：导入模板

在 Zabbix 前端导航到数据采集 → 模板（Data collection → Templates），点击右上角Import，选择本仓库 6.0/template_junos_space.yaml（若服务器为 Zabbix 5.4，则选 5.4 版本；5.0 则选 XML）。导入后即可在模板列表中看到Junos Space，且自动归属于Templates NMS组。

第二步：关联主机

在 Junos Space 服务器上安装并启动 Zabbix agent（被动模式，默认监听 10050 端口）；
在 Zabbix 前端创建/打开对应主机，在模板（Templates）字段中链接Junos Space；
确认主机的 agent 接口（IP/DNS + 端口）配置正确。

第三步：验证数据采集

导入后可用 Zabbix agent 的命令行工具直接验证进程匹配结果是否与预期一致。例如在 Junos Space 服务器本地执行：

zabbix_get -s 127.0.0.1 -k "proc.num[postmaster,postgres,,pgsql]" zabbix_get -s 127.0.0.1 -k "proc.num[java,opennms]" zabbix_get -s 127.0.0.1 -k "proc.num[mysqld,mysql]"

返回值即当前对应服务进程数。若返回 0，说明该进程在目标主机上确实未运行，需要先排查服务本身；若返回大于 0，则模板数据链路正常。

扩展建议与使用注意点

基于该模板的进程探测模型，实际部署时建议关注以下几点：

agent 运行权限：proc.num匹配用户与命令行依赖 agent 对/proc的读取能力。进程名为 root 用户所有（如httpd、heartbeat、perl）时，agent 需要有足够权限读取对应进程信息，必要时需以 root 身份运行 agent 或用AllowRoot相关配置配合；
cmdline 匹配是精确语义：cmdline参数按正则匹配进程命令行。若 Junos Space 版本升级后进程启动参数发生变化（如 JBoss 的--host-config文件名变更、NMA 模块命令行调整），需要同步更新对应的 item key，否则会出现误报；
触发器阈值可根据拓扑调整：模板默认"计数为 0 才告警"，适用于单节点部署。若 Junos Space 采用 HA 双机或集群部署，heartbeat 等进程的期望值可能大于 1，可将触发器表达式调整为last(...)<1或结合主机宏设置期望进程数；
合理搭配平台层指标：本模板只覆盖进程存活这一维度，不含 CPU、内存、磁盘等系统资源指标。建议与仓库 Operating_Systems/Linux 下的系统监控模板组合使用，形成"平台 + 服务"的完整监控闭环；
告警收敛：8 个 HIGH 级触发器同时触发时可能产生告警风暴，可在 Zabbix 动作（Actions）层面对该模板的触发器做抑制（如 maintenance 窗口、依赖关系设置）或升级策略编排。

小结

template_junos_space是社区模板库中一个典型的"进程探测型"监控模板：无宏、无发现规则、无模板依赖，仅靠 8 条proc.num监控项与配套的归零触发器，就为 Junos Space NMS 平台提供了关键服务的存活保障。其 user + cmdline 双重过滤的进程匹配思路、60 秒轮询 + 7 天历史的参数设定、以及从 5.0 XML 到 6.0 YAML 的迁移路径，都值得在自建监控模板时直接借鉴。