如何利用秒級監控進行mongodb故障排查

在我們平時的資料庫使用當中，監控系統，作為排查故障，告警故障的重要輔助系統，對dba、運維、業務開發同學進行問題診斷、排查、分析有著重要的作用。並且一個監控系統的好壞，也很大程度上影響了能否精確的定位故障，以及是否能正確進行問題修復，避免下一次的故障。而監控粒度、監控指標完整性、監控實時性是評價一個監控的三個重要因素。

在監控粒度上，目前很多的系統都只能做到分鐘級監控，或者半分鐘級監控。這樣一個監控粒度，在針對當前高速運轉的軟體環境下，能力已經越來越捉襟見肘。對於一些瞬間爆發的大量異常更是無能為力。而提升監控粒度，帶來的成倍增長的大數據量以及成倍降低的採集頻率，對於資源的消耗將會是極大的考驗。

在監控指標完整性上，當前絕大部分的系統採用的是預定義指標進行採集的方式。這種方式有一個極大的弊端，就是，如果因為一開始沒有意識到某個指標的重要性而漏采，但是恰恰卻是某次故障的關鍵性指標，這個時候這個故障便極有可能變成「無頭冤案」。

而在監控的實時性上——「沒有人關心過去是好是壞，他們只在乎現在」。

以上三個能力，只要做好一個，就可以稱得上是不錯的監控系統了。而阿里雲自研的秒級監控系統inspector已經可以做到1秒1點的真秒級粒度，全量指標採集、無一疏漏——甚至對曾經沒有出現過的指標進行自動採集，實時數據展示。1秒1點的監控粒度，讓資料庫的任何抖動都無處遁形；全量指標採集，給予了dba足夠全面完整的信息；而實時數據展示，能第一時間知道故障的發生，也能第一時間知道故障的恢復。

今天就針對mongodb資料庫，來聊一聊當遇到db訪問超時時，如果利用秒級監控系統inspector進行故障排查：

case 1

之前有一個線上業務，用的是mongodb副本集，並且在業務端進行了讀寫分離。突然有一天，業務出現大量線上讀流量超時，通過inspector可以明顯看到當時從庫的延遲異常飆高

從庫延遲飆高，則說明從庫oplog重放線程速度追不上主庫寫入速度，而在主從配置一致的情況下，如果從庫的響應速度比不上主庫，那隻能說明從庫當時除了正常的業務操作之外，還在進行一些高消耗的操作。

經過排查，我們發現當時db的cache出現了飆升：

從監控中可以明顯的看到，cache usage迅速從80%左右升到95%的evict trigger線，並且與此同時，dirty cache也有所攀升，達到了dirty cache evict的trigger線。

對於wiredTiger引擎，當cache使用率達到trigger線後，wt認為evict線程來不及evict page，那麼就會讓用戶線程加入evict操作，然後此時就會大量引起超時。而這個想法通過application evict time指標也可以加以印證：

通過上圖我們可以清晰的看到，當時用戶線程花費了大量時間去做evict，然後導致了正常訪問請求的大量超時

然後經過業務端排查，是因為當時有大量的數據遷移job導致cache打滿，所以在對遷移job進行限流並且增大cache之後，整個db運行也開始變的平穩。

case 2

某日線上一個使用sharding集群的業務突然又一波訪問超時報錯，然後短暫時間後又迅速恢復正常。通過經驗判斷，當時多半有一些鎖操作，導致訪問超時。

通過inspector，我們發現在故障發生時刻某個shard上鎖隊列很高：

所以基本印證了我們之前對於鎖導致訪問超時的猜想。那麼究竟是什麼操作導致了鎖隊列的飆升呢？

很快，通過對當時命令的排查，我們發現當時shard上的鑒權命令突然飆高：

而通過查看代碼，我們發現，mongos到mongod雖然使用keyfile進行認證，但是實際也是通過sasl命令的scram協議來進行認證，而這個在認證的時候會有一個全局鎖，所以當時瞬間大量的鑒權導致了全局鎖隊列飆升，然後導致訪問超時

所以，最後我們通過改小客戶端的連接數，來減少這種突然激增的鑒權產生全局鎖導致超時。

通過以上兩個case，我們能看到，足夠小的監控粒度，足夠全面的監控指標項，對於故障發生的問題排查有多麼重要，而實時性，在監控牆場景下的作用也十分明顯。

最後，秒級監控已經在阿里雲mongodb控制台開放，雲mongodb的用戶可以自主進行監控開啟，體驗秒級監控帶來的高清體驗。

原文鏈接

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎