TiDB金融级Zabbix监控方案：从指标采集到根因定位

1. 项目概述：为什么银行级监控不能只靠Zabbix原生能力

TiDB 在中国银行 Zabbix 监控方案中的应用，这个标题背后藏着一个非常典型的金融级基础设施运维痛点：当核心数据库从传统单体架构转向分布式HTAP架构后，Zabbix这类通用监控平台的“默认配置”会迅速失灵。我参与过多个类似场景的落地支持，最深的体会是——不是Zabbix不好用，而是它天生没为TiDB这种强一致性、多组件协同、自动分片调度的数据库设计监控逻辑。中国银行选择将TiDB深度接入Zabbix体系，并非简单加个Agent了事，而是重构了一整套指标采集-聚合-告警-根因定位的闭环链路。

核心关键词“TiDB”“中国银行”“Zabbix监控方案”已经划出了三条硬边界：第一是技术栈边界——必须基于TiDB v6.5+ LTS版本的Prometheus生态原生指标；第二是合规边界——所有采集行为需满足金融行业《信息系统监控审计规范》中关于数据不出域、指标脱敏、采集频次可控的要求；第三是运维边界——告警必须能直接映射到具体TiKV节点、Region分布、SQL执行计划层级，不能停留在“CPU高”“连接数满”这种模糊状态。这意味着方案里每一个采集脚本、每一条告警规则、每一次阈值设定，都得经得起生产环境7×24小时压测和审计回溯。适合参考的不是互联网公司的开源模板，而是某国有大行在2023年完成的同城双活TiDB集群监控改造案例——他们把Zabbix从“看门狗”升级成了“手术导航仪”。

2. 整体架构设计与关键选型逻辑

2.1 为什么放弃Zabbix原生JDBC插件直连TiDB

很多团队第一反应是用Zabbix的JDBC模板连TiDB的information_schema查状态，这在测试环境跑得飞快，但上线后立刻暴雷。原因有三：
第一，TiDB的performance_schema和metrics_schema本质是内存视图，每次查询都会触发内部采样计算，QPS超过5次/秒就会明显拖慢TiKV的Raft日志同步；
第二，JDBC直连无法获取底层TiKV的Region健康度、Peer分布不均、Write Stall等关键信号——这些指标藏在PD（Placement Driver）的HTTP API里，而Zabbix原生不支持多端点聚合；
第三，金融系统要求指标采集必须带租户标签（tenant_id），但JDBC查询结果无法天然携带PD分配的store_id、region_id等上下文，导致告警时根本定位不到具体故障单元。

我们最终采用“三层采集代理”架构：

• 底层：TiDB自带的Prometheus+Grafana监控栈保持原样运行，作为基础指标源；
• 中间层：用Python写的轻量级Exporter（我们叫tidb-zbx-exporter），它定时调用PD API、TiKV Status API、TiDB Dashboard API，把分散的JSON响应转换成Zabbix能识别的key-value格式；
• 上层：Zabbix Server通过Zabbix Agent2的system.run主动拉取Exporter暴露的/metrics端点，再经由Zabbix的Low-Level Discovery（LLD）自动发现TiKV Store、TiDB实例、PD节点等实体。

这个设计绕开了JDBC瓶颈，又复用了现有Zabbix资产。最关键的是，Exporter里内置了金融级安全控制：所有API调用强制走mTLS双向认证，指标字段自动过滤含SQL文本的trace_id，采集间隔可按组件分级设置（PD每10秒、TiKV每30秒、TiDB每60秒），完全满足等保三级对监控数据采集的合规要求。

2.2 TiDB核心组件与Zabbix监控对象的映射关系

Zabbix不是数据库监控专用平台，所以必须把TiDB的分布式概念翻译成Zabbix能理解的“主机-服务-触发器”模型。我们做了这样一张映射表：

注意这里有个关键细节：Zabbix的“主机”概念被我们重新定义了。传统做法是把一台物理机当一台主机，但TiDB的Store可能跨物理机部署（比如同一台服务器跑2个TiKV实例）。所以我们让Exporter在注册时，把每个Store的store_id作为Zabbix主机名，同时打上physical_host: server01、rack: rack-A等自定义标签。这样既保证Zabbix能按物理拓扑分组，又能按TiDB逻辑拓扑做故障隔离分析——比如当rack-A所有Store告警时，Zabbix自动关联出是机柜供电问题；当store_id=5的Store单独异常，则直接定位到该Store的磁盘IO瓶颈。

2.3 告警策略的金融级分级设计

银行系统最怕误报和漏报。我们把TiDB告警分成四级，每级对应不同处置流程：

• L1级（通知级）：如“TiDB QPS连续5分钟低于基线30%”，仅推送企业微信给值班工程师，不触发电话告警；
• L2级（预警级）：如“单个TiKV Store的raft propose延迟>200ms”，推送至运维群并生成工单，要求2小时内响应；
• L3级（严重级）：如“PD leader连续3次切换”或“region leader数<副本数”，立即电话告警，启动应急预案；
• L4级（灾难级）：如“超过50%的Store处于Tombstone状态”或“PD etcd存储使用率>95%”，自动触发灾备切换流程。

所有阈值都不是拍脑袋定的。比如raft propose延迟的200ms阈值，是基于某次压测得出的：当延迟超过180ms时，TPC-C测试的tpmC值开始断崖式下跌；而200ms留出了20ms的缓冲余量，避免网络抖动误触发。更关键的是，我们用Zabbix的“触发器依赖”功能构建了告警抑制链——L3级告警触发时，自动抑制其下属所有L1/L2级告警，防止告警风暴。例如PD leader切换时，会自动屏蔽所有TiKV Store的raft延迟告警，因为此时延迟升高是预期行为。

3. 核心指标采集实现与参数详解

3.1 tidb-zbx-exporter的核心采集逻辑

Exporter不是简单转发API，而是做了三层数据加工：
第一层：协议适配
TiDB各组件API返回格式不统一：PD用JSON，TiKV用纯文本，TiDB Dashboard用JSON但嵌套极深。Exporter用Python的requests库统一处理，对TiKV的/status接口返回的{"version":"6.5.0","status":"up"}这种极简响应，会主动补全uptime、start_time等字段；对TiDB Dashboard的/api/v1/statement/summary，则解析其avg_latency、exec_count等数组，按SQL指纹（digest）聚合后输出。

第二层：指标降噪
TiDB的/metrics接口每秒产生上万条指标，但Zabbix只需关键信号。Exporter内置白名单机制，只保留约200个核心指标。例如过滤掉tidb_executor_select_total这种无业务意义的计数器，而保留tidb_executor_select_latency_seconds_bucket的P99延迟桶。更重要的是，对tidb_tikvclient_region_err_total这类错误计数器，Exporter会计算每分钟增量（而非原始累计值），避免Zabbix触发器因计数器重置误判。

第三层：上下文注入
这是金融场景的关键。Exporter在采集每个Store指标时，会主动调用PD的/pd/api/v1/stores/{store_id}接口，获取该Store所在的labels（如{"zone":"cn-beijing-a","rack":"rack-01","host":"server01"}），然后把这些label转成Zabbix的host_metadata，最终在Zabbix前端显示为“server01-rack-01-cn-beijing-a”。这样当某个Store告警时，运维人员一眼就能看出它属于哪个可用区、哪台物理机。

实际部署时，Exporter以Systemd服务运行，配置文件exporter.conf关键参数如下：

[pd] url = https://pd01:2379/pd/api/v1 timeout = 5 # 启用mTLS认证 cert = /etc/tidb/exporter/pd-client.crt key = /etc/tidb/exporter/pd-client.key ca = /etc/tidb/exporter/ca.crt [tikv] # 支持批量采集，减少API调用次数 batch_size = 5 # 自动跳过已下线Store skip_offline = true [exporter] listen_port = 9101 # 指标缓存时间，避免Zabbix高频拉取 cache_ttl = 30

实测下来，单个Exporter可稳定支撑50个TiKV Store、20个TiDB实例的采集，CPU占用率始终低于15%，比用Zabbix原生HTTP agent方案低60%。

3.2 Zabbix Agent2的关键配置项

Zabbix Agent2必须启用zabbix_agent2二进制而非旧版zabbix_agentd，因为只有Agent2支持system.run的超时控制和JSON解析。核心配置段如下：

# /etc/zabbix/zabbix_agent2.d/userparameter_tidb.conf UserParameter=tidb.pd.leader.status, curl -s --cacert /etc/zabbix/ssl/ca.crt --cert /etc/zabbix/ssl/client.crt --key /etc/zabbix/ssl/client.key https://pd01:2379/pd/api/v1/leader | jq -r '.name' UserParameter=tidb.tikv.store.status[*], curl -s --cacert /etc/zabbix/ssl/ca.crt https://$1:20180/status | jq -r '.status' UserParameter=tidb.metrics.query[*], curl -s http://localhost:9101/metrics | grep "$1" | head -1 | awk '{print $2}'

特别注意UserParameter的[*]语法——它允许Zabbix在LLD发现时动态传入store_id，比如tidb.tikv.store.status[store-5]。而jq命令必须预装，且版本≥1.6，否则解析TiDB Dashboard的嵌套JSON会失败。

提示：Zabbix Server端必须开启AllowRoot=1，否则Agent2无法加载SSL证书。但生产环境严禁用root运行Agent2，我们的解法是在Systemd服务文件中用User=zabbix，然后用setcap 'cap_net_bind_service=+ep' /usr/sbin/zabbix_agent2赋予绑定低端口权限。

3.3 Low-Level Discovery（LLD）规则详解

LLD是让Zabbix自动感知TiDB拓扑的核心。我们创建了三个LLD规则：

• PD节点发现：调用curl https://pd01:2379/pd/api/v1/members，用JSONPath提取$.members[*].name和$.members[*].client_urls；
• TiKV Store发现：调用curl http://localhost:9101/discover/stores（Exporter提供的发现接口），返回[{"store_id":"1","address":"tikv01:20160","labels":{"zone":"a"}}]；
• TiDB实例发现：调用curl http://localhost:9101/discover/tidbs，返回[{"instance_id":"tidb-01","ip":"10.0.1.101"}]。

LLD规则的关键在于“过滤器”设置。比如TiKV Store发现规则，我们加了{#STORE_STATUS} matches "Up"的过滤条件，确保只发现健康Store。而Zabbix的“原型”（Prototype）里，每个监控项都绑定{#STORE_ID}宏，这样tidb.tikv.store.region_leader[{#STORE_ID}]就能自动展开为tidb.tikv.store.region_leader[store-5]。

实操中最大的坑是LLD缓存。Zabbix默认每3600秒刷新一次发现结果，但TiDB的Store可能随时下线。我们把刷新间隔改成120s，并在Exporter里加了/discovery/refresh端点，当PD API返回store_status变更时，主动调用Zabbix Server的discovery.checknowAPI强制刷新——这个细节让故障发现时间从分钟级降到秒级。

4. 关键告警规则与根因定位实践

4.1 Region Leader分布不均的精准告警

TiDB的Region均衡是PD自动调度的，但当出现“某个Store长期承担过多Leader”时，说明调度算法失效或存在硬件瓶颈。传统做法是告警“Leader数>平均值2倍”，但这在小集群（如4个Store）下极易误报。我们改用统计学方法：

• 计算所有Store的Leader数标准差σ；
• 当最大Leader数 > 平均值 + 2σ时，才触发告警；
• 同时关联tidb_pd_scheduler_balance_leader_duration_seconds指标，确认PD是否在持续尝试调度但失败。

Zabbix触发器表达式如下：

{TiDB Cluster:tidb.tikv.store.region_leader[{#STORE_ID}].max(5m)} > ({TiDB Cluster:tidb.tikv.store.region_leader.avg()} + 2 * {TiDB Cluster:tidb.tikv.store.region_leader.stddev()})

这个公式在某次真实故障中发挥了关键作用：当server03的SSD出现坏块时，其Store的Leader数缓慢下降（从12000降到8000），而server01的Leader数升到18000。标准差告警在第37分钟触发，比单纯看最大值告警早了22分钟，为更换磁盘争取了黄金时间。

4.2 Write Stall的复合判断逻辑

TiKV的Write Stall是性能雪崩前兆，但单一指标（如tikv_engine_write_stall_reason）容易误判。我们构建了三因子复合判断：

1. 写入延迟突增：tikv_storage_async_request_duration_seconds_bucket{le="0.1"} < 0.95（P95写入延迟>100ms）；
2. 后台压缩积压：tikv_rocksdb_compaction_pending_bytes > 1073741824（待压缩数据>1GB）；
3. Stall触发次数：increase(tikv_engine_write_stall_reason_total[5m]) > 3（5分钟内触发3次以上）。

Zabbix中用“AND”连接三个条件，但关键在时间窗口设置：延迟和压缩指标用5m滑动窗口，而Stall次数用5m区间增量。这样既避免瞬时抖动，又能捕捉持续恶化趋势。某次线上事故中，该规则在Stall首次触发后第4分钟就告警，而应用层的超时错误在第7分钟才出现，真正实现了故障预测。

4.3 慢查询根因的自动化下钻

Zabbix本身不存SQL文本，但我们利用TiDB Dashboard的/api/v1/statement/summary接口，让Exporter定期抓取Top 10慢查询的digest（SQL指纹），并存入Zabbix的text类型历史表。当Zabbix检测到tidb_statement_summary_max_latency_seconds > 5时，自动触发一个Action：

• 调用Zabbix API获取最近10条该digest的avg_latency、exec_count；
• 用curl请求TiDB Dashboard的/api/v1/statement/digest_text?digest=xxx获取原始SQL；
• 将SQL、执行计划（EXPLAIN ANALYZE结果）、涉及表的Region分布图（通过PD API生成）打包成PDF，邮件发送给DBA。

这个流程把原来需要30分钟的手动排查，压缩到90秒内。最典型的应用是识别“隐式类型转换”问题：某条WHERE user_id = '123'的查询，因user_id是INT类型，导致索引失效。Exporter抓取的digest显示其P99延迟从20ms飙升到2000ms，而PDF报告里直接标红了Type: string和Key: INT的冲突提示。

5. 实施过程中的典型问题与独家排障技巧

5.1 问题一：Zabbix Server CPU飙升，但Agent2日志无异常

现象：Zabbix Server负载突然从0.5升到12，zabbix_server.log里全是cannot send data to [10.0.1.101]:10050错误，但Agent2进程正常，netstat显示连接通畅。

根因分析：我们检查了Exporter的/metrics端点，发现返回内容长达12MB——因为TiDB的/metrics接口默认返回所有指标，而Exporter的白名单配置被意外注释掉了。Zabbix Server在解析超大文本时，正则引擎陷入回溯爆炸（catastrophic backtracking），导致CPU锁死。

解决步骤：

1. 立即在Exporter配置中取消注释[metrics]段的whitelist_file = /etc/tidb/exporter/whitelist.txt；
2. 重启Exporter，验证curl localhost:9101/metrics | wc -c返回值<500KB；
3. 在Zabbix Server的zabbix_server.conf中增加StartPollers=100（原为50），提升并发解析能力；
4. 最关键一步：在Zabbix Web界面，进入“Administration → General → Other”，把“History storage period”从90天改为30天，减少Server端历史数据处理压力。

注意：这个坑我们踩了两次。第一次修复后没改历史存储周期，一周后CPU再次飙升。后来发现Zabbix Server在清理过期历史数据时，会扫描所有监控项的原始值，而超大指标文本会让扫描变慢。所以必须双管齐下。

5.2 问题二：TiKV Store在Zabbix中状态忽上忽下

现象：Zabbix前端显示某个Store在“Up”和“Unknown”之间频繁切换，但curl http://tikv01:20180/status始终返回{"status":"up"}。

排查过程：

• 先确认Exporter日志：tail -f /var/log/tidb-exporter.log，发现大量Connection refused；
• 登录tikv01服务器，ss -tuln | grep 20180显示端口监听正常；
• curl -v http://localhost:20180/status成功，但curl -v http://10.0.1.101:20180/status超时；
• 终于发现：TiKV的status-addr配置为0.0.0.0:20180，但防火墙只放行了127.0.0.1的访问，其他IP被DROP。

终极解法：

• 在tikv01上执行iptables -I INPUT -p tcp --dport 20180 -j ACCEPT；
• 更稳妥的是修改TiKV配置：[server] status-addr = "10.0.1.101:20180"，让Exporter直连具体IP；
• 在Zabbix的LLD规则里，把Store地址从{#STORE_ADDRESS}改为{#STORE_IP}:{#STORE_PORT}，避免DNS解析引入额外延迟。

这个案例告诉我们：分布式系统的监控链路，任何一个环节的网络策略都可能成为单点故障。我们后来在Exporter里加了“健康检查探针”，每次采集前先ping目标IP，失败则跳过并记录warn日志，彻底杜绝了状态抖动。

5.3 问题三：PD leader切换告警频繁，但业务无感知

现象：Zabbix每天收到20+次PD leader切换告警，但TPS、延迟等业务指标平稳，DBA确认是正常调度。

深度分析：PD leader切换本身是高可用设计，但频繁切换说明PD集群存在不稳定因素。我们用curl https://pd01:2379/pd/api/v1/stats/raft查看raft状态，发现failed_proposal计数每小时增长100+。进一步检查PD日志，发现etcd的snapshot save耗时过长（>5s），原因是PD数据目录挂载在普通SATA盘上。

优化方案：

• 将PD的># pd.yaml config: schedule: max-snapshot-count: 3 # 限制并发快照数 replication: max-replicas: 3 # etcd.yml>