openGauss可观测性综述

以前我写过一篇文章，讨论过数据库的可观测性的必要性，数据库的可观测性的学习榜样是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的朋友做个科普吧。