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

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

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

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

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

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

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

case 1

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

如何利用秒级监控进行mongodb故障排查_第1张图片

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

如何利用秒级监控进行mongodb故障排查_第2张图片

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

如何利用秒级监控进行mongodb故障排查_第3张图片

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

case 2

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

如何利用秒级监控进行mongodb故障排查_第4张图片

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

如何利用秒级监控进行mongodb故障排查_第5张图片

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

如何利用秒级监控进行mongodb故障排查_第6张图片

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

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

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

你可能感兴趣的:(如何利用秒级监控进行mongodb故障排查)