DAY28 MongoDB Atlas 付费监控内容

这篇原本是要在25号发的，因为一些因素，只好延迟到这一天了。

全部的监控项目内容会过於庞大且不是主轴，於是放一些付费的监控指标，免费的功能就让各位自己上去体验了(官网的说明文件很详尽)。

Metrics

可以看到付费等级的监控服务和免费版的 Filter UI 是一样的，但是时间区间就无法改日期，只有当天。

这张图直接完整揭露付费的监控指标(官网完整说明)，在免费版只能看到少数几个，在前面有提到了。这个部分想特别提的是 replication 的监控，在 Atlas 中请特别注意这些项目：

Oplog GB/Hour

顾名思义就是主节点 Oplog 每小时产生的 GB 数，降低此值能够有效减缓其他图表的警告。简单来说就是把源头降低，就不会衍伸出其他问题，这边不是要我们一昧地降低，而是做必要性降低，特别是 schema 设计以及情境设计。

Replication Lag

Replication Lag 表示你的次节点资料复制落後主节点多久，时间越长表示资料同步差异越大，如果时间不断地变长，可能要考虑一下读写频率是否太多以及必要性，导致次节点抄写来不及。这个在之前 Oplog 相关文章有提到一些建议，可以回头参考。

Replication Oplog Window

这个图是按照当前 Oplog 写入的速度来推算，系统 Oplog 还有多久会写满。配合上面的资讯，如果当前预估剩下 1 hour 写满，而次节点已经落後 1 hour 以上，就会出发次节点的 full resync 动作，强制让次节点优先同步主节点资料。

提高 oplog 的大小可以提升剩余时间，毕竟你的缓冲就越大，但还是要去查看这麽大量个修改是否有其必要。至於剩下多少时间是合理的，要看服务的内容以及各位的心脏强度，没有一定的值是安全的。

Replication Headroom

这个项目跟 Replication Oplog Window 很相似，是主节点 Oplog 剩余量 与 次节点延迟的时间，当此值降为 0 时，就会触发次节点进入 Recovering 状态，也就是在做 full resync。这个指标已经建立在其他指标之上，所以进行快速监控时，挑选某一些即可，定期再去扫其他指标，监看 MongoDB 状态是否正常。

Opcounters

每秒钟於主节点执行了多少次操作，其中这些操作包含了 query, insert, update, delete, getMore, command。通常可以分析哪些时刻是高峰期，是否可以将这些分散在各个时间点。而每个高峰时刻又是哪些操作居多，是不是可以进一步优化。

Opcounters - repl

同上，只是图表显示的是次节点。

可以从实际监控中看到两种指标的差异。

Profiler

Profiler 部分左上角是所有项目，下方会列出所有指令操作, 次数和平均时间，让你可以知道哪些操作平均花费时间高。回头来想其实透过对 profiler 集合进行 aggregation 操作也是能办到的(or mongostat)，当然就是比较麻烦，少了画面的拖拉，但整合各个操作的图表呈现就没办法了，整体来说这个项目上线初期会很常使用。

Performance Advisor

这个功能会针对目前 MongoDB 运行的状况给予建议，主要是

• 长时间未使用的索引
  如果有索引长时间没有被使用，这个功能会建议你查看这个索引是否还有需要。

• 效能低落的索引
  有些索引可能评估错，或是需求面修改了，但忘记重新检验索引设计，导致索引效能不彰，系统会挑出来建议给你。

• Collection Scan 语法
  系统会自动帮你记录是否有 Collection scan 的产生，有的话会告诉你详细资讯并提出警告。

这三种不是完全对应到上图的三个项目，但是都包含在内。

Online archive

即时的备份机制。可以看到频率设定上有每小时或是每天，也有 retention 时间，让你在需要回复备份时，可以直接进行操作。

会想要写这篇的原因是觉得 Atlas 很可惜，这些功能在免费版看不到，所以蛮多维运的人不知道 Atlas 的强大与方便(也许可以建议官方提供一些 fixed sample 来帮助推广)。不知道大家都怎麽做 MongoDB 的监控呢？

本系列文章会同步发表於我个人的部落格 Pie Note