以前我写过一篇文章，讨论过数据库的可观测性的必要性，数据库的可观测性的学习榜样是 Oracle，我们根据 Oracle 官方发布的资料以及可观测性接口就可以比较清晰的了解到数据库的运行状态，进行问题定位、性能分析的工作。目前国产数据库都没有提供如此丰富的可观测性接口与工具，因此对于国产数据库的运维来说，造成了很大的障碍。

这个星期五 openGauss 开发者大会下午的生态工具分会场上，我会分享一个话题《openGauss 的可观测性》，周末的时候正好为这个演讲准备 PPT。针对 openGauss 的可观测性数据与接口做了一些分析，今天我们就来讨论一下这个话题吧。

openGauss 的可观测性接口在源于 PG 的国产手机卡来说，还是比较丰富的，虽然 openGauss 是就与较低的 PG 9.2.4 版本开发的数据库产品，不过这些年华为在 openGauss 代码上做了很大规模的修改，首先将整个项目从 C 语言转换为 C++，将 PG 的多进程架构改为多线程架构。并且 openGauss 也在追踪着社区版 PG 的功能，一些新版本社区版 PG 的功能在 openGauss 中也大多数具有，只是实现的方式有所不同。另外 openGauss 还在存储引擎上做一个大胆的尝试，就是用类似 ORACLE 的 USTORE 来替代 PG 传统的 ASTORE 存储引擎。不知道今年的开发者大会上发布的 openGauss 商业版里，会不会看到 USTORE 成为默认存储引擎的功能。

openGauss 的可观测性接口集成了 PG 原生态的一些监控接口（PG_STAT_*）；还增加了 dbe_perf SCHEMA，用户向使用者提供一些内存结构的数据展示，另外还增加了很多 gs_* 的物理表，新增了一些可观测性接口，总结起来有下面几种：

基础运行状态：PG_STAT_*/DBE_PERF 等，提供丰富的系统、表 / 索引等的运行情况，统计信息等；
等待事件：pg_stat_activity/pg_thread_wait_status/dbe_perf.wait_events，用于 openGauss 性能、运行状态、存在问题的分析与定位；
TOP_SQL：statements，发现 TOP SQL，慢 SQL，进行 SQL 优化分析；
ASP：GS_ASP/DBE_PERF.LOCAL_ACTIVE_SESSION：分析当前和历史会话情况，定位微观问题，类似 Oracle 的 ASH；
WDR：一定时间内系统运行情况，用于分析性能问题，定位故障（偏宏观）。
openGauss 的可观测性接口集中通过 dbe_perf SCHEMA 和 pg_stat_* 来提供，我们总结了一些常用的表和视图：

PG_SETTINGS：配置参数
PG_CONTROL_CHECKPOINT/PG_CONTROL_SYSTEM：基本信息
PG_EXTENSION: 插件
pg_database/pg_user/pg_tablespace/dbe_perf.stat_database/…：数据库信息
pg_stat_replication：复制
pg_current_wal_lsn/pg_current_xlog_location/pg_control_checkpoint /pg_stat_bgwriter:：bgwriter、checkpointer、WAL
pg_stat_archiver ：归档
pg_stat_activity/dbe_perf.os_thread/dbe_perf.session_stat/dbe_perf.session_time/dbe_perf.session_memory/…：并发、会话、线程
pg_prepared_xacts：两阶段提交
Dbe_perf.os_runtime：操作系统性能情况
dbe_perf.memory_node_detail/gs_shared_memory_detail：数据库实例内存使用情况
dbe_perf.file_iostat/dbe_perf.summary_file_iostat/dbe_perf.local_rel_iostat：文件 IO
dbe_perf.workload_sql_count/dbe_perf.workload_transaction/dbe_perf.workload_sql_elapse_time/dbe_perf.statement_count：负载
dbe_perf.STATEMENT/dbe_perf. STATEMENT_RESPONSETIME_PERCENTILE：SQL 与 SQL 性能
dbe_perf.stat_bad_block：坏块
openGauss 提供的 ASP 是一个亮点，目前国产数据库中已经提供类似 OracleASH 数据的是比较少的。而 ASH 是目前 DBA 进行高级问题定位时十分重要的数据。openGauss 通过 dbe_perf.local_active_session/gs_asp 来提供 ASP 数据。默认每秒钟采集一个样本，存储在特定的内存里，可以通过 dbe_perf.local_active_session 接口获取，内存中保留 10 万条记录（可配置），超过则写入持久化存储，持久化存储可以使用两种模式：表 gs_asp 或者文件（默认为表），默认的持久化保存采样比例为 10：1，也就是说内存中的采样的 1/10 会被写入持久化存储，如果你觉得这种采样比例不足以用于分析，通过参数进行调整，从而将所有数据都写入持久化存储。

PG 9.2.4 是没有等待事件的，不过在 openGauss 里提供了等待事件，并且等 openGauss3.0 待事件的数量比 PG 13 多了整整一倍。并且 openGauss 的等待事件有等待次数和等待时长的统计数据，因此比 PG 13 更易于用于分析。openGauss 的等待事件基本接口为 pg_stat_activity/pg_thread_wait_status/dbe_perf.wait_events。其中 pg_stat_activity 是 PG 9.6 以后提供的，openGauss 的起点虽然低于此版本，不过依然实现了这个兼容性的接口。实际上 openGauss 原生态的接口是 pg_thread_wait_status。dbe_perf.wait_events 是 openGauss 独有的接口，提供了等待事件的等待时长，等待次数，最大等待时间，平均等待时间等统计信息。这些信息对于运维的好处 DBA 应该都很清楚，我这里就不展开说了。

WDR 是 openGauss 提供的一个类似于 AWR 的可观测性接口，现在几乎所有的国产数据库都会提供一个类似的接口，DBA 可以用来生成一份报告用于运维分析。不过几乎所有的国产 AWR 报告都内容平淡，对 DBA 的帮助不大，似乎 openGauss 也不能免俗。openGauss 的 WDR 报告相当于 Oracle 8 的 AWR 报告的水平，仅仅是一些数据的罗列，并无任何分析，只是对于十分熟悉 openGauss 的人员有些价值，对于普通的 DBA 来说，还是可以看出一头雾水的。我想 Oracle 的 AWR 也是这么一点点的走来的，因此我们也期望以后的 WDR 会做的越来越好。不过要做好 WDR 也并不容易，罗列数据十分容易，重要的是要在报告里加入专家经验，提供一些直接的分析结论。

数据库的可观测性接口是十分复杂的，今天我也只是简单的介绍了一下，可能有点走马观花，甚至是坐火车观碑，不过解读这些接口是需要 DBA 在长期工作中不断积累经验的。今天算是我给一些刚刚接触 openGauss 的朋友做个科普吧。
————————————————

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/DBAIOps/article/details/136255892