雲數據庫MongoDB監控指標解讀與關注

本次直播視頻精彩回顧，戳這裏！

直播涉及到的PPT，戳這裏！

 

 

演講嘉賓簡介：

陳柯任（花名：莫歸），阿里巴巴高級開發工程師，曾在大衆點評從事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的過程當中對這些指標有所重視。

閱讀原文http://click.aliyun.com/m/41123/