小站重新装修,欢迎到访。
标签 #备忘

[备忘]记一次使用Btrace排查线上问题

本文仅供博主备忘。

背景

我目前负责我司的分布式消息队列产品,某日,有业务方上报可能发生少量数据丢失,事态紧急,赶紧排查!

验证问题

观察监控曲线,发现15分钟动态监控报表的生产和消费确实有数量上的差异,丢失的不算少。这里要说明一下,一般来说如果生产消费是持续不断的,是很难通过此类报表判断出数据丢失,因为消费是有延迟的,统计会在时间维度上产生错位,幸运的是此业务方的消息是定时发送的,大概是一两分钟一批,消费速度也很快,所以统计曲线看起来就像是一条条抛物线,丢不丢一算便知。

检查各计数器和log

相关计数器正常,log也未发现任何疑点。

思考

服务正常,但消息确实有少量丢失,而且受影响的topic似乎也极少,这个仅从表面看想必是很难看出原因了。考虑到消息的消费先是由LeaderServer分配ID段的,所以我决定祭上神器Btrace,线上抓取分配的ID和ACK表对比,力求找出蛛丝马迹。

动手

脚本如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@BTrace
public class GetMessageIDGreaterThan {
@OnMethod(clazz = "com.yihaodian.architecture.jumper.common.inner.dao.impl.mongodb.MessageDAOImpl", method = "getMessageIDGreaterThan", location = @Location(Kind.RETURN))
public static void traceExecute(@ProbeClassName String name,@ProbeMethodName String method,String topicName, Long messageId,int size, int index,@Return Long ret){
if(BTraceUtils.compare(topicName,"dmp_user_creative_product")){
BTraceUtils.print(strcat("params","=>"));
BTraceUtils.print(strcat(topicName,","));
BTraceUtils.print(strcat(str(messageId),","));
BTraceUtils.print(strcat(str(size),","));
BTraceUtils.print(strcat(str(index),","));
BTraceUtils.println(strcat("result=>", str(ret)));
}
}
}

其中,messageId是已经分配的最大ID,返回值ret是此次分配的最大ID。理论上,一系列输出应该是连续的。也即上一行的ret和此行的messageId是一致的。事实确实如此。

继续比对ACK表。解析一系列输出,写了个脚本输出了一堆mongo的查询语句,目的是查出哪些段的ID丢失了ack。经对比,一个奇怪的现象出现了,所有长度为264的ID段都丢失了。经检查,此数值乃JVM启动参数之一,即-Dglobal.block.queue.fetchsize,用来配置ConsumerServer批量获取消息的大小。为何这么巧合,丢失的都是长度为264的ID段呢?

表面淡定内心纠结地查了一通,发现了疑点,不是每台机器的-Dglobal.block.queue.fetchsize都一致,但最大的是就是264。这个比较意外,但想了想应该也不会出啥大问题啊。

更加糊涂了。

翻查代码,终于查找到元凶。如下,

1
2
3
4
if (messageIDList != null && messageIDList.size() <= fetchSize) {
//logic goes here
return messageIDList;
}

其中,

1
private final int fetchSize = Integer.parseInt(System.getProperty("global.block.queue.fetchsize", "200"));

问题找出来了,LeaderServer的配置是264,所以ConsumerServer拿到的ID段长度也是264,但本机的fetchSize比264要小,所以被直接忽略了。

那么问题是怎么产生的呢?导致问题的代码看似多余,其实也是一种自我保护。所以问题还是要归咎于配置不一致,引起逻辑上的混乱。那么为什么配置会不一致呢,原来前阵子SA为了方便使用puppet部署,将各种配置都参数化了,效果就是代码部署时,通过对硬件的计算,修改各种参数取值,这样就降低了运维的复杂度。虽然申请了一批硬件配置相同的机器,但是其“软配置”却各不相同,导致有些关键参数未能完全一致,而我又未能察觉隐患,故导致此问题。马上修改配置,重启,解决。

反思

吃一堑长一智,这件事情的教训就是,类似问题很难保证完全避免,但在研发阶段就要多思考会导致问题的场景,及时写注释或记录到文档里。毕竟代码逻辑久了谁都会忘,但注释放那就会时刻提醒你不要犯错。当初如果在脚本的相关参数上备注:必须保证每台机器的此配置取值一致,问题也就不会发生了。

另外一点就是Btrace确实是排查问题之神器,让人无路之时转而柳暗花明。

1

博主是一个不是很聪明的码农。完美主义者,强迫症中期。这里会记录一些回忆和点滴,以博为镜。

武器库:

该博客使用基于  Hexo  的  simpleblock  主题。博客内容使用  CC BY-NC-SA 3.0  授权发布。最后生成于 2017-02-20.