MongoDB 监控指标汇总
容量
通过db.stats
命令可获得每个数据库的存储空间信息。
分类 | 指标名 | 监控项 | 参考阈值 |
---|
容量 | 索引大小 | dbstats.indexSize | <= cacheSize |
容量 | 数据大小 | dbstats.dataSize | <= 2T × 80% |
容量 | 存储大小 | dbstats.storageSize | <= diskSize × 60% |
- 数据库的
cacheSize
值要求可容纳索引,否则会影响性能。 - 对磁盘空间的需求约等于
storageSize
(WiredTiger压缩后的数据集大小) 和 indexSize
的总和,考虑水位线设定在80%
左右。
资源用量
连接数
通过db.serverStatus命令获得完整的数据库状态指标信息。
分类 | 指标名 | 监控项 | 参考阈值 |
---|
连接数 | 可用连接数 | connections.available | > 0 |
连接数 | 当前连接数 | connections.current | <= 8000 |
- 数据库通过设定
maxIncomingConnections
可以限定单进程可接入的连接数,默认为65536。
并发队列
分类 | 指标名 | 监控项 | 参考阈值 |
---|
并发数 | ticket读用量 | wiredTiger.concurrentTransactions.read.out | < 128 |
并发数 | ticket写用量 | wiredTiger.concurrentTransactions.write.out | < 128 |
并发数 | ticket读剩余量 | wiredTiger.concurrentTransactions.read.available | > 0 |
并发数 | ticket写剩余量 | wiredTiger.concurrentTransactions.write.available | > 0 |
WiredTiger
引擎使用 ticket
计票方式用于管理并发的线程。ticket
数一般对应了同时进行的读写操作。当剩余可用的ticket
为0时,新的读写请求会被阻塞(进入阻塞队列)。
内存、缓存使用
分类 | 指标名 | 监控项 | 参考阈值 |
---|
内存 | 物理内存 | memory.resident | < OS.TotalMemory × 85% |
内存 | 虚拟内存 | memory.virtual | < OS.TotalMemory |
缓存 | 缓存使用大小 | wiredTiger.cache.”bytes currently in the cache” | < maximum × 95% |
缓存 | 最大缓存大小 | wiredTiger.cache.”maximum bytes configured” | 无 |
缓存 | 脏缓存大小 | wiredTiger.cache.”tracked dirty bytes in the cache” | < maximum ×20% |
缓存 | 读入缓存页数 | wiredTiger.cache.”pages-read-into-cache” | 观察波动 |
缓存 | 未修改淘汰页 | wiredTiger.cache.”unmodified pages evicted” | 观察波动 |
WiredTiger
会同时使用文件系统缓存以及存储引擎的缓存(默认内存的一半)。memory.resident
是指MongoDB占用的物理内存,一些Schema设计不合理、不必要的冗余索引等情况都可能导致占用过多的内存。- 脏缓存指的是缓存中已经被修改,但还没有刷新到磁盘的数据。脏数据比例逐渐增多,当达到20%以上时,则意味着缓存淘汰压力很大,此时业务请求时延会相应增加。通常如果写压力过大,磁盘写性能存在不足,则可能会出现脏数据比例持续较高的情况,可以通过提升磁盘性能或进行水平扩展优化。
- 对于读场景较多的业务,最好预留充足的缓存空间。
checkpoint
、TTL
定时器在一定程度上会产生积压式的写。如果磁盘能力较差,则会出现I/O用率的尖峰;如果出现业务时延抖动,则可以考虑设置更小的触发间隔以达到平滑写入。
吞吐量
访问类指标
分类 | 指标名 | 监控项 | 参考阈值 |
---|
访问量 | insert | opcounters.insert(增速) | 合并写操作计算 |
访问量 | query | opcounters.query(增速) | 合并读操作计算 |
访问量 | update | opcounters.update(增速) | 合并写操作计算 |
访问量 | delete | opcounters.delete(增速) | 合并写操作计算 |
访问量 | getmore | opcounters.getmore(增速) | 合并读操作计算 |
访问量 | command | opcounters.command(增速) | <= 10000 |
流量 | netIn | network.bytesIn(增速) | <= 100MB |
流量 | netOut | network.bytesOut(增速) | <= 100MB |
队列 | 活跃的读客户端数 | globalLock.activeClients.readers | < 128 |
队列 | 活跃的写客户端数 | globalLock.activeClients.writers | < 128 |
队列 | 阻塞的读客户端数 | globalLock.currentClients.readers | < 32 |
队列 | 阻塞的写客户端数 | globalLock.currentClients.writers | < 32 |
opcounters
是当前请求操作的计数器,检查不同类型操作的增速用于判断当前的访问吞吐量。- 通过合理地监控读写请求,可以快速发现潜在的负载瓶颈,并在问题发生前采取措施进行扩容。
游标
分类 | 指标名 | 监控项 | 参考阈值 |
---|
游标 | 同时打开的游标数 | metrics.cursor.open.total | 无 |
游标 | 超时的游标数 | metrics.cursor.open.total | 无 |
游标 | 永不超时的游标数 | metrics.cursor.open.noTimeout | 无 |
- MongoDB会为每个查询启用一个游标(cursor),并指向一个查询结果集。
- 当一个连接异常断开时,游标可能没有关闭,此时数据库会自动延长其超时时间。如果在后续的10分钟内(cursor.timeOut)没有活动,则被销毁。如果应用未及时关闭游标,则会导致大量的游标积压,这会消耗较多的内存。
副本集
分类 | 指标名 | 监控项 | 参考阈值 |
---|
复制 | 节点状态 | members.state | = PRIMARY/SECONDARY/ARBITER |
复制 | 节点复制延迟(lag) | members.optimeDate[primary] -members.optimeDate[secondary] | < 60s |
复制 | 复制窗口(window) | getReplicationInfo().timeDiff | > 5h |
复制 | 复制净值(headroom) | oplog.window - oplog.lag | > 0 |
- 复制延迟(replication lag)描述了备节点与主节点之间的差距。该值越小表明情况越佳。
- 复制窗口是
oplog
集合中最新和最老的记录之间的时间间隔。 - 复制净值是复制窗口与复制延迟的差值。
Reference
- 《MongoDB进阶与实战:微服务整合、性能优化、架构管理》(唐卓章)
Disclaimer
- License under
CC BY-NC 4.0
- Copyright issue feedback
me#imzye.me
, replace # with @ - Not all the commands and scripts are tested in production environment, use at your own risk
- No privacy information is collected here
Try iOS App