Jwebap使用手册.docVIP

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