Zabbix 监控 Ozeki SMS Gateway 实战：基于 SNMP 的连接状态、用户消息队列与告警模板全解析

本文围绕 Zabbix community-templates 仓库中 template_ozeki_sms_gateway 目录下的 8 Ozeki 模板展开，讲解如何通过 SNMP 完整监控 Ozeki SMS Gateway 的服务器信息、服务商连接状态、用户消息队列大小，并借助触发器实现「连接未达期望状态」与「发送队列积压」告警、借助图形原型实现六类消息队列的可视化。读完本文，你将掌握该模板在 Zabbix 5.0/5.4/6.0 下的导入方法、全部监控项与 LLD 发现机制、两条触发器的表达式含义，以及如何从导出文件还原其底层私有 MIB OID 结构，为自行排查和扩展监控提供依据。

模板概览：一套 SNMP 模板覆盖 SMS 网关四大监控维度

8 Ozeki 模板的核心定位（来自模板描述与 5.4 README）是：

• 服务器信息：产品名称、版本、公司、版权、安装日期、操作系统版本、运行引擎与运行时长等；
• 连接状态：服务商（Service Provider）连接的期望状态与实际状态、连接类型、连接名称；
• 用户与队列：网关用户列表，以及每个用户的 Inbox / Outbox / Sent / NotSent / Scheduled / Deleted 六类消息队列大小；
• 告警与可视化：连接未达期望状态时告警、NotSent 队列快速膨胀时告警，并以图形原型按用户自动生成队列趋势图。

模板的若干基础事实（原文档明示）：

• 模板名称为 8 Ozeki，所属主机组为 17HostGroupOzeki；
• 全部监控项均基于 SNMP agent 采集（Zabbix 对目标主机 UDP 161 端口发起轮询）；
• 所有监控项与发现规则的更新周期统一为 30s；
• 模板未定义宏（"There are no macros links in this template."），也未链接其他模板（"There are no template links in this template."），是一个完全独立的模板；
• 原模板描述注明 Tested on zabbix 3.4（在 Zabbix 3.4 上验证通过），仓库在此基础上提供了 5.0 / 5.4 / 6.0 三种导出格式。

仓库文件布局与适用版本

该模板在仓库中以「目录内 README + 官方导出文件」的形式组织，共覆盖三个 Zabbix 大版本：

目录	README	导出文件	格式
5.0	5.0/README.md	template_ozeki_sms_gateway.xml	XML（Zabbix 5.0 旧式导出）
5.4	5.4/README.md	template_ozeki_sms_gateway.yaml	YAML（新式导出）
6.0	6.0/README.md	template_ozeki_sms_gateway.yaml	YAML（新式导出）

三个版本的监控项、发现规则、触发器与图形原型完全一致（两份 YAML 的 uuid 也相同），主要差异在于 5.0 XML 使用旧式触发器表达式语法、5.4/6.0 YAML 使用 Zabbix 5.4 起的新式 change()/abs() 函数写法，详见下文「触发器表达式」一节。导出时间为 2021-11-21。

部署导入：三步把模板跑起来

前置条件（需在监控目标侧完成）：

1. Ozeki SMS Gateway 主机上已启用 SNMP 服务（在 Ozeki 管理界面中开启 SNMP 接口并配置 Community 字符串）；
2. Zabbix server / proxy 与目标主机之间 UDP 161 端口可达；
3. 在 Zabbix 主机配置中为 8 Ozeki 所关联的主机创建 SNMP 接口，并设置 SNMP community（模板本身未定义宏，SNMP 凭据依赖 Zabbix 默认的 {$SNMP_COMMUNITY} 主机级宏，默认值通常为 public）。

导入步骤：

1. 打开 Zabbix Web 界面 → Data collection → Templates → Import；
2. 根据你的 Zabbix 版本选择对应文件：
   • Zabbix 5.0 导入 template_ozeki_sms_gateway.xml；
   • Zabbix 5.4 / 6.0 导入对应目录下的 template_ozeki_sms_gateway.yaml；
3. 导入完成后，在主机配置中将模板 8 Ozeki 链接到目标主机；
4. 等待一个轮询周期后，在 Latest data 中验证 ozeki.* 系列监控项是否开始取值。

连通性快速验证（实操建议）：导入前可先用标准 SNMP 工具确认 Ozeki 私有子树可达，例如：

snmpwalk -v2c -c public <ozeki_host> 1.3.6.1.4.1.33355.1.1.3
snmpwalk -v2c -c public <ozeki_host> 1.3.6.1.4.1.33355.1.1.4

若返回为空或超时，应先排查 SNMP 服务与防火墙，而非模板问题。

模板内容全景：静态 Item + 两条 LLD + 触发器 + 图形原型

从 5.4 YAML 导出文件 的结构看，8 Ozeki 模板由四部分组成：

组成	数量	说明
静态监控项（items）	14	网关全局信息：产品、引擎、连接/用户汇总等
发现规则（discovery_rules）	2	ServiceProviderConnections、Users
原型监控项（item_prototypes）	15	5 个连接类 + 10 个用户类，随 LLD 动态生成
触发器 / 触发器原型	2 组	RequiredConnectionNotConnected、OzekiSendQueuOverflow
图形原型（graph_prototypes）	1	MessageQueus（六队列趋势）

服务器通用信息监控项：14 个静态 Item 全解

以下 14 个静态监控项直接采集自 Ozeki 私有 MIB（企业号 33355），类型均为 SNMP agent，更新周期 30s，值类型均为 TEXT 且关闭趋势存储（trends: '0'），适合作为主机 inventory 与状态展示信息。OID 与 key 均来自 5.4 YAML 与 5.0 XML：

监控项名称	Key	SNMP OID	值类型
OzekiSoftwareProduct	ozeki.OzekiSoftwareProduct	1.3.6.1.4.1.33355.1	TEXT
OzekiNGSMSGateway	ozeki.OzekiNGSMSGateway	1.3.6.1.4.1.33355.1.1	TEXT
Manifest	ozeki.Manifest	1.3.6.1.4.1.33355.1.1.1	TEXT
CompanyName	ozeki.CompanyName	1.3.6.1.4.1.33355.1.1.1.1	TEXT
ProductName	ozeki.ProductName	1.3.6.1.4.1.33355.1.1.1.2	TEXT
ProductURL	ozeki.ProductURL	1.3.6.1.4.1.33355.1.1.1.3	TEXT
ProductEmail	ozeki.ProductEmail	1.3.6.1.4.1.33355.1.1.1.4	TEXT
LegalCopyright	ozeki.LegalCopyright	1.3.6.1.4.1.33355.1.1.1.5	TEXT
InstallationDate	ozeki.InstallationDate	1.3.6.1.4.1.33355.1.1.1.6	TEXT
OSVersion	ozeki.OSVersion	1.3.6.1.4.1.33355.1.1.1.7	TEXT
Engine	ozeki.Engine	1.3.6.1.4.1.33355.1.1.2	TEXT
ProductUptime	ozeki.Uptime	1.3.6.1.4.1.33355.1.1.2.1	TEXT
ServiceProviderConnections	ozeki.ServiceProviderConnections	1.3.6.1.4.1.33355.1.1.3	TEXT
Users	ozeki.Users	1.3.6.1.4.1.33355.1.1.4	TEXT

从取值类型（全部 TEXT、无趋势）可以推断，这 14 个 Item 的设计意图是网关档案信息展示而非性能趋势分析：前 12 项描述产品与运行环境（安装日期、操作系统、引擎、运行时长、厂商联系信息等），后两项 ServiceProviderConnections 与 Users 则是连接表与用户表的汇总标量，与两条 LLD 规则形成「汇总 + 明细」的互补关系。

从导出文件还原 Ozeki 私有 MIB 的 OID 层级

把上述 OID 与下文原型 OID 放在一起，可以还原出模板所依赖的 Ozeki 私有 MIB 树（1.3.6.1.4.1.33355 为厂商私有企业号，以下树形结构完全依据导出文件中各 snmp_oid 字段推导）：

1.3.6.1.4.1.33355.1                      OzekiSoftwareProduct
└── 1.3.6.1.4.1.33355.1.1                OzekiNGSMSGateway
    ├── 1.3.6.1.4.1.33355.1.1.1          Manifest
    │   ├── .1 CompanyName
    │   ├── .2 ProductName
    │   ├── .3 ProductURL
    │   ├── .4 ProductEmail
    │   ├── .5 LegalCopyright
    │   ├── .6 InstallationDate
    │   └── .7 OSVersion
    ├── 1.3.6.1.4.1.33355.1.1.2          Engine
    │   └── .1 Uptime（ProductUptime）
    ├── 1.3.6.1.4.1.33355.1.1.3          ServiceProviderConnections（表）
    └── 1.3.6.1.4.1.33355.1.1.4          Users（表）

理解这棵树的价值在于：当模板出现「不支持 OID」「取值为空」时，你可以用 snmpwalk 逐层下钻，确认是网关侧 MIB 版本差异还是模板 OID 过期，实现快速定位。

LLD 发现规则一：ServiceProviderConnections（服务商连接）

该规则负责自动发现网关中配置的服务商连接（每个连接对应一条 SMS 服务商线路），并为其生成状态类监控项。

关键定义（来自 5.4 YAML）：

• 名称：ServiceProviderConnections
• 类型：SNMP agent
• SNMP OID：discovery[{#OZEKICONNAME},1.3.6.1.4.1.33355.1.1.3]
• Key：ozeki.ServiceProviderConnectionsList
• 更新周期：30s

这里的 discovery[{#OZEKICONNAME},oid] 是 Zabbix 的 SNMP 低层发现（LLD）语法：Zabbix 遍历 1.3.6.1.4.1.33355.1.1.3 子树的所有实例，把每个实例的索引写入宏 {#OZEKICONNAME}，从而动态枚举出所有连接；同时原型内部可引用自动宏 {#SNMPINDEX} 拼接具体实例 OID。该规则下共 5 个原型监控项（均 30s、TEXT、无趋势）：

原型名称	Key（含 LLD 宏）	原型 OID
ConnectionName $1	ozeki.ConnectionName[{#OZEKICONNAME}]	1.3.6.1.4.1.33355.1.1.3.{#SNMPINDEX}
ConnectionType $1	ozeki.ConnectionType[{#OZEKICONNAME}]	1.3.6.1.4.1.33355.1.1.3.{#SNMPINDEX}.1
ServiceProviderName $1	ozeki.ServiceProviderName[{#OZEKICONNAME}]	1.3.6.1.4.1.33355.1.1.3.{#SNMPINDEX}.2
DesiredConnectionStatus $1	ozeki.DesiredConnectionStatus[{#OZEKICONNAME}]	1.3.6.1.4.1.33355.1.1.3.{#SNMPINDEX}.3
ConnectionStatus $1	ozeki.ConnectionStatus[{#OZEKICONNAME}]	1.3.6.1.4.1.33355.1.1.3.{#SNMPINDEX}.4

可以看到每个连接实例由 5 个叶子节点描述：{index} 本身为连接名称，.1 为连接类型，.2 为服务商名称，.3 为期望连接状态（Desired），.4 为实际连接状态（Current）。其中 DesiredConnectionStatus 与 ConnectionStatus 正是触发器 RequiredConnectionNotConnected 的输入数据（见下文）。

LLD 发现规则二：Users（用户消息队列）

该规则自动发现网关中的用户，并为每个用户生成消息队列类监控项。队列是短信网关健康度最关键的数据：任一队列持续增长都意味着消息流转异常。

关键定义（来自 5.4 YAML）：

• 名称：Users
• 类型：SNMP agent
• SNMP OID：discovery[{#OZEKIUSERNAME},1.3.6.1.4.1.33355.1.1.4]
• Key：ozeki.UsersList
• 更新周期：30s

该规则下共 10 个原型监控项：

原型名称	Key（含 LLD 宏）	原型 OID	值类型
UserName $1	ozeki.UserName[{#OZEKIUSERNAME}]	1.3.6.1.4.1.33355.1.1.4.{#SNMPINDEX}	TEXT（无趋势）
UserType $1	ozeki.UserType[{#OZEKIUSERNAME}]	1.3.6.1.4.1.33355.1.1.4.{#SNMPINDEX}.1	TEXT（无趋势）
UserConnectionStatus $1	ozeki.UserConnectionStatus[{#OZEKIUSERNAME}]	1.3.6.1.4.1.33355.1.1.4.1.2	TEXT（无趋势）
UserMessageQueues $1	ozeki.UserMessageQueues[{#OZEKIUSERNAME}]	1.3.6.1.4.1.33355.1.1.4.{#SNMPINDEX}.3	TEXT（无趋势）
Inbox $1	ozeki.Inbox[{#OZEKIUSERNAME}]	1.3.6.1.4.1.33355.1.1.4.{#SNMPINDEX}.3.1	默认数值
Outbox $1	ozeki.Outbox[{#OZEKIUSERNAME}]	1.3.6.1.4.1.33355.1.1.4.{#SNMPINDEX}.3.2	默认数值
Sent $1	ozeki.Sent[{#OZEKIUSERNAME}]	1.3.6.1.4.1.33355.1.1.4.{#SNMPINDEX}.3.3	默认数值
NotSent $1	ozeki.NotSent[{#OZEKIUSERNAME}]	1.3.6.1.4.1.33355.1.1.4.{#SNMPINDEX}.3.4	默认数值
Scheduled $1	ozeki.Scheduled[{#OZEKIUSERNAME}]	1.3.6.1.4.1.33355.1.1.4.{#SNMPINDEX}.3.5	默认数值
Deleted $1	ozeki.Deleted[{#OZEKIUSERNAME}]	1.3.6.1.4.1.33355.1.1.4.{#SNMPINDEX}.3.6	默认数值

六类队列的语义（结合 OID 层级与模板命名推断）：Inbox 收件箱、Outbox 待发送队列、Sent 已发送、NotSent 发送失败/未发送、Scheduled 定时发送、Deleted 已删除消息。在导出文件中，这六个队列原型未显式声明 value_type，采用 Zabbix 默认的数值类型（NUMERIC_FLOAT）并保留默认趋势存储，这与前文 TEXT 类 Item 显式声明 value_type: TEXT、trends: '0' 形成鲜明对比——队列长度是需要保留趋势、绘制图形的数值指标，而档案信息不需要。

一个值得注意的实现细节：UserConnectionStatus 的原型 OID 是固定标量 1.3.6.1.4.1.33355.1.1.4.1.2，并没有像其他原型那样使用 {#SNMPINDEX} 展开。这意味着该 Item 对所有被发现的用户读取的是同一个 OID 实例，各用户生成的原型取值会彼此相同（或仅反映该固定实例的状态）。从源码结构看，这更像是模板作者针对特定 Ozeki 版本 MIB 的定制写法，在网关版本升级或 MIB 变更时需要特别留意。

告警触发器：断连检测与队列溢出

README 的 Triggers 一节列出了 4 条记录，本质是 2 个独立触发器 + 其 LLD 原型版本（即 README 中标记 (LLD) 的后两行，对应 YAML 中的 trigger_prototypes）。

触发器一：RequiredConnectionNotConnected（连接未达期望状态）

• 优先级：average（平均）
• 触发表达式（5.4/6.0 新式语法，见 5.4 YAML）：

abs(change(/8 Ozeki/ozeki.DesiredConnectionStatus[{#OZEKICONNAME}]))<>abs(change(/8 Ozeki/ozeki.ConnectionStatus[{#OZEKICONNAME}]))

• 语义：比较期望连接状态与实际连接状态在两个轮询点之间的绝对变化量。当期望状态发生跃迁（如管理员要求连接从「连接」切到「断开」，change 绝对值由 0 变为 1）而实际状态没有同步跃迁（change 绝对值仍为 0）时，两侧变化量不一致，触发器置为 PROBLEM，提示「期望的线路状态没有落实，连接不在期望状态」。
• 恢复表达式：空（README 中 Recovery expression 为空），即模板未提供独立恢复条件，恢复依赖表达式条件自然回落。
• 该触发器同时以 trigger_prototype 形式挂在 ServiceProviderConnections 发现规则下（README 中标记 (LLD) 的条目），对每个被发现的连接实例自动生效。

触发器二：OzekiSendQueuOverflow（发送队列溢出）

• 优先级：average（平均）
• 触发表达式（5.4/6.0 新式语法，见 5.4 YAML）：

abs(change(/8 Ozeki/ozeki.NotSent[{#OZEKIUSERNAME}]))>5

• 语义：NotSent（未发送）队列在一个更新周期（30s）内绝对增量超过 5 条时触发。这通常意味着消息发送通道拥堵、服务商连接异常或路由配置错误导致消息持续积压，是短信网关「发不出去」最直接的信号。
• 该触发器作为 item_prototype（NotSent $1）的内嵌 trigger_prototype 定义，随 Users 发现规则按用户自动生成，阈值 5 对每个用户独立生效。

触发器表达式的版本演进：5.0 XML 与 5.4/6.0 YAML 的写法对照

同一个触发器在 5.0 XML 与 5.4/6.0 YAML 中使用了两种语法，功能等价：

触发器	5.0 XML（旧式）	5.4/6.0 YAML（新式）
RequiredConnectionNotConnected	{8 Ozeki:ozeki.DesiredConnectionStatus[{#OZEKICONNAME}].abschange()}<>{8 Ozeki:ozeki.ConnectionStatus[{#OZEKICONNAME}].abschange()}	abs(change(/8 Ozeki/ozeki.DesiredConnectionStatus[{#OZEKICONNAME}]))<>abs(change(/8 Ozeki/ozeki.ConnectionStatus[{#OZEKICONNAME}]))
OzekiSendQueuOverflow	{abschange()}>5	abs(change(/8 Ozeki/ozeki.NotSent[{#OZEKIUSERNAME}]))>5

• 5.0 XML 使用函数后缀式写法（.abschange()），其中 {abschange()}>5 是省略主机/Item 引用的简写形式，等价于当前原型自身的绝对变化量；
• 5.4 起 Zabbix 采用新的函数式语法（abs(change(...))），并显式写明 主机/Item 全路径。两份文件在逻辑上完全一致，迁移版本时不会改变告警行为。

图形原型 MessageQueus：六类队列一图尽览

模板在 Users 发现规则下定义了一个图形原型 MessageQueus（5.4 YAML），将六类队列的长度绘制在同一张图中，序列与颜色映射如下：

排序	序列（Key）	颜色
0	ozeki.Deleted[{#OZEKIUSERNAME}]	1A7C11（绿）
1	ozeki.Inbox[{#OZEKIUSERNAME}]	F63100（红）
2	ozeki.NotSent[{#OZEKIUSERNAME}]	2774A4（蓝）
3	ozeki.Outbox[{#OZEKIUSERNAME}]	A54F10（棕）
4	ozeki.Scheduled[{#OZEKIUSERNAME}]	FC6EA3（粉）
5	ozeki.Sent[{#OZEKIUSERNAME}]	6C59DC（紫）

由于它是 graph_prototype，每发现一个新用户都会自动生成一张独立的 MessageQueus 趋势图，无需手工建图。这张图配合 OzekiSendQueuOverflow 触发器，可以直观看到队列的「正常水位」与「溢出拐点」，是短信网关容量与健康监控的常用视图。

总结与延伸使用建议

8 Ozeki 模板以纯 SNMP 方式覆盖了 Ozeki SMS Gateway 的档案信息、服务商连接状态与用户消息队列三大数据面，并内置了断连检测与发送队列溢出两类 average 级告警和一套六队列图形原型。它无宏、无模板依赖，部署成本极低，适合直接接入生产环境。

在此基础上可以进一步做的工程化动作（结合 Zabbix 能力，非模板自带）：

• 在 Zabbix 5.4+ 中基于 ozeki.* 监控项创建仪表盘 widget，将连接状态、NotSent 队列与 MessageQueus 图汇总到同一页面；
• 为主机补充告警媒介（邮件/钉钉/企业微信等），将两条 average 触发器接入值班通知；
• 若网关侧 MIB 版本不同导致某些 OID 无数据，可参考本文还原的 OID 树用 snmpwalk 对照排查，必要时在 Zabbix 中复制模板并修正对应 snmp_oid；
• 如需调整告警灵敏度，直接修改 RequiredConnectionNotConnected 的比较逻辑或 OzekiSendQueuOverflow 的阈值 5 即可，注意 LLD 原型与静态触发器需同步修改。

事实边界说明：本文所有监控项、OID、表达式与颜色均直接取自仓库中的 5.0 XML、5.4 YAML、6.0 YAML 导出文件及对应 README；「Tested on zabbix 3.4」为原模板描述原文；OID 树形结构与队列语义系依据导出文件中 snmp_oid 的层级关系推断，Ozeki 网关侧的 MIB 具体定义以你实际部署版本的官方 MIB 为准。