摘要：本文將聚焦於用戶監控的原理及應用進行介紹。
本文分享自華爲雲社區《GaussDB(DWS)監控工具指南（二）用戶級監控》，作者：幕後小黑爪 。
前言
資源監控是整個運維乃至整個產品生命週期重要的一環，事前及時語句發現故障，事後提供詳實的數據用於追查定位問題。GaussDB(DWS)整個資源監控體系分爲作業級監控、用戶監控和資源池監控。本文將聚焦於用戶監控的原理及應用進行介紹。
1、GuassDB(DWS)用戶體系
對於一個產品來說，最簡單的用戶分類是普通用戶、系統管理員、超級管理員三層體系。超級管理員擁有最高級的權限，普通用戶作爲最基本的用戶，用戶操作系統的部分權限，系統管理員也擁有部分權限，同時他也可改變普通用戶的權限。超級管理員擁有所有權限，但是不輕易使用。
1.1 兩層用戶機制介紹
對於一個企業來說，對數據庫的操作也是分部門運作，每個部門單獨有的表，同時每個部門也有單獨的優先級，有鑑於此，GaussDB（DWS）設計的用戶體系也分爲兩層：
第一層爲組用戶，該層用戶關聯組資源池，不作爲執行作業的用戶使用。
第二層爲業務用戶，該層用戶關聯業務資源池，可作爲執行作業的用戶使用。
組用戶之間可使用的資源也可單獨設置。每個業務用戶之間亦可設置單獨的資源。相較於以往單層的用戶機制而言，兩層的用戶機制可實現對用戶資源進行粒度更小的管控。
示例：
# 創建cgroup控制組
gs_ssh -c "gs_cgroup -c -S ClassG1 -G wn1"
# 創建組資源池resource_pool_a綁定ClassG1控制組。
CREATE RESOURCE POOL resource_pool_a WITH (control_group = 'ClassG1');
# 創建業務資源池resource_pool_a1綁定wn1控制組。
CREATE RESOURCE POOL resource_pool_a1 WITH (control_group = 'ClassG1:wn1');
# 創建組用戶關聯到組資源池。例如，名稱爲“tenant_a”的組用戶關聯到“resource_pool_a”組資源池
CREATE USER tenant_a RESOURCE POOL 'resource_pool_a' PASSWORD '********';
# 創建業務用戶關聯到業務資源池和組用戶。例如，名稱爲“tenant_a1”的業務用戶關聯到“resource_pool_a1”組資源池和“tenant_a”組用戶。
CREATE USER tenant_a1 RESOURCE POOL 'resource_pool_a1' USER GROUP 'tenant_a' PASSWORD '********';1.2 賦權
當我們需要普通用戶訪問某個表時，可使用grant語法對用戶賦權限或者收回權限，該操作需要擁有sysadmin權限的用戶進行，舉個例子
# 將public表空間下的lineitem表的查詢權限賦給user_1：
grant select on public.lineitem to user_1;
# 回收user_1的public表空間下的lineitem表的查詢權限：
Revoke select on public.lineitem from user_1;2、用戶資源監控
2.1 目標
一般情況下，數倉產品會同時有多個用戶對數據庫進行操作，每個用戶使用的資源量有差異，舉個極端的例子，當某個用戶下發了慢SQL，導致集羣整體性能劣化，此時我們就需要確定這個作業是哪個用戶下發的，然後找到對應的慢SQL，對其進行管理。
對於管理員用戶而言，用戶監控可以幫助管理員以用戶的維度瞭解系統的性能狀況，及時發現並解決資源瓶頸和故障，提高系統的可靠性和穩定性。還可區分每個用戶在整個集羣中使用的資源量，確定哪些用戶使用的資源量超標,然後對超標的用戶進行限制。
2.2 監控維度
用戶監控支持對CPU、內存、存儲空間、臨時空間、算子落盤空間、磁盤IO、網絡等方面的監控，通過對這些資源的監控，管理員可以瞭解系統的負載情況、進程的運行狀態、磁盤空間的使用情況、網絡帶寬的利用率等信息。這些信息可以幫助管理員及時發現系統的異常情況，及時採取措施，避免系統崩潰或者服務中斷。
使用示例：
postgres=# SELECT * FROM PG_TOTAL_USER_RESOURCE_INFO;
username | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_cou
nts | write_counts | read_speed | write_speed | send_speed | recv_speed
------------------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+---------
----+--------------+------------+-------------+------------+------------
user_grp_1 | 0 | 4928 | 0 | 16 | 1573880 | -1 | 0 | -1 | 0 | -1 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0
perfadm | 0 | 0 | 0 | 0 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0
user_normal | 0 | 24643 | 0 | 16 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0
usr1 | 0 | 69763 | 0 | 40 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0
logical_cluster1 | 0 | 24643 | 0 | 16 | 1834424 | -1 | 0 | -1 | 0 | -1 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0
user_2 | 0 | 985 | 0 | 16 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0
user_1 | 0 | 3942 | 0 | 16 | 1573880 | -1 | 0 | -1 | 0 | -1 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0
logical_cluster2 | 0 | 45120 | 0 | 24 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0
user_default | 0 | 24643 | 0 | 16 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0
wjx | 0 | 24643 | 0 | 16 | 0 | -1 | 0 | -1 | 0 | -1 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0
(10 rows)
postgres=# select * from GS_WLM_USER_RESOURCE_HISTORY;
username | timestamp | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_
kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed | send_speed | recv_speed
------------------+-------------------------------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+------
-------+--------------+-------------+--------------+------------+-------------+------------+------------
user_grp_1 | 2023-05-22 16:51:03.380482+08 | 0 | 4928 | 0 | 16 | 1573880 | -1 | 0 | -1 | 0 | -1 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
wjx | 2023-05-22 16:51:03.380482+08 | 0 | 24643 | 0 | 16 | 0 | -1 | 0 | -1 | 0 | -1 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
user_default | 2023-05-22 16:51:03.380482+08 | 0 | 24643 | 0 | 16 | 0 | -1 | 0 | -1 | 0 | -1 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
logical_cluster2 | 2023-05-22 16:51:03.380482+08 | 0 | 45120 | 0 | 24 | 0 | -1 | 0 | -1 | 0 | -1 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
user_1 | 2023-05-22 16:51:03.380482+08 | 0 | 3942 | 0 | 16 | 1573880 | -1 | 0 | -1 | 0 | -1 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
user_2 | 2023-05-22 16:51:03.380482+08 | 0 | 985 | 0 | 16 | 0 | -1 | 0 | -1 | 0 | -1 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
logical_cluster1 | 2023-05-22 16:51:03.380482+08 | 0 | 24643 | 0 | 16 | 1834424 | -1 | 0 | -1 | 0 | -1 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
usr1 | 2023-05-22 16:51:03.380482+08 | 0 | 69763 | 0 | 40 | 0 | -1 | 0 | -1 | 0 | -1 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
user_normal | 2023-05-22 16:51:03.380482+08 | 0 | 24643 | 0 | 16 | 0 | -1 | 0 | -1 | 0 | -1 |
0 | 0 | 0 | 0 | 0 | 0 | 0 | 02.3 監控原理
內核在作業運行時，依據作業攜帶的用戶信息，進行相關資源字段的累計，每隔一段時間將信息彙總至用戶監控歷史表中。此外，該功能的使用有些規格：
2.3.1 相關GUC參數
enable_logical_io_statistics：用戶資源監控和資源池資源監控IO相關數值的開關，默認爲on,開啓後用戶監控中io相關記錄（read_kbytes、write_kbytes、read_counts、write_counts、read_speed和write_speed）會進行統計。
enable_user_metric_persistent：否開啓用戶/資源池歷史資源監控轉存功能，開啓後會將監控記錄轉存到歷史表中。
user_metric_retention_time：設置用戶歷史資源監控數據的保存天數，默認爲7天
2.3.2 相關說明
當前用戶監控可同時監控快慢車道的所有作業的CPU、IO和內存使用情況。
當用戶在CN上進行查詢時，顯示的爲所有DN資源池使用和資源限制的累積和。在DN查詢時僅統計本DN上資源池使用和資源限制信息。
DN上數據收集週期爲5s，CN每隔5s從DN上收集一次信息。輔助線程每30s自動進行持久化操作，持久化用戶監控數據。
對於初始管理用戶暫不進行資源監控，因爲該用戶是超級管理員用戶，沒必要監控。
2.4 案例分析
2.4.1 當出現內存不可用時，可通過該視圖查看是哪個用戶使用的內存過高
2.4.2 可以監控用戶網絡使用情況，比如網絡的收發速率等。