CN110442506B - 一种日志获取方法、装置、业务服务器、系统及存储介质 - Google Patents

Abstract

本发明实施例提供一种日志获取方法、装置、业务服务器、系统及存储介质，其中方法包括：从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志；判断所述日志是否为第一容器的日志，所述第一容器由用户端预先指定；若所述日志为所述第一容器的日志，将所述日志发送给所述用户端。本发明实施例可提升日志获取的实时性。

Description

一种日志获取方法、装置、业务服务器、系统及存储介质

技术领域

本发明实施例涉及数据处理技术领域，具体涉及一种日志获取方法、装置、业务服务器、系统及存储介质。

背景技术

基于容器的虚拟化技术是当前虚拟化技术的热点，容器技术通过隔离进程和资源，可实现轻量级的虚拟化。在容器的虚拟化技术下，基于容器的应用容器引擎，可以让应用程序的开发者打包应用程序以及依赖包到可移植的镜像中，然后发布到宿主机上实现虚拟化，从而利用应用程序所在的镜像可快速创建并运行容器，在容器创建并运行后，应用程序即部署完成。

在容器的虚拟化技术下，应用程序运行于应用容器引擎的容器中，应用程序的运行以及容器的运行会产生相应的日志，即容器日志涉及容器内运行的应用程序的日志和/或容器自身的日志；容器日志在定位容器问题或应用程序问题等方面具有重要的应用，因此获取容器日志显得尤为必要。

然而，目前的日志获取方式，存在获取日志的实时性不足的问题。

发明内容

有鉴于此，本发明实施例提供一种日志获取方法、装置、业务服务器、系统及存储介质，以提升日志获取的实时性。

为实现上述目的，本发明实施例提供如下技术方案：

一种日志获取方法，包括：

从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志；

判断所述日志是否为第一容器的日志，所述第一容器由用户端预先指定；

若所述日志为所述第一容器的日志，将所述日志发送给所述用户端。

可选的，所述设定监听地址包括所述应用容器引擎的日志开放端口；所述从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志包括：

当所述应用容器引擎中运行的日志监控服务，监控到所述应用容器引擎产生日志时，从所述日志开放端口获取所述日志监控服务监控到的日志。

可选的，所述判断所述日志是否为第一容器的日志包括：

解析所述日志，以确定所述日志对应的容器标识；

判断所述容器标识与预记录的所述用户端的用户信息中的第一容器标识是否相对应；其中，所述第一容器标识为所述第一容器的标识，所述第一容器标识由所述用户端预先上传。

可选的，所述将所述日志发送给所述用户端包括：

基于与所述用户端建立的双向通信链接，将所述日志发送给所述用户端。

可选的，所述方法还包括：

获取所述用户端通过所述双向通信链接上传的目标信息，所述目标信息至少包括所述第一容器标识；

在所述用户端的用户信息中记录所述第一容器标识。

可选的，所述通过所述日志开放端口获取所述日志包括：

基于传输控制协议，从所述日志开放端口获取所述日志监控服务监控到的日志；

或，基于用户数据报协议，从所述日志开放端口获取所述日志监控服务监控到的日志。

可选的，所述方法还包括：

接收所述用户端发送的历史日志获取请求，所述历史日志获取请求用于请求第二容器的历史日志；

根据所述历史日志获取请求，从应用容器引擎获取第二容器的历史日志；

将所述第二容器的历史日志，发送给用户端。

可选的，所述接收所述用户端发送的历史日志获取请求包括：

基于超文本传输协议，接收所述用户端发送的携带第二容器标识的历史日志获取请求；

所述根据所述历史日志获取请求，从应用容器引擎获取第二容器的历史日志包括：

通过所述应用容器引擎的应用程序编程接口提供的超文本传输协议，从所述应用容器引擎获取第二容器标识对应的历史日志；

所述将所述第二容器的历史日志，发送给用户端包括：

基于超文本传输协议，将所述历史日志发送给用户端。

本发明实施例还提供一种日志获取装置，包括：

监听服务组件，用于基于传输控制协议或者用户数据报协议，从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志；

双向通信链接服务组件，用于获取所述监听服务组件监听的日志，判断所述日志是否为用户端预先指定的第一容器的日志；若所述日志为所述第一容器的日志，基于与所述用户端的双向通信链接，将所述日志发送给所述用户端。

可选的，所述双向通信链接服务组件，还用于：

获取所述用户端通过所述双向通信链接上传的目标信息，所述目标信息至少包括第一容器的第一容器标识；在所述用户端的用户信息中记录所述第一容器标识；

所述双向通信链接服务组件，用于判断所述日志是否为用户端预先指定的第一容器的日志，包括：

解析所述日志，以确定所述日志对应的容器标识；

判断所述容器标识与预记录的所述用户端的用户信息中的第一容器标识是否相对应。

可选的，所述装置还包括：

超文本传输协议服务组件，用于基于超文本传输协议，接收所述用户端发送的历史日志获取请求，所述历史日志获取请求用于请求第二容器的历史日志；通过所述应用容器引擎的应用程序编程接口提供的超文本传输协议，从所述应用容器引擎获取第二容器的历史日志；基于超文本传输协议，将所述第二容器的历史日志发送给用户端。

可选的，所述监听服务组件和所述双向通信链接服务组件集成于同一服务器设备中；所述监听服务组件和所述双向通信链接服务组件之间通过组件间通信进行通信。

可选的，所述监听服务组件和所述双向通信链接服务组件属于不同的服务器设备，所述监听服务组件和所述双向通信链接服务组件之间基于双向通信链接进行通信。

本发明实施例还提供一种业务服务器，所述业务服务器被配置为执行上述所述的日志获取方法。

本发明实施例还提供一种日志获取系统，包括：应用容器引擎，用户端，分别与所述应用容器引擎及所述用户端通信的如上述所述的业务服务器。

本发明实施例还提供一种存储介质，所述存储介质存储执行上述所述的日志获取方法的程序。

本发明实施例提供的日志获取方法，可从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志，从而在应用容器引擎产生新的日志时，本发明实施例可从所述设定监听地址，自动监听到应用容器引擎产生的新的日志，实现监听应用容器引擎实时产生的日志；并且，在用户端预先指定第一容器的情况下，本发明实施例可在监听到应用容器引擎产生新的日志时，判断所述日志是否为用户端需要获取的第一容器的日志；进而，在所述日志为所述第一容器的日志时，本发明实施例可确定监听到的日志为用户端需要获取的日志，将所述日志发送给用户端。

可见，本发明实施例可在自动监听到应用容器引擎产生新的日志，且所述日志为用户端需要获取的日志时，及时的将所述日志发送给用户端，实现在应用容器引擎产生用户端需要的日志时，及时的将该日志发送给用户端，使得用户端可及时的获取需要的日志，提升日志获取的实时性。进一步，由于本发明实施例可自动监听应用容器引擎产生的新的日志，而不需要定时刷新日志页面来监控应用容器引擎是否产生了新的日志，因此本发明实施例还可减少日志获取涉及的资源浪费。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本发明实施例提供的日志获取系统的架构框图；

图2为本发明实施例提供的日志获取方法的交互流程图；

图3为业务服务器通过docker的日志开放端口获取日志的过程示例图；

图4为本发明实施例提供的日志获取系统的另一架构框图；

图5为本发明实施例提供的日志获取系统的示例图；

图6为本发明实施例提供的日志获取方法的另一交互流程图；

图7为本发明实施例提供的日志获取方法的再一交互流程图；

图8为本发明实施例提供的日志获取系统的再一架构框图；

图9为本发明实施例提供的业务服务器的硬件结构图。

具体实施方式

目前的日志获取方式主要是通过定时刷新容器的日志页面，以获取日志；然而，通过定时刷新日志页面来获取日志的方式，并无法在新日志产生时，即时的获取到日志，同时，定时刷新日志页面存在浪费资源的问题(如浪费流量、带宽等资源)；可见，目前的日志获取方式存在获取日志的实时性不足，且存在资源浪费的问题。

基于此，本发明实施例提供改进的日志获取方案，以提升日志获取的实时性，并且减少日志获取涉及的资源浪费。下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在一种可选实现中，图1示出了本发明实施例提供的日志获取系统的一种可选架构，本发明实施例提供的日志获取方法可选基于图1所示系统实施，如图1所示，本发明实施例提供的日志获取系统可以包括：docker(应用容器引擎)10，业务服务器20和用户端30；

docker是指应用容器引擎，docker可提供基于容器的应用程序快速自动化部署的解决方案，docker可以让应用程序的开发者打包应用程序以及依赖包到可移植的镜像中，然后发布到宿主机上，从而实现基于容器的虚拟化；具体的，利用docker可以使用应用程序所在的镜像，快速创建并启动容器，容器创建并运行后，应用程序即部署完成，一般的，一台物理机上可以部署多个容器，每个容器之间相互隔离，该物理机一般被称为宿主机；

业务服务器20为本发明实施例主要实现日志获取的服务器设备，可选的，业务服务器可以是由单台服务器设备实现，也可以是由多台服务器设备组成的服务器群组实现；

用户端30为具有日志获取需求的用户设备，在本发明实施例中，用户端可向业务服务器预先指定第一容器，以表示用户端需要获取第一容器的日志，从而业务服务器20可利用本发明实施例提供的日志获取方法，在docker产生新的日志，且该日志为用户端指定的第一容器的日志时，将该日志发送给用户端，实现在应用容器引擎产生用户端需要的日志时，及时的将该日志发送给用户端。

可选的，第一容器可以是任一容器，第一容器可以由用户端指定，本发明实施例并不局限。

基于图1所示日志获取系统，图2示出了本发明实施例提供的日志获取方法的一种可选交互流程，如图2所示，该流程可以包括：

步骤S10、业务服务器从docker的设定监听地址，监听docker产生的日志。

可选的，docker的设定监听地址可以是设定的docker开放的日志对外传输地址，通过该日志对外传输地址，docker可将日志传输给外部设备；在本发明实施例中，业务服务器可利用docker开放的日志对外传输地址，监听docker产生的日志，从而在docker产生新的日志时，业务服务器可监听到该新的日志。

在一种可选实现中，docker的设定监听地址可以包括：docker ip(InternetProtocol，互联网协议地址)以及日志开放端口；其中，docker ip可以用于业务服务器定位docker的网络地址；docker的日志开放端口是docker对外开放的日志传输端口，本发明实施例可开放docker的日志开放端口，从而利用docker的日志开放端口，将docker产生的日志传输给业务服务器；可选的，docker的日志开放端口的端口号可以根据实际情况而定，一般的，docker的日志开放端口可以是docker的2375端口，当然本发明实施例并不局限docker的日志开放端口的端口号形式；

也就是说，基于docker ip，业务服务器可定位docker的网络地址，基于docker的日志开放端口，业务服务器可通过该端口获取docker产生的日志；

在进一步的一种可选实现中，本发明实施例可在docker中运行监控日志文件的日志监控服务，从而在日志监控服务监控到docker产生日志时，业务服务器可通过docker的日志开放端口，获取日志监控服务监控到的日志；可选的，图3示例了业务服务器通过docker的日志开放端口获取docker产生的日志的过程，如图3所示，docker中运行有监控日志文件的日志监控服务，该日志监控服务可以监控docker产生的新的日志，从而在该日志监控服务监控到docker产生新的日志时，日志监控服务可通过docker的日志开放端口，将监控到的新的日志，传输给业务服务器；也就是说，当docker中运行的日志监控服务，监控到docker产生日志时，业务服务器可从docker的日志开放端口获取所述日志监控服务监控到的日志。

步骤S11、业务服务器判断所述日志是否为第一容器的日志，若否，执行步骤S12，若是，执行步骤S13。

在本发明实施例中，需要获取日志的用户端可以向业务服务器预先指定第一容器，以表示用户端需要获取第一容器的日志，也就是说，docker产生的第一容器的日志为本发明实施例需要实时传输给用户端的日志，第一容器可以是用户端预先指定的任一容器，本发明实施例并不局限。

通过步骤S10，业务服务器可在docker产生新的日志时，监听到docker产生的日志。当业务服务器获取到docker产生的日志时，通过步骤S11，业务服务器可判断该日志是否为第一容器的日志，若否，则认为该日志不是用户端需要的日志，若是，则认为该日志为用户端需要获取的日志。

可选的，用户端可以向业务服务器预先指定第一容器标识(即第一容器的容器标识)，从而实现向业务服务器预先指定第一容器；可选的，容器标识可以是标识容器的信息，以实现不同容器之间的区分，容器标识例如容器ID(Identity document，身份标识号)等；

进而，业务服务器可判断监听到的日志对应的容器标识，是否与第一容器标识相对应，以实现判断监听到的日志是否为第一容器的日志；可选的，在一种实现中，业务服务器可解析所述日志，以确定所述日志对应的容器标识，从而判断所述容器标识与第一容器标识是否相对应；可选的，第一容器标识可以由用户端预先上传给业务服务器，并由业务服务器记录在所述用户端的用户信息中，相应的，业务服务器可判断所述日志对应的容器标识，与预记录的所述用户端的用户信息中的第一容器标识是否相对应。

当然，通过监听到的日志对应的容器标识与第一容器标识的比对，实现判断监听到的日志是否为第一容器的日志的方式仅是可选的，本发明实施例也可支持其他可能的判断方式，例如本发明实施例也可能基于日志的类型，判断监听到的日志是否为第一容器的日志，示例的，在预先指定第一容器，且第一容器的日志的类型为特定类型时，本发明实施例可通过判断监听到的日志的类型是否为该特定类型，以实现判断监听到的日志是否为第一容器的日志。本发明实施例并不局限判断监听到的日志是否为第一容器的日志的方式。

步骤S12、结束流程。

如果所述日志不为第一容器的日志，则本发明实施例可结束流程。

步骤S13、业务服务器将所述日志发送给用户端。

如果所述日志为第一容器的日志，说明业务服务器当前监听到的docker产生的日志为用户端需要获取的日志，从而业务服务器可将所述日志发送给用户端，以使得用户端获取到需要获取的日志。

可选的，本发明实施例提供的日志获取方法，可针对docker任一新产生的日志进行执行，当业务服务器监听到docker任一新产生的日志，且该日志为用户端预先指定的第一容器的日志时，业务服务器可将该日志发送给用户端。

本发明实施例提供的日志获取方法，可从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志，从而在应用容器引擎产生新的日志时，本发明实施例可从所述设定监听地址，自动监听到应用容器引擎产生的新的日志，实现监听应用容器引擎实时产生的日志；并且，在用户端预先指定第一容器的情况下，本发明实施例可在监听到应用容器引擎产生新的日志时，判断所述日志是否为用户端需要获取的第一容器的日志；进而，在所述日志为所述第一容器的日志时，本发明实施例可确定监听到的日志为用户端需要获取的日志，将所述日志发送给用户端。

可见，本发明实施例可在自动监听到应用容器引擎产生新的日志，且所述日志为用户端需要获取的日志时，及时的将所述日志发送给用户端，实现在应用容器引擎产生用户端需要的日志时，及时的将该日志发送给用户端，使得用户端可及时的获取需要的日志，提升日志获取的实时性。进一步，由于本发明实施例可自动监听应用容器引擎产生的新的日志，而不需要定时刷新日志页面来监控应用容器引擎是否产生了新的日志，因此本发明实施例还可减少日志获取涉及的资源浪费。

在一种可选实现中，业务服务器可通过设置多个服务组件，以实现本发明实施例提供的日志获取方法，在业务服务器由单个服务器设备实现时，该多个服务组件可以集成于同一服务器设备中，在业务服务器为多个服务器设备组成的服务器群组时，该多个服务组件可以属于不同的服务器设备；以下描述的内容可以支持服务组件集成于同一服务器设备的情况，也可以支持服务组件属于不同的服务器设备的情况。

可选的，图4示出了本发明实施例提供的日志获取系统的另一种可选架构，结合图1和图4所示，在本发明实施例中，业务服务器可以具有监听服务组件和双向通信链接服务组件；监听服务组件可与docker和双向通信链接服务组件相通信，双向通信链接服务组件可与用户端相通信；

可选的，监听服务组件可以基于传输控制协议(TCP，Transmission ControlProtocol)，或者用户数据报协议(UDP，User Datagram Protocol)与docker相通信；例如，监听服务组件可基于TCP或者UDP协议，从docker的设定监听地址，监听docker产生的日志；在一种示例中，监听服务组件可以是TCP服务组件或UDP服务组件；

可选的，双向通信链接服务组件可以基于双向通信链接与用户端相通信，双向通信链接服务组件可基于双向通信链接，确定用户端预先指定的第一容器，以及将docker产生的第一容器的日志发送给用户端；在一种示例中，双向通信链接例如websocket链接，双向通信链接服务组件可以是websocket服务组件；需要说明的是，websocket是HTML5提供的一种在单个TCP链接上进行全双工通讯的协议，例如websocket支持在浏览器和服务器之间建立一个不受限的双向通信的通道；

图4所示系统中，监听服务组件可与双向通信链接服务组件相通信，从而监听服务组件可将监听到的docker产生的日志，传输给双向通信链接服务组件；进而，双向通信链接服务组件在确定所述日志为第一容器的日志时，可基于双向通信链接，将所述日志发送给用户端；

可选的，如果监听服务组件和双向通信链接服务组件集成于同一服务器设备，则监听服务组件和双向通信链接服务组件之间可通过组件间通信(例如进程间通信等)进行通信，如果监听服务组件和双向通信链接服务组件属于不同的服务器设备，则监听服务组件和双向通信链接服务组件之间可通过双向通信链接进行通信；本发明实施例对于以上两种情况均可实现支持。

在一种日志获取系统的示例中，如图5所示，监听服务组件可以是UDP服务组件(当然监听服务组件也可以选用TCP服务组件，本发明实施例在此以UDP服务组件进行示例)，UDP服务组件与docker之间可通过UDP协议通信，双向通信链接服务组件可以是websocket服务组件，websocket服务组件可与用户端之间通过websocket链接实现通信；在UDP服务组件和websocket服务组件属于不同的服务器设备时，UDP服务组件与websocket服务组件之间可通过websocket链接实现通信，在UDP服务组件和websocket服务组件集成于同一服务器设备时，UDP服务组件与websocket服务组件之间可通过组件间通信进行通信。

基于上述日志获取系统，图6示出了本发明实施例提供的日志获取方法的另一交互流程，如图6所示，该流程可以包括：

步骤S20、双向通信链接服务组件建立与用户端的双向通信链接。

双向通信链接服务组件可建立与用户端的双向通信链接，从而使得双向通信链接服务组件与用户端之间可存在不受限的双向通信通道。

在步骤S20的一种示例中，websocket服务组件可以建立与用户端的websocket链接。

可选的，通过步骤S20可以实现业务服务器与用户端之间建立双向通信链接。

步骤S21、用户端通过所述双向通信链接，向双向通信链接服务组件上传目标信息；所述目标信息至少包括第一容器标识。

基于双向通信链接服务组件与用户端之间的双向通信链接，用户端可链接双向通信链接服务组件，从而向双向通信链接服务组件指定需要获取的日志所属的第一容器，即实现用户端向业务服务器指定第一容器；在本发明实施例的可选实现中，不同的容器可以由容器标识区分，用户端可通过双向通信链接，向双向通信链接服务组件上传至少包括第一容器标识的目标信息，以实现向双向通信链接服务组件指定第一容器。当然，步骤S21仅是用户端基于双向通信链接，向双向通信链接服务组件指定第一容器的一种可选方式。

在步骤S21的一种示例中，用户端可通过websocket链接，向websocket服务组件上传所述目标信息。

可选的，通过步骤S21，业务服务器可以获取到用户端通过所述双向通信链接上传的目标信息。

步骤S22、双向通信链接服务组件在所述用户端的用户信息中记录所述第一容器标识。

双向通信链接服务组件获取到所述目标信息后，可解析所述目标信息，得到所述第一容器标识，从而添加第一容器标识到用户端的用户信息中，例如，双向通信链接服务组件可添加第一容器标识到用户端的用户信息的指定字段中。

可选的，通过步骤S22，业务服务器可在所述用户端的用户信息中记录所述第一容器标识。

在步骤S22的一种示例中，websocket服务组件可在用户端的用户信息中记录第一容器标识。

基于步骤S20至步骤S21，双向通信链接服务组件可预记录用户端指定的第一容器标识，从而实现双向通信链接服务组件对用户端指定的第一容器的记录。

步骤S23、监听服务组件基于TCP或UDP协议，从docker的日志开放端口获取日志监控服务监控到的日志。

可选的，监听服务组件可基于TCP或UDP协议监听docker中产生的新日志，监听服务组件的监听地址可以为docker ip及docker的日志开放端；本发明实施例可在docker的docker compose设置docker产生的新日志基于TCP或UDP协议传输，从而基于TCP或UDP协议，监听服务组件可从监听地址，监听到docker产生的新日志；需要说明的，dockercompose是docker的开源项目，负责实现对容器集群的快速编排。

在一种更为具体的可选实现中，本发明实施例可开放docker的日志开放端口(例如开放docker的2375日志端口)，并在docker中运行基于TCP或UDP的日志监控服务，从而在日志监控服务监控到docker产生日志时，该日志监控服务可通过日志开放端口，基于TCP或UDP协议，向监听服务组件传输监控到的日志，从而使得监听服务组件基于TCP或UDP协议，从docker的日志开放端口获取日志监控服务监控到的日志。

可选的，通过步骤S23，业务服务器可基于TCP或UDP协议，从docker的日志开放端口获取日志监控服务监控到的日志。

在步骤S23的一种示例中，TCP服务组件可基于TCP协议，从docker的日志开放端口获取日志监控服务监控到的日志；或者，UDP服务组件可基于UDP协议，从docker的日志开放端口获取日志监控服务监控到的日志。

在本发明实施例中，监听服务组件可从TCP或UDP协议中择一使用，可选的，监听服务组件可以是TCP服务组件或者UDP服务组件；需要说明的是，UDP相比于TCP具有更快的传输速度，不需经过多次握手链接，当然UDP的可靠性会低于TCP，因此监听服务组件选择使用TCP或UDP中的哪一种协议，可以根据实际情况设定。

步骤S24、监听服务组件传输所述日志给双向通信链接服务组件。

监听服务组件获取到所述日志后，可将所述日志传输给双向通信链接服务组件；可选的，如果监听服务组件与双向通信链接服务组件集成于同一服务器设备，则监听服务组件可通过组件间通信，将所述日志传输给双向通信链接服务组件；如果监听服务组件与双向通信链接服务组件属于不同的服务器设备，则监听服务组件与双向通信链接服务组件间可建立双向通信链接，从而监听服务组件可通过双向通信链接，将所述日志传输给双向通信链接服务组件。

在步骤S24的一种示例中，TCP服务组件或UDP服务组件，可传输所述日志给websocket服务组件。

步骤S25、双向通信链接服务组件解析所述日志，以确定所述日志对应的容器标识。

双向通信链接服务组件接收到监听服务组件传输的日志后，可解析所述日志，从而获得所述日志对应的容器标识(例如容器ID)；当然，解析所述日志还可获得更多的内容，例如，日志属于的宿主机，日志产生时间，日志类型以及日志内容等。

在步骤S25的一种示例中，websocket服务组件可解析所述日志，以确定所述日志对应的容器标识。

步骤S26、双向通信链接服务组件判断所述容器标识与预记录的第一容器标识是否相对应，若否，执行步骤S27，若是，执行步骤S28。

双向通信链接服务组件获得所述容器标识后，可调取所述用户端的用户信息中预记录的第一容器标识，从而判断所述容器标识与预记录的第一容器标识是否相对应。

在步骤S26的一种示例中，websocket服务组件可判断所述容器标识与预记录的第一容器标识是否相对应。

可选的，步骤S25至步骤S26可以认为是业务服务器判断所述日志是否为第一容器的日志的一种可选实现方式。

步骤S27、结束流程。

双向通信链接服务组件判断所述容器标识与所述第一容器标识不对应，则认为所述日志不为用户端需要获取的日志，可结束后续流程。

步骤S28、双向通信链接服务组件，基于双向通信链接，将所述日志发送给所述用户端。

双向通信链接服务组件判断所述容器标识与所述第一容器标识相对应，则认为所述日志为用户端需要获取的日志，可基于与用户端的双向通信链接，将所述日志发送给所述用户端。

可选的，通过步骤S28可在所述日志为第一容器的日志时，实现业务服务器将所述日志发送给用户端。

在步骤S28的一种示例中，websocket服务组件可基于websocket链接，将所述日志发送给所述用户端。

本发明实施例通过自建的监听服务组件，可在docker产生新的日志时，自动监听到docker产生的日志，并将所述日志传递给自建的双向通信链接服务组件；通过自建的双向通信链接服务组件，本发明实施例可预记录用户端指定的第一容器，从而在双向通信链接组件判断所述日志为第一容器的日志时，将所述日志传递给用户端。本发明实施例通过自建的监听服务组件和双向通信链接服务组件，可在docker产生用户端需要的日志时，及时的将该日志发送给用户端，提升日志获取的实时性。并且监听服务组件可在docker产生新的日志时，自动监听到所述日志，减少日志获取涉及的资源浪费。

在进一步的可选实现中，双向通信链接服务组件可提供心跳检测接口，以供用户端检测用户端与双向通信链接服务组件的连接状态，从而在所述连接状态为连接中断时，用户端可实现断线重连，以便在用户端与双向通信链接服务组件的连接中断时，用户端可自动重新连接双向通信链接服务组件，避免在网络不稳定的环境中，用户端错过双向通信链接服务组件传输的重要信息；

具体的，在双向通信链接服务组件与用户端建立双向通信链接后，双向通信链接服务组件可通过心跳检测接口周期性的向用户端发送心跳信息，如果用户端检测到在连续的多个周期未接到心跳信息，则可认为用户端与双向通信链接服务组件间的连接中断，从而可请求重新连接双向通信链接服务组件。

在本发明实施例提供的进一步的可选实现中，业务服务器还可支持用户端请求docker的历史日志；可选的，图7示出了本发明实施例提供的日志获取方法的再一交互流程，利用该交互流程，本发明实施例可在用户端请求docker的历史日志时，将所述历史日志发送给用户端，如图7所示，该交互流程可以包括：

步骤S30、用户端向业务服务器发送历史日志获取请求，所述历史日志获取请求用于请求第二容器的历史日志。

可选的，第二容器可以是任一容器，第二容器可与前文描述的第一容器相同，也可以不同；需要说明的是，前文涉及的日志获取方法的内容是针对第一容器的实时日志进行获取，而本发明实施例在此处针对第二容器的历史日志进行获取。

在一种可选实现中，历史日志获取请求可以携带第二容器标识(第二容器的容器标识)，以实现向业务服务器请求第二容器的历史日志。

可选的，本发明实施例在支持docker的历史日志获取方面，用户端与业务服务器可通过HTTP(HyperText Transfer Protocol,超文本传输协议)协议进行通信，例如，用户端可通过HTTP协议向业务服务器发送所述历史日志获取请求，以向业务服务器指定需要获取第二容器的历史日志；也就是说，在docker的实时日志获取方面，本发明实施例中用户端与业务服务器间通过双向通信链接(如websocket链接)进行通信，而在docker的历史日志获取方面，本发明实施例中用户端与业务服务器间通过HTTP协议进行通信。

步骤S31、业务服务器根据所述历史日志获取请求，从docker获取第二容器的历史日志。

可选的，本发明实施例在支持docker的历史日志获取方面，业务服务器可通过docker api(Application Programming Interface，应用程序接口)提供的HTTP协议，获取docker中容器的状态、名称、容器标识(如ID)等信息；从而，用户端在向业务服务器指定获取第二容器的历史日志时，业务服务器可通过docker api提供的HTTP协议，从docker获取第二容器的历史日志。

在一种可选实现中，业务服务器可以容器标识获取指定容器的指定日期、数量的历史日志；从而，在本发明实施例中，业务服务器可通过docker api提供的HTTP协议，从docker获取第二容器标识对应的历史日志。

步骤S32、业务服务器将所述第二容器的历史日志，发送给用户端。

可选的，业务服务器可基于HTTP协议，将所述第二容器的历史日志发送给用户端，以实现用户端对docker历史日志的获取。

在一种可选实现中，业务服务器可通过设置超文本传输协议服务组件(HTTP服务组件)，以支持docker的历史日志获取；可选的，图8示出了本发明实施例提供的日志获取系统的再一种可选架构，结合图4和图5所示，在本发明实施例中，业务服务器还可以具有HTTP服务组件；HTTP服务组件在本发明实施例中主要用于实现获取docker的历史日志，HTTP服务组件与docker可通过docker api通信，具体可通过docker api提供的HTTP协议进行通信，HTPP服务组件与用户端可通过HTTP协议通信；

可选的，HTTP服务组件与监听服务组件和双向通信链接服务组件可以集成于同一服务器设备，当然，HTTP服务组件与监听服务组件和双向通信链接服务组件也可以属于不同的服务器设备。

本发明实施例可根据配置启动HTPP服务组件，HTPP服务组件可以具有获取docker宿主机信息以及其下所有容器信息的列表，从而HTPP服务组件可以获取docker环境的各项运行指标，例如docker已用内存，剩余内存，镜像信息等，从而HTTP服务组件可以基于运行指标检测到docker运行异常时，发出异常提醒，例如HTPP服务组件可以在检测到docker运行异常时，通过邮件提醒等方式向用户发出异常提醒，以便通过人工干预等方式解决导致docker运行异常的问题；可选的，在本发明实施例中，HTPP服务组件还可以容器的id来获取容器的历史日志以及操作容器的启动、停止、重启等功能。

基于图8所示日志获取系统，作为图7日志获取方法的一种示例，本发明实施例在docker历史日志获取方面的示例过程可以如下：

用户端通过HTTP协议，向HTTP服务组件指定第二容器标识，以请求获取第二容器的历史日志；可选的，用户端可通过HTPP协议，向HTTP服务组件发送携带第二容器标识的历史日志获取请求，相应的，HTTP服务组件可基于HTTP协议，接收到用户端发送的携带第二容器标识的历史日志获取请求；

HTTP服务组件通过docker api中的HTTP协议，从docker获取第二容器标识对应的历史日志；

HTPP服务组件基于HTTP协议，将所述历史日志发送用户端。

本发明实施例提供的日志获取方法，除可实现在docker产生用户端需要的日志时，及时的将该日志发送给用户端，使得用户端可及时的获取需要的日志，提升日志获取的实时性外，还可支持获取docker的历史日志，满足用户端多样的日志获取需求。

上文描述了本发明实施例提供的多个实施例方案，各实施例方案介绍的各可选方式可在不冲突的情况下相互结合、交叉引用，从而延伸出多种可能的实施例方案，这些均可认为是本发明实施例披露、公开的实施例方案。

下面对本发明实施例提供的日志获取装置进行介绍，下文介绍的日志获取装置可以认为是为实现本发明实施例提供的日志获取方法，所需设置的一种可选架构的服务组件。下文描述的日志获取装置的内容，可与上文描述的日志获取方法的内容相互对应参照。

在一种可选实现中，结合图4所示，本发明实施例提供的日志获取装置可以包括：监听服务组件和双向通信链接服务组件；

其中，监听服务组件，用于基于传输控制协议或者用户数据报协议，从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志；

双向通信链接服务组件，用于获取所述监听服务组件监听的日志，判断所述日志是否为用户端预先指定的第一容器的日志；若所述日志为所述第一容器的日志，基于与所述用户端的双向通信链接，将所述日志发送给所述用户端。

可选的，所述设定监听地址可以包括所述应用容器引擎的日志开放端口；监听服务组件，用于基于传输控制协议或者用户数据报协议，从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志，可以包括：

当所述应用容器引擎中运行的日志监控服务，监控到所述应用容器引擎产生日志时，基于传输控制协议或用户数据报协议，从所述日志开放端口获取所述日志监控服务监控到的日志。

可选的，双向通信链接服务组件可通过记录用户端指定的第一容器标识，以实现记录用户端预先指定的第一容器；进一步，双向通信链接服务组件，还可用于：

获取所述用户端通过所述双向通信链接上传的目标信息，所述目标信息至少包括第一容器的第一容器标识；在所述用户端的用户信息中记录所述第一容器标识；

相应的，双向通信链接服务组件，用于判断所述日志是否为用户端预先指定的第一容器的日志，可以具体包括：

解析所述日志，以确定所述日志对应的容器标识；

判断所述容器标识与预记录的所述用户端的用户信息中的第一容器标识是否相对应。

可选的，本发明实施例还可支持docker历史日志的获取；结合图8所示，本发明实施例提供的日志获取装置还可以包括：超文本传输协议服务组件；

其中，超文本传输协议服务组件，用于基于超文本传输协议，接收所述用户端发送的历史日志获取请求，所述历史日志获取请求用于请求第二容器的历史日志；通过所述应用容器引擎的应用程序编程接口提供的超文本传输协议，从所述应用容器引擎获取第二容器的历史日志；基于超文本传输协议，将所述第二容器的历史日志发送给用户端。

可选的，历史日志获取请求可以携带第二容器标识；超文本传输协议服务组件，用于通过所述应用容器引擎的应用程序编程接口提供的超文本传输协议，从所述应用容器引擎获取第二容器的历史日志，可以具体包括：

通过所述应用容器引擎的应用程序编程接口提供的超文本传输协议，从所述应用容器引擎获取第二容器标识对应的历史日志。

在一种可选实现中，本发明实施例提供的日志获取装置中的监听服务组件和双向通信链接服务组件可以集成于同一服务器设备中，从而，监听服务组件和双向通信链接服务组件之间通过组件间通信进行通信。当然，超文本传输协议服务组件也可与监听服务组件和双向通信链接服务组件集成于同一服务器设备中。

在另一种可选实现中，本发明实施例提供的日志获取装置中，监听服务组件和双向通信链接服务组件可以属于不同的服务器设备，从而监听服务组件和双向通信链接服务组件之间基于双向通信链接进行通信。当然，超文本传输协议服务组件也可与监听服务组件和双向通信链接服务组件属于不同的服务器设备。

本发明实施例还提供一种业务服务器，该业务服务器可以被配置为执行本发明实施例提供的日志获取方法。

在一种可选实现中，该业务服务器可以由单个服务器设备实现，可选的，该单个服务器设置可通过集成程序形式的上述服务组件，以执行本发明实施例提供的日志获取方法；示例的，图9示出了本发明实施例提供的业务服务器的一种可选硬件结构，包括：至少一个处理器1，至少一个通信接口2，至少一个存储器3和至少一个通信总线4；

可选的，处理器1可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。

存储器3可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

其中，存储器3存储有程序，处理器1调用存储器3所存储的程序，以执行本发明实施例提供的日志获取方法。

可选的，本发明实施例还可提供一种存储介质，该存储介质可以存储执行本发明实施例提供的日志获取方法的程序。

可选的，所述程序的细化功能和扩展功能可参照前文相应部分的描述，此处不再赘述。

在另一种可选实现中，本发明实施例提供的业务服务器可以由多台服务器设备实现，例如业务服务器可以包括：监听服务组件对应的服务器设备，双向通信链接服务组件对应的服务器设备，和超文本传输协议服务组件对应的服务器设备；也就是说，监听服务组件，双向通信链接服务组件，和超文本传输协议服务组件属于不同的服务器设备，通过各服务器设备之间的交互协作，实现本发明实施例提供的日志获取方法。

本发明实施例还提供一种日志获取系统，结合图1所示，该日志获取系统可以包括：应用容器引擎，用户端，分别与应用容器引擎及用户端通信的业务服务器；所述业务服务器可以被配置为执行本发明实施例提供的日志获取方法。

虽然本发明实施例披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。

Claims (13)

1.一种日志获取方法，其特征在于，包括：

从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志；

判断所述日志是否为第一容器的日志，所述第一容器由用户端预先指定；

若所述日志为所述第一容器的日志，将所述日志发送给所述用户端；

其中，所述设定监听地址包括所述应用容器引擎的日志开放端口；所述从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志包括：

当所述应用容器引擎中运行的日志监控服务，监控到所述应用容器引擎产生日志时，从所述日志开放端口获取所述日志监控服务监控到的日志；

所述判断所述日志是否为第一容器的日志包括：

解析所述日志，以确定所述日志对应的容器标识；

判断所述容器标识与预记录的所述用户端的用户信息中的第一容器标识是否相对应；其中，所述第一容器标识为所述第一容器的标识，所述第一容器标识由所述用户端预先上传。

2.根据权利要求1所述的日志获取方法，其特征在于，所述将所述日志发送给所述用户端包括：

基于与所述用户端建立的双向通信链接，将所述日志发送给所述用户端。

3.根据权利要求2所述的日志获取方法，其特征在于，还包括：

获取所述用户端通过所述双向通信链接上传的目标信息，所述目标信息至少包括所述第一容器标识；

在所述用户端的用户信息中记录所述第一容器标识。

4.根据权利要求1所述的日志获取方法，其特征在于，通过所述日志开放端口获取所述日志包括：

基于传输控制协议，从所述日志开放端口获取所述日志监控服务监控到的日志；

或，基于用户数据报协议，从所述日志开放端口获取所述日志监控服务监控到的日志。

5.根据权利要求1所述的日志获取方法，其特征在于，还包括：

接收所述用户端发送的历史日志获取请求，所述历史日志获取请求用于请求第二容器的历史日志；

根据所述历史日志获取请求，从应用容器引擎获取第二容器的历史日志；

将所述第二容器的历史日志，发送给用户端。

6.根据权利要求5所述的日志获取方法，其特征在于，所述接收所述用户端发送的历史日志获取请求包括：

基于超文本传输协议，接收所述用户端发送的携带第二容器标识的历史日志获取请求；

所述根据所述历史日志获取请求，从应用容器引擎获取第二容器的历史日志包括：

通过所述应用容器引擎的应用程序编程接口提供的超文本传输协议，从所述应用容器引擎获取第二容器标识对应的历史日志；

所述将所述第二容器的历史日志，发送给用户端包括：

基于超文本传输协议，将所述历史日志发送给用户端。

7.一种日志获取装置，其特征在于，包括：

监听服务组件，用于基于传输控制协议或者用户数据报协议，从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志；其中，所述设定监听地址包括所述应用容器引擎的日志开放端口；所述从应用容器引擎的设定监听地址，监听所述应用容器引擎产生的日志包括：当所述应用容器引擎中运行的日志监控服务，监控到所述应用容器引擎产生日志时，从所述日志开放端口获取所述日志监控服务监控到的日志；

双向通信链接服务组件，用于获取所述监听服务组件监听的日志，判断所述日志是否为用户端预先指定的第一容器的日志；若所述日志为所述第一容器的日志，基于与所述用户端的双向通信链接，将所述日志发送给所述用户端；所述双向通信链接服务组件，还用于：获取所述用户端通过所述双向通信链接上传的目标信息，所述目标信息至少包括第一容器的第一容器标识；在所述用户端的用户信息中记录所述第一容器标识；所述双向通信链接服务组件，用于判断所述日志是否为用户端预先指定的第一容器的日志，包括：解析所述日志，以确定所述日志对应的容器标识；判断所述容器标识与预记录的所述用户端的用户信息中的第一容器标识是否相对应。

8.根据权利要求7所述的日志获取装置，其特征在于，还包括：

超文本传输协议服务组件，用于基于超文本传输协议，接收所述用户端发送的历史日志获取请求，所述历史日志获取请求用于请求第二容器的历史日志；通过所述应用容器引擎的应用程序编程接口提供的超文本传输协议，从所述应用容器引擎获取第二容器的历史日志；基于超文本传输协议，将所述第二容器的历史日志发送给用户端。

9.根据权利要求7所述的日志获取装置，其特征在于，所述监听服务组件和所述双向通信链接服务组件集成于同一服务器设备中；所述监听服务组件和所述双向通信链接服务组件之间通过组件间通信进行通信。

10.根据权利要求7所述的日志获取装置，其特征在于，所述监听服务组件和所述双向通信链接服务组件属于不同的服务器设备，所述监听服务组件和所述双向通信链接服务组件之间基于双向通信链接进行通信。

11.一种业务服务器，其特征在于，所述业务服务器被配置为执行权利要求1-6任一项所述的日志获取方法。

12.一种日志获取系统，其特征在于，包括：应用容器引擎，用户端，分别与所述应用容器引擎及所述用户端通信的如权利要求11所述的业务服务器。

13.一种存储介质，其特征在于，所述存储介质存储执行权利要求1-6任一项所述的日志获取方法的程序。