CN106095864A - 一种日志处理系统及方法 - Google Patents

Abstract

本发明公开了一种日志处理系统及方法，其中，该系统包括：系统主控单元、网络通讯单元、日志处理单元、日志存储单元；其中，网络通讯单元，与系统主控单元、日志处理单元通信连接，用于系统主控单元与日志处理单元之间的交互通信、数据传输；日志处理单元，用于周期性地发送任务请求信息至系统主控单元，接收系统主控单元发送的任务信息，根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元；系统主控单元，用于接收任务请求信息、任务处理结果，向日志处理单元发送任务信息；日志存储单元，用于存储处理后的日志。

Description

一种日志处理系统及方法

技术领域

本发明涉及数据采集领域，更具体地，尤指一种日志处理系统及方法。

背景技术

在目前的企业应用系统中，日志数据作为其中不可缺少的组成部分，能帮助企业解决系统维护、安全监控、故障排除、用户行为分析等诸多问题。在另一领域，大数据革命正如火如荼地进行着，给传统行业的市场竞争带来全新的挑战。目前，网银、电商等众平台都将大数据挖掘技术应用到海量日志信息的分析洞察中，获得了广阔的应用空间。

每天，都有大量日志文件在应用服务器上生成，大数据挖掘技术需要将这些日志收集、汇总后再进行分析挖掘。然而面对复杂多变的应用环境，日志收集和存储的问题日益严重：首先，采集工作量巨大，已知待采集的日志分散在数目众多的服务器中，而这些服务器又分布于全国各地不同数据中心，采集目标多且分散；其次，网络带宽要求高，在日志生成的高峰时段，每小时总量可高达上百G，部分日志必须经过广域网远距离传输，给网络带宽造成压力；第三，系统可靠性要求高，由于采集任务复杂，若其中一个服务器节点运行崩溃或者发生通讯故障，将导致日志丢失或缺漏；第四，存储要求高，由于目标日志数量巨大，单节点的存储系统已无法满足海量日志的存储和管理。

因此，现有日志采集技术在采集、传输、可靠性、存储等方面有待改进和提高，亟需一种高效、可靠的日志采集系统。

发明内容

为解决现有技术中难以远程多点采集日志数据的难题，降低系统运维成本，本发明提出了一种日志处理系统及方法，该系统及方法借鉴了分布式处理的设计思想，部署多台工作服务器，开启多任务模式同时进行日志采集、传输等工作。同时，为提高日志的采集效率，本发明的日志处理系统及方法可根据企业应用系统的日志生成的规模和复杂性灵活、就近部署工作服务器，并对采集的日志进行批量压缩，从而减轻传输带宽压力；为加强系统运行的健壮性和稳定性，本发明通过定期监控系统工作节点的运行心跳，发现故障时系统启动“自愈”流程介入处理；为保证日志数据的正确性和完整性，本发明在打包和传输过程中引入MD5完整性校验机制，加强日志数据远程传输的可靠性；为满足海量数据的存储需求，本发明的日志存储系统采用Hadoop文件系统，对后续海量日志数据的挖掘分析工作提供了便利。

具体的，本发明提出的日志处理系统包括：系统主控单元、网络通讯单元、日志处理单元、日志存储单元；其中，网络通讯单元，与系统主控单元、日志处理单元通信连接，用于系统主控单元与日志处理单元之间的交互通信、数据传输；日志处理单元，用于周期性地发送任务请求信息至系统主控单元，接收系统主控单元发送的任务信息，根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元；系统主控单元，用于接收任务请求信息、任务处理结果，向日志处理单元发送任务信息；日志存储单元，用于存储处理后的日志。

本发明还提出了一种日志处理方法，该方法包括：步骤S1，系统主控单元按照预设规则生成任务信息，保存至任务列表；步骤S2，日志处理单元周期性地发送任务请求信息至系统主控单元；步骤S3，系统主控单元在接收到任务请求信息后，根据任务列表，判断是否有匹配日志处理单元的任务，如果没有，则以RPC请求的方式发送任务查找失败信息至日志处理单元，执行步骤S4，如果有，则以RPC请求的方式发送任务信息至日志处理单元，执行步骤S5；步骤S4，日志处理单元等待一定时间后，继续周期性地发送任务请求信息至系统主控单元，返回步骤S3；步骤S5，日志处理单元根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元。

本发明提出的日志处理系统及方法能够满足大型企业对海量数据的自动化采集需求，为数据传输提供了一条高效、可靠的通道，为用户提供了智能化、高可用的日志采集平台，简化采集工作量，提高工作效率。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1为本发明一实施例的日志处理系统结构示意图。

图2为本发明另一实施例的日志处理系统的结构示意图。

图3为本发明一实施例的应用场景示意图。

图4为本发明一实施例的日志数据的点对点传输流程图。

图5为本发明一实施例的日志处理方法流程图。

图6为本发明一实施例的失败任务自动重试的流程图。

图7为本发明一实施例的单点故障自动恢复的流程图。

具体实施方式

以下配合图示及本发明的较佳实施例，进一步阐述本发明为达成预定发明目的所采取的技术手段。

以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图1为本发明一实施例的日志处理系统结构示意图。如图1所示，该系统包括：系统主控单元100、网络通讯单元200、日志处理单元300、日志存储单元400；其中，

网络通讯单元200，与系统主控单元100、日志处理单元300通信连接，用于系统主控单元100与日志处理单元300之间的交互通信、数据传输；其采用RPC(Remote ProcedureCall)协议完成网络通讯功能。RPC技术采用客户端/服务器模式，通过网络向远程计算器端请求服务。因其屏蔽了底层网络技术信息，使得系统的网络通讯更加容易。

日志处理单元300，用于周期性地发送任务请求信息至系统主控单元100，接收系统主控单元100发送的任务信息，根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元400，并发送任务处理结果至系统主控单元100。

系统主控单元100，用于接收任务请求信息、任务处理结果，向日志处理单元300发送任务信息。

具体的，系统主控单元100用于保障整个日志处理系统的正常运行，工作内容包括：定期根据现有信息以及相关规则生成各类日志任务，任务包括日志采集、打包、传输、入库；其基于RPC通信方式同部署在各地的日志服务器进行通讯，接收任务请求并及时分发位于同一数据中心的任务；基于心跳机制监控各个应用单元，及时恢复发生单点故障的组件的正常工作，确保整个系统正常对外提供服务；基于容错机制分析接收各日志处理单元对于任务完成情况的反馈，对于失败的任务采取重试策略。

日志存储单元400，用于存储处理后的日志。

进一步的，结合图2所示，为本发明另一实施例的日志处理系统的结构示意图。该系统还包括：系统备用控制单元500，其中，日志处理单元300具体包括：日志采集模块301、日志打包模块302、日志传输模块303、日志入库模块304。

在图2中，双向箭头表示控制指令的交互，单向箭头表示日志数据流向。该系统采用Master/Slave架构，在整个系统中，两股信息流(控制指令流和日志数据流)的流动实现了系统各单元的连接。控制指令流通过网络通讯单元200使系统主控单元100与日志采集模块301、日志打包模块302、日志传输模块303和日志入库模块304信息交互。

日志采集模块301，用于周期性地向系统主控单元100发起日志采集请求，在获得系统主控单元100发送的采集指令后，启动日志采集线程；采集线程通过FTP协议将位于企业应用服务器的日志数据拉取至采集打包服务器磁盘中；在采集任务结束后，将采集结果反馈至所述系统主控单元100。

日志打包模块302，用于周期性地向系统主控单元100发起日志打包请求，在获得系统主控单元100发送的打包指令后，启动日志打包线程；打包线程使用预设的压缩算法及转码方式，用于将同一批次的日志进行合并压缩打包，并在打包过程中动态地计算打包文件的MD5值；日志打包后的打包文件存放于采集打包服务器磁盘中，在打包任务结束后，将打包结果和打包文件的MD5值反馈至系统主控单元100。

其中，MD5算法是一种信息摘要算法，输入任意长度的信息可计算得到128位的信息摘要。两个不同信息生成相同报文摘要的几率极小，本实施例采用MD5技术用于检验文件在运输过程中是否发生变化。

日志传输模块303，周期性地向系统主控单元100发起日志传输请求，在获得系统主控单元100发送的传输指令后，启动日志传输线程；传输线程通过FTP协议将位于采集打包服务器的日志压缩包运送至传输入库服务器磁盘中，传输过程中动态地计算日志压缩包得的MD5值，并与系统主控单元100存储的打包文件的MD5值比对，进行完整性校验；在传输任务结束后，将完整性校验结果反馈至系统主控单元100。

日志入库模块304，用于周期性地向系统主控单元100发起日志入库请求，在获得系统主控单元100发生的入库指令后，启动日志入库线程；入库线程将日志压缩包上传至日志存储单元400，在入库任务结束后将入库结果反馈给系统主控单元100。

综上所述，日志采集模块301通过FTP协议将位于企业应用服务器的日志数据拉取至本地服务器磁盘中；日志打包模块302使用给定的压缩算法及转码方式，负责将同一批次的日志进行合并压缩打包，并在打包过程中动态地计算文件的MD5值用于后续完整性校验，打包日志存储于本地服务器磁盘中；日志传输模块303通过FTP协议将位于各地的日志压缩包运送至本地服务器磁盘中，传输过程中动态地计算MD5值并与之前的MD5值比对，进行完整性校验；日志入库模块304将压缩后的日志数据上传至日志存储单元400。

在本实施例中，进一步结合图2所示，该系统还可以设置有一系统备用控制单元500，其具有与系统主控单元100一致的功能，当系统主控单元100发生故障时，系统备用控制单元500代替系统主控单元100工作，负责保障整个日志处理系统的正常运行。主、备控制单元的切换依赖于开源产品ZooKeeper提供服务，系统主控单元100在正常启动后会在ZooKeeper数据中建立临时节点，系统备用控制单元500则监控该临时节点。若系统主控单元100发生故障停止运行，ZooKeeper会接收感知自动删除临时节点，同时通知系统备用控制单元500接替系统主控单元100工作。由于系统备用控制单元500作为系统主控单元100的备机，仅在主机故障时激活运行，所以下文中以系统主控单元100为系统控制单元进行叙述。

在本实施例中，所述系统主控单元100，还用于根据任务处理结果判断任务是否成功完成；

如果任务结果的反馈为成功，系统主控单元100将已完成的任务从任务列表中去除，并记录任务完成时间、处理后日志数据存放位置以及文件大小，当已完成的任务为日志打包任务时，还记录MD5值；记录的信息用于提供系统主控单元100生成新的任务信息；

如果任务结果的反馈为失败，系统主控单元100记录任务处理的失败次数，并根据任务的不同类型，采取相应的处理方法；

当日志采集任务或日志传输任务失败时，系统主控单元100根据任务已失败的次数与失败次数阈值进行比较；

如果已失败的次数小于失败次数阈值，系统主控单元100将失败任务放回任务列表；

如果已失败的次数达到失败次数阈值，系统主控单元100放弃失败任务；

当日志打包任务或日志入库任务失败时，系统主控单元100将失败任务指派给同一日志处理单元300进行重复处理，直至任务成功。

进一步的，日志处理单元300，还用于定期向系统主控单元300发送心跳信息，表示正常工作；当日志处理单元300工作不正常时，停止心跳信息发送；

所述系统主控单元100，还用于监控日志处理单元300的心跳信息，判断是否收到日志处理单元300发送的心跳信息；

当在一预设时间内未收到心跳信息，系统主控单元100将故障的日志处理单元300进行重启，并将正在执行的任务重置于任务队列；其中，

如果为日志采集任务或日志传输任务，系统主控单元100查找另一满足处理要求的日志采集模块301或日志传输模块303，并将任务进行重新分配；

如果为日志打包任务或日志入库任务，等待相应的日志打包模块302或日志入库模块304自动恢复并向系统主控单元100申请任务，由系统主控单元100指派任务。

为了对上述日志处理系统进行更为清楚的解释，下面结合一个应用场景的实施例来进行说明，然而值得注意的是该实施例仅是为了更好地说明本发明，并不构成对本发明不当的限定。

结合图3所示，为本发明一实施例的应用场景示意图。其中，日志采集系统在分布式环境下的不属于各个服务器中。此分布式日志采集平台主要运行在基于TCP/IP通信协议的以太网局域网中，多个局域网基于VPN通信协议构建一个统一的企业内联网。系统中运行的日志服务器根据功能不同可分为主控服务器11、备用控制服务器12、采集打包服务器13、传输入库服务器14、日志存储服务器15。在具体生产环境中，日志服务器的操作系统以UNIX、Linux为主。

其中，图2所示的系统主控单元100、日志采集模块301、日志打包模块302、日志传输模块303、日志入库模块304、日志存储单元400、系统备用控制单元500以程序进程的方式运行在对应服务器上。

主控服务器11，配置有系统主控单元100，提供日志任务管理、应用组件监控、单点故障恢复等服务，保障整个日志采集系统的正常运行。具体的，主控服务器11定期根据现有信息生成各类日志任务，任务包括日志采集、打包、传输、入库；基于RPC通信方式同部署在各地的日志服务器进行通讯，接收任务请求并及时分发位于符合匹配条件的任务；基于心跳机制监控各个应用单元，及时恢复发生单点故障的组件的正常工作，确保整个系统正常对外提供服务；基于容错机制分析接收各日志处理单元对于任务完成情况的反馈，对于失败的任务采取重试策略。

备用控制服务器12，配置有系统备用控制单元500，其功能与主控服务器11相同，用于在主控服务器11发生故障时，代替其进行工作。

日志采集打包服务器13，整合日志采集模块301和日志打包模块302，负责采集所在区域的日志数据，并将日志数据压缩以减轻日志存储和传输成本。具体的，日志采集打包服务器13中含有日志采集模块301和日志打包模块302，分别周期性地向主控服务器发起申请任务的请求；日志采集模块301在获得主控服务器11派发的采集指令后，基于FTP协议进行将位于企业应用服务器的日志数据“拉取”至本地服务器；日志打包模块302在获得主控服务器11派发的打包指令后，将位于本地服务器的多个日志采用GZ算法进行合并压缩和转码，并动态地计算日志压缩包的MD5值；日志采集模块301和日志打包模块302在任务执行结束后，分别将任务结果以及相关信息返回给主控服务器11。

日志传输入库服务器14，整合日志传输模块303和日志入库模块304，负责将日志采集打包服务器13的日志数据传输至本地服务器磁盘，定期归总上传至日志存储服务器15。具体的，日志传输入库服务器14中含有日志传输模块303和日志入库模块304，分别周期性地向主控服务器11发起申请任务的请求；日志传输模块303在获得主控服务器11派发的传输指令后，将位于各地的日志压缩包运送至本地服务器，有些日志压缩包与传输服务器不在同一区域则需要跨越广域网传输；日志传输模块303传输过程中会动态地计算传输数据的MD5值，与数据打包时获取的MD5值比对，进行完整性校验；日志入库模块304在获得主控服务器11派发的入库指令后，将位于本地服务器的日志压缩包上传至日志存储服务器15；日志传输模块303和日志入库模块304在任务执行结束后，分别将任务结果以及相关信息返回给主控服务器11。

日志存储服务器15，配置有日志存储单元400，提供日志数据的存储和访问服务。若干台日志存储服务器15构成一个日志存储系统，对后续海量日志数据的挖掘分析工作提供了便利。

由上述默认配置方案可知，日志采集模块301和日志打包模块302、日志传输模块303和日志入库模块304必须联合部署在一台服务器中。

进一步的，根据企业应用系统的日志采集作业规模和复杂性，本实施例的日志处理系统中的各类处理单元可遵循“灵活配置”的原则整合在服务器中。例如，在工作压力较小的前提下，也可在单台设备中集中配置采集、打包、传输、入库四个模块。此外，系统主控单元100既可独立配置在单台服务器中，也可在服务器资源紧张的情况下作为附加单元部署在日志采集打包服务器或日志传输入库服务器之上。该系统在部署策略上还遵循了“负载均衡”的原则，在局域网内合理安排每一类服务器的数目，系统中每台服务器都能得到合适的工作量，避免服务器配置过少导致的单台服务器负荷过重，同时也规避了服务器配置过多导致的服务器资源浪费。

再结合图3所示，在本实施例中，一共有2个独立的数据中心16，数据中心16内部分别部署了若干日志采集打包服务器13，用于收集同一数据中心内的日志数据。处于灾备的目的，大型企业在数据集中化建设时通常会建立多个分布式数据中心，彼此之间可并行工作，可独立地为企业业务提供服务。在数据中心16的运维管理上，多个数据中心16实现资源的有机整合和共享，在宏观上可视为一个负载均衡的全局数据中心。

总部17内部部署了主控服务器11、备用控制服务器12、日志采集打包服务器13、日志传输入库服务器14以及日志存储服务器15。其中，系统主控服务器11和日志传输入库服务器14根据工作需求，可跨越广域网与其他数据中心16的日志采集打包服务器13进行通讯；总部17的日志采集打包服务器13只用于采集位于总部内的日志数据；日志存储服务器15用于集中存储和管理来自总部和数据中心的所有应用日志。总部17在一定意义上也属于数据中心的概念，由于在本实施例中，总部17部署了主控服务器11，其能调度其它数据中心16的日志采集打包服务器13正常工作，在工作职责上具有比数据中心16更多的权限，因此此处将其与其它数据中心16的名称区别，称之为“总部”。

结合图4所示，为本发明一实施例的日志数据的点对点传输流程图。无论是日志采集模块301在同一局域网内向企业服务器收集原始日志数据，还是日志传输模块303向各地采集打包服务器13汇总日志压缩包，其中都涉及了服务器交互连接以及数据文件的点对点传输，本系统采用FTP协议用于信息传输。FTP服务使用客户端/服务器工作模式，本发明中提供FTP服务的计算机称为服务器端，向服务器拉取数据的计算机为客户端，FTP服务器与客户端通过TCP进行链接。如图4所示，具体步骤包括：

步骤S401，服务器端等待客户端发出链接请求。

步骤S402，客户端首先发起建立与FTP服务器的控制链接，通过该TCP链接发送用户名和密码给服务器端。

具体的，客户端的日志处理单元在获取系统主控单元派发的任务时，可解析得到目标服务器的IP地址信息以及用户名和密码。

步骤S403，客户端为所在的数据链接选择一个临时的端口号，并通过控制链接将该端口号发送给服务器。

步骤S404，客户端建立与FTP服务器的数据链接，进入文件传输阶段。

具体的，客户端的日志处理单元从任务信息中获取目标服务器的日志路径，进行文件读取和传输。

步骤S405，客户端一次读取既定量的数据，根据不同的任务对这部分数据进行不同的处理，随后客户端继续不断地发起读取数据的请求，直到数据传输完毕。

具体的，在传输任务中，传输线程一次读到既定量(本发明设置为1MB)的数据，立即将这部分数据进行MD5值的计算；在采集任务中，采集线程读取既定量的数据后不做任何处理。

步骤S406，判断读取是否完毕，如果读取未完成，返回步骤S405，如果读取完毕，执行步骤S407。

步骤S407，当数据传输完毕后，关闭数据链接。

基于同一发明构思，本发明实施例中还提供了一种日志处理方法，如下面的实施例所述。由于该方法解决问题的原理与上述系统相似，因此该方法的实施可以参见上述系统的实施，重复之处不再赘述。

图5为本发明一实施例的日志处理方法流程图。如图5所示，该方法包括：

步骤S1，系统主控单元按照预设规则生成任务信息，保存至任务列表。

步骤S2，日志处理单元周期性地发送任务请求信息至系统主控单元。

步骤S3，系统主控单元在接收到任务请求信息后，根据任务列表，判断是否有匹配日志处理单元的任务，如果没有，则以RPC请求的方式发送任务查找失败信息至日志处理单元，执行步骤S4，如果有，则以RPC请求的方式发送任务信息至日志处理单元，执行步骤S5。

具体的，系统主控单元收到任务请求，首先解析任务处理的类型，并根据类型找到匹配的任务列表。系统主控单元遍历任务列表，按照一定的匹配算法查看是否有满足条件的任务。若任务为采集，系统主控单元判断任务列表中某个任务的区域编号是否与申请信息中提供的区域编号一致，若是则认为该任务满足匹配条件；若任务为打包、入库，系统主控单元判断任务列表中某个任务的服务器地址信息是否与申请信息中提供的服务器地址信息一致，若是则认为该任务满足匹配条件；若任务为传输且任务列表若非空，系统主控单元认为任务列表的第一个任务满足匹配条件。

步骤S4，日志处理单元等待一定时间后，继续周期性地发送任务请求信息至系统主控单元，返回步骤S3。

步骤S5，日志处理单元根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元。

在步骤S1中，任务信息包括：日志采集任务、日志打包任务、日志传输任务和日志入库任务。

具体的，在生成日志采集任务时，系统主控单元会根据数据库中的待采集日志的企业服务器的相关信息生成日志采集任务；日志采集任务的信息包括：企业应用服务器所在区域编号、企业应用服务器的地址信息、企业应用服务器存放日志的文件池路径以及日志采集后的存放路径。

在生成日志打包任务时，系统主控单元分析每台采集打包服务器上已采日志的累计增量，在既定时间内，日志累计增量达到预设的数据量或者在既定时间之后日志累计量没有到达预设量时，系统主控单元将累计的日志组织为一个批次，生成日志打包任务；日志打包任务的信息包括：待打包日志所在区域编号，待打包日志所在服务器地址信息、待打包日志的文件路径列表，日志打包后的存放路径。

在生成日志传输任务时，系统主控单元分析每一台采集打包服务器中新生成的日志压缩包的增量生成日志传输任务；日志传输任务的信息包括：待传输日志所在服务器地址信息、待传输日志的文件路径，日志传输后的存放路径。

在生成日志入库任务时，系统主控单元分析每个传输入库服务器的日志数据的增量生成日志入库任务；日志传输任务的信息包括：待入库日志所在服务器地址信息、待入库日志的文件路径，日志在存储系统的存放路径。

在步骤S5中，日志处理单元根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元，包括：

当日志处理单元接收到日志采集任务时，启动日志采集线程；该采集线程通过FTP协议将位于企业应用服务器的日志数据拉取至采集打包服务器磁盘中；在采集任务结束后，将采集结果反馈至所述系统主控单元。

当日志处理单元接收到日志打包任务时，启动日志打包线程；该打包线程使用预设的压缩算法及转码方式，用于将同一批次的日志进行合并压缩打包，并在打包过程中动态地计算打包文件的MD5值；日志打包后的打包文件存放于采集打包服务器磁盘中，在打包任务结束后，将打包结果和打包文件的MD5值反馈至系统主控单元。

当日志处理单元接收到日志传输任务时，启动日志传输线程；该传输线程通过FTP协议将位于采集打包服务器的日志压缩包运送至传输入库服务器磁盘中，传输过程中动态地计算日志压缩包得的MD5值，并与系统主控单元存储的打包文件的MD5值比对，进行完整性校验；在传输任务结束后，将完整性校验结果反馈至系统主控单元。

当日志处理单元接收到日志入库任务时，启动日志入库线程；该入库线程将日志压缩包上传至日志存储单元，在入库任务结束后将入库结果反馈给系统主控单元。

结合图6所示，为本发明一实施例的失败任务自动重试的流程图。如图6所示，该步骤包括：

步骤S501，日志处理单元在日志处理结束后，向系统主控单元反馈处理结果。

具体的，通过任务为传输或入库，仅需反馈任务完成时间和处理结果(成功、失败)；若任务为采集，还需额外反馈采集到的日志大小；若任务为打包，需额外反馈打包得到的MD5值。

步骤S502，系统主控单元根据任务处理结果判断任务是否成功完成；如果任务结果的反馈为成功，执行步骤S503，如果任务结果的反馈为失败，执行步骤S504。

步骤S503，系统主控单元将已完成的任务从任务列表中去除，并记录任务完成时间、处理后日志数据存放位置以及文件大小，当已完成的任务为日志打包任务时，还记录MD5值；记录的信息用于提供系统主控单元生成新的任务信息。

步骤S504，系统主控单元记录任务处理的失败次数，并根据任务的不同类型，采取相应的处理方法，称其为“失败重试机制”。

步骤S505，系统主控单元判断任务类型，当日志采集任务或日志传输任务失败时，执行步骤S506，当日志打包任务或日志入库任务失败时，执行步骤S507。

步骤S506，系统主控单元根据任务已失败的次数与失败次数阈值进行比较，如果已失败的次数小于失败次数阈值，执行步骤S508，如果已失败的次数达到失败次数阈值，执行步骤S509。

步骤S507，当日志打包任务或日志入库任务失败时，系统主控单元将失败任务指派给同一日志处理单元进行重复处理，直至任务成功。

步骤S508，系统主控单元将失败任务放回任务列表；

具体的，当其它日志处理单元向系统主控单元申请任务时，系统主控单元将符合匹配条件的该任务指派给该日志处理单元。

步骤S509，系统主控单元放弃失败任务，不再处理。

结合图7所示，为本发明一实施例的单点故障自动恢复的流程图。如图7所示，该步骤包括：

步骤S511，日志处理单元定期向系统主控单元发送心跳信息，表示正常工作；当日志处理单元工作不正常时，停止心跳信息发送。

具体的，日志处理单元会定时地通过RPC请求向系统主控单元发送心跳，表明该单元正常工作。

步骤S512，系统主控单元监控日志处理单元的心跳信息，判断是否收到日志处理单元发送的心跳信息，当在一预设时间内收到心跳信息，执行步骤S513，当在一预设时间内未收到心跳信息，执行步骤S514。

步骤S513，系统主控单元保持继续监控。

步骤S514，系统主控单元将故障的日志处理单元进行重启，并将正在执行的任务重置于任务队列。具体的，系统主控单元通过SSH协议对故障单元进程进行重启。重启后，故障进程会自动与主控进程进行一次握手通讯，之后又会自动加入集群中继续工作，在整个恢复过程中完全不需要人工干预。对于故障发生时未完成的任务，系统主控单元将该任务重置于任务列表。

其中，如果为日志采集任务或日志传输任务，系统主控单元查找另一满足处理要求的日志采集模块或日志传输模块，并将任务进行重新分配；

如果为日志打包任务或日志入库任务，等待相应的日志打包模块或日志入库模块自动恢复并向系统主控单元申请任务，由系统主控单元指派任务。

本发明提出的日志处理系统及方法包含以下优点：

1、在数据的采集方式上，该系统采用了主动拉取的模式，规避日志高峰时段无法及时处理主动推送到来的数据而引发的各种风险，同时在采集过程中也会通过流量控制企业服务器业务系统的影响。

2、在数据的运输方式上，该系统利用GZ算法将数据进行压缩打包并采用MD5协议加入完整性校验环节，既减少网络带宽的压力，又保证数据的完整性。

3、在系统部署方式上，该系统适用于拥有多个数据中心的大型企业的日志采集工作，根据每个数据中心的企业应用系统的规模和复杂性，可灵活部署日志系统服务器的数量，保证服务器资源的合理使用。

4、在日志任务的处理方式上，采取了并行处理的策略，可支持多个节点的并行日志收集和处理，系统中所有任务对主控服务器的任务请求以及任务内部的处理过程都是独立的，保证了整个系统的运行稳定性。

5、在系统健壮性设计上，秉承“故障是一种常态”的设计思路，使系统具备一种对故障的“自愈”能力，在提高系统可用性的同时，也大大降低了运维时人工干预的工作量。

综上所述，本发明提出的日志处理系统及方法能够满足大型企业对海量数据的自动化采集需求，为数据传输提供了一条高效、可靠的通道，为用户提供了智能化、高可用的日志采集平台，简化采集工作量，提高工作效率。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (21)

1.一种日志处理系统，其特征在于，该系统包括：系统主控单元、网络通讯单元、日志处理单元、日志存储单元；其中，

网络通讯单元，与系统主控单元、日志处理单元通信连接，用于系统主控单元与日志处理单元之间的交互通信、数据传输；

日志处理单元，用于周期性地发送任务请求信息至系统主控单元，接收系统主控单元发送的任务信息，根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元；

系统主控单元，用于接收任务请求信息、任务处理结果，向日志处理单元发送任务信息；

日志存储单元，用于存储处理后的日志。

2.根据权利要求1所述的日志处理系统，其特征在于，所述日志处理单元包括：日志采集模块、日志打包模块、日志传输模块、日志入库模块。

3.根据权利要求2所述的日志处理系统，其特征在于，所述日志采集模块，用于周期性地向系统主控单元发起日志采集请求，在获得系统主控单元发送的采集指令后，启动日志采集线程；在采集任务结束后，将采集结果反馈至所述系统主控单元。

4.根据权利要求3所述的日志处理系统，其特征在于，所述采集线程通过FTP协议将位于企业应用服务器的日志数据拉取至采集打包服务器磁盘中。

5.根据权利要求2所述的日志处理系统，其特征在于，所述日志打包模块，用于周期性地向系统主控单元发起日志打包请求，在获得系统主控单元发送的打包指令后，启动日志打包线程；日志打包后的打包文件存放于采集打包服务器磁盘中，在打包任务结束后，将打包结果和打包文件的MD5值反馈至系统主控单元。

6.根据权利要求5所述的日志处理系统，其特征在于，所述打包线程使用预设的压缩算法及转码方式，用于将同一批次的日志进行合并压缩打包，并在打包过程中动态地计算打包文件的MD5值。

7.根据权利要求5所述的日志处理系统，其特征在于，所述日志传输模块，周期性地向系统主控单元发起日志传输请求，在获得系统主控单元发送的传输指令后，启动日志传输线程；该传输线程通过FTP协议将位于采集打包服务器的日志压缩包运送至传输入库服务器磁盘中，传输过程中动态地计算日志压缩包得的MD5值，并与系统主控单元存储的打包文件的MD5值比对，进行完整性校验；在传输任务结束后，将完整性校验结果反馈至系统主控单元。

8.根据权利要求2所述的日志处理系统，其特征在于，所述日志入库模块，用于周期性地向系统主控单元发起日志入库请求，在获得系统主控单元发生的入库指令后，启动日志入库线程；该入库线程将日志压缩包上传至日志存储单元，在入库任务结束后将入库结果反馈给系统主控单元。

9.根据权利要求1所述的日志处理系统，其特征在于，该系统还包括：系统备用控制单元，与系统主控单元功能相同，当系统主控单元发生故障时启动，代替系统主控单元工作。

10.根据权利要求2所述的日志处理系统，其特征在于，所述系统主控单元，还用于根据任务处理结果判断任务是否成功完成；

如果任务结果的反馈为成功，系统主控单元将已完成的任务从任务列表中去除，并记录任务完成时间、处理后日志数据存放位置以及文件大小，当已完成的任务为日志打包任务时，还记录MD5值；记录的信息用于提供系统主控单元生成新的任务信息；

如果任务结果的反馈为失败，系统主控单元记录任务处理的失败次数，并根据任务的不同类型，采取相应的处理方法；

当日志采集任务或日志传输任务失败时，系统主控单元根据任务已失败的次数与失败次数阈值进行比较；

如果已失败的次数小于失败次数阈值，系统主控单元将失败任务放回任务列表；

如果已失败的次数达到失败次数阈值，系统主控单元放弃失败任务；

当日志打包任务或日志入库任务失败时，系统主控单元将失败任务指派给同一日志处理单元进行重复处理，直至任务成功。

11.根据权利要求2所述的日志处理系统，其特征在于，所述日志处理单元，还用于定期向系统主控单元发送心跳信息，表示正常工作；当日志处理单元工作不正常时，停止心跳信息发送；

所述系统主控单元，还用于监控日志处理单元的心跳信息，判断是否收到日志处理单元发送的心跳信息；

当在一预设时间内未收到心跳信息，系统主控单元将故障的日志处理单元进行重启，并将正在执行的任务重置于任务队列；其中，

如果为日志采集任务或日志传输任务，系统主控单元查找另一满足处理要求的日志采集模块或日志传输模块，并将任务进行重新分配；

如果为日志打包任务或日志入库任务，等待相应的日志打包模块或日志入库模块自动恢复并向系统主控单元申请任务，由系统主控单元指派任务。

12.一种日志处理方法，其特征在于，该方法包括：

步骤S1，系统主控单元按照预设规则生成任务信息，保存至任务列表；

步骤S2，日志处理单元周期性地发送任务请求信息至系统主控单元；

步骤S3，系统主控单元在接收到任务请求信息后，根据任务列表，判断是否有匹配日志处理单元的任务，如果没有，则以RPC请求的方式发送任务查找失败信息至日志处理单元，执行步骤S4，如果有，则以RPC请求的方式发送任务信息至日志处理单元，执行步骤S5；

步骤S4，日志处理单元等待一定时间后，继续周期性地发送任务请求信息至系统主控单元，返回步骤S3；

步骤S5，日志处理单元根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元。

13.根据权利要求12所述的日志处理方法，其特征在于，在步骤S1中，任务信息包括：日志采集任务、日志打包任务、日志传输任务和日志入库任务。

14.根据权利要求13所述的日志处理方法，其特征在于，在步骤S1中，系统主控单元按照预设规则生成任务信息，保存至任务列表，包括：

在生成日志采集任务时，系统主控单元会根据数据库中的待采集日志的企业服务器的相关信息生成日志采集任务；

在生成日志打包任务时，系统主控单元分析每台采集打包服务器上已采日志的累计增量，在既定时间内，日志累计增量达到预设的数据量或者在既定时间之后日志累计量没有到达预设量时，系统主控单元将累计的日志组织为一个批次，生成日志打包任务；

在生成日志传输任务时，系统主控单元分析每一台采集打包服务器中新生成的日志压缩包的增量生成日志传输任务；

在生成日志入库任务时，系统主控单元分析每个传输入库服务器的日志数据的增量生成日志入库任务。

15.根据权利要求14所述的日志处理方法，其特征在于，日志采集任务的信息包括：企业应用服务器所在区域编号、企业应用服务器的地址信息、企业应用服务器存放日志的文件池路径以及日志采集后的存放路径；

日志打包任务的信息包括：待打包日志所在区域编号，待打包日志所在服务器地址信息、待打包日志的文件路径列表，日志打包后的存放路径；

日志传输任务的信息包括：待传输日志所在服务器地址信息、待传输日志的文件路径，日志传输后的存放路径；

日志传输任务的信息包括：待入库日志所在服务器地址信息、待入库日志的文件路径，日志在存储系统的存放路径。

16.根据权利要求14所述的日志处理方法，其特征在于，在步骤S5中，日志处理单元根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元，包括：

当日志处理单元接收到日志采集任务时，启动日志采集线程；该采集线程通过FTP协议将位于企业应用服务器的日志数据拉取至采集打包服务器磁盘中；在采集任务结束后，将采集结果反馈至所述系统主控单元。

17.根据权利要求14所述的日志处理方法，其特征在于，在步骤S5中，日志处理单元根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元，包括：

当日志处理单元接收到日志打包任务时，启动日志打包线程；该打包线程使用预设的压缩算法及转码方式，用于将同一批次的日志进行合并压缩打包，并在打包过程中动态地计算打包文件的MD5值；日志打包后的打包文件存放于采集打包服务器磁盘中，在打包任务结束后，将打包结果和打包文件的MD5值反馈至系统主控单元。

18.根据权利要求14所述的日志处理方法，其特征在于，在步骤S5中，日志处理单元根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元，包括：

当日志处理单元接收到日志传输任务时，启动日志传输线程；该传输线程通过FTP协议将位于采集打包服务器的日志压缩包运送至传输入库服务器磁盘中，传输过程中动态地计算日志压缩包得的MD5值，并与系统主控单元存储的打包文件的MD5值比对，进行完整性校验；在传输任务结束后，将完整性校验结果反馈至系统主控单元。

19.根据权利要求14所述的日志处理方法，其特征在于，在步骤S5中，日志处理单元根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元，包括：

当日志处理单元接收到日志入库任务时，启动日志入库线程；该入库线程将日志压缩包上传至日志存储单元，在入库任务结束后将入库结果反馈给系统主控单元。

20.根据权利要求14所述的日志处理方法，其特征在于，在步骤S5中，日志处理单元根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元，包括：

步骤S501，日志处理单元在日志处理结束后，向系统主控单元反馈处理结果；

步骤S502，系统主控单元根据任务处理结果判断任务是否成功完成；如果任务结果的反馈为成功，执行步骤S503，如果任务结果的反馈为失败，执行步骤S504；

步骤S503，系统主控单元将已完成的任务从任务列表中去除，并记录任务完成时间、处理后日志数据存放位置以及文件大小，当已完成的任务为日志打包任务时，还记录MD5值；记录的信息用于提供系统主控单元生成新的任务信息；

步骤S504，系统主控单元记录任务处理的失败次数，并根据任务的不同类型，采取相应的处理方法；

步骤S505，系统主控单元判断任务类型，当日志采集任务或日志传输任务失败时，执行步骤S506，当日志打包任务或日志入库任务失败时，执行步骤S507；

步骤S506，系统主控单元根据任务已失败的次数与失败次数阈值进行比较，如果已失败的次数小于失败次数阈值，执行步骤S508，如果已失败的次数达到失败次数阈值，执行步骤S509；

步骤S507，当日志打包任务或日志入库任务失败时，系统主控单元将失败任务指派给同一日志处理单元进行重复处理，直至任务成功；

步骤S508，系统主控单元将失败任务放回任务列表；

步骤S509，系统主控单元放弃失败任务。

21.根据权利要求14所述的日志处理方法，其特征在于，在步骤S5中，日志处理单元根据任务信息对日志进行相应处理，将处理后的日志存储至日志存储单元，并发送任务处理结果至系统主控单元，包括：

步骤S511，日志处理单元定期向系统主控单元发送心跳信息，表示正常工作；当日志处理单元工作不正常时，停止心跳信息发送；

步骤S512，系统主控单元监控日志处理单元的心跳信息，判断是否收到日志处理单元发送的心跳信息，当在一预设时间内收到心跳信息，执行步骤S513，当在一预设时间内未收到心跳信息，执行步骤S514；

步骤S513，系统主控单元保持继续监控；

步骤S514，系统主控单元将故障的日志处理单元进行重启，并将正在执行的任务重置于任务队列；其中，

如果为日志采集任务或日志传输任务，系统主控单元查找另一满足处理要求的日志采集模块或日志传输模块，并将任务进行重新分配；

如果为日志打包任务或日志入库任务，等待相应的日志打包模块或日志入库模块自动恢复并向系统主控单元申请任务，由系统主控单元指派任务。