摘要： 為方便開發者的使用，雲資料庫MongoDB提供了許多查看其運行狀態指標的命令。如何分析這些繁多的數據指標？又如何使用這些數據指標解決我們業務中出現的問題呢？本文將帶大家了解查看這些監控指標的命令並為大家逐一解讀其中一些重要的指標。

演講嘉賓簡介：

陳柯任（花名：莫歸），阿里巴巴高級開發工程師，曾在大眾點評從事MongoDB與MySQL相關運維和自動化研發，現主要致力於分散式存儲和NoSQL資料庫相關領域

以下內容根據演講嘉賓視頻分享以及PPT整理而成

本次分享主要圍繞以下三個方面：

一．MongoDB指標分類及查看命令

二．關鍵指標詳解

三．場景診斷

一.MongoDB指標分類及查看：

MongoDB進程狀態指標命令：db.serverStatus()，主要數據性能查看來源

MongoDB數據文件狀態指標命令: db.stats(), db.c.stats()，查看文件大小，存儲空間大小等等

MongoDB副本集狀態指標命令: rs.status()

1.MongoDB數據文件狀態指標解析：

db.stats()實際是一個語法湯，在頂層是一個db.runCommand()的變數，其中包含dbstats與scale兩個參數，dbstats是輸出值，scale可以控制輸出值單位，一般默認dbstats為1，scale為byte，則此時以byte為單位輸出dbstats。另一種方法db.c.stats()與db.stats()方法相同，在此不多做贅述。

以上為db.stats()調用出的資料庫狀態圖片，共分為10項指標，這其中不少同學曾對dataSize與storageSize的意義感到迷惑。事實上，dataSize指的是數據本身即未壓縮時的大小，而storageSize則指的是數據落盤時的大小，數據在落盤時會執行一些相應的壓縮演算法，比如MongoDB本身默認的壓縮演算法，壓縮率在4到5倍之間，這便造成了雖然存放的數據一致，但dataSize往往比storageSize大的現象。當使用者發現這兩個數值相近時，很有可能是數據文件出現了文件空洞，這時建議使用者進行重搭一類的辦法消除文件空洞。indexSize指標指的是索引落盤的大小，即索引的物理存儲的大小。利用IndexSize與storageSize的加和我們可以清楚確定資料庫所佔磁碟空間的大小，同時用dataSize除以storageSize我們可以判斷壓縮比的值，若壓縮比值過小，很有可能出現了數據空洞或二進位編碼有誤等問題，需要我們對其用命令進行處理。

2.MongoDB副本集狀態指標解析：

用rs.status(),即內部值db.runCommand({replSetGetStatus:1})命令可查看資料庫副本集的狀態。其中set指標為副本集的名稱，term指標為選舉版本號，當集群進行切換或選舉時，系統回滾時會使用term對版本號進行判斷。optime指標記錄了每個當前實例oplog最後的操作時間，通過這個時間與主庫的時間進行比較可以得到主從庫的延遲。syncingTo指標表示當前結點的同步源，一般情況下是由MongoDB自身各個結點的健康狀態生成的。

3.MongoDB進程狀態指標解析：（以MongoDB 3.4版本為例）

db.serverStatus()命令,即內部值db.runCommand(serverStatus:1,option)

option參數使得serverStatus()命令可以追加各種的filter,用以強制系統輸出我們希望看到的數據。

二.關鍵指標詳解：

下面我們對進程狀態指標中比較重要的指標進行一一解讀：

1.asserts:

asserts本身值得注意的事項較少，這其中asserts|user是一個很有趣的指標，它記錄了用戶執行命令錯誤的次數，如果該值較高，說明使用者命令記憶不清晰，建議多讀一些指令文檔。其他的一些值例如：asserts|msg,asserts|warning等通常為0值，當這些值不為0時，或多或少反映系統存在著某些問題。

2.connections:

connections指標標註的是連接的狀況，其中available與current均顯示的是當前的值，available表示資料庫當前可用的連接量，當其值過低時，可能是出現了連接池過滿的現象，通過改進資料庫配置中的maxConnection或改善一些慢查詢佔用的連接可解決此問題。current表示資料庫當前的連接數，當這個值高時，即出現了與available過低一樣的問題，參考以上的解決方法同樣可以解決此種問題。另一指標totalCreated記錄了MongoDB啟動後一共創建過多少個連接，通過採集工具做delta後我們可以得到每秒的創建量，當每秒的創建量過大時，說明我們的資料庫採用了過多的短連進行連接，由於MongoDB基於線程模型的特點，過多的短連會使資料庫的性能下降，希望大家多重視這個指標。

3.globalLock:

globalLock中的值同樣表示的是當前的值，相較於connections, globalLock的值均由server內部的狀態值中取出。其中activeClients主要描述了當前請求客戶端操作鎖的情況，currentQueue描述了當前進行有關鎖的操作的隊列情況，當這其中有過高指標時，說明我們的業務中正有大的有關鎖部的操作影響著資料庫的性能。

4.locks:

除了globalLocks，還有另一個指標locks同樣負責描述資料庫中鎖的情況。大家會注意到在一些子指標中會有大寫的」W,R」與小寫的」w,r」。在這裡，小寫的r與w均為意向鎖的意思，MongoDB的意向鎖更像樂觀鎖，即雖然使用了鎖但事實上並沒有鎖住數據。而我們真正需要關注的是大寫的W與R,它們均為排它鎖，它們的值也是累計值，通過它們每秒的增值，我們可以判斷出我們系統的健康狀況及業務訪問的合理程度。子指標oplog的鎖在從庫上表現非常明顯，當我們的從庫觸發oplog時，它會對oplog進行加鎖。oplog是一個全局鎖，當長時間觸發時，會影響從庫的讀取，大家盡量保持主從庫之間延遲處在較小的水平，反過來說當我們的從庫讀請求變慢時，我們也可以參考這個值判斷是否是主從庫延遲過大的問題。

5.network:

network是一個記錄網路流量的累計值。bytesIn與bytesOut分別表示網路進口與網路出口流量，這些數據均已在MongoDB端被統計，physicalBytesIn與physicalBytesOut是3.4版本新加的指標，表示壓縮後即物理實際進口流量及物理即壓縮後出?流量。

6.opcounters:

opcounters是大家在使用過程中會經常參考的指標，是一個比較經典的監控指標，opcounters即為Op本身的一些QPS,其中command表示除了delete,getmore,insert,query,update以外，其他所有的操作命令，比如執行ServerSelect,DBSelect這樣一些操作，這個值也是累計值，我們通過採集它每秒的增量並將它們加和可以得到它真實的QPS,它的最大值是2的30次方，當系統運行時間過長該值超過2的30次方時，它會置為0值。大家有時會有這樣的疑問：「為什麼有時系統在某一時刻大量的超時，但QPS卻並不高？」這是因為MongoDB的統計都是在操作執?完成之後才會生成，如果此時使用者的操作在MongoDB內部被鎖住的話，這就造成了業務之間的時間差使得在這段時間內QPS不會增高，反而降低。

7.mem:

mem指標描述的大多數是內存中的狀態。bits表示當前的MongoDB由多少位編譯而成。resident表示常駐物理內存的大小，單位是兆。mem中的指標均為當前的值，大家取出來可以直接使用。

8.metrics:

metrics中的指標較多，而且不統一。metrics|command的指標大體可分為兩類：metrics|command|failed記錄了命令失敗的總次數，metrics|command|total記錄了命令執行的總次數，我們用total每秒的差值即可求得每秒執行命令的總次數。與前面講的opcounters|command結合來看我們就可知道在一段時間內資料庫中哪些命令執行的次數較多。下面的metrics|document|delete等指標為對文件的修改操作次數，也為累計值，同opcounters中的指標一樣，也是在操作執?結束後才會記錄。metrics|getLastError這類指標也是累計值，主要是在write大於1的模式下會使用到。其中metrics|getLastError|wtime|num指標表示寫操作在w>1模式下getLastError需要等待其它節點應答的次數，metrics|getLastError|wtime|totalMillis表示寫操作在w>1模式下getLastError需要等待其它節點應答的總時間，當這兩個指標的除值即totalMillis/num的值過高時，說明平均寫入同步延遲的時間過長，造成這種狀態的原因可能是因為從結點的性能出現問題，導致整個集群性能的下降。

9.wiredTiger:

wiredTiger|cache|maximum bytes configured用來配置cache大小的指標，wiredTiger|cache|bytes currently in the cache表示當前cache大小的指標，二者相除，即可得到cache的使用域，tracked dirty bytes in the cache表示當前臟頁大小，即我們寫入或落盤的cache大小，寫入大，如果是常態，可以適當提高dirty trigger。bytes read into cache與bytes written from cache指標是cache的讀寫量，它們的高低一般體現在我們磁碟的io讀與io寫上。concurrentTransactions是一個很有趣的指標，不知道大家平時是否有注意過？這個指標表示的是wiredTiger本身transaction控制的數量，這個值默認的是128個，當有一個請求時，會耗用一個transaction，在請求結束時，被耗用的值會被加回，當所有128個值被耗用光時，則從MongoDB層到所有引擎層的請求均會被break住，這些請求只有wiredTiger將所有的transaction都釋放掉時才會被執行。transaction checkpoint total time 指標也是一個累計值，它會在checkpoint結束之後才會進行計算該值，我們拿到這個值後可以用它估計系統的運行是否與我們的設計吻合。

三.場景診斷：

介紹了以上這麼多指標，我們下面在使用場景中來看看它們是怎麼應用的。

1.當我們的客戶端報錯：client checkout connect timeout時

這種情況?般是客戶端沒有釋放鏈接或者沒有?用連接池技術導致的，這時我們往往要看服務端與應用端的連接池情況。對於應用端來說，我們要關注connection.avaliable這個指標是否曾經出現過跌至0的情況，如上圖所示，這是一張秒級監控圖，在圖中我們會發現雖然多數時間內avaliable指標會升滿，但是有時該值還是會跌為0，在跌0的點，就一定會出現timeout的報錯。通過這個指標的異常，我們可以採取在應用端使用一些連接池技術或檢查一下是否存在連接沒有釋放等措施來進行一些優化。

2.寫入不斷超時：

寫入不斷超時的情況是一個比較常見比較經典的情況了。當出現這種問題時，我們會發現我們資料庫中的cache usage指標會不斷飆高，有時也會出現transactions指標跌0的現象出現，此時明顯我們的讀寫操作已無法繼續執行。事實上當transaction被用滿而客戶端又未做連接池時就會導致客戶端連接進不來，就會出現上述的這種狀況。

四.總結

以上即為MongoDB中重要監控指標的解讀及應用，通過這些指標我們可以比較快地確定我們業務中出現的問題，希望大家在使用MongoDB的過程中對這些指標有所重視。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！