【金仓数据库征文】KFS集群监控指标体系设计:从“看见故障”到“量化RTO/RPO” 文章目录每日一句正能量一、背景与问题二、环境与数据2.1 脱敏环境2.2 监控对象划分2.3 指标命名原则三、复现过程为什么“主机正常”仍可能业务中断3.1 复现一VIP 存在但数据库未就绪3.2 复现二共享存储单路径失效未触发主机告警3.3 复现三集群接管成功但连接池重试风暴3.4 复现四写请求返回超时但事务实际已提交四、方案实施4.1 指标体系总表4.1.1 主机与系统层4.1.2 网络层4.1.3 共享存储层4.1.4 KFS 集群层4.1.5 数据库层4.1.6 业务层4.2 RTO/RPO 指标设计4.2.1 T0T7 时间点4.2.2 RPO 核验4.3 告警分级与收敛4.4 监控部署流程第一步建立基线第二步部署采集器第三步配置告警第四步影子运行第五步故障演练4.5 故障注入与验证矩阵4.6 Prometheus 告警规则示例4.7 仪表盘设计总览页故障时间线页容量与趋势页五、结果对比5.1 监控体系实施前后5.2 脱敏演练示例5.3 监控质量指标六、风险与复盘6.1 阈值不能照抄6.2 监控脚本不能成为新故障源6.3 不能把“资源在线”当作“业务恢复”6.4 FENCE 指标优先级最高6.5 RPO 必须用业务语言表达6.6 检查清单必须进入变更流程附录一上线检查清单摘要部署前演练前演练中演练后每日一句正能量学习是一项人生回报率很高的投资。学习的复利效应越早开始、持续越久回报越可观。“回报率高”体现在多个维度认知提升、选择权增加、抗风险能力增强、内心更稳定。而且这种投资几乎稳赚不赔——学到的东西永远属于自己。一、背景与问题很多团队已经部署了数据库高可用集群却仍然无法回答三个最基本的问题故障是否已经发生集群是否已经安全接管业务是否真正恢复数据是否满足 RPO造成这一问题的根源是监控体系往往停留在“主机 CPU、内存、磁盘利用率”层面。对于 KFS 这类共享存储集群仅看主机指标远远不够。节点可能在线但集群资源已经漂移失败VIP 可能存在但数据库尚未接受写入实例可能启动成功但连接池仍在反复重连业务接口可能返回成功却出现未知提交、重复写入或账务汇总差异。因此监控设计不能只围绕“设备是否活着”而要围绕完整恢复链路建立指标基础设施 → 集群资源 → 数据库实例 → 数据访问 → 业务探针 → 数据一致性 → RTO/RPO。本文给出的目标不是堆砌指标而是形成一套可执行的运维闭环有清晰的指标分层每个告警都有阈值、持续时间和动作能通过故障注入验证告警是否真正生效能自动记录 T0T7 时间点能量化技术 RTO、业务 RTO 和业务 RPO有部署、演练、恢复和复盘检查清单。二、环境与数据2.1 脱敏环境项目示例配置数据库KingbaseES生产兼容模式集群KFS 两节点共享存储集群节点kfs-db01、kfs-db02业务入口漂移 VIP10.20.30.100存储双控制器共享存储双路径多路径访问FENCE带外电源隔离或等效 STONITH监控平台Prometheus Alertmanager Grafana采集周期15 秒关键探针 5 秒演练业务订单写入、订单查询、余额汇总峰值负载800 TPS连接数约 450目标 RTO技术 RTO ≤ 60 秒业务 RTO ≤ 120 秒目标 RPO已确认提交数据丢失为 02.2 监控对象划分监控对象按七层组织主机与操作系统层CPU、内存、负载、时钟、文件句柄、关键进程。网络层VIP、心跳链路、业务链路、管理链路、丢包、时延、连接失败率。共享存储层多路径、路径抖动、I/O 时延、队列、挂载、只读状态。KFS 集群层节点成员、资源状态、资源迁移、FENCE、仲裁、故障次数。数据库层实例状态、连接、事务、锁、等待、WAL/日志、检查点、临时空间。业务层连接探针、读探针、写探针、接口成功率、P95/P99、重试率。连续性层T0T7、技术 RTO、业务 RTO、未知提交、重复请求、数据差异。2.3 指标命名原则建议采用统一命名kfs_对象_指标_单位 kingbase_对象_指标_单位 biz_业务_指标_单位 dr_连续性_指标_单位标签至少包含cluster、node、resource、role、instance、service、env、region标签数量必须受控。订单号、SQL 文本、会话 ID 等高基数字段不能直接作为 Prometheus 标签否则会引起时间序列膨胀。三、复现过程为什么“主机正常”仍可能业务中断3.1 复现一VIP 存在但数据库未就绪故障演练中资源切换后 VIP 已漂移到备用节点网络监控立即恢复为绿色。但数据库仍在执行崩溃恢复业务连接持续失败 27 秒。如果监控只检查ping VIP会错误判断业务已经恢复。正确做法是设置三级探针L1TCP 端口可连接 L2执行 SELECT 1 L3执行带唯一请求号的幂等写入并回读只有 L3 成功才能认定写业务恢复。3.2 复现二共享存储单路径失效未触发主机告警注入一条存储路径故障后文件系统仍可读写主机、数据库和 VIP 均正常。由于剩余路径承载全部 I/O平均写时延由 2.8 ms 升至 18.6 msP99 达到 73 ms。业务还未失败但已经进入高风险状态。如果只监控“磁盘是否挂载”无法提前发现风险。必须监控有效路径数量路径状态变化单路径负载不均I/O 平均时延与 P99队列长度文件系统只读多路径切换次数。3.3 复现三集群接管成功但连接池重试风暴节点故障后数据库 39 秒完成接管但应用连接池继续持有旧连接。大量请求同时重试使新节点连接数在 12 秒内从 30 增至 920超过连接上限。技术层面已经恢复业务层面却二次雪崩。因此需要同时观察当前连接数与连接上限占比每秒新建连接登录失败率连接池等待线程应用重试次数数据库拒绝连接次数。3.4 复现四写请求返回超时但事务实际已提交在节点断电前 100 毫秒发起写请求客户端收到超时但目标库中数据已经提交。应用若无幂等机制会重试并产生重复订单。这类问题不能只靠数据库行数判断必须以业务唯一请求号核验SELECTrequest_id,COUNT(*)FROMops_monitor.biz_probe_orderWHEREtest_batch:batch_idGROUPBYrequest_idHAVINGCOUNT(*)1;四、方案实施4.1 指标体系总表4.1.1 主机与系统层指标采集方式建议预警建议严重说明CPU 使用率node exporter75% 持续 10 分钟90% 持续 5 分钟与 run queue 联合判断Load/CPU 核数node exporter1.22.0单独看 load 容易误判可用内存node exporter15%8%同时看 swap in/outSwap 活跃node exporter10 MB/min100 MB/min数据库节点通常应非常低文件句柄占比node exporter70%90%防止连接高峰耗尽时间偏差chrony exporter100 ms500 ms影响日志排序和仲裁判断关键进程process exporter进程消失 1 次连续 2 个周期消失避免一次采样抖动4.1.2 网络层指标预警阈值严重阈值持续时间业务网 RTT20 ms80 ms3 分钟心跳网 RTT5 ms20 ms30 秒丢包率0.2%1%1 分钟TCP 重传率1%5%3 分钟VIP 不可达1 次失败连续 3 次失败15 秒数据库端口失败1 次失败连续 2 次失败10 秒单向链路异常任一方向失败持续 15 秒15 秒心跳网阈值应比业务网更严格。阈值不能直接照搬必须基于生产基线和网络设备特性校准。4.1.3 共享存储层指标预警阈值严重阈值有效路径数少于基线 1 条仅剩 1 条或 0 条平均读时延10 ms30 ms平均写时延10 ms30 msP99 I/O 时延50 ms100 msI/O 队列长度设备基线 2 倍基线 5 倍文件系统利用率80%90%inode 利用率80%90%文件系统只读—立即严重多路径切换次数5 分钟内 15 分钟内 34.1.4 KFS 集群层KFS 层是整套体系的核心至少需要以下指标kfs_node_online kfs_node_role kfs_resource_online kfs_resource_owner kfs_resource_fail_count kfs_resource_restart_count kfs_failover_total kfs_last_failover_timestamp kfs_fence_success kfs_fence_duration_seconds kfs_cluster_quorum kfs_shared_disk_owner_count kfs_resource_state_change_total建议告警规则事件告警等级触发条件节点离线严重任一生产节点离线超过 15 秒集群失去仲裁灾难quorum0立即告警资源非唯一归属灾难共享资源归属节点数不等于 1FENCE 失败灾难隔离动作返回失败或超时资源反复迁移严重10 分钟内迁移 ≥2 次数据库资源离线严重资源离线超过 10 秒VIP 与数据库不在同一节点严重连续 2 个周期不一致故障计数增长预警1 小时内增长 ≥1资源状态 UNKNOWN严重持续 15 秒最重要的组合规则是共享盘唯一归属 1 AND 数据库资源在线 1 AND VIP 所有者 数据库资源所有者 AND 旧节点写探针失败 AND 新节点写探针成功只要其中一项不满足都不能认定安全接管完成。4.1.5 数据库层数据库指标应同时覆盖容量、性能与故障恢复。-- 活跃会话与等待SELECTstate,wait_event_type,wait_event,COUNT(*)ASsessionsFROMsys_stat_activityGROUPBYstate,wait_event_type,wait_eventORDERBYsessionsDESC;-- 长事务SELECTpid,current_timestamp-xact_startASxact_age,current_timestamp-query_startASquery_age,state,left(query,120)ASsample_sqlFROMsys_stat_activityWHERExact_startISNOTNULLORDERBYxact_ageDESC;-- 连接使用率SELECTCOUNT(*)AScurrent_connections,current_setting(max_connections)::intASmax_connections,ROUND(COUNT(*)*100.0/current_setting(max_connections)::int,2)ASusage_pctFROMsys_stat_activity;建议重点指标指标预警严重连接使用率70%90%活跃会话数基线 1.5 倍基线 3 倍长事务时长5 分钟15 分钟阻塞链长度≥2≥5死锁1 小时 ≥110 分钟 ≥2临时文件增长基线 2 倍持续增长 10 分钟检查点频率高于基线 2 倍高于基线 4 倍日志目录空间20%10%数据目录空间20%10%SQL P95基线 1.5 倍基线 3 倍4.1.6 业务层业务指标必须由真实应用链路或等价探针产生。biz_connect_probe_success biz_read_probe_success biz_write_probe_success biz_api_success_rate biz_api_p95_seconds biz_api_p99_seconds biz_retry_total biz_unknown_commit_total biz_duplicate_request_total biz_connection_pool_wait_threads建议门槛连接探针失败立即预警连续 2 次严重读探针失败连续 2 次严重写探针失败1 次预警连续 2 次严重5 分钟接口成功率低于 99.5%预警1 分钟接口成功率低于 95%严重P95 高于基线 2 倍预警未知提交数大于 0严重重复请求数大于 0严重。4.2 RTO/RPO 指标设计4.2.1 T0T7 时间点时间点含义T0故障注入开始T1监控首次发现异常T2集群确认故障T3旧节点完成隔离T4资源开始迁移T5数据库端口恢复T6写探针首次成功T7业务成功率恢复并稳定计算方式告警发现时间 T1 - T0 集群判定时间 T2 - T0 安全隔离时间 T3 - T0 技术 RTO T5 - T0 写服务 RTO T6 - T0 业务 RTO T7 - T0业务 RTO 比技术 RTO 更有价值。数据库启动完成并不等于应用已经恢复。4.2.2 RPO 核验共享存储集群通常以“已确认提交不丢失”为目标但演练仍需核验三类数据已确认提交客户端超时、结果未知自动重试产生的重复请求。建议在演练前生成一批带唯一请求号的写入CREATESCHEMAIFNOTEXISTSops_monitor;CREATETABLEIFNOTEXISTSops_monitor.biz_probe_order(request_idvarchar(64)PRIMARYKEY,test_batchvarchar(32)NOTNULL,amountnumeric(18,2)NOTNULL,request_timetimestampNOTNULL,commit_timetimestampDEFAULTcurrent_timestamp,node_namevarchar(64),result_statevarchar(20));演练后执行-- 重复检查SELECTrequest_id,COUNT(*)FROMops_monitor.biz_probe_orderWHEREtest_batch:batch_idGROUPBYrequest_idHAVINGCOUNT(*)1;-- 数量与金额检查SELECTtest_batch,COUNT(*)ASrow_count,SUM(amount)AStotal_amount,MIN(request_time)ASmin_time,MAX(request_time)ASmax_timeFROMops_monitor.biz_probe_orderWHEREtest_batch:batch_idGROUPBYtest_batch;RPO 结论不能只写“0”应附带发起请求数明确成功数明确失败数未知提交数目标库存在数重复数差异数。4.3 告警分级与收敛建议采用四级等级场景响应P1 灾难仲裁丢失、双写风险、共享盘多归属、FENCE 失败电话短信IM立即升级P2 严重数据库离线、VIP 漂移失败、写探针失败5 分钟内响应P3 预警单路径故障、时延升高、连接数升高30 分钟内处理P4 提示资源切换完成、节点重新纳管留痕即可告警必须做依赖抑制。例如数据库实例离线由节点掉电引起时应以“节点故障”为根告警抑制几十条从属告警避免值班人员被告警风暴淹没。建议的关联关系节点离线 ├─ 抑制该节点进程离线 ├─ 抑制该节点端口失败 ├─ 抑制该节点文件系统不可达 └─ 保留集群接管、FENCE、业务探针告警4.4 监控部署流程第一步建立基线至少连续采集 714 天形成工作日与周末基线峰值、均值、P95、P99正常资源迁移耗时正常数据库启动耗时连接池重建耗时存储延迟与网络延迟基线。第二步部署采集器部署顺序建议主机与进程采集器网络和黑盒探针多路径与存储采集脚本KFS 状态采集脚本数据库 exporter业务读写探针RTO/RPO 事件记录组件。所有自定义脚本必须具备超时只读错误码空结果处理锁防重入日志轮转最低权限账号。第三步配置告警先配置静态阈值再根据基线调整。涉及双写、仲裁和 FENCE 的安全指标不能使用宽松的动态阈值。第四步影子运行告警先运行 7 天但不通知值班人员统计每日告警数误报数漏报数重复告警数无处置动作告警数。只有达到可控水平后再正式启用。第五步故障演练演练顺序必须从低风险到高风险停止非关键采集器单条存储路径故障业务网轻微丢包心跳网络抖动数据库进程异常VIP 资源异常活动节点断电FENCE 失败模拟仅在隔离实验环境开展。4.5 故障注入与验证矩阵场景注入方法必须触发的告警必须验证的恢复点单存储路径失效禁用一条路径路径数量下降、I/O 风险业务不中断、路径可恢复网络延迟 100mstc netemRTT、重传、业务 P95不误切换或按策略切换丢包 3%tc netem丢包、连接失败重试不形成风暴数据库进程退出受控停止资源离线、端口失败自动拉起或迁移VIP 资源停止停止 VIP 资源VIP 失败、业务探针失败VIP 与实例归属一致活动节点断电带外控制节点离线、FENCE、迁移旧节点隔离、新节点接管多路径全部失效隔离实验环境I/O 严重、文件系统异常不出现双写与错误接管连接池重试风暴压测脚本新建连接速率、拒绝连接限流与退避生效每个演练场景必须输出四份证据告警截图或事件记录集群状态与日志T0T7 时间线数据一致性核验结果。4.6 Prometheus 告警规则示例groups:-name:kfs-criticalrules:-alert:KFSClusterLostQuorumexpr:kfs_cluster_quorum 0for:10slabels:severity:disasterannotations:summary:KFS集群失去仲裁description:集群 {{ $labels.cluster }} 已连续10秒无仲裁禁止手工启动数据库资源。-alert:KFSSharedDiskOwnerInvalidexpr:kfs_shared_disk_owner_count!1for:5slabels:severity:disasterannotations:summary:共享存储归属异常description:共享盘归属节点数为 {{ $value }}存在无主或多主风险。-alert:KFSFenceFailedexpr:kfs_fence_success 0for:1slabels:severity:disasterannotations:summary:故障节点隔离失败description:FENCE未成功禁止在其他节点强制挂载共享盘。-alert:KFSResourceFlappingexpr:increase(kfs_resource_state_change_total[10m]) 4for:1mlabels:severity:criticalannotations:summary:集群资源反复切换description:资源 {{ $labels.resource }} 10分钟内状态变化超过阈值。-alert:BusinessWriteProbeFailedexpr:biz_write_probe_success 0for:10slabels:severity:criticalannotations:summary:数据库写探针失败description:业务写探针连续失败技术资源在线不代表业务已恢复。4.7 仪表盘设计建议按“值班视角”设计而不是按组件堆面板。总览页第一屏只展示 12 个核心信息集群总体状态当前活动节点仲裁状态共享盘唯一归属FENCE 状态VIP 所有者数据库资源状态连接探针读探针写探针最近一次业务 RTO未知提交与重复请求数量。故障时间线页把节点、网络、存储、集群资源、数据库、业务探针放在同一时间轴上方便回答最早异常出现在哪里监控多久发现集群多久判定FENCE 是否先于资源接管完成业务恢复慢在数据库、网络还是连接池容量与趋势页展示 7 天、30 天趋势服务于阈值调整和容量规划避免将所有实时指标塞到总览页。五、结果对比5.1 监控体系实施前后对比项实施前实施后故障发现依赖人工报障15 秒内自动发现集群判断只看节点在线节点、仲裁、FENCE、资源归属联合判断业务恢复以数据库启动为准以写探针和接口成功率为准RTO口头估算T0T7 自动记录RPO默认认为 0按请求号核验成功、未知、重复和差异存储风险只看挂载路径数量、时延、队列、只读状态告警数量故障时数十条根因告警依赖抑制演练结果日志分散指标、告警、时间线、对账统一归档5.2 脱敏演练示例活动节点断电后记录阶段耗时T1 首次告警8 秒T2 集群确认故障15 秒T3 FENCE 完成24 秒T4 资源迁移开始27 秒T5 数据库端口恢复49 秒T6 写探针成功58 秒T7 业务成功率恢复76 秒因此技术 RTO 49 秒 写服务 RTO 58 秒 业务 RTO 76 秒演练批次共发起 12,000 个请求明确成功11,842 明确失败146 结果未知12 目标库存在11,854 重复请求0 差异请求012 个结果未知请求全部在目标库中查到说明客户端虽未收到确认但事务已提交。由于请求号唯一约束生效应用重试没有产生重复订单。5.3 监控质量指标监控平台本身也要被考核指标目标关键指标采集成功率≥99.9%告警发现延迟≤15 秒告警通知成功率≥99.9%误报率2%漏报率0无处置动作告警占比10%演练证据完整率100%六、风险与复盘6.1 阈值不能照抄不同硬件、业务量和网络环境差异很大。CPU 80%、I/O 10 ms、连接数 500 都不是天然故障。正确做法是安全类指标使用硬阈值性能类指标使用基线和趋势容量类指标使用剩余时间预测业务类指标以成功率和延迟为主。6.2 监控脚本不能成为新故障源自定义采集脚本若无超时或执行重查询会反过来压垮数据库。生产采集必须限制执行时间、频率和权限。禁止每 5 秒扫描大表也禁止将完整 SQL 文本作为高基数标签。6.3 不能把“资源在线”当作“业务恢复”KFS 资源状态为 Online只能说明集群管理器认为资源已启动。业务恢复必须由真实连接、读取、写入和接口成功率确认。6.4 FENCE 指标优先级最高共享存储集群最危险的不是停机而是旧节点未隔离时新节点强制接管。任何“快速恢复”都不能绕过隔离确认。FENCE 失败、共享盘归属异常和双写风险必须设置为最高级告警并明确禁止自动继续。6.5 RPO 必须用业务语言表达“数据库没有丢块”不等于“业务没有丢单”。最终复盘应回答哪些请求明确成功哪些请求明确失败哪些请求状态未知未知请求在目标库中是否存在是否出现重复订单金额、数量和状态汇总是否一致6.6 检查清单必须进入变更流程监控上线、阈值调整和故障演练都应纳入变更审批。检查清单不是文章附件而是生产操作的一部分。每一项都应有责任人、完成时间、证据链接和结论。附录一上线检查清单摘要部署前确认集群拓扑、节点、VIP、共享盘和 FENCE 清单确认管理网不受故障注入影响确认监控账号最小权限建立 714 天性能基线验证采集脚本超时与防重入验证告警路由和升级联系人验证监控平台自身高可用演练前业务负责人、DBA、系统、网络、存储人员到位明确停止条件和回退负责人记录 T0 前集群资源状态确认旧节点隔离能力启动带唯一请求号的业务探针确认对账 SQL 可执行确认故障注入脚本自动清理演练中记录 T0T7确认告警按预期触发确认无告警风暴确认 FENCE 完成后再接管确认共享盘始终唯一归属观察连接池重试与新建连接速率记录未知提交请求演练后执行重复请求检查执行数量和金额汇总检查长事务、锁和异常会话恢复所有网络、存储和节点配置验证节点重新纳管校准告警阈值形成复盘报告和整改责任人转载自https://blog.csdn.net/u014727709/article/details/163325514欢迎 点赞✍评论⭐收藏欢迎指正

本月热点