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的朋友做個科普吧。這個周五下午我的分享中會有更詳細一些的內容，包括我對openGauss開發團隊在可觀測性接口優化上的一些建議，有興趣的朋友關注一下本周末的這個大會吧（https://opengauss.org/zh/summit.html）。