第六部 · 可观测性篇

《没有可观测性，任何数据库都无法进入生产状态》

【系列】国产化数据库迁移 · 深度解析六部曲

【本部】第 6 部：可观测性篇

迁移过程中，很多团队会忽略一件事：你不仅换了数据库，也失去了原来的可观测性体系。

可观测性不是监控，是你“看得见系统在做什么”的能力。没有这个能力，任何数据库都无法真正进入生产状态。

这篇文章是整个系列的收尾，讲可观测性的重建。

过去几年我们参与过几次国产数据库落地项目。当我们总结所有成功与失败的迁移经验时，得到一个非常明确的结论：

迁移出问题的根本原因，从来不是 SQL，也不是数据，而是看不见。可观测性缺失，会让一个数据库从可运行变成不可运维。

所谓可观测性，不是指监控图标好不好看，而是系统是否具备以下能力：

• 能提前知道自己快出问题
• 能准确知道问题产生的位置
• 能够在问题产生时获得最小化损害
• 能从错误中恢复
• 能对业务提供 SLA 级信息

迁移到国产数据库后，最容易失效的就是这些能力。

以下内容，是基于我们实际项目中反复观察到的结构性现象整理的。没有夸大，也没有虚构。

第1章 迁移后监控正常，但可观测性却已失效

迁移完成后，很多团队都会说：

• 监控图都有了
• CPU、内存都能看到
• 数据库能跑 SQL 了

但这些并不等于可观测性。实际上，可观测性由三层能力构成：

1. 指标（Metrics）层

系统的健康度：CPU、内存、IO、连接数、节点状态等。迁移后通常这一层最容易恢复，但也最不够用。

2. 追踪（Tracing）层

一条 SQL 穿过数据库各节点的全过程，包括：

• 被优化器如何理解
• 在每个节点执行了哪些步骤
• 是否发生数据移动
• 每一步的耗时
• 每个节点的负载

MPP 架构（如磐维）尤其依赖这一层。缺失这一层，性能问题几乎无法定位。

3. 日志（Logging / Audit）层

包含：

• 行为日志
• 安全审计日志
• 错误链路
• 会话信息
• DDL/DML 行为

迁移后最容易失效的是这一层，因为日志结构经常与旧系统不兼容。

在迁移后的企业系统里，我们经常看到的是：

• 指标正常 → 行为正常
• 追踪缺失 → 性能不明
• 日志缺失 → 风险不可控

这就是典型的看上去很好，但其实瞎了。

第2章 为什么可观测性在迁移后更容易失效？

不是国产库的问题，也不是迁移方式的问题。真正的原因是：原数据库的可观测性体系根本无法迁移。

例如：

Oracle 的：

• OEM
• AWR
• ASH
• v$ 体系
• Latch/Wait 事件模型

Greenplum 的：

• gp_toolkit
• Explain analyze + motion 分析体系
• Resource Queue

Vertica 的：

• MC（Management Console）
• 资源池监控模型
• ROS/WOS 管理指标

这些体系本质上都是与数据库运行机制深度耦合的。迁移后必然全部失效。这是架构原因，不是谁的问题。而在国产库中，可观测性体系也有自己的结构：

• MPP 执行计划
• Shuffle 数据量
• 分布键命中情况
• 节点压力波动
• 事务/锁链路
• 审计事件模型
• 内置性能视图

这些并非 Oracle 或 GP 那套体系的替代物，它们只是另一种形式的可观测性。也就是说：迁移后，你必须重新学习数据库是如何运行的。否则，你连调优的起点都找不到。

第3章 必须向管理层说明：

可观测性不是迁移后补补监控这么简单，迁移后常见的误解是：数据库跑得起来，监控加上去就行！

但实际上：

1) 可观测性不是锦上添花，而是生产系统的必要条件

没有它：

• 慢 SQL 没法确认
• 数据倾斜无法判断
• 分布键是否失效不知道
• 事务阻塞是否恶化不知道
• 审计链是否断裂不知道
• 节点是否压力异常不知道

2) 可观测性不等于监控插件不兼容

这是常见误解。真正的问题是：原数据库为监控体系提供的语义接口在新数据库里不存在。

例如：

• Oracle 的 latch、mutex、wait event
• GP 的 motion、slice、gang
• Vertica 的 ROS/WOS merge 指标

目标库无论多先进，也不会复刻它们。因此可观测性必须全部重建。

第4章 迁移后最容易出现的五类可观测性盲区（实际项目中高频出现）

以下内容全部基于实际项目观察，但不涉及任何客户细节。

1）SQL 行为不可见（最危险）

迁移后你经常会看到：

• SQL 变慢了 → 不知道在哪个节点慢
• 计划变复杂了 → 不知道为什么选这个 plan
• 负载变高了 → 不知道是哪个 SQL 引起的
• 业务抖动 → 不知道是哪条链路造成的

这是根因不明类风险，会直接导致：系统不可维护。

2）节点行为缺失（MPP 架构致命点）

比如磐维数据库：

• 分布键错误 → 倾斜严重 → 单节点爆满
• Motion 过多 → 网络风暴
• 节点压力波动大 → 集群吞吐忽高忽低

如果你看不到这些指标，就无法判断：

• 痛点在哪里
• SQL 是否本地化
• 计划是否合理
• 资源是否被滥用

3）锁链路不可见

迁移常见问题：

• 锁等待
• 死锁
• 长事务
• 阻塞链叠加
• 事务异常卡住整个集群

如果无法可视化锁链路，运维成本会非常高。

4）审计链路中断（涉及监管风险）

迁移后：

• 帐号登录不被记录
• DDL 不上报
• 敏感字段访问不入审计
• 日志结构不被 SIEM 解析
• 多级审计链断裂

这类问题不是技术问题，是合规问题，影响远大于性能。

5）分区与分布策略不可见

你想象一下：

• 分区裁剪失效 → 全表扫描
• 分布键错误 → join 全部跨节点
• 统计信息过期 → plan 不稳定

这些问题没有可观测性，将无法被发现。

第5章、这份说明书最重要的部分：

可观测性缺失的真正风险是什么？下面这段话，是写给 CTO 的原文：

1）可观测性缺失，使迁移后的风险指数级放大

因为迁移后的数据库：

• 行为模式不同
• 优化器决策方式不同
• 并发模型不同
• 执行路径不同
• 日志结构不同

而我们看不到，无法掌握变化趋势。

2）问题本身不是致命的，但不可见才是致命的

任何数据库都会出现：

• 锁
• 慢 SQL
• 趋势变化
• 资源波动

但如果出现后无法确定原因：系统无法被维护，也无法被信任。

3）可观测性缺失会影响 SLA、影响业务方信心

业务部门最无法接受的不是慢，而是：

• 慢的时候不知道为什么慢
• 慢的时候不知道怎么办
• 慢的时候没有预警
• 慢的时候没有定位结果

迁移成功标准不是系统能跑，而是系统能被维护。

第6章 可观测性体系应该如何重建？

下面是我愿意给管理层的建议，也是我们经过实践总结出的路径：

1）务必启用国产库自身提供的可观测性视图

例如磐维数据库本身的：

• 节点视图
• SQL 监控
• 执行计划统计
• 分布键/数据倾斜查询
• 锁链路信息
• 内置审计日志

这些是最可靠的基础。

2）重建 Prometheus+Grafana 型监控体系

包括：

• 数据库节点 Exporter
• SQL 行为 Exporter
• Audit Exporter
• 执行计划 Exporter
• 分布式执行 Exporter

这是企业级可观测性的基础设施。

3）重建 SQL 层可视化工具

有了这些：

• SQL 运行轨迹
• 每个节点的耗时
• Hash Join / Motion 的代价
• 慢 SQL 来源
• SQL 排名

系统才能真正稳定。

4）重建审计链路

尤其是：

• 登录
• DDL
• 敏感字段访问
• 错误事件
• 会话行为

这涉及监管要求，不能忽略。

5）建立性能基线（Baseline）

迁移后必须：

• 基线 SQL
• 基线节点
• 基线数据量
• 基线资源曲线
• 基线慢 SQL 排名

没有基线，就无法判断性能是否变差。

总结一下：如果系统不可观测，它就不具备生产资格

可观测性不是迁移的附属品，而是系统稳定运行的基石。

• 你可以在没有监控的情况下开发
• 可以在没有监控的情况下测试
• 但不能在没有可观测性的情况下进入生产

因为：可观测性缺失不是“晚点上线”，而是“上线后无法维护”。

如果你正在做国产库迁移，希望这篇文章能让你提前意识到：能跑不是目标， 能看见它怎么跑才是迁移成功的关键。