本发明涉及计算机技术领域，尤其涉及一种集群管理方法、装置、终端设备及存储介质。
背景技术：
随着互联网技术的高速发展以及同类型服务的产品层出不穷，用户对服务质量的要求更严格。面对来自用户的压力，互联网公司通常采取了分布式集群部署服务，利用其高性能性、高可靠性、高扩展性来解决这巨大的挑战。伴随分布式集群规模扩大，分布式集群内部关联复杂，集群管理越来越成为提供稳健服务关键核心，成为学术界跟工程界的研究热点问题之一。
目前通用的集群管理方式主要是管理人员对集群进行定期的人为检查，这不仅需要管理人员具有深厚的技术基础，而且由于集群运行过程中产生的大量数据使得维护过程较为复杂，需要耗费大量时间，在集群某些节点服务器发生故障时候，由于无法及时发现和处理而导致整个集群的稳定性受到影响。
技术实现要素：
本发明实施例提供一种集群管理方法、装置、终端设备及存储介质，以解决当前集群管理对管理人员技术要求高、维护复杂和维护效率低的问题。
第一方面，本发明实施例提供一种集群管理方法，包括集群端执行的如下步骤：
获取基础资源数据，其中，所述基础资源数据用于记录所述集群端的配置信息和执行数据；
通过日志收集分析框架对所述基础资源数据进行处理，得到目标资源数据；
将所述目标资源数据发送给监控端；
若接收到所述监控端发送的集群管理指令，则根据所述集群管理指令进行集群管理。
第二方面，本发明实施例提供一种集群管理方法，包括监控端执行的如下步骤：
接收集群端通过日志收集分析框架发送的目标资源数据；
将所述目标资源数据存储到预设的数据库中；
通过构建可视化界面显示所述数据库中存储的所述目标资源数据；
若检测到用户在所述可视化界面的管理操作，则根据所述管理操作生成相应的集群管理指令；
将所述集群管理指令发送到所述集群端。
第三方面，本发明实施例提供一种集群管理装置，包括集群端，所述集群端包括：
基础资源数据获取模块，用于获取基础资源数据，其中，所述基础资源数据用于记录所述集群端的配置信息和执行数据；
目标资源数据获取模块，用于通过日志收集分析框架对所述基础资源数据进行处理，得到目标资源数据；
目标资源数据发送模块，用于将所述目标资源数据发送给监控端；
集群管理指令处理模块，用于若接收到所述监控端发送的集群管理指令，则根据所述集群管理指令进行集群管理。
第四方面，本发明实施例提供一种集群管理装置，包括监控端，所述监控端包括：
目标资源数据接收模块，用于接收集群端通过日志收集分析框架发送的目标资源数据；目标资源数据存储模块，用于将所述目标资源数据存储到预设的数据库中；
可视化显示和管理模块，用于通过构建可视化界面显示所述数据库中存储的所述目标资源数据；
集群管理指令生成模块，若检测到用户在所述可视化界面的管理操作，则根据所述管理操作生成相应的集群管理指令；
集群管理指令发送模块，用于将所述集群管理指令发送到所述集群端。
第五方面，本发明实施例提供一种终端设备，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现集群管理方法的步骤。
第六方面，本发明实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现集群管理方法的步骤。
本发明实施例与现有技术相比具有如下优点：本发明实施例提供的集群管理方法、装置、终端设备及存储介质中，集群端获取基础资源数据，通过日志收集分析框架对基础资源数据进行处理，得到目标资源数据，并将目标资源数据发送到监控端，监控端接收该目标资源数据并存储到数据库，通过构建可视化界面显示该数据库中存储的目标资源数据，当监控端的管理人员在可视化界面进行管理操作时，监控端生成相应的集群管理指令，并发送到集群端，集群端接收到该集群管理指令后进行相应的集群管理，从而实现了通过日志收集分析框架收集集群端的关键资源数据，并及时发送到监控端，在监控端进行可视化显示，在需要对集群进行管理时，通过可视化界面直观快捷地完成对集群的相应管理，从而降低了对管理人员的技术要求，同时也使集群维护变得简便，节省时间，提高了维护效率和集群管理的效率。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例1中提供的集群管理方法的实现流程图；
图2是本发明实施例1中提供的集群管理方法中步骤S101的实现流程图；
图3是本发明实施例1中提供的集群管理方法中步骤S102的实现流程图；
图4是本发明实施例1中提供的集群管理方法中步骤S106的实现流程图；
图5是本发明实施例1中提供的集群管理方法中监控端对异常信息的预警的实现流程图；
图6是本发明实施例2提供的集群管理装置的示意图；
图7是本发明实施例4中提供的终端设备的示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
实施例1
本发明实施例中的集群管理方法具体包括集群端执行的如下步骤：
获取基础资源数据，其中，所述基础资源数据用于记录所述集群端的配置信息和执行数据；
通过日志收集分析框架对所述基础资源数据进行处理，得到目标资源数据；
将所述目标资源数据发送给监控端；
若接收到所述监控端发送的集群管理指令，则根据所述集群管理指令进行集群管理。
本发明实施例中的集群管理方法具体还包括监控端执行的如下步骤：
接收集群端通过日志收集分析框架发送的目标资源数据；
将所述目标资源数据存储到预设的数据库中；
通过构建可视化界面显示所述数据库中存储的所述目标资源数据；
若检测到用户在所述可视化界面的管理操作，则根据所述管理操作生成相应的集群管理指令；
将所述集群管理指令发送到所述集群端。
请参阅图1，图1示出了本实施例提供的集群管理方法的实现流程。该集群管理方法应用于集群管理装置中，集群管理装置包括集群端和监控端，其中，集群端具体可以是集群服务器，监控端具体可以是监控服务器，一个监控端可同时管理多个集群端，每个集群端可以包含一台或多台集群服务器。详述如下：
S101：集群端获取基础资源数据，其中，该基础资源数据是用于记录集群端的配置信息和执行数据。
在本发明实施例中，集群端的配置信息包括但不限于：服务器IP地址、服务器内存、服务器CPU型号、服务器SWAP分区、服务器内存使用率及服务器CPU使用率等。集群端的执行数据是指集群端在执行任务时该任务的参数信息。
例如，一集群端执行的任务为铁路交通部门的智能交通任务，包括50台服务器执行的订票处理任务和3台服务器的站次查询任务，则该集群端的执行数据包括订票处理任务的参数信息和站次查询任务的参数信息，其中，订票处理任务的参数信息具体为：接收订票请求25600次，处理订票请求25570次，订票成功22570次，订票失败3000次，站次查询任务的参数信息具体为：接收查询请求21500次，处理查询请求21488次，查询成功21400次，查询失败88次。
优选地，在集群端部署脚本，通过执行该脚本获取集群端的基础资源数据。
S102：集群端通过日志收集分析框架对基础资源数据进行处理，得到目标资源数据。
在本发明实施例中，目标资源数据为根据实际需求对基础资源数据进行分析和筛选后得到的资源数据。
具体地，在日志收集分析框架中包含预设的过滤条件，日志收集分析框架基于该过滤条件对获取到的基础资源数据进行分析过滤，得到目标资源数据。
优选地，日志收集分析框架为分布式发布订阅消息系统Kafka和日志分析工具Logstash组合而成的框架。集群端通过Kafka实时获取基础资源数据，使用Logstash对基础资源数据进行分类过滤，得到目标资源数据。
S103：集群端将目标资源数据发送给监控端。
具体地，集群端通过日志收集分析框架将得到的目标资源数据发送给监控端。优选地，集群端与监控端之间通过进程通信协议进行通信，该进程通信协议具体可以为远程过程调用协议(Remote Procedure Call，RPC)。
S104：监控端接收集群端通过日志收集分析框架发送的目标资源数据。
在本发明实施例中，监控端包括若干数据接收接口，不同数据接收接口用于接收相应的预设类型的数据，当监控端接收到集群端通过日志收集分析框架发送的目标资源数据时，数据接收接口对目标资源数据进行正则匹配，接收符合预设类型的数据。
例如，若监控端的数据接收接口A的预设类型的数据为服务器IP地址和服务器内存容量，数据接收接口B的预设类型的数据为服务器IP地址和服务器内存使用率，当监控端接收到集群端的目标资源数据时，该目标资源数据包括：服务器IP地址、服务器内存容量、服务器CPU型号、服务器内存使用率，和服务器CPU使用率，数据接收接口A对该目标资源数据按照预设的匹配条件进行正则匹配，将不符合该匹配条件的目标资源数据过滤后，接收到的符合预设类型的数据为：“192.168.23.178，32G”，数据接收接口B接收到的数据为：“192.168.23.178，57％”。
需要说明的是，数据接收接口的预设类型可以根据实际应用的需要进行设置，此处不做限制。
S105：监控端将目标资源数据存储到预设的数据库中。
在本发明实施例中，在预设的数据库中使用数据记录表保存目标源数据，其中，数据记录表包含服务器IP地址、服务器内存容量、服务器CPU型号、服务器内存使用率、服务器CPU使用率，以及服务器执行任务各等字段中的至少一个，但并不限于此，数据记录表还可以包含其他需要保存的目标源数据的类型，其具体可以根据实际应用的需要进行设置，此处不做限制。
进一步地，在数据库中以服务器IP地址创建索引。
具体地，监控端获取到目标资源数据后，将数据接收接口获取到的数据按照相同服务器IP地址进行归类，并将归类后的每个服务器IP地址对应的数据保存在数据库中该服务器IP地址所在的记录中。
以步骤S104中的数据接收接口A和数据接收接口B为例，根据数据接收接口A接收到的数据“192.168.23.178，32G”，以及数据接收接口B接收到的数据“192.168.23.178，57％”可知，这两条数据对应同一个服务器IP地址，即内存容量和内存使用率为同一个服务器的内存属性，因此监控端将服务器内存容量和服务器内存使用率存储到数据记录表中该服务器IP地址所在的记录中，使得通过服务器IP地址“192.168.23.199”能够在数据库中直接查询到该服务器IP地址对应的服务器内存容量和服务器内存使用率。
S106：监控端通过构建可视化界面显示数据库中存储的目标资源数据。
具体地，监控端根据数据库中存储的目标资源数据，构建可视化界面对该目标资源数据进行显示和管理。
进一步地，可视化界面包括可视化图表显示界面和可视化管理操作界面。在可视化图表显示界面显示目标资源数据，在可视化管理操作界面实现对集群管理的人机交互操作。
可视化管理操作界面具体可以包括集群配置管理、集群节点管理、服务器运行模式管理、任务管理及主备服务器内核调整等。其中，集群配置管理包括但不限于对集群配置文件的备份、删除或更新等处理过程，集群配置文件包括集群参数配置文件、日志收集框架配置文件等。集群节点管理包括但不限于：增加节点、删除节点、更新节点等。服务器运行模式管理包括但不限于对服务器发送重启、关机或进入维护模式等指令。
需要说明的是，集群配置管理是通过监控端一键执行的，避免了在任务发生改变的时候，需要对每台服务器进行集群配置单独修改的问题，提高了集群管理的效率。
S107：监控端若检测到用户在可视化界面的管理操作，则根据该管理操作生成相应的集群管理指令。
在本发明实施例中，监控端的管理人员实时查看可视化图表显示界面显示的目标资源数据，当需要对集群端进行管理时，通过可视化管理操作界面执行管理操作。监控端检测到该管理操作时，根据该管理操作生成对应的集群管理指令。
具体地，集群管理指令包括待管理的集群端的标识信息和具体的操作指令，集群端的标识信息具体可以为集群端服务器IP地址。
例如，在集群运行过程中，若监控端的管理人员发现集群端的某台服务器的某个类型的数据波动较大，需要在集群节点中删除该服务器节点，待对该服务器进行检查后再重新添加到集群节点中，则管理人员可以在监控端的可视化管理操作界面中执行“删除节点”的管理操作，并填写要删除的服务器节点的IP地址“192.168.23.111”。监控端根据该管理操作和该IP地址，自动生成对应的管理指令“Remove Node 192.168.23.111”。
S108：监控端将集群管理指令发送到集群端。
具体地，监控端将根据管理操作生成的集群管理指令通过进程通信协议发送给集群端。
S109：集群端若接收到监控端发送的集群管理指令，则根据该集群管理指令进行集群管理。
具体地，当集群端接收到监控端发送的集群管理指令，集群端解析该集群管理指令，并根据解析结果进行相应的集群管理。
例如，集群端在接收到监控端发送的对服务器IP地址为“192.168.23.65”的服务器执行关机指令的集群管理指令时，解析该集群管理指令，获取待管理的服务器IP地址为“192.168.23.65”，具体的操作指令为“关机”，则对服务器IP地址为“192.168.23.65”的服务器执行“Shutdown.exe”进行关机操作。
在图1对应的实施例中，集群端获取基础资源数据，通过日志收集分析框架对基础资源数据进行处理，得到目标资源数据，并将目标资源数据发送到监控端，监控端接收该目标资源数据并存储到数据库，通过构建可视化界面显示该数据库中存储的目标资源数据，当监控端的管理人员在可视化界面进行管理操作时，监控端生成相应的集群管理指令，并发送到集群端，集群端接收到该集群管理指令后进行相应的集群管理，从而实现了通过日志收集分析框架收集集群端的关键资源数据，并及时发送到监控端，在监控端进行可视化显示，在需要对集群进行管理时，通过可视化界面直观快捷地完成对集群的相应管理，从而降低了对管理人员的技术要求，同时也使集群维护变得简便，节省时间，提高了维护效率和集群管理的效率。
接下来，在图1对应的实施例的基础之上，下面通过一个具体的实施例对步骤S101中所提及的集群端获取基础资源数据的具体实现方法进行详细说明。
请参阅图2，图2示出了集群端获取基础资源数据的具体实现流程，详述如下：
S201：集群端部署监控脚本。
具体地，在集群端需要进行基础资源数据收集的服务器上部署监控脚本。
优选地，监控脚本为shell脚本文件，利用shell的功能将监控命令预先写入到shell脚本文件中。
通过部署监控脚本，对集群端进行监控管理，包括但不限于：收集集群端的基础资源数据、接收监控端的管理指令、向集群端的服务器发送管理指令等。
S202：集群端基于监控脚本收集基础资源数据。
具体地，集群端通过部署好的监控脚本，对基础资源数据进行收集。
需要说明的是，用户可以根据实际应用的需要对监控脚本的内容进行调整。例如，预先部署的监控脚本收集的基础资源数据的数据类型包括：服务器IP地址、服务器内存容量、服务器SWAP分区，以及服务器内存使用率等，但在集群执行任务的过程中，对内存容量的监控需求降低，而对服务器CPU使用率的监控更加重要，则用户可随时调整监控脚本，将基础资源数据的数据类型修改为：服务器IP地址、服务器CPU型号、服务器SWAP分区和服务器CPU使用率等。
进一步地，在监控脚本中可以设置将收集到的基础资源数据通过超文本传输协议(HyperText Transfer Protocol，HTTP)或者安全外壳协议(Secure Shell，SSH)传输给日志收集分析框架。
其中，HTTP是互联网上应用最为广泛的一种网络协议，基于HTTP协议的客户/服务器模式的信息交换过程包括四个过程：建立连接、发送请求信息、发送响应信息和关闭连接。
其中，SSH为建立在应用层基础上的安全协议。SSH是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议，利用SSH协议可以有效防止远程管理过程中的信息泄露问题。
在图2对应的实施例中，集群端在运行的过程中，每天都会产生太字节(Terabyte，TB)级别的日志数据，通过部署监控脚本对实际需要的基础资源数据进行收集，并能够根据实际应用的需求灵活的对待收集的基础资源数据的数据类型进行调整，将收集到的基础资源数据发送给日志收集分析框架，从而避免了大量冗余数据的收集，提高了集群数据收集的效率，同时也方便管理人员的维护和管理。
在图1对应的实施例的基础之上，下面通过一个具体的实施例对步骤S102中所提及的集群端通过日志收集分析框架对基础资源数据进行处理，得到目标资源数据的具体实现方法进行详细说明。
请参阅图3，图3示出了集群端通过日志收集分析框架对基础资源数据进行处理，得到目标资源数据的具体实现流程，详述如下：
S301：集群端部署分布式发布订阅消息系统Kafka和日志分析工具Logstash。
具体地，在集群端的每个集群服务器上分别部署分布式发布订阅消息系统Kafka和日志分析工具Logstash。
其中，Kafka是一种高吞吐量的分布式发布订阅消息系统。Kafka通过磁盘数据结构提供消息的持久化，这种结构对于TB数量级的消息存储也能够保持长时间的稳定性能，能够处理消费者规模的站点中的所有动作流数据。
具体来说，动作流数据中的动作包括但不限于：网页浏览，搜索和其他用户的行动，这些动作是在现代网络上的许多社会功能的一个关键因素。动作流数据通常是根据吞吐量的要求，通过处理日志和日志聚合来解决。
例如，在一具体实施方式中，Kafka收集的动作流可以包括：服务器上各个进程运行产生的日志，管理人员对服务器的操作产生的日志，服务器运行时自身的处理日志等。
目前常见的用于集群管理的开源日志分析工具包括：Spark、Hadoop、Logstash等，其中Spark和Hadoop相对成本较高，因此本发明实施例中使用的日志分析工具为Logstash。
Logstash是一款轻量级的日志搜集处理框架，可以方便的把分散的、多样化的日志搜集起来，并进行自定义的处理，然后传输到指定的位置，例如某个服务器上或者某个文件里。
进一步地，Logstash可以通过配置匹配符来进行日志筛选过滤操作。
S302：集群端通过分布式发布订阅消息系统Kafka实时获取基础资源数据。
具体地，Kafka集群获取到的每条消息都有一个类别，这个类别被称为Topic。不同Topic的消息分开存储，存储位置可以根据需求进行自定义并记录在Offset中，消费者只需指定消息的Topic即可获取数据而不必关心数据具体存储在哪个地方。
其中，Offset为存储位置的索引序列，Offset包括但不限于：Offset编号、消息类别、服务器IP地址、存储位置和消息时间。
例如，在一个由服务器A、服务器B和服务器C组成的Kafka集群中，在一具体时间段接收到的消息类别中包含两类：故障记录消息和调试记录消息，其中，故障记录消息23条，调试记录消息160条，Kafka自动根据服务器A、服务器B和服务器C当前的状态，选择存储故障记录消息和调试记录消息的服务器。比如，将故障记录消息和调试记录消息分别存储在服务器A和服务器B上，其中，服务器A上存储了6条故障记录消息，其存储位置为：“C:\temp\server_fault_2952.log”，同时服务器A上还存储了100条调试记录消息，其存储位置为：“C:\temp\server_debug_3623.log”，服务器B上存储了17条故障记录消息，其存储位置为：“E:\min\server_fault_95.log”，同时服务器B上还存储了60条调试记录消息，其存储位置为：“C:\ser\server_debug_532.log”，服务器A的IP地址为：192.168.23.2，其存储的故障记录消息的Offset为“编号：9562，日志类别：故障记录消息，服务器IP地址：192.168.23.2，存储位置：C:\temp\server_fault_2952.log，消息时间：2018-01-19 11:49:20”。
需要说明的是，由于Kafka采用解耦的设计思想，并非原始的发布订阅，生产者把数据推送给每个Topic，消费者从Topic中获取数据，这种方式具有如下优势：
a)生产者的负载与消费者的负载解耦。
b)消费者按照自己的需要获取数据，避免了消费者集群中产生大量没必要的垃圾数据。其中，获取数据使用Fetch方法，Fetch方法提供了获取资源数据的API接口和更强大更灵活的功能集，消费者可以根据自己的能力来获取接口，不受生产者的服务器限制。
c)消费者可以自定义消费的数量。
可以理解地，由于这些优势，使得Kafka能够实时获取并存储所有基础资源数据。
S303：集群端使用日志分析工具Logstash对基础资源数据进行分类过滤，得到目标资源数据。
具体地，Logstash是一款轻量级的日志搜集处理框架，具有方便的把分散的、多样化的日志搜集起来的特性。在Kafak将实时获取的集群端基础资源数据分布式存放在预设的自定义存储位置后，Logstash根据应用的需要获取基础资源数据并对基础资源数据进行分类过滤，得到目标资源数据。其具体实现流程如下：
a)Logstash获取预设时间间隔内的Offset。
由于步骤S302中所提到的Kafka所具有的特性，使得Kafka可以实时获取并存储所有基础资源数据，出于性能方面的考虑，Logstash在处理这些基础资源数据的时候，需要预设一个时间间隔，通过获取预设时间间隔内的所有Offset来得到相关消息的记录。
例如，在一具体实施方式中，预设的处理基础资源数据的时间间隔为60秒，则Logstash在开始处理基础资源数据时，先获取距当前时间60内的所有Offset。
b)Logstash根据Offset内记载的存储位置获取相对应的日志文件。
由步骤S302中对Offset的说明可知，每个Offset包含有该Offset记载的消息的对应的存储位置，根据该存储位置，获取相对应的日志文件。
例如，在一具体实施方式中，获取到的某个Offset具体记载内容为：“编号：9562，日志类别：故障记录消息，服务器IP地址：192.168.23.2，存储位置：C:\temp\server_fault_2952.log，消息时间：2018-01-25 11:37:21”，容易理解地，其记载的存储信息为：“C:\temp\server_fault_2952.log”，其对应的日志文件为记载在服务器IP为“192.168.23.2”的服务器上的“C:\temp\”目录下的“server_fault_2952.log”文件。
c)Logstash对日志文件中的记录信息进行分类。
在获取到日志文件后，对日志文件里面的每条记录信息进行分类。
具体地，日志文件包含至少一条记录信息，每条记录信息包含但不限于该记录信息的类别、编号、和具体事件，但这些内容没有被分割开来，通过对记录信息进行分割，获取记录信息的分类。
例如：在一具体实施方式中，在一日志文件里存在这样一条记录信息：“0009[I]C:\Windows\system32\Macromed\Flash\activex.vch”，通过使用Split函数对该记录信息进行分割，得到{“0009”，“[I]”，“C:\Windows\system32\Macromed\Flash\activex.vch”}，其中“0009”为该记录信息的编号，“[I]”为该记录信息的类别，“C:\Windows\system32\Macromed\Flash\activex.vch”为该记录信息的具体事件。
d)Logstash从日志文件的记录信息中，获取与预设匹配符相匹配的类别的记录信息，同时获取该记录信息对应的服务器IP地址和消息时间，并将该记录信息、该服务器IP地址和该消息时间作为目标资源数据。
具体地，Logstash从日志文件的记录信息中，按照预设匹配符查找对应的类别，并获取查询到的与预设匹配符相匹配的类别所在的记录信息，并根据该记录信息所在的日志文件，获取该记录信息对应的服务器IP地址和消息时间。
例如，记录信息的类别可以包括“[D]”、“[I]”、“[W]”、“[E]”、“[F]”中的至少一种，其中，“[D]”、“[I]”、“[W]”、“[E]”、“[F]”分别对应“Debug”、“Info”、“Warn”、“Error”、“Fatal”，当预设匹配符为“Debug”、“Info”、“Warn”、“Error”、“Fatal”中的某一项或者多项组合时，通过获取与该匹配符相匹配的类别，进而获取该类别对应的记录信息。
需要说明的是，预设匹配符和记录信息的类别均可以根据实际应用的需要进行设置，此处不做限制。
在图3对应的实施例中，在集群端部署分布式发布订阅消息系统Kafka和日志分析工具Logstash，集群端通过分布式发布订阅消息系统Kafka实时获取基础资源数据，进一步使用日志分析工具Logstash对基础资源数据进行分类过滤，得到目标资源数据，实现了对基础资源数据的实时收集并按需要进行分析过滤，得到目标资源数据，在有效获取所需要的目标资源数据的同时，也避免了过多的冗余数据对集群管理效率带来的不利影响。
在图1对应的实施例的基础之上，下面通过一个具体的实施例对步骤S106中所提及的监控端通过构建可视化界面显示数据库中存储的目标资源数据的具体实现方法进行详细说明。
请参阅图4，图4示出了监控端通过构建可视化界面显示数据库中存储的目标资源数据的具体实现流程，详述如下：
S401：监控端根据目标资源数据，构建可视化图表，其中，该可视化图表包括趋势图、频数图、比重图或数据表格中的至少一个。
具体地，监控端获取数据库中存储的目标资源数据，基于该目标资源数据，构建可视化图表。
具体地，集群配置信息和任务数据根据预设的显示方式进行显示，预设的显示方式包括但不限于：趋势图、频数图、比重图或数据表格等。
例如，在集群执行铁路交通部门的智能交通任务过程中，监控端可以使用频数图显示在订票业务中各班次列车的需求情况，还可以使用趋势图或者数据表格显示订票请求在每天不同时间段的分布情况。
S402：监控端在可视化界面中显示可视化图表。
具体地，监控端将步骤S401构建的可视化图表在可视化界面的可视化图表显示界面中进行显示，以便管理人员随时查阅。
在图4对应的实施例中，根据目标资源数据，构建可视化图表，将可视化图表根据预设的显示方式在可视化图标显示界面中显示，方便管理人员在集群管理过程中能够直观查看目标资源数据，并根据需要对集群进行实时快捷的管理操作，提高了集群管理的效率。
在图1对应的实施例的基础之上，在步骤S106提及的监控端通过可视化界面显示数据库中存储的目标资源数据之后，监控端还包括对异常信息的预警过程。
请参阅图5，图5示出了监控端对异常信息进行预警的具体实现流程，详述如下：
在本发明实施例中，监控端预先部署预警脚本，该预警脚本中预设有第一预警范围和第二预警范围，并实时读取数据库存储的目标资源数据，并将该目标资源数据与第一预警范围比较和第二预警范围进行对比。
具体地，在预警脚本中分别针对第一预警范围和第二预警范围，具体预设了每种目标资源数据分别对应的预警范围。
例如，假设目标资源数据包括服务器内存使用率和服务器CPU使用率，则在预警脚本中对服务器内存使用率和服务器CPU使用率分别设置两种不同程度的预警范围，服务器内存使用率第一预警范围为(0.7-0.85)，即当服务器内存使用率大于等于0.7且小于0.85时，服务器的内存使用率达到第一预警范围，服务器内存使用率的第二预警范围为(0.86-0.99)，服务器CPU使用率第一预警范围为(0.75-0.8)，服务器CPU使用率第二预警范围为(0.81-0.99)。
S501：若目标资源数据满足预设的第一预警范围，则发送预警信息。
具体地，若监控端通过预警脚本监测到当前获取的目标资源数据处于第一预警范围内，则向可视化界面推送预警信息，以便提醒管理人员作出相应处理。
预警信息具体可以包括处于第一预警范围的目标资源数据的内容，该目标资源数据所在的集群端的详细信息，以及解除该预警的优化方法等。
例如，假设对服务器内存使用率第一预警范围为(0.7-0.85)，服务器CPU使用率的第一预警范围为(0.75-0.8)，当预警脚本监测到当前某一集群端服务器的内存使用率为0.77，服务器CPU使用率为0.6，则监控端确认该服务器的服务器内存使用率处于第一预警范围内，向可视化页面推送该服务器的预警信息，该预警消息具体为“服务器IP地址为192.168.23.119的服务器当前内存使用率为0.77，请开启UseConcMarkSweepGC和UseParNewGC模式(激活多线程CMS收集器，快速回收系统垃圾)，以便降低内存使用率”。
S502：若目标资源数据满足预设的第二预警范围，则执行相应的应急预警措施。
具体地，若监控端通过预警脚本监测到当前获取的目标资源数据处于第二预警范围内，则根据预先设置的目标资源数据与预警措施的对应关系，选取相应的应急预警措施自动执行。
应急预警措施包括但不限于：强制重启、强制关机、进入维护模式、删除该服务器节点等，预先为每种目标资源数据设置对应的预警措施。
例如，服务器内存使用率和服务器CPU使用率的第二预警范围为(0.86-0.99)和(0.81-0.99)，服务器内存使用率和服务器CPU使用率对应的应急预警措施可以设置为“强制重启”，当预警脚本监测到当前某一集群端服务器的内存使用率为0.91，则监控端确认该服务器的服务器内存使用率处于第二预警范围内，向该集群端服务器发送“强制重启”的指令，监控端在检测到该集群端服务器重启完成后，向可视化界面推送该服务器的预警信息，该预警消息具体为“服务器IP地址为192.168.23.156的服务器当前内存使用率为0.91，已自动进行重启操作”。
又例如，当预警脚本监测到当前某一服务器的内存使用率为0.97，CPU使用率为0.99，监控端确认该服务器的服务器内存使用率处于第二预警范围内，向该集群端服务器发送“进入维护模式”的指令后，若在预设时间范围内没有收到该集群端服务器返回的响应，则确认该集群端服务器处于宕机状态，监控端向该集群端服务器发送“删除该服务器节点”的指令，并向可视化界面推送该服务器的预警信息，该预警消息具体为“服务器IP地址为192.168.23.226的服务器当前内存使用率为0.97，当前CPU使用率为0.99，无法响应监控端指令，已自动删除该服务器节点”。
可以理解的是，若预警脚本监控到目标资源数据中的某些数据处于第二预警范围，另一些数据处于第一预警范围，则按照第二预警范围进行预警处理。
在图5对应的实施例中，监控端通过预先部署的预警脚本对数据库存储的目标资源数据进行实时监控，当目标资源数据处于预设的第一预警范围或者第二预警范围时，进行相应的预警处理，实现了分级别的预警以及在集群端服务器发生故障时能够及时采取应急措施，避免未及时发现和处理异常情况而导致整个集群的稳定性受到影响，从而有效提高了集群管理的效率。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
实施例2
对应于实施例1中的集群管理方法，图6示出了与实施例1中集群管理方法一一对应的集群管理装置。该集群管理装置包括集群端和监控端。为了便于说明，仅示出了与本发明实施例相关的部分。
如图6所示，该集群管理装置的集群端包括基础资源数据获取模块611、目标资源数据获取模块612、目标资源数据发送模块613和集群管理指令处理模块614。各功能模块详细说明如下：
基础资源数据获取模块611，用于获取基础资源数据，其中，基础资源数据用于记录集群端的配置信息和执行数据；
目标资源数据获取模块612，用于通过日志收集分析框架对基础资源数据进行处理，得到目标资源数据；
目标资源数据发送模块613，用于将目标资源数据发送给监控端；
集群管理指令处理模块614，用于若接收到监控端发送的集群管理指令，则根据集群管理指令进行集群管理。
进一步地，基础资源数据获取模块611包括：
监控脚本部署单元6111，用于部署监控脚本；
基础资源数据收集单元6112，用于基于监控脚本收集基础资源数据。
进一步地，目标资源数据获取模块612包括：
日志收集分析框架部署单元6121，用于部署分布式发布订阅消息系统Kafka和日志分析工具Logstash；
基础资源数据获取单元6122，用于通过Kafka实时获取基础资源数据；
目标资源数据获取单元6123，用于使用Logstash对基础资源数据进行分类过滤，得到目标资源数据。
请继续参阅图6，如图6所示，该集群管理装置的监控端包括目标资源数据接收模块621、目标资源数据存储模块622、可视化显示和管理模块623、集群管理指令生成模块624和集群管理指令发送模块625。各功能模块详细说明如下：
目标资源数据接收模块621，用于接收集群端通过日志收集分析框架发送的目标资源数据；
目标资源数据存储模块622，用于将目标资源数据存储到预设的数据库中；
可视化显示和管理模块623，用于通过构建可视化界面显示数据库中存储的目标资源数据；
集群管理指令生成模块624，用于若检测到用户在可视化界面的管理操作，则根据管理操作生成相应的集群管理指令；
集群管理指令发送模块625，用于将集群管理指令发送到集群端。
进一步地，可视化显示和管理模块623包括：
可视化图表构建单元6231，用于根据目标资源数据，构建可视化图表，其中，可视化图表包括趋势图、频数图、比重图或数据表格中的至少一个；
可视化图表显示单元6232，用于在可视化界面中显示可视化图表。
进一步地，该集群管理装置的监控端还包括：
第一预警模块626，用于若目标资源数据满足预设的第一预警范围，则发送预警信息；
第二预警模块627，用于若目标资源数据满足预设的第二预警范围，则执行相应的应急预警措施。
本实施例提供的一种集群管理装置中各模块/单元实现各自功能的过程，具体可参考前述实施例1的描述，此处不再赘述。
实施例3
本实施例提供一计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现实施例1中集群管理方法，为避免重复，这里不再赘述。或者，该计算机程序被处理器执行时实现实施例2中集群管理装置中各模块/单元的功能，为避免重复，这里不再赘述。
实施例4
图7是本发明一实施例提供的终端设备的示意图。如图7所示，该实施例的终端设备7包括：处理器71、存储器72以及存储在存储器72中并可在处理器71上运行的计算机程序73，例如集群管理方法的程序。处理器71执行计算机程序73时实现上述实施例1中集群管理方法的步骤，例如图1所示的步骤S101至步骤S109。或者，处理器71执行计算机程序73时实现上述实施例2中集群管理装置的各模块/单元的功能，例如图6所示集群端的模块611至模块614的功能，以及监控端的模块621至模块625的功能。
示例性的，计算机程序73可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器72中，并由处理器71执行，以完成本发明。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序73在终端设备7中的执行过程。例如，计算机程序73可以被分割成基础资源数据获取模块、目标资源数据获取模块、目标资源数据发送模块和集群管理指令处理模块。各功能模块详细说明如下：
基础资源数据获取模块，用于获取基础资源数据，其中，基础资源数据用于记录集群端的配置信息和执行数据；
目标资源数据获取模块，用于通过日志收集分析框架对基础资源数据进行处理，得到目标资源数据；
目标资源数据发送模块，用于将目标资源数据发送给监控端；
集群管理指令处理模块，用于若接收到监控端发送的集群管理指令，则根据集群管理指令进行集群管理。
进一步地，基础资源数据获取模块包括：
监控脚本部署单元，用于部署监控脚本；
基础资源数据收集单元，用于基于监控脚本收集基础资源数据。
进一步地，目标资源数据获取模块包括：
日志收集分析框架部署单元，用于部署分布式发布订阅消息系统Kafka和日志分析工具Logstash；
基础资源数据获取单元，用于通过Kafka实时获取基础资源数据；
目标资源数据获取单元，用于使用Logstash对基础资源数据进行分类过滤，得到目标资源数据。
计算机程序73还可以被分割成目标资源数据接收模块、目标资源数据存储模块、可视化显示和管理模块、集群管理指令生成模块和集群管理指令发送模块。各功能模块详细说明如下：
目标资源数据接收模块，用于接收集群端通过日志收集分析框架发送的目标资源数据；
目标资源数据存储模块，用于将目标资源数据存储到预设的数据库中；
可视化显示和管理模块，用于通过构建可视化界面显示数据库中存储的目标资源数据；
集群管理指令生成模块，用于若检测到用户在可视化界面的管理操作，则根据管理操作生成相应的集群管理指令；
集群管理指令发送模块，用于将集群管理指令发送到集群端。
进一步地，可视化显示和管理模块包括：
可视化图表构建单元，用于根据目标资源数据，构建可视化图表，其中，可视化图表包括趋势图、频数图、比重图或数据表格中的至少一个；
可视化图表显示单元，用于在可视化界面中显示可视化图表。
进一步地，计算机程序73还可以被分割成包括：
第一预警模块，用于若目标资源数据满足预设的第一预警范围，则发送预警信息；
第二预警模块，用于若目标资源数据满足预设的第二预警范围，则执行相应的应急预警措施。
终端设备7可以是桌上型计算机、笔记本、掌上电脑及云端服务器等终端设备。终端设备7可包括，但不仅限于，处理器71、存储器72及计算机程序73。本领域技术人员可以理解，图7仅仅是终端设备7的示例，并不构成对终端设备7的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如终端设备7还可以包括输入输出设备、网络接入设备、总线等。
处理器71可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
存储器72可以是终端设备7的内部存储单元，例如终端设备7的硬盘或内存。存储器72也可以是终端设备7的外部存储设备，例如终端设备7上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，存储器72还可以既包括终端设备7的内部存储单元也包括外部存储设备。存储器72用于存储所述计算机程序以及终端设备7所需的其他程序和数据。存储器72还可以用于暂时地存储已经输出或者将要输出的数据。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括是电载波信号和电信信号。
以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换，而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。