MONGODB serverStatus 对监控的意义

byt

最近听到一些对MONGODB的理解的歧义,认为MONGODB 数据库内容比较少,并没有一些值得深入研究,诚然对比不少数据库MONGODB看似是简单的,但任何一门技术都有他的特殊性,如果只是表面皮毛的利用和使用,或许也没有什么问题,可遇到问题后,如何解决就成了问题, 是做扁鹊 还是扁鹊的哥哥们,或者是一个庸医,都在你自己的一念之差.

对于MONGODB 的监控,获取有用的信息 serverStatus 是非常有意义

对于大批量的MONGODB 其实我们要管理,就需要对MONGODB 系统的状态信息进行收集.

例如我们去查看断言的asserts 其中例如 warning  , user 数量的变化,在有明显的某段时间的增量后,就需要对mongodb的日志进行观察,查询了.

同时对于MONGODB 连接的信息的统计,活跃连接,可继续分配的连接数等信息.

在这些基础的信息后,我们更关注的是性能方面的信息,例如锁,MONGODB 虽然是NOSQL 数据库但实际上也会存在锁有关的情况, 尤其在新版本后支持多文档事务的这样的情况

mongdb 中可以查看db.serverStatus() 中的 globalLock 时间,如果total有数字,则说明已经有锁征用,多个资源等待锁,如果数字持续上升的情况下. 如果要更细的分析,则可以分析是readers 或者 writers 那个方面产生了相关的征用的等待.

db.serverStatus().locks中可以获得database ,oplog ,以及 collection的locks 这里可以关注相关的collection 的数字的变动,如果有浮动有变化可以关注相关的collection 锁的增加的情况.

从另一个方面也说明在设计MONGODB 的schema的时候,有设计需要进行调整和更改的可能.

其中serverStatus中有一大块是涉及wiredTiger的, MMAPv1存储引擎已经不在是MONGODB 的重点或未来将被取消,则我们在注意MONGODB的内存的问题,则需要关注  writedTiger Cache 中的内容,

例如: bytes currently in the cache  和  bytes dirty in the cache cumulative  这两个值的对比可以看出,到底与上期说的checkpoint调整的是否需要,如果长时间脏数据占比都比较高的情况下,的确是要考虑相关的

调整.

例如如果统计每秒的operation 的操作,与执行的命令之间的关系,就需要下面两个参数从db.serverStatus 中提取

如果觉得某项技术简单,实际上是没有入门, 知识要想深入,总有越学越觉得自己不会的感觉, 例如wiretiger 数据库引擎是 b+tree 还是  lsm树的存储方式,其实两者都可以作为mongodb collection的存储方式, 那么后面的问题是那种效率更高,那种情况要使用那种存储方式等等,  所以问我你会某项技术吗,有时真不敢说 会.