云数据库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/