[转载]LogMinner――一种基于EMF和STAF的日志分析工具

LogMinner――一种基于EMF和STAF的日志分析工具

大型软件在运行过程中会产生大量的各种各样的日志信息，测试人员常常要分析大量的冗长的日志，而这些日志又往往分布在不同位置的 不同平台的主机的不同目录中，使得测试中的日志分析工作繁复、乏味，为了方便测试人员快速分析日志，本文的作者开发了一个基于EMF和STAF技术的日志 分析工具――LogMinner。

1. 概述

分布式异构软件系统的测试人员常常要分析大量的日志，例如安装日志，数据库日志等等，这些日志分布在不同位置的不同操作系统的主机上，测试人员为了 分析这些日志需要奔波于实验室各台机器之间，既便是有远程操作，测试人员也必须掌握多种操作系统，并登录到多台机器进行分析，而且很多日志文件，内容冗 长，使得测试工作显得繁复、乏味. 对于测试人员来说，查看这些日志文件并进行分析将是一个巨大的挑战。

为了实现测试人员快速高效简便的进行日志分析工作，我们开发实现了一个小巧易用的日志分析工具--LogMinner。

使用LogMinner，只需编辑xml格式的配置文件，在配置文件中指定需要分析的日志所在的机器名、路径、文件名的模式以及关键字的模式和属 性，LogMinner即会到指定机器搜索指定目录及其子目录中符合指定文件名模式的的文件，进行日志扫描,搜索符合关键字模式的关键字，并将分析结果信 息输出到指定或默认的html文件中。

LogMinner工具包括了基于EMF的配置文件编辑器（Config File Editor）、基于java和STAF的LogMinner控制台（LogMinner Console）和基于STAF的LogMinner Service三个组件。

本文将对LogMinner的体系结构、设计实现和配置使用进行介绍，并提出进一步的开发展望。

回页首

2. LogMinner

2.1LogMinner的体系结构

LogMinner是基于STAF(Software Testing Automation Framework) 的分布式P2P系统.系统中的所有主机都是STAF Client。其中LogMinner Servvice是定制的Java STAF Service。而LogMinner Console是运行在STAF环境下的Java应用程序, LogMinner Console和LogMinner Servvice之间的通讯是通过STAF实现的request/response 模式的同步通讯。LogMinner Console根据XML格式的配置文件向指定的一组部署了LogMinner Service的主机提出日志分析请求,LogMinner Service响应请求并将分析结果返回给LogMinner Console。系统的部署如下图所示.

图2.1 LogMinner的部署图

STAF是基于Service这种可重用组件设计的开源、支持多平台、多语言的软件自动测试框架。基于STAF实现的LogMinner系统依存与 边缘化设备的主动协作，而非中央服务器，成员之间直接通讯，打破了传统的C/S模式，成员具备客户端和服务器的双重特性。这种分散式的体系结构实现了日志 分析的分布式计算，有效的利用了网络环境中的计算资源。同时无需中心服务器，不但节约了硬件资源，而且无需中转服务的时间资源消耗使得系统具有通讯及时性 好，数据传输速率高的优点。LogMinner基于STAF的实现除了端到端的通讯模式外，面向service概念开发的可重用组件，使得此软件具有良好 的可重用性和可扩展性。

2.2LogMinner的各组件功能描述

1）担任服务器角色的LogMinner Service实现了日志的分析工作。LogMinner Service接收到LogMinner Console的服务请求,对于合法请求,搜索指定目录及其子目录中并对文件名进行指定正则表达式模式匹配,对符合的文件进行符合指定正则表达式的关键字 的搜索.生成结构化的结果消息集合,返回LogMinner Console。

2）担任客户端角色的LogMinner Console只需解析xml格式的配置文件,根据配置文件生成标准的LogMinner Service请求,向各台服务器提交请求,并读取响应数据解析写入指定或默认的结果文件.

3）作为可视化配置文件编辑器的Config File Editor利用了EMF（Eclipse Model Framework）技术，通过可视化的操作生成符合machineset.xsd定义的配置文件的xml schema的xml文档.是生成LogMinner配置文件的一个Eclipse插件工具，配置文件还可由其他任意xml文档编辑器生成和修改， Config File Editor并非LogMinner系统必须。

2.3LogMinner的设计实现

2.3.1Config File Editor是基于EMF的RCP(rich client platform),是由EMF根据自定义的配置文件的XML Schema自动生成Eclipse 插件。作为LogMinner的一个工具插件,它可视化的编辑配置文件,使用者无需对xml文件格式和xml schema定义有所了解即可添加、编辑配置文件中的各个元素。

EMF是一种建模框架，一种为构建基于结构化数据模型的工具、应用自动生成代码的工具。 Config File Editor的具体实现可以根据指定的XML Schema完全由EMF自动生成,并导出成为Eclipse Product，成为独立于Eclipse外运行的Eclipse Application。

EMF使得Config File Editor的实现核心从具体的编程中解放出来,焦点集中在XML Schema的定义上.当XML Schema根据需求的变更发生改变的时候,能够快速高效的重新得到新的Config File Editor。 关于用EMF根据XML Schema自动生成XML Editor，生成Rich Client以及导出成为Eclipse产品的方法可以从本文的参考资料中得到更多的信息。如果想更多的学习了解EMF可以登录Eclipse官方网站了解最新的信息。

2.3.2LogMinner Console是Java Application,需要注意的是,LogMinner Console所在主机也必须安装STAF,否则会出现无法注册到STAF handle错误从而而无法向其他STAF Client提交日志分析请求。

LogMinner Console的具体实现是由配置文件解析器(XML Parser),服务请求器(Service Requester)和服务响应器(Service Responser)3个模块组成。配置文件解析器读取xml格式的配置文件,并进行解析.服务请求器读取配置文件解析器的解析结果并生成标准的STAF 请求,根据STAF请求队列多线程提交日志分析请求.服务响应器读取响应数据,并解析返回编码,如分析成功则将响应信息写入结果文件中，否则提示请求错 误，输出STAF错误状态码和提示信息。

LogMinner Console实现的UML类图如下:

其中配置文件解析器采用SAX API，其实现是由包logminner.machineparser中的MachineSetParse.java实现的。实现步骤如下：

// 建立SAX 2解析器．．． XMLReader xr = XMLReaderFactory.createXMLReader(); // 安装ContentHandler．．． xr.setContentHandler(ms); // 解析文件．．． xr.parse(new InputSource(new FileReader(xmlFileOfMachineSet))); // 取得解析对象 maset = ms.getMachineSet();

其中ms是通过MachineSet ms = new MachineSet();建立的MachineSet的实例。而XML文档的具体解析既是通过 logminner.machineparser.machineElements包中的MachineSet.java实现了将XML文档中的 elements封装成自定义的java objects。MachineSet.java是通过继承org.xml.sax.helpers.DefaultHandler，重载了public void startElement(String namespaceURI, String localName,String qName, Attributes attr)、public void endElement(String namespaceURI, String localName, String qName)、public void characters(char[] ch, int start, int length)三个方法，将XML文档中的元素及其属性悉数取出，并封装为自定义的java对象。

需要注意的是，sun的jdk中缺少了Xerces的包，需要单独下载加入到运行环境中才能运行LogMinner Console，而IBM的jdk不存在此bug，因此建议LogMinner用户使用IBM的jdk。

服务请求器是由实现Runable接口,重载run方法实现，线程执行过程中通过注册到staf的handle的方法submint2提交请求。 STAFResult ss=handle.submit2(tmp[1],tmp[2],tmp[3]+" "+tmp[4])响应结果以STAFResult类型返回。由responser解析，解析函数为

public static List unmarshallResult(STAFResult result){ STAFMarshallingContext mc = STAFMarshallingContext.unmarshall(result.result); List resultList=(List) mc.getRootObject(); return resultList; }

2.3.3LogMinner Service是部署在需要进行日志分析的各台STAF Client上的定制的Java STAF Service。是通过实现STAFServiceInterfaceLevel30接口而实现日志分析服务的。

其UML类图如下：

LogMinner Service是通过类LogMinnerService实现的。该类实现了STAFServiceInterfaceLevel30，通过实现构造函数 public LogMinnerService()、初始化函数public STAFResult init(STAFServiceInterfaceLevel30.InitInfo info)、接收请求函数public STAFResult acceptRequest(STAFServiceInterfaceLevel30.RequestInfo info)和终结函数 public STAFResult term()完成了构造STAF Service的四个阶段：construction phase、initialization phase、accepting request phase和termination phase。具体逻辑的实现的关键在于accepting request phase，在此过程中通过函数public STAFResult handleMine(STAFServiceInterfaceLevel30.RequestInfo info)实现了该service如何响应STAF请求，并根据在initialization phase定义的STAFResult的数据结构封装响应结果为自定义的数据结构返回给请求客户端。其具体活动流程在2.4中的step4有具体的描述。

关于如何开发一个Java STAF Service具体可以参考STAF文档：STAF Service Developer's Guide，而STAF提供的Java API可以参照Java User's Guide for STAF V3。 LogMinner Service通过改写STAF Client的配置文件注册到STAF Client，它对于多平台的支持和请求线程池的管理完全继承了STAF的特性,开发的核心也完全专注在STAF请求的处理逻辑上.基于STAF Service的LogMinner Server具有良好的可重用性、可扩展性和跨平台性。

2.4系统工作流程

图2.2 系统工作流程图

LogMinner的系统工作流程如上图所示，其具体步骤描述如下：

Step1 由配置文件编辑器（Config File Editor）可视化生成日志分析的配置文件(当然,可以使用任何可用的xml文档编辑器编辑,只需xml文档符合系统定义的xml schema定义文档--machineset.xsd的定义).

Step2 配置文件解析器读取配置文件,并解析XML格式的配置文件中的各元素,将其封装成java 对象.

Step3 服务请求器根据配置文件解析器解析出的java对象生成服务请求队列,向配置文件中指定的各服务器多线程提交日志分析请求.

Step4 LogMinner Service接受请求,并对合法请求执行日志分析任务,返回分析结果.

其中，LogMinner Servie作为STAF Service符合其一般的服务响应流程,具体步骤为(1)接收请求(2)对请求进行信任度认证(3)合法的请求进一步解析请求命令,否则返回错误码 (4)对合法的请求串执行请求,否则返回错误码,其UML活动图如图2.3所示:

2.3LogMinner Service的活动图


2.4 LogMinner Servie处理请求的业务逻辑活动图

LogMinner Service处理请求的详细流程为:(1)搜索符合请求的日志文件(2)对日志文件进行信息搜索(3)包装结果信息为特定的数据结构的STAFResult对象(4)返回STAFResult,其活动图如图2.4所示.

Step5 服务响应器读取各服务器返回的响应结果的响应码,如分析成功,解析响应数据并按照一定的格式写入结果文件,否则返回分析错误提示信息.

回页首

3. LogMinner的特点

3.1输入输出文件格式简单通用,日志分析支持正则表达式匹配

LogMinner的核心输入为xml格式的配置文件,配置文件元素包括主机,配置文件和关键字.每台主机必须指定主机名或ip地址,一台主机元素 可以指定多个日志文件元素,每个日志文件元素必须指定路径和文件名属性,文件名属性可以使用正则表达式,文件的搜索支持正则表达式匹配,每个日志文件元素 可以指定多个关键字元素,关键字必须指定shouldExist属性,我们认为shouldExist为true的关键字必须在日志中出现,而 shouldExist为false的关键字都没有出现,该日志文件中没有错误信息,否则有丢失关键字或发现错误的错误信息,关键字搜索也支持正则表达式 匹配.

输出为html格式的结果文件.结果信息表格包括日志所在主机,日志文件的绝对路径(包含机器名),信息类型,信息的具体内容,对于丢失关键字的错 误信息,具体内容为丢失的关键字列表,而对于发现错误的错误信息,具体内容是：出现shouldExist为false的关键字的行号#关键字#该行的内 容.

图3.1 LogMinner的输入输出

输入输出文件格式分别选择为xml文档和html文档,其优点是不言而喻的.特别是输入的配置文件采用xml文档,还为利用EMF自动生成config file editor提供了可能.

日志文件搜索和日志内容分析的灵活性,精确性依赖于正则表达式的强大功能。LogMinner对于正则表达式匹配的支持,使得LogMinner工具非常小巧,但是可以有非常灵活适应性和精确的搜索结果。当然这需要使用者对于正则表达式有着良好的驾驭能力。

3.2基于EMF生成的Config File Editor具有良好的可扩展性和灵活性

Config File Editor除了是可视化工具具有良好的易用性之外,对于开发者和维护者来说基于EMF的Config File Editor具有良好的可扩展性和灵活性.EMF的最主要的成就就是把实现的焦点由具体实现细节转移至应用所依赖的模型,并能自动生成代码.因此配置文件 所需依从的xml schema一经定义,EMF可以迅速的自动生成Config File Editor。

3.3基于STAF的分散式体系结构具有较高的性能，良好的重用性、跨平台性

如在2.1中所述基于STAF实现的LogMinner系统分布式的P2P体系结构实现了日志分析的分布式计算，有效的利用了网络环境中的计算资 源。同时无需中心服务器，不但节约了硬件资源，而且无需中转服务的时间资源消耗使得系统具有通讯及时性好，数据传输速率高的优点。同时面向service 概念开发的LogMinner Service作为可重用组件，使得此软件具有良好的可重用性和可扩展性。而基于STAF的Client支持多平台多语言，屏蔽了底层通讯，将开发维护人 员从底层实现解放到业务逻辑中来。

3.4多线程的LogMinner Console兼顾了系统性能和容错

多线程提交请求和解析响应数据,使得LogMinner更加快速高效。客户端多线程提交请求和解析读取响应数据,提供了较好的分析效率.而日志分析 的过程是在各日志文件所在STAF Client进行分布式计算的,相对于将日志文件读取到客户端进行分析,既分散了计算任务,降低了客户端的资源消耗,也降低了网络流量。

而在线程的粒度划分上，LogMinner Console为需要日志分析的每台主机的每个目录生成一条LogMinner STAF请求，进行多线程提交。日志分析中最常出现的异常可能是由于配置文件中指定目录不存在生产生，按照如上粒度划分线程，使得当某个目录不存在时不影 响其他目录的日志分析。

回页首

4. LogMinner的部署和使用

4.1Config File Editor

1）通过file->new->machineset model菜单新建一个配置文件模型，此时会跳出new对话框。

2）通过file指定配置文件的路径和文件名，通过model object选择要新建的模型对象――machineset，点击finish按钮。

3）右击根类型，通过new child->*** type添加新的model object。

4）在右侧properties窗口中的value表格中输入值，为各类型的property指定值。

4.2将LogMinner Service部署至STAF Client

（1）在staf的安装目录下新建目录services

（2）将 LogMinnerService.jar拷贝services目录下

（3）在staf安装目录下inSTAF.Cfg中加入一行SERVICE LogMinner LIBRARY JSTAF EXECUTE C:STAFservicesLogMinnerService.jar（c:STAF请根据自己的STAF的安装目录作相应改动）

（4）为LogMinner客户端添加trust level，语法如下：TRUST LEVEL < DEFAULT | MACHINE [MACHINE ]... |USER [USER ]... > e.g. TRUST LEVEL 5 MACHINE 9.3.224.16

（5）重启staf

4.3运行LogMinner Console

（1）启动STAF

（2）启动命令行，在LogMinner.jar的所在目录下运行 java -jar LogMinner.jar param1 param2 param3。其中param1为配置文件的完整目录和文件名，param2为结果文件存储的目录，param3为结果文件的文件名。例如：java -jar LogMinner.jar d:workspaceLogMinner1.machineset。命令行运行如图：

注：如果不指定结果文件的目录和文件名，默认的目录为c:logminner esults,默认的结果文件名为result_< time>.htm(其中time是System.currentTimeMillis())，使用默认结构文件路径时如果c: logminner esults不存在系统会自动建立该路径。如果原文件已经存在，结果内容会在原文件后添加，不会清空原有内容。

回页首

5. 进一步的工作和展望

目前，LogMinner已经实现了日志搜索的功能,我们之所以为这个日志分析工具起名为LogMinner是希望实现它能最终实现日志数据挖掘， 从而为测试人员分析日志提供知识支持。因为测试人员在日志分析的过程中会积累和总结出很多所测试软件在安装、运行中出现的异常信息和异常发生原因的映射关 系的经验和规则,根据日志搜索出的异常信息和测试人员分析出的异常错误的原因,通过统计其相关联的支持度和置信度等数据挖掘分析,就能得到异常信息和异常 发生原因的关联规则。根据挖掘出的关联规则和开发人员提供的错误信息的reference搭建日志分析的知识库,就可以为日志分析的自动化提供良好的决策 支持。因此LogMinner可以向着数据挖掘的方向进一步发展完善。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/374079/viewspace-130704/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/374079/viewspace-130704/