javamongodb监控_MongoDB监控之⼀：运⾏状态、性能监
控，分析
为什么要监控？
监控及时获得应⽤的运⾏状态信息，在问题出现时及时发现。
监控什么？
CPU、内存、磁盘I/O、应⽤程序(MongoDB)、进程监控(ps -aux)、错误⽇志监控
1.4.1 MongoDB集监控⽅式
db.serverStatus()
db.serverStatus()　包含的监控信息是从上次开机到现在为⽌的累计数据，因此不能简单使⽤。
⾮常核⼼的有：
connections：关于连接数的信息；
locks：关于mongoDB使⽤的锁情况；
network：⽹络使⽤情况统计；
opcounters：CRUD的执⾏次数统计；
repl：复制集配置信息；
wiredTiger：包含⼤量wiredTiger执⾏情况的信息：
block-manager：WT数据块的读写情况；
session：session使⽤数量；
concurrentTransactions：Ticket使⽤情况；
mem：内存使⽤情况；
metrics：⼀系列性能指标统计信息；
查看实例运⾏状态(内存使⽤、锁、⽤户连接等信息)
通过⽐对前后快照进⾏性能分析
"connections"# 当前连接到本机处于活动状态的连接数"activeClients"# 连接到当前实例处于活动状态的客户端数量"locks"# 锁相关参数"opcounters"# 启动之后的参数"opcountersRepl"# 复制想关"storageEngine"# 查看数据库的存储引擎"mem" # 内存相关
状态:
db.stats()
显⽰信息说明：
# 统计数据库信息
db.stats()
{"db" : "test", # 系统⾃带测试数据库"collections" : 0, # 集合数量"views" : 0, #"objects" : 0, # ⽂档对象的个数, 所有集合的记录数之和"avgObjSize" : 0, # 平均每个对象的⼤⼩, 通过 dataSize /Objects 得到"dataSize" : 0, # 当前库所有集合的数据⼤⼩"storageSize" : 0, # 磁盘存储⼤⼩"numExtents" : 0, # 所有集合的扩展数据量统计数"indexes" : 0, # 已建⽴索引数量"indexSize" : 0, # 索引⼤⼩"fileSize" : 0, #"fsUsedSize" : 0, #"fsTotalSize" : 0, #总⼤⼩"ok" : 1}
1.4.2 mongostat
mongostat是mongdb⾃带的状态检测⼯具，在命令⾏下使⽤。它会间隔固定时间获取mongodb的当前运⾏状态，并输出。如果你发现数据库突然变慢或者有其他问题的话，你第⼀⼿的操作就考虑采⽤mongostat来查看mongo的状态。
主要功能：
实时数据库状态，读写、加锁、索引命中、缺页中断、读写等待队列等情况。
每秒刷新⼀次状态值，并能提供良好的可读性，通过这些参数可以观察到MongoDB系统整体性能情况。
常⽤命令格式：
mongostat --host 192.168.1.100:27017 -uroot -p123456 --authenticationDatabase admin
参数说明：
host：指定IP地址和端⼝，也可以只写IP，然后使⽤--port参数指定端⼝号
-u： 如果开启了认证，则需要在其后填写⽤户名
-p: 不⽤多少，肯定是密码
--authenticationDatabase：若开启了认证，则需要在此参数后填写认证库(注意是认证上述账号的数据库)
输出各字段解释说明：
insert/s : 官⽅解释是每秒插⼊数据库的对象数量，如果是slave，则数值前有*，则表⽰复制集操作
query/s : 每秒的查询操作次数
update/s : 每秒的更新操作次数
delete/s : 每秒的删除操作次数
getmore/s: 每秒查询cursor(游标)时的getmore操作数
command: 每秒执⾏的命令数，在主从系统中会显⽰两个值(例如 3|0)，分表代表 本地|复制 命令
注： ⼀秒内执⾏的命令数⽐如批量插⼊，只认为是⼀条命令(所以意义应该不⼤)
dirty: 仅仅针对WiredTiger引擎，官⽹解释是脏数据字节的缓存百分⽐
used：仅仅针对WiredTiger引擎，官⽹解释是正在使⽤中的缓存百分⽐
flushes:
For WiredTiger引擎：指checkpoint的触发次数在⼀个轮询间隔期间
For MMAPv1 引擎：每秒执⾏fsync将数据写⼊硬盘的次数
注：⼀般都是0，间断性会是1， 通过计算两个1之间的间隔时间，可以⼤致了解多长时间flush⼀次。flush开销是很⼤的，如果频繁的flush，可能就要原因了
vsize： 虚拟内存使⽤量，单位MB (这是 在mongostat 最后⼀次调⽤的总数据)
res:  物理内存使⽤量，单位MB (这是 在mongostat 最后⼀次调⽤的总数据)
注：这个和你⽤top看到的⼀样, vsize⼀般不会有⼤的变动， res会慢慢的上升，如果res经常突然下降，去查查是否有别的程序狂吃内存。
qr: 客户端等待从MongoDB实例读数据的队列长度
qw：客户端等待从MongoDB实例写⼊数据的队列长度
ar: 执⾏读操作的活跃客户端数量
aw: 执⾏写操作的活客户端数量
注：如果这两个数值很⼤，那么就是DB被堵住了，DB的处理速度不及请求速度。看看是否有开销很⼤的慢查询。如果查询⼀切正常，确实是负载很⼤，就需要加机器了
netIn:MongoDB实例的⽹络进流量
netOut：MongoDB实例的⽹络出流量
注：此两项字段表名⽹络带宽压⼒，⼀般情况下，不会成为瓶颈
conn: 打开连接的总数，是qr,qw,ar,aw的总和
注：MongoDB为每⼀个连接创建⼀个线程，线程的创建与释放也会有开销，所以尽量要适当配置连接数的启动参
数，maxIncomingConnections，阿⾥⼯程师建议在5000以下，基本满⾜多数场景。
1.4.3 mongotop
mongotop命令说明：
[mongod@MongoDB oplog]$ mongotop -h 127.0.0.1:27017
2018-01-08T17:32:56.623+0800 connected to: 127.0.0.1:27017ns total read write2018-01-
08T17:32:57+08:les 0ms 0ms 0ms
admin.system.users 0ms 0ms 0ms
admin.system.version 0ms 0ms 0ms
app.user 0ms 0ms 0ms
automationcore.automation.job.status 0ms 0ms 0ms
automationstatus.lastAgentStatus 0ms 0ms 0ms
mongotop重要指标
ns：数据库命名空间，后者结合了数据库名称和集合。
total：mongod在这个命令空间上花费的总时间。
read：在这个命令空间上mongod执⾏读操作花费的时间。
write：在这个命名空间上mongod进⾏写操作花费的时间。
1.4.3 mongosniff
此⼯具可以从底层监控到底有哪些命令发送给了MongoDB 去执⾏，从中就可以进⾏分析：以root ⾝份执⾏：
$./mongosniff --source NET lo
然后其会监控位到本地以localhost 监听默认27017 端⼝的MongoDB 的所有包请求。
1.4.3 db级别命令
1、db.currentOp()
db.currentOp是个好东西，顾名思义，就是当前的操作。在mongodb中可以查看当前数据库上此刻的操作语句信息，包括
insert/query/update/remove/getmore/command等多种操作。直接执⾏
db.currentOp()⼀般返回⼀个空的数组，我们可以指定⼀个参数true，这样就返回⽤户connections与系统cmmand相关的操作。下⾯看个列⼦：
db.currentOp(true) 会返回很多信息：
db.currentOp()
查看数据库当前执⾏什么操作。
⽤于查看长时间运⾏进程。
通过(执⾏时长、操作、锁、等待锁时长)等条件过滤。
重点关注以下⼏个字段：
字段说明
client
请求是由哪个客户端发起的。
opid
操作的opid，有需要的话，可以通过db.killOp(opid) 直接终⽌该操作。
secs_running/microsecs_running
这个值重点关注，代表请求运⾏的时间，如果这个值特别⼤，请看看请求是否合理。
query/ns
这个字段能看出是对哪个集合正在执⾏什么操作。
mongodb和mysql结合lock*
- 还有⼀些跟锁相关的参数，需要了解可以看官⽹⽂档，本⽂不做详细介绍。
- db.currentOp⽂档请参见：db.currentOp。
⽰例：
gechongrepl:PRIMARY>db.currentOp()
{"inprog": [
{"opid" : 6222,"active" : true,"secs_running" : 3,"microsecs_running" : NumberLong(3662328),"op" : "getmore","ns" : "local.oplog.rs","query": {
},"client" : "192.168.91.132:45745","desc" : "conn5","threadId" : "0x7f1370cb4700","connectionId" : 5,"waitingForLock" : false,"numYields" : 0,"lockStats": {"timeLockedMicros": {"r" : NumberLong(141),"w" : NumberLong(0)
},"timeAcquiringMicros": {"r" : NumberLong(16),"w" : NumberLong(0)
}
}
}
]
}
opid" : 6222,#进程号
"active" : true,#是否活动状态
"secs_running" : 3,#操作运⾏了多少秒
"microsecs_running" : NumberLong(3662328),
"op" : "getmore",#操作类型，包括(insert/query/update/remove/getmore/command)
"ns" : "local.oplog.rs",#命名空间
"query" : {},#如果op是查询操作，这⾥将显⽰查询内容；也有说这⾥显⽰具体的操作语句的
"client" : "192.168.91.132:45745",#连接的客户端信息
"desc" : "conn5",#数据库的连接信息
"threadId" : "0x7f1370cb4700",#线程ID
"connectionId" : 5,#数据库的连接ID
"waitingForLock" : false,#是否等待获取锁
"numYields" : 0,
"lockStats" : {
"timeLockedMicros" : {#持有的锁时间微秒
"r" : NumberLong(141),#整个MongoDB实例的全局读锁
"w" : NumberLong(0)},#整个MongoDB实例的全局写锁
"timeAcquiringMicros" : {#为了获得锁，等待的微秒时间
"r" : NumberLong(16),#整个MongoDB实例的全局读锁
"w" : NumberLong(0)}#整个MongoDB实例的全局写锁
2、db.killOp(opid)
kill当前的操作 opid为具体的操作id号，当然了，只能kill正在进⾏中的。opid是通过db.currentOp()查询返回的。如果发现⼀个操作太长，把数据库卡死的话，可以⽤这个命令杀死他：> db.killOp(608605)
⽰例：
{ "inprog":
[
{"opid" : 3434473,//操作的id

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。