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