基於知識圖譜與異常檢測的PG資料庫故障定位

PostgreSQL資料庫是近年來熱度上升最快的關係型資料庫之一，近年來大量國內企業都在把系統向PostgreSQL上遷移。目前熱度較高的國產資料庫中也有一大半的廠商選擇了PostgreSQL開源專案作為資料庫產品的研發基礎。不過PostgreSQL的運維一直是個難點，與Mysql相比，PostgreSQL過於複雜，運維難度遠大於Mysql。而與Mysql相比，熟悉Postg reSQL 運維與最佳化的D BA 數量又遠遠不及。再加上開源資料庫的文件資料相比Oracle等商用資料庫來說更是差距甚大，如何做好P ostgreSQL 資料庫的運維就成為很多企業面臨的大問題。

在2020年的第十屆中國P G 使用者大會上，我分享了一個主題-《基於知識圖譜的PostgreSQL深度分析》，當時正好是基於P G 的知識圖譜1.0剛剛具備雛形的時候，正在實驗性的用於D-SMART產品中，對P G 等資料庫進行輔助診斷。  

在那個分享裡，我介紹了利用團隊梳理的知識庫和異常檢測演算法進行P G 資料庫異常的自動診斷的一些嘗試。

 

當時我們採用在生產系統中取樣，並進行專家標註的方法構建分析中最為核心的異常檢測演算法，結合知識圖譜定義的診斷路徑，找出與某個故障現象相關的指標集，然後透過異常檢測發現其中存在問題的子集，最後透過收斂演算法，找到問題的根因。

 

在那個演講中，我舉了一個實際的案例，在一個電力客戶中有一套P G 資料庫，現場D BA 對P G 運維完全無感，因此這套系統一直是在盲跑，到底有沒有問題，只有老天知道，只要不當機就啊彌陀佛了。客戶反饋系統慢也沒有任何辦法去做分析，因為運維團隊裡沒有任何針對P G 進行最佳化的知識。

正好客戶和我們一起啟動了一個智慧化運維的課題，於是我們就針對這套資料庫進行了一些智慧診斷的嘗試。在D -SMART 1.9 中我們提供了一個智慧診斷工具，利用這套知識庫可以進行初步的分析，將問題收斂到了幾個方面，運維人員根據這些方面的分析結論，結合智慧化工具推薦的診斷工具，手動點選這些工具，最終定位了問題。這種智慧化輔助的手段可以減輕D BA 的工作負擔，提高問題定位的正確性。不過也只是能夠起到一定的輔助作用。

當時我們分享的這個案例只是一個實驗性的案例，我們採用的異常檢測演算法是依賴於專家人工標註的。

 

透過離線的資料採集，經過無監督學習（實際上就是暴力計算）找到一些疑似故障點，然後對這些資料進行一定的人工標註，再透過半監督學習構建模型，用於生產系統中的異常檢測。為什麼要採用這種迂迴的方法來構建異常檢測模型呢？這是因為暴力計算需要很高的算力，如果用於實時監控，對伺服器C PU 資源消耗過大，需要一個龐大的叢集才能支撐較大規模的資料庫運維場景。

這種方法雖然在實驗室中獲得了一定的效果，但是在實際生產環境中我們遇到了一個巨大的問題，那就是這樣構建起來的模型並不通用，換了一個客戶，甚至在一個客戶的多種不同的應用場景中，模型都不通用。對於一個具有數百個甚至上千個資料庫例項的使用者來說，都採用如此高成本的模型構建方法是完全行不通的。後來我們又嘗試了一系列基於時間序列的無監督演算法，比如H TM/LSTM ，以及隨機森林等方法，最後獲得的效果都不理想。

 

基於上面遇到的問題，在構建2.0版本的知識庫的時候，我們放棄了以前的一些設計，針對異常檢測，需要找到一種計算量較小的，不依賴於專家標註的演算法。於是我們想到了模仿Oracle的統計資訊，以一定週期為單位（比如一週，半個月），滾動更新統計資料，採集指標的資料進行取樣，構建常規執行的資料模型，然後根據這些資料模型，建立算力要求較低的演算法，用於生產環境的指標異常檢測。

同時針對知識庫的更新也在繼續進行。從去年1.0版本的數千個頂點，兩萬多個關係變為5萬個頂點，十幾萬個關係。

 

在知識庫構建的過程中，1.0版本主要解決了從某個故障場景的診斷路徑自動發散，透過發散後的路徑來尋找各種問題的可能性。1.0版本並沒有解決好問題的收斂，雖然智慧診斷可以不斷地發散，讓D BA 抓住所有的蛛絲馬跡，但是沒辦法對問題進行收斂歸類。從而較為準確的定位故障點，有時候甚至會出現大量的誤判，把一些與這個故障無關的因素分析了出來。這是因為資料庫系統是一個十分複雜的系統，當某類問題出現的時候，系統中還存在很多其他方面的問題，這些都可能對智慧化分析產生嚴重的干擾。在資料庫專家的輔助下，這些干擾可以比較容易的被裁剪，但是智慧分析演算法並沒有人類的這種智慧，只是一種演算法智慧，是無法解決這些問題的。因此2.0版本的知識庫中重點對診斷路徑的收斂做了最佳化，最後形成比較規範的故障結論。

實際上，智慧化診斷是一種算力與演算法的診斷，而並不完全是一個真正的人工智慧，我們更喜歡稱之為“知識自動化”，是一種基於各種感測技術與算力的自動化駕駛。我們來看下面的一張 D-SMART 中智慧化診斷的示意圖。

 

首先是透過各種異常發現的演算法與規則引擎，找出異常點，並歸納為某個異常場景。然後透過知識圖譜發散思維，合理的擴散診斷路徑。第三步是根據診斷路徑找到關聯指標，形成待分析的指標集。第四步是透過異常檢測演算法對這個指標集進行檢測分析，找出可能的問題路徑。最後對問題路徑進行收斂，獲得分析結果。

下面是D -SMART 2.0 的一個診斷案例，我們在進行模擬壓測時， D-SMART 出現了一個告警，含義是s hared buffers 中的髒塊寫盤的狀態出現了異常，b ackend 程式承擔了過多的髒塊寫出的工作。

 

比如上面的這個故障場景，在系統負載比較高的時候，經常會出現b ackend 回寫共享快取的比例過高的問題，這會影響應用的效能，對於一些效能敏感的應用影響較大。針對這個告警，D -SMART 提供了一個智慧化分析工具和幾條標準化的診斷路徑。上面是“智慧指標分析”工具顯示的相關指標情況，在後面，該工具直接給出了診斷結論：

 

診斷結論還是通俗易懂的，懂一些PostgreSQL運維的人都可以獲得如下的資訊，首先這個問題出現的原因是系統併發量太大，其次資料庫的配置有可最佳化的地方。另外系統中存在T OP SQL ，I O 的吞吐量也有點大。

事實是否如此呢？首先併發量大這一點十肯定的，因為出現告警的時間段正好在做壓測。系統配置是不是有問題，我們可以直接透過工具去驗證。目前2.0的知識庫還有一個地方不夠完善，那就是針對f inding 的確認，在2.1版本中，知識庫裡會帶有診斷結果確認的知識，當然這些知識是透過關聯相關診斷知識點來實現的。升級到2.1版本的知識庫後，在每個發現後面會直接輸出自動確認的結果。

 

對B GWRITER 相關引數的分析，提出的建議是不調整相關引數，而去加大s hared buffers 。從s hared buffers 的命中率看，確實在問題發生的時間段內的命中率較低。

 

這也是 PostgreSQL 資料庫常見的問題，當 shared buffers 不足的時候，大量的資料塊需要寫出，此時b ackend 就被迫承擔了大量的 bgwriter 的工作了。對於大型的PostgreSQL資料庫，要儘可能減少這種情況的出現。

 

上面的診斷結果和智慧診斷的f inding 中D B CACHE 配置不合理是吻合的，根據上面的建議，我們把s hared buffers 調整為15 GB ，然後再載入類似的負載。再看看剛才的問題是否緩解了。

 

 

從上面的這個資料可以看出，調整s hared buffers 之後， backend 程式寫出共享快取的比例合理多了。和今天上午同樣壓測的情況相比，也要低了很多。我們再來看shared   buffers的命中率情況：

 

S hared   buffers的命中率也沒有再出現上午的抖動情況。從壓測工具上來看，t pmc 也穩定在60多萬，比上午增加了15%左右，而且 tpmc 也不像上午壓測那樣抖動了。從這個例子來看，知識庫2.0很好的幫助 DBA 完成了一次較為複雜的診斷。

知識庫2.0版本在分析能力上必1.0版本有了較大的提升，代價是在D -SMART 伺服器上需要消耗大量的C PU 資源去對已有的監控資料做取樣分析，從而獲得較為準確的資料，用於指標的異常檢測。和傳統的監控系統相比，智慧化運維工具需要更高的算力來做支撐。隨著工具能力的不斷提升，D -SMART 從一個只需要跑在一臺配置很低的虛擬機器上，已經變成了一個算力吞金獸了，不過幸運的是，算力在現在已經較為便宜了。