企业官网建设流程全解析

本指南围绕社区模板仓库community-templates中位于 Databases/template_progress_datasul_totvs 的Banco Progress Datasul模板展开，讲解如何借助 Zabbix Agent（Windows 或 Linux）对 TOTVS Datasul 套件所使用的 Progress 数据库默认服务端口进行连通性监控。读完本文，你将掌握该模板的完整结构（22 个端口监控项、值映射与触发器）、模板导出文件（5.0 XML 与 5.4/6.0 YAML）中的实现细节差异，以及从导入到验证的完整部署流程。

模板定位与适用场景

根据模板 README 的说明（见 5.0/README.md 与 5.4/README.md），该模板的核心定位是：

Basic template with items and triggers monitoring default Totvs Datasul ports using Zabbix Agent on the host (Windows or Linux).

即：基于 Zabbix Agent 的被动检查，监控 TOTVS Datasul 的默认端口。Datasul 是 TOTVS 的 ERP 产品线，其底层数据库为 Progress（模板名 "Banco Progress Datasul" 即"Progress 数据库 / Datasul"之意，README 中也明确写到 "banco Progress para o Datasul da Totvs"）。在生产环境中，Datasul 的各个业务数据库（EMS、FINANCE、PAYROLL、HCM 等）分别监听独立的 TCP 端口，任何一个数据库实例异常下线都会直接影响业务可用性，因此以端口可达性作为监控信号，是一种轻量且无需侵入数据库内部的实用方案。

需要说明的适用前提：

• 模板要求监控主机上安装并运行 Zabbix Agent（README 注明支持 Windows 或 Linux 主机）；
• 模板导出文件按 Zabbix 版本组织：5.0 提供 XML 格式（template_progress_datasul_totvs.xml），5.4 与 6.0 提供 YAML 格式（5.4 版 YAML、6.0 版 YAML）；
• README 标注该模板最初在 Zabbix 3.4.6 上测试通过，三个版本文件的实际导出日期均为 2021-11-21。

模板整体结构剖析

从模板导出文件可以还原出模板的完整骨架。模板名为Banco Progress Datasul，归属于两个主机/模板组：Datasul与Progress。在 5.0 的 XML 中，所有监控项都被归入名为Progress的 application（应用组）；而在 5.4/6.0 的 YAML 中，这一分组方式被替换为统一的 tag 标记：tag: Application, value: Progress。这是 Zabbix 新旧版本导出格式的典型差异，但语义一致——所有监控项均与 Progress 数据库这一应用上下文绑定。

模板不包含任何宏（macros）、模板链接（template links）或发现规则（discovery rules），这一点在三个版本的 README 中均有明确声明。这意味着：

• 模板开箱即用，无需预定义宏或依赖其他模板；
• 22 个监控项全部为静态定义，不依赖 LLD 自动发现；
• 各数据库名称与端口号在模板中固定写死，适用于标准端口部署的 Datasul 环境。

值映射：把 0/1 变成 Online/Offline

模板导出了名为Progress Datasul的全局值映射（value map），定义如下：

该值映射在 5.0 XML 与 5.4/6.0 YAML 中完全一致（见 5.0 XML 的 value_maps 段 与 5.4 YAML 的 valuemaps 段）。由于net.tcp.port键返回的是 0/1 数值，值映射让监控项在最新数据界面中直接呈现为可读的 "Online / Offline"，而不是裸数字。

22 个端口监控项全表

模板的监控项全部基于 Zabbix Agent 内建键net.tcp.port[<address>,<port>]，用于探测指定 TCP 端口是否可连通：返回1表示端口开放（可达），返回0表示不可达。模板中将第一个参数（地址）留空，由 Agent 依据自身配置确定探测目标；端口号作为第二个参数显式指定。

以下为模板定义的完整监控项清单（数据来源于 5.0/README.md 的 Items collected 表格，并与 5.0 XML 交叉核对）：

从上表可以看出三个规律：

1. 端口规划集中：除DB MGESP（23700）外，其余 21 个数据库端口集中在 23600～23640 区间，与 Datasul 默认端口规划一致；
2. 更新频率统一：所有监控项均为 10 秒更新一次，属于较积极的探测频率，可及时反映数据库服务中断；
3. 部分项默认禁用：DB NEOGRID、DB EMSINC、DB SRCADGER、DB SRMOVFIN、DB MDTCRM五个监控项在模板导出文件中被标记为DISABLED（见 5.0 XML 中各 item 的<status>DISABLED</status>字段）。这一点在 README 的表格中并未体现，属于导出文件中的实际状态，推测这些数据库并非所有 Datasul 部署都启用，导入后可结合现场环境按需启用。

触发器：README 与模板文件的事实差异

一个值得注意的细节：README 的 Triggers 一节声明 "There are no triggers in this template"（模板中无触发器），但实际模板导出文件并非如此。

核对 5.0 XML 与 5.4/6.0 YAML 可以发现：22 个监控项中，除DB MOV2DIS外，其余 21 个监控项每个都内嵌定义了一个触发器，命名为Database <XXX> is down（如Database EMS2ADT is down），严重级别为HIGH。这是以 README 为代表的文档与实际模板实现不一致的典型案例——在实际使用中应以模板导出文件为准。

触发器的判定逻辑简单而直接：只要最近一次探测结果不等于 1（{last()}<>1），即认为对应数据库端口不可达，触发告警。由于net.tcp.port在端口开放时返回 1、关闭时返回 0，因此<>1等价于"端口未开放"。表达式在三个版本中的写法存在语法差异：

• 5.0 XML：简写形式{last()}<>1（XML 中转义为<>），如{last()}<>1；
• 5.4/6.0 YAML：完整引用形式last(/Banco Progress Datasul/net.tcp.port[,23600])<>1，明确指定了模板与 item key 的完整路径（见 5.4 YAML 第 82 行 等处的 triggers 定义）。

与"无触发器"声明矛盾的还有禁用项的处理：DB NEOGRID等 5 个被禁用的监控项，其内嵌触发器同样被标记为DISABLED（XML 与 YAML 中 trigger 的<status>/status字段均为 DISABLED），随监控项一起静默，不会产生告警噪音。

部署与使用步骤

1. 按版本导入模板

仓库按 Zabbix 版本划分了三个目录，导入时务必选择与你的 Zabbix Server 主版本匹配的文件：

导入路径：Zabbix 前端Configuration（配置）→ Templates（模板）→ Import（导入），选择对应文件后提交。仓库根目录 README.md 也给出了通用流程：下载模板 → 导入到支持的 Zabbix 版本 → 按配置要求调整 → 将模板关联到主机。

2. 配置主机并关联模板

模板的类型为Zabbix agent（被动检查），因此监控主机必须满足：

• 安装并运行 Zabbix Agent（Windows 或 Linux 均可，模板不区分平台）；
• Agent 与 Zabbix Server/Proxy 网络可达，且主机已加入 Zabbix 监控；
• 主机上 Datasul 的 Progress 数据库服务正常监听上述默认端口。

在主机配置页面通过Templates链接搜索并添加Banco Progress Datasul模板即可完成关联。

3. 验证数据采集

导入并关联后，可以在Monitoring → Latest data（最新数据）中查看各监控项取值：端口可达时显示映射值Online（原始值 1），不可达时显示Offline（原始值 0）。若需要命令行快速验证 Agent 侧的探测结果，可在 Zabbix Server 上使用zabbix_get手工测试：

zabbix_get -s <主机IP或主机名> -k "net.tcp.port[,23600]" # 返回 1 表示 23600 端口可达，返回 0 表示不可达

注意：zabbix_get命令需要在安装有 zabbix-get 工具的环境中执行，并且主机 Agent 需允许该主机的被动检查请求。

4. 按需调整

• 若现场部署未使用NEOGRID、EMSINC、SRCADGER、SRMOVFIN、MDTCRM等数据库，保持其禁用状态即可；若使用了这些数据库，可在监控项配置中将其启用（同时会连带启用对应触发器）；
• 若 Datasul 数据库端口在环境中被改写过（非标准端口部署），模板中写死的端口号需要同步修改——该模板未使用宏，端口号直接内嵌于 item key 中；
• 10 秒的更新间隔可根据告警策略与 Agent 负载适当调大（如 30s/60s），减少无谓的探测开销。

监控原理与边界说明

从模板结构可以推断其设计思路：用 TCP 端口连通性作为数据库实例存活的代理指标。net.tcp.port是 Zabbix Agent 的内建键，由 Agent 进程发起 TCP 连接探测，不依赖任何外部脚本或第三方工具，因此部署成本极低、跨平台一致（Windows/Linux 行为相同），这是该模板最大的实用价值。

同时也要明确其边界：

• 端口可达只代表TCP 层监听正常，不代表数据库进程健康（例如 Progress 服务僵死但仍占用端口、或端口被其他进程占用时，会出现误判）；如需更深层健康检查，应结合数据库自身状态指标扩展监控；
• 模板不含发现规则，新增数据库实例需要手动在模板中补充监控项；
• 从源码结构看，DB MOV2DIS是唯一没有内嵌触发器的监控项（见 5.0 XML 中该 item 的定义），即它只采集数据、不产生告警，需要告警时需自行补充。

总结

Banco Progress Datasul是一个简洁、零依赖的 Zabbix 社区模板：以net.tcp.port键为核心，用 22 个静态监控项覆盖 TOTVS Datasul 的 Progress 数据库默认端口（23600～23640 及 23700），配合Progress Datasul值映射（0=Offline / 1=Online）与 21 个 HIGH 级别 "is down" 触发器，实现数据库端口层面的实时告警。部署时只需在安装有 Zabbix Agent 的 Windows/Linux 主机上导入对应版本模板并关联即可。需要特别提醒的是：README 中"无触发器"的声明与模板文件中的实际定义不符，实际告警能力以内嵌于模板导出文件的触发器为准；文档与实现存在出入，这也体现了以模板导出文件作为事实依据的重要性。