??之前看過很多根因定位的論文,大多數都是基于PC算法+隨機游走,而這些論文上的算法很難落地。去了解很多大廠的解決方案之后,發現他們基本上都是基于專家規則做分類。下面介紹一下華為opengauss的AI4DB中的慢SQL根因定位時如何實現的。根據他的這種方案,我們可以推廣到系統根因定位、日志系統的根因定位等。
??慢SQL一直是數據運維中的痛點問題,如何有效診斷慢SQL根因是當前一大難題,工具結合openGauss自身特點融合了現網DBA慢SQL診斷經驗,該工具可以支持慢SQL根因15+,能同時按照可能性大小輸出多個根因并提供針對性的建議。
先來看一下數據流圖:

參數配置
??1:在misc/dbmind.config中設置detection_interval(檢測的間隔),和last_detection_time(上次檢測距離本次多久)。

2:利用metadatabase/slow_queries.py在關系數據庫中建立如下表,方便前端系統獲取數據展示:

3:設置計算特征的閾值,也是在數據庫建表,你也可以保存在文件中或固定的代碼中:

4:模塊啟動時的其他參數

慢SQL和專家規則
1:慢SQL類(common/types/misc.py)

2:根因類(common/types/root_cause.py)

??每個根因由四部分組成,分別是根因類別、根因細節、根因的建議、根因等級。
3:根因映射(slow_sql/featurelib/feature_mapping.py)

4:定義根因的規則(slow_sql/featurelib/features.py)
?①:FEATURE_LIB[‘features’]

?這是一個75*22的矩陣,行表示樣本數可以是專家定義(針對一些根因,只需要一個特征被觸發,前20個樣本中大部分都是這樣的)的也可以是歷史慢SQL被打標簽。列代表抽取出的慢SQL的特征。
?②:FEATURE_LIB[‘labels’]

??①中樣本的標簽,1到17對應于根因映射中分C1到C17,C1到C16只需要一個特征就能觸發這些根因。
?③:FEATURE_LIB[‘weight_matrix’]

??這是一個17*22的矩陣,17代表根因數,22代表特征數,是由①中的features矩陣計算而來的,詳細計算過程在slow_sql/featurelib/feature_model.py中的calculate_weight函數
定時任務
和趨勢預測都是定時任務的腳本中app/timed_app.py

??1:檢測間隔
??2:從prometheus獲取最近時間(last_detection_time)的慢查詢集合。
??2:上次檢測距離本次多久,last_detection_time轉換為秒
??3:慢查詢診斷入口函數(并行檢測)
模塊入口
在app/diagnosis/query/init.py中(這個函數由上面的定時任務調用):

??1:慢SQL診斷的核心類
??2:入口函數,接下來我們會進入該函數進行詳解
??3:如果遇到異常,默認返回該根因
診斷的核心類SlowSQLAnalyzer
核心入口run()函數:

??1:QueryContext是慢SQL對象的數據處理工廠類
??2:從慢SQL獲取數據庫的相關信息:庫、模式、表,以字典形式返回
??3:從2返回的字典中獲取schema信息,
??4:診斷的核心函數,
核心函數_analyze():

??1:對一些特殊情況(commit或關鍵字)直接匹配指定的根因
??2:正則找到所有SQL文本中所有schema.table,找到schmema和table
??3:把所有的schema.table替換為空,是SQL文本成文SQL pattern
??4:初始化各種類型的metrics(數據庫、表結構、鎖信息、系統信息)

??5:調用QueryFeature類的__call__函數,依次生成features列表中的每一個特征

?6:在第5步中生成的慢SQL根因和featurelib下的features.py下的權重矩陣計算距離,得到topk個最相似的根因

?7:遍歷根因封裝到慢SQL對象的屬性中
?8:如果沒有找到根因,以‘C_UNKNOW’根因返回




