如何利用秒级监控进行mongodb故障排查

在我们平时的数据库使用当中，监控系统，作为排查故障，告警故障的重要辅助系统，对dba、运维、业务开发同学进行问题诊断、排查、分析有着重要的作用。并且一个监控系统的好坏，也很大程度上影响了能否精确的定位故障，以及是否能正确进行问题修复，避免下一次的故障。而监控粒度、监控指标完整性、监控实时性是评价一个监控的三个重要因素。

在监控粒度上，目前很多的系统都只能做到分钟级监控，或者半分钟级监控。这样一个监控粒度，在针对当前高速运转的软件环境下，能力已经越来越捉襟见肘。对于一些瞬间爆发的大量异常更是无能为力。而提升监控粒度，带来的成倍增长的大数据量以及成倍降低的采集频率，对于资源的消耗将会是极大的考验。

在监控指标完整性上，当前绝大部分的系统采用的是预定义指标进行采集的方式。这种方式有一个极大的弊端，就是，如果因为一开始没有意识到某个指标的重要性而漏采，但是恰恰却是某次故障的关键性指标，这个时候这个故障便极有可能变成“无头冤案”。

而在监控的实时性上——“没有人关心过去是好是坏，他们只在乎现在”。

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

今天就针对mongodb数据库，来聊一聊当遇到db访问超时时，如果利用秒级监控系统inspector进行故障排查：

case 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指标也可以加以印证：

通过上图我们可以清晰的看到，当时用户线程花费了大量时间去做evict，然后导致了正常访问请求的大量超时
然后经过业务端排查，是因为当时有大量的数据迁移job导致cache打满，所以在对迁移job进行限流并且增大cache之后，整个db运行也开始变的平稳。

case 2

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

所以基本印证了我们之前对于锁导致访问超时的猜想。那么究竟是什么操作导致了锁队列的飙升呢？
很快，通过对当时命令的排查，我们发现当时shard上的鉴权命令突然飙高：

而通过查看代码，我们发现，mongos到mongod虽然使用keyfile进行认证，但是实际也是通过sasl命令的scram协议来进行认证，而这个在认证的时候会有一个全局锁，所以当时瞬间大量的鉴权导致了全局锁队列飙升，然后导致访问超时

所以，最后我们通过改小客户端的连接数，来减少这种突然激增的鉴权产生全局锁导致超时。

通过以上两个case，我们能看到，足够小的监控粒度，足够全面的监控指标项，对于故障发生的问题排查有多么重要，而实时性，在监控墙场景下的作用也十分明显。

最后，秒级监控已经在阿里云mongodb控制台开放，云mongodb的用户可以自主进行监控开启，体验秒级监控带来的高清体验。