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

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

在我们平时的数据库使用当中，监控系统，作为排查故障，告警故障的重要辅助系统，对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的用户可以自主进行监控开启，体验秒级监控带来的高清体验。

原文链接

干货好文，请关注扫描以下二维码：

如何利用秒级监控进行mongodb故障排查相关推荐

阿里云云数据库RDS秒级监控功能解锁，通宵加班找故障将成为过去式
摘要: 每一个奋斗在前线的数据库管理员和运维人员似乎运气都不太好,这些人都绝对经历过的诡异事件就是:逢年过节必出故障,明明眼看着要休假了,又接到故障通知,只好通宵加班找问题.没问题的时候可能大家都不会 ...
第一章基础设施，1.1 万亿交易量级下的秒级监控(作者：郁松、章邯、程超、癫行)...
1.1 万亿交易量级下的秒级监控前言 2016财年,阿里巴巴电商交易额(GMV)突破3万亿元人民币,成为全球最大网上经济体,这背后是基础架构事业群构筑的坚强基石. 在2016年双11全球购物狂欢节中 ...
阿里万亿交易量级下的秒级监控
本文整理自 GOPS2017全球运维大会·上海站演讲<万亿交易量级下的秒级监控> 作者简介孔罗星癫行研发效能事业部-监控平台-技术专家 2014年加入阿里巴曾在福建富士通开发CMD ...
美信“监控易”：海量秒级监控，实现一体化集中运维
随着云计算及物联网的到来,网络化.数字化.智能化成为企业发展的新方向,IT系统的建设成为重中之重,因此运维监控显得尤为重要.面对大量设备的指数型增长,使用传统监控方式的企事业单位普遍面临以下挑战: 挑 ...
记一次MongoDB故障排查的过程
数据技术嘉年华等你来预告:11.16-17日,北京市东三环中路61号富力万丽酒店,相聚数据技术嘉年华,(99元票务)免费购票倒计时,点击查看大会详情. 张甦老师带来主题"双剑合璧带你走进M ...
2017双11技术揭秘—阿里数据库进入全网秒级实时监控时代
摘要: 2017双11再次创下了32.5万笔/秒交易创建的纪录,在这个数字后面,更是每秒多达几千万次的数据库写入,如何大规模进行自动化操作.保证数据库的稳定性.快速发现问题是一个巨大的难题, 这也是数 ...
十万服务器秒级管控腾讯云如何将AIOps用于日常管理？
AIOps,是指基于算法的 IT运维(Algorithmic IT Operations),由 Gartner定义的新类别,源自业界之前所说的 ITOA(IT Operations and Analy ...
基于Flink秒级计算时CPU监控图表数据中断问题
基于Flink进行秒级计算时,发现监控图表中CPU有数据中断现象,通过一段时间的跟踪定位,该问题目前已得到有效解决,以下是解决思路: 一.问题现象以SQL02为例,发现本来10秒一个点的数据,有时会 ...
c语言计时纳秒_如何利用rdtsc计算纳秒级的时间
从奔腾(Penium)系列开始,Intel X86 处理器中增加了一个64位的时间戳寄存器(TSC),每个经过一个时钟周期,该寄存器加1:机器重启时,该寄存器将清空. 现在的处理器其主频都在1G以上, ...

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

如何利用秒级监控进行mongodb故障排查相关推荐

最新文章

热门文章