PHP小码农

Appearance

Zabbix 监控 ​

Prometheus 体系是云原生时代的事实标准，但大量企业（尤其金融、制造、传统 IT）的监控中枢早已是 Zabbix：统一的设备/应用纳管、成熟的告警升级机制、完善的用户与权限体系。对这类企业，PostgreSQL 的正确接入方式不是另起炉灶，而是用 Zabbix 官方的 PostgreSQL 模板把数据库纳入既有监控版图——告警进企业统一的值班流程，报表进统一的运营视图。

Zabbix 对 PostgreSQL 的支持走的是新一代 Agent 2 + Go 插件路线：Zabbix agent 2 内置 PostgreSQL 插件，直接以 SQL 访问数据库采集指标；配套官方模板「PostgreSQL by Zabbix agent 2」提供开箱即用的监控项、自动发现（LLD）与触发器。本页讲清这套方案的架构、配置、监控项体系、LLD 机制与告警设计，并与上一页的 Prometheus 方案做正面对比，帮你做出适配自己组织的选择。

前置知识

建议先阅读：Prometheus + Grafana 监控

基础概念 ​

Zabbix 架构速览（数据库监控视角） ​

text
┌──────────────┐    zabbix_agent2（Go，含 PostgreSQL 插件）   ┌───────────────┐
│  PostgreSQL  │◄──── 直接执行 SQL（pgsql.* 监控项）──────────│  Zabbix Server │
│  （数据库）    │                                            │  （采集与评估）  │
└──────────────┘                                            └───────┬───────┘
                                                                    │ Web/API
                                                             ┌──────▼──────┐
                                                             │ Zabbix Frontend │
                                                             │ （模板/触发器/告警）│
                                                             └─────────────┘
组件职责数据库监控中的角色
Zabbix agent 2部署在数据库主机，Go 插件直连数据库执行采集 SQL探针（等价 exporter 的角色）
Zabbix server接收采集值、评估触发器、存储历史指标存储与告警引擎
Frontend / API模板管理、看板、告警配置运维入口
Proxy（可选）分布式场景下代理采集多机房部署的中继

与 Prometheus 的第一直觉差异：Zabbix 的采集是 server 主动向 agent 要数据（被动检查为主），agent 与 server 之间走 Zabbix 私有协议；而 Prometheus 是 server 去 exporter 的 HTTP 端点「拉」。对监控结果的语义差别不大，对网络拓扑的要求差别不小——多机房、跨防火墙场景 Zabbix proxy 体系很成熟。

Agent 2 与 PostgreSQL 插件 ​

Zabbix agent 2 是 Zabbix 5.0 起引入的 Go 语言新代 agent，支持插件化扩展；PostgreSQL 插件是官方内置插件，在 Zabbix 6.0 起配套官方模板成熟可用。它的核心设计：

  • 插件在 agent2 进程内维护与 PostgreSQL 的连接（可复用），按监控项定义的 SQL 采集指标；
  • 连接目标由 URI 表达（如 tcp://localhost:5432），凭据走模板宏或 agent 配置；
  • 监控项键名以 pgsql. 前缀命名（如连接数、缓存命中、复制延迟等，具体键名清单以官方插件文档为准）。

官方模板一览 ​

Zabbix 官方模板库（Git 仓库 zabbix/zabbix 与官网 Templates 页）中与 PostgreSQL 相关的主模板：

模板采集方式适用
PostgreSQL by Zabbix agent 2agent2 插件直连数据库主流选择，本页主线
PostgreSQL by ODBCODBC 数据源无法安装 agent 的场景
PostgreSQL by Zabbix agent 2（多实例变体）命名会话单机多实例

选型几乎总是第一个：agent2 插件方式部署最简、覆盖最全。ODBC 变体依赖 unixODBC 与驱动配置，仅作特殊场景备选。

与 Prometheus 方案的定位对比 ​

维度Zabbix（agent2 插件）Prometheus + Grafana
指标模型监控项（item）为主键的数值/文本标签化时序
告警触发器（Trigger）+ 升级动作（Action/escalation）告警规则 + Alertmanager
生态企业监控传统强项：设备、网络、主机、中间件统一纳管云原生、容器、微服务生态
自定义扩展自定义监控项（UserParameter）+ SQL任意自定义查询文件
展示内置看板（可配 Grafana 读写 Zabbix 数据源）Grafana 原生主场
团队成本需 Zabbix 运维技能需 Prometheus/Grafana 运维技能

一句话总结：组织已有 Zabbix 就接入 Zabbix，云原生绿地项目选 Prometheus。两者也可以共存——Grafana 有 Zabbix 数据源插件，Zabbix 的指标可以直接画进 Grafana 看板。

语法与用法 ​

准备监控账号 ​

与 Prometheus 一致，最小权限是铁律。Zabbix 官方模板文档对权限的指引与 PostgreSQL 的角色体系对应如下：

sql
-- 创建监控账号
CREATE ROLE zbx_monitor WITH LOGIN PASSWORD '强口令';

-- 授予 pg_monitor（它已聚合了 pg_read_all_settings、
-- pg_read_all_stats、pg_stat_scan_tables 三个内置角色，
-- 覆盖模板所需的全部统计视图读取权限）
GRANT pg_monitor TO zbx_monitor;

-- 允许连接业务库（模板的数据库级监控项需要）
GRANT CONNECT ON DATABASE appdb TO zbx_monitor;

pg_monitor 聚合的三个角色各司其职：pg_read_all_settings（读配置）、pg_read_all_stats（读全部统计）、pg_stat_scan_tables（执行统计类扫描函数）。日常排障若个别监控项仍报权限错误，先用同一账号在 psql 里复现该查询，定位缺失的具体权限再补充，不要图省事直接升级为 superuser。

conf
# pg_hba.conf：限定 agent 主机
host  all  zbx_monitor  10.0.8.10/32  scram-sha-256

安装 agent 2 并配置插件 ​

bash
# 安装（官方仓库，以 RHEL 系为例）
dnf install zabbix-agent2

# 启用并启动
systemctl enable --now zabbix-agent2
conf
# zabbix_agent2.conf —— PostgreSQL 插件配置（示意，参数名以官方文档为准）

# 数据库连接 URI（插件级默认值）
Plugins.PostgreSQL.Uri=tcp://localhost:5432

# 或使用命名会话（多实例场景）
# Plugins.PostgreSQL.Sessions.primary.Uri=tcp://localhost:5432

Server=10.0.8.1            # Zabbix server/proxy 地址
ServerActive=10.0.8.1
Hostname=pg-primary-01
bash
# 验证 agent 与插件的连通性（在 agent 主机用 zabbix_agent2 自测）
zabbix_agent2 -t pgsql.uptime
# 输出类似：pgsql.uptime [s|123456]  → 插件已能访问数据库

凭据的传递方式有两种：模板宏（{$PG.USER} / {$PG.PASSWORD}，配置在 Zabbix 前端）或 agent 配置。优先模板宏——凭据集中在 Zabbix 侧管理，agent 配置文件里不留口令；若组织要求口令不落前端，则用 agent 配置的会话级凭据并纳入密钥管理。宏与配置的确切命名以所用 Zabbix 版本的模板说明为准。

挂接官方模板 ​

text
Zabbix Frontend：
1. Data collection → Hosts → Create host
   Host name: pg-primary-01
   Groups: PostgreSQL servers / Production
   Interfaces: Agent 10.0.1.12:10050
2. Templates 标签 → 添加「PostgreSQL by Zabbix agent 2」
3. 模板宏（该 host 层覆盖）：
   {$PG.URI}      = tcp://localhost:5432
   {$PG.USER}     = zbx_monitor
   {$PG.PASSWORD} = ***
   {$PG.DATABASE} = appdb（模板默认连 postgres 库做基础采集）
4. 保存后等待第一轮采集，Latest data 里应出现 pgsql.* 监控项

宏在 Zabbix 里有继承链（全局 → 模板 → 主机），生产实践建议：模板层留默认、主机层覆盖真实值——同一模板挂多台主机时互不干扰。

核心监控项体系 ​

官方模板的监控项覆盖（键名以官方插件文档为准，此处按语义归类）：

类别典型监控项对应内核来源
可用性实例存活、运行时长pg_isready / pg_postmaster_start_time
连接连接数、按状态分布、使用率pg_stat_activity
性能事务速率、块命中/读、缓存命中率pg_stat_database
锁锁数量、等待锁的会话pg_locks / pg_stat_activity
WAL 与归档WAL 数量/速率、归档成功/失败pg_stat_wal / pg_stat_archiver
复制延迟（字节/时长）、备库状态、回放年龄pg_stat_replication
数据库各库大小、连接分布pg_database / LLD 发现
检查点bgwriter/checkpointer 活动pg_stat_bgwriter（版本相关）

两个使用要点：其一，模板监控项采集频率大多为 1m~15m 级，比 Prometheus 的 15s 粗——这是 Zabbix 体系对历史数据存储成本的通用权衡，需要更细分辨率的关键指标单独调整 item 的 Update interval；其二，模板自带「主库/备库」语义的监控项依赖配置正确（如复制类监控项只应在主库采集），多角色环境用模板的条件过滤或宏控制。

采集语义与预处理（Preprocessing） ​

Zabbix 监控项在「采集原始值」与「入库」之间有一个预处理管道（Preprocessing pipeline），理解它才能看懂模板里很多指标的语义来源：

text
监控项数据流：

  agent2 插件执行 SQL → 原始值（如 pg_stat_database 的累计事务数）
       → Preprocessing 步骤链
            ① 原始值校验/类型转换
            ② 差分/速率计算（累计计数器 → 每秒速率）
            ③ 单位换算、自定义脚本
       → 入库（History/Trends）
       → 触发器基于入库后的值评估

这解释了一个新手常见困惑：为什么模板里「事务速率」监控项查的是累计值视图却画出了速率曲线——速率是在预处理步骤里用相邻两次采集的差分算出来的。由此带来两个推论：其一，累计型指标直接看原始值没有意义（单调递增），看板要用模板派生好的速率项；其二，速率类指标在 agent 或数据库重启后会出现一次跳变（计数器归零），模板通常有处理，自定义监控项套用同样模式时要自己考虑。

自定义监控项做速率的三种姿势：让 SQL 直接返回速率（自己算差分，需要状态，不推荐）；返回累计值 + 在监控项上配置差分预处理步骤（模板的标准做法）；触发器层面用 Zabbix 表达式的时间聚合函数计算（适合低频告警场景）。第一种把状态带进 SQL 不可取，后两种按「是否需要在看板上显示」来选——要显示走预处理，只为告警走表达式。

LLD：数据库自动发现 ​

模板内置低级发现（LLD），自动发现实例中的数据库并按需创建监控项：

text
发现规则（示意）：
  Database discovery → 遍历 pg_database（排除 template0/template1）
  → 按过滤宏 {$PG.LLD.FILTER_DATABASE} 筛选
  → 为每个命中的数据库创建：
      数据库大小、连接数等 per-database 监控项

LLD 的运维意义：新库上线自动纳入监控，不用改模板。注意两点：发现过滤宏务必配置（否则几百个临时库会全部纳管，产生海量监控项）；per-database 监控项的采集间隔适当放宽（库级大小变化本来就是小时级）。LLD 的具体规则名与宏名以官方模板版本为准，升级模板时留意发现规则的变更记录。

详细说明 ​

触发器体系与告警分级 ​

Zabbix 的告警三件套：触发器（Trigger，定义异常条件）、动作（Action，定义通知与升级）、维护期（Maintenance，压制误报）。官方模板自带一组触发器，语义按严重度分级（Zabbix 的 severity：Not classified → Info → Warning → Average → High → Disaster）：

text
模板自带触发器语义（示意，具体表达式以模板为准）：
  PostgreSQL: service is down            → High（进程/端口不可达）
  PostgreSQL: too many connections       → Average（连接率超阈值）
  PostgreSQL: replication lag too high   → Average/High
  PostgreSQL: archive failed             → Warning/Average（归档失败）
  PostgreSQL: cache hit ratio low        → Warning
  PostgreSQL: WAL segments too many      → Average（WAL 堆积）

触发器设计：从模板到自定义 ​

模板触发器覆盖通用场景，业务特有的阈值走自定义触发器。表达式语言示例（Zabbix 5.4+ 新语法）：

text
# 连接率告警（示意表达式）
last(/PostgreSQL by Zabbix agent 2/pgsql.connections[...]) / max_connections > 0.8

# 长事务（结合自定义监控项）
max(/PostgreSQL by Zabbix agent 2/pgsql.custom.long_tx_age, #3) > 3600

# 复制延迟字节
last(/PostgreSQL by Zabbix agent 2/pgsql.replication.lag[...]) > 104857600

自定义触发器的四条纪律：阈值来源可追溯（写明依据：SLO 推导还是历史基线）；多周期确认（用 max/min/avg + 周期参数过滤毛刺，等价 Prometheus 的 for）；severity 对齐企业标准（critical 打电话那套映射到 Zabbix 的 High/Disaster）；恢复通知配置（告警恢复也要通知，值班需要闭环信号）。

触发器依赖与告警风暴治理 ​

数据库故障往往引发连锁告警：主库宕机时，复制延迟、连接失败、归档失败、备份失败的告警会同时炸群。Zabbix 用触发器依赖（Trigger dependencies）治理这类风暴——被依赖的触发器处于 Problem 状态时，依赖它的触发器不再重复通知：

text
依赖链示例（数据库场景的典型画法）：

  PostgreSQL: service is down（主库）
      ▲ 依赖
      ├── 复制延迟类触发器（主库不可达时延迟必然异常）
      ├── 连接类触发器（实例挂了连接必然失败）
      └── 归档类触发器（实例挂了归档必然失败）

  主库宕机 → 只有 service down 一个告警进值班流程
  其余派生异常静默记录，恢复后自动收敛

官方模板已经内置了部分依赖关系，自定义触发器时要主动挂进依赖树。两条经验法则：因果关系的下游触发器都挂依赖（延迟告警依赖实例存活、锁等待告警依赖实例存活）；依赖只做因果，不做时间（「A 之后 B 才告警」这类时序逻辑用 Action 的条件与升级步骤表达，依赖树表达不了时间）。没有依赖树的告警体系，在大事故夜里最大的危害不是漏报而是噪音淹没——值班在几十条重复告警里找不到真正的根因。

维护期（Maintenance）与变更窗口 ​

版本升级、主备切换演练、批量索引重建、硬件更换——这些计划内操作必然触发一批触发器。Zabbix 的维护期机制让你提前声明「这段时间的告警是预期的」：

text
维护期配置要点：
  1. Data collection → Maintenance → Create maintenance period
  2. 定义时间窗口（一次性/每日/每周周期）
  3. 关联主机或主机组（如 "PostgreSQL servers"）
  4. 两个数据采集选项：
     - No data collection：维护期间完全停止采集
     - Continue collecting：继续采集但不评估触发器（推荐）
       ——维护期间的数据在事后复盘仍有价值
text
配合变更管理的实践：
  变更单号 → 创建维护期（名字带上单号）
  → 变更执行 → 观察期结束 → 维护期自动过期
  → Frontend 的 Problem 页面不会出现本次变更的噪音

两个易错点：维护期忘记设过期时间是最常见的「监控盲区事故」——维护期挂了三天没人删，期间真故障全部静默，所以维护期必须有明确的结束时间；另一个是维护期粒度——按主机组建维护期会把组内所有数据库一起静默，单机变更应该只建在变更的那台 host 上。

自定义监控项：模板之外的一切 ​

与 exporter 的 queries.yaml 对应，Zabbix 的扩展路径是自定义监控项（UserParameter）或 agent2 插件的自定义查询能力：

conf
# zabbix_agent2.conf —— UserParameter 示意
UserParameter=pgsql.custom.long_tx,psql -U zbx_monitor -d appdb -Atc \
  "SELECT coalesce(max(extract(epoch FROM now() - xact_start)),0)::int \
   FROM pg_stat_activity WHERE state <> 'idle' \
   AND xact_start < now() - interval '5 minutes'"
text
Frontend 侧：
1. 模板或主机 → Items → Create item
   Key: pgsql.custom.long_tx
   Type: Zabbix agent
   Type of information: Numeric (unsigned)
   Update interval: 1m
2. 配套创建触发器（见上节）

UserParameter 每次采集 fork 一个 psql 进程，1m 级频率下开销可接受，但不适合 15s 级高频采集；更复杂场景应优先研究所用 Zabbix 版本 agent2 的自定义查询配置能力（插件文档有专门章节）。与 Prometheus 一页相同的三条红线同样适用：只查统计视图、结果有界、上线观察负载。

模板升级与自定义内容的隔离 ​

官方模板会随 Zabbix 版本演进（监控项增删、宏改名、触发器阈值调整），生产环境的自定义内容如果没有做好隔离，模板升级就是一场灾难。隔离的原则：自定义内容挂在独立的模板层，与官方模板通过链接组合。

text
推荐的模板层级结构：

  Template "PostgreSQL by Zabbix agent 2"（官方，只升级不改）
        ▲ linked
  Template "PostgreSQL Custom CompanyX"（自建层）
      ├── 自定义监控项（长事务、业务队列深度……）
      ├── 自定义触发器（业务阈值）
      ├── 自定义图形与看板
      └── 与官方触发器的依赖关系
        ▲ linked
  Host pg-primary-01（主机层只放宏覆盖）

这样升级官方模板时，自定义层不动；自建层做版本管理（Zabbix API 导出 YAML 入 Git），变更走评审。禁手是直接在官方模板上改阈值——下次模板升级全部丢失且无据可查。大型组织还可以把「环境差异」放主机宏、把「业务共性」放自建模板，形成三层配置模型，跟基础设施即代码（IaC）的分层思想一致。

多实例与多角色部署模式 ​

单机多实例（一机跑主备两个 PG 实例）的接入模式：

text
方案 A：一个 agent2 + 命名会话
  zabbix_agent2.conf 为每个实例定义 Session（各自 Uri/凭据），
  模板用会话名区分监控项归属

方案 B：两个 agent2 实例（不同端口与配置）
  每实例一个 agent，各自挂模板，Zabbix 侧是两个 host

方案 C：每实例一个独立主机条目 + 模板宏区分 URI
  agent 共享，主机层面宏 {$PG.URI} 各自指向不同端口

主备复制场景还有一个经典坑：复制延迟监控项挂在主库视角（数据来自 pg_stat_replication），备库上采集该指标得到的是空值——模板通过条件（备库 role 触发器依赖另一组指标）处理了这一点，自定义指标时要在 SQL 里写清视角（在主库查）或在 Zabbix 侧声明采集条件。跨机房部署用 Zabbix proxy：proxy 驻留机房内采集，加密转发给中心 server——这是 Zabbix 在分布式企业环境的老牌优势。

数据保留与容量规划 ​

Zabbix 的历史数据存储有「History（原始值）+ Trends（聚合）」两层机制，容量规划与 Prometheus 的基数治理不同维度：

text
容量估算要素：
  监控项数量 × 采集频率 × 保留期（History 默认 90d，Trends 默认 365d）
  PostgreSQL 监控项多为低频数值型，单实例通常贡献极小
  风险点是 LLD 未过滤（几百个库 × 若干监控项 × 频率）

治理手段：History/Trends 保留期按公司合规要求配置（Frontend 全局或按监控项覆盖）；无需趋势的文本型监控项设短保留；大型部署考虑 TimescaleDB 后端（Zabbix 官方支持的时序化存储方案）。把「监控数据也是数据」的容量意识带进 Zabbix 运维，与上一页的基数治理异曲同工。

与 Grafana 的组合 ​

Zabbix 有官方 Grafana 数据源插件，让两套体系各展所长：

text
组合模式：
  Zabbix：采集、告警、值班流程（企业既有强项）
  Grafana：高级可视化（用 Zabbix 数据源直接画 pgsql.* 指标）

这个组合对「已有 Zabbix 但想要 Grafana 画质」的组织是零迁移成本的方案——不需要引入 Prometheus，Grafana 直接连 Zabbix server 的 API。看板建设的方法论（四层结构、标签/变量体系）完全沿用上一页的讲法。

通知渠道与值班流程集成 ​

Zabbix 在「告警送达」这一环的企业级能力，是很多团队坚持它的核心原因。配置链路是三段式：

text
Media type（媒介类型，怎么发）
  Email / Webhook / SMS / 脚本……
  Webhook 类型可以对接企业 IM（钉钉/飞书/企业微信）与
  电话呼叫平台——社区有大量现成的媒介模板
        ↓
Action operation（动作操作，发给谁、何时发）
  按触发器 severity 与主机组路由：
    Warning  → DBA 群消息
    Average  → DBA 群 + 值班IM私聊
    High/Disaster → 电话呼叫当前值班人
  Repeat/升级间隔：未确认 N 分钟后重复或升级
        ↓
Escalation（升级链，一直没人处理怎么办）
  步骤 1：值班 DBA
  步骤 2（+30min 未恢复/未确认）：DBA 主管
  步骤 3（+2h）：部门经理

对接 PostgreSQL 运维的三条实操建议：告警消息里带上排障起步信息（Webhook 消息体里放触发器名、主机、持续时间与 runbook 链接，让值班在手机上就能开始判断）；确认（Ack）机制用起来（Zabbix 的告警确认 + 确认留言形成值班交接的轨迹，这是它比 Alertmanager 强的地方）；通知风暴测试（一次网络抖动触发 50 条告警时，聚合/去重策略是否扛得住——Zabbix 按触发器逐条通知，风暴治理主要靠触发器依赖与告警聚合媒介，这要在真演练里验证）。

安全与审计 ​

Zabbix 深入企业后，安全配置要从三面做：

text
前端：统一认证（LDAP/SAML 对接）、双因素、按用户组分权
通信：agent 与 server 间启用 PSK/TLS 加密（大型企业强制）
凭据：数据库口令用宏存储（前端访问受控）或 agent 配置 + 文件权限收紧；
     zbx_monitor 账号纳入数据库口令轮转体系
审计：Zabbix 的 Audit 记录配置变更；数据库侧的 pg_stat_activity
     里要能认出 zbx_monitor 的采集会话（application_name 特征）

「监控通道本身被加密与审计」在等保、金融合规场景是硬要求，部署模板时一并落好，避免事后补课。

与 Prometheus 体系的并存与迁移策略 ​

现实企业里两套体系并存是常态而非例外：云原生团队的新服务在 Prometheus，存量数据库在 Zabbix。并存阶段的分工建议：

text
并存期的职责划分（经过验证的稳态）：

  Zabbix                    Prometheus + Grafana
  ─────────────             ─────────────────────
  存量数据库纳管              新建数据库集群
  可用性/资源类告警            深度性能指标（pg_stat_* 全家桶）
  企业值班流程对接            语句级/对象级分析
  合规审计留痕               SRE 自助看板
       │                          │
       └──── Grafana 作为统一可视化层 ────┘
         （Zabbix 数据源插件 + Prometheus 数据源）

如果决定从 Zabbix 迁移到 Prometheus（或反向），迁移顺序的经验：先并行观察期（两套同时跑 2~4 周，对比指标语义差异）、先迁可视化后迁告警（看板先在新体系建好并被团队使用，告警最后切，切换时旧体系告警降级为静默观察而非直接关闭）、每迁一批演练一次。最忌讳「周末一刀切」——周一发现值班群没人收到任何告警，因为新体系的 Action/Alertmanager 还没接通 IM。

实战示例 ​

示例一：单实例接入全流程 ​

bash
# 1. 数据库侧：建账号
psql -c "CREATE ROLE zbx_monitor WITH LOGIN PASSWORD '...';"
psql -c "GRANT pg_monitor TO zbx_monitor;"

# 2. 数据库主机：装 agent2、配插件 URI
dnf install zabbix-agent2
# /etc/zabbix/zabbix_agent2.conf: Plugins.PostgreSQL.Uri=tcp://localhost:5432
systemctl enable --now zabbix-agent2

# 3. Frontend：建主机、挂模板、配宏
# 4. 验证：Latest data 查看第一轮 pgsql.* 采集值
text
验收清单：
□ Latest data 出现 pgsql.uptime 且数值合理
□ 连接数监控项与 psql 手查 pg_stat_activity 一致
□ 复制延迟项（主库）有数据
□ LLD 发现规则只创建了预期的数据库监控项
□ 人为制造异常（如 kill 掉 PG）触发 service down 告警并送达

最后一条「人为制造一次故障」是接入验收的硬要求——模板挂上不等于监控有效。

示例二：LLD 过滤与库级监控调优 ​

text
场景：实例上有 200 个租户库，全部纳管不可接受。

1. 找到模板的 Database discovery 规则 → Filters
2. 配置 {$PG.LLD.FILTER_DATABASE} 正则：
   ^(appdb|reportdb|archive[A-Z0-9_]+)$   ← 只纳管命名规范内的库
3. per-database 监控项（大小/连接）采集间隔调整为 1h
4. 观察一周：LLD 创建的监控项数量稳定、无垃圾库混入

命名规范 + 发现过滤的组合，让「库级纳管」从运维负担变成自动流程——新租户库只要命名合规，自动进入监控。

示例三：自定义长事务监控项与升级动作 ​

conf
# agent 配置：长事务最大年龄（秒）
UserParameter=pgsql.custom.long_tx_age,psql -U zbx_monitor -d appdb -Atc \
  "SELECT coalesce(max(extract(epoch FROM now() - xact_start)),0)::int \
   FROM pg_stat_activity WHERE state <> 'idle' AND xact_start IS NOT NULL"
text
Frontend：
1. Item: pgsql.custom.long_tx_age，1m 采集
2. Trigger: max(…, #5) > 1800  → Average（连续 5 分钟超 30 分钟）
3. Action:
   条件：Trigger = 上述触发器 且 维护期之外
   步骤 1：通知 DBA 群（IM 集成）
   步骤 2（10 分钟后仍未恢复）：电话呼叫值班
   步骤 3（1 小时后）：升级到 DBA 主管

这套「连续确认 → 分级通知 → 超时升级」的动作链是 Zabbix 的看家本领，等价于 Alertmanager 的 route/repeat/escalation，但配置门槛更低、企业特性（值班表对接）更成熟。

示例四：主备集群的双视角监控 ​

text
目标：主库与备库各自挂模板，复制状态双向可见。

主库 host（pg-primary-01）：
  模板：PostgreSQL by Zabbix agent 2
  关注：复制延迟（pg_stat_replication 视角）、连接、WAL 速率
备库 host（pg-replica-01）：
  模板：同上
  关注：回放延迟、热备冲突、只读状态

补充自定义项（备库）：
  pgsql.custom.recovery_age —— 备库最后回放的事务时间距现在的秒数
  （SELECT extract(epoch FROM now() - pg_last_xact_replay_timestamp())）

联动触发器：
  主库 WAL 速率正常 + 备库 recovery_age 持续增长
  → High：「备库回放停滞」
  （这个组合判断能区分"主库没流量"与"备库真停滞"）

复制监控最容易误报的地方是「主库无流量时延迟为 0 但备库实际早已断开」——双向视角 + 组合触发器是消除这类误报的标准手法。

示例五：监控接管演练（季度演习） ​

text
目标：验证「Zabbix 挂了」时团队能否第一时间发现——监控系统的监控
      （meta-monitoring）是最容易被忽略的一环。

演习脚本（每季度一次，30 分钟内完成）：

1. 停掉 zabbix-agent2（模拟 agent 失联）
   预期：Zabbix Frontend 出现「Zabbix agent is not available」告警
   验证点：告警是否送达值班渠道？延迟多少秒？
2. 停掉 zbx_monitor 账号的连接权限（模拟凭据失效/账号锁定）
   预期：pgsql.* 监控项转为 Unsupported 状态
   验证点：是否有「监控项不可用」类告警？（模板内含 item
   unsupported 触发器的要确认在启用状态）
3. 人为改错 {$PG.PASSWORD} 宏
   预期：同上，采集全面失败
   验证点：从故障注入到告警送达的全链路耗时
4. 恢复一切，记录时间线，把发现的问题转成待办
text
常见的演习发现（真实世界的输出）：
  - agent 失联告警走了 5 分钟才到——server 的 unavailable 延迟没调
  - 宏改错后只有 Latest data 里数值消失，没有任何告警配置覆盖
    "监控项 unsupported" 场景
  - 值班群机器人 token 三个月前过期了，之前从未真实验证过

这三类发现几乎每家企业都命中过至少一条。监控系统自身的可用性要有独立视角（另一套系统盯它的存活，或至少有 server 侧的进程监控），「监控的监控」投入很小，事故夜回报巨大。

注意事项 ​

模板宏与参数命名随版本演进。 Zabbix 6.0、6.4、7.0 各 LTS 的模板与插件配置有过调整（宏命名、监控项键、agent 配置参数），升级 Zabbix 或模板版本时按官方模板变更说明核对，不要凭旧版经验硬写。

agent2 是独立于 agent 1 的运行时。 同一主机上 agent 与 agent2 不要混用（同一主机条目只能对接其一）；PostgreSQL 监控能力只存在于 agent2，老的 agent 1 无插件体系。

监控账号权限要最小且可审计。 pg_monitor 已覆盖模板所需；任何「直接给 superuser 省事」的做法都会在审计时变成事故。账号口令纳入轮转，宏修改记录在 Zabbix Audit 里可查。

采集频率与数据库负载的平衡。 模板默认频率对绝大多数实例无感，但自定义项的高频采集（15s 级 UserParameter fork psql）要评估；「监控项比业务查询还重」是本末倒置的信号。

LLD 不过滤 = 监控项爆炸。 前文反复强调：发现过滤宏必配，模板升级后重新检查发现规则的过滤是否被重置。

Zabbix 的 Proxy 链路要纳入容量与安全规划。 proxy 与 server 间的带宽（历史数据回传）、proxy 本机的存储缓冲、链路加密，多机房大规模部署时是独立的运维课题。

不要在 Zabbix 里重建 Grafana 的全部能力。 Zabbix 看板适合状态总览，复杂分析图表交给 Grafana（用 Zabbix 数据源）——各干各的，别互相硬凑。

速率类指标的重启跳变要有预期。 累计计数器在数据库或 agent 重启后归零，速率曲线会出现一次尖峰或空洞；模板自带项已处理，自定义速率项要套用同样的差分预处理，别在触发器里裸用差值。

监控告警要演练。 与 Prometheus 一页相同的结论：模板自带的触发器也要人为触发一次，确认 Action 链路（IM/电话/值班表）真实可达。没有演练过的告警体系在事故夜会集体失声。

PostgreSQL 大版本升级时同步核对监控项。 模板里部分采集 SQL 依赖特定统计视图（如 pg_stat_bgwriter 的字段在版本间有变化），数据库大版本升级前先确认所用模板版本对该版本的兼容性声明，避免升级当晚监控集体变红或静默失效。

Zabbix server 自身的容量是隐性单点。 全企业主机共享一个 server 时，数据库监控项的加入会叠加采集压力；server 性能不足表现为采集延迟与触发器评估滞后，容量评估（NVPS 指标）要在大规模纳管数据库前完成。

模板自带的图形与看板只是起点。 官方模板附带的图表面向通用场景，团队真正高频使用的「数据库一屏总览」（可用性 + 连接 + 延迟 + WAL 四象限）值得自建并在组织内标准化，避免每个人看不同的仪表盘。

监控配置的变更要走与生产系统同级的流程。 一条改错的触发器表达式可以让关键告警永远沉默——监控配置的变更同样需要评审与灰度（先改测试主机验证），Zabbix API 导出入 Git 是把这条流程落地的最小做法。

PostgreSQL 侧要能识别监控流量。 zbx_monitor 的采集会话应通过 application_name 或用户名在 pg_stat_activity 里一眼可辨，并在连接数告警的口径里说明其占比；「监控流量混进业务连接统计」会让连接容量规划失真。

最佳实践 ​

  1. 优先用官方模板「PostgreSQL by Zabbix agent 2」，不要手搓监控项起步。 模板是社区经验的结晶，覆盖面与正确性远超临场发挥；自定义只做模板没覆盖的业务指标。
  2. 监控账号 pg_monitor + pg_stat_scan_tables 语义核对后最小授权。（pg_monitor 已聚合后者，显式授予只作版本兼容的防御性写法。）禁止 superuser 接入监控。
  3. 凭据走模板宏或 agent 会话配置，纳入口令轮转。 agent 配置文件权限收紧到属主可读；前端访问受统一认证保护。
  4. LLD 发现过滤必配，per-database 项降频。 命名规范驱动纳管，垃圾库与临时库挡在门外。
  5. 自定义指标沿用「统计视图优先、结果有界、上线观察」三关。 UserParameter 适合 1m 级，更高频需求研究 agent2 插件的自定义查询能力。
  6. 触发器设计带多周期确认与可追溯的阈值依据。 每条触发器写明阈值来源与 runbook 链接；severity 对齐企业告警标准。
  7. 主备环境做双视角监控。 主库看延迟、备库看回放，组合触发器消除「无流量误报」；failover 演练时同步演练监控视角的切换。
  8. 多机房用 proxy，链路加密与缓冲容量进设计。 分布式不是事后补丁，是拓扑设计的组成部分。
  9. Zabbix 管告警值班、Grafana 管深度可视化。 官方 Grafana 数据源插件让两套体系零迁移组合，避免在 Zabbix 里硬画复杂图表。
  10. History/Trends 保留期按合规要求显式配置。 大规模部署评估 TimescaleDB 后端；监控数据的容量也要进容量规划。
  11. 版本升级三同步：Zabbix 主版本、模板版本、PostgreSQL 大版本。 每次升级核对模板变更说明，监控项键名与宏可能有变。
  12. 接入验收必须包含「人为故障演练」。 kill 实例、制造长事务、拔备库——每种告警路径都要真实走过一遍才算上线完成；随后进入下一页，看看 pgwatch 如何把语句级监控做到开箱即用。

下一节

继续学习：pgwatch 监控

参考链接 ​