【
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
井底青蛙,常望天空 阅读(366)
评论(0) 编辑 收藏 所属分类:
java 、
tools