【免费下载链接】community-templates
Zabbix Community Templates repository
本文基于 Zabbix Community Templates 仓库中 Databases/Microsoft_SQL_Server/template_app_ms_sql_database_discovery_(lld)) 目录下的模板定义（5.0/5.4/6.0 三个版本）及其 5.0 README/5.0/README.md) 撰写，完整讲解该模板的发现机制、29 个性能计数器监控项、告警触发器与图形原型，并给出可落地的部署与调参建议。
模板是什么：一个按库粒度监控 SQL Server 的 LLD 方案
Template App MS SQL DB Discovery是 Zabbix Community Templates 仓库中针对Microsoft SQL Server 数据库级（per-database）性能监控的专用模板。它与同目录下的姊妹模板Template App MS SQL Instance Discovery（实例级发现，见 5.0 README/5.0/README.md)）形成"实例 + 数据库"的两级监控体系：后者负责发现机器上安装了哪些 SQL Server 实例，前者负责在单个指定实例内自动发现所有用户数据库，并为每个数据库自动创建一组SQL Server:Databases(*)性能计数器监控项。
模板的核心价值在于低级别发现（LLD）：运维人员无需为每个数据库手工创建监控项，模板会通过windowsdb.discovery键枚举实例中的数据库列表，然后借助{#DBS}宏为每个数据库动态生成几十个监控项。读完本文，你将掌握：
- 该模板的发现规则、过滤器与宏的完整配置逻辑；
- 29 个数据库级性能计数器的含义、单位与取值建议；
- 5 类告警触发器的表达式与告警阈值设计思路；
- 8 个图形原型的组成，以及如何在 Zabbix 5.0（XML 导入）与 5.4/6.0（YAML 导入）中落地使用。
模板总览：版本、分组与应用
该模板在仓库中按 Zabbix 版本提供三份等价定义：
| Zabbix 版本 | 文件 | 格式 |
|---|---|---|
| 5.0 | template_app_ms_sql_database_discovery_(lld).xml/5.0/template_app_ms_sql_database_discovery_(lld).xml) | XML（zabbix_export） |
| 5.4 | template_app_ms_sql_database_discovery_(lld).yaml/5.4/template_app_ms_sql_database_discovery_(lld).yaml) | YAML |
| 6.0 | template_app_ms_sql_database_discovery_(lld).yaml/6.0/template_app_ms_sql_database_discovery_(lld).yaml) | YAML |
三份定义导出的实体完全一致，只是序列化格式不同：5.0 版使用<applications><application><name>SQL Databases</name></application></applications>声明应用，而 5.4/6.0 版改用标签（tag）体系，为每个 item prototype 打上Application: SQL Databases标签（见 5.4 YAML 第 37-40 行/5.4/template_app_ms_sql_database_discovery_(lld).yaml#L37-L40)）。模板所属组均为Windows Servers，从模板的组织归属即可看出它的目标平台是 Windows 主机（SQL Server 通常部署在 Windows 上）。
核心机制一：发现规则windowsdb.discovery
模板只有一个发现规则，但它是整个模板的引擎。以 5.0 XML 为例（XML 第 24-38 行/5.0/template_app_ms_sql_database_discovery_(lld).xml#L24-L38)）：
| 属性 | 值 |
|---|---|
| 名称 | MS SQL DB Discovery |
| 键（Key） | windowsdb.discovery |
| 类型 | Zabbix agent |
| 更新间隔 | 300 秒 |
| 过滤器 | {#DBS}匹配全局正则@MS SQL System DBs |
数据来源：PowerShell 脚本
README 对发现规则的描述是 "Discovers databases within a single instance specified in a Powershell script"，即windowsdb.discovery键的 JSON 数据由被监控主机上的 PowerShell 脚本生成：脚本连接指定实例、枚举数据库名，并以{"data":[{"{#DBS}":"数据库名"}, ...]}的 LLD 标准 JSON 格式输出给 Zabbix agent。脚本本体未包含在本仓库中，需要参照 Zabbix 官方 Windows 支持脚本（windows目录下的 PowerShell 发现脚本）的惯例，将其部署到 Zabbix agent 的scripts目录并在zabbix_agentd.conf中用UserParameter=windowsdb.discovery[...]注册——这是该模板落地时最关键的外部依赖。
过滤器：排除 SQL Server 系统数据库
发现规则配置了过滤器（5.0 XML 第 29-37 行/5.0/template_app_ms_sql_database_discovery_(lld).xml#L29-L37)）：
宏（macro）：{#DBS} 值（value）：@MS SQL System DBs 公式ID：A@MS SQL System DBs是Zabbix 全局正则表达式（global regex）的引用，作用是对{#DBS}宏（即脚本返回的数据库名）做匹配过滤。该全局正则需要在 Zabbix 前端「管理 → 一般 → 正则表达式」中预先定义，通常用于匹配master、model、msdb、tempdb等系统数据库名，其语义即"命中系统库名称的数据库将被排除、不创建监控项"。仓库内未附带该正则的定义文件，导入模板后需要自行创建，这是第二个外部依赖。
为什么用 LLD：按库动态伸缩
发现间隔 300 秒意味着数据库列表最长 5 分钟刷新一次。当实例中新增/删除数据库时，item prototypes 会依据最新发现结果自动创建/删除对应监控项，无需人工干预。这种"一次定义、按库展开"的模式正是 LLD 相对静态监控的核心优势。
核心机制二：宏{$INSTANCE01}与性能计数器键
模板定义了唯一一个用户宏（5.0 XML 第 685-690 行/5.0/template_app_ms_sql_database_discovery_(lld).xml#L685-L690)）：
| 宏 | 描述 | 默认值 | 类型 |
|---|---|---|---|
{$INSTANCE01} | 无（README 未给出描述） | SQLServer | Text macro |
所有 29 个监控项的键都遵循同一模式：
perf_counter["\{$INSTANCE01}:Databases({#DBS})\<计数器名>",300]拆解该键的语义：
perf_counter[...]是 Zabbix agent 内置的 Windows 性能计数器键，直接读取SQL Server:Databases(<数据库>)性能对象下的计数器实例；\{$INSTANCE01}是 SQL Server 性能计数器对象名的实例前缀：默认实例为SQLServer，命名实例形如MSSQL$<实例名>（例如MSSQL$SQLEXPRESS）。宏之所以写成{$INSTANCE01}而非硬编码，就是为了让用户在主机/模板宏层面按需覆盖，监控命名实例时无需修改任何监控项；({#DBS})是 LLD 宏，发现出的每个数据库名都会被代入此处，形成perf_counter["SQLServer:Databases(master)\..."]这样的具体键；- 键末尾的
,300是perf_counter键的<step>参数（秒），用于指定计算速率型计数器的采样步长，模板统一取 300 秒； - item prototype 更新间隔为 30 秒，值类型统一为
FLOAT。
监控项全集：29 个数据库级性能计数器
模板在单个发现规则下定义了 29 个 item prototypes（5.0 XML 第 39-448 行/5.0/template_app_ms_sql_database_discovery_(lld).xml#L39-L448)），全部隶属于应用/标签SQL Databases。按指标主题可分为五大类，下表完整列出（单位与取值参考 5.4 YAML 定义/5.4/template_app_ms_sql_database_discovery_(lld).yaml)）：
事务与吞吐类
| 监控项名称 | 计数器 | 单位 | 说明 |
|---|---|---|---|
{$INSTANCE01} Databases {#DBS} Active Transactions | Active Transactions | 无 | 数据库当前活动事务数 |
{$INSTANCE01} Databases {#DBS} Transactions/sec | Transactions/sec | /sec | 每秒启动的事务数 |
{$INSTANCE01} Databases {#DBS} Write Transactions/sec | Write Transactions/sec | /sec | 上一秒内写入并提交的事务数 |
{$INSTANCE01} Databases {#DBS} Tracked transactions/sec | Tracked transactions/sec | /sec | 每秒记录到提交表（commit table）中的已提交事务数 |
{$INSTANCE01} Databases {#DBS} Bulk Copy Rows/sec | Bulk Copy Rows/sec | /sec | 每秒批量复制的行数 |
{$INSTANCE01} Databases {#DBS} Bulk Copy Throughput/sec | Bulk Copy Throughput/sec | KBytes/sec | 每秒批量复制（bulk copy）的数据量（KB） |
{$INSTANCE01} Databases {#DBS} Commit Table Entries | Commit Table Entries | 无 | 数据库提交表的内存部分大小 |
日志写入与等待类
| 监控项名称 | 计数器 | 单位 | 说明 |
|---|---|---|---|
{$INSTANCE01} Databases {#DBS} Log Flushes/sec | Log Flushes/sec | /sec | 每秒日志刷写（flush）次数 |
{$INSTANCE01} Databases {#DBS} Log Flush Waits/sec | Log Flush Waits/sec | /sec | 每秒因等待日志刷写而阻塞的提交数 |
{$INSTANCE01} Databases {#DBS} Log Flush Wait Time | Log Flush Wait Time | millisec | 刷写日志的总等待时间（毫秒）；AlwaysOn 辅助副本上表示日志记录写入磁盘（hardened）的等待时间 |
{$INSTANCE01} Databases {#DBS} Log Flush Write Time (ms) | Log Flush Write Time (ms) | millisec | 上一秒内完成的日志刷写所花写入时间（毫秒） |
{$INSTANCE01} Databases {#DBS} Log Bytes Flushed/sec | Log Bytes Flushed/sec | Bytes/sec | 每秒刷写的日志字节数（README 无描述） |
{$INSTANCE01} Databases {#DBS} Group Commit Time/sec | Group Commit Time/sec | /sec | 组提交时间（README 无描述） |
{$INSTANCE01} Databases {#DBS} Log Cache Reads/sec | Log Cache Reads/sec | /sec | 每秒经日志管理器缓存执行的读取次数 |
{$INSTANCE01} Databases {#DBS} Log Cache Hit Ratio | Log Cache Hit Ratio | 无（百分比） | 日志缓存读取的命中率（%） |
日志空间与增长类
| 监控项名称 | 计数器 | 单位 | 说明 |
|---|---|---|---|
{$INSTANCE01} Databases {#DBS} Percent Log Used | Percent Log Used | % | 日志空间使用百分比 |
{$INSTANCE01} Databases {#DBS} Log File(s) Size (KB) | Log File(s) Size (KB) | KBytes | 数据库全部事务日志文件的累计大小 |
{$INSTANCE01} Databases {#DBS} Log File(s) Used Size (KB) | Log File(s) Used Size (KB) | KBytes | 数据库全部日志文件已使用的累计大小 |
{$INSTANCE01} Databases {#DBS} Log Growths | Log Growths | 无 | 事务日志被扩展的总次数 |
{$INSTANCE01} Databases {#DBS} Log Shrinks | Log Shrinks | 无 | 事务日志被收缩的总次数 |
{$INSTANCE01} Databases {#DBS} Log Truncations | Log Truncations | 无 | 事务日志被截断（shrunk）的次数 |
日志池（Log Pool）类
| 监控项名称 | 计数器 | 单位 | 说明 |
|---|---|---|---|
{$INSTANCE01} Databases {#DBS} Log Pool Requests/sec | Log Pool Requests/sec | /sec | 日志池每秒处理的日志块请求数 |
{$INSTANCE01} Databases {#DBS} Log Pool Disk Reads/sec | Log Pool Disk Reads/sec | /sec | 日志池为获取日志块发起的磁盘读取次数 |
{$INSTANCE01} Databases {#DBS} Log Pool Cache Misses/sec | Log Pool Cache Misses/sec | /sec | 日志池缓存未命中的请求数；日志池是事务日志的内存缓存，用于优化恢复、事务复制、回滚与 AlwaysOn 可用性组场景下的日志读取 |
复制、数据文件与其他类
| 监控项名称 | 计数器 | 单位 | 说明 |
|---|---|---|---|
{$INSTANCE01} Databases {#DBS} Repl. Trans. Rate | Repl. Trans. Rate | /sec | 每秒从发布数据库事务日志读出并投递到分发数据库的事务数 |
{$INSTANCE01} Databases {#DBS} Repl. Pending Xacts | Repl. Pending Xacts | 无 | 标记为复制但尚未投递到分发数据库的事务数 |
{$INSTANCE01} Databases {#DBS} Shrink Data Movement Bytes/sec | Shrink Data Movement Bytes/sec | Bytes/sec | 自动收缩或DBCC SHRINKDATABASE/DBCC SHRINKFILE每秒移动的数据量 |
{$INSTANCE01} Databases {#DBS} DBCC Logical Scan Bytes/sec | DBCC Logical Scan Bytes/sec | Bytes/sec | 数据库控制台命令（DBCC）每秒的逻辑读取扫描字节数 |
{$INSTANCE01} Databases {#DBS} Data File(s) Size (KB) | Data File(s) Size (KB) | KBytes | 含自动增长在内的全部数据文件累计大小；该计数器常用于判断 tempdb 的合理大小 |
从上表可以直观看出模板的覆盖思路：事务负载（Transactions、Write Transactions、Active Transactions）、日志写入瓶颈（Log Flush Waits、Log Flush Wait Time）、日志空间耗尽风险（Percent Log Used、Log Growths、Log Shrinks）、复制延迟（Repl. Pending Xacts）以及容量规划（Data/Log File(s) Size）一应俱全，基本覆盖了日常 DBA 巡检数据库健康度的核心计数器。
告警触发器：5 类日志健康告警
模板在 item prototype 上内嵌了 5 个触发器原型（5.0 XML 各 trigger_prototypes 段/5.0/template_app_ms_sql_database_discovery_(lld).xml)），全部为warning优先级。README 的 Triggers 表格将其展开为 10 行（5 个基础触发器 + 5 个带(LLD)后缀的重复条目，后者是文档生成器对同一原型的重复呈现）：
| 触发器名称 | 表达式（5.0 相对形式） | 表达式（5.4/6.0 绝对形式） | 阈值含义 |
|---|---|---|---|
{#DBS} Log Flush Waits/sec | {avg(600)}>0.1 | avg(/App MS SQL DB Discovery/perf_counter[" SQLServer:Databases({#DBS}) Log Flush Waits/sec",300],600s)>0.1 | 每秒等待日志刷写的次数（600 秒均值）超过 0.1 |
{#DBS} Log Flush Wait Time | {avg(600)}>0.1 | avg(/App MS SQL DB Discovery/perf_counter[" SQLServer:Databases({#DBS}) Log Flush Wait Time",300],600s)>0.1 | 日志刷写总等待时间（毫秒）600 秒均值超过 0.1 |
{#DBS} Log Growths | {avg(600)}>0.1 | avg(/App MS SQL DB Discovery/perf_counter[" SQLServer:Databases({#DBS}) Log Growths",300],600s)>0.1 | 日志扩展次数 600 秒均值超过 0.1 |
{#DBS} Log Shrinks | {avg(600)}>0.1 | avg(/App MS SQL DB Discovery/perf_counter[" SQLServer:Databases({#DBS}) Log Shrinks",300],600s)>0.1 | 日志收缩次数 600 秒均值超过 0.1 |
{#DBS} Percent Log Used | {last()}>80 | last(/App MS SQL DB Discovery/perf_counter[" SQLServer:Databases({#DBS}) Percent Log Used",300])>80 | 日志使用率最新值超过 80% |
阈值设计背后的运维逻辑
Percent Log Used > 80%：模板描述明确指出 "Since all work in an OLTP database stops until writes can occur to the transaction log... the recommendation to keep the log under 80% full"。事务日志写满会导致 OLTP 工作全部停顿，因此在日志达到 80% 时告警，留出提前介入（如备份截断日志或扩容）的窗口。Log Growths > 0.1/600s：日志每增长一次，期间所有用户活动都必须暂停直至增长完成，因此理想情况是日志增长发生在预定义的维护窗口而非业务时间。0.1 次/600 秒的阈值意味着 10 分钟内出现 1 次增长即触发告警，用于捕捉业务时段的意外日志扩展。Log Flush Waits/sec与Log Flush Wait Time：两者共同反映日志写入 IO 是否成为瓶颈——前者是"每秒有多少提交在等日志刷写"，后者是"刷写等待累计毫秒数"，任一异常升高都提示存储 IO 延迟或日志文件所在磁盘性能不足。
5.0 的 XML 定义中触发器表达式采用相对形式{avg(600)}>0.1（以原型自身为基准），5.4/6.0 的 YAML 则显式写全了主机名App MS SQL DB Discovery与完整键路径，语义完全等价，仅取决于导出格式。恢复表达式（Recovery expression）在模板中均未定义，告警恢复依赖表达式自然回落。
图形原型：8 个按库自动生成的图表
除监控项与触发器外，模板还定义了 8 个图形原型（graph prototypes），每个发现的数据库都会自动生成一套图表（5.0 XML 第 449-682 行/5.0/template_app_ms_sql_database_discovery_(lld).xml#L449-L682)）：
| 图形名称 | 包含计数器 |
|---|---|
Database {#DBS} Bulk Copies | Bulk Copy Rows/sec、Bulk Copy Throughput/sec |
Database {#DBS} File Sizes (KB) | Data File(s) Size (KB)、Log File(s) Size (KB)、Log File(s) Used Size (KB) |
Database {#DBS} Log Pool Rates | Log Pool Cache Misses/sec、Log Pool Disk Reads/sec、Log Pool Requests/sec |
Database {#DBS} Log Rates | Log Bytes Flushed/sec、Log Cache Reads/sec、Log Flushes/sec、Log Flush Waits/sec |
Database {#DBS} Log Sizes | Log Growths、Log Shrinks、Log Truncations、Percent Log Used |
Database {#DBS} Log Times and Ratios | Log Cache Hit Ratio、Log Flush Wait Time、Log Flush Write Time (ms) |
Database {#DBS} Replication | Repl. Pending Xacts、Repl. Trans. Rate |
Database {#DBS} Transactions | Active Transactions、Tracked transactions/sec、Transactions/sec、Write Transactions/sec |
这些图形把功能相关的计数器聚合到同一张图上（例如"文件大小"图同时叠放数据文件与日志文件、已用/总大小），便于在监控屏上快速对比趋势，是模板开箱即用的可视化资产。
部署与使用步骤
1. 导入模板
- Zabbix 5.0：前端「配置 → 模板 → 导入」，选择 5.0 XML 文件/5.0/template_app_ms_sql_database_discovery_(lld).xml)；
- Zabbix 5.4 / 6.0：同样在「配置 → 模板 → 导入」选择对应 5.4 YAML/5.4/template_app_ms_sql_database_discovery_(lld).yaml) 或 6.0 YAML/6.0/template_app_ms_sql_database_discovery_(lld).yaml) 文件。
2. 配置两项外部依赖（关键前置条件）
- PowerShell 发现脚本：
windowsdb.discovery依赖脚本输出数据库列表 JSON。需将脚本部署到被监控 Windows 主机的 Zabbix agent 脚本目录，并在zabbix_agentd.conf中通过UserParameter注册该键（仓库未附带脚本实现，请参照 Zabbix 官方 Windows 支持脚本惯例完成）。 - 全局正则
@MS SQL System DBs：在 Zabbix 前端「管理 → 一般 → 正则表达式」创建名为MS SQL System DBs的全局正则，用于匹配master、model、msdb、tempdb等系统数据库，从而在发现结果中将其排除。
3. 关联主机并设置宏
- 将模板链接到目标 Windows 主机；
- 默认实例无需改动：宏
{$INSTANCE01}默认值SQLServer即对应默认实例； - 命名实例：在主机宏或模板宏层将
{$INSTANCE01}覆盖为MSSQL$<实例名>（例如MSSQL$SQLEXPRESS），所有 29 个监控项会自动采用新实例名采样。
4. 验证
链接后等待首个发现周期（最长 5 分钟）及监控项首个更新周期（30 秒），在「监测 → 最新数据」中按主机过滤，即可看到按{#DBS}展开的形如SQLServer:Databases(<库名>)\Transactions/sec的监控项开始出数据。若发现规则无数据，优先排查 PowerShell 脚本输出格式、UserParameter 注册及全局正则匹配情况。
与实例级发现模板的配合
在 Windows 服务器上监控 SQL Server，通常需要两级模板协同：
- 实例级：
Template App MS SQL Instance Discovery（README/5.0/README.md)）通过windowssqlinstances.discovery发现多个实例，监控Buffer Manager、SQL Statistics、Locks、Latches、General Statistics、Access Methods、Memory Manager等实例级计数器，并为每个实例监控 SQL 服务状态； - 数据库级：本文的
Template App MS SQL DB Discovery聚焦SQL Server:Databases(*)对象，按库细化到事务、日志、复制与容量维度。
两者一个管"实例整体健康"，一个管"每个库的明细"，按需链接即可构成完整的 SQL Server 监控栈。
注意事项与最佳实践
- 日志空间是最高优先告警：
Percent Log Used > 80%使用last()即时判断，其余四个触发器使用 600 秒均值平滑，二者互补——前者捕捉瞬时风险，后者过滤毛刺； Log Growths/Log Shrinks的语义：增长与收缩本身不是错误，但发生在业务时段往往意味着日志配置（初始大小、自动增长步长）不合理或存在反复收缩问题，告警触发后应检查日志文件初始大小与DBCC SHRINKFILE的滥用情况；- 复制计数器仅在配置了复制/AlwaysOn 时才有意义：
Repl. Trans. Rate、Repl. Pending Xacts在无复制的数据库上通常恒为零或不存在实例，可结合实例实际配置决定是否保留相关监控项； {$INSTANCE01}宏的语义边界：它指向的是SQL Server 性能计数器对象名（默认实例SQLServer，命名实例MSSQL$xxx），与实例发现模板中逐实例枚举的{#INSTANCES}宏机制不同——本模板是"固定单实例 + 按库展开"，发现的是数据库而非实例；- 版本兼容：5.0 的 XML 与 5.4/6.0 的 YAML 在实体上等价，若在 5.4+ 上导入旧版 XML 也通常可行，但推荐按版本选择对应格式文件以保留 uuid 等元数据（5.4/6.0 YAML 中每个实体都带
uuid字段，便于后续升级合并）。
总结
Template App MS SQL DB Discovery通过"一个 PowerShell 发现脚本 + 一个 LLD 规则 + 29 个计数器原型"的组合，把 SQL Server 数据库级性能监控做成了可复用的模板资产：发现规则负责按库展开，宏负责实例适配，触发器与图形原型负责告警与可视化。部署时只要补齐windowsdb.discovery脚本与@MS SQL System DBs全局正则两项外部依赖，即可在 Zabbix 5.0/5.4/6.0 上获得开箱即用的按库监控能力，是 Windows + SQL Server 环境运维监控的实用方案。
【免费下载链接】community-templates
Zabbix Community Templates repository
相关推荐
Zabbix 监控 Nginx Plus 实战：App Nginx Plus 模板的 API 采集与 LLD 低级别发现全解析
Zabbix 监控 Nginx Plus 实战：App Nginx Plus 模板的 API 采集与 LLD 低级别发现全解析 本指南以 Zabbix 官方社区
使用 Zabbix JMX 低级别发现（LLD）全面监控 Kafka 节点：App Kafka 社区模板深度解析
使用 Zabbix JMX 低级别发现（LLD）全面监控 Kafka 节点：App Kafka 社区模板深度解析 本文以 Zabbix Community Te
基于 Zabbix ODBC 低级别发现的 Veritas/Symantec Backup Exec Server 监控模板深度解析
基于 Zabbix ODBC 低级别发现的 Veritas/Symantec Backup Exec Server 监控模板深度解析 导读 本文围绕 commu
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
