服务器监控可以告诉我们数据库主机的 CPU、内存、磁盘和网络是否异常，却不能说明数据库内部是否还能正常提供服务。连接池可能耗尽，复制可能中断，锁等待可能持续，缓存命中率可能下降，备份可能失败，而操作系统指标仍然看起来正常。数据库监控必须进入实例内部，同时又要遵守最小权限、低开销和不影响业务的原则。

本文以 Zabbix 7.0 LTS 为主要范围，覆盖 MySQL、PostgreSQL、Redis 和 MongoDB 四类常见数据库。优先使用 Zabbix 官方模板和 Agent 2 插件，必要时才使用 ODBC、HTTP Agent 或自定义查询。官方 integrations 页面提供不同 Zabbix 版本对应的模板要求和已测试数据库版本，落地时必须选择与当前 Server 和模板分支匹配的版本，不能把 7.4 模板能力直接当作 7.0 环境的事实。

数据库监控至少覆盖六个维度：可用性、连接与并发、查询与吞吐、锁与等待、复制与高可用、容量与备份。操作系统资源是基础，但不能替代实例指标。

先定义数据库服务目标

数据库监控不能从“模板有多少 item”开始，而要从服务目标开始。核心交易数据库关注写入可用性、事务延迟、复制和数据安全；报表库关注长查询、资源隔离和批处理窗口；Redis 缓存关注命中率、内存淘汰和主从状态；MongoDB 集群关注副本集、WiredTiger、连接和分片状态。

数据库角色也会改变告警语义。MySQL 主库复制线程异常和从库复制线程异常影响不同；PostgreSQL 主库 WAL 堆积与只读副本延迟不同；Redis 主节点内存耗尽和只读副本延迟不同；MongoDB primary 切换和 secondary 短时落后也不同。模板、标签和严重级别应表达角色。

每个数据库对象至少应有 env、service、dbtype、role、cluster、team、criticality 等标签。这样告警可以路由到 DBA 或平台团队，Dashboard 可以按集群和业务聚合，维护窗口可以覆盖正确对象。

采集架构选择

Zabbix 数据库监控采集架构

数据库采集方式可以分四类。第一类是 Agent 2 插件，由数据库主机上的 Agent 2 连接本机或远程实例，适合 MySQL、PostgreSQL、Redis、MongoDB 等官方插件。第二类是传统 Agent 和 UserParameter，适合存量环境或官方模板要求命令行客户端的场景。第三类是 ODBC，由 Server 或 Proxy 通过驱动执行查询。第四类是 HTTP Agent，适合提供管理 API 或指标接口的数据库和中间件。

优先 Agent 2 的原因是插件和模板配合、支持命名会话、减少自定义脚本。官方 Agent 2 template operation 文档说明，插件支持命名会话时，可以为多个同类实例配置各自 URI、用户名和密码。这样一台主机运行多个数据库实例时，不需要复制多套脚本。

ODBC 适合不能安装 Agent 或需要从 Proxy 统一访问的数据库，但要管理驱动、DSN、网络和凭据。ODBC 查询运行在 Server 或 Proxy，慢查询会占用 poller 和数据库连接，必须限制 SQL 开销。HTTP Agent 也要控制响应体、超时和认证。

自定义 SQL 只用于官方模板未覆盖的业务指标。查询必须只读、带超时、使用索引、返回稳定单值或 JSON。不要让 Zabbix 执行全表扫描、复杂报表和修改语句。监控系统的查询不能成为数据库压力来源。

最小权限与凭据

数据库监控账号必须独立。不要复用应用账号、管理员账号或个人 DBA 账号。账号只获得读取状态、性能视图、复制状态和必要系统表的权限，不得写业务表、改配置、建用户或执行高风险管理命令。

凭据不应直接写在文章、模板导出、主机可见宏或脚本命令行中。优先放在 Agent 2 插件配置、Secret macro、受控配置文件或密钥管理系统。配置文件限制属主和权限，传输链路使用 TLS，数据库侧限制来源地址。

账号还要有生命周期。创建、轮换、失效、删除都要有责任人。轮换后应执行真实模板测试，确认所有会话都更新。多实例和集群环境不要假设一个账号能访问所有节点，尤其是故障切换后，新主节点可能缺少账号或权限。

MySQL 监控

MySQL 监控配置路径

Zabbix 7.0 官方 integrations 提供 MySQL by Zabbix agent、MySQL by ODBC 和 MySQL by Zabbix agent 2 等方案。Agent 2 模板不需要外部脚本，适合新环境。选择模板前要核对 Zabbix 版本、数据库版本和插件包。

MySQL 基础指标包括可用性、版本、运行时间、连接数、线程状态、QPS、事务、慢查询、临时表、表锁、InnoDB buffer pool、redo、行操作、复制状态和数据库大小。并不是所有指标都需要告警，很多指标用于趋势和排障。

连接数要看使用比例、活跃线程和连接拒绝。连接数接近上限可能来自业务增长、连接池过大、连接泄漏或慢查询堆积。只提高 max_connections 可能把问题转化为更大的内存压力。告警说明应引导检查连接来源和慢查询。

InnoDB 监控重点是 buffer pool、脏页、日志、行锁、事务和 I/O。缓存命中率下降不一定立即是故障，但与磁盘 I/O 和查询延迟同时变化时很有价值。长事务和锁等待会阻塞业务，应监控持续时间和数量。

复制监控要根据复制模式。传统异步复制关注 IO/SQL 线程、延迟、错误和 relay log；GTID 环境关注集合差异和故障切换；组复制或 InnoDB Cluster 需要额外监控成员状态和仲裁。模板能提供基础数据，但高可用产品的具体健康要结合产品接口和官方文档。

MySQL 监控账号权限必须按官方模板 README 配置。不同模板和版本需要的权限可能不同，不能复制旧文章里的固定 GRANT。落地时从对应 release 分支模板说明获取 SQL，并由 DBA 审核。

PostgreSQL 监控

PostgreSQL 监控分为数据库活动、后台进程、锁、WAL、复制、vacuum、表和数据库容量。官方 PostgreSQL integrations 页面显示，Zabbix 7.0 提供 Agent 2 插件模板，使用可加载插件运行 SQL；传统 Agent 模板则依赖 pg_isready、psql 和 UserParameter。新环境优先评估 Agent 2 方案。

PostgreSQL 10 及以上可以为监控用户授予 pg_monitor 角色，但仍应按官方模板要求和组织安全策略审查。监控账号通常不需要业务表写权限。若需要监控自定义数据库和 schema，额外 SELECT 权限应限制范围。

连接监控要区分 active、idle、idle in transaction、waiting。大量 idle in transaction 可能阻止 vacuum、持有锁和增加膨胀。连接总数接近上限时，要结合连接池、应用实例和长事务排查。

锁与等待是 PostgreSQL 关键指标。监控 blocked sessions、blocking session、deadlock 和长事务。触发器不应只看瞬时锁数量，而应看持续时间和影响。短锁是正常并发机制，长时间阻塞才需要处置。

WAL 和复制监控包括复制槽、WAL 生成、归档失败、流复制状态和 replay lag。废弃复制槽可能导致 WAL 长期保留，最终占满磁盘。复制延迟要按字节和时间理解，并结合业务读一致性要求设置阈值。

vacuum 和表膨胀需要趋势观察。自动 vacuum 没有及时处理、长事务阻止清理、表更新频繁都会产生膨胀。Zabbix 可以监控 dead tuples、vacuum 时间和数据库大小，但复杂表级分析可以由 DBA 工具补充。

Redis 监控

PostgreSQL、Redis 与 MongoDB 监控差异

官方 Redis by Zabbix agent 2 模板不需要外部脚本，7.0 分支支持多种 Redis 版本。Redis 监控重点与关系数据库不同：内存、命中率、淘汰、连接、阻塞、持久化、复制和集群状态更重要。

内存监控不能只看 used_memory。要结合 maxmemory、RSS、碎片率、allocator、峰值和淘汰策略。接近 maxmemory 时，行为取决于策略：可能淘汰 key，也可能拒绝写入。告警必须说明当前策略和业务影响。

命中率下降可能表示缓存失效、key 设计变化、业务流量变化或内存淘汰。它不是单独的故障结论，应与 evicted_keys、expired_keys、QPS、延迟和后端数据库压力结合。缓存穿透或大规模失效时，Redis 自身可能正常，但后端数据库会受到冲击。

持久化监控包括 RDB 最后保存、AOF 重写、失败、fork 和磁盘空间。如果 Redis 仅作为可重建缓存，持久化失败严重级别可以较低；如果承担数据存储，持久化和复制失败必须高优先级。角色和业务定义决定阈值。

复制和集群监控包括主从连接、复制偏移、延迟、主节点状态、cluster_state、slot 和 failover。单节点 ping 成功不代表集群健康。集群模板和节点模板要正确关联，并避免同一问题重复通知。

MongoDB 监控

Zabbix 7.0 提供 MongoDB node by Zabbix agent 2 和 MongoDB cluster by Zabbix agent 2。官方页面说明节点模板通过 Agent 2 采集，很多指标一次批量获取；集群模板从 mongos 获取分片集群信息。

MongoDB 节点监控包括连接、操作计数、队列、缓存、WiredTiger、锁、游标、网络和断言。WiredTiger read/write tickets 低会导致新请求排队，是重要压力信号。连接和游标异常也可能指向应用连接管理问题。

副本集监控关注 primary、secondary、节点健康、状态变化、复制延迟和选举。节点角色切换可能是正常故障转移，也可能伴随可用性影响。状态变化触发器应与业务可用探针和持续时间结合。

分片集群还要监控 mongos、config server、shard 状态、chunk 分布和平衡。Zabbix 官方模板提供基础集群信息，但热点 shard、慢查询和 schema 设计问题仍需要 MongoDB 专用分析工具。

监控账号权限按官方模板 README 配置。连接字符串、用户名和密码可以使用模板宏或 Agent 2 named session，但敏感宏必须受保护。副本集和 TLS 环境要验证连接参数、CA 和主机名。

触发器设计

数据库触发器策略

数据库触发器可以分成五类。第一类是可用性：实例不可连接、角色异常、集群不可用。第二类是数据安全：复制中断、持久化失败、备份失败、WAL 或日志空间风险。第三类是并发：连接耗尽、锁等待、长事务。第四类是性能：查询延迟、队列、缓存、I/O。第五类是容量：数据、日志、表空间、内存和磁盘增长。

可用性和数据安全通常优先级高，性能和容量更需要持续窗口。数据库瞬时负载高很常见，单点值容易误报。触发器应使用五分钟或更长窗口，并根据业务峰值调整。复制延迟阈值也要结合 RPO、读写分离和故障切换要求。

根因和症状要建立依赖。数据库主机不可达时，数据库连接失败是症状；主库不可用时，从库延迟和应用查询失败可能是症状；区域 Proxy 故障时，多实例无数据是症状。依赖和事件关联可以减少告警风暴。

数据库告警必须带上下文：实例、集群、角色、当前值、阈值、持续时间、业务系统、负责人和第一步检查。只发“连接数过高”不足以行动。

备份与恢复

数据库监控不能忽略备份。至少监控最后成功时间、最后失败时间、备份大小、持续时间、目标存储空间、校验和恢复演练。复制不是备份，高可用也不能替代备份。

备份状态可以来自备份系统 API、日志、数据库备份工具或 sender。监控查询不应读取备份文件内容，只需要稳定状态。备份大小突然下降可能表示漏表或任务异常，持续时间突然变化可能表示数据增长或存储性能问题。

恢复演练结果应进入监控或治理记录。核心数据库超过规定周期未完成恢复测试时提醒负责人。只有实际恢复成功，才能证明备份可用。

Dashboard

数据库 Dashboard 建议按集群和角色组织。顶部显示实例可用性、复制、连接、锁、备份和容量问题；中部显示吞吐、延迟、缓存和 I/O；底部显示长期容量和最近事件。不要把不同数据库类型和量纲全部放进一张图。

MySQL 页面重点是连接、QPS/TPS、InnoDB、慢查询和复制；PostgreSQL 页面重点是会话、锁、WAL、复制和 vacuum；Redis 页面重点是内存、命中率、淘汰、持久化和集群；MongoDB 页面重点是副本集、WiredTiger、连接和分片。

验证与故障注入

数据库监控排障路径

数据库监控上线后要验证采集、权限、触发器和恢复。先用数据库客户端或 Agent 2 test key 验证监控账号，再检查 Zabbix latest data。确认插件连接、模板宏、命名会话、TLS 和数据库角色。

测试环境可以停止一个副本、阻断监控账号、降低测试阈值、创建短时锁等待或暂停备份任务，验证 Problem 和 Recovery。不要在生产核心数据库随意制造长锁、磁盘耗尽或复制中断。生产可通过维护窗口、测试实例和只读模拟验证。

排障时按链路走：Agent 或 Proxy 是否正常；数据库端口是否可达；监控账号是否能登录；模板和插件版本是否匹配；宏和会话是否正确；SQL 是否超时；预处理是否失败；item 是否 unsupported。不要在没有证据时直接提高权限或改数据库参数。

性能开销控制

数据库监控查询本身必须被监控。查询频率、超时和返回数据量要受控。高频全表统计、遍历所有表、复杂锁图和大 JSON 会给数据库和 Zabbix 都带来压力。尽量使用性能视图和一次采集多个指标的 master item。

表级和库级 LLD 需要过滤。大型实例可能有成千上万张表，如果全部生成 item 和 trigger，Zabbix 会迅速膨胀。只发现关键数据库、表空间、复制槽和业务对象，其他信息按需查询。

常见反模式

第一，使用管理员账号监控。第二，把密码写入普通宏或脚本命令行。第三，为每个指标执行一次 SQL，造成连接和查询压力。第四，只监控进程存活。第五，把所有慢查询和锁都发高优先级告警。第六，只监控复制，不监控备份。第七，模板升级后不验证插件兼容。

还有一种反模式是统一阈值。不同数据库、角色、业务和容量的正常范围不同。阈值要通过宏、历史基线和 DBA 评审设置。监控平台不能替代数据库专业判断，但能持续提供证据。

交付清单

数据库纳管记录至少包括数据库类型和版本、实例和集群、角色、监控方式、Agent 或 Proxy、插件和模板版本、监控账号、权限说明、凭据存储、宏、关键指标、触发器、备份、Dashboard、维护窗口、验收结果、DBA 和业务负责人。

每季度复审账号权限、模板版本、插件版本、失效实例、复制拓扑、备份策略、阈值、unsupported item 和高开销查询。数据库升级、主从切换、集群扩缩容和迁移后必须提前复审。

一个落地案例

假设生产订单系统使用一主两从 MySQL。三台主机都有 Linux 基线，数据库使用 MySQL by Zabbix agent 2。标签区分 primary 和 replica，模板宏配置连接会话和阈值。主库监控写入、事务、锁和日志，从库监控复制线程、延迟和只读状态。

集群级业务探针从应用区域执行只读查询，验证真实访问路径。主库不可用是 Disaster；单从库复制中断是 High 或 Average；复制延迟根据读一致性要求设置；连接和缓冲池进入性能视图；备份失败单独高优先级通知。

上线时验证监控账号、插件、复制指标、备份状态、Problem/Recovery 和告警路由。维护窗口内做一次受控从库停止测试，确认依赖和恢复。交付记录注明故障切换后监控账号和主机角色如何更新。

指标口径治理

数据库指标经常出现“名称相同、含义不同”。连接数可能是当前连接、活跃连接、会话、客户端数或连接使用率；延迟可能是 SQL 执行时间、复制时间差、WAL 字节差、网络延迟或业务接口延迟；缓存命中率也可能是 buffer pool、shared buffers、keyspace 或操作系统页缓存。模板说明和 Dashboard 必须写清口径。

单位也要统一。字节、页、块、毫秒、秒、每秒变化率和累计计数器不能混用。累计值需要预处理成速率或变化量，复制延迟要注明时间还是字节，数据库大小要注明逻辑大小还是实际磁盘占用。错误单位会导致触发器和容量预测完全失真。

指标命名建议包含数据库类型、实例和语义，例如“订单主库当前连接使用率”“订单从库 replay lag bytes”“Redis 主节点 evicted keys rate”。不要只写“连接数”“延迟”“缓存命中”，尤其是在一个 Dashboard 展示多个数据库时。

MySQL 指标深度

MySQL 连接监控包括 Threads_connected、Threads_running、Connections、Aborted_connects 和最大连接。Threads_connected 高但 Threads_running 低，可能只是连接池保留连接；两者都高并伴随延迟，才更像并发压力。Aborted_connects 增长可能与认证、网络或连接配置有关。

吞吐指标包括 Questions、Queries、Com_select、Com_insert、Com_update、Com_delete 和事务提交回滚。它们用于建立业务基线，不适合全部告警。吞吐下降可能是业务流量下降，也可能是数据库异常，需要结合应用请求和错误率。

慢查询数量只是线索。慢查询阈值由数据库配置决定，数量增加可能来自业务高峰、执行计划变化、锁等待、统计信息、缓存冷启动或存储压力。Zabbix 适合发现趋势，不负责保存完整 SQL 和执行计划。详细分析应进入 slow log、performance_schema 和数据库诊断工具。

InnoDB buffer pool 指标需要结合工作集。buffer pool 使用率高通常正常，关键是命中率、读请求、物理读、脏页、刷新和等待。突然增加的物理读可能表示缓存失效或工作集扩大。日志等待和 checkpoint 压力可能影响写入延迟。

锁监控包括行锁等待、等待时间、死锁和长事务。死锁会被数据库检测并回滚一个事务，偶发并不一定严重，频繁发生才需要应用和 SQL 治理。长事务更危险，它可能持有锁、阻止清理并扩大日志。触发器应关注持续时间和业务影响。

复制监控不能只看一个 Seconds Behind。该值可能为 NULL、0 或不准确，具体取决于复制状态。应同时看 IO/SQL 线程、Last_IO_Error、Last_SQL_Error、GTID、relay log、复制队列和只读状态。发生故障切换时，角色标签和 Dashboard 必须更新。

PostgreSQL 指标深度

PostgreSQL 会话状态里，active 表示正在执行，idle 表示等待客户端，idle in transaction 表示事务打开但没有执行。后者持续过长会持有快照和锁，阻止 vacuum。监控应该关注持续时间而不是简单数量。

数据库吞吐可以通过 commits、rollbacks、blocks read/hit、tuples returned/fetched/inserted/updated/deleted 等建立基线。cache hit ratio 下降可能表示工作集、查询模式或 shared_buffers 变化，但不能单独决定扩容。还要结合磁盘读、查询延迟和表大小。

锁监控需要识别阻塞链。一个被阻塞会话可能不是根因，真正根因是最上游持锁事务。Zabbix 可以监控阻塞数量和最长等待，告警说明中提示 DBA 查询 blocking PID 和事务。不要让监控账号自动终止会话。

WAL 监控包括生成速率、归档状态、复制槽 retained WAL、sender/receiver 状态和 replay lag。废弃逻辑复制槽或物理复制槽会让 WAL 无法回收，可能快速耗尽磁盘。触发器应关注 retained bytes 和目录空间。

autovacuum 监控要关注 last vacuum/analyze、dead tuples、freeze age 和事务 ID 风险。单个表 dead tuples 多不一定立即故障，但持续增长且 vacuum 不运行会造成膨胀和性能下降。对大表和高更新表，可以建立专门角色模板。

复制延迟可用字节差和时间差表达。字节差更直接反映 WAL 堆积，时间差受事务活动影响。只读业务要求秒级一致时阈值严格，灾备副本允许更长延迟。阈值必须来自业务要求。

Redis 指标深度

Redis 的内存指标包括 used_memory、used_memory_rss、maxmemory、mem_fragmentation_ratio 和 allocator 信息。RSS 明显高于逻辑内存可能是碎片、fork 或内存释放行为。碎片率不是越接近 1 越绝对健康，需要结合实例大小和操作系统看。

evicted_keys 增长说明 maxmemory 策略正在淘汰；expired_keys 增长可能是正常过期；keyspace_hits 和 misses 用于计算命中率。命中率下降时，要看是否有冷启动、业务模式变化、缓存穿透或大批 key 过期。

blocked_clients、instantaneous_ops_per_sec、rejected_connections 和 latency 是关键运行指标。阻塞客户端可能来自阻塞命令或资源压力，拒绝连接可能是 maxclients 或文件描述符问题。高 QPS 本身不是故障，只有伴随延迟、阻塞和错误才需要告警。

RDB 和 AOF 监控要看最后成功、正在进行、失败、fork 时间、重写和磁盘空间。fork 在大内存实例上可能造成延迟。持久化策略不同，告警严重级别不同。纯缓存实例可以接受数据重建，数据型 Redis 则必须保障持久化和复制。

复制监控包括 role、master_link_status、master_last_io_seconds_ago、repl_backlog、offset 和 replica 数。Sentinel 和 Cluster 还要监控选主、quorum、slot 和 cluster_state。单节点 INFO 正常不代表整个集群可用。

大 key、热 key 和慢命令不适合由 Zabbix 高频扫描。它们需要专门工具和受控操作。Zabbix 可以监控已由诊断任务产出的数量或状态，避免监控本身执行重操作。

MongoDB 指标深度

MongoDB 连接和操作指标包括 current/available connections、opcounters、network bytes、asserts 和 cursors。连接接近上限需要结合应用连接池和慢操作。游标超时率或打开游标持续增加，可能说明客户端没有正确关闭或查询模式变化。

WiredTiger cache 是性能核心。监控 cache bytes、dirty bytes、pages read/written、eviction 和 tickets。可用 read/write tickets 降到很低时，新请求会排队。触发器应使用持续窗口，并结合操作延迟和队列。

副本集指标包括成员状态、health、optime、lag 和选举。primary 变化需要记录和确认，短时选举可能自动恢复，但业务连接字符串、read preference 和 write concern 决定影响。监控消息应包含副本集和节点角色。

分片集群监控要看 mongos、config server 和 shard。chunk 分布不均、balancer 异常和热点 shard 可能造成局部压力。Zabbix 适合监控状态和趋势，分片设计和查询路由仍需 MongoDB 专业工具。

高可用与故障切换

高可用数据库监控必须覆盖“切换后仍能监控”。很多系统平时所有节点都有数据，切换后新主节点监控账号、网络 ACL、插件会话或标签不正确，正需要监控时反而失效。故障演练要把监控验证纳入。

切换前记录主从角色、复制状态、监控账号和主机标签。切换后验证新主可用、旧主角色、复制重新建立、业务探针、备份任务和告警恢复。Zabbix 主机对象可以保持节点身份，角色通过 item 和标签表达；如果自动化更新标签，要保证幂等。

集群级告警和节点级告警要分开。单节点故障可能由高可用吸收，集群仍可服务；集群无主、仲裁不足或业务探针失败才是服务级灾难。节点告警帮助修复冗余，集群告警驱动业务响应。

锁、慢查询与应用协同

数据库性能问题往往需要应用团队参与。慢 SQL、连接泄漏、长事务、批量更新和错误重试都可能来自应用。Zabbix 告警应包含业务系统和负责人，不应只发给 DBA。DBA 解决资源问题，应用团队修复调用模式。

锁告警要提供持续时间、阻塞数量和实例，但不要在消息里泄露完整 SQL 或业务数据。可以提供到安全诊断页面的链接。对生产数据库自动杀会话风险很高，不应由 Zabbix 动作直接执行。

慢查询告警可以采用聚合方式，例如慢查询率持续增加、最长执行时间超过基线、活跃会话堆积。完整 SQL 进入日志或 APM。这样监控系统保留趋势，诊断系统保留细节。

容量管理

数据库容量不只是数据文件。还包括 redo/WAL、binlog、relay log、临时文件、表空间、索引、备份、归档和复制槽。磁盘满会直接影响写入和恢复，因此容量视图要按目录和用途拆分。

容量预测要结合增长速度和处理周期。云盘扩容快，传统存储或专线采购慢；分区表清理可能需要变更窗口；归档可能受合规保留影响。阈值要给出足够准备时间。

数据库大小的采集频率可以较低，按小时或每天足够。大型实例频繁统计所有表大小会消耗资源。优先数据库级、表空间级，关键大表由低频任务生成结果。

监控账号权限复核

权限复核不能只在首次创建。数据库升级、模板升级、插件变化和高可用切换都可能改变所需权限。每季度检查账号是否仍存在、来源限制是否正确、是否意外获得写权限、密码是否轮换、闲置实例账号是否删除。

如果模板开始出现权限错误，不要直接授予更高权限。先查看对应版本官方模板 README，确认具体查询和所需视图，再由 DBA 审批最小权限。监控账号权限扩大应有变更记录。

上线验收矩阵

每种数据库都应验证五类场景。可用性：正常连接、错误凭据、端口不可达。性能：指标有值、单位正确、采集频率合理。高可用：副本或节点状态、角色变化、复制延迟。安全：账号最小权限、凭据受保护、TLS。闭环：Problem、Recovery、告警路由、维护窗口和 Dashboard。

验收不能只看“Save & Test”。至少观察一个业务高峰和一个备份周期。复制延迟、锁、持久化和备份往往在特定时间才出现。低频任务需要专门安排验证。

故障案例

案例一：MySQL 连接数持续高。监控显示连接使用率接近上限，但 Threads_running 很低。最终发现应用连接池配置过大并长期保留空闲连接。处理不是直接提高 max_connections，而是调整连接池、分批重启应用，并继续观察内存。

案例二：PostgreSQL 磁盘增长。主机磁盘持续增加，数据库大小变化不大。检查发现废弃复制槽保留大量 WAL。通过复制槽和 WAL 监控定位，确认下游已废弃后按流程删除槽，并补充槽新鲜度告警。

案例三：Redis 命中率下降。命中率下降并伴随 evicted_keys 增长，后端数据库压力上升。根因是业务数据增长超过 maxmemory，且淘汰策略不适合。处理包括扩容、调整策略和修复 key 生命周期。

案例四：MongoDB 应用延迟。节点在线、连接正常，但 WiredTiger write tickets 长期低，写请求排队。通过 tickets、缓存和操作延迟确认压力，进一步由 DBA 分析写模式和存储。

数据库变更联动

数据库变更必须同步监控。版本升级可能改变系统视图、字段和插件兼容；主从切换会改变角色和复制方向；扩容会改变容量基线；新增实例要更新模板会话、标签和 Dashboard；删除实例要回收账号和监控对象。

变更前应记录当前最新数据、复制状态、监控账号、模板和告警状态，并创建维护窗口。变更中观察实例可用、复制、连接、错误和业务探针。变更后确认 Agent 2 插件仍能连接、所有 item 支持、角色标签正确、备份任务指向新拓扑、Problem 已恢复。

数据库参数调整也会影响监控口径。例如 max_connections、maxmemory、shared_buffers、WiredTiger cache、慢查询阈值变化后，触发器宏和 Dashboard 阈值可能需要同步。不要让数据库配置已改变而监控仍按旧基线判断。

恢复演练

数据库恢复演练是监控验收的一部分。演练不要求 Zabbix 执行恢复，而是要求 Zabbix 能观察演练过程：备份是否存在、恢复是否开始、持续时间、恢复是否成功、恢复后实例是否可连接、数据校验是否通过。

核心数据库可以把最近一次恢复演练日期和结果上报为低频 item。超过组织规定周期未演练时提醒负责人。这样备份、恢复和监控形成闭环，不会出现备份任务长期显示成功却从未证明可恢复。

高可用演练也要验证告警质量。停止一个测试副本时，应产生节点级告警但集群服务仍正常；切换 primary 时，应记录角色变化和短时影响；集群失去仲裁时，才触发服务级高优先级事件。演练后复盘重复告警和缺失上下文。

交付记录与复审

数据库监控交付记录应包含官方模板来源和 release 分支、插件包、数据库已测试版本、监控账号 SQL 审批、凭据存储位置、连接 URI、TLS、模板宏、实例角色、复制拓扑、备份来源、业务探针和故障演练结果。

记录中还要区分“已现场验证”和“需按官方文档复核”。文章里的示例不等于现场结果，真实环境的数据库版本、发行版、插件包、权限和网络都可能不同。只有实际连接、latest data、故障测试和恢复通过，才能标记为已验证。

季度复审时，DBA、平台团队和业务负责人共同检查。DBA确认指标和权限，平台团队确认模板、插件和告警，业务负责人确认影响和处置时限。监控不是 DBA 单方任务，也不是平台单方任务。复审结论应写入变更记录，明确失效指标、阈值调整、账号整改和下一次验证日期，并保留相关验收证据、整改责任人、完成日期和最终复核结论记录归档备查清单明细表格文档记录。

小结

数据库监控的关键是把实例内部状态、操作系统资源、复制、高可用、备份和业务探针连成一条证据链。官方模板和 Agent 2 插件降低了接入成本，但最小权限、角色语义、阈值、性能开销和验收仍需团队设计。

下一篇进入分布式监控架构，解决多区域、多安全区和大规模对象如何通过 Proxy 接入中心 Server，并在链路中断时缓存数据。

参考资料