HDUO Lab

标签： PostgreSQL

  • 深入 Zabbix 监控雪崩排查：LLD 发现风暴引发的 Proxy 缓存积压与 History Syncer 夯死实战

    近期处理了一起 Zabbix 6.0 LTS 集群雪崩事故。根因是某业务线引入劣质自定义 LLD 模板，单机生成逾万监控项，引发 Proxy 缓存打满与 History Syncer 进程 100% 繁忙，最终压垮后端 DB IO 导致全局断连。核心解法：阻断异常 LLD 发现、调优 Zabbix 核心缓存参数，并将底层存储彻底迁移至 PostgreSQL + TimescaleDB 解决写入墙问题。

    故障现场：Queue 积压与 Poller 满载

    排查过程中，监控大屏首先报警的是 Zabbix Queue 严重积压，延迟超过 10 分钟的 item 数量直线飙升破 5 万。登录 Zabbix Server 核心节点，top 命令显示 Load Average 飙升至 80+，系统 iowait 长期盘踞在 40% 以上。

    查看 Zabbix Server 日志 /var/log/zabbix/zabbix_server.log，满屏都是极其致命的告警：

    Zabbix server history syncer processes more than 75% busy
Zabbix server history syncer processes more than 100% busy
server is out of memory: Out of memory (data: 256M, index: 64M)
cannot accept connection from proxy "cn-sh-proxy-01": max number of Trapper processes reached

    切到前端分布式 Proxy 节点 /var/log/zabbix/zabbix_proxy.log，同样处于崩溃边缘：

    cannot send proxy data to server at "10.0.0.10": Zabbix server connection failed
history cache is full, sleeping for 1 second

    表象很清晰：数据写不进数据库，导致 Zabbix Server 的 History Syncer（负责将内存数据刷入 DB 的核心进程）全部夯死。Server 端 Trapper 进程耗尽，导致 Proxy 无法上报数据，Proxy 本地的 HistoryCache 被打爆，最终整个监控链路瘫痪。

    为什么一个简单的自定义模板能搞垮整个监控集群？

    很多开发在写 Zabbix 监控脚本时，缺乏“防御性编程”思维。抓取故障现场的 Proxy sqlite3 库（或本地临时文件），发现罪魁祸首是一个名为 Custom_K8s_Pod_Discovery 的 LLD (Low-Level Discovery) 脚本。

    该脚本通过 Python 遍历全量 Pod 状态，但没有做任何 Limit 限制和状态机过滤。单台 Kubernetes Node 上的脚本直接返回了近 5MB 的 JSON Array：

    {
  "data": [
    {"{#PODNAME}": "web-api-7b89f...", "{#NAMESPACE}": "prod", "{#CONTAINER}": "nginx"},
    // ... 往下还有 15000+ 个对象
  ]
}

    Zabbix LLD 引擎在处理这个宏大 JSON 时，会为每一个 {#PODNAME} 动态生成 5 个 Item（CPU、内存、网络 IO 等）。 算一笔账：1 台机器抛出 15000 个实体 $\times$ 5 个 Item = 75000 个监控项。 如果是 100 台节点的集群，瞬间生成 750 万个新监控项。

    这些海量监控项每 30 秒采集一次数据，疯狂涌入 Zabbix Proxy。 Proxy 的默认 HistoryCacheSize 仅有区区 16M，瞬间被打满。随后 Proxy 将庞大的 Payload 塞给 Zabbix Server，Server 端的 History Syncer 试图将这几百万条并发写入后端的 MySQL history_uint 表。MySQL InnoDB 面对这种毫无规律的极高频并发 Insert，B+ 树页分裂严重，NVMe 磁盘的 IOPS 直接打满，写延迟达到 500ms 以上，彻底堵死。

    架构级改造：从 MySQL 到 PG+TimescaleDB

    在千万级 Item 的企业监控场景下，MySQL 表分区脚本（如常用的 partitioning.sql 存储过程）不仅维护极其痛苦，且对历史数据的清理依然会产生锁争用。

    解决写入瓶颈的最终态方案，是利用原生时序数据库。Zabbix 从 5.0 开始深度支持 PostgreSQL + TimescaleDB 扩展，将 history 相关的表转化为 hypertable，实现按时间维度的透明 Chunk 分片。

    迁移与落地步骤：

    1. 部署 PostgreSQL 14 与 TimescaleDB 插件。

    2. 导入 Zabbix 基础 Schema 后，务必执行 TimescaleDB 转换脚本：

    # Zabbix 6.0 环境下开启 TimescaleDB 支持
zcat /usr/share/doc/zabbix-sql-scripts/postgresql/timescaledb.sql | sudo -u zabbix psql zabbix
    1. 在 Zabbix Server 开启内部历史数据压缩（极大降低磁盘 IO 并节省 70% 空间）：
    -- 连接到 zabbix 库
UPDATE config SET db_extension='timescaledb', history_compression_status=1, history_compress_older='7d';

    切换到 TimescaleDB 后，Zabbix History Syncer 的写操作变成了针对内存中最新 Chunk 的顺序追加写（Append-only），避开了全表扫描和巨型 B-Tree 维护，单机轻松抗住 10万+ QPS 的监控项写入。

    调优与防御性配置落地

    底层存储问题解决后，必须对 Zabbix 核心配置进行防御性加固，防止类似 LLD 风暴再次冲垮服务。

    1. Zabbix Server 核心参数重调

    编辑 /etc/zabbix/zabbix_server.conf：

    # 根据物理内存，大幅提高历史缓存，作为 DB 抖动时的缓冲池
HistoryCacheSize=2G
HistoryIndexCacheSize=256M
ValueCacheSize=1G

# 增加数据刷盘进程数（需结合 DB 最大连接数考量）
StartHistorySyncers=30

# 增加处理 Proxy 和 Agent 主动上报的 Trapper 进程
StartTrappers=100

# 禁用 Server 端轮询，强制全部走 Proxy 分布式采集
StartPollers=0

    2. Zabbix Proxy 缓冲防御

    编辑 /etc/zabbix/zabbix_proxy.conf：

    # 提高 Proxy 侧的缓存，容忍更长时间的 Server 端断连
HistoryCacheSize=1G
HistoryIndexCacheSize=128M

# 严格控制外部脚本超时时间，防止进程卡死（默认3秒，最大不超过10秒）
Timeout=10

    3. 数据预处理（Pre-processing）截流

    针对自定义监控项，强制要求在 Zabbix Web UI 的 Item Preprocessing 中配置以下规则：

    • Discard unchanged with heartbeat (心跳抑制): 如果监控值没有变化，直接在 Proxy/Server 端丢弃，只在达到 heartbeat（如 1 小时）时强制写入一次。这能削减 60% 以上的无用状态写入。

    • 正则表达式过滤: 对 LLD 发现的文本进行白名单截断，丢弃非核心进程的数据。

    常见问题

    Q1: Proxy 报错 “Zabbix server connection failed”，但网络 Ping 和 Telnet 都通，如何排查？ 通常不是网络问题，而是 Zabbix Server 端的 Trapper 进程全忙。检查 Zabbix Server 监控大屏上的 Zabbix server trapper processes busy 指标是否达到 100%。若是，需调大 StartTrappers，或检查是否有超大 Payload 正在阻塞网络层解析。

    Q2: 监控项经常出现断点，日志提示 “first network error, wait for 15 seconds”，如何优化？ 这是 Poller 进程在执行某些慢请求（如大文本抓取、远端 API 调用）时超时了。Zabbix 默认超时 Timeout=3 秒。建议将耗时任务改成 Agent 端的异步 Crontab 写入本地文件，Zabbix 只做简单的 vfs.file.contents 读取；或者将 Timeout 谨慎上调至 10。

    Q3: 迁移到 TimescaleDB 后，Zabbix 的 Housekeeper 还需要开启吗？ 绝对不需要对历史表开启。开启 TimescaleDB 后，应在 Zabbix UI 的 “Administration -> General -> Housekeeping” 中，勾选 Override item history period 并启用内部机制。旧数据的清理会由 DB 原生的 drop_chunks() 函数瞬间完成，而不是 Housekeeper 一行行执行极度耗 IO 的 DELETE 语句。

    Q4: 怎样防止自定义 LLD 脚本再次引发灾难？ 运维必须剥夺业务组直接创建 LLD Template 的权限。通过 CI/CD 管道扫描业务侧提交的脚本，限制 LLD 返回的 JSON 最大数组长度（如不超过 200）。此外，在 Zabbix 中利用 “LLD overrides” 功能，强制要求匹配特定正则的对象才能触发 Item 发现。

  • 深入 PostgreSQL 生产表膨胀雪崩：长事务挂起引发的 autovacuum 失效与 XID Wraparound 宕机危机

    近期处理了一起极其经典的 PostgreSQL 数据库性能雪崩事故。核心表现为核心集群 CPU Load 飙升至 100+，读写 P99 延迟从 5ms 暴增到 3000ms，同时监控面板上的磁盘利用率以肉眼可见的速度疯狂攀升（每小时吃掉数十 GB）。

    结论先行：业务服务因某个非预期的异常退出，留下了一个长达数天的 idle in transaction（事务空闲）会话。这个幽灵会话死死按住了全局的 xmin 水位线，导致底层的 autovacuum 进程虽然疯狂拉起扫表，却无法清理任何死元组（Dead Tuples），最终引发海量表膨胀，并险些触发 PG 核心的 XID Wraparound（事务 ID 环绕）强制只读宕机保护。

    解决方法极其简单粗暴：pg_terminate_backend(pid) 杀掉僵尸进程，并在全局强制开启 idle_in_transaction_session_timeout 防御性配置。随后通过 pg_repack 无锁重建膨胀表。

    现场还原：当磁盘 I/O 被无效扫描打满

    排查过程中，第一视角的监控极其惨烈：

    1. iostat 显示底层 NVMe 盘的 %util 长时间顶在 100%，大量的随机读写。

    2. 慢查询日志被打爆，平平无奇的单行 UPDATE 和 SELECT 居然要跑几秒钟。

    直觉告诉我，数据扫描路径出问题了。连上数据库，直接看活跃会话：

    SELECT pid, usename, state, backend_xid, backend_xmin, duration 
FROM (
    SELECT pid, usename, state, backend_xid, backend_xmin, 
           now() - xact_start AS duration 
    FROM pg_stat_activity 
    WHERE state != 'idle'
) sq 
ORDER BY duration DESC LIMIT 5;

    结果极其刺眼：排名第一的会话状态是 idle in transaction，duration 已经高达 96:12:45（整整四天！）。

    再看系统视图里的表膨胀情况：

    SELECT relname, n_live_tup, n_dead_tup, 
       round(n_dead_tup::numeric / (n_live_tup + n_dead_tup + 0.01) * 100, 2) AS dead_ratio
FROM pg_stat_user_tables 
ORDER BY n_dead_tup DESC LIMIT 5;

    核心订单表的 n_dead_tup 高达数亿，dead_ratio 超过 70%。这意味着业务每次查询，PG 都要在磁盘上额外扫描 70% 的废弃数据，I/O 不炸才是见鬼了。

    底层原理：为什么一个 idle 会话能拖垮整个集群？

    很多人从 MySQL 迁移到 PostgreSQL 时，最不适应的就是它的 MVCC（多版本并发控制）实现。

    MySQL 把旧版本数据存放在独立的 Undo Log 里，而 PG 的设计更为激进——直接把新老版本（Tuples）写在同一个数据文件中。 当执行 UPDATE 或 DELETE 时，PG 只是在老元组的头部打上过期标记（xmax），然后插入一个新元组。这些被打上标记的老旧死元组，全靠后台的 autovacuum 进程来回收空间。

    但 autovacuum 清理死元组有一个铁律：必须保证当前系统中没有任何活跃事务可能再访问到这些元组。

    这里就涉及全局最小活跃事务 ID（xmin）。 如果系统中存在一个事务 A（比如我们抓到的那个僵尸会话），它在 4 天前开启（执行了 BEGIN 并且做过查询），那么 PG 必须为事务 A 保留它开启那个时间点的所有数据快照。 在事务 A 提交或回滚之前，全局的 xmin 水位永远无法向前推进。

    这就是最致命的地方：即便这 4 天里产生了上亿个死元组，autovacuum 正常按计划被唤醒，它扫描了整个表，发现这些死元组的 xid 都比那个僵尸事务 A 的 xid 要大，于是它一个字节都不能删，只能无奈地退出。循环往复，白白消耗大量 I/O 去扫表，却做着无用功。

    致命一击：XID Wraparound 保护

    更可怕的还在日志里。查看 postgresql.log，发现大量类似这样的告警：

    WARNING:  database "prod_db" must be vacuumed within 10000000 transactions
HINT:  To avoid a database shutdown, execute a database-wide VACUUM in that database.

    PG 的事务 ID（XID）是一个 32 位的无符号整数，最大约 42 亿。为了处理环绕（即 XID 耗尽后从头开始），PG 把 XID 空间一分为二，过去 21 亿是“过去”，未来 21 亿是“未来”。 为了防止极其古老的事务 ID 变成“未来”导致数据不可见，PG 强制要求在 XID 跨度达到 20 亿之前，必须通过 VACUUM 冻结（Freeze）旧事务。

    因为那个 4 天前的僵尸事务拦住了 autovacuum 的清理与冻结逻辑，XID 正在逼近环绕红线。一旦触发 autovacuum (to prevent wraparound)，这是最高优先级的强制清理操作，它会无视常规调度并疯狂吃光 I/O。如果最后还没清理完，PG 会为了保护数据不损坏，强行将整个数据库锁死进入只读模式（shutdown）。

    防御性落地：如何给系统系上安全带

    一个开发连直连线上 DB 手敲 BEGIN 忘了 COMMIT 去喝咖啡，或者微服务里一个没有设置 Timeout 的 HTTP 请求持有了 DB 链接挂死，就能让整个集群陪葬。这种架构容错率极低，必须从配置层面进行防御性斩断。

    1. 止血操作： 立刻执行斩首，将该 PID 强杀：

    SELECT pg_terminate_backend(pid);

    杀掉之后，autovacuum 终于能工作了，观察磁盘 I/O 依然很高，但那是正在真正清理死元组。

    2. 核心防御配置（必须写进 postgresql.conf）：

    # 强制终止空闲在事务中的会话（救命配置，单位毫秒）
idle_in_transaction_session_timeout = 600000  # 10分钟

# 强制终止超长查询（防止烂SQL打满CPU）
statement_timeout = 30000  # 30秒

# 开启 autovacuum 慢执行日志，增强可观测性
log_autovacuum_min_duration = 1000 # 超过1秒的清理记录到日志

    3. 空间回收： autovacuum 只能把死元组标记为可复用，它不会把磁盘空间还给操作系统（除非死元组刚好在文件的最后）。 对于已经严重膨胀的表，直接执行 VACUUM FULL 会获取最高级别的排他锁（AccessExclusiveLock），直接导致业务阻塞报错。 生产环境的唯一正解是使用 pg_repack 或 pg_squeeze 插件：

    # 在线无锁重建膨胀表，将真实数据拷贝到临时表并交换文件指针
pg_repack -h localhost -d prod_db -t public.orders -j 4

    排查清单与同类问题速查

    1. 检查挂起长事务：周期性监控 pg_stat_activity 中 state = 'idle in transaction' 且 duration > 5m 的会话，直接触发告警。

    2. 监控表膨胀率：通过 pg_stat_user_tables 结合 pg_class 估算 dead_tuple 比例，超过 20% 的大表需人工介入检查。

    3. 关注 XID Age：监控 datfrozenxid 的年龄（age(datfrozenxid)），如果超过 autovacuum_freeze_max_age（默认 2 亿）且持续攀升，说明系统的冻结机制已失效，距离全盘宕机倒计时开始。

    4. 警惕复制槽（Replication Slot）滞留：除了长事务，未被消费的废弃逻辑复制槽也会拖住 xmin，导致主库无法清理死元组，需通过 pg_replication_slots 视图排查清理。

  • 深入 PostgreSQL MVCC 机制：从 500GB 表膨胀看 Autovacuum 与 xmin 陷阱实战

    PG 核心表突发 500GB 膨胀，查询 P99 从 50ms 飙升至 3s。根因是长事务或废弃复制槽拖住了全局 xmin 视界，导致 Autovacuum 彻底失效，引发 Dead Tuples 堆积的“死亡螺旋”。本文拆解 PG 14 的 MVCC 与 VACUUM 底层机制，并给出防御性调优基线。

    现场与线索

    某次排查过程中，监控大盘开始疯狂告警：某 PG 14.5 生产集群磁盘使用率突破 85%，核心业务读写耗时严重劣化。登录主机查看系统负载，Load Average 飙升至 60+（32核机型），I/O Wait 居高不下。

    通过 pg_stat_user_tables 排查表状态，发现一张核心订单表 n_dead_tup（死元组数量）高达数千万，表物理体积从原本的 50GB 暴涨到了 550GB。

    显然，这是一次典型的表膨胀（Table Bloat）。立刻手动触发分析：

    VACUUM VERBOSE orders;

    终端很快返回了令人窒息的日志：

    INFO:  vacuuming "public.orders"
INFO:  "orders": found 0 removable, 45120485 nonremovable row versions in 702581 pages
DETAIL:  45120485 dead row versions cannot be removed yet, oldest xmin: 245189012

    关键信息在 0 removable 和 cannot be removed yet。Autovacuum 其实在正常调度，只是它无权清理这些死元组。

    为什么正常执行的 Autovacuum 无法回收死元组（Dead Tuples）？

    要解释这个问题，必须扒开 PostgreSQL 基于多版本并发控制（MVCC）的底层实现。

    在 PG 中，执行 UPDATE 或 DELETE 并不会原地修改或删除数据。UPDATE 实际上是 DELETE + INSERT。旧的数据行被称为 Dead Tuple。PG 在每行数据（Tuple）头部维护了两个核心隐藏字段：

    • t_xmin：插入/更新该元组的事务 ID。

    • t_xmax：删除/更新该元组的事务 ID（如果是活元组，此值为 0）。

    当 Autovacuum 扫描表时，它需要判断一个 Dead Tuple 是否可以被物理回收。判断的唯一法则基于 全局最小活跃事务 ID（Global Xmin Horizon）。 如果一个 Dead Tuple 的 t_xmax 大于或等于 当前系统中正在运行的最老活跃事务的 ID（也就是 oldest xmin），那么这个 Dead Tuple 绝对不能被清理。因为那个老事务如果执行查询，根据 MVCC 可见性规则，它依然需要读取这行“历史数据”。

    因此，一旦系统中出现“刺客”拖住了全局 xmin，哪怕你把 Autovacuum 调得再激进，也是徒劳。常见的“刺客”有三种：

    1. 长事务（Long Transactions）：代码里忘了 COMMIT 的 idle in transaction 状态。

    2. 废弃的逻辑复制槽（Abandoned Replication Slots）：下游消费端宕机，导致主库一直保留 WAL 和 xmin 视图。

    3. 两阶段提交的孤儿事务（Prepared Transactions）。

    揪出元凶

    执行以下 SQL 抓取系统中最老的事务或复制槽：

    -- 查长事务
SELECT pid, usename, state, backend_xmin, backend_xid, 
       age(backend_xmin) AS xmin_age, query, state_change
FROM pg_stat_activity 
WHERE backend_xmin IS NOT NULL 
ORDER BY age(backend_xmin) DESC LIMIT 5;

-- 查复制槽
SELECT slot_name, plugin, slot_type, active, xmin, 
       catalog_xmin, age(xmin) AS xmin_age 
FROM pg_replication_slots 
ORDER BY age(xmin) DESC;

    排查发现，业务端有个定时任务触发了死锁异常被捕获，但在异常处理逻辑中漏掉了 Rollback，导致一个 idle in transaction 的会话挂了 3 天，彻底锁死了全局 xmin 推进。

    解决手段简单粗暴：直接 pg_terminate_backend(pid) 杀掉僵尸会话。随后 Autovacuum 迅速介入，大量死元组被标记为可复用空间（FSM, Free Space Map）。

    生产级 Autovacuum 防御性调优基线

    原生 PG 的默认配置极度保守，是为了能在树莓派或低配虚机上跑起来而设计的。把默认配置直接上到几十核的高并发生产环境，等于给系统埋雷。

    为了防止类似“死亡螺旋”的发生，我们在 postgresql.conf 中必须落地以下防御性配置策略（基于 PG 14）：

    1. 斩断长事务的黑手

    绝对不要相信业务代码能完美处理所有异常分支。在数据库侧兜底是运维的基本素养。

    # 防御性配置：强制终结空闲时间过长的事务（极度重要）
idle_in_transaction_session_timeout = '10min'

# （可选）针对高并发OLTP，设置单条语句最大执行时间
# statement_timeout = '30s'

    2. 限制复制槽的 WAL 与 xmin 保留

    PG 13 引入了关键配置，防止死掉的逻辑复制槽把主库磁盘撑爆。

    # 限制复制槽最大保留的WAL大小，超出此值将强制失效复制槽
max_slot_wal_keep_size = '50GB'

    3. 释放 Autovacuum 的 I/O 枷锁

    默认的 autovacuum_vacuum_cost_limit 是 200，它限制了 VACUUM 进程的 I/O 速率，导致在大表中 VACUUM 速度远落后于 UPDATE 产生垃圾的速度。

    # 降低触发阈值，避免累积过多才开始清理
# 默认是0.2（20%），对于1亿行的表，要等2000万行变更才触发，太晚了
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02

# 提升 VACUUM 的 I/O 配额限制（默认 200 太低，SSD 环境可以直接上 2000~5000）
autovacuum_vacuum_cost_limit = 2000
autovacuum_vacuum_cost_delay = 2ms

    避坑指南：很多人喜欢调大 autovacuum_max_workers（默认 3）。注意，所有 Worker 是平分 autovacuum_vacuum_cost_limit 这个 I/O 额度的。如果只加 Worker 不加 Limit，每个 Worker 的执行速度反而会变得像蜗牛一样慢，加剧锁竞争。

    常见问题 (FAQ)

    Q1：表已经膨胀到 500GB 了，杀死长事务后，Autovacuum 跑完了，为什么磁盘空间没有释放？ A：Autovacuum 只能将 Dead Tuple 占用的空间标记为 Free Space Map (FSM) 供后续 INSERT/UPDATE 复用，它不会将空间退还给操作系统（除非恰好死元组都在表文件的物理末尾）。如果急需释放磁盘空间，不能使用常规 VACUUM，需要使用 VACUUM FULL（会获取 8 级排他锁，阻塞读写），或在生产环境使用第三方工具 pg_repack 或 pg_squeeze 进行在线无锁空间重组。

    Q2：日志里疯狂打印 “WARNING: oldest xmin is far in the past”，并伴随 Transaction ID Wraparound 警告，怎么救？ A：XID 环绕是 PG 最严重的问题之一。PG 的事务 ID 是 32 位整数（约42亿），用尽后会绕回，导致未来的事务把旧数据看作不可见，造成“数据蒸发”错觉。当到达防环绕阈值时，PG 会强制进入只读模式。 一旦触发警告，需立即停止应用写入，找出拖住 xmin 的老事务/复制槽清理掉，并手工执行 VACUUM (FREEZE, VERBOSE) table_name 来冻结老数据的 XID。若已宕机，需进入单用户模式（Single-User Mode）手动执行 Freeze。

    Q3：频繁触发 VACUUM 会不会对 WAL 产生剧烈影响？ A：会。当开启了 wal_log_hints = on 或使用了数据校验和（Checksums），且发生 Checkpoint 后的第一次页面修改时，PG 会触发全页写入（Full Page Writes, FPW）。VACUUM 过程中如果是第一次 touch 某个页，也会产生大量的 FPW，导致 WAL 体积激增。这是保证 Crash Safe 的必要代价。应对策略是合理拉长 Checkpoint 间隔（调大 max_wal_size 和 checkpoint_timeout），降低 FPW 的发生频率。