摘要：而阿里云自研的秒級(jí)監(jiān)控系統(tǒng)已經(jīng)可以做到秒點(diǎn)的真秒級(jí)粒度，全量指標(biāo)采集無一疏漏甚至對曾經(jīng)沒有出現(xiàn)過的指標(biāo)進(jìn)行自動(dòng)采集，實(shí)時(shí)數(shù)據(jù)展示。最后，秒級(jí)監(jiān)控已經(jīng)在阿里云控制臺(tái)開放，云的用戶可以自主進(jìn)行監(jiān)控開啟，體驗(yàn)秒級(jí)監(jiān)控帶來的高清體驗(yàn)。

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

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

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

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

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

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

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

case 1

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

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

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

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

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

case 2

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

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

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

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

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

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

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

原文鏈接

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