CN113806160A - 一种监测配置文件的方法及装置、设备、存储介质 - Google Patents

Abstract

本申请公开了一种监测配置文件的方法及装置、设备、存储介质，其中，所述方法包括：启动定时任务；根据所述定时任务定时从服务端获取待监测的应用集合中每一应用的属性信息；将每一所述应用的属性信息与本地存储的配置文件库进行匹配，得到目标应用集合，其中，所述配置文件库用于记录所述客户端侧安装的属性信息；获取所述目标应用集合中每一应用的配置文件；将所述目标应用集合中每一应用的配置文件发送给服务端。这样，每经过一个定时周期，客户端无需升级就自动获取需要检测的应用范围和应用配置信息，并根据本地存储的配置文件库判断是否有必要进行比对，有必要时再上报给服务端，减少了人工的控制时间，提高了对于异常参数检测的时效性。

Description

一种监测配置文件的方法及装置、设备、存储介质

技术领域

本申请涉及互联网领域，涉及但不限定于一种监测配置文件的方法及装置、设备、存储介质。

背景技术

在计算机系统中，部署着各种各样的应用程序，这些应用程序只有适配运行环境的时候才能正常运行，为了适配运行环境，一般需要配置文件进行配置。服务端也需要必要的参数配置，例如端口号、超时时间等。而对于运行在它上面的应用，并不是一次就可以部署到位，需要后续的应用升级或者对出现的漏洞进行修补。那在这个二次改造过程中，就会出现文件之间的覆盖、操作失误导致参数配置错误等问题。

现有的配置文件检测系统有两种，第一种是基于人工比对进行检测，如通过文本对比工具beyond compare等比对配置文件，但对于数据量比较大的时候效率会非常低下。第一种人工比对的方法在数据量比较大、系统比较复杂的时候效率会非常低下，需要很大的人工维护成本。

第二种是配置文件检测系统，可以提供配置文件的比较，但缺乏对实际生产坏境复杂性的考虑，导致其方法的适应性以及实用性较低。对于第二种方法，通过对配置文件进行比较，获得变化的配置参数，缺点是难以适应多变的文件格式，现有的配置检测时效性比较低，没有实现自动获取各种配置信息并上报给服务端的功能。同时，在检测的过程中，不能支持文件比对类型的多样性，检测和校验功能的统一性以及交互界面的友好性。

发明内容

有鉴于此，本申请提供一种监测配置文件的方法及装置、设备、存储介质，达到减少了人工的控制时间，提高了对于异常参数检测的时效性的效果，解决了人工比对的方法效率低和配置文件检测系统检测异常参数时效性差的问题。

本申请的技术方案是这样实现的：

第一方面，本申请提供一种监测配置文件的方法，应用于客户端，所述方法包括：

启动定时任务；根据所述定时任务定时从服务端获取待监测的应用集合中每一应用的属性信息；将每一所述应用的属性信息与本地存储的配置文件库进行匹配，得到目标应用集合，其中，所述配置文件库用于记录所述客户端侧安装的属性信息；获取所述目标应用集合中每一应用的配置文件；将所述目标应用集合中每一应用的配置文件发送给服务端。

第二方面，本申请提供一种监测配置文件的方法，应用于服务端，所述方法包括：

响应客户端发送的应用脚本请求，将所述应用脚本发送给所述客户端；解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式；根据所述配置文件的类型确定用于校验所述配置文件的校验算法，其中，所述校验算法用于校验所述配置文件的版本号、路径、名称和格式；使用所述校验算法校验所述配置文件的版本号、路径、名称和格式；当校验不一致时，在展示界面标识出校验结果。

第三方面，本申请提供一种监测配置文件的装置，应用于客户端，所述装置包括启动模块、第一获取模块、匹配模块、第二获取模块和发送模块，其中：

所述启动模块，用于启动定时任务；所述第一获取模块，用于根据所述定时任务定时从服务端获取待监测的应用集合中每一应用的属性信息；所述匹配模块，用于将每一所述应用的属性信息与本地存储的配置文件库进行匹配，得到目标应用集合，其中，所述配置文件库用于记录所述客户端侧安装的属性信息；所述第二获取模块，用于获取所述目标应用集合中每一应用的配置文件；所述发送模块，用于将所述目标应用集合中每一应用的配置文件发送给服务端。

第四方面，本申请提供一种监测配置文件的装置，应用于服务端，所述装置包括响应模块、解析模块、确定模块、校验模块和标识模块，其中：

所述响应模块，用于响应客户端发送的应用脚本请求，将所述应用脚本发送给所述客户端；所述解析模块，用于解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式；所述确定模块，用于根据所述配置文件的类型确定用于校验所述配置文件的校验算法，其中，所述校验算法用于校验所述配置文件的版本号、路径、名称和格式；所述校验模块，用于使用所述校验算法校验所述配置文件的版本号、路径、名称和格式；所述标识模块，用于当校验不一致时，在展示界面标识出校验结果。

第五方面，本申请提供一种监测配置文件的设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述监测配置文件的方法中的步骤。

第六方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述监测配置文件的方法中的步骤。

本申请应用于客户端，首先客户端利用定时启动功能，定时从服务器接口获取待监测的应用集合中每一应用的属性信息，将每一应用的属性信息与本地存储的配置文件库进行匹配得到需要上报给服务端的配置文件。这样，客户端上报新的配置文件给服务端的过程中，引入定时机制，每经过一个定时周期，客户端无需升级就自动获取需要检测的应用范围和应用配置信息，并根据本地存储的配置文件库判断是否有必要进行比对，有必要时再上报给服务端，减少了人工的控制时间，提高了对于异常参数检测的时效性。

在一些实施例中，应用于客户端，首先客户端利用定时启动功能，定时从服务器接口获取脚本或软件，运行脚本或软件获取当前客户端的应用属性信息，将每一应用的属性信息与本地存储的配置文件库进行匹配得到需要上报给服务端的配置文件。这样，服务端以脚本或软件的形式提供给客户端，方便客户端获取待监测的应用集合中每一应用的属性信息。

在一些实施例中，应用于服务端，服务端解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式，根据所述配置文件的类型确定用于校验所述配置文件的校验算法，使用所述校验算法校验所述配置文件的版本号、路径、名称和格式，当校验不一致时，在展示界面标识出校验结果。这样实现了在服务端进行比对以及比对文件的多样性。基于服务端的文件比对，可以实现一个服务端服务于成百上千个客户端，从而通过服务端去控制客户端，检测效率有了很大的提升。同时在比对过程中，对于不同的文件格式，采取不同的文件解析方法，提高了文件解析比对的效率。对检测不一致的结果在界面上标识，增强了检测结果展示界面的友好性。

在一些实施例中，应用于服务端，服务端先要将添加待管理的客户端所有应用的属性信息和配置文件的路径信息，根据所述所有应用的属性信息和所述配置文件的路径信息，生成应用脚本。当客户端应用使用Docker镜像包部署时，需要复制得到所述配置文件的类型、版本号、路径、名称和格式；当应用的配置文件从镜像中复制出来后，可以直接解析。解析客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式，根据所述配置文件的类型确定用于校验所述配置文件的校验算法。当所述配置文件是Property类型时，确定使用键值对存储形式对应的校验算法；所述配置文件是XML类型时，确定使用Scheme解析技术校验算法。当校验不一致时，在展示界面标识出校验结果。这样具体描述了本申请支持Docker镜像包中应用配置文件读取和文件比对，针对不同类型的文件采用不用的校验方法，实现了在服务端进行比对以及比对文件的多样性。

附图说明

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

图1A为本申请实施例提供的一种监测配置文件的方法的流程示意图；

图1B为本申请实施例提供的另一种监测配置文件的方法的流程示意图；

图2为本申请实施例提供的再一种监测配置文件的方法的流程示意图；

图3为本申请实施例提供的又一种监测配置文件的方法的流程示意图；

图4A为本申请实施例提供的又一种监测配置文件的方法；

图4B为本申请实施例提供的又一种监测配置文件的方法流程示意图；

图5A为本申请实施例提供的一种监测配置文件的装置的组成结构示意图；

图5B为本申请实施例提供的另一种监测配置文件的装置的组成结构示意图

图6为本申请实施例提供的一种监测配置文件的设备的硬件实体示意图。

具体实施方式

本申请提出了一种计算机系统中用于配置检测的方法。通过将客户端修改升级后新的配置记录自动上报到服务端，并在服务端将新的配置记录和已有的原始记录进行校验和比对，根据配置管理的记录对于有变化的配置参数进行标记，通过发邮件或者短信的方式提醒管理人员，做后续处理。从而实现配置参数快速、精确的检测。该方案的性能在机器数量变大的时候，尤为明显。同时该技术支持获取Docker镜像包中文件配置，其中Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。支持扫描Tomcat、Redis、Mysql等配置文件并支持扩展其他软件扫描，支持文件比对告警邮件通知等功能。

本申请实施例提供一种监测配置文件的方法，应用于客户端，图1A为本申请实施例提供的一种监测配置文件的方法的流程示意图，如图1A所示，所述方法包括：

步骤S101、启动定时任务；

步骤S102、根据所述定时任务定时从服务端获取待监测的应用集合中每一应用的属性信息；

用户提前在服务端配置好需要监测的应用集合中每一应用的属性信息，每一应用的属性信息包括应用的名称和版本等。客户端根据定时任务定时从服务端接口获取待监测的应用集合中每一应用的属性信息。

步骤S103、将每一所述应用的属性信息与本地存储的配置文件库进行匹配，得到目标应用集合，其中，所述配置文件库用于记录所述客户端侧安装的属性信息；

本地存储的配置文件库用于记录所述客户端侧安装的应用名称、版本号等应用的属性信息。将从服务端获取待监测的应用集合中每一应用的属性信息与配置文件库进行匹配。先将每一应用的名称与所述配置文件库进行匹配，得到名称匹配上的应用集合；再将所述名称匹配上的应用集合中的每一所述应用的版本号与所述配置文件库进行匹配，得到所述目标应用集合。

步骤S104、获取所述目标应用集合中每一应用的配置文件；

在计算机系统中，部署着各种各样的应用程序，这些应用程序只有适配运行环境的时候才能正常运行，为了适配运行环境，一般需要配置文件进行配置。所以需要获取目标应用集合中每一应用的配置文件。

步骤S105、将所述目标应用集合中每一应用的配置文件发送给服务端。

服务器需要获取客户端当前的应用配置文件，对这些配置文件进行检测。

本申请实施例，应用于客户端，首先客户端利用定时启动功能，定时从服务器接口获取待监测的应用集合中每一应用的属性信息，将每一应用的属性信息与本地存储的配置文件库进行匹配得到需要上报给服务端的配置文件。这样，客户端上报新的配置文件给服务端的过程中，引入定时机制，每经过一个定时周期，客户端无需升级就自动获取需要检测的应用范围和应用配置信息，并根据本地存储的配置文件库判断是否有必要进行比对，有必要时再上报给服务端，减少了人工的控制时间，提高了对于异常参数检测的时效性。

本申请实施例提供一种监测配置文件的方法，应用于客户端，图1B为本申请实施例提供的一种监测配置文件的方法的流程示意图，如图1B所示，所述方法包括：

步骤S111、启动定时任务；

步骤S112、根据所述定时任务定时从服务端获取应用脚本，其中，所述应用脚本用于使所述客户端获取待监测的应用集合中每一应用的属性信息；

用户提前在服务端配置好需要监测的应用集合中每一应用的属性信息，每一应用的属性信息包括应用的名称和版本等，以脚本或软件的形式存放在服务端。客户端根据定时任务定时从服务端接口获取配置好的脚本或软件。

步骤S113、执行所述应用脚本，得到所述待监测的应用集合中每一应用的属性信息；

在客户端运行从服务端获取的脚本或软件，获得客户端当前的应用属性信息。

步骤S114、将每一所述应用的属性信息与本地存储的配置文件库进行匹配，得到目标应用集合，其中，所述配置文件库用于记录所述客户端侧安装的属性信息；

步骤S115、获取所述目标应用集合中每一应用的配置文件；

步骤S116、将所述目标应用集合中每一应用的配置文件发送给服务端。

本申请实施例，应用于客户端，首先客户端利用定时启动功能，定时从服务器接口获取脚本或软件，运行脚本或软件获取当前客户端的应用属性信息，将每一应用的属性信息与本地存储的配置文件库进行匹配得到需要上报给服务端的配置文件。这样，客户端上报新的配置文件给服务端的过程中，引入定时机制，每经过一个定时周期，客户端无需升级就自动获取需要检测的应用范围和应用配置信息，并根据本地存储的配置文件库判断是否有必要进行比对，有必要时再上报给服务端，减少了人工的控制时间，提高了对于异常参数检测的时效性。服务端以脚本或软件的形式提供给客户端，方便客户端获取待监测的应用集合中每一应用的属性信息。

本申请实施例提供一种监测配置文件的方法，应用于服务端，图2为本申请实施例提供的再一种监测配置文件的方法的流程示意图，如图2所示，所述方法包括：

步骤S201、响应客户端发送的应用脚本请求，将所述应用脚本发送给所述客户端；

用户将用于发送给客户端的脚本或软件制作好，放在服务端。服务端响应客户端发送的应用脚本请求，将应用脚本发送给所述客户端。

步骤S202、解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式；

客户端确定好需要上报给服务端的配置文件后，会将配置文件上报给服务端。服务端获取客户端上报的配置文件并解析配置文件，可以得到配置文件的类型、版本号、路径、名称和格式。

步骤S203、根据所述配置文件的类型确定用于校验所述配置文件的校验算法，其中，所述校验算法用于校验所述配置文件的版本号、路径、名称和格式；

根据解析得到的配置文件的类型，可以确定校验配置文件的校验算法。

步骤S204、使用所述校验算法校验所述配置文件的版本号、路径、名称和格式；

步骤S205、当校验不一致时，在展示界面标识出校验结果。

在服务端制作展示界面，展示界面用于展示客户端IP、应用名称、校验时间和校验结果，其中客户端IP可以区分出每个应用来自哪个客户端，校验结果显示正常或异常。例如：服务端将新的配置记录和已有的原始记录进行校验比对，校验比对不一致时，在校验结果列标识未异常，点击异常可以显示校验不通过的具体配置项。还可以通过发邮件或者短信的方式提醒管理人员，做后续处理，同时可以提供对检测报告的下载。

本申请实施例，应用于服务端，服务端解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式，根据所述配置文件的类型确定用于校验所述配置文件的校验算法，使用所述校验算法校验所述配置文件的版本号、路径、名称和格式，当校验不一致时，在展示界面标识出校验结果。这样实现了在服务端进行比对以及比对文件的多样性。基于服务端的文件比对，可以实现一个服务端服务于成百上千个客户端，从而通过服务端去控制客户端，检测效率有了很大的提升。同时在比对过程中，对于不同的文件格式，采取不同的文件解析方法，提高了文件解析比对的效率。对检测不一致的结果在界面上标识，增强了检测结果展示界面的友好性。

本申请实施例提供一种监测配置文件的方法，应用于服务端，图3为本申请实施例提供的又一种监测配置文件的方法的流程示意图，如图3所示，所述方法包括：

步骤S301、添加待管理的客户端所有应用的属性信息和配置文件的路径信息，其中所述应用的属性信息包括应用的名称和版本号；

用户需要在服务端添加待管理的客户端所有应用的名称和版本号等属性信息和配置文件的路径信息。

步骤S302、根据所述所有应用的属性信息和所述配置文件的路径信息，生成应用脚本；

用户确定每个客户端对应需要监测的应用配置后，根据所有应用的属性信息和所述配置文件的路径信息，生成待发送给客户端的应用脚本或软件。

步骤S303、响应客户端发送的应用脚本请求，将所述应用脚本发送给所述客户端；

步骤S304、当确定所述应用使用直接解压方式部署时，解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式；

直接解压方式部署应用，可以直接解析客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式。

步骤S305、当确定所述应用使用Docker镜像包部署时，将所述应用的配置文件复制得到所述配置文件的类型、版本号、路径、名称和格式；

使用Docker镜像包部署的应用，需要先将应用的配置文件复制，才能得到配置文件的类型、版本号、路径、名称和格式。

步骤S306、当所述配置文件是Property类型时，确定使用键值对存储形式对应的校验算法；

键值对存储是数据库最简单的组织形式。基本上全部的编程语言都带有应用在内存中的键值对存储。不像关系型数据库，键值对存储不须要了解值中的数据，也没有像MySQL或者PostgreSQL中那样的关系型存储结构。当所述配置文件是Property类型时，需要确定使用键值对存储形式对应的校验算法。

步骤S307、当所述配置文件是XML类型时，确定使用Scheme解析技术校验算法；

XML是可扩展标记语言，标准通用标记语言的子集，是一种用于标记电子文件使其具有结构性的标记语言。在电子计算机中，标记指计算机所能理解的信息符号，通过此种标记，计算机之间可以处理包含各种的信息比如文章等。它可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。当所述配置文件是XML类型时，确定使用Scheme解析技术校验算法。

步骤S308、使用所述校验算法校验所述配置文件的版本号、路径、名称和格式；

步骤S309、当校验不一致时，在展示界面标识出校验结果。

本申请实施例，应用于服务端，服务端先要将添加待管理的客户端所有应用的属性信息和配置文件的路径信息，根据所述所有应用的属性信息和所述配置文件的路径信息，生成应用脚本。当客户端应用使用Docker镜像包部署时，需要复制得到所述配置文件的类型、版本号、路径、名称和格式；当应用的配置文件从镜像中复制出来后，可以直接解析。解析客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式，根据所述配置文件的类型确定用于校验所述配置文件的校验算法。当所述配置文件是Property类型时，确定使用键值对存储形式对应的校验算法；所述配置文件是XML类型时，确定使用Scheme解析技术校验算法。当校验不一致时，在展示界面标识出校验结果。这样具体描述了本申请支持Docker镜像包中应用配置文件读取和文件比对，针对不同类型的文件采用不用的校验方法，实现了在服务端进行比对以及比对文件的多样性。基于服务端的文件比对，可以实现一个服务端服务于成百上千个客户端，从而通过服务端去控制客户端，检测效率有了很大的提升。同时在比对过程中，对于不同的文件格式，采取不同的文件解析方法，提高了文件解析比对的效率。对检测不一致的结果在界面上标识，增强了检测结果展示界面的友好性。

本申请实施例提出了一种配置参数自动检测的技术，应用于应用软件的配置检测，通过比对客户端上传的配置记录和原始记录实现配置参数的检测。基于服务端配置文件比对的技术包括三个模块：客户端模块、服务端模块和告警模块。

客户端模块无需升级就能自动更新需要检测的应用范围及配置信息，其原理是所有应用信息和文件路径配置都在服务端动态添加完成，客户端调用服务端接口获取需要检查的应用软件及相关配置脚本路径信息，比如首次部署客户端时，服务端只配置了5款应用需要检测，那么客户端只会检测并上报这5款软件，而过了一段时间因为生产环境配置检测需要，通过在服务端又增加了10款应用，那么客户端会自动获取增加的10款应用信息并去检测和上报，这样可以实现客户端后续无需升级就可以实现动态更新。

本申请实施例提供一种监测配置文件的方法，图4A为本申请实施例提供的又一种监测配置文件的方法的流程示意图，应用于客户端，如图4A所示，所述方法包括：

步骤S401、客户端定时任务启动；

为了实现配置检测的自动化和时效性，在客户端模块装有定时功能，监测配置文件需要先启动客户端定时任务。

步骤S402、客户端根据定时任务执行服务端提供的应用脚本；

定时任务启动后通过，客户端根据定时任务执行服务端提供的应用脚本。

步骤S403、根据执行应用脚本获取应用软件名称、版本号和配置文件；

客户端根据执行应用脚本获取应用软件名称、版本号和配置文件。

步骤S404、根据获取应用软件名称、版本号和配置文件，使用配置文件库记录判断是否有必要进行比对；

配置文件库保存应用名称、版本号、使用节点IP、端口信息，客户端根据获取的应用软件名称、版本号和配置文件，使用应用使用情况知识库记录判断是否有必要进行比对，即，判断是否在应用使用情况知识库存在这个应用，如果知识库中不存在这个应用或对应版本就不需要比对，只有知识库中存在这个应用并匹配到对应的应用版本才会进行比对。

步骤S405、判断有必要的话，客户端向服务端上报发现的配置文件及应用版本号。

本申请实施例在客户端模块，在客户端上报新的配置记录给服务端的过程中，引入定时机制，每经过一个定时周期，客户端无需升级就自动获取需要检测的应用范围和应用配置信息，并根据使用情况知识库记录判断是否有必要进行比对，有必要时再上报给服务端，减少了人工的控制时间，提高了对于异常参数检测的时效性。通过引入定时机制，解决了人工上报配置文件的低效率问题；同时，通过获取配置管理信息，客户端无需升级，可对需要检测的应用配置进行扩展并自动获取，从而减少了不必要的配置文件的上报。

服务端模块分为两部分，分别是校验比对和结果处理。对于校验比对模块，在收取到客户端的上报信息后，进行文件校验比对，对于tomcat、redis、mysql等多种应用，从配置文件的版本号、路径、名称、格式进行校验比对，例如，对于一个端口字段范围是(0至65535)，如果超出了这个范围，校验失败，做出告警提示。

本申请实施例提供一种监测配置文件的方法，图4B为本申请实施例提供的又一种监测配置文件的方法流程示意图，应用于服务端的，如图4B所示，所述方法包括：

步骤S410、服务端获取客户端上的配置文件及应用版本号；

步骤S411、根据所述配置文件的版本号、路径、名称、格式进行校验比对，获取文件类型；

服务端根据客户端上的配置文件得到配置文件的版本号、路径、名称、格式，通过校验比对得到文件类型。

步骤S412、根据所述文件类型采用不同的比对机制进行校验；

服务端根据得到的不同文件类型采用向匹配的比对机制进行校验，这里，机制指的是算法。面对不同的配置文件格式，采用不同的比对算法，例如，对于Property类型文件，将其内容分为键值对存储，用于下一步的比对；对于XML类型文件，使用Scheme解析技术进行比对，并将比对结果保持数据库，然后进行下一步的比对，另外，还支持Docker镜像包中应用配置文件读取和文件比对。

步骤S413、校验失败，做出告警提示；

服务端进行文件校验比对，对于tomcat、redis、mysql等多种应用，从配置文件的版本号、路径、名称、格式进行校验比对，例如，对于一个端口字段范围是(0至65535)，如果超出了这个范围，校验失败，做出告警提示。

步骤S415、根据告警提示，对检测不一致的结果标识；

在结果处理告警模块中，增加了检测结果展示界面的友好性。在根据客户端使用情况知识库的记录对于有变化的配置参数进行标记之后，对于检测的结果，在服务端对每个客户端按照每个应用的节点IP、应用名称、安装应用软件名称、版本号、检测时间做出界面展示，其中展示界面包括节点IP、应用名称、安装应用软件名称、版本号、检测时间、检测结果(正常、异常)。最后对检测不一致的结果标红，做异常告警提示。

步骤S416、根据告警提示，异常告警短信和邮件的方式通知管理人员，同时提供对检测报告的下载。

本申请实施例，实现了在服务端进行比对以及比对文件的多样性。基于服务端的文件比对，可以实现一个服务端服务于成百上千个客户端，从而通过服务端去控制客户端，降低了检测的复杂性，检测效率有了很大的提升。同时在比对过程中，对于不同的文件格式，采取不同的文件解析方法，提高了文件解析比对的效率。在结果处理模块中，对检测不一致的结果标红，做异常提示，并以短信和邮件的方式告知管理人员，同时提供对检测报告的下载，增强了检测结果展示界面的友好性，以短信和邮件的方式通知管理人员，同时提供对检测报告的下载。极大地方便了管理人员对于检测结果的全面的把握，从而快速做出应对策略。以短信和邮件的方式通知管理人员，同时提供对检测报告的下载，极大地方便了管理人员对于检测结果的全面的把握，从而快速做出应对策略。

基于前述的实施例，本申请实施例提供一种监测配置文件的装置，该装置包括所包括的各模块、以及各模块所包括的各单元，可以通过设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。

图5A为本申请实施例提供的一种监测配置文件的装置的组成结构示意图，应用于客户端，如图5A所示，所述监测配置文件的装置500包括：启动模块501、第一获取模块502、匹配模块503、第三获取模块504和发送模块505，其中：

所述启动模块501，用于启动定时任务；

所述第一获取模块502，用于根据所述定时任务定时从服务端获取待监测的应用集合中每一应用的属性信息；

所述匹配模块503，用于将每一所述应用的属性信息与本地存储的配置文件库进行匹配，得到目标应用集合，其中，所述配置文件库用于记录所述客户端侧安装的属性信息；

所述第二获取模块504，用于获取所述目标应用集合中每一应用的配置文件；

所述发送模块505，用于将所述目标应用集合中每一应用的配置文件发送给服务端。

在一些实施例中，所述第一获取模块还包括获取单元和执行单元，其中所述获取单元，用于根据所述定时任务定时从服务端获取应用脚本，其中，所述应用脚本用于使所述客户端获取待监测的应用集合中每一应用的属性信息；所述执行单元，用于执行所述应用脚本，得到所述待监测的应用集合中每一应用的属性信息。

图5B为本申请实施例提供的另一种监测配置文件的装置的组成结构示意图，应用于服务端，如图5B所示，所述监测配置文件的装置510包括：响应模块511、解析模块512、确定模块513、校验模块514和标识模块515，其中：

所述响应模块511，用于响应客户端发送的应用脚本请求，将所述应用脚本发送给所述客户端；

所述解析模块512，用于解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式；

所述确定模块513，用于根据所述配置文件的类型确定用于校验所述配置文件的校验算法，其中，所述校验算法用于校验所述配置文件的版本号、路径、名称和格式；

所述校验模块514，用于使用所述校验算法校验所述配置文件的版本号、路径、名称和格式；

所述标识模块515，用于当校验不一致时，在展示界面标识出校验结果。

在一些实施例中，所述监测配置文件的装置还包括添加模块和生成模块，其中所述添加模块，用于添加待管理的客户端所有应用的属性信息和配置文件的路径信息，其中所述应用的属性信息包括应用的名称和版本号；所述生成模块，用于根据所述所有应用的属性信息和所述配置文件的路径信息，生成应用脚本。

在一些实施例中，所述确定模块还包括第一确定单元和第二确定单元，其中所述第一确定单元，用于当所述配置文件是Property类型时，确定使用键值对存储形式对应的校验算法；所述第二确定单元，用于当所述配置文件是XML类型时，确定使用Scheme解析技术校验算法。

在一些实施例中，所述解析模块还包括第一解析单元和第二解析单元，其中所述第一解析单元，用于当确定所述应用使用直接解压方式部署时，解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式；第二解析单元，用于当确定所述应用使用Docker镜像包部署时，将所述应用的配置文件复制得到所述配置文件的类型、版本号、路径、名称和格式。

这里需要指出的是：以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的监测配置文件的方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得包含该存储介质的设备自动测试线执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

对应地，本申请实施例提供一种监测配置文件的设备，例如，客户端或服务端，图6为本申请实施例提供的一种监测配置文件的设备的硬件实体示意图，如图6所示，该设备600的硬件实体包括：处理器601、通信接口602和存储器603，其中

处理器601通常控制设备600的总体操作。

通信接口602可以使设备600通过网络与其他终端或服务端通信。

存储器603配置为存储由处理器601可执行的指令和应用，还可以缓存待处理器601以及设备600中各模块待处理或已经处理的数据，可以通过闪存(FLASH)或随机访问存储器(Random Access Memory，RAM)实现。

对应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的监测配置文件的方法中的步骤。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本申请实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得设备自动测试线执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种监测配置文件的方法，应用于客户端，所述方法包括：

启动定时任务；

根据所述定时任务定时从服务端获取待监测的应用集合中每一应用的属性信息；

将每一所述应用的属性信息与本地存储的配置文件库进行匹配，得到目标应用集合，其中，所述配置文件库用于记录所述客户端侧安装的属性信息；

获取所述目标应用集合中每一应用的配置文件；

将所述目标应用集合中每一应用的配置文件发送给服务端。

2.如权利要求1所述的方法，其特征在于，所述根据所述定时任务定时从服务端，获取待监测的应用集合中每一应用的属性信息，包括：

根据所述定时任务定时从服务端获取应用脚本，其中，所述应用脚本用于使所述客户端获取待监测的应用集合中每一应用的属性信息；

执行所述应用脚本，得到所述待监测的应用集合中每一应用的属性信息。

3.一种监测配置文件的方法，应用于服务端，所述方法包括：

响应客户端发送的应用脚本请求，将所述应用脚本发送给所述客户端；

解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式；

根据所述配置文件的类型确定用于校验所述配置文件的校验算法，其中，所述校验算法用于校验所述配置文件的版本号、路径、名称和格式；

使用所述校验算法校验所述配置文件的版本号、路径、名称和格式；

当校验不一致时，在展示界面标识出校验结果。

4.如权利要求3所述的方法，其特征在于，所述方法还包括：

添加待管理的客户端所有应用的属性信息和配置文件的路径信息，其中所述应用的属性信息包括应用的名称和版本号；

根据所述所有应用的属性信息和所述配置文件的路径信息，生成应用脚本。

5.如权利要求3所述的方法，其特征在于，所述根据所述配置文件的类型确定用于校验所述配置文件的校验算法，包括：

当所述配置文件是Property类型时，确定使用键值对存储形式对应的校验算法；

当所述配置文件是XML类型时，确定使用Scheme解析技术校验算法。

6.如权利要求3所述的方法，其特征在于，所述解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式，包括：

当确定所述应用使用直接解压方式部署时，解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式；

当确定所述应用使用Docker镜像包部署时，将所述应用的配置文件复制得到所述配置文件的类型、版本号、路径、名称和格式。

7.一种监测配置文件的装置，应用于客户端，所述装置包括启动模块、第一获取模块、匹配模块、第二获取模块和发送模块，其中：

所述启动模块，用于启动定时任务；

所述第一获取模块，用于根据所述定时任务定时从服务端获取待监测的应用集合中每一应用的属性信息；

所述匹配模块，用于将每一所述应用的属性信息与本地存储的配置文件库进行匹配，得到目标应用集合，其中，所述配置文件库用于记录所述客户端侧安装的属性信息；

所述第二获取模块，用于获取所述目标应用集合中每一应用的配置文件；

所述发送模块，用于将所述目标应用集合中每一应用的配置文件发送给服务端。

8.一种监测配置文件的装置，应用于服务端，所述装置包括响应模块、解析模块、确定模块、校验模块和标识模块，其中：

所述响应模块，用于响应客户端发送的应用脚本请求，将所述应用脚本发送给所述客户端；

所述解析模块，用于解析所述客户端上报的配置文件，得到所述配置文件的类型、版本号、路径、名称和格式；

所述确定模块，用于根据所述配置文件的类型确定用于校验所述配置文件的校验算法，其中，所述校验算法用于校验所述配置文件的版本号、路径、名称和格式；

所述校验模块，用于使用所述校验算法校验所述配置文件的版本号、路径、名称和格式；

所述标识模块，用于当校验不一致时，在展示界面标识出校验结果。

9.一种监测配置文件的设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至6任一项所述方法中的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至6中任一项所述方法中的步骤。

Images