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

摘要： 在咱們平時的數據庫使用當中，監控系統，做爲排查故障，告警故障的重要輔助系統，對dba、運維、業務開發同窗進行問題診斷、排查、分析有着重要的做用。而且一個監控系統的好壞，也很大程度上影響了可否精確的定位故障，以及是否能正確進行問題修復，避免下一次的故障。

在咱們平時的數據庫使用當中，監控系統，做爲排查故障，告警故障的重要輔助系統，對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的用戶能夠自主進行監控開啓，體驗秒級監控帶來的高清體驗。

原文連接

閱讀更多幹貨好文，請關注掃描如下二維碼：