云数据库MongoDB监控指标解读与关注-阿里云开发者社区

开发者社区> 数据库> 正文

云数据库MongoDB监控指标解读与关注

简介: 为方便开发者的使用,云数据库MongoDB提供了许多查看其运行状态指标的命令。如何分析这些繁多的数据指标?又如何使用这些数据指标解决我们业务中出现的问题呢?本文将带大家了解查看这些监控指标的命令并为大家逐一解读其中一些重要的指标。

本次直播视频精彩回顾,戳这里!

直播涉及到的PPT,戳这里!

演讲嘉宾简介:

陈柯任(花名:莫归),阿里巴巴高级开发工程师,曾在大众点评从事MongoDBMySQL相关运维和自动化研发,现就职于阿里云MongoDB团队,主要致力于分布式存储和NoSQL数据库相关领域。

 

以下内容根据演讲嘉宾视频分享以及PPT整理而成

 

本次分享主要围绕以下三个方面

一.MongoDB指标分类及查看命令

二.关键指标详解

三.场景诊断

 

一.MongoDB指标分类及查看:

  • MongoDB进程状态指标命令:db.serverStatus(),主要数据性能查看来源
  • MongoDB数据文件状态指标命令: db.stats(), db.c.stats(),查看文件大小,存储空间大小等等
  • MongoDB副本集状态指标命令: rs.status()

 

1.    MongoDB数据文件状态指标解析

     3f1709c980ac563c00bab2ab9c64aac38eb6f92d


db.stats()实际是一个语法糖,在底层实现是db.runCommand({dbstats:1,scale:scale})的命令,其中包含dbstatsscale两个参数,dbstats是输出值,scale可以控制输出值单位,一般默认dbstats1scalebyte,则此时以byte为单位输出dbstats。另一种方法db.c.stats()db.stats()方法相同,在此不多做赘述。

以上为db.stats()调用出的数据库状态图片,共分以上指标,这其中不少同学曾对dataSizestorageSize的意义感到迷惑。事实上,dataSize指的是数据本身即未压缩时的大小,而storageSize则指的是数据落盘时的大小,数据在落盘时会执行一些相应的压缩算法,比如MongoDB本身默认的snappy压缩算法,压缩率在45倍之间,这便是为什么dataSize往往比storageSize大的原因。当使用者发现这两个数值相近时,很有可能是数据文件出现了文件空洞,这时建议使用者进行compact或者重搭一类的办法消除文件空洞。indexSize指标指的是索引落盘的大小,即索引的物理存储的大小。利用IndexSizestorageSize相加,我们就能得到对应数据库占用磁盘的大小,同时用dataSize除以storageSize我们可以判断压缩比的值,若压缩比值过小,很有可能出现了数据空洞,需要我们对其用compact命令进行处理。

 

2.    MongoDB副本集状态指标解析


4a70520a62ddfab0b3adac5f97c931289d6aefc4


rs.status(),即内部实现db.runCommand({replSetGetStatus:1})命令可查看数据库副本集的状态。其中set指标为副本集的名称,term指标为选举版本号,当集群进行切换或选举时,系统回滚时会使用term对版本号进行判断。optime指标记录了每个当前实例oplog最后的操作时间,通过这个时间与主库的时间进行比较可以得到主从库的延迟。syncingTo指标表示当前结点的同步源,一般情况下是由MongoDB自身各个结点的健康状态生成的。

 

3.    MongoDB进程状态指标解析:(以MongoDB 3.4版本为例)


4f483fc830bf4223f271be2495eaf84ea24fb270


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

option参数使得serverStatus()命令可以追加各种的filter,用以强制系统输出我们希望看到的数据。

 

二.关键指标详解:

下面我们对进程状态指标中比较重要的指标进行一一解读:

 

1.    asserts:

2b45bd7404644ba5958a997679fe2237b27eadc2


asserts本身值得注意的事项较少,这其中asserts|user是一个很有趣的指标,它记录了用户执行命令错误的次数,如果该值较高,说明使用者命令记忆不清晰,建议多读一些指令文档。其他的一些值例如:asserts|msg,asserts|warning等通常为0值,当这些值不为0时,或多或少反映系统存在着某些问题。

 

2.    connections:

649eca0e19a4f77fea1eae7196747f20c3e5dbbe


connections指标标注的是连接的状况,其中availablecurrent均显示的是当前的值,available表示数据库当前可用的连接量,当其值过低时,可能是出现了连接池过满的现象,通过改进数据库配置中的maxConnection或改善一些慢查询占用的连接可解决此问题。current表示数据库当前的连接数,当这个值高时,即出现了与available过低一样的问题,参考以上的解决方法同样可以解决此种问题。另一指标totalCreated记录了MongoDB启动后一共创建过多少个连接,通过采集工具做delta后我们可以得到每秒的创建量,当每秒的创建量过大时,说明我们的数据库采用了过多的短连进行连接,由于MongoDB基于线程模型的特点,过多的短连会使数据库的性能下降,希望大家多重视这个指标。

 

3.    globalLock:

a06970170191ae650d41284fd4c68595ee2423ff


globalLock中的值同样表示的是当前的值,相较于connections, globalLock的值均由server内部的状态值中取出。其中activeClients主要描述了当前请求客户端操作锁的情况,currentQueue描述了当前进行有关锁的操作的队列情况,当这其中有过高指标时,说明我们的业务中正有大的有关锁部的操作影响着数据库的性能。

 

4.    locks:

e2c7d2cfdfb638e70f89db887eb55fae2af92300


除了globalLocks,还有另一个指标locks同样负责描述数据库中锁的情况。大家会注意到在一些子指标中会有大写的”W,R”与小写的”w,r”。在这里,小写的rw均为意向锁的意思,MongoDB的意向锁更像乐观锁,即虽然使用了锁但事实上并没有锁住数据。而我们真正需要关注的是大写的WR,它们均为排它锁,它们的值也是累计值,通过它们每秒的增值,我们可以判断出我们系统的健康状况及业务访问的合理程度。子指标oplog的锁在从库上表现非常明显,当我们的从库触发apply oplog时,它会对oplog进行加锁。oplog是一个全局锁,当长时间触发时,会影响从库的读取,大家尽量保持主从库之间延迟处在较小的水平,反过来说当我们的从库读请求变慢时,我们也可以参考这个值判断是否是主从库延迟过大的问题。

 

5.    network:

7d210702d078a02f31461fed13ef5519ff35fe0e


network是一个记录网络流量的累计值。bytesInbytesOut分别表示网络进口与网络出口流量,这些数据均已在MongoDB端被统计,physicalBytesInphysicalBytesOut3.4版本新加的指标,表示压缩后即物理实际进口流量及物理即压缩后出量。

 

6.    opcounters:

850305609d5bbad6f64ab9fd7558b344fad6bf1d


opcounters是大家在使用过程中会经常参考的指标,是一个比较经典的监控指标 opcounters即为Op本身的一些QPS,其中command表示除了delete,getmore,insert,query,update以外,其他所有的操作命令,比如执行ServerStatus等这样一些操作,这个值也是累计值,我们通过采集它每秒的增量并将它们加和可以得到它真实的QPS,它的最大值是230次方,当系统运行时间过长该值超过230次方时,它会置为0值。大家有时会有这样的疑问:“为什么有时系统在某一时刻大量的超时,但QPS却并不高?”这是因为MongoDB的统计都是在操作执完成之后才会生成,如果此时使用者的操作在MongoDB内部被锁住的话,这就造成了业务之间的时间差使得在这段时间内QPS不会增高,反而降低。


7.    mem:

9a5a468bc3459ec212b66e0b77d326b567714e1c


mem指标描述的大多数是内存中的状态。bits表示当前的MongoDB由多少位编译而成。resident表示常驻物理内存的大小,单位是兆。mem中的指标均为当前的值,大家取出来可以直接使用。

 

8.    metrics:

c2c8261e8ea715010fbf96cea94c84ed221ed858


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:

a707b5756752af8ab13aad555e56fa8c206c9e08


wiredTiger|cache|maximum bytes configured用来配置cache大小的指标,wiredTiger|cache|bytes currently in the cache表示当前cache使用大小的指标,二者相除,即可得到cache的使用率,tracked dirty bytes in the cache表示当前脏页大小,即我们写入或落盘的cache大小,写入大,如果是常态,可以适当提高dirty triggerbytes read into cachebytes written from cache指标是cache的读写量,它们的高低一般体现在我们磁盘的io读与io写上。concurrentTransactions是一个很有趣的指标,不知道大家平时是否有注意过?这个指标表示的是wiredTiger本身transaction控制的数量,这个值默认的是128个,当有一个请求时,会耗用一个transaction,在请求结束时,被耗用的值会被加回,当所有128个值被耗用光时,则从MongoDB层到所有引擎层的请求均会被block住,这些请求只有wiredTiger将持有的transaction释放掉时才会被执行。transaction checkpoint total time 指标也是一个累计值,它会在checkpoint结束之后才会进行计算该值,我们可以通过这个值计算checkpoint开始时间,并检查是否与系统发生问题的时间吻合。


三.场景诊断:

介绍了以上这么多指标,我们下面在使用场景中来看看它们是怎么应用的。

1.    当我们的客户端报错:client checkout connect timeout

7d58234911fc5a0dcf994f0447eba39fc0419f5d


这种情况般是客户端没有释放链接或者没有用连接池技术导致的,这时我们往往要看服务端与应用端的连接池情况。对于应用端来说,我们要关注connection.avaliable这个指标是否曾经出现过跌至0的情况,如上图所示,这是一张秒级监控图,在图中我们会发现虽然多数时间内avaliable指标会升满,但是有时该值还是会跌为0,在跌0的点,就一定会出现timeout的报错。通过这个指标的异常,我们可以采取在应用端使用一些连接池技术或检查一下是否存在连接没有释放等措施来进行一些优化。

 

2. 写入不断超时:

6ea94e4d3cdb4e5e18e980913ca408add205fd4a

写入不断超时的情况是一个比较常见比较经典的情况了。当出现这种问题时,我们会发现我们数据库中的cache usage指标会不断飙高,有时也会出现transactions指标跌0的现象出现,此时明显我们的读写操作已无法继续执行。


四.总结

以上即为MongoDB中重要监控指标的解读及应用,通过这些指标我们可以比较快地确定我们业务中出现的问题,希望大家在使用MongoDB的过程中对这些指标有所重视。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章