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

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

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

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

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

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

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

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

case 1

之前有一个线上业务,用的是mongodb副本集,并且在业务端进行了读写分离。突然有一天,业务出现大量线上读流量超时,通过inspector可以明显看到当时从库的延迟异常飙高

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

从库延迟飙高,则说明从库oplog重放线程速度追不上主库写入速度,而在主从配置一致的情况下,如果从库的响应速度比不上主库,那只能说明从库当时除了正常的业务操作之外,还在进行一些高消耗的操作。

经过排查,我们发现当时db的cache出现了飙升:

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

从监控中可以明显的看到,cache usage迅速从80%左右升到95%的evict trigger线,并且与此同时,dirty cache也有所攀升,达到了dirty cache evict的trigger线。

对于wiredTiger引擎,当cache使用率达到trigger线后,wt认为evict线程来不及evict page,那么就会让用户线程加入evict操作,然后此时就会大量引起超时。而这个想法通过application evict time指标也可以加以印证:

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

通过上图我们可以清晰的看到,当时用户线程花费了大量时间去做evict,然后导致了正常访问请求的大量超时

然后经过业务端排查,是因为当时有大量的数据迁移job导致cache打满,所以在对迁移job进行限流并且增大cache之后,整个db运行也开始变的平稳。

case 2

某日线上一个使用sharding集群的业务突然又一波访问超时报错,然后短暂时间后又迅速恢复正常。通过经验判断,当时多半有一些锁操作,导致访问超时。

通过inspector,我们发现在故障发生时刻某个shard上锁队列很高:

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

所以基本印证了我们之前对于锁导致访问超时的猜想。那么究竟是什么操作导致了锁队列的飙升呢?

很快,通过对当时命令的排查,我们发现当时shard上的鉴权命令突然飙高:

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

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

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

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

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

相关推荐