CN105278996A - 一种日志采集方法、装置及日志服务系统 - Google Patents

Abstract

本发明提供了一种日志采集方法、装置及日志服务系统，涉及网络技术领域，解决了现有日志采集过程中，需引入第三方组件导致引用冲突的问题。本发明实施例提供的方法包括：加载java应用程序的类文件；判断所述类文件是否在日志采集的监控范围内；若确定所述类文件在日志采集的监控范围内，则获取所述类文件的所有类方法，确定所述所有类方法中是否存在需进行日志采集的类方法；若所述所有类方法中存在需进行日志采集的方法，则在需进行日志采集的类方法中植入日志采集代码，形成新的类文件；加载所述新的类文件进行日志采集。

Description

一种日志采集方法、装置及日志服务系统

技术领域

本发明涉及网络技术领域，尤其涉及一种日志采集方法、装置及日志服务系统。

背景技术

应用系统中，日志是不可缺少的重要组成部分，所有Java应用程序的出错信息等都应该能在日志文件中查找到，目前，绝大多数Java应用程序在运行过程中都会采用日志框架来生成各种日志文件。

但是，现有日志框架都采用jar集成的方式包含在第三方组件(如mina或netty)中，这导致Java应用程序在运行过程需要先强制性地引入第三方组件，然后在应用程序中配置相应的参数，调用第三方组件提供的应用程序编程接口(ApplicationProgrammingInterface，API)函数，通过查找第三方组件中的日志框架来生成日志文件，由于应用程序和日志框架时均需要引入第三方组件，比如双方都引用netty或mina等第三方组件时，因各自引用的版本不一致，易导致引用冲突。

发明内容

本发明的主要目的，在于提供一种日志采集方法、装置及日志服务系统，解决了现有日志采集过程中，需引入第三方组件导致引用冲突的问题。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，本发明实施例提供一种日志采集方法，包括：

加载java应用程序的类文件；

判断所述类文件是否在日志采集的监控范围内；

若确定所述类文件在日志采集的监控范围内，则获取所述类文件的所有类方法，确定所述所有类方法中是否存在需进行日志采集的类方法；

若所述所有类方法中存在需进行日志采集的方法，则在需进行日志采集的类方法中植入日志采集代码，形成新的类文件；

加载所述新的类文件进行日志采集。

第二方面，本发明实施例提供一种日志采集装置，包括：

类加载器：用于加载java应用程序的类文件；

判断单元：用于判断所述类文件是否在日志采集的监控范围内；

解析单元：用于当所述判断单元确定所述类文件在日志采集的监控范围内时，获取所述类文件的所有类方法，确定所述所有类方法中是否存在需进行日志采集的类方法；

代码植入单元：用于当所述解析单元确定所述所有类方法中存在需进行日志采集的方法时，在需进行日志采集的类方法中植入日志采集代码，形成新的类文件；

所述类加载单元，还用于加载所述新的类文件进行日志采集。

第三方面，本发明实施例还提供一种日志服务系统，所述日志服务系统包括：如第二方面所述的日志采集装置、Kafka集群、以及日志应用装置。

所述日志采集装置，用于通过异步传输的方式将采集到的日志信息发送至Kafka集群中的消息队列中；

所述日志应用装置，用于读取所述Kafka集群消息队列中的日志消息进行消费。

由上可知，本发明实施例提供一种日志采集方法、装置及日志服务系统，所述日志采集方法由日志采集装置中的JVM执行，JVM先加载java应用程序的类文件，当确定所述类文件在日志采集的监控范围内，且所述类文件的所有类方法存在需进行日志采集的类方法时，将日志采集代码植入类方法中，形成新的类文件，重新加载新的类文件进行日志采集。在本发明的日志采集过程中，不需要事先引进第三组件，而是在需要进行日志采集的地方才加载日志采集代码，实现零耦合的日志采集文件的动态加载，避免了现有日志采集过程中，需引入第三方组件导致引用冲突的问题。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的日志服务系统原理框图；

图2为本发明实施例提供的日志采集装置的结构图；

图3为本发明实施例提供的日志采集方法的流程图；

图4为本发明实施例提供的日志采集装置10的结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

首先，为了便于理解本发明所述的技术方案，对本发明中的一些重要名词进行详细解释：

宿主机(Host)：作为管理层，用以完成硬件资源的管理、分配；为Java虚拟机呈现虚拟硬件平台；实现虚拟机的调度和隔离。其中，Host可能是虚拟机监控器(VMM)；虚拟硬件平台对其上运行的各个Java虚拟机提供各种硬件资源，如提供虚拟处理器(如VCPU)、虚拟内存、虚拟磁盘等等。其中，该虚拟磁盘可对应Host的一个文件或者一个逻辑块设备。Java虚拟机运行在Host为其准备的虚拟硬件平台上，Host上运行一个或多个Java虚拟机。

Java虚拟机(JavaVirtualMachine，JVM)：可运行java代码的虚拟计算机，只要根据JVM规格描述将解释器移植到特定的计算机上，就能保证经过编译的任何java代码能够在该系统上运行，JVM拥有自己完善的硬件架构，如处理器、堆栈、寄存器等，并且还具有相应的指令系统。

类(class)文件：java类文件，用于存储java程序运行时代码指令集的文件，可通过类装载器加载到JVM上。

类装载器：java类装载器，由于java程序包含很多的类文件，并且这些类文件不像静态的C程序一次性装载入JVM内存，它们只有在需要的时候才装载，java类装载器先从类文件中获取不依赖平台的字节码，然后将它们装载到JVM内存空间运行。

jar文件：包含多个java类文件和相关资源的同一存储库，是java程序组件分发的一种通用形式。

java虚拟机工具接口：(JavaVirtualMachineToolkitInterface，JVMTI)，是监控虚拟机运行状态的接口，是JDK提供的一套用于开发JVM监控、问题定位与性能调优的通用编程接口(ApplicationProgrammingInterface，API)。通过JVMTI，我们可以开发各式各样的JVMTIAgent。这个Agent的表现形式是一个以c/c++语言编写的动态共享库(dynamicmodule)，在java启动或运行时，可动态加载dynamicmodule到Java进程内，然后触发JVM源生线程AttachListener来执行这个dynamicmodule的回调函数。在函数体内，你可以获取各种各样的JVM级信息，注册感兴趣的JVM事件，甚至控制JVM的行为。

需要理解的是，上述名词仅是本领域技术人员为了描述方便常用的命名，并不代表或暗示所指的系统或元件必须有此命名，因此不能理解为对本发明的限制。

通常情况下，一个完整的日志服务过程可以包括两大部分：日志生产和日志消费，其中，日志生产是指：通过对应用程序的日志采集生成相应的日志信息(如运行栈过程信息、程序异常信息等等)；日志消费是指：将生成的日志消息存储到日志库或大数据库中供用户查询或进行其他应用。例如，图1为本发明实施例提供的日志服务系统原理框图，如图1所示，所述日志服务系统可以包括：日志采集装置，用于对应用程序进行日志采集；Kafka集群，作为存储区域，对日志采集装置生产出的日志信息进行存储；日志应用装置，用于读取Kafka集群中存储的日志信息，进行后期消费(如存储到日志库或大数据中)。

其中，为了区别于背景技术中提到的现有日志采集方法，本发明实施例重点对图1所述的日志采集装置以及该装置执行的日志采集方法进行详细说明。所述日志采集装置可以为能够提供日志采集功能的任一物理主机，如图2所示，为本发明实施例提供的日志采集装置10的结构图，从图2中可以看出，该装置10可以包括：硬件层、运行在所述硬件层之上的宿主机(Host)、以及运行在所述Host之上的至少一个Java虚拟机JVM101；所述硬件层可以包括通信接口、处理器、内存以及用于实现这些装置之间的连接和相互通信至少一个通信总线(为便于表示，图2中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线)。其中，通信总线可以是工业标准体系结构(IndustryStandardArchitecture，简称为ISA)总线、外部设备互连(PeripheralComponent，简称为PCI)总线或扩展工业标准体系结构(ExtendedIndustryStandardArchitecture，简称为EISA)总线等。内存可以包括：随机存取存储器，存储有待运行的应用程序，可向处理器提供指令和应用程序。处理器可以是一个中央处理器(CentralProcessingUnit，简称为CPU)，或者是特定集成电路(ApplicationSpecificIntegratedCircuit，简称为ASIC)，或者是被配置成实施本发明实施例的一个或多个集成电路。

一方面，在本发明实施例中，所述日志采集方法可以由图2所示的日志采集装置10中的任一Java虚拟机JVM101执行，即本发明提供的日志采集方法在日志采集装置的java虚拟机上执行，如图3所示，所述日志采集方法可以包括：

步骤101：加载java应用程序的类文件。

其中，java应用程序的类文件存储在日志采集装置的硬件层内存中，即硬件存储器中。

优选的，JVM可以通过JVM内部的类加载器，从日志采集装置的硬件层内存的磁盘目录或Jar包中将java应用程序的类文件加载到JVM的内存中。

步骤102：判断所述类文件是否在日志采集的监控范围内，如果是，则执行步骤103；否则表示所述类文件不需要进行日志采集，结束。

优选的，JVM可以根据所述类文件的属性信息、以及预设的待进行日志采集的类文件的属性信息的集合，判断所述类文件是否在日志采集的监控范围内；例如：

JVM可查询预设的待进行日志采集的类文件的属性信息的集合，若所述类文件的属性信息包含在所述集合中，则表示所述类文件为需要进行日志采集的文件，在日志采集的监控范围内；若所述类文件的属性信息未包含在所述集合中，则表示所述类文件不需要进行日志采集，不在日志采集的监控范围内。

其中，所述属性信息可以包含：类文件所在jar包的包名、和/或类文件的存储路径。

预设的待进行日志采集的类文件的属性信息的集合可以由开发人员根据需要配置在JVM上，如：预设的属性信息的集合包括：com.asiainfo、com.ai两个路径信息，此时，若所述类文件的路径信息为com.asiainfo，则确定所述类文件在日志采集的监控范围内。

步骤103：获取所述类文件的所有类方法，确定所述所有类方法中是否存在需进行日志采集的类方法，若存在，则执行步骤104，否则，结束。

优选的，JVM可以将所述类文件解析成带有一定数据结构的信息，从所述信息中获取所有类方法；需要说明的是，JVM可以采用现有技术对类文件进行解析，在此不再赘述。

示例性的，JVM可以从类方法对应的指令代码中查找是否包含与日志采集相关的指令代码，若包含，则确定所述类方法为需进行日志采集的类方法；若不包含，则确定所述类方法不是需进行日志采集的类方法；同理，针对于所有类方法均可以采用该方式确定是否为需要进行日志采集的类方法，在此不再详细赘述。其中，与日志采集相关的指令代码可以为包含Log代码在内的任意指令。

例如，若类文件解析后包含的类方法对应的指令代码如下：

PublicvoiddoSendLog(Stringservice，StringlogType，objectlogObj){

//业务代码

send(service，logType，logObj)；

}

其中，指令代码“doSendLog”表示发送日志，从而可知该类方法为需进行日志采集的类方法，需要在该类方法汇中植入日志采集代码。

步骤104：在需进行日志采集的类方法中植入日志采集代码，形成新的类文件。

目前，在实际应用中主要支持4大类的日志采集，如：

1、error：表示收集指定目录范围发生的异常信息，默认管理编码为：h01；

2、process：表示收集指定目录运行栈过程信息，默认管理编码为：h02；

3、logger：收集第三方日志输出信息，目录支持log4j、logback，默认管理编码为：h03；

4、interceptParam：收集指定方法的入参信息，默认管理编码为：h04；

所以，本发明实施例中，为了实现上述任一种或多种的日志采集，用户可以根据需要预先配置日志采集类型，然后当存在需要进行日志采集的类方法时，产生符合预先配置的日志采集类型的代码，将产生的代码植入所述类方法中，形成新的类文件；例如，若预先设置的配置参数为：

hlog.base.path.con.asiainfo＝error.process，则表示处于con.asiainfo路径下的类文件，在进行日志采集时，需要实现第1类error和第2类process的日志采集；根据该配置hlog.base.path.con.asiainfo＝error.process，可以在步骤103所示的类方法中可以植入如下的日志采集代码：

PublicvoiddoSendLog(Stringservice，StringlogType，objectlogObj){

Stringvar4＝RuntimeContext.logId()；

Stringvar5＝RuntimeContext.buildLogPId(var4)；

Stringvar6＝“com.asiainfo.test.DefaultLogSender”；

Stringvar7＝“doSendLog”；

ParamObjsvar8＝null；

Var8＝newParamObjs(3)；

Var8.addParam(0，var1)；

Var8.addParamName(0，“service”)；

Var8.addParam(1，var2)；

Var8.addParamName(1，“logType”)；

Var8.addParam(2，var3)；

Var8.addParamName(2，“logObj”)；

RuntimeContext.writeInterceptParam2(“$service”，var4,var5,var6,var7,var8)

//业务代码

send(service，logType，logObj)；

}

步骤105：加载所述新的类文件进行日志采集。

优选的，JVM可以将新的类文件进行编译，形成JVM可识别的二进制代码，执行该二进制代码实现日志信息的采集。

进一步的，为了避免在需要进行日志采集的java应用程序上写入配置参数，本发明实施例，如图2所示，JVM中还可以设置JVMTI，并根据JVMTI生成JVMTI代理(Agent)，然后，将步骤102-104的过程封装在一个函数内，由JVMTI代理(Agent)在监测到应用模块中需要进行日志采集的类文件被加载时，通过回调函数调用该函数，执行上述日志采集过程中的步骤102-104；具体如下：

JVM加载基于Java虚拟机工具接口(JavaVirtualMachineToolInterface，JVMTI)的动态链接库文件，根据该动态链接库文件生成JVMTIAgnet，将封装有步骤102-104的函数在JVMTIAgnet中进行注册，当JVMTI监测到类文件被加载时，JVMTIAgnet通过回调函数调用该函数。

下面以一个实例详细说明其过程：

在JVM上配置-javaagent:/app/dev/hlog-agent-0.1.jar通知JVM进行JVMTI包的加载，以代理日志采集工作，其中，在代理过程中，对日志采集进行相应配置，完整参数如下：

-javaagent:/app/dev/hlog-agent-0.1.jar#加载JVMTI包

-DhlogDomain＝CRMSERV

-DhlogServerAlias＝CRMSERV

-DhlogLevel＝none

-DhlogSaveWeaveClass＝no

-noverify

进一步的，由于现有技术中通常将采集到的日志信息实时传输至服务后台进行日志应用，此时，若日志信息处于大并发和大数据量的情况下，则经常会出现如ACTIVEMQ队列不工作的性能问题，因此，为了解决该问题，在本发明实施例图1所示的日志采集系统下，JVM在采集到日志信息后，还可以包括如下步骤：

通过异步传输的方式将采集到的日志信息发送至Kafka集群中的消息队列中，以便于日志应用装置读取所述Kafka集群消息队列中的日志消息进行消费。

由上可知，本发明实施例提供一种日志采集方法，所述日志采集方法由日志采集装置中的JVM执行，JVM先加载java应用程序的类文件，当确定所述类文件在日志采集的监控范围内，且所述类文件的所有类方法存在需进行日志采集的类方法时，将日志采集代码植入类方法中，形成新的类文件，重新加载新的类文件进行日志采集。在本发明的日志采集过程中，不需要事先引进第三组件，而是在需要进行日志采集的地方才加载日志采集代码，实现零耦合的日志采集文件的动态加载，避免了现有日志采集过程中，需引入第三方组件导致引用冲突的问题。

另一方面，图4为本发明实施例提供的日志采集装置10的结构图，用于执行上述日志采集方法，如图4所示，所述日志采集装置10可以包括：

类加载器1011：用于加载java应用程序的类文件。

其中，java应用程序的类文件存储在日志采集装置的硬件层内存中，即硬件存储器中。

可选的，类加载器1011，可以用于从日志采集装置的硬件层内存的磁盘目录或Jar包中将java应用程序的类文件加载到JVM的内存中。

判断单元1012：用于判断所述类文件是否在日志采集的监控范围内。

解析单元1013：用于当所述判断单元1012确定所述类文件在日志采集的监控范围内时，获取所述类文件的所有类方法，确定所述所有类方法中是否存在需进行日志采集的类方法。

代码植入单元1014：用于当所述解析单元1013确定所述所有类文件中存在需进行日志采集的类方式时，在需进行日志采集的类方法中植入日志采集代码，形成新的类文件。

所述类加载单元1011，还用于加载所述新的类文件进行日志采集。

具体的，所述判断单元1012，可以用于：

根据所述类文件的属性信息、以及预设的待进行日志采集的类文件的属性信息的集合，判断所述类文件是否在日志采集的监控范围内；

例如：可查询预设的待进行日志采集的类文件的属性信息的集合，若所述类文件的属性信息包含在所述集合中，则表示所述类文件为需要进行日志采集的文件，在日志采集的监控范围内；若所述类文件的属性信息未包含在所述集合中，则表示所述类文件不需要进行日志采集，不在日志采集的监控范围内。

其中，所述属性信息可以包含：类文件所在jar包的包名、和/或类文件的存储路径。

具体的，解析单元1013，可以用于：

从类方法对应的指令代码中查找是否包含与日志采集相关的指令代码，若包含，则确定所述类方法为需进行日志采集的类方法；若不包含，则确定所述类方法不是需进行日志采集的类方法。

具体的，代码植入单元1014可以用于：

当存在需要进行日志采集的类方法时，产生符合预先配置的日志采集类型的代码，将产生的代码植入所述类方法中，形成新的类文件。

需要说明的是，上述单元执行的过程可以由处理器通过调用具有相同的功能程序代码来实现。

进一步的，为了避免在需要进行日志采集的java应用程序上写入配置参数，本发明实施例，如图4所示，在日志采集装置10中可以设置JVMTI1015、以及JVMTI的代理模块1016；

JVMTI1015，用于监测应用模块中是否有类文件被加载；

JVMTI的代理模块1016，用于当JVMTI1015监测到应用模块中有类文件被加载时，通过回调函数调用判断单元1012、解析单元1013、以及代码植入单元1014的执行相应的功能。

其中，应用模块，用于存储日志采集数据的目标对象。

具体的，可以将执行判断单元1012、解析单元1013、以及代码植入单元1014的功能的程序代码封装在一个函数内，将该函数在代理模块1016中进行注册，当JVMTI1015监测到有类文件被加载时，通过回调函数调用该函数，即相当于执行判断单元1012、解析单元1013、以及代码植入单元1014所具有的功能。

进一步的，由于现有技术中通常将采集到的日志信息实时传输至服务后台进行日志应用，此时，若日志信息处于大并发和大数据量的情况下，则经常会出现如ACTIVEMQ队列不工作的性能问题，因此，为了解决该问题，如图4所示，所述日志采集装置10还可以包括：

发送单元1017，用于通过异步传输的方式将采集到的日志信息发送至Kafka集群中的消息队列中，以便于日志应用装置读取所述Kafka集群消息队列中的日志消息进行消费。

由上可知，本发明实施例提供一种包含JVM的日志采集装置，先加载java应用程序的类文件，当确定所述类文件在日志采集的监控范围内，且所述类文件的所有类方法存在需进行日志采集的类方法时，将日志采集代码植入类方法中，形成新的类文件，重新加载新的类文件进行日志采集。在本发明的日志采集过程中，不需要事先引进第三组件，而是在需要进行日志采集的地方才加载日志采集代码，实现零耦合的日志采集文件的动态加载，避免了现有日志采集过程中，需引入第三方组件导致引用冲突的问题。

再一方面，本发明实施例还提供一种如图1所示的日志服务系统，所述日志服务系统可以包括：包含图4所示的JVM101在内的日志采集装置、Kafka集群、以及日志应用装置。

其中，所述JVM101与前述JVM具有相同功能，在此不再赘述；

所述Kafka集群为存储数据的中转设备。

所述日志采集装置，用于接收采集到的日志信息，并对日志信息进行消费，如：可以将接收到日志信息流进行不同格式的处理，并将处理后的数据存储于不同的介质上，如ORACLE、文件、大数据或FTP服务等。

其中，为了避免采集到的日志信息处于大并发和大数据量的情况下，出现如ACTIVEMQ队列不工作的性能问题，所述JVM101可以用于：通过异步传输的方式将采集到的日志信息发送至Kafka集群中的消息队列中；

相应的，所述日志应用装置，可以用于读取所述Kafka集群消息队列中的日志消息进行消费。

由上可知，本发明实施例提供一种日志采集系统，先通过日志采集装置进行日志采集，然后将采集到的日志信息通过异步传输的方式将采集到的日志信息发送至Kafka集群中的消息队列中，以便于后期日志应用装置的读取消费。如此，通过异步传输的方法进行信息传输，使得日志服务的吞吐量和性能得到很大的提高。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种日志采集方法，其特征在于，包括：

加载java应用程序的类文件；

判断所述类文件是否在日志采集的监控范围内；

若确定所述类文件在日志采集的监控范围内，则获取所述类文件的所有类方法，确定所述所有类方法中是否存在需进行日志采集的类方法；

若所述所有类方法中存在需进行日志采集的方法，则在需进行日志采集的类方法中植入日志采集代码，形成新的类文件；

加载所述新的类文件进行日志采集。

2.根据权利要求1所述的方法，其特征在于，所述判断所述类文件是否在日志采集的监控范围内包括：

查询预设的待进行日志采集的类文件的属性信息的集合，若所述类文件的属性信息包含在所述集合中，则确定所述类文件在日志采集的监控范围内；

若所述类文件的属性信息未包含在所述集合中，则确定所述类文件不在日志采集的监控范围内；

其中，所述属性信息包含：类文件所在jar包的包名、和/或类文件的存储路径。

3.根据权利要求1或2所述的方法，其特征在于，对于所述类文件的任一类方法，确定所述类方法中是否存在需进行日志采集的类方法具体包括：

查询所述类方法对应的指令代码；

若所述指令代码中包含与日志采集相关的指令代码，则确定所述类方法为需进行日志采集的类方法；

所述指令代码中未包含与日志采集相关的指令代码，则确定所述类方法不是需进行日志采集的类方法。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

通过异步传输的方式将采集到的日志信息发送至Kafka集群中的消息队列中，以便于日志应用装置读取所述Kafka集群消息队列中的日志消息进行消费。

5.一种日志采集装置，其特征在于，包括：

类加载器：用于加载java应用程序的类文件；

判断单元：用于判断所述类文件是否在日志采集的监控范围内；

解析单元：用于当所述判断单元确定所述类文件在日志采集的监控范围内时，获取所述类文件的所有类方法，确定所述所有类方法中是否存在需进行日志采集的类方法；

代码植入单元：用于当所述解析单元确定所述所有类方法中存在需进行日志采集的方法时，在需进行日志采集的类方法中植入日志采集代码，形成新的类文件；

所述类加载单元，还用于加载所述新的类文件进行日志采集。

6.根据权利要求5所述的装置，其特征在于，所述判断单元具体用于：

查询预设的待进行日志采集的类文件的属性信息的集合，若所述类文件的属性信息包含在所述集合中，则确定所述类文件在日志采集的监控范围内；

若所述类文件的属性信息未包含在所述集合中，则确定所述类文件不在日志采集的监控范围内；

其中，所述属性信息包含：类文件所在jar包的包名、和/或类文件的存储路径。

7.根据权利要求5或6所述的装置，其特征在于，所述解析单元具体用于：

查询所述类方法对应的指令代码；

若所述指令代码中包含与日志采集相关的指令代码，则确定所述类方法为需进行日志采集的类方法；

所述指令代码中未包含与日志采集相关的指令代码，则确定所述类方法不是需进行日志采集的类方法。

8.根据权利要求5所述的装置，其特征在于，所述日志采集装置还包括：JVMTI以及代理模块；

JVMTI，用于监测是否有类文件被加载；

代理模块，用于当JVMTI监测到类加载器加载了java应用程序的类文件时，通过回调函数调用所述判断单元、所述解析单元、以及所述代码植入单元执行相应的功能。

9.根据权利要求5-8任一项所述的装置，其特征在于，所述日志采集装置还包括：

发送单元，用于通过异步传输的方式将采集到的日志信息发送至Kafka集群中的消息队列中，以便于日志应用装置读取所述Kafka集群消息队列中的日志消息进行消费。

10.一种日志采集装置，其特征在于，包括：硬件层、运行在所述硬件层之上的宿主机(Host)、以及运行在所述Host之上的至少一个Java虚拟机JVM；

其中，所述JVM用于执行权利要求1-4任一项所述的方法。