一 MONGODB 监控那些基本 “点” 到东拉西扯

文章插图
最近老有一些文字，写不安全，漏洞，损失之类的文章，点进去看，原来就是没有设置最基本的安全验证，俗称用户名密码，你放那个数据库，都不安全，这样博人眼球的文字，我比较“反感”，因为有些“高层人士”，会一遍遍的问，这个安全吗，最近看经常有说不安全，有漏洞的，所以，请写这样文字的人，有点公德心，好好的一个要上线被高层叫停，你是何等心情。
话归正题，的确是很“皮实”的一个数据库，（要不都是雷神做封面）。但在“耐X”你也得监控他不是，要不你使用过度出了差错那就很难搞了。
其实从监控数据库的角度来看大体的监控点都是趋于一致的，然后就是根据每种数据库的细枝末节来进行，区别化对待。
一般那怎么来从里到外的监控，下面就来 TALK 一下
1 使用很少有单机来搞，复制集是标配，所以复制集的滞后就是一个点，复制延迟是指将数据从主节点复制到辅助节点的延迟。这当然的被监控。
2 复制状态，的主副本是随时因为某些因素切换的，所以副本状态跟踪辅助节点是否死亡以及是否有新主节点的选择的方法。
3 锁定状态的统计，锁定状态显示设置了哪些数据锁，以及它们的存在时间长度。
4 内存使用情况，相对于其他的数据库的内存使用量更值得关注。
5 数据库的连接数
6 数据库的磁盘的使用率与程度。
7 语句慢查询
以上的内容不少，所以的监控应该是一个连续剧，今天就用slave lag 来开刀
要看复制延迟那一定都要使用,rs.nInfo(), 这个命令，这个命令本身是可以在复制集中任何的节点中运行的，这个地球人都知道。

文章插图

文章插图
但这里有一个问题，就是在主节点一段时间没有任何操作的过程中，再次操作，此时如果执行了 rs.ninfo 会显示负值，主要的原因他会接受来自节点之前的心跳来对比现在的则会在很短的时间又显示负数的可能，负数的大小与主库有多长时间不活动有关。
所以这里建议的是，在主库运行rs.ninfo命令。
以上的建议在最新的的版本依然有效。
而rs.(), 是另一个针对复制有关的命令，这个命令可以观察你本地的oplog的size以及你的oplog 还可以接受多长时间的数据，first 和 last event 的时间是多少等等，信息。
需要提到的 3.4 以及以前的版本，是不能随便改动 oplog的，这其实不是好事，就如同 MYSQL 不能随便变动 ize 在MYSQL 运行的时候，并且改动很麻烦。
所以如果还在使用 3.4 之前的版本，还是很有必要升级到更新的版本。
至于其他的点，后面会继续，下面是一些常用，或可能你不知道的的简单的监控工具。
1 最常用的监控程序就是自提供的通过可以查看query等操作的类型并且是可以对和提取监控的数据的。
同时为了保证数据的安装也是需要输入用户名和密码的并且你提供的用户需要的权限。

文章插图
通过这个基本的监控，我们可以掌握，例如某些故障时刻或数据库不正常时刻的query,的数据量，看看有什么异常，同时也可以看到 dirty 看看脏页是否过多，系统的资源是否有异常。
：每秒插入数
query：每秒查询数
：每秒更新数
：每秒删除数
：每秒返回的游标数