从仪表盘探索 MongoDB 关键指标
这是 MongoDB 监控系列文章的第七篇,前面几篇文章的链接如下:
按照前面系列文章,我们已经采集到 MongoDB 的监控数据了,并且通过 Grafana 和 Nightingale 的仪表盘看到了数据,这一节开始,我们来探索一下 MongoDB 的关键指标,对于未来配置告警规则、排查问题都有帮助。
通过 MongoDB Grafana 仪表盘查看 MongoDB 关键指标
一般仪表盘中每个图表的左上角,会有一个 i
图标,点击这个图标,可以看到这个图表的一些提示信息,这个信息可是非常重要,是制作仪表盘的那个人的经验总结。我们先看看 Grafana 那个仪表盘,看的时候注意看这个提示信息。
mongodb_instance_uptime_seconds
这个指标是 MongoDB 实例的运行时间,这个指标是一个累加值,单位是秒,可以用来判断 MongoDB 实例的运行时间,如果这个值突然变小,说明 MongoDB 服务重启了。有人会创建一个告警规则:如果这个值小于 300,就报警,说明最近 5 分钟内发生过重启。当然了,这么粗暴的告警规则,在新实例刚刚启动的时候,也会报警。
qps
mongodb_op_counters_total 表示总的操作次数,显然是 counter 类型,即单调递增的,所以使用 irate 或 rate 求每秒操作次数,又因为 type 有多种取值,所以 sum 一下把各类操作求和,但是 type 排除了 command,不知道原因是啥,莫非是因为 command 是什么特殊操作?回头再研究。
latency
mongodb_mongod_op_latencies_latency_total 是延迟总量,mongodb_mongod_op_latencies_ops_total 是操作总量,求 rate 之后再相除,就是每个操作的平均延迟了。具体细节还需要进一步研究。
Current ReplSet State
这个图表有提示:
This shows the role of the selected service. Normally this should be one of PRIMARY, SECONDARY and ARBITER, but if the system is newly added it could show STARTUP2 during its initial sync.
看起来是 MongoDB 集群中某个实例的角色,一般是 PRIMARY、SECONDARY 和 ARBITER 三种,如果是新加入的实例,可能会显示 STARTUP2,这个提示很有用,可以帮助我们理解这个图表。但是我的显示的是 STARTUP,可能是因为我是一个 standalone 实例,不是集群。
在 Prometheus 生态里没法存储字符串,所以这里显示的内容显然是根据数字换算出来的,我们先看看这个图表对应的指标:
核心就是 mongodb_mongod_replset_my_state 指标,这个指标是一个数字,根据这个数字,我们可以知道这个实例的角色。从图表上可以看到对应关系:
Command Operations
这个图表包含三个 promql:
mongodb_op_counters_total 用于计算普通操作,mongodb_mongod_op_counters_repl_total 用于计算 repl 相关的操作,mongodb_mongod_metrics_ttl_deleted_documents_total 用于计算 TTL 删除的文档数。具体含义就需要研究 MongoDB 的文档和原理了,回头再说。
Latency detail
这个 promql 和前面的 Latency 是一样的,只不过上面的是展示的当前值,下面这个展示的是趋势图,并且下面的会把不同的 type 的 command 都展示出来,这样可以看到不同操作的延迟情况。
Current Connections
对于数据库而言,连接数是一个非常重要的指标,这个图表展示了当前连接数,这个指标是一个 gauge 类型,即时的,不是累加值。
Cursors
这个图表展示了当前打开的游标数,这个指标是一个 gauge 类型,即时的,不是累加值。从图表的 legend 可以看出,这个指标有个 state 标签,用来区分不同状态的游标。
Document Operations
表示文档操作的总数,这个指标是一个 counter 类型,即单调递增的,所以使用 irate 或 rate 求每秒操作次数。从 legend 可以看出,这个指标有个 state 标签,用来区分不同类型的文档操作。
Queued Operations
这个 panel 有个提示:Operations queued due to a lock. 由于锁的缘故积压的操作数。
没有使用 rate、irate 之类的,说明是一个 gauge 类型的指标,从 legend 看出这个指标有个 type 标签,用来区分不同类型的数据。
Query Efficiency
Panel 提示:Ratio of Documents returned or Index entries scanned / full documents scanned。 返回的文档数或索引条目数与扫描的完整文档数的比率。
另一个:
如果扫描了很多,但是返回的很少,即上面的值较小说明效率低,反之效率高。具体还需要再研究。
Scanned and Moved Objects
这个 panel 有提示:This panel shows the number of objects (both data (scanned_objects) and index (scanned)) as well as the number of documents that were moved to a new location due to the size of the document growing. Moved documents only apply to the MMAPv1 storage engine。 此面板显示了由于文档大小增长而将对象(数据(scanned_objects)和索引(scanned))移动到新位置的数量,由于文档大小增长而移动的文档仅适用于 MMAPv1 存储引擎。
另一个:
这两个指标都是 counter 类型,即单调递增的,所以使用 irate 或 rate 求每秒操作次数。
getLastError Write Time
这个 panel 有提示:Legacy driver operation: Number of, and Sum of time spent, per second executing getLastError commands to confirm write concern. 传统驱动程序操作:每秒执行 getLastError 命令以确认写入关注点的数量和时间总和。
这个指标明显是一个 counter 类型,单位是 milliseconds,求 rate 之后表示每秒中有多少 ms 是用于 getLastError 的。
Assert Events
这个 panel 有提示:This panel shows the number of assert events per second on average over the given time period. In most cases assertions are trivial, but you would want to check your log files if this counter spikes or is consistently high. 此面板显示了给定时间段内每秒平均的断言事件数。 在大多数情况下,断言是微不足道的,但如果此计数器激增或持续很高,则应检查日志文件。
这个指标是一个 counter 类型,即单调递增的,所以使用 irate 或 rate 求每秒操作次数。
Page Faults
这个 panel 有提示:Unix or Window memory page faults. Not necessarily from mongodb. Unix 或 Windows 内存页面错误。 不一定来自 mongodb。
这个指标是一个 counter 类型,即单调递增的,所以使用 irate 或 rate 求每秒次数。
总结
通过每个 panel 的研读,我们对 MongoDB 的监控知识又前进了一步,要想彻底弄懂还需要研究 MongoDB 的文档和原理。本文的探索希望给大家一些学习这类知识的方向。
评论