一、如何获取监控数据

监控信息的来源:

db.serverStatus()(主要)
db.isMaster()(次要)
mongostats 命令行工具(只有部分信息)

说明: db.serverStatus() 包含的监控信息是从上次开机到现在为止的累计数据 .

三、serverStatus() Output
host
version
process
pid
uptime
uptimeMillis
uptimeEstimate
localTime
asserts
connections
electionMetrics
extra_info
flowControl
freeMonitoring
flowControl
freeMonitoring
globalLock
locks
network
opLatencies
opReadConcernCounters
opcounters
opcountersRepl
oplogTruncation
repl
storageEngine
tcmalloc
trafficRecording
transactions
transportSecurity
wiredTiger

二、serverStatus() 主要信息

connections: 关于连接数的信息;

locks: 关于 MongoDB 使用的锁情况;

network: 网络使用情况统计;

opcounters: CRUD 的执行次数统计;

repl: 复制集配置信息;

wiredTiger: 包含大量 WirdTiger 执行情况的信息:

block-manager: WT 数据块的读写情况;
session: session 使用数量;
concurrentTransactions: Ticket 使用情况;

mem: 内存使用情况;

metrics: 一系列性能指标统计信息;

具体信息如下


#=====实例信息=====

host: 系统的主机名。在Unix / Linux系统中,与hostname命令的输出相同。

version:当前MongoDB进程的MongoDB版本。

process:当前的MongoDB进程,可能的值为mongos或mongod

pid: 进程的id号

uptime: 当前MongoDB进程处于活动状态的总秒数,即启动时长。

uptimeMillis: 当前MongoDB进程处于活动状态的毫秒数。

uptimeEstimate: MongoDB内部粗粒度时间保持系统以秒为单位的启动时长

localTime: ISODate表示服务器当前时间,以UTC表示。

#=====断言asserts=====

> db.serverStatus().asserts

{ "regular" : 0, "warning" : 0, "msg" : 0, "user" : 5, "rollovers" : 0 }

asserts.regular, 自MongoDB进程启动以来引发的常规断言的数量。查看日志文件以获得有关这些消息的更多信息。

asserts.warning, 该字段返回自MongoDB进程启动以来引发的警告次数

asserts.msg,自MongoDB进程启动以来引发的消息断言的数量。查看日志文件以获得有关这些消息的更多信息。

asserts.user, 自上次MongoDB进程启动以来发生的“user断言”的数量。这些是用户可能产生的错误,如磁盘空间不足或重复密钥。

asserts.rollovers, 自上次MongoDB进程启动以来,滚动计数器已滚动的次数。计数器将在230个断言后切换到零。使用此值为断言数据结构中的其他值提供上下文。

#=======globalLock报告数据库锁状态的文档=====

1. globalLock: 报告数据库锁状态的文档。通常,锁文档提供有关锁使用的更详细数据。

2. globalLock.totalTime: 自数据库上次启动和创建全局锁以来的时间(以微秒为单位)。这大致与总服务器启动时间相同。

3. globalLock.currentQueue: 锁引起的排队操作数目的文档

4. globalLock.currentQueue.total: 等锁的操作的总数(即,globalLock.currentQueue.readers和 globalLock.currentQueue.writers的总和)。 持续很小的队列,特别是较短的操作,不必关注。综合考虑globalLock.activeClients 读写相关信息。

5. globalLock.currentQueue.readers: 排队等待读锁的操作数。持续很小的读队列,尤其是较短的操作,不必关注。

6. globalLock.currentQueue.writers: 排队等待写锁的操作数。持续很小写队列,特别是较短的操作,不必关注。

7. globalLock.activeClients: 正在执行读写操作的已连接客户端数目文档,综合考虑globalLock.currentQueue。

8. globalLock.activeClients.total: 内部客户端连接db总数,包括系统线程以及读写队列。由于包括系统线程,此值将高于activeClients.readers 和activeClients.writers之和。

9. globalLock.activeClients.readers: 执行读操作的活跃客户端连接数。

10. globalLock.activeClients.writers: 执行写操作的活跃客户端连接数。

#=======locks报告每个锁和锁数据的文档============

locks..acquireCount:在特定模式下获取锁的次数。

locks..acquireWaitCount: 因锁冲突,引起locks.acquireCount锁等待的次数。

locks..timeAcquiringMicros: 获取锁的等待时间和(以微秒为单位)。

locks.timeAcquiringMicros除以 locks.acquireWaitCount给出特定锁定模式的近似平均等待时间。

locks..deadlockCount: 获取锁时遇到死锁的次数。

#========network网络使用情况,主要是网络的进出量的相关信息===========

network.bytesIn: 数据库接收的网络流量字节数。使用此值可确保发送到mongod进程的网络流量与预期和整个应用程序间流量一致。

network.bytesOut: 数据库发送的网络流量的字节数 。使用此值可确保mongod进程发送的网络流量与预期和整体应用程序间流量一致。

network.numRequests: 服务器已收到的不同请求的总数。使用此值为network.bytesIn和network.bytesOut 值提供上下文, 以确保MongoDB的网络使用率与期望和应用使用一致。

#=========repl报告副本集配置的文档。 repl仅在当前主机是副本集时存在========**

repl.hosts:当前副本集成员的主机名和端口信息(”host:port”)的数组。

repl.setName:当前副本集名称的字符串。此值反映–replSet命令行参数或配置文件中replSetName的值。

repl.ismaster:一个布尔值,指示当前节点是否是副本集的primary节点 。

repl.secondary:一个布尔值,指示当前节点是否是副本集的 secondary成员。

repl.primary:3.0版中的新功能。副本集的当前primary成员的主机名和端口信息(”host:port”) 。

repl.me:3.0版中的新增功能:副本集当前成员的主机名和端口信息(”host:port”)。

repl.rbid:3.0版中的新功能。回滚标识符。用于确定此mongod实例是否发生了回滚。

repl.replicationProgress:在3.2版中更改:以前名称serverStatus.repl.slaves。3.0版中的新功能。

一个数组,副本集的每个成员报告复制进程给这个成员的一个数组文档。通常,这个成员是primary或者使用链式复制的secondary。

要输出repl,必须将repl选项传递给 serverStatus,如下所示:

db.serverStatus({ "repl": 1 })

db.runCommand({ "serverStatus": 1, "repl": 1 })

repl.replicationProgress部分的内容取决于每个成员复制的源。支持内部操作,仅供内部和诊断使用。

repl.replicationProgress[n].rid:ObjectId用作副本集成员的ID。仅限内部使用。

repl.replicationProgress[n].optime:从这个成员报告的,成员应用的oplog最后一个操作信息。

repl.replicationProgress[n].host:主机的名称[hostname]:[port]格式为副本集的成员。

repl.replicationProgress[n].memberID:此成员的副本集的整数标识符

#======mem报告mongod的系统架构和当前内存使用的文档========

shard01:PRIMARY> db.serverStatus().mem

{ "bits" : 64, "resident" : 24, "virtual" : 5496, "supported" : true }

mem:报告mongod的系统架构和当前内存使用的文档 。

mem.bits:可选数字64或32,表示已编译的mongodb实例是32位还是64位体系结构。

mem.resident:该值mem.resident大致相当于数据库进程当前使用的RAM量(以兆字节(MB)为单位)。在正常使用期间,该值趋于增长。在专用数据库服务器中,此数字接近系统内存总量。

mem.virtual:mem.virtual显示mongod进程使用的虚拟内存的总量(以兆字节(MB)为单位)。

mem.supported:一个布尔值,指示底层系统是否支持扩展内存信息。如果为false,表示系统不支持扩展内存信息,则数据库服务器可能无法访问其他 mem值。

#======opcounters========

> db.serverStatus().opcounters

opcounters.insert:自上次启动mongod实例以来收到的插入操作总数

opcounters.query:自 上次启动mongod实例以来收到的查询总数。

opcounters.update:自上次启动mongod实例以来收到的更新操作总数 。

opcounters.delete:自上次启动mongod实例以来的删除操作总数。

opcounters.getmore:自上次启动mongod实例以来“getmore”操作的总数。即使查询数目较低,此计数器也可能很高。作为复制进程的一部分,Secondary节点将发送 getMore操作

opcounters.command:自mongod上次启动实例以来向数据库发出的命令总数 。

opcounters.command计数所有的命令 ,除了写命令: insert,update,和delete。

#=======connections报告连接状态========

connections: 报告连接状态的文档。使用这些值来评估服务器的当前负载和容量要求。

connections.current: 从客户端到数据库服务器的连接数。此数值包括当前的shell会话。考虑connections.available为此数据添加更多上下文的值。

该值将包括所有传入连接,包括任何shell连接或来自其他服务器的连接,例如 副本集成员或mongos实例。

connections.available: 可用的未使用连接数。将此值与 connections.current以了解数据库上的连接负载,查阅UNIX ulimit设置文档,获取有关可用连接的系统阈值的更多信息。

connections.totalCreated: 计算创建到服务器的所有连接。此数字包括已关闭的连接。

五、监控报警的考量
具备一定的容错机制以减少误报的发生;
总结应用各指标峰值;
适时调整报警阈值;
留出足够的处理时间;

三、建议监控指标说明

指标	功能	采集方法
opcounters(操作计数器)	查询、更新、插入、删除、getmore 和其他命令的的数量。	db.serverStatus().opcounters
tickets(令牌)	对 WiredTiger 存储引擎的读/写令牌数量。令牌数量表示了可以进入存储引擎的并发操作数量。	db.serverStatus().wiredTiger.concurrentTransactions
replication lag(复制延迟)	这个指标代表了写操作到达从结点所需要的最小时间。过高的 replication lag 会减小从结点的价值并且不利于配置了写关注 w>1 的那些操作。	db.adminCommand({‘replSetGetStatus’: 1})
connections(连接数)	连接数应作为监控指标的一部分,因为每个连接都将消耗资源。应该计算低峰/正常/高峰时间的连接数,并制定合理的报警阈值范围。	db.serverStatus().connections
复制集节点状态	每个节点的运行状态。如果节点状态不是 PRIMARY、SECONDARY、ARBITER 中的一个,或无法执行上述命令则报警	db.runCommand(“isMaster”)
dataSize(数据大小)	整个实例数据总量(压缩前)	每个 DB 执行 db.stats();