mongo监控与分析

DB级别监控

1：db.stats()

该命令查看当前数据库的情况【如无特殊说明，单位都是B】

>use fpftest
> db.stats()
{
        "db" : "fpftest",#库名称
        "collections" : 1,#集合个数
        "objects" : 2,#文档个数
        "avgObjSize" : 35,#平均每个文档的大小
        "dataSize" : 70,#数据大小（所有文档）
        "storageSize" : 16384,#数据库占用存储空间大小 
        "numExtents" : 0,#数据库所有集合中的片区计数**？** 
        "indexes" : 1,#索引个数
        "indexSize" : 16384,#索引大小
        "ok" : 1
}

2：db.test.stats()

> db.test.stats()
{
        "ns" : "fpftest.test",#集合名称
        "count" : 2,#文档个数
        "size" : 70,
        "avgObjSize" : 35,
        "storageSize" : 32768,
        "capped" : false,
        "wiredTiger" : {
             ......
}

3：db.serverStatus()

db.serverStatus()#查看MondoDB服务状态，下面两个是常用的选项

>db.serverStatus().connections
{ 
	"current" : 369,#当前活跃（已使用）连接数
 	"available" : 79631, #当前可用连接数
 	"totalCreated" : NumberLong(86006) #表示历史创建的总连接数
}
#总共的可用连接数total= current + available

db.serverStatus().mem
{
        "bits" : 64,#服务器32/64位
        "resident" : 2474,#到现在总共使用的物理内存,单位是MB
        "virtual" : 3689,#当前Mongodb实例使用的虚拟内存大小，单位MB，一般情况下比mem.map的值要超大一点，如果大很多很有可能发生内存泄露，如果使用journal,大约是2倍的map值
        "supported" : true,#本机是否支持内存扩展
        "mapped" : 0,#Mongodb使所有数据都映射到内存中，所以这个值可以看似整个数据量的值。
        "mappedWithJournal" : 0#数据文件和 journaling文件映射到内存中的大小，单位MB，这个值一直是mapped的二倍。
}

4：db.currentOp()

>db.currentOp()
{
        "inprog" : [
                {
                        "desc" : "conn111911",#数据库的连接信息，可与日志信息联系起来，可以用来筛选相关的日志信息。
                        "threadId" : "140075999385344",#线程ID
                        "connectionId" : 111911,#数据库连接ID
                        "client" : "10.62.124.34:37476",#客户端socket
                        "clientMetadata" : {#元数据
                                "driver" : {
                                        "name" : "NetworkInterfaceASIO-RS",
                                        "version" : "3.4.9"
                                },
                                "os" : {
                                        "type" : "Linux",
                                        "name" : "CentOS Linux release 7.4.1708 (Core) ",
                                        "architecture" : "x86_64",
                                        "version" : "Kernel 3.10.0-693.el7.x86_64"
                                }
                        },
                        "active" : true,#当前连接是否处于活动状态
                        "opid" : 757162244,#操作的唯一标识符，可通过它来终止操作，【相当重要】
                        "secs_running" : 2,#操作执行时间，单位秒【相当重要】
                        "microsecs_running" : #操作执行时间，单位毫秒NumberLong(2386307),
                        "op" : "getmore",#操作类型，包括(insert/query/update/remove/getmore/command)
                        "ns" : "local.oplog.rs",#操作对象，一般是数据库.集合名称
                        "query" : {#如果op是查询操作，这里将显示查询内容；也有说这里显示具体的操作语句的
                                "getMore" : NumberLong("12928643803"),
                                "collection" : "oplog.rs",
                                "maxTimeMS" : NumberLong(5000),
                                "term" : NumberLong(313),
                                "lastKnownCommittedOpTime" : {
                                        "ts" : Timestamp(1516859517, 1),
                                        "t" : NumberLong(313)
                                }
                        },
                        "originatingCommand" : {#操作
                                "find" : "oplog.rs",
                                "filter" : {
                                        "ts" : {
                                                "$gte" : Timestamp(1516755142, 1)
                                        }
                                },
                                "tailable" : true,
                                "oplogReplay" : true,
                                "awaitData" : true,
                                "maxTimeMS" : NumberLong(60000),
                                "term" : NumberLong(313)
                        },
                        "planSummary" : "COLLSCAN",
                        "numYields" : 0,#表示该操作交出锁的次数
                        "locks" : {#锁的相关信息 

                        },
                        "waitingForLock" : false,#表示该操作是否因正在等待其他操作交出锁而处于阻塞状态。
                        "lockStats" : {#锁的相关信息
                        		 "timeLockedMicros" : {#此操作获得以下锁后,把持的微秒时间  
                                         "R" : NumberLong(0),#整个mongodb服务实例的全局读锁  
                                         "W" : NumberLong(0),#整个mongodb服务实例的全局写锁  
                                         "r" : NumberLong(0),#某个数据库实例的读锁  
                                         "w" : NumberLong(0) #某个数据库实例的写锁  
                                 },  
                                 "timeAcquiringMicros" : {#此操作为了获得以下的锁，而耗费等待的微秒时间  
                                         "R" : NumberLong(0),#整个mongodb服务实例的全局读锁  
                                         "W" : NumberLong(0),#整个mongodb服务实例的全局写锁  
                                         "r" : NumberLong(0),#某个数据库实例的读锁  
                                         "w" : NumberLong(0)#某个数据库实例的写锁  
                                 }    
                                "Global" : {
                                        "acquireCount" : {
                                                "r" : NumberLong(2)
                                        }
                                },
                                "Database" : {
                                        "acquireCount" : {
                                                "r" : NumberLong(1)
                                        }
                                },
                                "oplog" : {
                                        "acquireCount" : {
                                                "r" : NumberLong(1)
                                        }
                                }
                        }
                }
               
        ],
        "ok" : 1
}

常用的过滤方法，和mongo操作没区别：

db.currentOp(
{
	"op":
	{
		"$in":["insert","update","remove","query"]
	},
	"secs_running" : { "$gt" : 3 },
	"active" : true,
	"ns":"local.oplog.rs"
	}
);

5：db.killOp()

>db.killOp(2564788);

killOp的实现原理如下:
每个连接对应的服务线程存储了一个killPending的字段，当发送killOp时，会将该字段置1；请求在执行过程中，可以通过不断的调用OperationContext::checkForInterrupt()来检查killPending是否被设置，如果被设置，则线程退出。
一个请求要支持killOp，必须在请求的处理逻辑里加上checkForInterrupt()检查点才行，否则即使发送了killOp，也只能等待请求完全处理完毕线程才会退出。
比如createIndex的处理逻辑里包含了类似如下的代码，在createIndex的循环过程中，一旦killPending被置1了，createIndex的执行可以在当前循环结束时退出。
while (!createIndexFinished) {
createIndexForOneElement();
checkForInterupt();
}
所以发送killOp后，请求要执行到下一个『检查点』线程才会退出，MongoDB在很多可能耗时长的请求中，都加入了checkForInterrupt()检查点，如创建索引，repair database，mapreduce、aggregation等。

6：开启Profiling，可以理解为MySQL的慢查询日志

#获取慢查询状态信息
> db.getProfilingStatus()
{
	"was" : 0, #日志级别 0：关闭，不收集任何数据。1：收集慢查询数据，默认是100毫秒。2：收集所有数据
	"slowms" : 100 #查询时间多久会被定义为慢查询，默认100ms
}
#获取慢查询状态信息
> db.getProfilingLevel()
0
#设置日志级别
> db.setProfilingLevel(1)
{ "was" : 1, "slowms" : 100, "ok" : 1 }
#设置日志级别和超时时间
> db.setProfilingLevel(1,200)
{ "was" : 0, "slowms" : 100, "ok" : 1 }
#当开启Profiling时，会自动在该数据库下创建system.profile集合，用于记录慢查询语句
#从一个特定的时间范围内返回信息
> db.system.profile.find(
 {
     ts : {
              $gt : new ISODate("2015-10-18T03:00:00Z"),
              $lt : new ISODate("2015-10-19T03:40:00Z")
           }
 }).pretty()
#特定时间，限制用户，按照消耗时间排序

工具级监控

1：mongostat

2：mongotop

3：mongosniff

注意：分片，副本集可能返回内容有差异，但相应字段含义不变的。

参考资料

1：mongo db.stats()解析
2：mongo db.serverStatus()分析一
3：mongo db.serverStatus()分析二
4：mongo db.serverStatus()分析三
5：官方文档,全局方法
6：mongo db.db.currentOp()分析
7：mongotop/mongostat/
8：mongodb监控常用方法
9：MongoDB监控之一：运行状态、性能监控，分析