CN113268891B - 一种运维系统的建模方法和装置 - Google Patents

Abstract

本发明实施例提供了一种运维系统的建模方法和装置。所述方法包括：步骤1，获取运维系统中的所有节点，构造所述运维系统的节点集合N；步骤2，获取所述运维系统中的所有节点的类型属性，构造所述运维系统的节点的属性标记函数C；并且为所述所有节点配置全局唯一的id；步骤3，获取所述运维系统中的所有节点之间的关联关系，构造所述运维系统的节点之间的关联关系集合E；步骤4，获取所述运维系统中的所有节点在一预定时间段内的运维事件，构造所述运维系统的节点上的在一预定时间段内的运维事件标记函数L；步骤5，将所述节点集合N、所述属性标记函数C、所述关联关系集合E、所述运维事件标记函数L作为所述运维系统的模型。

Description

一种运维系统的建模方法和装置

技术领域

本发明涉及运维领域，尤其涉及一种运维系统的建模方法和装置。

背景技术

随着运维领域的不断发展，运维系统的复杂程度逐渐增加，传统的运维手段对系统的管理和分析也日趋困难。在此基础上，智能运维应运而生。它通过自动化和智能化的手段对运维系统进行管理。然而，智能运维往往专注于运维领域的具体问题，对系统结构的整体把握有所欠缺，而从系统的各种信息和属性拼凑出的系统整体的模型往往通用性差且因此导致泛用性不足。

发明内容

本发明的实施例提供了一种运维系统的建模方法和装置，为进行自动化和智能化的运维故障排查提供了易用的模型。

一种运维系统的建模方法，所述方法包括：

步骤1，获取运维系统中的所有节点，构造所述运维系统的节点集合N；

步骤2，获取所述运维系统中的所有节点的类型属性，构造所述运维系统的节点的属性标记函数C；并且为所述所有节点配置全局唯一的id；

步骤3，获取所述运维系统中的所有节点之间的关联关系，构造所述运维系统的节点之间的关联关系集合E；

步骤4，获取所述运维系统中的所有节点在一预定时间段内的运维事件，构造所述运维系统的节点上的在一预定时间段内的运维事件标记函数L；

步骤5，将所述节点集合N、所述属性标记函数C、所述关联关系集合E、所述运维事件标记函数L作为所述运维系统的模型。

一种运维系统的建模装置，包括：

第一构造单元，获取运维系统中的所有节点，构造所述运维系统的节点集合N；

第二构造单元，获取所述运维系统中的所有节点的类型属性，构造所述运维系统的节点的属性标记函数C；并且为所述所有节点配置全局唯一的id；

第三构造单元，获取所述运维系统中的所有节点之间的关联关系，构造所述运维系统的节点之间的关联关系集合E；

第四构造单元，获取所述运维系统中的所有节点在一预定时间段内的运维事件，构造所述运维系统的节点上的在一预定时间段内的运维事件标记函数L；

建模单元，将所述节点集合N、所述属性标记函数C、所述关联关系集合E、所述运维事件标记函数L作为所述运维系统的模型。

由上述本发明的实施例提供的技术方案可以看出，本发明实施例中，本发明利用双标记迁移系统模型对运维系统进行建模，提出了对运维系统的通用抽象模型。模型通用性很好为运维人员处理问题提供了足够的条件，并为进一步进行自动化和智能化的运维故障排查提供了良好和易用的模型基础。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

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

图1为本发明的运维系统的建模方法的流程示意图；

图2为本发明应用场景中双标记迁移系统的建模流程图。

图3为本发明应用场景中业务流程示意图。

图4是本发明应用场景中运维系统的两个具体业务的流程及配置示意图。

图5为本发明应用场景中运维业务系统的网络配置示意图。

具体实施方式

下面详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

为便于对本发明实施例的理解，下面将结合附图以几个具体实施例为例做进一步的解释说明，且各个实施例并不构成对本发明实施例的限定。

以下先进行必要的名词解释：

运维系统：运维对象实体集合的统称，例如某互联网公司在某地的机房，银行业务系统等。

节点：运维系统中实现单一功能的实体模块或抽象模块，例如业务系统、模块、服务、中间件集群、中间件、虚拟机、微服务、服务器集群、主机等。节点本身具有一些属性，例如层级、类型等。用A表示系统中节点属性的集合。

运维事件：某种与运维系统结构或性质改变相关的事件，例如某服务器的CPU使用率超过阈值，某业务的响应时间过长，某服务调用的失败率过高等。通常情况下，运维事件包括运维人员关心的系统异常，以及服务的部署、变更、下架等系统结构改动。对于固定的运维系统，用Σ表示该系统内运维事件的集合。

运维系统模型

表示为如下的双标记迁移系统四元组：

接下来对这四部分内容进行详细的解释。

N为系统的节点集合，包括业务系统、模块、服务、中间件集群、中间件、服务器集群、虚拟机和主机。对于每一个系统的节点，我们为其分配一个全局唯一id来对其进行标记。

为系统有向边的集合，表示系统节点之间的关联关系，用于描述系统不同节点之间的从属、调用、部署、配置等信息。上述的节点层次(业务系统、模块、服务、中间件集群、中间件、服务器集群、虚拟机和主机)之间，排在前面的上层节点可以调用同层节点或者排在后面的下层节点，则在E中可能会有模块到中间件的边、服务到服务器集群的边等，但不会有虚拟机到服务的边，因为不会有下层节点到上层节点的边。节点的顺序关系已经在定义系统时给出，所获得的业务流程、业务配置和网络拓扑中带有这些信息，因此在建模时可以很方便地将节点的前后顺序抽取出来放入E中。

L:N×T→2^Σ为系统节点上的运维事件标记函数，用以刻画系统在不同时刻所处的具体状态。举例来说，L(n,i)＝{a₁,a₂}，表示系统节点n在时刻i发生了两个运维事件a₁和a₂。此处我们设定T为一个有限的时间区间。这一点是符合实际情况的，因为任何运维系统总是存在一个交付使用的开始时间，并且即使系统一直处于运行当中，其运行时长也是有限的。

C:N→2^A为系统节点属性的标记函数，用以刻画系统在任何时候都具有的特性。例如，C(vm₂)＝{type(apache),level(service)}，表示节点vm₂的层次(level)为服务(service)，其类型(type)为部署apache的网页服务器。需要注意的是，属性函数C与事件函数L在形式定义上的区别，即属性函数C不包含时间T，而事件函数L包含。这是基于我们对系统的一般认识：同一系统节点在不同时刻发生的运维事件可能不尽相同，但其属性不会随时间的变化而变化。

以上四部分组成了运维系统模型

首先，它包含了运维人员所关心的系统服务配置信息和调用链信息，并且不仅包括服务到服务的信息，也包含了细化的中间件调用情况。上述信息均在

的有向边集合E和节点标记函数C中得到体现。

其次，L包含了系统的变化和异常情况，为运维人员排查系统故障、定位故障原因提供了充分的信息。

如图1所示，为本发明所述的一种运维系统的建模方法，所述方法包括：

步骤1，获取运维系统中的所有节点，构造所述运维系统的节点集合N；所述步骤1具体为：从所述运维系统中的业务配置和网络拓扑中，抽取节点，根据抽取的所述节点构造节点集合N。

步骤2，获取所述运维系统中的所有节点的类型属性，构造所述运维系统的节点的属性标记函数C；并且为所述所有节点配置全局唯一的id；所述节点包括：业务系统、模块、服务器、中间件集群、中间件、服务器集群、虚拟机或物理主机中的一个或者多个。所述节点的类型属性包括：节点的系统层级、节点类型；所述节点类型包括：业务系统、模块、服务器、中间件集群、中间件、服务器集群、虚拟机、物理主机或数据库。

步骤3，获取所述运维系统中的所有节点之间的关联关系，构造所述运维系统的节点之间的关联关系集合E；所述步骤3包括：通过清洗所述运维系统中的业务流程和业务配置中节点的关联关系，获取所述运维系统中的节点之间的关联关系，将其加入E。可选的，所述步骤3还包括：通过所述运维系统的调用链数据中节点的关联关系，获取所述运维系统中的节点之间的关联关系，将其加入E。其中，

E为系统有向边的集合，用于描述节点之间的关联关系，所述关联关系包括：运维系统的节点之间的从属关系、调用关系、部署关系、配置关系，其中，N为系统的节点集合。

步骤4，获取所述运维系统中的所有节点在一预定时间段内的运维事件，构造所述运维系统的节点上的在一预定时间段内的运维事件标记函数L；所述步骤4包括：从所述运维系统的日志数据中，提取发生异常事件的节点、异常事件及其异常事件的发生时间；根据所述发生异常事件的节点、异常事件及其异常事件的发生时间，构造所述运维系统的节点上的运维事件标记函数L。或者，所述步骤4包括：从所述运维系统的指标数据中，提取指标数据发生异常的时间、指标数据发生异常对应的发生异常事件的节点、异常事件；根据所述发生异常事件的节点、异常事件及其异常事件的发生时间，构造所述运维系统的节点上的运维事件标记函数L。

步骤5，将所述节点集合N、所述属性标记函数C、所述关联关系集合E、所述运维事件标记函数L作为所述运维系统的模型。

本发明的目的是解决目前没有针对运维系统的通用建模方法，在充分理解运维领域的基础上，对运维系统进行了合理的抽象。针对运维领域的特点，将运维系统抽象为有标记迁移系统，同时对运维领域所关心的服务调用信息、系统配置信息、系统异常消息记录等方面均进行了建模，弥补了运维领域对运维系统没有通用建模的不足。而针对通常有标记迁移系统模型无法自然区分系统的时序性质和静态性质，发明双标记迁移系统来对运维系统进行抽象和建模。

本发明还提供一种运维系统的建模装置，包括：

第一构造单元，获取运维系统中的所有节点，构造所述运维系统的节点集合N；

第二构造单元，获取所述运维系统中的所有节点的类型属性，构造所述运维系统的节点的属性标记函数C；并且为所述所有节点配置全局唯一的id；

第三构造单元，获取所述运维系统中的所有节点之间的关联关系，构造所述运维系统的节点之间的关联关系集合E；

第四构造单元，获取所述运维系统中的所有节点在一预定时间段内的运维事件，构造所述运维系统的节点上的在一预定时间段内的运维事件标记函数L；

建模单元，将所述节点集合N、所述属性标记函数C、所述关联关系集合E、所述运维事件标记函数L作为所述运维系统的模型。

以下描述本发明的应用场景。本发明为一种基于双标记迁移系统的运维系统的建模方法，可用于对运维系统进行建模。以迁移系统描述了运维系统，并利用多个标签函数描述系统的时序性质和静态性质。

本发明的目的是解决目前没有针对运维系统的通用建模方法，在充分理解运维领域的基础上，对运维系统进行了合理的抽象。针对运维领域的特点，将运维系统抽象为有标记迁移系统，同时对运维领域所关心的服务调用信息、系统配置信息、系统异常消息记录等方面均进行了建模，弥补了运维领域对运维系统没有通用建模的不足。而针对通常有标记迁移系统模型无法自然区分系统的时序性质和静态性质，发明双标记迁移系统来对运维系统进行抽象和建模。

图2为双标记迁移系统的建模流程图。如图2所示，建立双标记迁移系统模型的算法需要四个数据源，分别是图2右边的日志数据、指标数据、调用链数据和业务配置及网络拓扑。

首先，算法从业务配置和网络拓扑中抽取所有的节点，形成节点集合N；并抽取所有节点的ID、类型等属性，构造属性标记函数C；

并清洗业务流程和业务配置部分的关联关系，将其加入E。

其次，通过调用链数据，算法在E中补全服务节点之间的关联关系。

至此，节点集合N，属性函数C和关联关系E构造完成。

其次，算法分别从日志数据和指标数据当中检测异常，形成运维事件标记函数L。对于日志数据，算法从中提取产生日志节点的ID、时间戳的固定字段的信息，并从日志消息中抽取异常事件及其发生的节点和时间。对于指标数据，算法将其抽象为时间序列并进行异常检测；节点的指标发生异常的时间点代表了该指标上的某一异常事件。将两种数据源得到的异常事件进行汇总，便构造出了运维事件标记函数L。

本发明具有以下有益效果：

本发明利用双标记迁移系统模型对运维系统进行建模，提出了对运维系统的通用抽象模型。该模型涵盖了运维和运营系统中业务流程、资源配置以及网络结构的各方面信息，为运维人员处理问题提供了足够的条件，并为进一步进行自动化和智能化的运维故障排查提供了良好和易用的模型基础。

图3为本发明实施例的业务流程示意图。在实施例中描述一个整体运维系统的各个方面，来说明基于双标记迁移系统的运维系统建模方法可以涵盖运维建模各方面的需要。

一个运维系统一般来说包括三个部分：业务流程、业务资源配置以及网络结构。

在此实施例中，我们描述一个具有两条业务线的系统。每条业务线的总体流程如下：用户调用业务功能，并由业务侧返回计算得到的数据。在业务的计算过程中会用到数据库当中的数据。因此整个业务流程形成了用户-业务-数据库的关系。

图4是运维系统的两个具体业务的流程及配置图。虚线的方框及箭头分别代表了某个业务完整的调用情况，其中每一个服务分别运行在独立的虚拟机上(如虚线方框右下角的方框所示)。每一个虚拟机都部署在物理主机上(如图中带有机箱图标的虚线方框所示)。v一业务在分布式服务器上的执行以实现资源的高效利用。对于图中表示的每一个虚拟机，以其图中的名字vm_i来表示。对于图中的物理主机，我们用ps_j表示，其中ps₁为部署vm₁和vm₆的主机，ps₂为部署vm₂的主机，ps₃为部署vm₃的主机，ps₄为部署vm₄和vm₇的主机，ps₅为部署vm₅和vm₈的主机。

图5为运维业务系统的网络配置图。因为两条业务线均部署在分布式服务器集群上，其信息交换均通过远程过程调用(RPC)方式进行，即通过网络实现不同服务器上的服务调用和数据请求。例如，对于图3中标示的业务，用户的请求通过网络中的核心交换机(图中CS节点)输入网络。该请求入网后，首先通过汇聚交换机节点DS，经路由rt₃发送至ps₁服务器上的虚拟机vm₁进行负载均衡。假定该请求m₁和vm₆上LVS类型的节点是负载均衡器，用于协调同

需由vm₂进行处理，则ps₁通过网络RPC调用的方式将工作任务发送给ps₂主机上的虚拟机vm₂。之后，vm₂通过RPC方式获取ps₃中vm₃上的数据，并完成计算和返回输出数据。

我们根据图3和图4中的业务流程、业务资源配置和网络结构，对该系统在某个部分出现故障的时段进行系统建模。

首先，做如下定义。用<high-CPU>表示主机的中央处理器(CPU)使用率过高这一运维事件，用<long-RT>表示服务响应时间过长。属性level(·)表示系统的层级，其中level(ps)表示节点为物理主机，level(vm)表示节点为虚拟机。属性type(·)表示服务层节点的类型，具体类型如图中所示有LVS，apache和mysql三种取值。其中LVS表示该节点为类型为LinuxVirtualServer的负载均衡服务器；apache表示该节点为Apache类型的网络服务器；mysql表示该节点为MySQL类型的数据库。

现在，考虑图3的运维系统所发生的故障情况。主机ps₅在100秒发生了CPU使用率过高的状况，继而影响到了vm₅和vm₈上服务的运行，使得二者所运行服务的响应时间增加，并且均在102秒产生了响应时间过长的事件。由于vm₄和vm₇分别调用vm₅和vm₈，二者随后分别在104和105秒产生了响应时间过长的事件。随后该故障继续传播，于107秒在vm₆、108秒在vm₁触发了响应时间过长的事件。由于除vm₅和vm₈以外的响应时间均由响应时间的传播性造成，除ps₅外，其他物理主机均无异常出现。各节点的异常状况均在持续20秒后结束。

对该系统在T＝[90,140]进行建模，该模型记为

下面我们详细定义

的各个部分。

N表示系统节点的集合。例子中的系统包含两类节点，分别是虚拟机和主机，其命名方式已在上文有所交代。因此定义N＝{vm₁，vm₂,…,vm₈，ps₁,…,ps₅,CS,CK,DS,AS,fw,rt₁,rt₂,rt₃}。

E表示系统节点到节点的关系。可以从图4中整理出各虚拟机之间的调用关系，并且由上文的阐述，虚拟机与主机之间的部署关系也已经明确。因此定义E₁＝{(vm₁，vm₄),(vm₄,vm₅),(vm₆,vm₇),(vm₇,vm₈),(vm₁,ps₁),(vm₁,ps₁),(vm₆,ps₁),(vm₂,ps₂),(vm₃,ps₃),(vm₄,ps₄),(vm₇,ps₄),(vm₅,ps₅),(vm₈,ps₅)}，其中(vm_i,vm_j)表示虚拟机vm_i“调用”虚拟机vm_j，(vm_i,ps_j)表示虚拟机vm_i“部署于”物理主机ps_j上。另外，从图4中整理出系统节点在通信网络中的分布情况。根据图4各节点间的连接关系，定义E₂＝{(CS,DS),(DS,rt₁),(DS,rt₂),(DS,rt₃),(rt₁,fw),(fw,ps₃),(fw,ps₅),(rt₂，AS),(AS,ps₂),(AS,ps₄),(rt₃,ps₁)}。综合上述讨论，我们有E＝E₁∪E₂。

L表示各节点上运维事件的标记函数。根据本节上文描述，构造L使得<high-CPU>∈L(ps₅,i)，i＝100,...,120和<long-RT>∈L(vm₅,i),i＝102,...,122等等，使得L足以描述上文描述的一系列运维事件。

C表示各节点的属性标记。根据本节上文的描述和定义，对于编号为i的物理主机，有C(psi)＝{level(ps)}；对于虚拟机，例如对于vm₁，有C(vm₁)＝{level(vm),type(LVS)}，而对于vm₅，我们有C(vm₅)＝{level(vm),type(mysql)}等等，来使得C能够精确表示图3.中系统各节点的属性。对于图4中网络层的节点x(x为CS，DS，AS，fw)，有C(x)＝{level(nd),type(x)}(nd表示网络设备)，而对于路由器rt_i，有C(rt_i)＝{level(nd)，type(Router)}。

在建立运维系统模型

之前，并未明确特定领域的运维属性集合A和运维事件集合Σ。这是因为本发明的是一个通用的建模方法，是对运维系统的高度抽象，现有的运维和运营系统均可以此方法为基础进行建模。这一点也可以从实施例中看出：在实施例中我们利用双标记迁移系统对系统的所有层次(业务流程、业务资源配置和网络结构)均进行了建模。

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

Claims (10)

1.一种运维系统的建模方法，其特征在于，所述方法包括：

步骤1，获取运维系统中的所有节点，构造所述运维系统的节点集合N；

步骤2，获取所述运维系统中的所有节点的类型属性，构造所述运维系统的节点的属性标记函数C；并且为所述所有节点配置全局唯一的id；

步骤3，获取所述运维系统中的所有节点之间的关联关系，构造所述运维系统的节点之间的关联关系集合E；

步骤4，获取所述运维系统中的所有节点在一预定时间段内的运维事件，构造所述运维系统的节点上的在一预定时间段内的运维事件标记函数L；

步骤5，将所述节点集合N、所述属性标记函数C、所述关联关系集合E、所述运维事件标记函数L作为所述运维系统的运维系统模型

其中，运维系统模型

表示为：

其中，所述步骤3中

E为系统有向边的集合，用于描述节点之间的关联关系，所述关联关系包括：运维系统的节点之间的从属关系、调用关系、部署关系、配置关系，所述运维事件标记函数L为L:N×T→2^∑，用以刻画系统在不同时刻所处的具体状态，T为一个有限的时间区间，系统节点属性标记函数C为C:N→2^A，用以刻画系统在任何时候都具有的特性，A为运维属性集合。

2.根据权利要求1所述的方法，其特征在于，所述步骤1包括：

从所述运维系统中的业务配置和网络拓扑中，抽取节点，根据抽取的所述节点构造节点集合N。

3.根据权利要求1所述的方法，其特征在于，

所述节点包括：业务系统、模块、服务器、中间件集群、中间件、服务器集群、虚拟机或物理主机中的一个或者多个。

4.根据权利要求1所述的方法，其特征在于，所述节点的类型属性包括：节点的系统层级、节点类型；

所述节点类型包括：业务系统、模块、服务器、中间件集群、中间件、服务器集群、虚拟机、物理主机或数据库。

5.根据权利要求1所述的方法，其特征在于，所述步骤3包括：

通过清洗所述运维系统中的业务流程和业务配置中节点的关联关系，获取所述运维系统中的节点之间的关联关系，将其加入E。

6.根据权利要求1所述的方法，其特征在于，所述步骤3包括：

通过所述运维系统的调用链数据中节点的关联关系，获取所述运维系统中的节点之间的关联关系，将其加入E。

7.根据权利要求1所述的方法，其特征在于，

属性函数C与事件函数L的区别在于，属性函数C不包含时间T，而事件函数L包含。

8.根据权利要求1所述的方法，其特征在于，所述步骤4包括：

从所述运维系统的日志数据中，提取发生异常事件的节点、异常事件及其异常事件的发生时间；

根据所述发生异常事件的节点、异常事件及其异常事件的发生时间，构造所述运维系统的节点上的运维事件标记函数L。

9.根据权利要求1所述的方法，其特征在于，所述步骤4包括：

从所述运维系统的指标数据中，提取指标数据发生异常的时间、指标数据发生异常对应的发生异常事件的节点、异常事件；

根据所述发生异常事件的节点、异常事件及其异常事件的发生时间，构造所述运维系统的节点上的运维事件标记函数L。

10.一种运维系统的建模装置，其特征在于，包括：

第一构造单元，获取运维系统中的所有节点，构造所述运维系统的节点集合N；

第二构造单元，获取所述运维系统中的所有节点的类型属性，构造所述运维系统的节点的属性标记函数C；并且为所述所有节点配置全局唯一的id；

第三构造单元，获取所述运维系统中的所有节点之间的关联关系，构造所述运维系统的节点之间的关联关系集合E；

第四构造单元，获取所述运维系统中的所有节点在一预定时间段内的运维事件，构造所述运维系统的节点上的在一预定时间段内的运维事件标记函数L；

建模单元，将所述节点集合N、所述属性标记函数C、所述关联关系集合E、所述运维事件标记函数L作为所述运维系统的运维系统模型

其中，运维系统模型

表示为：

其中，所述第三构造单元中

E为系统有向边的集合，用于描述节点之间的关联关系，所述关联关系包括：运维系统的节点之间的从属关系、调用关系、部署关系、配置关系，所述运维事件标记函数L为L:N×T→2^∑，用以刻画系统在不同时刻所处的具体状态，T为一个有限的时间区间，系统节点属性标记函数C为C:N→2^A，用以刻画系统在任何时候都具有的特性，A为运维属性集合。

Images