如何实现MongoDB的秒级监控？探索高效设置方法

MongoDB秒级监控设置

背景介绍

在当今高速运转的软件环境中，监控系统作为排查故障、告警故障的重要辅助系统，对数据库管理员（DBA）、运维人员和业务开发人员进行问题诊断、排查、分析有着至关重要的作用，而一个监控系统的好坏，很大程度上影响了能否精确地定位故障，以及是否能正确进行问题修复，避免下一次的故障，监控粒度、监控指标完整性、监控实时性是评价一个监控系统的三个重要因素。

目前许多系统的监控粒度只能做到分钟级或半分钟级，这样的监控粒度在面对一些瞬间爆发的大量异常时显得捉襟见肘，提升监控粒度带来的成倍增长的大数据量以及成倍降低的采集频率，对资源的消耗将是极大的考验，而在监控指标完整性上，当前绝大部分的系统采用的是预定义指标进行采集的方式，这种方式存在弊端，如果因为一开始没有意识到某个指标的重要性而漏采，但是恰恰却是某次故障的关键性指标，这个时候这个故障便极有可能变成“无头冤案”。

监控实时性

实时性也是监控系统中不可或缺的一部分，“没有人关心过去是好是坏，他们只在乎现在”，以上三个能力，只要做好一个，就可以称得上是不错的监控系统了，而阿里云自研的秒级监控系统 inspector 已经可以做到 1 秒 1 点的真秒级粒度，全量指标采集、无一疏漏——甚至对曾经没有出现过的指标进行自动采集，实时数据展示，1 秒 1 点的监控粒度，让数据库的任何抖动都无处遁形；全量指标采集，给予了 DBA 足够全面完整的信息；而实时数据展示，能第一时间知道故障的发生，也能第一时间知道故障的恢复。

我们就针对 MongoDB 数据库，来聊一聊如何设置秒级监控以及其在故障排查中的实际应用。

为什么需要秒级监控？

精准捕捉性能波动：传统的分钟级监控无法捕捉到短时间内的性能波动和异常情况，而秒级监控可以提供更精细的数据，帮助团队快速识别并解决潜在问题。

提高响应速度：在高并发环境下，任何微小的延迟都可能引发连锁反应，秒级监控能够及时发现这些变化，使得团队能够迅速采取措施，减少对业务的影响。

优化资源利用：通过实时监控资源使用情况，可以更好地进行容量规划和资源分配，避免浪费或过载。

设置步骤

1. 选择合适的监控工具

需要选择一个支持秒级监控的工具，市面上有许多第三方监控工具可供选择，如 Prometheus + Grafana、Zabbix 等，这些工具不仅支持自定义监控项，还能以图表形式直观展示监控数据。

2. 安装代理程序

在目标服务器上安装监控代理程序，用于收集系统和应用层面的各种指标数据，对于 MongoDB 可以选择官方提供的 MongoDB Monitoring Service 或者使用开源的解决方案如 MongoDB Exporter。

3. 配置监控项

根据业务需求配置具体的监控项，常见的监控项包括但不限于：

CPU 使用率

内存占用

磁盘 I/O

网络流量

MongoDB 特有的指标，如连接数、查询速率、错误率等

确保所有重要的性能指标都被纳入监控范围内，并且设置合理的阈值，以便在超出正常范围时触发警报。

4. 验证与调整

完成初步设置后，观察一段时间内的监控数据，检查是否有遗漏的重要指标或不合理的阈值设置，根据实际情况进行调整优化，确保监控系统能够准确反映系统状态。

5. 集成告警机制

将监控系统与告警系统集成，当检测到异常时能够及时通知相关人员，可以通过邮件、短信、即时消息等多种方式发送告警信息。

案例分析

为了更好地理解秒级监控的应用价值，下面分享两个实际案例：

案例 1：副本集从库延迟问题

之前有一个线上业务使用的是 MongoDB 副本集，并且在业务端进行了读写分离，突然有一天，业务出现大量线上读流量超时的情况，通过秒级监控系统 inspector，我们可以明显看到当时从库的延迟异常飙高。

从库延迟飙高说明从库 oplog 重放线程速度追不上主库写入速度，在主从配置一致的情况下，如果从库的响应速度比不上主库，那就说明从库当时除了正常的业务操作之外，还在进行一些高消耗的操作，经过排查，发现当时 db 的 cache 出现了飙升。

从监控中可以明显看到，cache usage 迅速从 80%左右升到了 95%的 evict trigger 线，dirty cache 也有所攀升，达到了 dirty cache evict 的 trigger 线，对于 wiredTiger 当 cache 使用率达到 trigger 线后，wt 认为 evict 线程来不及 evict page，那么就会让用户线程加入 evict 操作，这时就会导致大量的超时，这一想法通过 application evict time 指标也可以得到印证。

经过业务端的进一步排查，确认是由于当时有大量的数据迁移 job 导致 cache 打满，在对迁移 job 进行限流并增大 cache 之后，整个数据库运行开始变得平稳。

案例 2：分片集群访问超时问题

某日线上一个使用 sharding 集群的业务突然又一波访问超时报错，然后短暂时间后又迅速恢复正常，通过经验判断，当时多半有一些锁操作导致访问超时，通过 inspector，我们发现在故障发生时刻某个 shard 上的锁队列很高，这基本印证了我们之前对于锁导致访问超时的猜想。

那么究竟是什么操作导致了锁队列的飙升呢？很快，通过对当时命令的排查，我们发现当时 shard 上的鉴权命令突然飙高，通过查看代码发现，mongos 到 mongo 虽然使用 keyfile 进行认证，但实际也是通过 sasl 命令的 scram 协议来进行认证，而这个在认证的时候会有一个全局锁，所以当时瞬间大量的鉴权导致了全局锁队列飙升，从而导致访问超时，通过改小客户端的连接数减少了这种突然激增的鉴权产生的全局锁导致超时的问题。

通过以上两个案例可以看出，足够小的监控粒度、足够全面的监控指标项以及监控的实时性对于故障发生时的问题排查有多么重要，实时性在监控墙场景下的作用也十分明显，秒级监控已经在阿里云 MongoDB 控制台开放，云 MongoDB 的用户也可以自主进行监控开启，体验秒级监控带来的高清体验。

小伙伴们，上文介绍了“MongoDB秒级监控_设置秒级监控”的内容，你了解清楚吗？希望对你有所帮助，任何问题可以给我留言，让我们下期再见吧。