CN114356718A - 日志处理方法、介质、系统和计算设备 - Google Patents

Abstract

本公开的实施方式提供了一种日志处理方法、介质、系统和计算设备。该方法应用于计算集群，所述计算集群包括计算节点，所述计算节点用于运行计算任务，所述计算任务对应至少一个计算进程，所述计算节点包括日志信息输出服务和上传组件，所述方法包括：所述日志信息输出服务将所述计算进程产生的日志以日志文件的形式输出至本地磁盘；所述日志信息输出服务在捕捉到所述计算进程的退出事件时，将所述日志文件的后缀更新为用于指示所述计算进程结束的后缀标识，得到目标日志文件；所述上传组件响应于监听到所述本地磁盘中生成所述目标日志文件，向存储集群上传所述目标日志文件。实现了Spark运行在Kubernetes上时的计算任务日志的收集。

Description

日志处理方法、介质、系统和计算设备

技术领域

本公开的实施方式涉及计算机技术领域，更具体地，本公开的实施方式涉及一种日志处理方法、介质、系统和计算设备。

背景技术

本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

Apache Spark是一种支持大规模数据处理的高效的计算引擎，可以用于构建大型的、低延迟的数据分析应用程序，支持包括文本处理、机器学习等计算的处理。

当Spark运行在Kubernetes的节点上时，通过Kubernetes的节点的资源可以实现Spark的各个计算任务的处理。由于Kubernetes的节点在任务处理完成后会被删除，计算任务的日志不能进行集中的管理。因此，需要提供一种方案，以实现Spark运行在Kubernetes上时的计算任务日志的收集。

发明内容

本公开提供一种日志处理方法、介质、系统和计算设备，以实现Spark运行在Kubernetes上时的计算任务日志的收集。

在本公开实施方式的第一方面中，提供了一种日志处理方法，应用于计算集群，所述计算集群包括计算节点，所述计算节点用于运行计算任务，所述计算任务对应至少一个计算进程，所述计算节点包括日志信息输出服务和上传组件，所述方法包括：

所述日志信息输出服务将所述计算进程产生的日志以日志文件的形式输出至本地磁盘；所述日志信息输出服务在捕捉到所述计算进程的退出事件时，将所述日志文件的后缀更新为用于指示所述计算进程结束的后缀标识，得到目标日志文件；

所述上传组件响应于监听到所述本地磁盘中生成所述目标日志文件，向存储集群上传所述目标日志文件。

在本公开实施方式的第二方面中，提供了一种日志处理系统，应用于计算集群，所述计算集群包括计算节点，所述计算节点用于运行计算任务，所述计算任务对应至少一个计算进程，所述计算节点包括日志信息输出服务和上传组件，所述日志处理系统包括：

所述日志信息输出服务，用于将所述计算进程产生的日志以日志文件的形式输出至本地磁盘；所述日志信息输出服务在捕捉到所述计算进程的退出事件时，将所述日志文件的后缀更新为用于指示所述计算进程结束的后缀标识，得到目标日志文件；

所述上传组件，用于响应于监听到所述本地磁盘中生成所述目标日志文件，向存储集群上传所述目标日志文件。

在本公开实施方式的第三方面中，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序指令，所述计算机程序指令被执行时，实现如第一方面中任一项所述的日志处理方法。

在本公开实施方式的第四方面中，提供了一种计算设备，包括：存储器和处理器；

所述存储器用于存储程序指令；

所述处理器用于调用所述存储器中的程序指令执行如第一方面中任一项所述的日志处理方法。

本公开实施例提供的日志处理方法、介质、系统和计算设备，应用于计算集群，计算集群中包括计算节点，计算节点用于运行计算任务，计算任务对应至少一个计算进程，当计算进程运行在计算节点上时，日志信息输出服务会将计算进程产生的日志以日志文件的形式输出至本地磁盘，并在捕捉到计算进程的退出事件时，将日志文件的后缀更新为用于指示计算进程结束的后缀标识，得到目标日志文件。由于日志信息输出服务是在计算进程将要退出时对日志文件的后缀进行更新的，因此得到的目标日志文件中包括计算进程运行产生的完整的日志。上传组件在监听到本地磁盘中生成了目标日志文件后，向存储集群上传目标日志文件，从而能够将计算进程产生的日志进行完整的收集，完整收集的目标日志文件有利于帮助定位计算进程中产生的问题，节省计算进程开发和运维的成本。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：

图1为本公开实施例提供的应用场景示意图；

图2为本公开实施例提供的日志处理方法的流程示意图；

图3为本公开实施例提供的一种日志处理系统的示意图；

图4为本公开实施例提供的一种日志文件列表示意图；

图5为本公开实施例提供的存储目标日志文件示意图一；

图6为本公开实施例提供的存储目标日志文件示意图二；

图7为本公开实施例提供的确定待删除日志文件夹的示意图；

图8为本公开实施例提供的历史日志查看示意图；

图9为本公开实施例提供的当前运行计算进程的日志查看示意图；

图10为本公开实施例提供的存储介质的示意图；

图11为本公开实施例提供的日志处理系统的结构示意图；

图12为本公开实施例提供的计算设备的结构示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施方式，提出了一种日志处理方法、介质、装置和计算设备。

在本文中，需要理解的是，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

首先，对本公开涉及的基本概念进行介绍。

Apache Spark：是一种支持大规模数据处理的高效且通用的计算引擎，可以用于构建大型的、低延迟的数据分析应用程序，支持包括SQL查询、文本处理、机器学习等计算。

Kubernetes：是一个开源的、用于管理云平台中多个主机上的容器化的应用，使得部署容器化的应用简单且高效，Kubernetes提供了应用部署、规划、更新、维护的机制。其中，容器(Container)：和虚拟机相似，也是计算机系统的仿真器，由于容器之间底层共享操作系统，所以相对于虚拟机来说，更加的轻量化。

Kubernetes Pod：是Kubernetes创建或部署的最小的计算单元，一个Pod代表集群上正在运行的一个进程。Pod所建模的是特定于应用的“逻辑主机”，其中包含一个或多个容器，这些容器相对紧密的耦合在一起。

Kubernetes DaemonSet：DaemonSet确保指定计算节点(默认为全部)上运行一个Pod，当有Pod出现异常时，会立马启动相同的Pod进行替代。当有新的计算节点加入计算集群时，也会为新加入的计算节点新增一个Pod。

Log4j：一种由Apache开源的，帮助控制日志信息输出的项目。

Spark History Server：历史服务器，一个Apache Spark内部维护的开源模块，用于展示完成任务的各项信息，便于监控计算任务的完成情况。

Spark UI：进程界面，一个Apache Spark内部维护的开源模块，用于展示进行中的任务的各项信息，便于监听计算任务的运行情况。

Spark on Yarn：Spark程序运行在Yarn集群之上，由Yarn集群进行资源的管理和调度。

Spark on Kubernetes：Spark程序运行在Kubernetes集群之上，由Kubernetes集群进行资源的管理和调度。

Yarn：Apache Hadoop YARN(Yet Another Resource Negotiator，另一种资源协调者)是一种新的Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度。

Apache Commons-IO：Apache Commons IO是Apache开源的一个工具包，其封装了对IO的常见操作，使开发人员只需要少量的代码就能完成大量的IO操作。

HDFS：Hadoop分布式文件系统(HDFS)是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统(Distributed File System)。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。

Flume：是一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方(可定制)的能力。

下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。

发明概述

当Spark运行在Yarn上时，Yarn作为资源管理器，在运行Spark程序的同时，会收集Spark计算进程产生的日志，并提供给Spark History Server展示。

本发明人发现，当Spark运行在Kubernetes上时，Spark计算进程产生的日志并不能向Spark运行在Yarn上一样被收集，并通过Spark History Server进行查看。在Kubernetes中缺乏对Spark计算进程产生的日志进行收集、管理和展示的功能。当Spark运行在Kubernetes上，Spark计算任务产生的日志如果不被持久化，则当Spark计算任务结束、对应的Pod结束时会被删除。即使Spark计算任务产生的日志通过挂载本地磁盘的方式被持久化，各个计算任务产生的日志也会分散在Kubernetes的各个计算节点上，不能集中进行管理，不利于开发和运维通过日志对计算任务进行问题的定位。

在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。

应用场景总览

首先参考图1对本公开的应用场景进行介绍。

图1为本公开实施例提供的应用场景示意图，如图1所示，包括计算集群11和存储集群12，计算集群11中包括Kubernetes的各个计算节点(图1中示例了3个)，分别是计算节点13、计算节点14和计算节点15。

Spark可以运行在Kubernetes上，例如在图1中，计算节点13上正在运行Spark-163的计算任务，计算节点14上正在运行Spark-164的计算任务，计算节点15上正在运行Spark-165的计算任务，每个计算任务中可能包括一个或多个计算进程。

当计算进程在计算节点上运行时，会产生相应的日志。对任意一个计算进程而言，计算进程在运行的过程中会持续产生日志，在计算进程运行结束后停止产生日志。计算进程产生的日志首先会存储在计算节点的本地磁盘上，例如，Spark-163的计算任务下的计算进程运行时产生的日志首先存储在计算节点13的本地磁盘上，Spark-164的计算任务下的计算进程运行时产生的日志首先存储在计算节点14的本地磁盘上，Spark-165的计算任务下的计算进程运行时产生的日志首先存储在计算节点15的本地磁盘上。

在计算进程运行结束之后，可以将本地磁盘中存储的该计算进程的日志上传至存储集群，从而实现Spark运行在Kubernetes上的日志的收集，也能够将分散在Kubernetes的各个计算节点上的日志集中存储到存储集群进行统一的管理。

示例性方法

下面结合图1的应用场景，参考图2来描述根据本公开示例性实施方式的日志处理方法。需要注意的是，上述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。

图2为本公开实施例提供的日志处理方法的流程示意图，该方法应用于计算集群，计算集群中包括计算节点，计算节点用于运行计算任务，计算任务对应至少一个计算进程，计算节点包括日志信息输出服务和上传组件，如图2所示，该方法可以包括：

S21，日志信息输出服务将计算进程产生的日志以日志文件的形式输出至本地磁盘。

本公开实施例中的计算集群为Kubernetes，而计算节点可以为在Kubernetes中创建的Pod。每个计算任务对应至少一个计算进程(executor)，当Spark计算任务运行于Kubernetes上的某个计算节点时，Spark计算任务对应的各个计算进程随着运行的过程不断的产生日志。

在计算节点中包括日志信息输出服务，日志信息输出服务可以用于收集每个计算进程的完整的日志。具体的，日志信息输出服务可以在计算进程运行的过程中，将产生的日志以日志文件的形式输出至本地磁盘。在计算进程的运行过程中，日志信息输出服务向本地磁盘中输出日志的过程也持续进行。

S22，日志信息输出服务在捕捉到计算进程的退出事件时，将日志文件的后缀更新为用于指示计算进程结束的后缀标识，得到目标日志文件。

当日志信息输出服务在捕捉到计算进程的退出事件时，表示该计算进程的运行过程即将结束，此时日志信息输出服务会将相应的日志文件进行后缀更新处理，得到目标日志文件。

例如，当日志信息输出服务在捕捉到计算进程的退出事件之前，以日志文件形式输出至本地磁盘的日志文件的后缀可以为.inprocess，而在捕捉到计算进程的退出事件之后，可以将日志文件的后缀.inprocess更新为.completed，后缀标识.completed即用于指示该计算进程结束。

目标日志文件的后缀为用于指示计算进程结束的后缀标识，目标日志文件的内容与后缀更新之前的日志文件的内容一致，仅仅是对日志文件的后缀进行了更新处理。由于日志信息输出服务是在捕捉到计算进程的退出事件后对日志文件的后缀进行更新的，因此得到的目标日志文件中包括该计算进程的完整的日志。

S23，上传组件响应于监听到本地磁盘中生成目标日志文件，向存储集群上传目标日志文件。

上传组件与Kubernetes的计算节点可以一一对应，即每个计算节点中包括一个上传组件，上传组件可以基于Apache Commons-IO实现。

上传组件作为DaemonSet在计算节点上运行，上传组件主要用于监听该计算节点的本地磁盘目录。当上传组件监听到本地磁盘中生成目标日志文件时，上传组件可以向存储集群上传该目标日志文件。

上传组件在监听本地磁盘中是否生成目标日志文件时，主要是基于本地磁盘中的日志文件的后缀标识来监听的。例如，若用于指示计算进程结束的后缀标识为.completed，则上传组件持续监听本地磁盘中是否有以.completed为后缀的日志文件被创建。若上传组件监听到本地磁盘中有以.completed为后缀的日志文件被创建，则触发上传组件的收集功能，上传组件将目标日志文件上传至存储集群，实现计算进程的日志的收集。

本公开实施例提供的日志处理方法，应用于计算集群，计算集群中包括计算节点，计算节点用于运行计算任务，计算任务对应至少一个计算进程，当计算进程运行在计算节点上时，日志信息输出服务会将计算进程产生的日志以日志文件的形式输出至本地磁盘，并在捕捉到计算进程的退出事件时，将日志文件的后缀更新为用于指示计算进程结束的后缀标识，得到目标日志文件。由于日志信息输出服务是在计算进程将要退出时对日志文件的后缀进行更新的，因此得到的目标日志文件中包括计算进程运行产生的完整的日志。上传组件在监听到本地磁盘中生成了目标日志文件后，向存储集群上传目标日志文件，从而能够将计算进程产生的日志进行完整的收集，完整收集的目标日志文件有利于帮助定位计算进程中产生的问题，节省计算进程开发和运维的成本。

下面将结合附图对本公开的方案进行详细介绍。

图3为本公开实施例提供的一种日志处理系统的示意图，如图3所示，主要包括计算集群和存储集群。

在计算集群Kubernetes上可以包括一个或多个计算节点，图3中仅以一个计算节点为例，计算节点可以运行Spark的计算任务，Spark的计算任务中可以包括一个或多个计算进程。

计算节点包括日志信息输出服务和上传组件，其中，日志信息输出服务可以包括日志输出组件和钩子函数，日志输出组件和钩子函数共同完成计算进程的日志文件的输出以及对日志文件的后缀更新处理。

在计算进程的启动脚本中，可以为计算进程配置相应的日志链接，日志链接中包括目标日志文件的文件名称和日志地址，文件名称中包括计算进程的任务标识(ApplicationID)和进程标识(ExecutorID)。例如，某个Spark计算任务为spark-163，该Spark计算任务使用了5个计算进程，分别是1、2、3、4、5，则针对计算进程1而言，其任务标识为spark-163，进程标识为1；针对计算进程2而言，其任务标识为spark-163，进程标识为2，等等。根据文件名称和日志地址可以配置日志链接，例如，日志链接可以由“Spark_LOG_URL_文件名称＝日志地址”组成，日志地址可以通过配置文件的方式进行简单配置，能做到每个计算进程都允许简单的自定义。

具体的，当计算进程运行在计算节点上，会持续产生日志，而日志输出组件可以将计算进程产生的日志以日志文件的形式输出至本地磁盘。而钩子函数用于捕捉计算进程的退出事件，并将日志文件的后缀更新为用于指示计算进程结束的后缀标识，得到目标日志文件。

例如，可以通过自定义拓展Log4j的日志输出组件FileAppender来实现日志文件的输出。在Log4j中可以通过输出组件Appender来指定日志输出的目的地，其中，FileAppender用于指示将日志输出到文件中，即日志文件。在Log4j初始化的时候，可以向Java原生的钩子函数ShutDownHook中添加功能函数，其中，钩子函数ShutDownHook可以用于捕捉计算进程的退出事件，而在钩子函数ShutDownHook中添加功能函数后，钩子函数ShutDownHook可以在捕捉到计算进程的退出事件时，将持久化到本地磁盘的日志文件的后缀进行更新处理，得到目标日志文件，目标日志文件的后缀为用于指示计算进程结束的后缀标识。

例如，在后缀更新之前的日志文件的后缀名称为.inprocess，在后缀更新之后的目标日志文件的后缀名称为.completed。上传组件在监听到本地磁盘中创建了后缀名称为.completed的目标日志文件后，根据计算进程的日志链接，向存储集群上传目标日志文件。

上传组件首先会根据目标日志文件的文件名称中包括的任务标识和进程标识进行拆分。具体的，上传组件根据配置的存储HDFS路径拼接任务标识作为目录，进程标识作为目标日志文件的文件名称，通过任务标识和进程标识确保文件路径的唯一性，从而避免产生存储文件路径冲突的问题。

上传组件按照日志链接尝试上传目标日志文件，当上传组件上传目标日志文件成功后，上传组件不再重复上传；当上传组件上传目标日志文件失败后，上传组件可以重复尝试上传。

在某些情况下，可能产生上传组件无法上传目标日志文件成功的情况，为了避免上传过程持续占用计算资源，可以预先设置一个最大重复传输的次数N，N为大于1的预设正整数。上传组件响应于第i次向存储集群上传目标日志文件失败，且i小于N，则上传组件第i+1次向存储集群上传目标日志文件，并更新i为i+1，其中，i初始为1，i为大于或等于1且小于或等于N的正整数。

即当第i次向存储集群上传目标日志文件失败且还未达到最大重复传输的次数N时，上传组件会重复尝试上传操作，直至目标日志文件上传成功或达到最大重复传输的次数。以N＝3为例，若第1次上传组件向存储集群上传目标日志文件成功，则上传组件不再重复向存储集群上传该目标日志文件；若第1次向存储集群上传目标日志文件失败，则上传组件会第2次尝试向存储集群上传该目标日志文件；若第2次上传组件向存储集群上传目标日志文件成功，则上传组件不再重复向存储集群上传该目标日志文件；若第2次向存储集群上传目标日志文件失败，则上传组件会第3次尝试向存储集群上传该目标日志文件。由于最大重复传输的次数N＝3，因此在第3次尝试向存储集群上传该目标日志文件后，无论是否上传成功，均不进行第4次重复尝试传输。

本公开实施例中通过Java自带的钩子函数ShutDownHook，在计算进程即将退出(无论执行失败还是正常完成)前，修改持久化到本地磁盘的日志文件后缀，与Kubernetes提供的pre-stop功能相比，通过Java中的钩子函数的方式能减少侵入性，同时通过设置失败重传机制，既能够提高目标日志文件上传的成功率，也能够在由于某些原因无法成功上传时，通过失败重传次数的限定来避免上传过程持续占用资源。通过本公开实施例的方案，能够上传计算进程的完整的目标日志文件。

与通过Flume方式上传目标日志文件至HDFS的方式相比，通过Flume方式上传日志至HDFS，只能将所有的日志文件传输至一个目录下，在后续需要查找日志文件时，需要扫描所有的日志文件，给遍历查询带来压力。而本公开实施例中，对每个目标日志文件均明确标识了其所属任务标识和进程标识。在目标日志文件上传至HDFS后，提供日志管理服务的功能组件(例如下述实施例中的下载组件)可以根据各个目标日志文件的任务标识，将同一任务标识下的各计算进程的目标日志文件存储至同一日志文件夹中。在后续需要查找日志文件时，提供日志管理服务的功能组件只需要查找日志文件夹列表中的各日志文件夹的文件夹名称，大大减小了遍历查询的计算量。同时，通过Flume方式上传日志的方式，是一边运行计算进程一边上传，上传的过程会占用资源，而本公开的方式是在计算进程运行完成之后上传，上传的过程不会占用计算资源，能够进一步保证计算进程的良好运行。

存储集群中包括分布式系统节点HDFS，以及历史服务器(Spark HistoryServer)，上传组件上传的目标日志文件存储于HDFS中。在计算集群中，还可以包括下载组件，下载组件作为Pod运行在Kubernetes的计算节点上，可以用于管理和提供计算进程的目标日志文件。下载组件为对管理和提供计算进程的目标日志文件的数据或方法的封装，例如，下载组件提供日志管理功能，可以管理存储在HDFS的目标日志文件；下载组件还可以分别提供不同的端口给历史服务器和进程界面，通过相应的端口，下载组件可以接收历史服务器或进程界面的日志查看请求，从而根据日志查看请求查找相应的日志文件，供开发人员或运维人员查看，等等。

下载组件可以周期性的扫描HDFS中存储目标日志文件的日志文件夹列表，日志文件夹列表中包括各个日志文件夹的文件夹名称。当上传组件将目标日志文件上传至HDFS后，下载组件根据各个目标日志文件的任务标识，将同一个计算任务下的不同的计算进程的目标日志文件归并至同一日志文件夹中。在本公开实施例中，下载组件和HDFS之间不进行日志文件的传输，而是由下载组件对存储在HDFS中的日志文件进行管理。由于同一日志文件夹中包括的目标日志文件为同一个计算任务下的不同的计算进程的目标日志文件，因此这些目标日志文件的任务标识相同，可以将该任务标识作为日志文件夹的文件夹名称。相同的日志文件夹中包括同一计算任务下的不同计算进程的目标日志文件，不同的日志文件夹中包括不同计算任务下的计算进程的目标日志文件。

图4为本公开实施例提供的一种日志文件列表示意图，如图4所示，示意了5个日志文件夹，这5个日志文件夹的任务标识依次为spark-161、spark-162、spark-163、spark-164、spark-165，5个日志文件夹的文件夹名称即为对应的任务标识。在每个日志文件夹中，可以包括对应的任务标识的计算任务下的一个或多个计算进程的目标日志文件。

下载组件在每次扫描HDFS时，无需对单个目标日志文件进行扫描，而只需扫描以任务标识为文件夹名称的日志文件夹列表。在日志文件夹列表中，各日志文件夹的文件夹名称根据对应的最后更新时间顺序排列。例如在图4中，示意了各个日志文件夹的最后更新时间，例如spark-161的最后更新时间为7月12号8:46。根据最后更新时间，各个日志文件夹的文件夹名称从上至下依次为spark-161、spark-165、spark-164、spark-162、spark-163。

当上传组件上传了目标日志文件至HDFS后，下载组件可以根据目标日志文件的任务标识，将目标日志文件归并至HDFS中对应的目标日志文件夹中，其中，目标日志文件夹的文件夹名称中包括目标日志文件的任务标识。

具体的，下载组件会扫描HDFS中存储的日志文件夹列表，判断日志文件夹列表中是否有目标日志文件夹的文件夹名称，目标日志文件夹的文件夹名称为目标日志文件的任务标识。

若日志文件夹列表中包括目标日志文件夹的文件夹名称，表示以目标日志文件的任务标识为文件夹名称的日志文件夹已被创建。下载组件响应于在日志文件夹列表中扫描到目标日志文件夹的文件夹名称，将目标日志文件归并至该目标日志文件夹中。

若日志文件夹列表中不包括目标日志文件夹的文件夹名称，表示以目标日志文件的任务标识为文件夹名称的日志文件夹未被创建。下载组件响应于在日志文件夹列表中未扫描到目标日志文件夹的文件夹名称，在日志文件夹列表中创建目标日志文件夹，然后将目标日志文件归并至所创建的目标日志文件夹中。

图5为本公开实施例提供的存储目标日志文件示意图一，如图5所示，在日志文件夹列表51中包括3个日志文件夹，这3个日志文件夹的文件夹名称分别是spark-161、spark-162、spark-163，每个日志文件夹中分别存储了至少一个目标日志文件。其中，spark-161中包括目标日志文件1和目标日志文件2，spark-162中包括目标日志文件3，spark-163中包括目标日志文件4和目标日志文件5。

现有目标日志文件A，目标日志文件A的任务标识为spark-161，则在存储目标日志文件A时，下载组件首先扫描日志文件夹列表51。日志文件夹列表51中包括文件夹名称为spark-161的日志文件夹，则该日志文件夹为目标日志文件A的目标日志文件夹，下载组件将目标日志文件A归并至该目标日志文件夹中，得到新的目标日志文件夹52。进一步的，由于目标日志文件A存储至目标日志文件夹中，目标日志文件夹发生了更新，其最后更新时间在3个日志文件夹中最晚，因此将该目标日志文件夹的文件夹名称的排列顺序放到日志文件夹列表52的最后。

图6为本公开实施例提供的存储目标日志文件示意图二，如图6所示，在日志文件夹列表61中包括3个日志文件夹，这3个日志文件夹的文件夹名称分别是spark-161、spark-162、spark-163，每个日志文件夹中分别存储了至少一个目标日志文件。其中，spark-161中包括目标日志文件1和目标日志文件2，spark-162中包括目标日志文件3，spark-163中包括目标日志文件4和目标日志文件5。

现有目标日志文件B，目标日志文件B的任务标识为spark-164，则在存储目标日志文件B时，下载组件首先扫描日志文件夹列表61。日志文件夹列表61中不包括文件夹名称为spark-164的日志文件夹，因此首先创建一个文件夹名称为spark-164的日志文件夹，该日志文件夹即为目标日志文件B的目标日志文件夹。在创建完成后，将目标日志文件B归并至该目标日志文件夹中，得到新的日志文件夹列表62。进一步的，由于该目标日志文件夹是新创建的文件夹，其最后更新时间在4个日志文件夹中最晚，因此将该目标日志文件夹的文件夹名称的排列顺序放到日志文件夹列表62的最后。

下载组件除了可以管理存储在HDFS上的目标日志文件外，还可以管理存储在HDFS上的日志文件的使用容量。由于Spark运行在Kubernetes上，各个spark计算任务对应的计算进程均产生日志，而这些日志会以目标日志文件的形式被上传组件上传到HDFS上。若不对存储在HDFS上的目标日志文件进行清理，则会极大的占用HDFS的存储空间。

因此，下载组件可以在日志文件夹列表对应的各日志文件夹中确定待删除日志文件夹，并根据所确定的结构在HDFS中清除待删除日志文件夹。

由于日志文件是用于提供给开发人员和运维人员，用于定位计算进程中出现的问题的，因此日志文件均具备一定的时效性，只有在一定的时间范围内的日志文件才是有效的，超过一定的时间范围的日志文件对于计算进程的问题定位无法起到相应的作用，会浪费存储空间。因此，本公开实施例中，可以根据各日志文件夹的最后更新时间，在各日志文件夹中确定待删除日志文件夹，然后在HDFS中清除待删除日志文件夹。

图7为本公开实施例提供的确定待删除日志文件夹的示意图，如图7所示，在删除日志文件夹之前，HDFS中存储有10个日志文件夹，分别是日志文件夹1-日志文件夹10，如日志文件夹列表70所示。图7中示例了各个日志文件夹的最后更新时间，各个日志文件夹的文件夹名称根据最后更新时间从上到下排列。

一种可能的实现方式是，可以预先设定一个第一时段，第一时段例如可以为距当前时刻在3天内的时段。当日志文件夹的最后更新时间在该第一时段内时，表示该日志文件夹为最近更新的日志文件夹，不作为待删除日志文件夹；当日志文件夹的最后更新时间在该第一时段外时，例如距今超过了5天，表示该日志文件夹的更新时间较早，可以将该日志文件夹确定为待删除日志文件夹。例如在图7中，根据该实施方式，可以确定日志文件夹2和日志文件夹5为待删除日志文件夹，对日志文件夹2和日志文件夹5可以进行清除，清除后得到新的日志文件夹列表71。

一种可能的实现方式是，获取日志文件夹列表中包括的文件夹名称的数目，判断HDFS中存储的日志文件夹的数目是否大于或等于预设数目，若是，则将超过预设数目的日志文件夹确定为待删除日志文件夹。在该实施方式中，也是根据日志文件夹的最后更新时间确定待删除日志文件夹的。例如在图7中，预设数目为7，而HDFS中存储了10个日志文件夹，因此可以将最后更新时间最早的3个日志文件夹-日志文件夹2、日志文件夹5和日志文件夹1确定为待删除日志文件夹，对日志文件夹2、日志文件夹5和日志文件夹1可以进行清除，清除后得到新的日志文件夹列表72。

通过设置辅助组件(辅助组件包括上传组件和下载组件)，填补了Kubernetes缺乏的功能。其中，上传组件提供了日志文件的收集功能，实现了计算进程的日志的完整上传，并将各个计算节点上分散的计算进程的日志集中到HDFS上。下载组件提供了管理和展示目标日志文件的功能，能够管理存储在HDFS上的目标日志文件，同时还能够对过期的目标日志文件进行清理，防止无限制的占用HDFS的存储资源。

在上述实施例中，对下载组件进行日志文件的存储和管理进行了介绍，下载组件除了可以进行日志文件的存储和管理外，还可以根据日志查看请求查找相应的日志，其中，日志查看请求可以是来自存储集群中的历史服务器的日志查看请求，也可以是来自进程界面(Spark UI)的日志查看请求，下面分别进行介绍。

图8为本公开实施例提供的历史日志查看示意图，如图8所示，下载组件可以接收来自历史服务器的第一日志查看请求，第一日志查看请求中包括第一待查看日志文件的日志链接。

历史服务器请求查看的是已经运行结束的计算进程的日志文件，如上述实施例中介绍，计算进程在运行结束即将退出时，钩子函数ShutDownHook就会对计算进程产生的日志文件进行后缀更新处理，并由上传组件将得到的目标日志文件上传至HDFS，因此，下载组件在接收到第一日志查看请求后，根据第一待查看日志文件的日志链接，首先在HDFS中查找第一待查看日志文件。

由于日志链接中包括对应的计算进程的任务标识和进程标识，下载组件在HDFS中查看第一待查看日志文件的过程中，首先根据日志链接中的任务标识，查找是否有对应的日志文件夹。若有，则进一步查找该日志文件夹中是否有日志文件名称为日志链接中的进程标识的日志文件，若有，则可以确定该日志文件为第一待查看日志文件。下载组件响应于在HDFS中查找到第一待查看日志文件，控制HDFS向历史服务器发送第一待查看日志文件。

若根据日志链接中的任务标识在HDFS中查找时，未查找到对应的日志文件夹，或者，查找到对应的日志文件夹但在该日志文件夹中未查找到有日志文件名称为该日志链接中的进程标识的日志文件，则下载组件在HDFS上未查找到第一待查看日志文件。

下载组件在HDFS上未查找到第一待查看日志文件的可能性有多种。例如，第一待查看日志文件为过期日志文件，即第一待查看日志文件的最后更新时间距今较久，而下载组件会定期清理HDFS中的日志文件夹；例如，上传组件在向HDFS上传第一待查看日志文件时，未上传成功。

因此，在下载组件在HDFS上未查找到第一待查看日志文件的情况下，首先判断第一待查看日志文件是否为过期日志文件。若第一待查看日志文件为过期日志文件，则表示未查找到第一待查看日志文件的原因为第一待查看日志文件被下载组件清除了。下载组件可以向历史服务器发送过期指令，用于指示第一待查看日志文件为过期日志文件。

若第一待查看日志文件为非过期日志文件，下载组件可以向第一待查看日志文件对应的上传组件发送第一日志查看请求，第一待查看日志文件对应的上传组件在本地磁盘中查找第一待查看日志文件。若在本地磁盘中查找到第一待查看日志文件，则下载组件可以向历史服务器发送第一待查看日志文件，第一待查看日志文件对应的上传组件再次尝试向存储集群上传第一待查看日志文件。

当Spark程序运行在Kubernetes上时，由于在计算进程的启动脚本中配置了相应的日志链接，从而无需对历史服务器的代码进行修改，Spark程序运行在Kubernetes上产生的日志都能以日志链接的方式提供给历史服务器展示，通过历史服务器上展示的日志链接可以查看相应的日志文件，进而能够根据日志文件对计算进程运行过程中出现的问题进行有效的定位和处理。

图8实施例对通过历史服务器请求查看历史日志进行了介绍，下面介绍通过SparkUI查看正在运行的计算进程的日志的方案。

Spark UI为一个web界面，通过Spark UI可以查看正在运行的计算进程的日志。在Spark UI上显示有刷新控件，当操作Spark UI上的刷新控件后，Spark UI会向下载组件发送刷新请求。下载组件根据刷新请求，确定第一时刻至当前时刻之间新增的且正在运行的计算进程，并向Spark UI发送上述新增的且正在运行的计算进程的日志文件。

第一时刻为当前时刻之前最近一次从Spark UI接收到刷新请求的时刻。例如，用户第一次操作刷新控件，下载组件在时刻A第一次收到刷新请求；用户第二次操作刷新控件，下载组件在时刻B第二次收到刷新请求，则针对第二次操作而言，第一时刻即为时刻A，当前时刻即为时刻B，下载组件需要确定在时刻A至时刻B这一时段内新增的且正在运行的计算进程，并将这一时段内新增的且正在运行的计算进程的日志文件发送给Spark UI。

相比于其他的冲刷缓存操作，是将所有缓冲的日志全部冲刷到Spark UI，由于每次冲刷的日志的大小有一定的限制，例如每次只能冲刷500M的日志内容，这种实施方式会根据大小的限制将日志进行分割，可能导致同一计算进程的日志被分成两次冲刷至SparkUI。本公开实施例的方案，只冲刷第一时刻至当前时刻的日志，能够实现有序的日志冲刷，且同一计算进程的日志不会被分割，能够保证计算日志的完整性。

图9为本公开实施例提供的当前运行计算进程的日志查看示意图，如图9所示，下载组件可以接收来自Spark UI的第二日志查看请求，第二日志查看请求中包括第二待查看日志文件的任务标识、进程标识和日志地址。

下载组件在接收到第二日志查看请求后，根据第二待查看日志文件的任务标识和进程标识，指示第二待查看日志文件对应的上传组件在对应的本地磁盘中查找第二待查看日志文件。若在本地磁盘中查找到第二待查看日志文件，则下载组件向Spark UI发送第二待查看日志文件。

例如，在图9中，目前Spark On Kubernetes正在运行任务标识为Spark-163的任务，并且使用5个计算进程。

此时通过Spark UI查看正在进行的任务的计算进程1的日志，Spark UI向下载组件发送第二日志查看请求，第二日志查看请求中包括任务标识spark-163，进程标识1，日志地址XXX。下载组件连接XXX节点上的上传组件，请求文件名称为spark163-exec-1.log.inprocess的日志文件，并返回给SparkUI。

当计算进程准备退出任务时，钩子函数ShutDownHook会修改日志文件spark-163-exec-1.log.inprocess为目标日志文件spark-163-exec-1.log.completed。上传组件监听到该事件并上传此目标日志文件至HDFS:(配置的根目录)/spark-163/1.log。

Spark UI向下载组件发送第二日志查看请求，下载组件能够根据第二日志查看请求中的任务标识和进程标识查看相应的第二待查看日志文件，实现了通过Spark UI获取正在运行的各计算进程的实时的日志文件的功能。

本公开实施例提供的日志处理方法，应用于计算集群，计算集群中包括计算节点，计算节点用于运行计算任务，计算任务对应至少一个计算进程，当计算进程运行在计算节点上时，日志信息输出服务会将计算进程产生的日志以日志文件的形式输出至本地磁盘，并在捕捉到计算进程的退出事件时，将日志文件的后缀更新为用于指示计算进程结束的后缀标识，得到目标日志文件。由于日志信息输出服务是在计算进程将要退出时对日志文件的后缀进行更新的，因此得到的目标日志文件中包括计算进程运行产生的完整的日志。上传组件在监听到本地磁盘中生成了目标日志文件后，向存储集群上传目标日志文件，从而能够将计算进程产生的日志进行完整的收集，完整收集的目标日志文件有利于帮助定位计算进程中产生的问题，节省计算进程开发和运维的成本。

示例性介质

在介绍了本公开示例性实施方式的方法之后，接下来，参考图10对本公开示例性实施方式的存储介质进行说明。

参考图10所示，存储介质100中存储着根据本公开的实施方式的用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备。

示例性装置

在介绍了本公开示例性实施方式的介质之后，接下来，参考图11对本公开示例性实施方式的日志处理系统进行说明，用于实现上述任一方法实施例中的方法，其实现原理和技术效果类似，在此不再赘述。

图11为本公开实施例提供的日志处理系统的结构示意图，该日志处理系统110应用于计算集群，所述计算集群包括计算节点，所述计算节点用于运行计算任务，所述计算任务对应至少一个计算进程，所述计算节点包括日志信息输出服务111和上传组件112，所述日志处理系统110包括：

所述日志信息输出服务111，用于将所述计算进程产生的日志以日志文件的形式输出至本地磁盘；所述日志信息输出服务在捕捉到所述计算进程的退出事件时，将所述日志文件的后缀更新为用于指示所述计算进程结束的后缀标识，得到目标日志文件；

所述上传组件112，用于响应于监听到所述本地磁盘中生成所述目标日志文件，向存储集群上传所述目标日志文件。

在一种可能的实施方式中，所述日志信息输出服务111包括日志输出组件；所述日志输出组件用于：

将所述计算进程产生的日志以日志文件的形式输出至所述本地磁盘。

在一种可能的实施方式中，所述日志信息输出服务111还包括钩子函数；所述钩子函数用于：

所述钩子函数在捕捉到所述退出事件时，将所述日志文件的后缀更新为用于指示所述计算进程结束的后缀标识，并将后缀更新后的日志文件作为所述目标日志文件。

在一种可能的实施方式中，所述上传组件具体用于：

响应于监听到所述本地磁盘中生成所述目标日志文件，根据所述计算进程的日志链接，向所述存储集群上传所述目标日志文件；

所述日志链接是在所述计算进程的启动脚本中为所述计算进程配置的，所述日志链接中包括所述目标日志文件的文件名称和日志地址，所述文件名称包括对应的计算进程的任务标识和进程标识。

在一种可能的实施方式中，所述上传组件还用于：

响应于第i次向所述存储集群上传所述目标日志文件失败，且所述i小于N，所述上传组件第i+1次向所述存储集群上传所述目标日志文件，并更新所述i为i+1；

其中，所述i初始为1，所述i为大于或等于1且小于或等于N的正整数，所述N为大于1的预设正整数。

在一种可能的实施方式中，所述日志处理系统还包括下载组件，所述存储集群包括分布式系统节点，所述下载组件用于：

根据所述目标日志文件的任务标识，将所述目标日志文件归并至所述分布式系统节点中对应的目标日志文件夹中，所述目标日志文件夹的文件夹名称中包括所述目标日志文件的任务标识。

在一种可能的实施方式中，所述下载组件具体用于：

扫描所述分布式系统节点中存储的日志文件夹列表，所述日志文件夹列表中包括至少一个日志文件夹的文件夹名称，所述日志文件夹列表中的各日志文件夹的文件夹名称根据对应的最后更新时间排列；

响应于在所述日志文件夹列表中扫描到所述目标日志文件夹的文件夹名称，将所述目标日志文件归并至所述目标日志文件夹中；

响应于在所述日志文件夹列表中未扫描到所述目标日志文件夹的文件夹名称，在所述日志文件夹列表中创建目标日志文件夹，并将所述目标日志文件归并至所创建的目标日志文件夹中。

在一种可能的实施方式中，所述下载组件还用于：

在所述日志文件夹列表对应的各所述日志文件夹中确定待删除日志文件夹，并根据所确定的结果在所述分布式系统节点中清除所述待删除日志文件夹。

在一种可能的实施方式中，所述下载组件具体还用于：

根据各所述日志文件夹的最后更新时间，在各所述日志文件夹中确定为所述待删除日志文件夹。

在一种可能的实施方式中，所述存储集群还包括历史服务器，所述下载组件还用于：

接收来自所述历史服务器的第一日志查看请求，所述第一日志查看请求中包括第一待查看日志文件的日志链接；

根据所述第一待查看日志文件的日志链接在所述分布式系统节点中查找对应的所述第一待查看日志文件；

响应于在所述分布式系统节点中查找到所述第一待查看日志文件，向所述历史服务器发送所述第一待查看日志文件。

在一种可能的实施方式中，所述下载组件在所述分布式系统节点中未查找到所述第一待查看日志文件，所述下载组件还用于：

若所述第一待查看日志文件为过期日志文件，向所述历史服务器发送过期指令，用于指示所述第一待查看日志文件为过期日志文件；

若所述第一待查看日志文件为非过期日志文件，向所述第一待查看日志文件对应的上传组件发送所述第一日志查看请求；

所述第一待查看日志文件对应的上传组件在本地磁盘上查找所述第一待查看日志文件。

在一种可能的实施方式中，所述下载组件还用于：

响应于在所述本地磁盘上查找到所述第一待查看日志文件，控制所述分布式系统节点向所述历史服务器发送所述第一待查看日志文件；

所述第一待查看日志文件对应的上传组件还用于：

向所述存储集群上传所述第一待查看日志文件。

在一种可能的实施方式中，所述下载组件还用于：

接收来自进程界面的第二日志查看请求，所述第二日志查看请求中包括第二待查看日志文件的任务标识、进程标识和日志地址；

根据所述第二待查看日志文件的任务标识和进程标识，指示所述第二待查看日志文件对应的上传组件在对应的本地磁盘中查找所述第二待查看日志文件，所述第二待查看日志文件对应的上传组件为根据所述日志地址确定的计算节点的上传组件；

向所述进程界面发送所述第二待查看日志文件。

在一种可能的实施方式中，所述下载组件还用于：

接收来自进程界面的刷新请求；

根据所述刷新请求，确定第一时刻至当前之间时间新增的且正在运行的计算进程，所述第一时刻为所述当前时刻之前最近一次从所述进程界面接收到所述刷新请求的时刻；

向所述进程界面发送所述新增的且正在运行的计算进程的日志文件。

本公开实施例提供的日志处理系统，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

示例性计算设备

在介绍了本公开示例性实施方式的方法、介质和装置之后，接下来，参考图12对本公开示例性实施方式的计算设备进行说明。

图12显示的计算设备120仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图12所示，计算设备120以通用计算设备的形式表现。计算设备120的组件可以包括但不限于：上述至少一个处理单元121、上述至少一个存储单元122，连接不同系统组件(包括处理单元121和存储单元122)的总线123。

总线123包括数据总线、控制总线和地址总线。

存储单元122可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)1221和/或高速缓存存储器1222，可以进一步包括非易失性存储器形式的可读介质，例如只读存储器(ROM)1223。

存储单元122还可以包括具有一组(至少一个)程序模块1224的程序/实用工具1225，这样的程序模块1224包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算设备120也可以与一个或多个外部设备124(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(I/O)接口125进行。并且，计算设备120还可以通过网络适配器126与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图12所示，网络适配器126通过总线123与计算设备120的其它模块通信。应当理解，尽管图中未示出，可以结合计算设备120使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了信息获取装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

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

虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种日志处理方法，应用于计算集群，所述计算集群包括计算节点，所述计算节点用于运行计算任务，所述计算任务对应至少一个计算进程，所述计算节点包括日志信息输出服务和上传组件，所述方法包括：

所述日志信息输出服务将所述计算进程产生的日志以日志文件的形式输出至本地磁盘；所述日志信息输出服务在捕捉到所述计算进程的退出事件时，将所述日志文件的后缀更新为用于指示所述计算进程结束的后缀标识，得到目标日志文件；

所述上传组件响应于监听到所述本地磁盘中生成所述目标日志文件，向存储集群上传所述目标日志文件。

2.根据权利要求1所述的方法，所述日志信息输出服务包括日志输出组件；所述日志信息输出服务将所述计算进程产生的日志以日志文件的形式输出至本地磁盘，包括：

所述日志输出组件将所述计算进程产生的日志以日志文件的形式输出至所述本地磁盘。

3.根据权利要求2所述的方法，所述日志信息输出服务还包括钩子函数；所述日志信息输出服务在捕捉到所述计算进程的退出事件时，将所述日志文件的后缀更新为用于指示所述计算进程结束的后缀标识，得到目标日志文件，包括：

所述钩子函数在捕捉到所述退出事件时，将所述日志文件的后缀更新为用于指示所述计算进程结束的后缀标识，并将后缀更新后的日志文件作为所述目标日志文件。

4.根据权利要求1-3任一项所述的方法，所述计算集群还包括下载组件，所述存储集群包括分布式系统节点，所述方法还包括：

所述下载组件根据所述目标日志文件的任务标识，将所述目标日志文件归并至所述分布式系统节点中对应的目标日志文件夹中，所述目标日志文件夹的文件夹名称中包括所述目标日志文件的任务标识。

5.根据权利要求4所述的方法，所述根据所述目标日志文件的任务标识，将所述目标日志文件归并至所述分布式系统节点中对应的目标日志文件夹中，包括：

扫描所述分布式系统节点中存储的日志文件夹列表，所述日志文件夹列表中包括至少一个日志文件夹的文件夹名称，所述日志文件夹列表中的各日志文件夹的文件夹名称根据对应的最后更新时间排列；

响应于在所述日志文件夹列表中扫描到所述目标日志文件夹的文件夹名称，将所述目标日志文件归并至所述目标日志文件夹中；

响应于在所述日志文件夹列表中未扫描到所述目标日志文件夹的文件夹名称，在所述日志文件夹列表中创建目标日志文件夹，并将所述目标日志文件归并至所创建的目标日志文件夹中。

6.根据权利要求4所述的方法，所述存储集群还包括历史服务器，所述方法还包括：

所述下载组件接收来自所述历史服务器的第一日志查看请求，所述第一日志查看请求中包括第一待查看日志文件的日志链接；

所述下载组件根据所述第一待查看日志文件的日志链接在所述分布式系统节点中查找对应的所述第一待查看日志文件；

响应于在所述分布式系统节点中查找到所述第一待查看日志文件，所述下载组件控制所述分布式系统节点向所述历史服务器发送所述第一待查看日志文件。

7.根据权利要求4所述的方法，所述方法还包括：

所述下载组件接收来自进程界面的第二日志查看请求，所述第二日志查看请求中包括第二待查看日志文件的任务标识、进程标识和日志地址；

所述下载组件根据所述第二待查看日志文件的任务标识和进程标识，指示所述第二待查看日志文件对应的上传组件在对应的本地磁盘中查找所述第二待查看日志文件，所述第二待查看日志文件对应的上传组件为根据所述日志地址确定的计算节点的上传组件；

向所述进程界面发送所述第二待查看日志文件。

8.一种日志处理系统，应用于计算集群，所述计算集群包括计算节点，所述计算节点用于运行计算任务，所述计算任务对应至少一个计算进程，所述计算节点包括日志信息输出服务和上传组件，所述日志处理系统包括：

所述日志信息输出服务，用于将所述计算进程产生的日志以日志文件的形式输出至本地磁盘；所述日志信息输出服务在捕捉到所述计算进程的退出事件时，将所述日志文件的后缀更新为用于指示所述计算进程结束的后缀标识，得到目标日志文件；

所述上传组件，用于响应于监听到所述本地磁盘中生成所述目标日志文件，向存储集群上传所述目标日志文件。

9.一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序指令，所述计算机程序指令被执行时，实现如权利要求1至7中任一项所述的日志处理方法。

10.一种计算设备，包括：存储器和处理器；

所述存储器用于存储程序指令；

所述处理器用于调用所述存储器中的程序指令执行如权利要求1至7中任一项所述的日志处理方法。

Images