摘要： 在我們平時的數據庫使用當中，監控系統，作為排查故障，告警故障的重要輔助系統，對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，我們能看到，足夠小的監控粒度，足夠全面的監控指標項，對於故障發生的問題排查有多麼重要，而實時性，在監控牆場景下的作用也十分明顯。
閱讀更多 雲棲社區 的文章
