Jwebap使用手册.doc

Jwebap使用手册.docJwebap User Guide
leadyu (yu-lead@)
介绍
Jwebap是一个用于java web application 的profiler工具。它不采用JVMPI提供的特性实现监控,是一个纯粹的JAVA应用,不依赖于OS,JVM,。
它的目的是希望能够安全高效的部署于生产以及测试应用系统,及时地发现应用系统中存在的性能瓶颈,以及为一些动态性很高难于调试和维护的应用系统提供帮助。目前它主要致力于性能分析和优化方面,以后可能往其他监控方面发展(比如业务数据的监控)。因此,组件提供基本的SDK,提供基本的分析功能,不断丰富的分析功能可以通过统一的方式以插件的形式加入Jwebap组件。
出于这些目的,作者心目中理想的监控分析工具应该具备下面几个特性:
高效
组件本身必须具有很高的执行效率,对应用系统的运行带来的负担非常微小。其实就目前来说,一般的profiler工具在一定的组件功能复杂度的情况下,需要处理非常庞大的数据量,做到真正的高效率其实是一个困难度很高的挑战,所以,一方面组件本身要足够健壮和高效,另一方面对于组件可以监控的范围也要可以配置
。(毕竟我们进行性能分析并不一定需要了解应用的全部执行细节)
分析功能丰富
如果只是把庞大的应用系统运行细节暴露出来,已经远远不能满足现有的需要,根据不同视角的分析与统计变得非常必要。并且分析的功能能够不断丰富。(例如对于数据库的监控插件提供topMethod,topSQL之类的分析报表,甚至是动态的图形报表)
跨平台
基于JAVA的组件难道还要考虑跨平台的问题吗?回答是当然需要,起码对于profiler工具来说。目前不少profiler通过jvmpi以及一些本地化接口实现对于JVM内部运行细节的监控。而理想的监控工具应该是纯JAVA的,不依赖JVM和OS,否则组件的生命会变得脆弱,使用的时候也会很麻烦,我希望组件不但可以使用在测试环境,同样无缝的部署与生产应用系统。难道让生产系统应监控工具而改变OS和JVM吗?这明显不大可能。
部署简易
希望是非常的方便,通过对动态类加载,字节码注入等技术的运用对外提供简单的部署方式,我希望就是通过几行的配置文件就能完成部署。
可扩展性
前面提到,组件应该能够提供丰富的分析功能,并且这种功能可以通过插件的方式不断集成于组件之中以满足不同的需要。所以,组件的实现中信息的采集和信息的分析必须是解耦的,一方面组件提供高效稳定的信息采集方式,另一方面组件提供基于插件的框架,能够不断扩展分析功能以满足需要,甚至这些分析功能不仅仅是性能方面,也包括业务数据的监控。
什么是轨迹
在组件的设计中包含一个重要的概念——轨迹。那么什么是轨迹?
轨迹的定义
        在系统中,任何程序的执行都有可能留下轨迹(数据库的调用会留下SQL轨迹,事务的轨迹,http请求会留下访问的轨迹,程序的方法执行也可以留下轨迹)。
        轨迹包含了对性能分析有用的信息(比如上下文的信息,线程堆栈的信息,执行时间的信息等等),轨迹之间存在关系,比如数据库事务的轨迹和SQL的轨迹,http请求和类方法执行的轨迹之间都有一定的关系。在性能分析中,我们可能存在几个关注点,比如数据库,远程调用,方法调用,组件等等,通过这些关注点相关程序留下的轨迹,我们进行性能分析。
轨迹的管理
       轨迹是错综复杂的,零碎地,关系模糊的,所以要真正有助于性能分析,还需要相应的支持。所以,轨迹又需要生命周期管理,和统计管理。
       轨迹的生命周期管理:轨迹创建,运行,销毁,钝化的各个状态。通过分析工具把有问题的轨迹(比如执行时间过长)找到,通过视图暴露出来。
       轨迹的统计:不同关注点的轨迹,存在不同的统计逻辑,通过不同的分析插件,展现给性能分析者。
轨迹的注入
      轨迹不会自己产生,我们也不可能修改系统的代码。而我又不想像其他的一些分析工具一样,通过本地接口获取JVM的状态从而进行统计(那样就得依赖JVM,依赖OS)。而现在有一个不错的办法摆在我们的面前,那就是采用ClassWorking。目前,我已经实现了一个ClassEnhancer以及一个PackageEnhancer,它能够对指定的类和包进行注入。
轨迹的生命周期
Jwebap插件
Jwebap在模型上采用了插件的设计,从而达到对轨迹的收集管理,和分析统计的解耦。模型如下图:
,也可以动态的在RuntimeContext中注册。如下:
Jwebap分为两大部分,Jwebap ponent。
Jwebap ponent的管理,轨迹的收集,生命周期,轨迹的磁盘钝