摘要： 在我們平時的數(shù)據(jù)庫使用當(dāng)中，監(jiān)控系統(tǒng)，作為排查故障，告警故障的重要輔助系統(tǒng)，對dba、運維、業(yè)務(wù)開發(fā)同學(xué)進(jìn)行問題診斷、排查、分析有著重要的作用。并且一個監(jiān)控系統(tǒng)的好壞，也很大程度上影響了能否精確的定位故障，以及是否能正確進(jìn)行問題修復(fù)，避免下一次的故障。

在我們平時的數(shù)據(jù)庫使用當(dāng)中，監(jiān)控系統(tǒng)，作為排查故障，告警故障的重要輔助系統(tǒng)，對dba、運維、業(yè)務(wù)開發(fā)同學(xué)進(jìn)行問題診斷、排查、分析有著重要的作用。并且一個監(jiān)控系統(tǒng)的好壞，也很大程度上影響了能否精確的定位故障，以及是否能正確進(jìn)行問題修復(fù)，避免下一次的故障。而監(jiān)控粒度、監(jiān)控指標(biāo)完整性、監(jiān)控實時性是評價一個監(jiān)控的三個重要因素。

在監(jiān)控粒度上，目前很多的系統(tǒng)都只能做到分鐘級監(jiān)控，或者半分鐘級監(jiān)控。這樣一個監(jiān)控粒度，在針對當(dāng)前高速運轉(zhuǎn)的軟件環(huán)境下，能力已經(jīng)越來越捉襟見肘。對于一些瞬間爆發(fā)的大量異常更是無能為力。而提升監(jiān)控粒度，帶來的成倍增長的大數(shù)據(jù)量以及成倍降低的采集頻率，對于資源的消耗將會是極大的考驗。

在監(jiān)控指標(biāo)完整性上，當(dāng)前絕大部分的系統(tǒng)采用的是預(yù)定義指標(biāo)進(jìn)行采集的方式。這種方式有一個極大的弊端，就是，如果因為一開始沒有意識到某個指標(biāo)的重要性而漏采，但是恰恰卻是某次故障的關(guān)鍵性指標(biāo)，這個時候這個故障便極有可能變成“無頭冤案”。

而在監(jiān)控的實時性上——“沒有人關(guān)心過去是好是壞，他們只在乎現(xiàn)在”。

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

今天就針對mongodb數(shù)據(jù)庫，來聊一聊當(dāng)遇到db訪問超時時，如果利用秒級監(jiān)控系統(tǒng)inspector進(jìn)行故障排查：

case 1

之前有一個線上業(yè)務(wù)，用的是mongodb副本集，并且在業(yè)務(wù)端進(jìn)行了讀寫分離。突然有一天，業(yè)務(wù)出現(xiàn)大量線上讀流量超時，通過inspector可以明顯看到當(dāng)時從庫的延遲異常飆高

從庫延遲飆高，則說明從庫oplog重放線程速度追不上主庫寫入速度，而在主從配置一致的情況下，如果從庫的響應(yīng)速度比不上主庫，那只能說明從庫當(dāng)時除了正常的業(yè)務(wù)操作之外，還在進(jìn)行一些高消耗的操作。
經(jīng)過排查，我們發(fā)現(xiàn)當(dāng)時db的cache出現(xiàn)了飆升：

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

對于wiredTiger引擎，當(dāng)cache使用率達(dá)到trigger線后，wt認(rèn)為evict線程來不及evict page，那么就會讓用戶線程加入evict操作，然后此時就會大量引起超時。而這個想法通過application evict time指標(biāo)也可以加以印證：

通過上圖我們可以清晰的看到，當(dāng)時用戶線程花費了大量時間去做evict，然后導(dǎo)致了正常訪問請求的大量超時
然后經(jīng)過業(yè)務(wù)端排查，是因為當(dāng)時有大量的數(shù)據(jù)遷移job導(dǎo)致cache打滿，所以在對遷移job進(jìn)行限流并且增大cache之后，整個db運行也開始變的平穩(wěn)。

case 2

某日線上一個使用sharding集群的業(yè)務(wù)突然又一波訪問超時報錯，然后短暫時間后又迅速恢復(fù)正常。通過經(jīng)驗判斷，當(dāng)時多半有一些鎖操作，導(dǎo)致訪問超時。
通過inspector，我們發(fā)現(xiàn)在故障發(fā)生時刻某個shard上鎖隊列很高：

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

很快，通過對當(dāng)時命令的排查，我們發(fā)現(xiàn)當(dāng)時shard上的鑒權(quán)命令突然飆高：

而通過查看代碼，我們發(fā)現(xiàn)，mongos到mongod雖然使用keyfile進(jìn)行認(rèn)證，但是實際也是通過sasl命令的scram協(xié)議來進(jìn)行認(rèn)證，而這個在認(rèn)證的時候會有一個全局鎖，所以當(dāng)時瞬間大量的鑒權(quán)導(dǎo)致了全局鎖隊列飆升，然后導(dǎo)致訪問超時

所以，最后我們通過改小客戶端的連接數(shù)，來減少這種突然激增的鑒權(quán)產(chǎn)生全局鎖導(dǎo)致超時。

通過以上兩個case，我們能看到，足夠小的監(jiān)控粒度，足夠全面的監(jiān)控指標(biāo)項，對于故障發(fā)生的問題排查有多么重要，而實時性，在監(jiān)控墻場景下的作用也十分明顯。

最后，秒級監(jiān)控已經(jīng)在阿里云mongodb控制臺開放，云mongodb的用戶可以自主進(jìn)行監(jiān)控開啟，體驗秒級監(jiān)控帶來的高清體驗。

原文鏈接

干貨好文，請關(guān)注掃描以下二維碼：

總結(jié)

以上是生活随笔為你收集整理的如何利用秒级监控进行mongodb故障排查的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。