日志汇总方法、装置、电子设备及存储介质与流程

本公开涉及计算机技术领域，具体而言，涉及一种日志汇总方法、日志汇总装置、计算机可读存储介质以及电子设备。

背景技术：

日志是记录设备系统中硬件、软件和系统问题的信息，同时还可以监视设备系统中发生的事件。因此，当设备系统发生错误时，可以通过登录服务器查看日志以定位具体问题。对于分布式服务器，需要通过登录所有服务器汇总日志来统一定位，即通过建设日志平台来查看日志。

现有技术中，日志合并技术elk(elasticsearch、logstash、kibana，日志分析平台)不仅可以收集日志还能对其进行大数据分析。但是，本地搭建elk成本较高，而且需要额外配置网络环境。另外，在日志汇总后，使用elk查看日志时需要再次筛选才能达到查询目标日志的目的。

因此，为了降低在本地调试时查看日志的复杂度，提供一种日志汇总方法以提高查看日志的效率是非常必要的。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

本公开的目的在于提供一种日志汇总方法、日志汇总装置、计算机可读存储介质以及电子设备。所述方法通过将日志进行排序汇总以降低开发者在本地调试时查看日志的复杂度，从而提高查看日志的效率。

根据本公开的第一方面，提供一种日志汇总方法，包括：

监听多个日志文件以获取所述日志文件的增量日志；

以多线程方式将所述增量日志发送至日志队列；

以单线程方式将所述日志队列中过滤后的增量日志进行排序；

以多线程方式将所述排序后的增量日志发送到写文件线程；

在所述写文件线程中，通过异步写文件生成更新后的日志文件并进行存储。

在本公开的一种示例性实施例中，所述监听多个日志文件以获取所述日志文件的增量日志，包括：

通过循环读文件的方式监听多个日志文件以获取所述日志文件的增量日志。

在本公开的一种示例性实施例中，所述以多线程方式将所述增量日志发送至日志队列，包括：

以一个日志文件对应一个线程的方式将所述增量日志发送至日志队列并进行存储。

在本公开的一种示例性实施例中，所述将所述增量日志发送至日志队列后，所述方法还包括：

根据预设日志过滤规则以对所述增量日志进行过滤。

在本公开的一种示例性实施例中，所述以单线程方式将所述日志队列中过滤后的增量日志进行排序，包括：

以单线程方式将所述日志队列中过滤后的增量日志按时间维度进行排序。

在本公开的一种示例性实施例中，所述以多线程方式将所述排序后的增量日志发送到写文件线程，包括：

批量拉取所述排序后的增量日志；

以多线程方式将所述拉取的增量日志排序输出到写文件线程。

在本公开的一种示例性实施例中，所述以多线程方式将所述拉取的增量日志排序输出到写文件线程，包括：

以多线程方式将所述拉取的增量日志自增的后缀名输出到写文件线程。

在本公开的一种示例性实施例中，所述在所述写文件线程中，通过异步写文件生成更新后的日志文件并进行存储，包括：

根据所述增量日志的后缀名通过异步写文件生成更新后的日志文件；

将所述更新后的日志文件的文件名存储到本地。

在本公开的一种示例性实施例中，所述方法还包括：

读取指定目录的日志文件，并判断是否在本地存储的已完成写文件的集合中，如果存在已完成写文件集合中则将所述更新后的日志文件输出到控制台，并高亮显示所述更新后的日志文件中的指定内容以进行展示。

根据本公开的第二方面，提供一种日志汇总装置，包括：

监听模块，用于监听多个日志文件以获取所述日志文件的增量日志；

第一发送模块，用于以多线程方式将所述增量日志发送至日志队列；

排序模块，用于以单线程方式将所述日志队列中过滤后的增量日志进行排序；

第二发送模块，以多线程方式将所述排序后的增量日志发送到写文件线程；

存储模块，用于在所述写文件线程中，通过异步写文件生成更新后的日志文件并进行存储。

根据本公开的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的方法。

根据本公开的第四方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的方法。

本公开示例性实施例可以具有以下部分或全部有益效果：

在本公开的一示例实施方式所提供的日志汇总方法中，通过监听多个日志文件以线程组合的方式将日志进行排序汇总。一方面，通过本公开所述线程组合方式汇总日志的效率更高，进一步提高开发者查看日志的效率。另一方面，将日志进行排序汇总使得在查看多个微服务日志时无需来回切换控制台以及翻页查询指定日志，并且通过在日志汇总过程中按时间维度进行排序，查询时只需要按顺序查看日志文件即可，降低开发者查看日志的时间成本。将所有微服务日志进行汇总后，输出到本地控制台时，无需考虑跨网络读取日志文件的权限问题，降低开发者在本地调试微服务程序时查看日志的复杂度。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1示出了可以应用本公开实施例的一种日志汇总方法及装置的示例性系统架构的示意图；

图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图；

图3示意性示出了根据本公开的一个实施例的日志汇总方法的流程图；

图4示意性示出了根据本公开的一个实施例的日志汇总方法的步骤的流程图；

图5示意性示出了根据本公开的一个具体实施例的日志汇总方法的流程图；

图6示意性示出了根据本公开的一个实施例的日志汇总装置的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图1示出了可以应用本公开实施例的一种日志汇总方法及装置的示例性应用环境的系统架构的示意图。

如图1所示，系统架构100可以包括服务器101、102、103和104中的一个或多个，通过服务器101、102和103获取微服务的日志文件，将所述日志文件中的日志进行汇总发送到服务器104。应所述理解，图1中的服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的服务器。比如服务器101可以是多个服务器组成的服务器集群等。本公开实施例所提供的日志汇总方法一般由服务器104执行，相应地，日志汇总装置一般设置于服务器104中。

图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图2示出的电子设备的计算机系统200仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图2所示，计算机系统200包括中央处理单元(cpu)201，其可以根据存储在只读存储器(rom)202中的程序或者从存储部分208加载到随机访问存储器(ram)203中的程序而执行各种适当的动作和处理。在ram203中，还存储有系统操作所需的各种程序和数据。cpu201、rom202以及ram203通过总线204彼此相连。输入/输出(i/o)接口205也连接至总线204。

以下部件连接至i/o接口205：包括键盘、鼠标等的输入部分206；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分207；包括硬盘等的存储部分208；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至i/o接口205。可拆卸介质211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器210上，以便于从其上读出的计算机程序根据需要被安装入存储部分208。

特别地，根据本公开的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，所述计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，所述计算机程序可以通过通信部分209从网络上被下载和安装，和/或从可拆卸介质211被安装。在所述计算机程序被中央处理单元(cpu)201执行时，执行本申请的方法和装置中限定的各种功能。

作为另一方面，本申请还提供了一种计算机可读介质，所述计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入所述电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个所述电子设备执行时，使得所述电子设备实现如下述实施例中所述的方法。例如，所述的电子设备可以实现如图3至图5所示的各个步骤等。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，所述程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，所述计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

以下对本公开实施例的技术方案进行详细阐述：

近年来，分布式服务蓬勃发展，并且已经成为业界主流技术。分布式服务将单体应用程序拆分为多个应用程序，每个应用程序集群又部署了多台服务器做负载均衡，多个应用程序可以实现多种功能从而完成不同的业务。其中，如果某项业务发生系统错误，开发或者运维人员以单体应用程序的方式登录一台服务器查看日志已无法定位到具体问题，而是需要通过登录所有服务器将日志进行汇总来统一定位。其中，日志是指网络设备、系统及服务程序等，在运作时都会产生log(日志)事件记录，所述事件记录称作日志，每一行日志都记载着日期、时间、使用者及动作等相关操作的描述。由此可知，日志平台建设尤为重要。

在日志合并技术elk(elasticsearch、logstash、kibana，日志分析平台)中，通过logstash(开源数据收集引擎)收集每台服务器的日志文件，按定义的正则模板过滤所述日志文件后将其传输到kafka(分布式日志系统)或redis(存储系统)。由另一个logstash从所述kafka或redis中读取日志并存储到elasticsearch(开源搜索引擎)中创建索引。最后通过kibana(开源分析和可视化平台)展示给开发者或运维人员进行分析。

当开发者在本地开发时，会在本地开发环境中启用多个微服务以开启调试模式，通过依次查询所述微服务来查看日志，而无法将日志统一汇总后进行查看。另外，即使可以通过日志合并技术elk将日志进行汇总，但是，本地搭建elk成本较高，需要在本地搭建logstash、es集群以及kibana可视化界面。如果使用测试环境已搭建好的elk集群，要考虑本地与测试环境的网络是否通畅，是否需要额外配置一些网络环境等，还需要确保能熟练使用logstash配置日志监听等。此外，使用elk查看日志，需要在日志汇总之后再通过筛选时间段或者某个关键字达到查询目标日志的目的。由此可知，开发者在本地调试时使用elk查看日志的流程较复杂。

基于上述一个或多个问题，本示例实施方式提供了一种日志汇总方法，所述方法可以应用于上述服务器104，参考图3所示，所述日志汇总方法可以包括以下步骤s310至步骤s350：

步骤s310.监听多个日志文件以获取所述日志文件的增量日志。

步骤s320.以多线程方式将所述增量日志发送至日志队列。

步骤s330.以单线程方式将所述日志队列中过滤后的增量日志进行排序。

步骤s340.以多线程方式将所述排序后的增量日志发送到写文件线程。

步骤s350.在所述写文件线程中，通过异步写文件生成更新后的日志文件并进行存储。

在本示例实施方式所提供的日志汇总方法中，通过监听多个日志文件以线程组合的方式将日志进行排序汇总。一方面，通过本公开所述线程组合方式汇总日志的效率更高，进一步提高开发者查看日志的效率。另一方面，将日志进行排序汇总使得在查看多个微服务日志时无需来回切换控制台以及翻页查询指定日志，并且通过在日志汇总过程中按时间维度进行排序，查询时只需要按顺序查看日志文件即可，降低开发者查看日志的时间成本。将所有微服务日志进行汇总后，输出到本地控制台时，无需考虑跨网络读取日志文件的权限问题，降低开发者在本地调试微服务程序时查看日志的复杂度。

下面，对于本示例实施方式的上述步骤进行更加详细的说明。

在步骤s310中，监听多个日志文件以获取所述日志文件的增量日志。

本示例实施方式中，首先，开发者可以在本地开发环境中启用多个微服务以开启调试模式。微服务是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制进行通信。通过多个微服务用户可以配置多个日志文件，日志文件是记录操作系统或其他软件运行中发生的事件或通信软件中不同用户之间的消息的文件，包括事件日志和消息日志。其中，事件日志可以记录系统执行过程中发生的事件，以便提供可用于理解系统活动和诊断问题的检查的跟踪。

其次，可以配置高亮显示的日志内容，如将指定关键字进行高亮显示，以方便开发者查找目标日志。以及可以预设日志过滤规则，用户可以根据日志内容自定义日志过滤规则，例如，过滤“mobile”字段相关的日志。也可以通过比较日志级别来控制日志输出，例如，过滤掉debug日志。过滤规则还可以包含日志登记的规则，例如，登记顺序为并发事务执行的时间顺序。预设日志规则通过日志过滤可以显示特定类型事件的记录，同样可以方便开发者查找目标日志。因此，日志过滤，高亮日志等功能可以提高查看日志的效率，有助于开发者提高开发效率。

然后，开发者可以启动程序，根据用户获取的日志文件做监听。获取日志文件的同时，可以获取日志文件的相关信息，如日志文件的创建时间、大小、路径等。因此，在一种示例实施方式中，可以通过循环读文件的方式监听多个日志文件以获取所述日志文件的增量日志，循环读文件是按预设的时间周期多次读取日志文件。例如，读取文件a.txt，第一次读取之后记录文件读取的位置，可以在1分钟后进行第二次读取文件并以上一次读取的位置为起始位置。对每个微服务增量产生的日志进行监听，监听得到的日志文件包含原始日志和增量日志，从而可以及时掌握日志变化情况。

一种示例实施方式中，还可以通过flume(日志收集系统)监听日志文件。flume是一个分布式日志采集、聚合和传输系统。flume的结构主要分为三部分：source(源头)、channel(通道)以及sink(目的地)。其中，source负责采集日志；channel负责传输和暂时储存；sink将采集到的日志进行保存。因此，可以通过flume的spoolingdirectorysource(假脱机目录源)对所有日志文件进行监听，具体是通过source部分监听获取的日志文件，如果有增量日志产生时，将其读取并传入配置的channel部分，利用sink部分从channel部分不断读取增量日志以实现增量日志的同步获取。

在步骤s320中，以多线程方式将所述增量日志发送至日志队列。

本示例实施方式中，可以以单线程方式将增量日志发送至日志队列，也可以以多线程方式将增量日志发送至日志队列。线程是操作系统里能够进行运算调度得最小单位，是程序中一个单一的顺序控制流程。其中，单线程是指程序按连续顺序进行执行和排序，即处理完当前增量日志后再处理下一个增量日志，而多线程是指在单个程序中同时运行多个线程完成不同的任务，从而提高程序的效率。同样，采用多线程方式可以使增量日志的传输效率更高。另外，可以通过继承thread类(线程类)方法来创建多线程，通过定义thread类的子类，并重写所述类的run方法，创建子类的实例，即创建了线程对象，调用线程对象的start方法来启动所述线程。另外，也可以通过实现runable接口(线程辅助类)或实现callable接口(线程辅助类)方法来创建多线程。

具体的，可以以一个日志文件对应一个线程的方式将上述增量日志同时发送至日志队列并进行存储，这种方式下增量日志的传输效率更高。也可以以多个日志文件对应一个线程的方式发送增量日志，本示例实施方式中不做限定。所述日志队列是将消息队列应用在日志处理中，其中，消息队列(messagequeue)为应用程序之间传递的信息载体。消息队列技术是分布式应用间交换信息的一种技术，消息队列可驻留在内存或磁盘上，队列存储消息直到其被应用程序读走。另外，多线程之间也可以同步发送增量日志，即线程b需要等待线程a执行methoda方法完以后才能执行methodb，即共享内存。

举例而言，日志队列可以是jvm(javavirtualmachine，java虚拟机)服务器自带的队列。例如，可以是arraylist(可变长度的数组)队列，arraylist底层使用object类型(基类，对象类型)的数组来存放数据。还可以是concurrentqueue(并发队列)队列，队列遵循先进先出的特征。当日志文件数据量大时，也可以将各个微服务产生的增量日志发送到kafka分布式队列进行消息传递和分发，然后从所述队列中拉取消息进行分析处理。

将上述增量日志发送到日志队列后，按照用户配置的自定义过滤规则将其进行过滤。在一种示例实施方式中，可以按日志登记规则进行过滤，登记日志文件时遵循两个原则：一是登记的次序严格按事务执行的时间次序；二是先写数据库，后写日志文件。由此可知，根据所述日志登记规则过滤增量日志以便将其进行排序。

在步骤s330中，以单线程方式将所述日志队列中过滤后的增量日志进行排序。

本示例实施方式中，可以按日志登记的规则将增量日志进行过滤，因此，过滤得到的增量日志也可以是按时间维度排序，并且排序过程可以以单线程方式进行。单线程是指程序按连续顺序进行执行和排序，即处理完当前增量日志后再处理下一个增量日志，从而实现所述增量日志的统一排序，开发者在查询时只需要按顺序查看日志文件即可，降低开发者查看日志的时间成本。另外，也可以自定义顺序进行排序，例如，字母日志先于数字日志，字母日志按字母顺序排序，先按内容排序，再按标识符排序。

在步骤s340中，以多线程方式将所述排序后的增量日志发送到写文件线程。参考图4所示，本示例实施方式中可以通过下述步骤s410以及步骤s420发送所述排序后的增量日志。其中：

在步骤s410中，批量拉取所述排序后的增量日志。

示例性的，可以采用mq(messagequeue，消息队列)消息处理服务器从所述日志队列批量拉取所述增量日志，例如，可以采用集群方式，采用多个mq消息处理服务器进行批量拉取。

在步骤s420中，以多线程方式将所述拉取的增量日志排序输出到写文件线程。

一种示例实施方式中，可以从arraylist队列中批量拉取，每个线程可以分别选取n条增量日志，可以以单线程方式排序输出到写文件线程，也可以多线程方式排序输出到写文件线程以写文件，相对于以单线程方式输出增量日志，采用多线程方式耗时更短，因此，传输增量日志的效率更高。其中，通过多线程方式发送增量日志时，所述增量日志的顺序会被打乱。

但是，如果同时输出所述增量日志自增的文件后缀名给写文件线程，所述后缀名是在通过多线程输出到写文件线程中分配给各个线程时指定的，因此，所述后缀名也是按时间顺序排序的，从而可以通过后缀名来区分增量日志的顺序。

在步骤s350中，在所述写文件线程中，通过异步写文件生成更新后的日志文件并进行存储。

本示例实施方式中，可以以n条增量日志为一组数据，一组数据对应一个写文件线程以多线程方式来写文件。具体可以根据增量日志的后缀名进行异步写文件，生成更新后的日志文件包括原始日志和增量日志，因此，在本示例实施方式中，可以达到实时获取日志的效果，保证了汇总日志文件的时效性。其中，异步写文件指按顺序读取所有增量日志后再写文件。可以将写完的日志文件的文件名输出并存储到本地已完成写文件的集合中。如果有后期检索的需求也可以将其存储到mysql数据库中，本实施例对此不做限定。

一开始可以对指定目录的日志文件进行统一排序汇总，汇总后可以读取所述指定目录的日志文件。所述日志文件包括正在写入的日志文件和已写完的日志文件，可以将已写完的日志文件进行展示。因此，需要判断所述汇总完的日志文件是否在本地存储的已完成写文件的集合中，写文件线程会将写完的日志文件的文件名进行缓存并存储到本地已完成写文件的集合中，如果所述日志文件的文件名存在已完成写文件集合中则将所述更新后的日志文件输出到控制台，并高亮显示所述更新后的日志文件中的指定内容以进行展示。输出完成后删除所述日志文件并且同时在已完成文件的集合中将其移除。

参考图5所示，为本示例实施方式中方法的一个具体应用举例。其中，在步骤s511中，启用多个微服务获取多个日志文件，图5中的日志文件的数目仅仅是示意性的。根据实现需要，可以具有任意数目的日志文件；在步骤s512中，监听每个日志文件写入的增量日志；在步骤s513中，将多个增量日志发送到增量消息队列中；在步骤s514中，多个线程中同时选取n条数据，即选取n条增量日志；在步骤s515中，将每个线程中的n条增量日志排序输出到文件，该文件是由写文件线程中根据增量日志的后缀名通过异步写文件生成的。在步骤s516中，因为可以通过增量日志自增的后缀名以达到区分所述增量日志顺序的目的，所以将所述增量日志自增的后缀名输出。然后，读取指定目录的日志文件，并判断是否在已完成写文件的集合中，如果存在已完成写文件集合中则将更新后的日志文件输出到控制台，并高亮显示指定内容以进行展示。输出完成后删除所述日志文件并且同时在已完成写文件的集合中将其移除。通过本示例实施方式中的方法，可以在本地开发时将所有的微服务日志汇总输出到本地控制台，降低开发者在本地调试微服务程序时查看日志的复杂度。

在本公开的一示例实施方式所提供的日志汇总方法中，通过监听多个日志文件以线程组合的方式将日志进行排序汇总。一方面，通过本公开所述线程组合方式汇总日志的效率更高，进一步提高开发者查看日志的效率。另一方面，将日志进行排序汇总使得在查看多个微服务日志时无需来回切换控制台以及翻页查询指定日志，并且通过在日志汇总过程中按时间维度进行排序，查询时只需要按顺序查看日志文件即可，降低开发者查看日志的时间成本。将所有微服务日志进行汇总后，输出到本地控制台时，无需考虑跨网络读取日志文件的权限问题，降低开发者在本地调试微服务程序时查看日志的复杂度。

应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照所述特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

进一步的，本示例实施方式中，还提供了一种日志汇总装置，所述装置可以应用于一服务器104。参考图6所示，所述日志汇总装置600可以包括监听模块610、第一发送模块620、排序模块630、第二发送模块640以及存储模块650。其中：

监听模块610，用于监听多个日志文件以获取所述日志文件的增量日志；

第一发送模块620，用于以多线程方式将所述增量日志发送至消息队列；

排序模块630，用于以单线程方式将所述日志队列中过滤后的增量日志进行排序；

第二发送模块640，用于以多线程方式将所述排序后的增量日志发送到写文件线程；

存储模块650，用于接收由所述目标设备发送的第二密文，所述第二密文通过所述第一密钥加密日志得到；

上述日志汇总装置中各模块的具体细节已经在对应的日志汇总方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。