CN116450464B - 运维管理方法、系统及设备 - Google Patents

Abstract

本发明提供了一种运维管理方法、系统及设备，所述方法包括以下步骤：服务器端获取所述交互端生成的插件文件；所述插件文件包括监控策略信息；所述服务器端将所述插件文件与所述代理节点端进行关联，并将每一所述插件文件部署于相关联的所述代理节点端；所述代理节点端加载相关联的所述监控策略信息，并执行与所述监控策略信息对应的监控管理程序，以获得监控数据；以及所述代理节点端根据所述监控数据，执行预设故障修复操作或者预设监控告警操作；本发明提供一种灵活性和易用性较好的运维管理方法，使得客户自己的运维人员可以随时根据客户实际需求，便捷接入运维系统即可实现运维监控需求变更的目的。

Description

运维管理方法、系统及设备

技术领域

本发明涉及IT运维软件技术领域，具体地说，涉及一种运维管理方法、系统及设备。

背景技术

对于许多客户来说，通常会从运维系统服务提供商来采购IT运维服务。在IT系统运维管理过程中，在采购IT运维系统之后，后续随着实际情况的变化，客户的运维监控需求会有变更（比如增删改），这是运维系统服务提供商经常会面临的问题。

在相关技术中，客户需求变更后，由于运维系统结构复杂，客户自己的运维人员通常无法完成对完整运维系统的重新编码等操作，需要依赖运维系统服务提供商对相应的运维系统进行重新编码、编译、上线发布等操作，时间成本较高。对于客户来说，需要等待服务提供商将变更的功能实现完成之后，才能升级系统；时间和费用成本也都较大，导致目前的运维管理方法的灵活性较差。

因此，如何提供一种灵活性和易用性较好的运维管理方法，使得客户能够更加灵活地实现运维监控需求变更的目的，是目前面临的一个问题。

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

发明内容

针对现有技术中的问题，本发明的目的在于提供一种运维管理方法、系统及设备，提供一种灵活性和易用性较好的运维管理方法，使得客户自己的运维人员可以随时根据客户实际需求，便捷接入运维系统即可实现运维监控需求变更的目的。

为实现上述目的，本发明提供了一种运维管理方法，应用于运维管理系统，所述运维管理系统包括交互端、服务器端以及代理节点端；所述服务器端分别与所述交互端和所述代理节点端建立通信；所述方法包括以下步骤：

S110，服务器端获取所述交互端生成的插件文件；所述插件文件包括相关联的监控策略信息和监控管理程序；

S120，所述服务器端将所述插件文件与所述代理节点端进行关联，并将每一所述插件文件部署于相关联的所述代理节点端；其中，每一所述代理节点端与对应的所述插件文件中包含的监控策略信息相关联；

S130，所述代理节点端加载相关联的所述监控策略信息，并执行与所述监控策略信息对应的监控管理程序，以获得监控数据；以及

S140，所述代理节点端根据所述监控数据，执行预设故障修复操作或者预设监控告警操作。

可选地，步骤S110包括：

基于所述交互端获取所有的监控指标；

基于所有的所述监控指标，生成插件文件。

可选地，所述监控策略信息中包括时间规划策略；步骤S130包括：

所述代理节点端获取所述监控策略信息中的时间规划策略；

所述代理节点端根据所述时间规划策略，生成时间执行队列；

所述代理节点端将所述监控策略信息添加至所述时间执行队列中；

所述代理节点端每间隔第一预设时长轮询所述时间执行队列，执行对应的所述监控策略信息，以获得监控数据；

步骤S140包括：

所述代理节点端将所述监控数据写入第一日志文件中。

可选地，所述监控策略信息中还包括日志文件采集策略；步骤S130包括：

所述代理节点端获取所述监控策略信息中的日志文件采集策略；

所述代理节点端根据所述日志文件采集策略，生成日志队列；

所述代理节点端将所述监控策略信息添加至所述日志队列中；

步骤S140包括：

所述代理节点端每间隔第二预设时长轮询所述日志队列，根据所述日志文件采集策略和所述第一日志文件，获得第二日志文件，并将所述第二日志文件发送至所述交互端。

可选地，所述日志文件采集策略包括日志文件名和字符串匹配条件；步骤S140包括：

所述代理节点端根据所述日志文件名和所述字符串匹配条件，从所述第一日志文件中抽取数据，组合形成第二日志文件。

可选地，所述插件文件、所述监控策略信息、所述时间规划策略以及所述日志文件采集策略以多级目录的形式进行存储；且第一级目录为插件文件组；所述插件文件组包括多个所述插件文件；所述插件文件位于第二级目录；所述监控策略信息位于第三级目录；所述时间规划策略以及所述日志文件采集策略位于第四级目录。

可选地，步骤S130还包括：

当所述代理节点端接收到所述服务器端发送的插件更新指令，所述代理节点端依据所述插件更新指令，分别对所述第二级目录、第三级目录以及第四级目录中的对应文件进行更新。

可选地，所述监控策略信息中包含策略组，所述策略组包括多个策略文件，每一所述策略文件与一所述代理节点端相关联，且所述策略文件分别与所述时间规划策略以及所述日志文件采集策略相关联。

可选地，多个所述代理节点端归属于一节点组；步骤S120包括：

将所述策略组与所述节点组进行关联；

将所述策略组中的策略文件分发至相关联的所述节点组，以将所述策略文件分发至所述节点组中所有的代理节点端并执行。

可选地，步骤S140包括：

当与一监控指标对应的所述监控数据存在异常，判断是否存在与所述监控指标对应的预设故障修复操作；

若存在，则根据所述监控数据和所述预设故障修复操作，对对应异常的监控指标进行修复；

若不存在，则根据所述监控数据和对应的监控指标，生成告警信息，并将所述告警信息发送至所述交互端。

可选地，所述代理节点端相关联的所述监控策略信息中还包括运维人员的终端设备信息和邮箱信息；步骤S140包括：

当执行预设监控告警操作时，将所述监控数据发送至所述运维人员的终端设备信息和邮箱信息。

本发明还提供了一种运维管理系统，用于实现上述运维管理方法，所述系统包括交互端、服务器端以及代理节点端；

所述交互端用于生成插件文件；

所述服务器端获取所述插件文件，以及将所述插件文件与所述代理节点端进行关联，并将每一所述插件文件部署于相关联的所述代理节点端；其中，所述插件文件包括监控策略信息；每一所述代理节点端与对应的所述插件文件中包含的监控策略信息相关联；

所述代理节点端加载相关联的所述监控策略信息，并执行与所述监控策略信息对应的监控管理程序，以获得监控数据；以及根据所述监控数据，执行预设故障修复操作或者预设监控告警操作。

本发明还提供了一种运维管理设备，包括：

处理器；

存储器，其中存储有上述处理器的可执行程序；

其中，上述处理器配置为经由执行上述可执行程序来执行上述任意一项运维管理方法的步骤。

本发明还提供了一种计算机可读存储介质，用于存储程序，上述程序被处理器执行时实现上述任意一项运维管理方法的步骤。

本发明与现有技术相比，具有以下优点及突出性效果：

本发明提供的运维管理方法、系统及设备使得客户自己的运维人员可以随时根据客户实际需求，自己编写程序或脚本以生成插件文件，即可便捷接入运维系统实现运维监控需求变更的目的，不依赖于运维系统服务提供商的开发人员去编码、升级，提高了运维管理的灵活性和易用性；

另一方面，本发明将插件文件下发到管理的代理节点之后，根据时间计划自动运行，采集信息，并根据配置的阈值数据及时触发告警或者故障修复行为，实现系统运维管理的智能化、自动化，保障系统的稳定运行。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显。

图1为本发明一实施例公开的一种运维管理系统的结构示意图；

图2为本发明一实施例公开的一种运维管理方法的示意图；

图3为本发明另一实施例公开的一种运维管理方法的示意图；

图4为本发明另一实施例公开的一种运维管理方法的示意图；

图5为本发明另一实施例公开的一种运维管理方法的示意图；

图6为本发明另一实施例公开的一种运维管理方法的示意图；

图7为本发明一实施例公开的一种运维管理设备的结构示意图。

具体实施方式

以下通过特定的具体实例说明本申请的实施方式，本领域技术人员可由本申请所揭露的内容轻易地了解本申请的其他优点与功效。本申请还可以通过另外不同的具体实施方式加以实施或应用系统，本申请中的各项细节也可以根据不同观点与应用系统，在没有背离本申请的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

下面以附图为参考，针对本申请的实施例进行详细说明，以便本申请所属技术领域的技术人员能够容易地实施。本申请可以以多种不同形态体现，并不限定于此处说明的实施例。

在本申请的表示中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的表示意指结合该实施例或示例表示的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，表示的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本申请中表示的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于表示目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的表示中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

为了明确说明本申请，省略与说明无关的器件，对于通篇说明书中相同或类似的构成要素，赋予了相同的参照符号。

在通篇说明书中，当说某器件与另一器件“连接”时，这不仅包括“直接连接”的情形，也包括在其中间把其它元件置于其间而“间接连接”的情形。另外，当说某种器件“包括”某种构成要素时，只要没有特别相反的记载，则并非将其它构成要素排除在外，而是意味着可以还包括其它构成要素。

当说某器件在另一器件“之上”时，这可以是直接在另一器件之上，但也可以在其之间伴随着其它器件。当对照地说某器件“直接”在另一器件“之上”时，其之间不伴随其它器件。

虽然在一些实例中术语第一、第二等在本文中用来表示各种元件，但是这些元件不应当被这些术语限制。这些术语仅用来将一个元件与另一个元件进行区分。例如，第一接口及第二接口等表示。再者，如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。应当进一步理解，术语“包含”、“包括”表明存在的特征、步骤、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、步骤、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“A、B或C”或者“A、B和/或C”意味着“以下任一个：A；B；C；A和B；A和C；B和C；A、B和C”。仅当元件、功能、步骤或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。

此处使用的专业术语只用于言及特定实施例，并非意在限定本申请。此处使用的单数形态，只要语句未明确表示出与之相反的意义，那么还包括复数形态。在说明书中使用的“包括”的意义是把特定特性、区域、整数、步骤、作业、要素及/或成份具体化，并非排除其它特性、区域、整数、步骤、作业、要素及/或成份的存在或附加。

虽然未不同地定义，但包括此处使用的技术术语及科学术语，所有术语均具有与本申请所属技术领域的技术人员一般理解的意义相同的意义。普通使用的字典中定义的术语追加解释为具有与相关技术文献和当前提示的内容相符的意义，只要未进行定义，不得过度解释为理想的或非常公式性的意义。

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

如图1所示，本发明一实施例公开了一种运维管理系统1，该运维管理系统包括交互端11、服务器端12以及代理节点端13。上述服务器端12分别与上述交互端11和上述代理节点端13建立通信。

上述交互端11用于生成插件文件。具体而言，当运维系统客户需要进行运维监控需求变更时，客户自己的运维人员可以随时根据客户实际需求，在交互端编写监控管理程序，这个监控管理程序可以是一个或多个程序模块的集合。客户自己的运维人员可以采用任何语言工具编写，只要能在需要监控管理的代理节点端上正常运行即可。其中，监控管理程序需要上传至服务器端中。具体实施时，可以根据监控管理程序生成插件文件，插件文件中还包含监控管理程序和监控策略信息中的时间规划策略的关联关系，以及监控管理程序和代理节点端的关联关系。该交互端可以为一展示于计算机上的交互界面，本发明对其具体实现形式不作限定。

上述服务器端12获取上述插件文件，以及将插件文件与代理节点端进行关联，并将每一个插件文件部署于与该插件文件相关联的代理节点端。也即，每一个代理节点端均具有相对应的插件文件。

其中，上述插件文件包括相关联的监控策略信息和监控管理程序。每一个代理节点端与对应的上述插件文件中包含的监控策略信息相关联。

上述代理节点端13加载相关联的上述监控策略信息，并执行与上述监控策略信息对应的监控管理程序，以获得监控数据。以及根据上述监控数据，执行预设故障修复操作或者预设监控告警操作。该监控管理程序可以预先存储于上述插件文件中，监控管理程序与监控策略信息相关联。

这样客户自己的运维人员可以随时根据客户实际需求，自己编写程序或脚本以生成插件文件，即可便捷接入运维系统实现运维监控需求变更的目的。

可以理解的是，本发明实施例公开的运维管理系统还包括其他支持运维管理系统运行的现有功能模块。图1显示的运维管理系统仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

需要说明的是，本发明上述实施例中图1仅示出了三个代理节点端，仅用于示例性说明，本发明对运维管理系统中的代理节点端数量并不作限定。

如图2所示，本发明一实施例公开了一种运维管理方法。该运维管理方法应用于上述运维管理系统。上述运维管理方法包括以下步骤：

S110，服务器端获取上述交互端生成的插件文件。

具体实施时，该步骤S110可以包括：

S111，基于上述交互端获取所有的监控指标。

S112，基于所有的上述监控指标，生成插件文件。上述监控指标比如可以为CPU温度或者数据库占用内存等。本发明对此不作限定。插件文件中包含监控策略信息和监控管理程序。且监控策略信息和监控管理程序相关联。

这样有利于实现客户自己的运维人员可以随时根据客户实际需求，自己编写程序或脚本完成监控管理程序，以生成插件文件。

S120，服务器端将上述插件文件与代理节点端进行关联，并将每一上述插件文件部署于相关联的代理节点端。其中，每一个代理节点端与对应的插件文件中包含的监控策略信息相关联。具体而言，服务器端在接收到交互端发送的插件文件之后，将该插件文件发送给相关联的代理节点端。服务器端将每一个监控策略信息分发至相关联的上述代理节点端。

每一个代理节点端可以与多个监控策略信息相关联。每一个监控策略信息也可以关联多个代理节点端。上述监控策略信息可以以配置文件的形式存储于服务器端或者代理节点端。

S130，代理节点端加载相关联的监控策略信息，并执行与上述监控策略信息对应的监控管理程序，以获得监控数据。以及

S140，代理节点端根据上述监控数据，执行预设故障修复操作或者预设监控告警操作。比如可以根据上述监控数据和预先配置的预设阈值数据，触发告警或者预设故障修复操作。比如当监控数据大于等于上述预设阈值数据时，触发告警。当监控数据小于预设阈值数据时，不执行任何操作。

可以预先建立上述预设故障修复操作与监控指标之间的映射关系。比如监控指标为CPU温度，那么对应的预设故障修复操作可以降低CPU转速。也即，当出现故障，且监控数据对应的监控指标存在对应的预设故障修复操作时，直接执行该预设故障修复操作。

这样就实现了根据配置的阈值数据及时触发告警或者故障修复行为，实现系统运维管理的智能化、自动化，利于保障运维系统的稳定运行。

基于本发明上述实施例公开的运维管理方法，客户公司运维人员可以通过交互端创建插件文件，定制监控策略信息，将监控策略关联到需要管理的代理节点端，并分发策略；服务器端保存监控策略及其关联关系，分发监控策略到对应的代理节点端，代理节点端轮询策略，执行策略规划好的指令，采集信息，将采集监控到的数据发送到服务器端，即完成完整的运维管理自动化流程。

在一些可选的实施例中，上述代理节点端相关联的上述监控策略信息中还包括运维人员的终端设备信息和邮箱信息。

相应地，步骤S140还包括：

当执行预设监控告警操作时，将上述监控数据发送至上述运维人员的终端设备信息和邮箱信息。比如发送至客户运维系统对应的运维人员的手机或者邮箱，可以起到及时通知的效果，利于实现系统运维管理的智能化、自动化，利于保障运维系统的稳定运行。其中，上述运维人员可以为客户自己公司的运维人员。

在本申请的另一实施例中，公开了另一种运维管理方法。如图3所示，该方法在上述图2对应实施例的基础上，上述监控策略信息中包括时间规划策略。步骤S130包括：

S131，代理节点端获取监控策略信息中的时间规划策略。

S132，代理节点端根据时间规划策略，生成时间执行队列。

S133，代理节点端将监控策略信息添加至时间执行队列中。以及

S134，代理节点端每间隔第一预设时长轮询时间执行队列，执行对应的监控策略信息，以获得监控数据。

步骤S140替换为步骤S141：

代理节点端将监控数据写入第一日志文件中，并根据监控数据，执行预设故障修复操作或者预设监控告警操作。

示例性地，上述第一预设时长可以为1分钟，本发明不以此为限。比如每1分钟轮询时间执行队列，执行配置在监控策略信息中的命令，采集信息，写入到第一日志文件中。

该实施例中，与监控策略信息中命令执行同步生成第一日志文件，便于客户公司的运维人员在进行运维管理的过程中，在出现故障时，提供相关参考信息，提高了客户自己进行运维管理的灵活性和易用性。

在本申请的另一实施例中，公开了另一种运维管理方法。如图4所示，该方法在上述图2对应实施例的基础上，上述监控策略信息中还包括日志文件采集策略。步骤S130包括：

S135，代理节点端获取监控策略信息中的日志文件采集策略。

S136，代理节点端根据日志文件采集策略，生成日志队列。以及

S137，代理节点端将监控策略信息添加至日志队列中。

步骤S140替换为步骤S142：

代理节点端根据上述监控数据，执行预设故障修复操作或者预设监控告警操作；并且每间隔第二预设时长轮询日志队列，根据日志文件采集策略和第一日志文件，获得第二日志文件，并将第二日志文件发送至交互端。

也即，将上述第二日志文件展示给客户公司的运维人员作为参考，使其不必查看全部的第一日志文件，只需查看第二日志文件即可，降低了客户公司的运维人员的学习门槛和运维难度，提高了客户自己进行运维管理的灵活性和易用性。

可选地，上述日志文件采集策略包括日志文件名和字符串匹配条件。步骤S140包括：

上述代理节点端根据上述日志文件名和上述字符串匹配条件，从上述第一日志文件中抽取数据，组合形成第二日志文件。其中，日志文件名和上述字符串匹配条件根据监控指标而确定。

示例性地，上述第二预设时长可以为1分钟，本发明不以此为限。

在本申请的另一实施例中，公开了另一种运维管理方法。该方法在上述图4对应实施例的基础上，上述监控策略信息中包含策略组，上述策略组包括多个策略文件，每一上述策略文件与一上述代理节点端相关联，且上述策略文件分别与上述时间规划策略以及上述日志文件采集策略相关联。

这样客户公司运维人员在通过交互端比如web页面关联代理节点端的时候，就比较方便，只需要把策略组和代理节点端进行关联即可，就可以实现一次性把多个策略文件关联到代理节点端，有利于降低客户公司运维人员的操作复杂度和难度，提高了客户自己进行运维管理的灵活性和易用性。

可选地，在上一实施例的基础上，多个代理节点端归属于一节点组。如图5所示，该实施例中，步骤S120包括：

S121，将上述策略组与上述节点组进行关联。以及

S122，将上述策略组中的策略文件分发至相关联的节点组，以将策略文件分发至该节点组中所有的代理节点端并执行。

这样客户公司运维人员在部署策略文件的时候，只需要针对节点组层面和策略组层面进行操作即可，降低了运维人员的操作复杂度和难度，提高了客户自己进行运维管理的灵活性和易用性。

在本申请的另一实施例中，公开了另一种运维管理方法。该方法在上述图4对应实施例的基础上，上述插件文件、监控策略信息、时间规划策略以及上述日志文件采集策略以多级目录的形式进行存储。且第一级目录为插件文件组。上述插件文件组包括多个上述插件文件。上述插件文件位于第二级目录。上述监控策略信息位于第三级目录。上述时间规划策略以及上述日志文件采集策略位于第四级目录。

步骤S130还包括：

当上述代理节点端接收到上述服务器端发送的插件更新指令，上述代理节点端依据上述插件更新指令，分别对上述第二级目录、第三级目录以及第四级目录中的对应文件进行更新。

这样便于客户公司运维人员对生成的插件文件的直观感知，便于其直观进行监控管理策略调整和部署，降低了运维人员的操作复杂度和难度，提高了客户自己进行运维管理的灵活性和易用性。

下面对插件文件组的组织结构也即上述多级目录的存储形式进行示例性说明：

<Agent>/plugins/ #所有的plugin都在这个目录下

perf/ #plugin ‘perf’，监控系统性能

policy/ #监控策略目录

group/ #策略所属的组即策略组

perf_grp #策略文件

sche/ #按照时间规划运行的策略目录

perf_sche #时间规划策略

log/ #读取日志文件采集信息的策略目录

perf_log #日志文件采集策略

instrumentation/ #通过策略运行的文件目录

perf.py #监控管理程序

fs/ #plugin ‘fs’，监控系统文件系统

policy/

group/

sche/

log/

instrumentation/ #

其中，上述示出的‘<Agent>/plugins/’即为第一级目录，‘perf/’和‘fs/’ 即为第二级目录，‘policy/’和‘instrumentation/’ 即为第三级目录，‘group/’、‘sche/’、‘log/’和‘perf.py’等即为第四级目录。

参考上述示例，plugins目录位于agent服务的指定目录下，这里以变量<Agent>表示，这样agent服务在运行plugin（插件文件）的时候，就可以定位到这个目录。这个目录下存放的是多个plugin（插件），上面的示例中有2个plugin：perf 和 fs。

Plugin‘perf’下面有2个目录：一个是policy目录，存放的是plugin运行策略policy，即监控策略信息。另一个是instrumentation目录，存放的是plugin运行程序（即监控管理程序）和工具，这个目录下面的文件可以是任何语言编写的，只要确保能在代理节点端上运行起来。

policy目录下有3个目录：一个是group目录，下面存放一个或多个文件，表示这个plugin预先定制的一些策略组policy group。一个是sche目录（即时间规划策略），下面是一个或多个文件，描述plugin按照时间执行程序的一些规划。一个是log目录（即日志文件采集策略），下面是一个或多个策略文件，描述plugin读取日志文件，采集信息、发送信息的一些规则。group目录下的每个文件会关联当前plugin的sche 或/和 log目录下的一些策略文件。比如perf_grp文件包含了perf_sche和perf_log，这样在通过交互端web页面关联管理代理节点端的时候，就比较方便，只需要把策略组关联到管理节点，就可以一次性把多个策略关联到管理节点。policy或policy group文件的格式可以是json，yml，xml等格式。

instrumentation目录下保存的是plugin的策略执行的文件，包括一个或多个可执行文件以及可执行文件需要的配置文件，这个目录下的文件是和sche目录下的策略关联起来，通过sche目录下的策略文件触发执行。如perf_sche就描述了perf.py按照时间规划执行的计划。plugin‘fs’的文件和目录组织结构类似。

管理节点的agent服务只需要轮询plugins目录下的sche和log类型的policy文件，就可以触发监控程序，采集信息，无需重新编译，重启，升级系统。如果需要删除plugin，只需要页面选中某个plugin，直接删除。完全以热插拔的方式实现设备管理的动态扩展。

其中，对于不同的监控对象，有不同的监控指标，比如对文件系统的监控，对数据库的监控，其监控指标应该是不一样的，因而需要不同的plugin（插件文件）实现不同的监控目的。

一个plugin的创建需要包括两方面：一个是policy集，用于配置需要执行的采集信息的程序，和需要抽取信息的日志文件；一个是采集信息的程序，实现对监控指标的定时采集，在policy中配置运行时间，即可定期采集数据。可以参考上面的plugin文件组织结构加以理解。

一个plugin创建好之后，可以导出，反过来也可以导入。然后就可以通过policy分发操作下发到需要监控的代理节点上，实现对象监控。

在本申请的另一实施例中，公开了另一种运维管理方法。如图6所示，该方法在上述图2对应实施例的基础上，步骤S140包括：

S143，当与一监控指标对应的监控数据存在异常，判断是否存在与上述监控指标对应的预设故障修复操作。

若存在，则执行步骤S144：根据上述监控数据和上述预设故障修复操作，对对应异常的监控指标进行修复。

若不存在，则执行步骤S145：根据上述监控数据和对应的监控指标，生成告警信息，并将上述告警信息发送至上述交互端。

本发明上述实施例公开的运维管理方法提供了一种插件式开发接口，使客户的运维人员可以随时根据实际需求，自己编写程序或脚本，简捷接入管理系统即可工作，达到监控和管理的目的。而无需重新编码、编译、升级系统。同时插件的开发定制也方便易用，功能扩展不受限制。

上述实施例公开的运维管理方法不仅可以以热插拔的方式在管理系统上方便地添加或删除监控对象，及时告警，还可以进行自动化的故障清除，根据运维人员的经验配置合适的故障清除指令，在系统预警阶段，自动执行故障清除指令，保障系统功能恢复正常，实现系统的智能化运维。其中，上述告警信息可以直接发出或者转换文本格式之后发出，或者可以根据运维人员配置进行目录下的文件断开、写日志文件等行为，也可以提供一个接口，转发至运维人员配置的指定的其他服务器等等，这些触发操作运维人员都可以进行自定义配置，本发明对此不作限制。

需要说明的是，本申请中公开的上述所有实施例可以进行自由组合，组合后得到的技术方案也在本申请的保护范围之内。

本发明实施例公开的上述运维管理系统还可以用于实现上述的运维管理的方法，因此对于运维管理系统的具体实施步骤可以参照上述对运维管理的方法的描述，此处不再赘述。

本发明一实施例还公开了一种运维管理设备，包括处理器和存储器，其中存储器存储有上述处理器的可执行程序；处理器配置为经由执行可执行程序来执行上述运维管理方法中的步骤。图7是本发明公开的运维管理设备的结构示意图。下面参照图7来描述根据本发明的这种实施方式的电子设备600。图7显示的电子设备600仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，电子设备600以通用计算设备的形式表现。电子设备600的组件可以包括但不限于：至少一个处理单元610、至少一个存储单元620、连接不同平台组件（包括存储单元620和处理单元610）的总线630、显示单元640等。

其中，存储单元存储有程序代码，程序代码可以被处理单元610执行，使得处理单元610执行本说明书上述运维管理方法部分中描述的根据本发明各种示例性实施方式的步骤。例如，处理单元610可以执行如图2中所示的步骤。

存储单元620可以包括易失性存储单元形式的可读介质，例如随机存取存储单元（RAM）6201和/或高速缓存存储单元6202，还可以进一步包括只读存储单元（ROM）6203。

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

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

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

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

如上所示，该实施例的计算机可读存储介质的程序在执行时，利于客户自己的运维人员可以随时根据客户实际需求，自己编写程序或脚本以生成插件文件，即可便捷接入运维系统实现运维监控需求变更的目的，不依赖于运维系统服务提供商的开发人员去编码、升级，提高了运维管理的灵活性和易用性；

另一方面，本发明将插件文件下发到管理的代理节点之后，根据时间计划自动运行，采集信息，并根据配置的阈值数据及时触发告警或者故障修复行为，实现系统运维管理的智能化、自动化，保障系统的稳定运行。

本发明一实施例公开了一种计算机可读存储介质。该存储介质是实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器（CD-ROM）并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

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

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

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

本发明实施例提供的运维管理方法、系统及设备有利于实现客户自己的运维人员可以随时根据客户实际需求，自己编写程序或脚本以生成插件文件，即可便捷接入运维系统实现运维监控需求变更的目的，不依赖于运维系统服务提供商的开发人员去编码、升级，提高了运维管理的灵活性和易用性；

另一方面，本发明将插件文件下发到管理的代理节点之后，根据时间计划自动运行，采集信息，并根据配置的阈值数据及时触发告警或者故障修复行为，实现系统运维管理的智能化、自动化，保障系统的稳定运行。

以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (10)

1.一种运维管理方法，其特征在于，应用于运维管理系统，所述运维管理系统包括交互端、服务器端以及代理节点端；所述服务器端分别与所述交互端和所述代理节点端建立通信；所述方法包括以下步骤：

S110，服务器端获取所述交互端生成的插件文件；所述插件文件包括相关联的监控策略信息和监控管理程序；

S120，所述服务器端将所述插件文件与所述代理节点端进行关联，并将每一所述插件文件部署于相关联的所述代理节点端；其中，每一所述代理节点端与对应的所述插件文件中包含的监控策略信息相关联；

S130，所述代理节点端加载相关联的所述监控策略信息，并执行与所述监控策略信息对应的监控管理程序，以获得监控数据；以及

S140，所述代理节点端根据所述监控数据，执行预设故障修复操作或者预设监控告警操作；

所述监控策略信息中包括时间规划策略；步骤S130包括：

所述代理节点端获取所述监控策略信息中的时间规划策略；

所述代理节点端根据所述时间规划策略，生成时间执行队列；

所述代理节点端将所述监控策略信息添加至所述时间执行队列中；

所述代理节点端每间隔第一预设时长轮询所述时间执行队列，执行对应的所述监控策略信息，以获得监控数据；

步骤S140包括：

所述代理节点端将所述监控数据写入第一日志文件中；

所述监控策略信息中还包括日志文件采集策略；步骤S130包括：

所述代理节点端获取所述监控策略信息中的日志文件采集策略；

所述代理节点端根据所述日志文件采集策略，生成日志队列；

所述代理节点端将所述监控策略信息添加至所述日志队列中；

步骤S140包括：

所述代理节点端每间隔第二预设时长轮询所述日志队列，根据所述日志文件采集策略和所述第一日志文件，获得第二日志文件，并将所述第二日志文件发送至所述交互端。

2.如权利要求1所述的运维管理方法，其特征在于，步骤S110包括：

基于所述交互端获取所有的监控指标；

基于所有的所述监控指标，生成插件文件。

3.如权利要求1所述的运维管理方法，其特征在于，所述日志文件采集策略包括日志文件名和字符串匹配条件；步骤S140包括：

所述代理节点端根据所述日志文件名和所述字符串匹配条件，从所述第一日志文件中抽取数据，组合形成第二日志文件。

4.如权利要求1所述的运维管理方法，其特征在于，所述插件文件、所述监控策略信息、所述时间规划策略以及所述日志文件采集策略以多级目录的形式进行存储；且第一级目录为插件文件组；所述插件文件组包括多个所述插件文件；所述插件文件位于第二级目录；所述监控策略信息位于第三级目录；所述时间规划策略以及所述日志文件采集策略位于第四级目录。

5.如权利要求4所述的运维管理方法，其特征在于，步骤S130还包括：

当所述代理节点端接收到所述服务器端发送的插件更新指令，所述代理节点端依据所述插件更新指令，分别对所述第二级目录、第三级目录以及第四级目录中的对应文件进行更新。

6.如权利要求1所述的运维管理方法，其特征在于，所述监控策略信息中包含策略组，所述策略组包括多个策略文件，每一所述策略文件与一所述代理节点端相关联，且所述策略文件分别与所述时间规划策略以及所述日志文件采集策略相关联。

7.如权利要求6所述的运维管理方法，其特征在于，多个所述代理节点端归属于一节点组；步骤S120包括：

将所述策略组与所述节点组进行关联；

将所述策略组中的策略文件分发至相关联的所述节点组，以将所述策略文件分发至所述节点组中所有的代理节点端并执行。

8.如权利要求2所述的运维管理方法，其特征在于，步骤S140包括：

当与一监控指标对应的所述监控数据存在异常，判断是否存在与所述监控指标对应的预设故障修复操作；

若存在，则根据所述监控数据和所述预设故障修复操作，对对应异常的监控指标进行修复；

若不存在，则根据所述监控数据和对应的监控指标，生成告警信息，并将所述告警信息发送至所述交互端。

9.一种运维管理系统，用于实现如权利要求1所述的运维管理方法，其特征在于，所述系统包括交互端、服务器端以及代理节点端；

所述交互端用于生成插件文件；

所述服务器端获取所述插件文件，以及将所述插件文件与所述代理节点端进行关联，并将每一所述插件文件部署于相关联的所述代理节点端；其中，所述插件文件包括监控策略信息；每一所述代理节点端与对应的所述插件文件中包含的监控策略信息相关联；

所述代理节点端加载相关联的所述监控策略信息，并执行与所述监控策略信息对应的监控管理程序，以获得监控数据；以及根据所述监控数据，执行预设故障修复操作或者预设监控告警操作。

10.一种运维管理设备，其特征在于，包括：

处理器；

存储器，其中存储有所述处理器的可执行程序；

其中，所述处理器配置为经由执行所述可执行程序来执行权利要求1至8中任意一项所述运维管理方法的步骤。