企业官网建设流程全解析

每日一句正能量

学习是一项人生回报率很高的投资。
学习的复利效应：越早开始、持续越久，回报越可观。“回报率高”体现在多个维度：认知提升、选择权增加、抗风险能力增强、内心更稳定。而且这种投资几乎稳赚不赔——学到的东西，永远属于自己。

一、背景与问题

很多团队已经部署了数据库高可用集群，却仍然无法回答三个最基本的问题：

1. 故障是否已经发生？
2. 集群是否已经安全接管？
3. 业务是否真正恢复，数据是否满足 RPO？

造成这一问题的根源，是监控体系往往停留在“主机 CPU、内存、磁盘利用率”层面。对于 KFS 这类共享存储集群，仅看主机指标远远不够。节点可能在线，但集群资源已经漂移失败；VIP 可能存在，但数据库尚未接受写入；实例可能启动成功，但连接池仍在反复重连；业务接口可能返回成功，却出现未知提交、重复写入或账务汇总差异。

因此，监控设计不能只围绕“设备是否活着”，而要围绕完整恢复链路建立指标：

基础设施 → 集群资源 → 数据库实例 → 数据访问 → 业务探针 → 数据一致性 → RTO/RPO。

本文给出的目标不是堆砌指标，而是形成一套可执行的运维闭环：

• 有清晰的指标分层；
• 每个告警都有阈值、持续时间和动作；
• 能通过故障注入验证告警是否真正生效；
• 能自动记录 T0～T7 时间点；
• 能量化技术 RTO、业务 RTO 和业务 RPO；
• 有部署、演练、恢复和复盘检查清单。

二、环境与数据

2.1 脱敏环境

2.2 监控对象划分

监控对象按七层组织：

1. 主机与操作系统层：CPU、内存、负载、时钟、文件句柄、关键进程。
2. 网络层：VIP、心跳链路、业务链路、管理链路、丢包、时延、连接失败率。
3. 共享存储层：多路径、路径抖动、I/O 时延、队列、挂载、只读状态。
4. KFS 集群层：节点成员、资源状态、资源迁移、FENCE、仲裁、故障次数。
5. 数据库层：实例状态、连接、事务、锁、等待、WAL/日志、检查点、临时空间。
6. 业务层：连接探针、读探针、写探针、接口成功率、P95/P99、重试率。
7. 连续性层：T0～T7、技术 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，会错误判断业务已经恢复。

正确做法是设置三级探针：

L1：TCP 端口可连接 L2：执行 SELECT 1 L3：执行带唯一请求号的幂等写入并回读

只有 L3 成功，才能认定写业务恢复。

3.2 复现二：共享存储单路径失效未触发主机告警

注入一条存储路径故障后，文件系统仍可读写，主机、数据库和 VIP 均正常。由于剩余路径承载全部 I/O，平均写时延由 2.8 ms 升至 18.6 ms，P99 达到 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 主机与系统层

4.1.2 网络层

心跳网阈值应比业务网更严格。阈值不能直接照搬，必须基于生产基线和网络设备特性校准。

4.1.3 共享存储层

4.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

建议告警规则：

最重要的组合规则是：

共享盘唯一归属 = 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;

建议重点指标：

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 T0～T7 时间点

计算方式：

告警发现时间 = T1 - T0 集群判定时间 = T2 - T0 安全隔离时间 = T3 - T0 技术 RTO = T5 - T0 写服务 RTO = T6 - T0 业务 RTO = T7 - T0

业务 RTO 比技术 RTO 更有价值。数据库启动完成并不等于应用已经恢复。

4.2.2 RPO 核验

共享存储集群通常以“已确认提交不丢失”为目标，但演练仍需核验三类数据：

1. 已确认提交；
2. 客户端超时、结果未知；
3. 自动重试产生的重复请求。

建议在演练前生成一批带唯一请求号的写入：

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 告警分级与收敛

建议采用四级：

告警必须做依赖抑制。例如数据库实例离线由节点掉电引起时，应以“节点故障”为根告警，抑制几十条从属告警，避免值班人员被告警风暴淹没。

建议的关联关系：

节点离线 ├─ 抑制该节点进程离线 ├─ 抑制该节点端口失败 ├─ 抑制该节点文件系统不可达 └─ 保留集群接管、FENCE、业务探针告警

4.4 监控部署流程

第一步：建立基线

至少连续采集 7～14 天，形成：

• 工作日与周末基线；
• 峰值、均值、P95、P99；
• 正常资源迁移耗时；
• 正常数据库启动耗时；
• 连接池重建耗时；
• 存储延迟与网络延迟基线。

第二步：部署采集器

部署顺序建议：

1. 主机与进程采集器；
2. 网络和黑盒探针；
3. 多路径与存储采集脚本；
4. KFS 状态采集脚本；
5. 数据库 exporter；
6. 业务读写探针；
7. RTO/RPO 事件记录组件。

所有自定义脚本必须具备：

• 超时；
• 只读；
• 错误码；
• 空结果处理；
• 锁防重入；
• 日志轮转；
• 最低权限账号。

第三步：配置告警

先配置静态阈值，再根据基线调整。涉及双写、仲裁和 FENCE 的安全指标不能使用宽松的动态阈值。

第四步：影子运行

告警先运行 7 天但不通知值班人员，统计：

• 每日告警数；
• 误报数；
• 漏报数；
• 重复告警数；
• 无处置动作告警数。

只有达到可控水平后再正式启用。

第五步：故障演练

演练顺序必须从低风险到高风险：

1. 停止非关键采集器；
2. 单条存储路径故障；
3. 业务网轻微丢包；
4. 心跳网络抖动；
5. 数据库进程异常；
6. VIP 资源异常；
7. 活动节点断电；
8. FENCE 失败模拟，仅在隔离实验环境开展。

4.5 故障注入与验证矩阵

每个演练场景必须输出四份证据：

1. 告警截图或事件记录；
2. 集群状态与日志；
3. T0～T7 时间线；
4. 数据一致性核验结果。

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 个核心信息：

1. 集群总体状态；
2. 当前活动节点；
3. 仲裁状态；
4. 共享盘唯一归属；
5. FENCE 状态；
6. VIP 所有者；
7. 数据库资源状态；
8. 连接探针；
9. 读探针；
10. 写探针；
11. 最近一次业务 RTO；
12. 未知提交与重复请求数量。

故障时间线页

把节点、网络、存储、集群资源、数据库、业务探针放在同一时间轴上，方便回答：

• 最早异常出现在哪里？
• 监控多久发现？
• 集群多久判定？
• FENCE 是否先于资源接管完成？
• 业务恢复慢在数据库、网络还是连接池？

容量与趋势页

展示 7 天、30 天趋势，服务于阈值调整和容量规划，避免将所有实时指标塞到总览页。

五、结果对比

5.1 监控体系实施前后

5.2 脱敏演练示例

活动节点断电后记录：

因此：

技术 RTO = 49 秒 写服务 RTO = 58 秒 业务 RTO = 76 秒

演练批次共发起 12,000 个请求：

明确成功：11,842 明确失败：146 结果未知：12 目标库存在：11,854 重复请求：0 差异请求：0

12 个结果未知请求全部在目标库中查到，说明客户端虽未收到确认，但事务已提交。由于请求号唯一约束生效，应用重试没有产生重复订单。

5.3 监控质量指标

监控平台本身也要被考核：

六、风险与复盘

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 清单
• 确认管理网不受故障注入影响
• 确认监控账号最小权限
• 建立 7～14 天性能基线
• 验证采集脚本超时与防重入
• 验证告警路由和升级联系人
• 验证监控平台自身高可用

演练前

• 业务负责人、DBA、系统、网络、存储人员到位
• 明确停止条件和回退负责人
• 记录 T0 前集群资源状态
• 确认旧节点隔离能力
• 启动带唯一请求号的业务探针
• 确认对账 SQL 可执行
• 确认故障注入脚本自动清理

演练中

• 记录 T0～T7
• 确认告警按预期触发
• 确认无告警风暴
• 确认 FENCE 完成后再接管
• 确认共享盘始终唯一归属
• 观察连接池重试与新建连接速率
• 记录未知提交请求

演练后

• 执行重复请求检查
• 执行数量和金额汇总
• 检查长事务、锁和异常会话
• 恢复所有网络、存储和节点配置
• 验证节点重新纳管
• 校准告警阈值
• 形成复盘报告和整改责任人

转载自：https://blog.csdn.net/u014727709/article/details/163325514
欢迎 👍点赞✍评论⭐收藏，欢迎指正