counter服务报警问题分析解决

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了counter服务报警问题分析解决相关的知识,希望对你有一定的参考价值。

counter服务介绍:
    我们sae这边counter服务给用户提供的功能为计数器服务,使用的软件为redis。而我们对counter服务的监控,是通过monitor来做的,主要操作就是set,get,delete,increase,create,remove等操作。而counter报警问题,之前也存在,大概两三天会有一次报警。


报警问题主要分为如下两个阶段:

一,某天counter服务频繁报警:
    是因为之前monitor的counter监控只监控了com组webruntime, 把ent,bigapp加进去之后,频繁报警。这是因为ent,bigapp组sae-php-saecounter软件包版本比较低, 而低版本的包代码中没有添加执行redis操作失败的重试机制。软件版本统一之后,每天counter的报警大概在十几条左右。
    注:
ent,bigapp组counter没升级的原因为新counter的软件包一直在com组做灰度

二,counter服务每天十几条的报警:
通过分析报警内容,redis的 aof文件,monitor报警逻辑及分析tcpdump抓的数据包发现一些问题,具体如下:
    1,报警内容都是create和remove的时候没有成功,其它的set,get,increase操作没问题。
    2,create和remove一个key的时候,是一个事物操作。但是,在aof文件中看涉及对两个key的操作。和服务负责人确认,是代码逻辑添加的。涉及到的一个key是hash表中客户端要操作的key本身,另一个key是记录此hash表的key数量(ent或com或 bigapp组每组的counter的monitor会共用一个key)
    3,在抓包中看到,报警的ent webruntime机器在执行一个remove key事物操作前,已经被redis watch的key(这个key为此hash表的key数量,watch操作也是在代码中的)被另一台ent webruntime给修改了(因为monitor报警是并发的,故对redis的操作在一段时间内,不一定只有一台机器执行),导致remove或者 create的时候,redis发现被watch的key修改了,故停止执行此事物操作,重试5次没有成功,故导致monitor报警


    解决办法:
    1,适当增大redis命令执行失败后的delay时间和重试次数,这样当事务执行失败后,会在延迟后继续重试执行,一定程度降低失败率
    2,修改counter代码逻辑,可以通过hlen命令获得hash表的长度。可以解决这个问题


最终我们才用第二种方法解决了这个问题。

本文出自 “” 博客,请务必保留此出处http://leejia.blog.51cto.com/4356849/1758172

以上是关于counter服务报警问题分析解决的主要内容,如果未能解决你的问题,请参考以下文章

九阳豆浆机故障分析及排除

平台服务器句柄泄露问题的排查与解决

(转)postfix疯狂外发垃圾邮件之分析与解决

Ambari Server网口带宽占用率很高问题的分析和解决办法

Linux运维21:服务器内存过高跟踪思路

对MySQL报警的一次分析处理小结