往事如风
记录工作中的点点滴滴 留住那些淡淡的回忆
posts - 6,  comments - 3,  trackbacks - 0

【 BTrace 说明】 http://kenai.com/projects/btrace
是一个实时监控工具,使用了 java agent 和 jvm attach 技术,可以在不停机的情况下实时监控线上程序的运行情况,另外,对 btrace 脚本(实际上就是 java 程序)做了非常严格的安全限制,安全性很高,对应用程序基本没有影响。在性能方面, cobar 进行过测试,对方法进行调用耗时统计的时候,基本消费在微秒级别,可以说微不足道。

【背景】

在中文站 napoli 上线过程后,发现了一个奇怪的现象,尽管"已知"的 offer 发送端都已经迁移到
napoli 系统中,但是老的 mq 系统仍然有新的 offer 消息进来,因为连接 mq 的服务器非常多,定位消息来源成了一个非常大的问题。这种情况,想到了使用 BTrace 在某一台服务器进行线上监控进而期望发现这个幽灵。

【过程】

首先,我们需要知道两个基本信息:消息类型和来源 ip ,这样才可以定位 offer 消息的来源。

要知道来源 ip ,需要找到服务器端 管理的类,只有在建立 socket 的地方,才可以抓到具体 ip ,经过分析 amq 代码,发现 tcp 连接基本是由下面这个类来服务所有消息的接收的:

public class TcpTransport extends TransportThreadSupport implements Transport, Service, Runnable {

private static final Log LOG = LogFactory.getLog(TcpTransport.class);

private static final ThreadPoolExecutor SOCKET_CLOSE;

protected final URI remoteLocation;

protected final URI localLocation;

protected final WireFormat wireFormat;


protected int connectionTimeout = 30000;

protected int soTimeout;

protected int socketBufferSize = 64 * 1024;

protected int ioBufferSize = 8 * 1024;

protected boolean closeAsync=true;

protected Socket socket;


这个类中包含一个 socket 对象的成员变量,所有我们只要监控 readCommand 方法,这个方法的返回值实际上就是一个 ActivemqObjectMessage 对象,这样就可以在一个方法上加拦截器就可以同时捕获到 ip 和消息对象,两全其美!!!

protected Object readCommand() throws IOException {

return wireFormat.unmarshal(dataIn);

}

因为原有 ESB 消息通道都是一个队列 ESBQueue ,所以无法通过队列名称来确定消息类型,必须通过
ESBTransferObject 对象来取得消息类型: destType , offer 的区间是 1000-1008

public class ESBTransferObject implements Serializable {

private static final long serialVersionUID = -5975115234845303878L;

/**

* 消息体,原则上对象序列化后的XML数据(String) 注意使用XML1.1规范。

*/

private Object content;

/**

* 用户自定义数据

*/

private Object userDefineData;

/**

* 目的消息类型

*/

private int destType = -1;


但是,在服务器端并没有 ESBTransferObject 对象,无法反序列化( BTrace 也不支持反序列化操作),所以没有方法简单取得消息类型信息!!!

OK ,我不反序列化,直接拿二进制 byte[] ,类型信息应该是在固定位置的吧?但是发现这个对象
content 变长字符串定义在类型之前,类型位置不确定了,晕倒啊
不死心,输出二进制数据,柳暗花明啊,原来对象序列化的时候, primitive 的 field 都是紧接着类型信息写入的,所以,类型信息是在固定位置的 ,类型信息始终是 255 , 256 两个字节(实际上是 4 个字节,但是目前我们只占有 2 个) Ok ,编写代码,测试环境运行一下,晕倒,竟然有数组溢出!

使用 BTrace ,把这个数组打印下来(这个需要点技巧, btrace 连 for 都不允许),竟然发现 位置偏移到 205 , 206 位置 ,这个真的不知道什么原因,估计是客户端发送的时候压缩了,简单修改偏移量,测试运行, ok ,所有的消息类型和 ip 的对照表打印出来了。


package com.alibaba.btrace.script;

import static com.sun.btrace.BTraceUtils.*;

import com.sun.btrace.annotations.*;

@BTrace

public class AMQQueue2IP {


@OnMethod(clazz = "org.apache.activemq.transport.tcp.TcpTransport", //需要拦截的类名

method = "readCommand", //需要拦截的方法名

location = @Location(Kind.RETURN)) //拦截位置,方法返回时

public static void onTransportCommandExit(@Self Object transport, @Return Object command) { //捕获调用对象和返回值

String commandName = str(command);

boolean isObjectMessage = (indexOf(commandName, "org.apache.activemq.command.ActiveMQObjectMessage") >= 0);

if (isObjectMessage) {

Object msg = command;

Object content = get(field(getSuperclass(getSuperclass(classOf(msg))), "content", false), msg);//捕获消息内容byte[]

byte[] bs = (byte[]) get(field(classOf(content), "data", false), content);

if (bs.length >= 206) {

int off = getInt(field(classOf(content), "offset", false), content);

int code = (0xff00&bs[205]<<8)+(0xff&bs[206]); //转换205,206字节为消息类型

//println(str(code));

Object socket = get(field(classOf(transport), "socket"), transport);

String address = str(socket); //截取ip地址

int s = indexOf(address, "/");

int e = indexOf(address, ",");

int len = e - s;

String ip = substr(address, s + 1, e);

print(strcat(timestamp(),"---"));

println(strcat(strcat("ip: ", ip), strcat(" queueName: ", str(code))));

}

}

}

}


打印结果:


2/3/10 12:38 PM---ip: 172.22.2.34 queueName: 2001

2/3/10 12:38 PM---ip: 172.22.2.41 queueName: 5001

2/3/10 12:38 PM---ip: 172.22.2.22 queueName: 5001

2/3/10 12:38 PM---ip: 172.22.2.47 queueName: 2001

2/3/10 12:38 PM---ip: 172.22.2.31 queueName: 2001

2/3/10 12:38 PM---ip: 172.22.2.13 queueName: 5001

2/3/10 12:38 PM---ip: 172.22.2.6 queueName: 5001

2/3/10 12:38 PM---ip: 172.22.2.48 queueName: 2001

2/3/10 12:38 PM---ip: 172.22.2.39 queueName: 2001


【补充】

BTrace 是一个强大的工具,但是,在线上检测的时候考虑时效性和安全性,必须有一个经过检验的脚本库才可以安全及时的定位系统问题.

posted on 2010-07-14 19:18 井底青蛙,常望天空 阅读(462) 评论(0)  编辑  收藏 所属分类: java 、tools

<2010年7月>
日一二三四五六
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

常用链接

留言簿

随笔分类

随笔档案

搜索

  •  

最新评论

阅读排行榜

评论排行榜