日志收集方法、装置及计算机可读存储介质与流程

文档序号:17130373发布日期:2019-03-16 01:07阅读:179来源:国知局
日志收集方法、装置及计算机可读存储介质与流程

本发明涉及日志处理技术领域,尤其涉及一种日志收集方法、装置及计算机可读存储介质。



背景技术:

现有技术中通常是基于磁盘文本文件间接采集日志,然后通过在业务服务器上部署的日志采集代理直接读取存储在磁盘文件上的日志文件,并对日志文件进行日志解析后发送给下游的日志收集服务。

现有基于磁盘文本文件的日志收集方式主要存在以下弊端:

(1)由于需要频繁对磁盘设备进行操作,因而可能会影响业务服务对磁盘的正常读写;

(2)由于磁盘本身读写性能较低,因而在业务持续高负载的情况下,日志采集代理可能会过载,进而导致业务日志丢失。



技术实现要素:

本发明的主要目的在于提供一种日志收集方法、装置及计算机可读存储介质,旨在解决如何避免基于磁盘文本文件的日志收集方式所存在的弊端的技术问题。

为实现上述目的,本发明提供一种日志收集方法,所述日志收集方法包括以下步骤:

通过前端业务应用的业务进程调用日志采集api,将业务应用产生的日志数据写入共享内存队列;

通过日志采集代理从所述共享内存队列读取日志数据,并将日志数据转发至后端日志收集服务。

可选地,所述共享内存队列的头部设有用于标记所述共享内存队列中已使用的共享内存空间范围的第一偏移量参数与第二偏移量参数;

所述第一偏移量参数用于:标识当前已使用的共享内存空间尾部相对于起始地址的偏移量,以确定当前已使用的共享内存空间尾部位置;

所述第二偏移量参数用于:标识当前已使用的共享内存空间头部相对于起始地址的偏移量,以确定当前已使用的共享内存空间头部位置。

可选地,所述通过前端业务应用的业务进程调用日志采集api,将业务应用产生的日志数据写入共享内存队列包括:

通过前端业务应用的业务进程调用日志采集api,对所述共享内存队列进行cas操作,以根据待写入的日志数据的长度,修改所述第一偏移量参数的参数值;

判断所述第一偏移量参数的参数值是否修改成功;

若是,则将业务应用产生的日志数据写入所述共享内存队列中已使用的共享内存空间尾部。

可选地,所述通过日志采集代理从所述共享内存队列读取日志数据,并将日志数据转发至后端日志收集服务包括:

通过日志采集代理从所述共享内存队列中已使用的共享内存空间头部拷贝日志数据;

根据拷贝的日志数据的长度,修改所述第二偏移量参数的参数值;

将拷贝的日志数据转发至后端日志收集服务。

可选地,所述通过日志采集代理从所述共享内存队列读取日志数据,并将日志数据转发至后端日志收集服务包括:

通过日志采集代理的代理进程,从所述共享内存队列读取日志数据;

根据日志数据的类型,将读取的日志数据传输至对应的转发进程;

通过转发进程将日志数据转发至后端日志收集服务,其中,所述转发进程采用微线程方式转发日志数据。

可选地,所述代理进程与各转发进程之间通过管道传输数据。

可选地,各业务应用中集成有所述日志采集api。

进一步地,为实现上述目的,本发明还提供一种日志收集装置,所述日志收集装置包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的日志收集程序,所述日志收集程序被所述处理器执行时实现如上述任一项所述的日志收集方法的步骤。

进一步地,为实现上述目的,本发明还提供一种计算机可读存储介质,所述计算机可读存储介质上存储有日志收集程序,所述日志收集程序被处理器执行时实现如上述任一项所述的日志收集方法的步骤。

本发明基于共享内存队列采集日志,通过前端业务应用的业务进程调用日志采集api,将业务应用产生的日志数据写入共享内存队列,而通过日志采集代理从共享内存队列读取日志数据,然后将读取的日志数据转发至后端日志收集服务,从而实现日志收集。由于共享内存队列支持多进程通信,因而可提升日志采集的性能,避免日志采集代理过载而导致日志丢失,保证了日志数据采集的稳定性与安全性。

附图说明

图1为本发明日志收集装置实施例方案涉及的设备硬件运行环境的结构示意图;

图2为本发明日志收集方法一实施例的流程示意图;

图3为本发明日志收集方法一实施例中的日志采集上下文示意图;

图4为本发明日志收集方法中共享内存队列一实施例的结构示意图;

图5为图2中步骤s10一实施例的流程示意图;

图6为图4中写入日志数据时共享内存队列的前后变化示意图;

图7为图2中步骤s20一实施例的流程示意图;

图8为图4中读取日志数据时共享内存队列的前后变化示意图;

图9为图2中步骤s20另一实施例的流程示意图;

图10为本发明日志收集方法一实施例中日志采集代理转发日志数据的结构示意图。

本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。

具体实施方式

应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。

本发明提供一种日志收集装置。

参照图1,图1为本发明日志收集装置实施例方案涉及的设备硬件运行环境的结构示意图。

如图1所示,日志收集装置可以包括:处理器1001,例如cpu,通信总线1002、用户接口1003,网络接口1004,存储器1005。其中,通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(display)、输入单元比如键盘(keyboard),可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如wi-fi接口)。存储器1005可以是高速ram存储器,也可以是稳定的存储器(non-volatilememory),例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储设备。需要说明的是,处理器1001采用嵌入式芯片方式安装在日志收集装置内。

本领域技术人员可以理解,图1中示出的日志收集装置的硬件结构并不构成对日志收集装置的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。

如图1所示,作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及日志收集程序。其中,操作系统是管理和控制日志收集装置与软件资源的程序,支持网络通信模块、用户接口模块、日志收集程序以及其他程序或软件的运行;网络通信模块用于管理和控制网络接口1004;用户接口模块用于管理和控制用户接口1003。

在图1所示的日志收集装置硬件结构中,网络接口1004主要用于连接系统后台,与系统后台进行数据通信;用户接口1003主要用于连接客户端(用户端),与客户端进行数据通信;日志收集装置通过处理器1001调用存储器1005中存储的日志收集程序,并执行以下操作:

通过前端业务应用的业务进程调用日志采集api,将业务应用产生的日志数据写入共享内存队列;

通过日志采集代理从所述共享内存队列读取日志数据,并将日志数据转发至后端日志收集服务。

进一步地,所述共享内存队列的头部设有用于标记所述共享内存队列中已使用的共享内存空间范围的第一偏移量参数与第二偏移量参数;

日志收集装置通过处理器1001调用存储器1005中存储的日志收集程序,还执行以下操作:

通过前端业务应用的业务进程调用日志采集api,对所述共享内存队列进行cas操作,以根据待写入的日志数据的长度,修改所述第一偏移量参数的参数值;

判断所述第一偏移量参数的参数值是否修改成功;

若是,则将业务应用产生的日志数据写入所述共享内存队列中已使用的共享内存空间尾部。

进一步地,日志收集装置通过处理器1001调用存储器1005中存储的日志收集程序,还执行以下操作:

通过日志采集代理从所述共享内存队列中已使用的共享内存空间头部拷贝日志数据;

根据拷贝的日志数据的长度,修改所述第二偏移量参数的参数值;

将拷贝的日志数据转发至后端日志收集服务。

进一步地,日志收集装置通过处理器1001调用存储器1005中存储的日志收集程序,还执行以下操作:

通过日志采集代理的代理进程,从所述共享内存队列读取日志数据;

根据日志数据的类型,将读取的日志数据传输至对应的转发进程;

通过转发进程将日志数据转发至后端日志收集服务,其中,所述转发进程采用微线程方式转发日志数据。

基于上述日志收集装置的硬件运行环境,提成本发明日志收集方法的以下各实施例。

共享内存(sharedmemory)是一种进程间的通信机制,共享内存允许两个或多个进程可以直接共享访问同一块内存区域。也即通过共享内存可用于传递消息,进而实现多进程间通信。而共享内存队列具体指以队列形式使用共享内存,进而利用共享内存实现进程间传递消息的消息队列。

共享内存允许多个进程使用某一块内存区域,因而数据不需要在进程之间复制,多个进程都把该内存区域映射到自己的虚拟地址空间,直接访问该共享内存区域,从而可以通过共享内存区域进行通信,实现较高的读写性能。

因此,相比基于磁盘文本文件的日志收集方式,本发明基于共享内存的日志收集方式可以避免由于磁盘读写性能下降而对业务服务的影响,同时还可以避免在业务持续高负载的情况下,由于磁盘本身读写性能交底而导致日志采集代理过载,进而致使业务日志丢失的问题。

此外,采用队列形式使用共享内存,由于队列中数据遵循先进先出,因而使用共享内存队列既能便于管理多进程写入数据,同时也能实现日志数据的时序性。

参照图2,图2为本发明日志收集方法一实施例的流程示意图。本实施例中,所述日志收集方法包括以下步骤:

步骤s10,通过前端业务应用的业务进程调用日志采集api,将业务应用产生的日志数据写入共享内存队列;

本实施例中,预先创建一共享内存队列,以供存储采集的日志数据。例如,预先在业务应用所运行的设备上开辟一块内存区域作为共享内存以创建共享内存队列。

为进一步提升数据读写性能,本实施例中,日志收集装置并未创建新的进程来采集数据,而是直接使用前端业务应用的业务进程来采集本业务应用所产生的日志数据。

本实施例中,日志收集装置优选通过业务进程调用预先定义的日志采集接口(applicationprogramminginterface,api)来采集自身业务应用所产生的日志数据,并将采集的日志数据写入共享内存队列。

可选的,为进一步提升日志采集性能,每一业务应用中都集成有日志采集api,进而便于业务应用直接调用。

步骤s20,通过日志采集代理从所述共享内存队列读取日志数据,并将日志数据转发至后端日志收集服务。

本实施例中,由于后端日志收集服务需要收集前端所有业务应用产生的日志数据,因此,还需进一步通过日志采集代理从共享内存队列读取日志数据,并将日志数据转发至后端日志收集服务。

本实施例中,日志采集代理既可以部署在业务应用运行的设备上,也可以部署在其他设备上。日志采集代理采用agent技术,agent是指处于一定环境下包装的计算实体,agent能在该环境下灵活自主的活动,比如本实施例中日志采集代理能自动读取日志数据并进行转发。

如图3所示,本实施例中,位于前端业务应用与后端日志采集代理之间的共享内存队列,前端业务应用的业务进程向共享内存队列写入日志数据,而后端日志采集代理的代理进程从共享内存队列读取数据,也即实现了业务进程与代理进程之间的通信。

本实施例基于共享内存队列采集日志,通过前端业务应用的业务进程调用日志采集api,将业务应用产生的日志数据写入共享内存队列,而通过日志采集代理从共享内存队列读取日志数据,然后将读取的日志数据转发至后端日志收集服务,从而实现日志收集。由于共享内存队列支持多进程通信,因而可提升日志采集的性能,避免日志采集代理过载而导致日志丢失,保证了日志数据采集的稳定性与安全性。

进一步地,参照图4,图4为本发明日志收集方法中共享内存队列一实施例的结构示意图。

本实施例中,共享内存队列的头部设有用于标记所述共享内存队列中已使用的共享内存空间范围的第一偏移量参数与第二偏移量参数;

(1)tailoffset:第一偏移量参数,用于标识当前已使用的共享内存空间尾部相对于起始地址的偏移量,以确定当前已使用的共享内存空间尾部位置;

(2)headoffset:第二偏移量参数,用于标识当前已使用的共享内存空间头部相对于起始地址的偏移量,以确定当前已使用的共享内存空间头部位置。

(3)tailcursor:共享内存队列尾部游标,用于标识当前已使用的共享内存空间尾部,只存在于逻辑上,由tailoffset确定;

(4)headcursor:共享内存队列头部游标,用于标识当前已使用的共享内存空间头部,只存在于逻辑上,由headoffset确定;

(5)usedshm:共享内存队列中已使用的共享内存空间;

(6)unusedshm:共享内存队列中未使用的共享内存空间。

基于以上共享内存队列的结构特征,对日志数据的写入与读取过程分别进行说明。

参照图5,图5为图2中步骤s10一实施例的流程示意图。基于上述实施例,本实施例中,上述步骤s10进一步还包括:

步骤s101,通过前端业务应用的业务进程调用日志采集api,对所述共享内存队列进行cas操作,以根据待写入的日志数据的长度,修改所述第一偏移量参数的参数值;

步骤s102,判断所述第一偏移量参数的参数值是否修改成功;

步骤s103,若是,则将业务应用产生的日志数据写入所述共享内存队列中已使用的共享内存空间尾部;否则继续对共享内存队列进行cas操作。

本实施例中,由于向队列写入数据是从尾部插入数据,因此,在向共享内存队列写入时需要修改第一偏移量参数tailoffset。另外,由于前端存在多个业务进程并发写入日志的情况,因此本实施例采用cas机制,通过cas原子操作来修改共享内存队列的tailoffset参数值。

在向共享内存队列写入日志数据之前,业务进程调用日志采集api,先尝试用cas机制修改tailoffset参数值,若tailoffset参数值修改成功,则表示日志数据可以写入共享内存队列,然后将日志数据拷贝到共享内存队列尾部。

如图6所示,例如,假设待写入的日志数据长度为3k,原headoffset参数值为0k、原tailoffset参数值为10k,业务进程调用日志采集api采用cas机制对共享内存队列进行cas操作并成功将tailoffset参数值修改为13k,则将当前3k长度的日志数据写入共享内存队列的尾部。

cas操作(compareandswap,比较并替换)是一种cpu指令层面的原子操作,可用于实现各种无锁的数据结构。cas操作包含有以下3个基本操作参数:内存地址v、旧的预期值a和要修改的新值b。当更新一个变量时,只有当变量的预期值a和内存地址v当中的实际值相同时,才会将内存地址v对应的值修改为b。

本实施例采用cas操作更新共享内存队列的tailoffset参数值,可以实现高并发无锁队列操作,提升数据写入的操作效率。需要说明的是,如果一次cas操作失败,也即没有成功修改tailoffset参数值,则需要继续对共享内存队列进行cas操作直至成功修改tailoffset参数值。

参照图7,图7为图2中步骤s20一实施例的流程示意图。基于上述实施例,本实施例中,上述步骤s20进一步还包括:

步骤s201,通过日志采集代理从所述共享内存队列中已使用的共享内存空间头部拷贝日志数据;

步骤s202,根据拷贝的日志数据的长度,修改所述第二偏移量参数的参数值;

步骤s203,将拷贝的日志数据转发至后端日志收集服务。

与向共享内存队列尾部写入数据类似,本实施例从共享内存队列头部读取数据同样需要修改headoffset参数值,本实施例优选先通过日志采集代理从共享内存队列头部拷贝日志数据,然后再修改headoffset参数值,以避免待拷贝的日志数据可能被修改,保证读取的日志数据的准确性。

如图8所示,例如,假设待读取的日志数据长度为3k,原headoffset参数值为0k、原tailoffset参数值为10k;日志采集代理先从共享内存队列头部拷贝3k长度的日志数据,然后修改将headoffset参数值修改为3k。需要说明的是,由于日志采集代理的进程是单进程读取,也即不存在进程并发竞争的问题,因此,从共享内存队列读取数据没有使用cas机制。

本实施例从共享内存队列读取日志数据,相较于从磁盘文件中读取日志数据,效率更高,且保证了日志数据采集的稳定性与安全性。

进一步地,由于后端日志收集服务需要收集前端所有业务应用产生的日志数据,因此,日志采集代理还需进一步将日志数据转发至后端日志收集服务。为提升日志数据的转发性能,因此优选采用微线程方式转发日志数据,以实现数据的高并发转发。

参照图9,图9为图2中步骤s20另一实施例的流程示意图。本实施例中,上述步骤s20进一步包括:

步骤s204,通过日志采集代理的代理进程,从所述共享内存队列读取日志数据;

本实施例对于从共享内存队列读取日志数据的实现方式不限,优选采用上述实施例中先通过日志采集代理从共享内存队列头部拷贝日志数据,然后再修改headoffset参数值的方式读取日志数据。

步骤s205,根据日志数据的类型,将读取的日志数据传输至对应的转发进程;

步骤s206,通过转发进程将日志数据转发至后端日志收集服务,其中,所述转发进程采用微线程方式转发日志数据。

本实施例中,日志采集代理设有代理进程以及多个转发进程,不同转发进程转发不同类型的日志数据,并采用微线程方式实现日志数据的高并发转发。

如图10所示,日志采集代理agent设有dataproxy代理进程,以及还设有多个worker转发进程,代理进程与各转发进程之间优选通过管道pipe(一种进程或线程间的通信方式)传输日志数据。dataproxy代理进程统一从无锁共享内存队列读取日志数据,然后根据日志数据的类型,将不同类型的日志数据通过管道pipe传输至不同的worker转发进程处理,而worker转发进程则负责将日志数据转发给下后端日志收集服务。

本实施例中,转发进程采用微线程方式转发日志数据,从而可实现数据的高并发转发,提升了日志数据的读取性能多转发进程具有较高的可扩展性。

本发明还提供一种计算机可读存储介质。

本实施例中,计算机可读存储介质上存储有日志收集程序,所述日志收集程序被处理器执行时实现如上述任一项实施例中所述的日志收集方法的步骤。

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如rom/ram)中,包括若干指令用以使得一台终端(可以是手机,计算机,服务器或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述,但是本发明并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本发明的启示下,在不脱离本发明宗旨和权利要求所保护的范围情况下,还可做出很多形式,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,这些均属于本发明的保护之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1