【IT168 技术】我最初开发EurekaJ是在2008年。那时，我正在寻找一种具有我需要功能的开源剖析器，但没有找到。于是，我开始开发自己的工具。开发过程中，我涉猎了大量不同的技术并参考了许多架构模型，直到EurekaJ第一个版本发布。你可以从项目网站上了解更多的EurekaJ历史，查看源代码或下载并试着安装自己的版本。

　　EurekaJ提供了两个主要应用：

　　一个基于java的管理器程序，可以接收传入的统计数据并一致地以可视化视图展现出来

　　一个解析BTrace输出的代理程序，将其转化为JSON格式并输入到EurekaJ管理程序的REST接口

　　EurekaJ接受两种类型的输入数据格式。EurekaJ代理期望BTrace脚本的输出被格式化为逗号分隔的文件(这点在BTrace中可很容易做到)，而EurekaJ管理程序期望它的输入符合它的JSON REST接口格式。这意味着你能通过代理程序或直接经由REST接口来传递度量数据。

　　借助EurekaJ管理程序，我们可以在一张图上分组显示多个统计数据、可以定义阈值和给接收者发出警报。我们还可以方便的查看收集到的实时数据或历史数据。

　　所有收集到的数据排序成一种逻辑树结构，其结构由BTrace脚本作者指定。我建议BTrace脚本的作者对相关统计数据分组，这样，当它们显示在EurekaJ中时会更容易理解和观察。例如，我个人喜欢对统计数据进行如下的逻辑分组：

　　图10：EurekaJ演示程序的统计分组示例

　　图例

　　一种需要采集的重要信息是程序运行时的平均系统负载。要是你正面对一个运行缓慢的程序，那么缺陷可能并不在程序自身，而是隐藏到应用驻留的主机某处。我曾经在调试运行缓慢的应用时偶尔发现，真正的根源是病毒扫描程序。如果不进行测量分析，这种事情会很难被发现。考虑到这一点，我们需要能够在一张图中显示系统平均负载和进程加载后产生的负载。下图显示了一个运行EurekaJ 演示程序的Amazon EC2虚拟服务器的2小时平均负载(该应用登录的用户名和密码都是‘user’)。

　　图11：显示平均系统负载的EurekaJ图表

　　图中，黄色和红色的线条表示警戒阈值。一旦图形超过黄线的次数超过预设的最小警戒次数时，则测量结果到达“警告”状态。类似，若突破红线，测量结果就到达“危险”或“错误”状态。每当发生状态转换，EurekaJ都会发送一封邮件给之前注册的收件人。

　　在上面的情形中，好像有周期性的事件每20分钟发生一次，从平均负载图上显示的波峰可以看到这一点。首先你要确定的是这个波峰确实由你的程序产生，而非其他原因。我们也可以通过测量进程的CPU负载来确认这点。在EurekaJ树菜单中，选择两个测量点后，两个图表结果会一起快速成像显示出来，其中一个位于另一个下面。

　　图12：同时显示多个图表

　　在上面的例子中，我们清楚地看到进程CUP占用和系统负载存在必然的联系。

　　许多应用需要在程序无响应或不可用时及时发出警告。下图是一个Confluence(Atlassian的企业级Wiki软件)的例子。这个例子中，程序内存占用快速上升，直到产生程序内存溢出。这时，Confluence无法处理接收到的请求，同时日志文件记录了各种奇怪的错误。

　　你可能希望当程序运行导致内存溢出时，程序能立刻抛出一个OOME(内存溢出错误)，然而，事实上JVM不会抛出OOME直到它发觉垃圾回收过于缓慢。结果，程序没有完全崩溃，又过了2小时，Java仍然没有抛出OutOfMemoryError，甚至两小时后程序依然在“运行”(意味着JVM进程仍然在运行)。显然，这时任何进程监测工具都不能发现程序已经“停止”。

　　图13：EurekaJ堆图显示内存溢出错误的一种可能情形

　　注意最后几个小时的执行情况，图表揭示了下面的度量指标。

　　图14：前面图表放大后的效果

　　EurekaJ使我们可以设置程序的堆内存警告，个人建议最好如此。若程序持续占用堆内存超过95%-98%(取决于堆的大小)，几乎可以肯定，程序存在内存问题，要么用–Xmx参数为程序分配更多的堆，要么优化程序使其使用更少内存。同时，EurekaJ未来版本计划增加统计数据不足的警报。

　　最后的图表示例展示了一个包含4个不同程序内存使用的图表组。这种类型的图表组可方便用来比较一个程序不同部分的、或甚至不同程序之间、服务器之间的数据。下图的这4个程序有不同的内存需求和内存占用模式。

　　如下图示，不同程序有不同的内存曲线。这些曲线非常依赖一些实际情况，比如使用的架构、缓存数量、用户数、程序负载等。我希望通过下图说明你需要掌握程序在正常和高负载下执行情况的重要性，因为这将直接关系到如何定义报警阈值。

　　图15：EurekaJ图组会将图像彼此叠加在一起

　　注意性能干扰 – 让非热点区不受影响!

　　你使用的每一种测量方法似乎都会引起系统性能干扰。一些数据的测量可以被认为“无干扰”(或“忽略不计”)，然而另外一些数据的测量可称得上代价昂贵。非常重要的一点是，要知道你需要BTrace测量什么。因此，你要将这种分析工具对程序的性能干扰减少到最小。关于这点，请参考下面的3条原则：

　　基于“采样”的度量通常可被认为“无影响”。采样CPU负载、进程CPU负载、内存使用和每5-10秒的线程计数，其带来的额外一两个毫秒的影响可被忽略。在我看来，你应该经常收集这类统计数据，它们对你来说不会有什么损耗。

　　对长时间运行的任务的测量也可被认为“无影响”。通常，它仅会对每个被测量方法带来1700-2500纳秒的影响。如果你正测量这些对象的执行时间：SQL查询、网络流量、硬盘读写或一个预期范围在40毫秒(磁盘存取)到1秒(Servlet处理)之间的Servlet处理过程，那么对这些对象每个增加额外的2500纳秒左右的时间也是可接受的。

　　绝对不要对循环内执行的方法进行测量

　　寻找程序热点区的一个通用规则是不要影响非热点区域。例如，考虑下面的类：

　　图16：需要测量的简单的数据访问接口类

　　第5行的SQL执行时间可能使readStatFromDatabase方法可能成为一个热点。当查询返回相当多的数据行时，它无疑会成为一个热点，这对13行(程序和数据库服务器之间的网络流量)和14-16行(结果集中每行所需处理)会造成负面影响。如果从数据库返回结果时间过长，该方法也会成为一个热点(在13行)。

　　方法buildNewStat就其本身来说似乎绝不会成为一个热点。即使被多次执行，每次调用都会在几纳秒内完成。另一方面，若给每次调用增加了2500纳秒的测量采集干扰，则无论SQL何时被执行，都势必会让该方法看起来像个热点。因此，我们要避免测量它。

　　图17：显示上面类哪些部分可以被测量，哪些需要避免

　　建立完整的运行分析

　　使用EurekaJ建立一个完整的运行分析，需要以下几个主要部分：

　　准备需要监测/操纵的程序

　　BTrace - java代理

　　告知BTrace如何测量的BTrace脚本

　　存储BTrace输出的文件系统

　　将BTrace输出传输到EurekaJ管理器的EurekaJ代理

　　安装好的EurekaJ管理器(本地安装或可通过互联网访问的远程安装)

　　图18：使用本文所描述工具对程序进行运行分析的概览图

　　关于这些产品的完整安装手册，请访问EurekaJ项目网站。

　　总结

　　这篇文章给我们介绍了一些用于程序运行分析的开源工具，它们不仅能帮我们完成对运行中JVM的深度分析，而且可以帮助我们对开发、测试和程序部署进行多方位的持续监测。

　　希望你已经开始了解不断收集度量信息的好处和超过阈值后及时报警能力的重要性。