中间件客户端的日志管理方法、装置及计算机系统
技术领域
本申请涉及中间件客户端的日志管理技术领域,特别是涉及中间件客户端的日志管理方法、装置及计算机系统。
背景技术
中间件是处于操作系统和应用程序之间的软件,例如,可以包括消息队列中间件,远程过程调用中间件,等等。这种中间件可以以服务或者代码库等形式,并提供给程序开发人员使用。对于服务形式的中间件,可以为开发者提供相关的API,开发者在开发自己的应用的过程中,可以通过调用API的方式,将具体的中间件客户端引入到自己的应用中,由中间件客户端实现相关的功能。而对于代码库形式存在的中间件,直接在应用代码中引入中间件的代码即可。由于中间件屏蔽了底层操作系统的复杂性,因此,使程序开发人员可以面对一个简单而统一的开发环境,减少程序设计的复杂性,将注意力集中在自己的业务上,不必再为程序在不同系统软件上的移植等而重复工作,从而大大减少了技术上的负担。
对于一个应用而言,除了实现基础功能之外,通常还需要实现日志记录功能,以记录应用运行过程中的一些具体的日志信息,例如,对于支付功能的应用,可以对支付是否成功、收款是否成功等信息进行记录,以供后续进行问题分析排查等。而如果在应用中使用了某中间件客户端,则通常也需要实现对该中间件客户端的日志记录功能,例如,包括中间件客户端在运行过程中的服务调用关系,是否调用成功,等等。为此,由于中间件客户端还可以为开发者提供日志接口类库,其中定义了日志打印所需的API接口,例如,常用的有:slf4j,jcl等,开发者在开发应用的过程中,如果需要使用中间件客户端,则需要在代码中实现对这些API接口的调用逻辑。为此,中间件客户端的提供者通常还需要为开发者提供使用文档,关于具体配置哪些日志,日志打印的路径以及日志规范等都可以通过这种文档告诉开发者,然后,由需要开发者在应用工程的日志配置文件中加入这些对中间件客户端的日志配置。但是,应用的开发者通常仅对自己应用内部的功能逻辑等比较了解,例如,支付应用开发者通常对支付功能、收款功能等比较了解,而关于中间件客户端内部的逻辑(消息队列,远程过程调用等)可能并不了解,因此,开发者需要理解每个中间件客户端(或其他功能性Jar)的相关配置知识,这个过程中有一定学习和工作成本,而且容易出现漏配,配错以及配置信息不一样等情况,不利后续运维,问题分析排查等场景。
另一种实现方式时,可以提供一些日志实现类库,与日志接口类库不同的是,通过这种日志实现类库可以直接提供日志打印的具体实现逻辑,而不再是简单的接口。例如,常见的java库包括:log4j,log4j2,logback等。这样,中间件客户端中可以预先实现对其中一种日志实现类库的依赖,使得开发者直接在自己的应用中引入具体的中间件客户端即可,而不再需要在应用代码中实现对中间件客户端的日志记录相关逻辑。但是,这种方式的缺点在于,日志实现类库的种类比较多,中间件客户端使用的其中一种日志实现类库是中间件提供者预先选择并绑定的,该信息对于应用开发者而言是透明的;而具体开发的应用内使用的日志实现类库则是由应用开发者设定的,因此,可能出现中间件客户端与应用工程所使用的日志实现类库不一样或者版本不兼容的情况,导致的复杂的依赖冲突问题,需要耗费时间解决冲突,严重时甚至无法使用。
因此,如何更好的实现对应用中引入的中间件客户端的日志记录,成为需要本领域技术人员解决的技术问题。
发明内容
本申请提供了中间件客户端的日志管理方法、装置及计算机系统,能够节省学习以及工作成本的同时,避免中间件客户端依赖的日志实现类库与目标应用所依赖的日志实现类库之间产生冲突。
本申请提供了如下方案:
一种中间件客户端的日志管理方法,
所述中间件客户端中定义有命名空间,所述命名空间对应的资源目录下包括多个子目录,每个子目录分别与一种日志实现类库对应,并保存有对应日志实现类库的日志配置文件;所述中间件客户端中还实现了以所述命名空间的标识信息为参数对预置的日志管理功能库的调用逻辑;
在所述中间件客户端被引入到目标应用,所述目标应用启动并运行到所述中间件客户端的代码时,通过调用所述日志管理功能库执行以下处理:
确定所述目标应用依赖的日志实现类库,并根据所述目标应用依赖的日志实现类库确定目标日志实现类库;
从所述命名空间的资源目录中确定所述目标日志实现类库对应的目标日志配置文件;
通过解析所述目标日志配置文件,生成日志工具对象,以便通过所述日志工具对象实现对所述中间件客户端的日志输出。
一种中间件客户端的日志管理装置,
所述中间件客户端中定义有命名空间,所述命名空间对应的资源目录下包括多个子目录,每个子目录分别与一种日志实现类库对应,并保存有对应日志实现类库的日志配置文件;所述中间件客户端中还实现了以所述命名空间的标识信息为参数对预置的日志管理功能库的调用逻辑;
所述装置包括:
探测单元,用于在所述中间件客户端被引入到目标应用,所述目标应用启动并运行到所述中间件客户端的代码时,确定所述目标应用依赖的日志实现类库,并根据所述目标应用依赖的日志实现类库确定目标日志实现类库;
目标日志配置文件确定单元,用于从所述命名空间的资源目录中确定所述目标日志实现类库对应的目标日志配置文件;
日志工具对象生成单元,用于通过解析所述目标日志配置文件,生成日志工具对象,以便通过所述日志工具对象实现对所述中间件客户端的日志输出。
一种计算机系统,包括:
一个或多个处理器;以及
与所述一个或多个处理器关联的存储器,所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:
确定目标应用依赖的日志实现类库,并根据所述目标应用依赖的日志实现类库确定目标日志实现类库;
从预置的命名空间的资源目录中确定所述目标日志实现类库对应的目标日志配置文件;
通过解析所述目标日志配置文件,生成日志工具对象,以便通过所述日志工具对象实现对中间件客户端的日志输出。
根据本申请提供的具体实施例,本申请公开了以下技术效果:
在本申请实施例中,通过为中间件客户端定义命名空间,在命名空间对应的资源目录下创建多个子目录,分别用于保存各种常用的日志实现类库对应的日志配置文件,并以命名空间的标识信息为参数实现对预置的日志管理功能库的调用。这样,在一个目标应用引入了该中间件客户端之后,在该目标应用启动并运行到该中间件客户端时,便可以实现对日志管理功能库的调用。然后,日志管理功能库可以首先对目标应用实际依赖(直接或间接)的日志实现类库进行感知,然后据此确定出中间件客户端可以使用的目标日志实现类库,并从命名空间中取出该目标日志实现类库对应的日志配置文件,通过对该日志配置文件的解析,生成具体的日志工具对象,以此实现对中间件客户端的日志输出。通过上述方式,使得应用的开发者不必再通过编写代码的方式来实现对中间件客户端的日志输出,可以节省学习以及工作成本;同时,由于中间件客户端并没有与任何一个日志实现类库进行强绑定,而是能够根据目标应用实际所依赖的日志实现类库,来智能适应到合适的日志实现类库,因此,还可以避免中间件客户端依赖的日志实现类库与目标应用所依赖的日志实现类库之间产生冲突。
当然,实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的方案的逻辑结构示意图;
图2是本申请实施例提供的方法的流程图;
图3是本申请实施例提供的应用日志空间示意图;
图4是本申请实施例提供的装置的示意图;
图5是本申请实施例提供的计算机系统的示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员所获得的所有其他实施例,都属于本申请保护的范围。
为了更好的理解本申请实施例提供的技术方案,现在首先对应用、中间件客户端之间的关系进行简单的介绍。
在本申请实施例中,具体的应用可以是指程序开发者开发的应用,例如,可以是具有支付功能的应用,等等。开发者在开发一款应用时,通常都会为应用实现日志记录逻辑,以便在一些关键的业务节点处对业务处理结果进行日志记录。这样,可以通过查看日志的方式,定位应用运行过程中存在的缺陷等等。例如,对于具有支付功能的应用,可以记录某次支付是否成功,某次收款是否成功,等等。为了达到上述目的,开发者可以从已有的多种日志实现类库中选择其中任意一个或多种,然后将自己开发的应用依赖于该日志实现类库,这样,便可以实现对应用主业务逻辑处理过程中的日志输出。或者,由于开发者对自己开发的应用内部的具体业务处理逻辑都比较清楚,因此,为了实现更灵活的日志输出,开发者也可以利用一些日志接口类库,及其对应的使用文档等,自行通过写代码的方式实现具体的日志打印逻辑,等等。总之,开发者在开发一款应用时,会为该应用实现具体的日志输出功能,期间可能会用到已有的标准化的日志实现类库,或者,也可能会是使用日志接口类库,通过编码的方式实现更加适合具体应用的日志输出逻辑。
另外,对于一些分布式的大型应用项目而言,为了减少程序设计的复杂性,将注意力集中在自己的业务上,开发者可能会在应用中使用中间件客户端,来屏蔽底层操作系统的复杂性。例如,如果应用中需要进行消息队列处理,或者实现远程过程调用,等等,则可以使用中间件客户端来实现,此时,开发者只需要通过中间件客户端提供的API等接口,在应用的代码中实现对中间件客户端的调用即可实现对应的消息队列处理、远程过程调用等功能,而无需关心功能内部的具体代码实现。
其中,中间件客户端通常是由具体的中间件服务商提供的,也就是说,对于中间件服务商而言,其职能是提供中间件客户端,这种中间件客户端的用户是程序开发者。开发者在自己开发的应用中引入一个中间件客户端时,该中间件客户端的内部实现逻辑对于应用开发者而言可以是透明的,但是,该中间件客户端在运行过程中同样可能会存在一些需要排查的问题,因此,也需要对中间件客户端的运行过程进行日志输出。而由于应用开发者并不熟悉中间件客户端的内部实现,因此,如果由应用开发者使用日志接口类库来进行编码实现中间件客户端的日志输出功能,则会增加开发者的学习以及工作成本。而如果由中间件客户端的提供者预先为中间件客户端绑定某一种日志实现类库,则可能会存在中间件客户端依赖的日志实现类库,与应用本身依赖的日志实现类库相冲突的问题。
因此,在本申请实施例中,为了在对中间件客户端进行日志输出时,降低应用开发者的学习和工作成本,同时也避免中间件客户端所依赖的日志实现类库与应用本身所依赖的日志实现类库之间产生冲突,提供了相应的解决方案。在该方案中,参见图1,首先可以为中间件客户端提供命名空间(namespace)的概念,通过在中间件客户端中定义namespace,可以逻辑隔离出多个域,使得namespace里可以尽量定义常见的各种日志实现类库分别对应的配置文件,从而避免了提前为中间件客户端绑定某种固定的日志实现类库;另外,还可以提供独立的日志管理功能库,该日志管理功能库的作用主要可以是用于为中间件客户端生成具体的日志工具对象,以便通过该日志工具对象实现对中间件客户端的日志输出。中间件客户端中在定义了namespace,并实现了多种日志实现类库分别对应的配置文件之后,还可以以该namecpace的名称等标识信息为参数,实现对该日志管理功能库的调用。这样,在该中间件客户端被引入某应用时,应用开发者不需要为该中间件客户端进行与日志管理相关的处理,直接通过API调用等方式引入中间件客户端即可。而在该应用运行时,中间件客户端便可以通过调用前述日志管理功能库,对应用运行当前环境中使用的日志实现类库进行智能探测,并将中间件客户端具体使用的日志实现类库自适应到与该应用相同的日志实现类库,并生成相应的日志工具对象,实现对中间件客户端的日志输出。其中,日志管理功能库在进行上述对应用所依赖的日志实现类库的探测,以及具体日志工具对象的生成等处理时,可以是在工厂模式下来进行,也即,上述处理过程对于中间件客户端的使用者(即具体的应用开发者)而言也可以是不感知的,因此,上述日志管理功能库也可以称为“日志工厂”。也就是说,在本申请实施例中,中间件客户端中预先实现了对多种日志实现类库的日志配置文件,具体在运行过程中使用哪种日志实现类库进行日志输出,则取决于应用实际所使用的日志实现类库。这样,不需要应用开发者对中间件客户端的日志管理进行相应的编码操作,同时,也不会出现中间件客户端与应用所依赖的日志实现类库相冲突的问题。
下面对具体的实现方式进行详细介绍。
首先,本申请实施例提供了一种中间件客户端的日志管理方法,具体实现是,所述中间件客户端中定义有命名空间,所述命名空间对应的资源目录下包括多个子目录,每个子目录分别与一种日志实现类库对应,并保存有对应日志实现类库的日志配置文件;所述中间件客户端中还实现了以所述命名空间的标识信息为参数对预置的日志管理功能库的调用逻辑。其中,所述中间件客户端具体可以包括多种,也即,在实际应用中,各种中间件客户端都可以通过本申请实施例提供的方式,来实现namespace,并对预置的日志管理功能库进行调用。具体实现时,可以由中间件客户端的提供者通过写代码的方式实现上述定义以及对日志管理功能库的调用。例如,首先可以在中间件客户端的代码中加入上述用于定义namespace的代码,并且,还可以为具体的namespace定义唯一的名称信息。之后,便可以在该namespace对应的资源目录下创建多个子目录,其中,每个子目录可以对应一种日志实现类库。这里的日志实现类库可以是常用的标准化日志实现类库,也即,分别为各种常用的日志实现类库创建子目录,子目录的名称可以与日志实现类库的名称相同。例如,常用的日志实现类库包括Log4j2,Logback,Log4j,则可以在namespace对应的资源目录下创建三个子目录,各自的名称分别为Log4j2,Logback,Log4j。另外,还可以在各子目录中分别保存各自对应的日志实现类库的日志配置文件。也就是说,如果共有三种常用的日志实现类库,则可以在同一个中间件客户端的namespace中保存三份日志配置文件,这三份日志配置文件与中间件客户端之间均不存在绑定关系,但是,可以通过另外提供的日志管理功能库,来实现对对其中任意一种日志配置文件的解析,并使其对应的日志实现类库生效。因此,在完成对namespace的定义,以及子目录的创建、日志配置文件的保存之后,还可以以该namespace的名称等标识信息为参数,实现对前述日志管理功能库的调用。具体实现时,所述日志管理功能库也可以提供相关的API,这样,中间件客户端的提供者可以通过在代码中加入对该API的调用,来实现对日志管理功能库的调用。这样,后续在该中间件客户端被具体的应用调用并运行时,中间件客户端就可以调用该日志管理功能库,来实现对中间件客户端的日志管理。
在完成对中间件客户端中namespace的定义,以及实现对日志管理功能库的调用等处理之后,便可以将中间件客户端提供给应用开发者使用。这样,应用开发者在需要开发某款应用时,便可以在该应用中引用该中间件客户端,具体可以通过API调用等方式来实现上述对中间件客户端的引用。相应的,在所述中间件客户端被引入到目标应用,并且所述目标应用启动并运行到所述中间件客户端的代码时,便可以通过调用所述日志管理功能库执行具体的日志管理方面的处理操作。也即,在一项具体的应用开发完成之后,便可以启动运行,在运行过程中,如果其中引入了某中间件客户端,则在某时刻会调用该中间件客户端,使得中间件客户端得以运行,进而,在中间件客户端运行的过程中,由于预先实现了对日志管理资源库的调用,因此,日志管理资源库会被调用,并执行对中间件客户端的日志管理相关的处理操作。具体的,如图2所示,处理过程可以包括:
S201:确定所述目标应用依赖的日志实现类库,并根据所述目标应用依赖的日志实现类库确定目标日志实现类库;
首先可以确定出当前的目标应用本身所依赖的日志实现类库。具体实现时,关于目标应用本身所依赖的日志实现类库通常是由该目标应用的开发者所指定的,日志管理资源库可以通过相关的API等探测到当前的目标应用本身所依赖的日志实现类库。在实际应用中,目标应用本身所依赖的日志实现类库可能会仅有一个,或者也可能有多个。其中,如果所述目标应用仅依赖一个日志实现类库,则可以将该目标应用依赖的日志实现类库确定为所述目标日志实现类库。如果所述目标应用依赖多个日志实现类库,则可以从该目标应用依赖的多个日志实现类库中选择其中一个作为所述目标日志实现类库。其中,所述目标日志实现类库也就是为中间件客户端确定出的具体可以使用的日志实现类库。
S202:从所述命名空间的资源目录中确定所述目标日志实现类库对应的目标日志配置文件;
在确定出目标日志实现类库之后,由于在中间件客户端的namespace中已经预先保存了该目标日志实现类库的配置文件,因此,还可以从所述命名空间的资源目录中确定所述目标日志实现类库对应的目标日志配置文件。
S203:通过解析所述目标日志配置文件,生成日志工具对象,以便通过所述日志工具对象实现对所述中间件客户端的日志输出。
在确定出所述目标日志配置文件之后,还可以对目标日志配置文件进行解析,得到解析结果,然后,可以根据解析结果生成具体的日志工具对象。例如,当感知到目标应用依赖的日志实现类库是Log4j2,则可以选择namespace中Log4j2对应的日志配置文件并进行解析,然后,据此生成日志工具对象。这样,便可以通过所述日志工具对象实现对所述中间件客户端的日志输出。其中,所述解析结果具体可以包括日志打印路径和/或日志规范信息等。也就是说,根据具体的日志打印路径以及日志规范信息等,便可以生成具体的日志工具对象,该日志工具对象便可以用于实现对中间件客户端的日志输出。
由于本申请实施例中保存了具体日志实现类库对应的日志配置文件,因此,具体的日志打印路径可以是根据这种配置文件生成的,例如,可以根据所述目标日志实现类库对应的目标日志配置文件所在的子目录,确定日志打印路径,以便将对所述中间件客户端的日志信息记录到该子目录中,等等。也就是说,在本申请实施例中,具体中间件客户端对应的日志打印路径,与目标应用本身对应的日志打印路径可以是不同的。另外,如果一个目标应用中对应多个不同的中间件客户端,则各个不同的中间件客户端对应的日志打印路径都可以是不同的。也就是说,如图3所示,通过namespace来划分出多个日志空间,使得每个日志空间都可以独立指定一个日志配置文件,并都可以作为中间件客户端的日志打印路径。
需要说明的是,在具体实现时,还可以将日志配置文件解析结果和/或所述日志工具对象加入缓存,这样,只需要在首次尝试时解析一次,之后再使用时通过所述缓存中的信息便可以获取日志工具对象,因此,可以提高效率。
当然,如前文所述,在具体实现时,还可能存在以下情况:对于目标应用中的日志输出功能,可能并不是基于标准的日志实现类库来实现的,而是由应用的开发者自行通过编写代码的方式,调用日志接口类库来实现。此时,探测结果可能是所述目标应用未依赖标准的日志实现类库。此时,还可以确定出所述目标应用使用的日志工具对象,该日志工具对象是根据日志接口类库通过编写代码的方式实现的,并且可以利用所述目标应用使用的日志工具对象实现对所述中间件客户端的日志管理。也就是说,在目标应用没有使用标准的日志实现类库的情况下,其通常会通过编写代码的方式实现一个日志工具对象,此时,直接将其日志工具对象作为中间件客户端所使用的日志工具对象即可。这样也可以实现对中间件客户端的日志输出,并且不会与应用实际的日志工具对象相冲突。当然,在这种处理方式下,中间件客户端的日志打印路径会与目标应用自身的日志打印路径相同,也即,中间件客户端的日志可能会与目标应用本身输出的日志混在一起,目标应用的日志空间不会再被划分为多份。
另外需要说明的是,在前述日志管理功能库对目标应用依赖的日志实现类库进行感知,以及对目标日志实现类库的解析,生成日志对象工具,或者直接将目标应用使用的日志对象工具作为中间件客户端的日志对象工具的过程中,可以是在工厂模式下进行的。在工厂模式下创建对象时,不会对具体的应用暴露创建逻辑,并且是通过使用一个共同的接口来指向新创建的对象,由于在本申请实施例中创建的对象特指日志工具对象,因此,也可以将日志管理功能库称为“日志工厂”。“日志工厂”的作用就是根据目标应用中实际使用的日志实现类库,为中间件客户端创建对应的日志工具对象。如果目标应用中没有使用日志实现类库,还可以直接使用目标应用中的日志工具对象。
总之,在本申请实施例中,通过为中间件客户端定义命名空间,在命名空间对应的资源目录下创建多个子目录,分别用于保存各种常用的日志实现类库对应的日志配置文件,并以命名空间的标识信息为参数实现对预置的日志管理功能库的调用。这样,在一个目标应用引入了该中间件客户端之后,在该目标应用启动并运行到该中间件客户端时,便可以实现对日志管理功能库的调用。然后,日志管理功能库可以首先对目标应用实际依赖(直接或间接)的日志实现类库进行感知,然后据此确定出中间件客户端可以使用的目标日志实现类库,并从命名空间中取出该目标日志实现类库对应的日志配置文件,通过对该日志配置文件的解析,生成具体的日志工具对象,以此实现对中间件客户端的日志输出。通过上述方式,使得应用的开发者不必再通过编写代码的方式来实现对中间件客户端的日志输出,可以节省学习以及工作成本;同时,由于中间件客户端并没有与任何一个日志实现类库进行强绑定,而是能够根据目标应用实际所依赖的日志实现类库,来智能适应到合适的日志实现类库,因此,还可以避免中间件客户端依赖的日志实现类库与目标应用所依赖的日志实现类库之间产生冲突。
与前述方法相对应,本申请实施例还提供了一种中间件客户端的日志管理装置,其中所述中间件客户端中定义有命名空间,所述命名空间对应的资源目录下包括多个子目录,每个子目录分别与一种日志实现类库对应,并保存有对应日志实现类库的日志配置文件;所述中间件客户端中还实现了以所述命名空间的标识信息为参数对预置的日志管理功能库的调用逻辑;
参见图4,所述装置具体可以包括:
探测单元401,用于在所述中间件客户端被引入到目标应用,所述目标应用启动并运行到所述中间件客户端的代码时,确定所述目标应用依赖的日志实现类库,并根据所述目标应用依赖的日志实现类库确定目标日志实现类库;
目标日志配置文件确定单元402,用于从所述命名空间的资源目录中确定所述目标日志实现类库对应的目标日志配置文件;
日志工具对象生成单元403,用于通过解析所述目标日志配置文件,生成日志工具对象,以便通过所述日志工具对象实现对所述中间件客户端的日志输出。
具体实现时,所述探测单元具体可以用于:
如果所述目标应用仅依赖一个日志实现类库,则将该目标应用依赖的日志实现类库确定为所述目标日志实现类库。
或者,所述探测单元具体用于:
如果所述目标应用依赖多个日志实现类库,则从该目标应用依赖的多个日志实现类库中选择其中一个作为所述目标日志实现类库。
另外,所述探测单元还可以用于:
如果所述目标应用未依赖标准的日志实现类库,则确定所述目标应用使用的日志工具对象,所述日志工具对象是根据日志接口类库实现的,以便利用所述目标应用使用的日志工具对象实现对所述中间件客户端的日志管理。
具体实现时,所述日志工具对象生成单元可以包括:
解析子单元,用于对所述目标日志配置文件进行解析获得解析结果,所述解析结果包括日志打印路径和/或日志规范信息;
生成子单元,用于根据所述解析结果生成所述日志工具对象。
其中,所述解析子单元具体用于:
根据所述目标日志实现类库对应的目标日志配置文件所在的子目录,确定日志打印路径,以便将对所述中间件客户端的日志信息记录到该子目录中。
另外,该装置还可以包括:
缓存单元,用于将日志配置文件解析结果和/或所述日志工具对象加入缓存,以便下次使用时通过所述缓存中的信息获取日志工具对象。
另外,本申请实施例还提供了一种计算机系统,包括:
一个或多个处理器;以及
与所述一个或多个处理器关联的存储器,所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时,执行如下操作:
确定目标应用依赖的日志实现类库,并根据所述目标应用依赖的日志实现类库确定目标日志实现类库;
从预置的命名空间的资源目录中确定所述目标日志实现类库对应的目标日志配置文件;
通过解析所述目标日志配置文件,生成日志工具对象,以便通过所述日志工具对象实现对中间件客户端的日志输出。
其中,图5示例性的展示出了计算机系统的架构,具体可以包括处理器510,视频显示适配器511,磁盘驱动器512,输入/输出接口513,网络接口514,以及存储器520。上述处理器510、视频显示适配器511、磁盘驱动器512、输入/输出接口513、网络接口514,与存储器520之间可以通过通信总线530进行通信连接。
其中,处理器510可以采用通用的CPU(Central Processing Unit,中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit,ASIC)、或者一个或多个集成电路等方式实现,用于执行相关程序,以实现本申请所提供的技术方案。
存储器520可以采用ROM(Read Only Memory,只读存储器)、RAM(Random AccessMemory,随机存取存储器)、静态存储设备,动态存储设备等形式实现。存储器520可以存储用于控制计算机系统500运行的操作系统521,用于控制计算机系统500的低级别操作的基本输入输出系统(BIOS)。另外,还可以存储网页浏览器523,数据存储管理系统524,以及日志管理系统525等等。上述日志管理系统525就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之,在通过软件或者固件来实现本申请所提供的技术方案时,相关的程序代码保存在存储器520中,并由处理器510来调用执行。
输入/输出接口513用于连接输入/输出模块,以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出),也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等,输出设备可以包括显示器、扬声器、振动器、指示灯等。
网络接口514用于连接通信模块(图中未示出),以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信,也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线530包括一通路,在设备的各个组件(例如处理器510、视频显示适配器511、磁盘驱动器512、输入/输出接口513、网络接口514,与存储器520)之间传输信息。
另外,该计算机系统500还可以从虚拟资源对象领取条件信息数据库541中获得具体领取条件的信息,以用于进行条件判断,等等。
需要说明的是,尽管上述设备仅示出了处理器510、视频显示适配器511、磁盘驱动器512、输入/输出接口513、网络接口514,存储器520,总线530等,但是在具体实施过程中,该设备还可以包括实现正常运行所必需的其他组件。此外,本领域的技术人员可以理解的是,上述设备中也可以仅包含实现本申请方案所必需的组件,而不必包含图中所示的全部组件。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统或系统实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上对本申请所提供的中间件客户端的日志管理方法、装置及计算机系统,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处。综上所述,本说明书内容不应理解为对本申请的限制。