中国最知名的网站建设公司,ps网站界面设计,拼车网站开发,网站html静态化解决方案摘要#xff1a; 在我们平时的数据库使用当中#xff0c;监控系统#xff0c;作为排查故障#xff0c;告警故障的重要辅助系统#xff0c;对dba、运维、业务开发同学进行问题诊断、排查、分析有着重要的作用。并且一个监控系统的好坏#xff0c;也很大程度上影响了能否精…摘要 在我们平时的数据库使用当中监控系统作为排查故障告警故障的重要辅助系统对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的用户可以自主进行监控开启体验秒级监控带来的高清体验。
原文链接
干货好文请关注扫描以下二维码
