一种日志信息输出控制方法及装置
技术领域
本申请涉及计算机应用技术领域,尤其涉及一种日志信息输出控制方法及装置。
背景技术
日志是一种用于记录系统运行情况的文本信息,当系统出现故障时,维护人员可以通过分析日志信息的方式来排查故障,此外,日志信息也是对系统进行优化或调整时的重要依据。
日志信息的输出包括写入日志文件、在控制台展现等方式,根据所记录事件的重要程度,日志信息被划分为若干级别,例如,一种四级分类体系下的日志信息级别包括debug、info、warn和error,其重要程度为:debug<info<warn<error。在系统正常运行过程中,会产生大量的日志信息,基于性能方面的考虑,一般会将系统配置为仅对比较重要的日志信息(例如warn及以上级别)进行输出,而当需要进行故障排查时或其他功能测试时,系统维护人员则希望看到包括debug、info在内的更为详尽的日志信息。为满足上述需求,现有技术的实现方式是通过重启系统、加载不同的配置文件以控制日志信息的输出级别,然而对于在线运行的系统而言,重启的代价往往是非常大的,为了改变日志信息的输出级别而频繁重启系统可能会导致更为严重的问题,例如,引起暂时性的服务不可用。
发明内容
针对上述技术问题,本申请提供一种日志信息输出控制方法及装置,技术方案如下:
一种日志信息输出控制方法,该方法包括:
接收业务处理请求;
判断所述业务处理请求中是否携带测试业务标识;
如果是,则在对应于所述业务处理请求的本次业务处理过程中,按照预设的测试业务所需级别对日志信息进行输出;
否则,在本次业务处理过程中,按照默认的输出级别配置对日志信息进行输出。
一种日志信息输出控制装置,该装置包括:
业务请求接收模块,用于接收业务处理请求;
业务类型识别模块,用于判断所述业务处理请求中是否携带测试业务标识;
日志信息输出模块,用于在所述业务处理请求中携带测试业务标识的情况下,在对应于所述业务处理请求的本次业务处理过程中,按照预设的测试业务所需级别对日志信息进行输出;否则,在本次业务处理过程中,按照默认的输出级别配置对日志信息进行输出。
应用本申请所提供的技术方案,在系统维护人员发出的测试业务请求中添加一个特殊标识,对于系统而言,能够根据业务处理请求中是否携带该标识来识别当前要处理的业务是正常的线上业务还是用于模拟线上环境的测试业务,并且进一步根据识别结果控制日志信息的输出级别。与现有技术相比,不需要重新启动系统就可以针对不同的需求灵活控制日志信息的输出级别。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1是本申请的日志信息输出控制方法的流程示意图;
图2是本申请的一种日志信息输出架构示意图;
图3是本申请的MrpLogger日志记录器的架构示意图;
图4是本申请的日志信息输出控制装置的结构示意图。
具体实施方式
针对现有技术所存在的问题,本申请所提出的解决方案是,在业务请求中增加特定的标识位,对于一般线上业务和用于模拟线上环境的测试业务进行区分,这样,系统在接收业务请求后,可以根据请求中的标识位判断出本次请求的业务是正常的线上业务还是测试业务,然后根据判断结果确定在本次业务的处理过程中需要输出何种级别的日志信息。
为了使本领域技术人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行详细地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于本申请保护的范围。
图1所示,为本申请提供的日志信息输出控制方法的流程图,该方法可以包括以下步骤:
S101,接收业务处理请求;
S102,判断所述业务处理请求中是否携带测试业务标识,如果是则执行S103,否则执行S104;
S103,则在本次业务处理过程中,按照预设的测试业务所需级别对日志信息进行输出;
S104,否则,在本次业务处理过程中,按照默认的输出级别配置对日志信息进行输出。
为了便于描述,在后文中将系统正常运行时所处理的一般业务称为“非测试业务”,根据本申请方案,为了对非测试业务和用于模拟线上环境的测试业务进行区分,采用在业务请求中增加特定标识位的方式。为了尽量减少对原有系统的改动,可以在仅在测试业务请求中增加一个特定标识位,然后为系统的日志输出装置增加解析业务请求并识别该标识位的功能。当然,也可以在非测试业务请求和测试业务请求中统一增加标识位,通过赋予不同标识位取值的方式来实现对两种业务请求的区分,本申请对此并不需要进行限定。
系统在接收到一次业务处理请求后,在处理对应的业务之前,先对业务处理请求进行解析,根据该请求中是否携带测试业务标识,判断本次需要处理的业务是测试业务还是一般线上业务。如果是非测试业务,则在后续处理本次业务的过程中,按照系统默认的输出级别配置对日志信息进行输出,如果是测试业务,则在后续处理本次业务的过程中,按照测试业务所需的级别对日志信息进行输出。
例如,系统采用包含debug、info、warn和error的四级日志信息分类体系,在系统正常运行期间,默认的配置是仅输出warn及以上级别的日志信息,为了满足测试需求,可以配置为对于测试业务输出全部级别的日志信息。这样,系统接收到业务处理请求后,如果判断出本次业务为非测试业务,则输出warn和error级别的日志信息,如果判断出本次业务为测试业务,则输出debug、info、warn和error级别的日志信息。
可以理解的是,如果还有进一步细化的多种日志信息输出级别控制需求,可以使用多个标记位取值,例如,规定标识位取1时,输出info、warn和error三种级别的日志信息,标识位取2时,输出debug、info、warn和error四种级别的日志信息,等等。当然,也可以在业务请求中另行增加新的标识位以实现上述功能,本申请对此并不需要进行限定。
根据本申请方案,可以使用多种方式实现日志信息的输出。例如,按照输出时机的不同,可以分为实时输出和延时输出;而按照输出形式的不同,又可以分为将日志信息写入日志文件、在命令行控制台进行显示输出、在网页进行显示输出等。对于输出方式的控制,可以使用系统默认的方式,也可以在业务处理请求中进一步增加一个输出方式标识位,利用不同的数值代表不同的日志信息输出方式,例如以0代表实时输出、1代表延时输出,等等。用户在需要对系统进行测试时,可以手动选择所期望的日志信息输出方式,在生成测试业务处理请求时,会根据用户的选择在请求的输出方式标识位写入不同的数值,以便系统进行区分。
在需要对日志信息进行延时输出时,可以预先分配一部分缓存空间用于存储所输出的日志信息,对于已经写入缓存的日志信息,可以采用周期性取出的方式,也可以采用事件触发取出的方式,例如在业务请求处理完成后取出、在缓存的中的日志信息达到一定数值后取出、根据用户的手动触发操作从缓存取出,等等。根据实际需求,从缓存中取出的日志信息后,进一步的处理方式可以是直接做显示输出,或者写入日志文件等等,对从缓存中所取出的日志信息处理完毕后,可以将这部分日志信息从缓存中清除。
图2所示,为本申请提供的一种日志信息输出控制架构示意图,下面分别对各个部分进行说明:
Thread Local通道容器:是预先划分出的缓存空间,用于临时存放输出的日志信息,并且根据用户的手动操作从缓存中取出日志信息在网页控制台页面上进行显示。
通道标记位过滤:是Thread Local通道容器的开关,当上层有日志信息输出时,根据该标记检测Thread Local通道容器是否开启,如果开启则将日志信息输出到ThreadLocal通道容器中,否则会忽略此次日志信息输出操作。
通道统一访问接口:底层存储容器暴露给上层日志信息输出组件的统一接口。
通用接口、Debug Trace Appender输出器和MrpLogger是三种输出组件,三种输出组件均可以输出日志信息,区别仅在于使用方式。
MrpLogger日志记录器:如图3所示,MrpLogger包含两个日志记录体系的日志记录器,记为LogA和LogB。其中LogA是处理测试业务时所使用的记录器,对应的日志输出位置为Debug Trace Appender输出器,最终的输出方式为根据用户的操作在网页控制台页面进行显示日志信息,LogB是处理非测试业务时所使用的记录器,对应的日志输出方式为实时写入日志文件或实时在命令行控制台进行显示输出。
Debug Trace Appender输出器:具有两种功能:一方面,可以作为MrpLogger日志记录器的一个输出位置组件,配合MrpLogger中的LogA将更为丰富日志信息输出到网页控制台页面;另一方面,当执行非测试业务时,可以将默认级别的日志信息输出到日志文件。
通用接口:既可以用于输出非测试业务对应的默认级别日志信息,也可以用于输出测试业务对应的更为丰富日志信息,输出的方式仅支持在网页控制台页面进行显示。
根据上述架构,用户在需要对系统进行测试时、并且希望在网页控制台页面看到日志信息时,首先通过操作打开通道标记位过滤开关,然后发出测试业务处理请求,该请求中携带测试业务标识,系统接收到该请求后,根据标识确定该请求属于测试业务请求。同时,根据图2所示出的架构,根据该标识还能够进一步确定输出方式为网页控制台页面进行显示。在本次业务的后续执行过程中,系统按照测试业务的需求输出更为丰富的日志信息至Thread Local通道容器。当请求处理结束时,系统从Thread Local通道容器取出已缓存的日志信息,并将日志通过http协议传输到网页控制台页面显示,并且清除Thread Local通道容器中缓存的内容和关闭通道标记位过滤开关。
需要说明的是,图2所示的架构仅是本申请日志输出控制方案的一种具体实施方式,并不应理解为对本申请方案的限定。
相应于上述方法实施例,本申请还提供一种日志信息输出控制装置,参见图4所示,该装置可以包括:
业务请求接收模块110,用于接收业务处理请求;
业务类型识别模块120,用于判断业务处理请求中是否携带测试业务标识;
日志信息输出模块130,用于在所述业务处理请求中携带测试业务标识的情况下,在对应于业务处理请求的本次业务处理过程中,按照预设的测试业务所需级别对日志信息进行输出;否则,在本次业务处理过程中,按照默认的输出级别配置对日志信息进行输出。
在本申请的一种具体实施方式中,业务处理请求中还携带日志信息输出方式标识;日志信息输出模块130可以具体用于:根据日志信息输出方式标识,控制本次业务处理过程中的日志信息输出方式。
在本申请的一种具体实施方式中,日志信息输出模块130对日志信息进行输出的方式可以包括:
将日志信息写入预设的缓存位置,或
对日志信息进行实时显示输出或实时写入日志文件。
在本申请的一种具体实施方式中,日志信息输出模块130还可以用于:
将日志信息写入预设的缓存位置后,根据预设的取出条件,对缓存中的日志信息进行显示输出或写入日志文件。
在本申请的一种具体实施方式中,日志信息输出模块130还可以用于:
将已进行显示输出或已写入日志文件日志的信息从缓存中清除。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本申请的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。