Docker服务容器日志的处理方法、装置和电子设备与流程

本公开涉及计算机技术领域，更具体地，涉及一种docker服务容器日志的处理方法、docker服务容器日志的处理装置、计算机存储介质和电子设备。

背景技术：

在蓬勃发展的计算机技术中，虚拟化(virtualization)是一种资源管理技术，是将计算机的各种实体资源，如服务器、网络、内存及存储等，予以抽象和转换后呈现出来，打破实体结构间的不可切割的障碍，使用户可以比原本的组态更好的方式来应用这些资源。其中，以docker为代表的基于容器的虚拟化技术是当前虚拟技术的热点。容器技术通过隔离进程和资源，实现轻量级虚拟化。由于在应用程序运行过程中会产生大量的日志，而服务容器日志不仅包括自身的日志，还包括容器内运行的各类应用的日志，因此，对服务容器中的各类日志的处理成为关键研究点之一。

目前对docker容器日志的收集主要包括容器外收集、容器内收集以及网络收集，然而该些方法仅仅是收集容器内的某一种日志，且在收集或删除服务日志时，需要很多人力成本去进行分别配置；在更改配置后需要对服务进行重启，降低了服务日志的处理效率，还需要投入大量的运维人力，难以避免由人为失误带来的问题。

因此，需要提供一种新的docker服务容器日志的处理方法。

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

技术实现要素：

本公开的目的在于提供一种docker服务容器日志的处理方法及装置、计算机存储介质和电子设备，进而至少在一定程度上克服由于docker服务容器日志的处理时难以实现对服务容器的配置信息的自动化配置而导致的服务容器的日志处理效率低、运维成本高等问题。为实现以上技术效果，本公开采用如下技术方案。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供一种docker服务容器日志的处理方法，所述方法应用于日志处理系统中的用于对服务容器对应的配置信息进行管理的控制单元，所述日志处理系统还包括服务容器、用于存储与所述服务容器对应的配置信息的存储单元和根据所述配置信息对所述服务容器进行日志处理的处理单元；

所述方法包括：从所述存储单元中获取与所述服务容器对应的容器配置信息；根据目标容器配置信息对与所述目标容器配置信息对应的服务容器执行部署操作，以获取目标服务容器，其中所述目标容器配置信息包含于所述容器配置信息中；根据所述部署操作，生成目标日志配置信息；采用所述目标日志配置信息重置所述存储单元中与所述目标服务容器对应的原始日志配置信息，以使所述处理单元根据所述目标日志配置信息对与所述目标服务容器对应的日志进行处理。

在本公开的一种示例性实施例中，所述从所述存储单元中获取与所述服务容器对应的容器配置信息，包括：通过调用与所述存储单元连接的预设接口获取所述容器配置信息。

在本公开的一种示例性实施例中，所述根据目标容器配置信息对与所述目标容器配置信息对应的服务容器执行部署操作，以获取目标服务容器，包括：判断所述存储单元中的容器配置信息是否发生改变；若所述容器配置信息发生改变，则将改变后的容器配置信息作为所述目标容器配置信息，并根据所述目标容器配置信息对与所述目标容器配置信息对应的服务容器执行部署操作，以获取目标服务容器。

在本公开的一种示例性实施例中，所述容器配置信息包括启动配置信息和停止配置信息；若所述容器配置信息发生改变，则将改变后的容器配置信息作为所述目标容器配置信息，并根据所述目标容器配置信息对与所述目标容器配置信息对应的服务容器执行部署操作，以获取目标服务容器，包括：若所述目标容器配置信息为启动配置信息，则对与所述目标容器配置信息对应的服务容器部署启动操作，以获取所述目标服务容器；若所述目标容器配置信息为停止配置信息，则对与所述目标容器配置信息对应的服务容器部署停止操作，以获取所述目标服务容器。

在本公开的一种示例性实施例中，所述根据所述部署操作，生成目标日志配置信息，包括：若对与所述目标容器配置信息对应的服务容器部署启动操作，则生成日志收集配置信息，并将所述日志收集配置信息与所述服务容器的容器标识进行合并，以生成所述目标日志配置信息；若对与所述目标容器配置信息对应的服务容器部署停止操作，则生成日志删除配置信息，并将所述日志删除配置信息与所述服务容器的容器标识进行合并，以生成所述目标日志配置信息。

根据本公开的一个方面，提供一种docker服务容器日志的处理方法，所述方法应用于日志处理系统中的根据配置信息对服务容器进行日志处理的处理单元，所述日志处理系统还包括服务容器、用于存储与所述服务容器对应的配置信息的存储单元和用于对所述服务容器对应的配置信息进行管理的控制单元；

所述方法包括：根据所述存储单元中的目标容器配置信息，获取与所述目标容器配置信息对应的目标服务容器；监测所述存储单元中的与所述目标服务容器对应的原始日志配置信息是否被所述控制单元重置；若所述原始日志配置信息发生重置，则根据重置后的目标日志配置信息对与所述目标服务容器对应的日志进行处理。

在本公开的一种示例性实施例中，所述若所述原始日志配置信息发生重置，则根据重置后的目标日志配置信息对与所述目标服务容器对应的日志进行处理，包括：通过一预设模板对所述重置后的目标日志配置信息进行渲染，以获取当前日志配置信息；根据所述当前日志配置信息，生成日志配置文件，并根据所述日志配置文件，对与所述目标服务容器对应的日志进行处理。

在本公开的一种示例性实施例中，所述日志配置文件包括与所述目标服务容器对应的容器标识和待处理日志的日志类型；所述根据所述日志配置文件，对与所述目标服务容器对应的日志进行处理，包括：根据所述容器标识和所述待处理日志的日志类型，获取与所述目标服务容器对应的日志路径；根据所述日志路径获取所述日志路径下的与所述目标服务容器对应的日志，并对所述日志进行处理。

在本公开的一种示例性实施例中，所述重置后的目标日志配置信息包括日志收集信息、日志过滤信息和日志删除信息。

在本公开的一种示例性实施例中，当所述重置后的目标日志配置信息为日志收集信息时，所述方法还包括：根据所述日志收集信息对所述目标服务容器的日志进行收集，并输出至预设存储中心。

在本公开的一种示例性实施例中，所述方法还包括：获取用户的自定义日志配置信息，并根据所述自定义日志配置信息生成日志配置文件；根据所述日志配置文件，对与所述目标服务容器对应的日志进行处理。

根据本公开的一个方面，提供一种docker服务容器日志的处理装置，应用于日志处理系统中的用于对服务容器对应的配置信息进行管理的控制单元，所述日志处理系统还包括服务容器、用于存储与所述服务容器对应的配置信息的存储单元和根据所述配置信息对所述服务容器进行日志处理的处理单元；所述docker服务容器日志的处理装置包括：

容器配置信息获取模块，用于从所述存储单元中获取与所述服务容器对应的容器配置信息；

目标服务容器获取模块，用于根据目标容器配置信息对与所述目标容器配置信息对应的服务容器执行部署操作，以获取目标服务容器，其中所述目标容器配置信息包含于所述容器配置信息中；

日志配置信息生成模块，用于根据所述部署操作，生成目标日志配置信息；

日志处理模块，用于采用所述目标日志配置信息重置所述存储单元中与所述目标服务容器对应的原始日志配置信息，以使所述处理单元根据所述目标日志配置信息对与所述目标服务容器对应的日志进行处理。

根据本公开的一个方面，提供一种docker服务容器日志的处理装置，应用于日志处理系统中的根据配置信息对服务容器进行日志处理的处理单元，所述日志处理系统还包括服务容器、用于存储与所述服务容器对应的配置信息的存储单元和用于对所述服务容器对应的配置信息进行管理的控制单元；所述docker服务容器日志的处理装置包括：

目标服务容器获取模块，用于根据所述存储单元中的目标容器配置信息，获取与所述目标容器配置信息对应的目标服务容器；

监测模块，用于监测所述存储单元中的与所述目标服务容器对应的原始日志配置信息是否被所述控制单元重置；

日志处理模块，用于若所述原始日志配置信息发生重置，则根据重置后的目标日志配置信息对与所述目标服务容器对应的日志进行处理。

根据本公开的一个方面，提供一种计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的docker服务容器日志的处理方法。

根据本公开的一个方面，提供一种电子设备，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的docker服务容器日志的处理方法。

本公开的示例性实施例中的docker服务容器日志的处理方法，在基于获取的容器配置信息进行服务容器的部署时，会自动加载与相应的服务容器对应的日志配置信息，并根据该日志配置信息进行服务容器日志的处理。一方面，仅通过简单的容器配置信息，系统便自动加载相应的服务容器的日志配置信息，无需在线上服务器进行操作，提高了服务容器日志的处理效率；同时，基于该日志配置信息，可以对一台或多台目标服务容器的日志进行处理，使日志的处理更具针对性，避免了因人为配置失误带来的配置错误等情况；另一方面，系统可以基于获取的容器配置信息自动的对相应的服务容器的日志进行处理，无需投入过多的运维人力，减少了人力资源的投入。

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

附图说明

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

图1示意性地示出了根据本公开示例性实施方式的docker服务容器日志的处理方法的流程图；

图2示意性地示出了根据本公开示例性实施方式的docker服务容器日志处理系统的架构图；

图3示意性地示出了根据本公开示例性实施方式的某一节点上的多个服务容器的分组示意图；

图4示意性地示出了根据本公开示例性实施方式的根据目标容器配置信息获取目标服务容器的流程图；

图5示意性地示出了根据本公开另一示例性实施方式的docker服务容器日志的处理方法的流程图；

图6根据日志配置文件对与目标服务容器对应的日志进行处理的流程图；

图7示意性地示出了根据本公开示例性实施方式的docker服务容器日志的处理装置的结构示意图；

图8示意性地示出了根据本公开另一示例性实施方式的docker服务容器日志的处理装置的结构示意图；

图9示意性地示出了根据本公开示例性实施方式的存储介质的示意图；以及

图10示意性地示出了根据本公开示例性实施方式的电子设备的框图。

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

具体实施方式

现在将参考附图更全面地描述示例性实施方式。然而，示例性实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施例使得本公开将更加全面和完整，并将示例性实施方式的构思全面地传达给本领域的技术人员。图中相同的附图标记表示相同或类似的结构，因而将省略它们的详细描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现或者操作以避免模糊本公开的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个软件硬化的模块中实现这些功能实体或功能实体的一部分，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

在本领域的相关技术中，docker服务容器日志的收集，主要包括三类：容器外收集是将主机磁盘挂为容器中的日志目录和文件，并在主机上做日志的收集；容器内收集是在服务容器内运行一个后台日志收集服务，以此来进行日志的收集；网络收集，容器内的应用将日志通过网络直接发送至日志中心。

相应地，相关技术中docker服务容器日志的收集方法存在如下缺陷：相关技术中主要是针对单一的docker服务容器，而对于docker内部运行多个服务时，其产生的日志既包括服务容器自身的日志，还包括服务容器内运行的应用产生的日志，相关技术中难以对该些不同种类的日志进行有针对性的收集；同时，在服务容器下线后，也无法将已有的日志配置信息进行删除，造成了资源空间的浪费；此外，相关技术中需要对服务容器进行分别配置，无法实现集群化管理，需要投入较多的运维人力。

目前docker容器服务已涉及到多种应用场景，例如将docker容器作为云主机使用、作为服务使用、作为微架构服务使用；将doker容器应用于科学计算服务领域、应用于游戏和网联网领域，等等。

基于此，在本示例实施例中，首先提供了一种docker服务容器日志的处理方法。图1示出了本公开示例性实施方式的docker服务容器日志的处理方法的流程图，该方法应用于日志处理系统中的用于对服务容器对应的配置信息进行管理的控制单元，该日志处理系统还包括服务容器、用于存储与服务容器对应的配置信息的存储单元和根据所述配置信息对服务容器进行日志处理的处理单元。

参考图1所示，该docker服务容器日志的处理方法可以包括以下步骤：

步骤s110：从所述存储单元中获取与所述服务容器对应的容器配置信息；

步骤s120：根据目标容器配置信息对与所述目标容器配置信息对应的服务容器执行部署操作，以获取目标服务容器，其中所述目标容器配置信息包含于所述容器配置信息中；

步骤s130：根据所述部署操作，生成目标日志配置信息；

步骤s140：采用所述目标日志配置信息重置所述存储单元中与所述目标服务容器对应的原始日志配置信息，以使所述处理单元根据所述目标日志配置信息对与所述目标服务容器对应的日志进行处理。

根据本示例实施例中的docker服务容器日志的处理方法，一方面，仅通过简单的容器配置信息，系统便自动加载相应的服务容器的日志配置信息，无需在线上服务器进行操作，提高了服务容器日志的处理效率；同时，基于该日志配置信息，可以对一台或多台目标服务容器的日志进行处理，使日志的处理更具针对性，避免了因人为配置失误带来的配置错误等情况；另一方面，系统可以基于获取的容器配置信息自动的对相应的服务容器的日志进行处理，无需投入过多的运维人力，减少了人力资源的投入。

下面将对本示例实施例中的docker服务容器日志的处理方法进行进一步的说明，该方法的执行主体为日志处理系统中的用于对服务容器对应的配置信息进行管理的控制单元。

在步骤s110中，从所述存储单元中获取与所述服务容器对应的容器配置信息。

在本公开的示例性实施方式中，存储单元用于存储日志处理系统内的与全部服务容器的启动或停止相关的容器配置信息以及与服务容器对应的日志配置信息，是作为docker服务容器的配置信息存储的数据库。其中，存储单元中的日志配置信息包括服务容器的容器标识以及日志类型标签；容器配置信息包括启动配置信息和停止配置信息，具体的，启动配置信息是指启动一个或多个目标服务容器的配置信息；停止配置信息是指停止一个或多个目标服务容器的配置信息，即将目标服务容器下线的配置信息。

图2示出了docker服务容器日志处理系统的架构图，如图2所示，控制单元可以通过调用一与存储单元连接的预设接口，实时监控存储单元中的容器配置信息是否存在管理员新添加的容器配置信息，并获取相应的容器配置信息。此外，存储单元中的容器配置信息和日志配信息可以以key/value(一种数据库类型)键值对的形式进行保存，当然，还可以根据不同的实际需求采用相应的数据保存形式。

进一步的，存储单元中日志配置信息还可以包括公共配置信息和节点配置信息，其中，公共配置信息是所有服务容器共享的配置信息，而节点配置信息为仅针对于该节点对应的服务容器的配置信息。此外，对于节点上的多个服务容器的多种日志的收集，还可以以服务容器的容器标识进行分组，在某一个分组下还可以根据日志处理路径进行分组，具体的，图3示出了某一节点上的多个服务容器的分组示意图，如图3所示，对于节点下的多个服务容器(docker1、docker2、docker3和docker4)，首先根据容器的标识进行分组，分别为分组1和分组2；在分组1下，docker1和docker2的日志处理路径均为存储路径1，则将docker1和docker2分为一组，而以存储路径2为存储路径的docker3则作为一组。基于不同的分组，日志处理系统既可以对某一服务容器的日志进行收集，也可以同时对多个服务容器的日志进行收集，并将收集后的日志存储于预设的路径下，提高了服务日志的处理效率。

需要说明的是，储存单元中的日志配置信息还可以根据实际需求进行相应的更改，以便于更方便的根据日志配置信息对服务容器的日志进行处理，本公开包括但不限于上述的日志配置信息的配置方式。

在步骤s120中，根据目标容器配置信息对与所述目标容器配置信息对应的服务容器执行部署操作，以获取目标服务容器，其中所述目标容器配置信息包含于所述容器配置信息中。

在本公开的示例性实施方式中，由于存储单元中存储有整个日志处理系统内的服务容器的容器配置信息，因此可以首先从存储单元中获取部分(一个或多个)服务容器对应的容器配置信息，即目标容器配置信息，并根据目标容器配置信息对与目标容器配置信息对应的服务容器执行部署操作。具体而言，图4示出了根据目标容器配置信息获取目标服务容器的流程图，如图4可知，步骤s120还包括步骤s410和步骤s420：在步骤s410中，判断存储单元中的容器配置信息是否发生改变；在步骤s420中，若容器配置信息发生改变，则将改变后的容器配置信息作为目标容器配置信息，并根据目标容器配置信息对与目标容器配置信息对应的服务容器执行部署操作，以获取目标服务容器。

其中，由步骤s110可知，容器配置信息包括启动配置信息和停止配置信息，若目标容器配置信息为启动配置信息，则对与目标容器配置信息对应的服务容器部署启动操作，以获取目标服务容器；若目标容器配置信息为停止配置信息，则对与目标容器配置信息对应的服务容器部署停止操作，以获取目标服务。举例而言，继续参照图2所示，若目标容器配置信息为启动配置信息，可以对相应的服务容器docker部署启动操作；若目标容器配置信息为停止配置信息，可以对相应的服务容器docker部署销毁操作。

在步骤s130中，根据所述部署操作，生成目标日志配置信息。

在本公开的示例性实施方式中，部署操作是指根据目标容器配置信息，对与目标容器配置信息对应的目标服务容器进行相应的操作，其中部署操作包括启动操作和停止操作，也就是说，启动目标服务容器和将服务容器下线。具体的，若对与目标容器配置信息对应的服务容器部署启动操作，则生成日志收集配置信息，并将日志收集配置信息与服务容器的容器标识进行合并，以生成目标日志配置信息；若对与目标容器配置信息对应的服务容器部署停止操作，则生成日志删除配置信息，并将日志删除配置信息与服务容器的容器标识进行合并，以生成目标日志配置信息。通过目标日志配置信息的生成，将存储于存储单元中的原始日志配置信息与服务容器的容器标识进行合并，以得到目标容器配置信息，方便了后续根据该目标容器配置信息对相应的目标服务容器的日志进行处理，使日志的处理更具有针对性。

在步骤s140中，采用所述目标日志配置信息重置所述存储单元中与所述目标服务容器对应的原始日志配置信息，以使所述处理单元根据所述目标日志配置信息对与所述目标服务容器对应的日志进行处理。

在本公开的示例性实施方式中，以目标日志配置信息重置存储单元中的与目标服务容器对应的原始日志配置信息，具体而言，若目标日志配置信息为日志收集或日志过滤信息，则采用该目标日志配置信息覆盖存储单元中的相应的原始日志配置信息；若目标日志配置信息为日志删除信息，则根据该日志删除信息将与目标服务容器对应的原始日志配置信息进行删除。

进一步的，继续参照图2所示，将重置后的目标日志配置信息存储于存储单元中，以便于处理单元检测到该目标日志配置信息，并根据该目标日志配置信息对与目标服务容器对应的日志进行处理操作。

综上可知，日志处理系统中的用于对服务容器对应的配置信息进行管理的控制单元，作为日志处理系统的控制管理服务中心，通过监测和获取存储单元中的容器配置信息的改变，并根据该容器配置信息进行相应的服务容器部署操作，并根据相应的部署操作生成目标日志配置进行，使整个系统在其管理下能够自动完成服务容器日志的处理，提高了日志处理的效率。

图1所示本公开示例性实施方式的技术方案是从控制单元(即日志处理系统中的用于对服务容器对应的配置信息进行管理的控制单元)的角度对本公开的示例性实施方式的docker服务容器日志的处理方法进行了说明，以下结合图5从日志处理系统中的根据配置信息对服务容器进行日志处理的处理单元的角度对本公开的示例性实施方式的docker服务容器日志的处理方法进行阐述：

步骤s510：根据所述存储单元中的目标容器配置信息，获取与所述目标容器配置信息对应的目标服务容器。

在本公开的示例性实施方式中，目标容器配置信息为存储单元中的发生改变后的容器配置信息，可以获取控制单元根据该目标容器配置信息，对与目标容器配置信息对应的服务容器进行部署操作后得到的服务容器，作为目标服务容器。

步骤s520：监测所述存储单元中的与所述目标服务容器对应的原始日志配置信息是否被所述控制单元重置。

在本公开的示例性实施方式中，处理单元将实时监测存储单元中的日志配置信息是否发生重置，以便于根据重置后的日志配置信息进行相应的日志处理操作。

步骤s530：若所述原始日志配置信息发生重置，则根据重置后的目标日志配置信息对与所述目标服务容器对应的日志进行处理。

在本公开的示例性实施方式中，由于存储单元中的日志配置信息并不是处理单元能够直接识别到的配置信息，因此若检测到目标服务容器的原始日志配置信息发生了重置，则首先通过一预设模板对重置后的目标日志配置信息进行渲染，以获取当前日志配置信息；然后，根据该当前日志配置信息，生成日志配置文件，并根据日志配置文件，对与目标服务容器对应的日志进行处理。需要说明的是，重置后的目标日志配置信息包括日志收集信息、日志过滤信息和日志删除信息，相应的，根据该日志配置信息生成的日志配置文件也包括日志收集信息、日志过滤信息和日志删除信息。当然，对于一些非固定配置，没有固定的模板供渲染，还可以直接将相关的日志配置信息生成日志配置文件。

此外，日志配置文件包括与目标服务容器对应的容器标识和待处理日志的日志类型；具体而言，图6示出了根据日志配置文件对与目标服务容器对应的日志进行处理的流程图，如图6所示，该日志处理过程包括步骤s610和步骤s620：在步骤s610中，根据容器标识和待处理日志的日志类型，获取与目标服务容器对应的日志路径；在步骤s620中，根据日志路径获取日志路径下的与目标服务容器对应的日志，并对日志进行处理。具体而言，根据与目标服务容器对应的日志路径对相应的目标服务容器的日志进行日志收集信息、日志过滤信息或日志删除信息。

其中，若重置后的目标日志配置信息为日志收集信息时，则根据该日志收集信息生成日志配置文件后，在根据该日志配置文件对目标服务容器的日志进行收集后，可以将收集到的日志输出至预设存储中心，该预设存储中心可以是实时日志存储服务的一种，本公开对此不做具体限定。需要说明的是，处理单元还可以将根据目标日志配置信息获得的相应的目标服务容器的日志挂载到约定的宿主机相应的路径下，再根据实际需求输出至预设存储中心。

此外，还可以获取用户的自定义日志配置信息，并根据自定义日志配置信息生成日志配置文件；然后根据该日志配置文件，对与目标服务容器对应的日志进行处理。具体而言，对于服务容器自身的容器日志的处理时，一方面可以根据上述方式根据容器配置信息自动加载容器的部署以及对相应的目标服务容器的日志的处理；另一方面，还可以通过在处理单元启动时添加相应的参数以实现对服务容器自身日志的收集或统一日志的输出路径等。例如，当处理单元配置了以gelf(一种应用日志驱动)方式收集服务容器自身的日志时，可以通过在其启动时的配置参数中添加log_config配置信息，基于该配置信息将触发处理单元生成相应的日志配置文件，并根据该日志配置文件对服务容器自身的日志的收集，当然，这是用户根据实际需要手动添加自定义配置信息。

此外，在本公开的示例性实施方式中，还提供了一种docker服务容器日志的处理装置，应用于日志处理系统中的用于对服务容器对应的配置信息进行管理的控制单元，所述日志处理系统还包括服务容器、用于存储与所述服务容器对应的配置信息的存储单元和根据所述配置信息对所述服务容器进行日志处理的处理单元。

参考图7所示，该docker服务容器日志的处理装置700可以包括容器配置信息获取模块710、目标服务容器获取模块720、日志配置信息生成模块730以及日志处理模块740。具体地，

容器配置信息获取模块710，用于从所述存储单元中获取与所述服务容器对应的容器配置信息；

目标服务容器获取模块720，用于根据目标容器配置信息对与所述目标容器配置信息对应的服务容器执行部署操作，以获取目标服务容器，其中所述目标容器配置信息包含于所述容器配置信息中；

日志配置信息生成模块730，用于根据所述部署操作，生成目标日志配置信息；

日志处理模块740，用于采用所述目标日志配置信息重置所述存储单元中与所述目标服务容器对应的原始日志配置信息，以使所述处理单元根据所述目标日志配置信息对与所述目标服务容器对应的日志进行处理。

图8示出了本公开另一示例性实施方式的docker服务容器日志的处理装置，应用于日志处理系统中的根据配置信息对服务容器进行日志处理的处理单元，所述日志处理系统还包括服务容器、用于存储与所述服务容器对应的配置信息的存储单元和用于对所述服务容器对应的配置信息进行管理的控制单元；该docker服务容器日志的处理装置800可以包括目标服务容器获取模块810、监测模块820以及日志处理模块830。具体地，

目标服务容器获取模块810，用于根据所述存储单元中的目标容器配置信息，获取与所述目标容器配置信息对应的目标服务容器；

监测模块820，用于监测所述存储单元中的与所述目标服务容器对应的原始日志配置信息是否被所述控制单元重置；

日志处理模块830，用于若所述原始日志配置信息发生重置，则根据重置后的目标日志配置信息对与所述目标服务容器对应的日志进行处理。

上述装置中各模块/单元的具体细节在方法部分的实施方式中已经详细说明，因此不再赘述。

此外，在本公开示例性实施方式中，还提供了一种能够实现上述方法的计算机存储介质。其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施例中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施例的步骤。

参考图9所示，描述了根据本公开的示例性实施方式的用于实现上述方法的程序产品900，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

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

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

此外，在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施例、完全的软件实施例(包括固件、微代码等)，或硬件和软件方面结合的实施例，这里可以统称为“电路”、“模块”或“系统”。

下面参照图10来描述根据本公开的这种实施例的电子设备1000。图10显示的电子设备1000仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图10所示，电子设备1000以通用计算设备的形式表现。电子设备1000的组件可以包括但不限于：上述至少一个处理单元1010、上述至少一个存储单元1020、连接不同系统组件(包括存储单元1020和处理单元1010)的总线1030、显示单元1040。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1010执行，使得所述处理单元1010执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施例的步骤。

存储单元1020可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)1021和/或高速缓存存储单元1022，还可以进一步包括只读存储单元(rom)1023。

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

总线1030可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备1000也可以与一个或多个外部设备1100(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1000交互的设备通信，和/或与使得该电子设备1000能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口1050进行。并且，电子设备1000还可以通过网络适配器1060与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器1060通过总线1030与电子设备1000的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1000使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施例的方法。

此外，上述附图仅是根据本公开示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

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