一种网络监控数据收集与分析系统及方法与流程

本发明涉及网络应用交付控制领域，特别涉及一种可编程的网络监控数据收集与分析系统及方法。

背景技术：

在过去较为简单的网络设备部署下，对设备或计算节点的监控往往采用简单的单一界面、人工观察、简单事件通知等方式。如今在大规模云计算部署条件下，这种监控数据处理的方式越来越无法满足用户，以下两点问题尤其突出：

a.多节点联合监控:同时监控多网络结点的健康状态及负载状况。

b.自动化智能监控:通过预定义的软件逻辑对监控对象的多种统计数据进行综合的实时分析，在发生异常时及时预警，或通过控制接口自动采取措施。

软件定义网络(Software Defined Network,SDN)是一种新型网络创新架构，它通过将网络设备控制面与数据面分离开，从而实现了网络流量的灵活控制与部署，为核心网络及应用的创新提供了良好的平台。软件定义一切(SDE)是近年来IT领域流行的一种思想，即由硬件提供基础设施，而由软件来灵活定义功能策略脚本－将策略脚本控制从计算/存储/网络流量中分离出来。目前，在网络领域优秀的SDN/SDE平台有：

Openflow(http://www.opennetworking.org)；

Openstack(http://www.openstack.org),

Opendaylight(http://opendaylight.org)等。

上述Openstack(美国国家航空航天局和Rackspace合作研发的云端运算软件)的子项目Telemetry(曾用名Ceilometer)提供了一种通用的收集整个虚拟化平台中各结点监控数据的方式，如图1所示，该项目让管理员可以通过统一 的接口监控整个云计算环境中所有子服务的状态，但是上述技术仍无法灵活地通过软件定制监控网络数据策略。上述相关技术资料可参考如下网站：

https://wiki.openstack.org/wiki/Ceilometer；

http://docs.openstack.org/developer/ceilometer/。

中国专利201010205472.X公开了一种“全程全网安全协同防御系统的协同防御方法”，它是对网络中多节点布控，统一分析管理节点设备，实现系统全局性协同防御。其具体步骤是：设置于计算机网络的网络节点外端口处的流量数据探测子系统，捕捉预进入节点内的流量数据，并将数据发送给协同防御设备；设置于计算机网络节点处的协同防御设备分析所采集数据流量并记录异常流量等安全事件，并对安全事件进行处理，将安全事件相关信息传送给安全分析控制中心；经分析控制中心进行统一分析后做出管理决策，查看各协同防御设备了解系统运行状况，然后更新各协同防御设备的协同防御策略脚本，对协同防御设备的各功能组件进行统一部署，并通过审核日记对安全事件进行源头控制，实现对网络安全事件的一体化协同安全防御。这种方法布局及监控过程复杂，用户也无法方便灵活地通过软件定制适合自身需求的监控数据策略脚本，从而优化网络管理，实现网络监控效率的最大化。

技术实现要素：

为克服已有技术中存在的问题，本发明的目的之一是提供一种简便易行的可编程的网络监控数据收集与分析系统,进一步地是提供一种可编程深度分析器，根据用户定制的策略脚本，对多节点监控数据进行实时分析、处理，从而大大提高网络管理的执行效率。

本发明的另一目的是提供一种可编程的网络监控数据收集与分析的方法，将监控数据本身与监控策略脚本相分离，使用软件灵活定义监控策略脚本，实现全程数据收集、实时分析、实时发现异常事件、实时通知管理员或直接采取行动。

鉴于上述目的，本发明将已有技术中SDN/SDE的思想应用到网络监控领域，将监控数据本身与监控策略相分离，使用软件灵活定义监控策略－，实现全程 数据收集、实时分析、实时发现异常事件、实时通知管理员或直接采取行动。

为此，本发明采取了如下的技术方案：

一种网络监控数据收集与分析系统，它是由基础设施层，可编程深入分析器以及接口层组成,其中所述的基础设施层，包括但不限于安全网关设备、网络数据流控方设备、应用虚拟化设备、负载均衡设备、WAN优化设备等各类网络安全及应用交付控制设备；所述的可编程深入分析器是由数据收集与预处理模块、数据仓库、以及策略引擎装置组成；所述的接口层，是由将本系统产生的数据和事件呈现出来或通知外部系统的模块组成。

所述的数据收集与预处理模块通过侦听插件或轮询插件分别与受监控设备连接。

所述的数据收集与预处理模块还可通过支持各种网络协议的插件并配合数据采集器代理与受监控设备连接。

所述的策略引擎模块是由策略管理模块、策略初始化模块、策略运行模块和计时器构成。

进一步地，所述的策略管理模块是根据用户需求定义的，用于查看、添加、删除、修改策略脚本。

所述的策略初始化模块用于注册事件处理函数。

所述的注册事件处理函数包括注册计时器事件处理函数。

所述的策略运行模块用于运行策略脚本，主要包括解析数据类型、调用事件函数解析数据、调用已注册事件处理函数并执行函数题直至触发新事件。

所述的触发新事件包括向受监控设备发出控制命令以及通知网络管理员。

本发明还提供了一种可编程的网络监控数据收集与分析的方法，包括以下步骤：

步骤1，根据用户需求，预定义网络监控数据策略脚本，同时设置策略脚本管理，使得用户可以通过一定的接口查看、添加、删除、修改策略脚本；

步骤2，初始化策略脚本，将用户定义的策略脚本由文件装载到内存中，特别是在运行时数据结构中注册事件处理函数；

步骤3，收集及预处理来自受监控设备的各种数据及各类事件，用以作为所述策略脚本的触发数据，同时储存到数据仓库以备查询及整合监控；

步骤4，策略运行，由运行时收集到的数据触发策略(事件处理函数)的执行，该步骤尤其包括解析数据类型、调用事件处理函数解析数据、调用已注册的事件处理函数并执行函数题直至触发新事件：向受监控设备发出控制命令以及通知网络管理员。

本发明提供了一种软件定义策略的方式，利用这些用户可定制的策略，对监控数据进行实时分析、处理，实现客户的灵活需求，从而大大提高网络管理的执行效率。本发明系统具有很强的可扩展性，通过开发插件，可以监控云计算网络中任何类型的数据源(受监控设备)的任何类型的数据、事件。特别适用当今大规模云计算网络环境。

附图说明

图1是已有技术系统结构示意图；

图2是本发明一种网络监控数据收集与分析系统结构示意图；

图3是本发明系统结构中一种数据收集及预处理模块对外连接结构实例的示意图；

图4是本发明系统中策略引擎模块结构示意图；

图5是本发明方法一种较佳实施例流程示意图；

图6是本发明方法中数据预处理后的数据结构示意图；

图7是本发明本发明方法中初始化策略脚本后策略脚本与事件名称、事件处理函数关系示意图；

图8是本发明策略引擎流程示意图；

图9是本发明系统第一较佳实施例系统结构示意图；

图10是本发明系统第二较佳实施例系统结构示意图；

图11是本发明系统第三较佳实施例系统结构示意图。

具体实施方式

在以下的叙述中，为了使读者更好地理解本申请而提出了许多技术细节。但是，本领域的普通技术人员可以理解，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也是本申请各项权利要求所要求保护的技术方案。

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明的实施方式作进一步地详细描述。

如图2所示，一种网络监控数据收集与分析系统，它是由基础设施层100，可编程深入分析器200以及接口层300组成,其中

所述的基础设施层，包括但不限于安全网关设备、网络数据流控方设备、应用虚拟化设备、负载均衡设备、WAN优化设备等各类网络安全及应用交付控制设备，所述的各类网络安全及应用交付控制设备即为本发明所指受监控 设备或称数据源，以下统称受监控设备。所述受监控设备一般情况下需要监控的数据，例如某虚拟服务的实时吞吐量、并发连接数等；受监控设备可能发生的各类事件，例如CPU过热、接口物理连接断开等。所述的基础设施层还包括接受来自上层的控制命令、执行配置更改或其他动作的装置等。

所述的可编程深入分析器，是由数据收集与预处理模块210、数据仓库220、以及策略引擎装置230组成。可编程深入分析器的输入端接收来自受监控设备的数据和事件，并储存到数据仓库以备查询和对历史数据的整合监控，所述数据和事件将作为策略引擎装置的触发数据；可编程深入分析器输出经过策略引擎装置分析后触发新事件数据，并发送控制命令给外部结点或网络管理员。

所述的接口层，是由将本系统产生的数据和事件呈现出来或通知外部系统的模块组成，包括但不限于报表生成器、Web图形界面、RESTful API服务器等。

进一步地，所述的数据收集与预处理模块负责数据与事件的采集和预处理，如图3所示的一种实施例，该模块通过一组插件、例如侦听插件221，222及轮询插件、例如轮询插件223，分别与受监控设备、例如受监控设备101、102、103连接，用于接收来自受监控设备及软件结点的数据或事件消息，或者定时向受控设备轮询信息；根据受监控结点的不同功能，数据收集及预处理模块可以支持多种网络协议，例如UDP/TCP/SNMP，XML-RPC,RESTful API等；所述受监控设备101,102,103均可直接向数据收集与预处理模块发送消息，数据收集与预处理模块可以通过不同的插件实现不同的协议，例如侦听插件221、222可以是通过简单网络管理协议插件(SNMP Listener Plugin)或用户数据报协议插件(UDP Listener Plugin)实现，这两种插件都是被动接收式的，轮询插件223可以通过REST Poller Plugin插件实现，该插件是主动轮询式的。

特殊地，为了适应更多的应用场景，对各种网络协议的支持可以插件的形式开发，并配合数据采集器代理(collector agent)进行更灵活的部署：再如图3所示，当受监控设备无法由简单的网络协议实现时，所述的数据收集与预处理模块还可以通过代理侦听插件224连接数据采集器代理225，此时需要一个特殊定制的代理软件(Collector Agent)和该结点的主体部分部署在同一个受监控设备上，例如受监控设备104，该代理通过定制的插件收集受监控设备104的数据或事件，并通过专有的协议将数据发送给数据收集与预处理模块。

进一步地，所述的数据仓库负责数据与事件的持久化存储，例如可选取开源的InfluxDB实现，它是一款使用Go语言开发的易于部署的时间序列数据库，具有类SQL的查询语句以及众多专为时间序列应用优化的功能。

进一步地，所述的策略引擎装置，是由根据用户需求定义的策略脚本和受监控设备数据二者逻辑运算后的结果驱动、对数据进行实时的计算和逻辑判断、触发新的事件或将计算后的数据写入数据仓库持久存储的装置。如图4所示，它是由策略管理模块231、策略初始化模块232、策略运行模块233和计时器234构成。

更进一步地，所述的策略管理模块是根据用户需求定义或编辑的，用于用户查看、添加、删除、修改策略脚本。

更进一步地，所述的策略初始化模块主要用于注册事件处理函数包括注册计时器事件处理函数；

更进一步地，所述的策略运行模块，用于运行策略脚本，主要包括解析数据类型、调用事件函数解析数据、调用已注册事件处理函数并执行函数题直至触发新事件，例如向受监控设备发出控制命令以及通知网络管理员；

所述的策略运行模块，还包括调用计时器处理函数解析数据、调用已注册计时器处理函数并执行函数题直至触发新事件，例如向受监控设备发出控制命令以及通知网络管理员。

图5所示，为本发明方法的一个较佳实施例，在该例中主要监控的数据为某服务的实时吞吐量(单位Kbps)，具体实现步骤为：

步骤1，根据用户需求，预定义网络监控数据策略脚本，例如预定义网络监控数据策略脚本是：

策略脚本A：当每分钟平均吞吐量即时增长速度超过1000Kbps时，触发新事件并通知管理员。如设置受监控设备数据信息触发策略脚本A启动处理程序，即设置每秒吞吐量的每条数据消息都会触发策略脚本A的处理，策略脚本A运行时缓存过去一分钟每秒的吞吐量，并计算过去一分钟的平均吞吐量，将每分钟的平均吞吐量写入数据仓库，计算每分钟吞吐量的变化，如果即时增长超过1000Kbps，触发释出新事件：即“每分钟平均吞吐量激增”这个新事件，该释出新事件引擎策略脚本A处理程序朝两个方向：一方面该事件将作为通知发送给网络管理员(例如通过Email,WebUI,RESTful API等方式)，另一方面该事件将作为输入供以下策略脚本D分析；

策略脚本B：当最近一小时的平均吞吐超过过去一周平均吞吐的200％以上，触发新事件并通知管理员。如设置由定时器(timer)触发策略脚本B启动处理程序，例如每小时一次从数据仓库读取过去一小时的吞吐量数据，并进行均值计算，将每小时的平均吞吐量存至数据仓库；

策略脚本C：当策略脚本A的情况下，如果同时满足最近1分钟HTTP连接的平均时延高于500ms(我们可以认为吞吐量的激增影响了整个系统的服务质量)，进一步触发新事件并通知管理员。可以设置由定时器(timer)触发策略脚本C启动处理程序，例如每小时一次从数据仓库读取过去一周的吞吐 量数据，计算均值后与过去一小时的吞吐量数据进行对比，当符合预警条件(小时平均比周平均高200％以上)时，触发新事件；策略脚本C启动处理程序可以是将上述新事件作为通知发送给网络管理员，或者同时发送一条控制命令给受监控设备，用以提高受监控设备本身的吞吐量限制配置；

策略脚本D：设置由每个连接的平均时延数据触发策略脚本D启动处理程序。如缓存过去一分钟的所有平均时延数据，并计算每分钟的时延，当该均值大于500ms时，查看最近1分钟是否触发了“每分钟平均吞吐量激增”事件(来自所述策略脚本A)，如果是，则触发释出新事件：即“该受监控设备网络服务遭遇疑似攻击”这个新事件，策略脚本D启动处理程序：该新事件将作为通知发送给网络管理员。

同时，进一步设置策略脚本管理，使得用户可以通过一定的接口查看、添加、删除、修改策略脚本。

所述的策略脚本可以是一个javascript程序文本片段，用户既可以导入现有的策略脚本文件，也可以在本系统提供的web界面中直接编辑策略脚本，下面给出两例是使用标准javascript语言编辑的策略脚本文件：

实例1：

实例2，以图5中的策略脚本A为例并使用标准javascript语言编辑的策略脚本文件：

步骤2，初始化策略脚本，将用户定义的策略脚本由文件装载到内存中，特别是在运行时数据结构中注册事件处理函数；例如上述步骤1中给出了使用标准javascript语言编辑的两例策略脚本，该两实例所述策略脚本文件初始化后的数据结构如图7所示，图7中Connection是一个javascript全局对象，保存了与Connection这个Model(模型)相关的信息，在这里，我们给它注册了两个“事件处理函数”，分别对应两个Event Name(事件名称)。

步骤3，收集及预处理来自受监控设备的各种数据及各类事件，用以作为所述策略脚本的触发数据，同时储存到数据仓库以备查询及整合监控。从受监控设备接收原始数据，例如每秒的吞吐量及每个连接的平均时延，原始数据可能是任何格式，预处理流程会将数据规范化为符合本系统规范的统一格式，根据应用的需求，处理之后的数据既可以直接写入数据仓库留待之后查询，也可以触发策略引擎装置中的各种策略脚本。数据收集与预处理模块收集数据的方式可以有两种，a.被动接收式：可配置为监听某个端口，接收来自受监控设备或软件结点的数据或事件消息，数据收集与预处理模块可支持多种网络协议：例如UDP/TCP/SNMP等；b.主动轮询式：数据收集与预处理模块主动定时向受监控设备轮询信息，根据受监控结点的不同功能，数据收集与预处理模块可以支持多种网络协议：例如SNMP,XML-RPC,RESTful API等。

为了适应更多的应用场景，对各网络协议的支持也可以采用插件的形式 开发，并且配合数据采集器代理(collector agent)进行更灵活的部署：如图3所示，受监控设备101、102、103均直接向数据收集及预处理模块发送消息，数据收集及预处理模块通过不同的插件实现不同的协议，例如，用于SNMP Listener Plugin协议的侦听插件101、102与用于UDP Listener Plugin协议的侦听插件103是被动接收式的，用于REST Poller Plugin协议的侦听插件103是主动轮询式的。又如受监控设备104的数据收集无法由简单的网络协议实现，而是需要一个特殊定制的代理软件(Collector Agent)和该结点的主体部分部署在同一个设备上，该代理通过定制的代理侦听插件收集受监控设备104的数据或事件，并通过专有的协议将数据发送给数据收集与预处理模块。

数据收集与预处理模块和数据采集器代理利用各种插件将各种来源的数据统一成标准的数据结构以实现数据的预处理，例如图6所示的数据结构是经过预处理后的标准数据结构。这是一种高度灵活的数据结构，只规定了两个32位的头部字段，其中Msg Type是技术实现内部保留字段，无确切涵义；Msg ID是开发者定义的“消息ID”，代表了一类具体的数据模型，例如上述例子中的应用交付控制器的实时吞吐量数据，所述ID决定了本发明系统后续的所有流程中怎样处理消息体中的数据，实际数据所在的body段是可变长度的，且因不同的应用(由Msg ID决定)可以有完全自定义的结构。

所述的触发策略引擎装置中的各种策略脚本，包括由计时器触发，由受监控设备数据触发，以及由来自其他策略的新事件触发。所述的策略脚本可以主动地查询数据仓库中的历史数据，也可以主动将数据写入数据仓库。

步骤4，策略运行，由运行时收集到的数据触发策略(事件处理函数)的执行，如图8所示，包括解析数据类型、调用事件处理函数解析数据、调用已注册的事件处理函数(包括调用已注册的计时器事件处理函数)并执行函数题直至触发新事件：向受监控设备发出控制命令以及通知网络管理员。

所述的解析数据类型，例如来自数据收集及预处理模块的标准化消息通 过头部字段“Msg ID”指明了该消息的数据类型，即首先根据Msg ID找到了系统中的数据模型及事件名称，如图7中的Connection与connection_info，这里的映射关系是由开发者预先定义的。

所述调用事件处理函数解析数据是针对不同的模型，系统进一步调用上述事件处理函数或计时器处理函数进行数据解析，数据解析的过程主要实现两个目标：第一是根据消息体中的一些索引字段，找到系统中的一个具体实例，如果未找到，则创建一个实例。例如图7中，当系统接收到connection_info消息时，自动创建一个新的实例并存储于内存中的一个哈希表中，使用该连接的源IP、目标IP、目标端口、创建时间等信息索引，这个实例在脚本中可使用this变量访问。当系统收到connection_throughput_out消息时，根据消息体中同样的上述信息可以查找到之前创建的实例；第二是将消息体中的各字段由网络数据解析为javascript变量，构成一个“事件对象”，该对象在策略脚本中可以使用变量e访问。

所述的调用已注册的事件处理函数(包括调用已注册的计时器事件处理函数)并执行函数题，是根据上述解析出的数据模型及事件名称，可以找到步骤2中注册的事件处理函数，并执行函数题。该函数的函数题中，可以访问上述解析数据中解析出的this变量及e变量。

所述的触发新事件，是事件处理函数中，在对各种数据进行逻辑分析和计算后，在满足一定条件的情况下，可以调用this.emit()函数触发新的事件，参数中指定了新事件的名称及数据。新事件将与当前事件共享一个this变量，表明这是同一个实例(例如例子中的同一个连接)释放的事件。进一步地，所述的策略脚本中还可以使用一些工具性的全局对象：例如Timer函数、DB函数等。Timer可以用于注册计时器事件处理，现给出以下两种计时器实例：

Timer.timeout(<time_in_milliseconds>,<handler_function>[,<instance>])；

Timer.interval(<time_in_milliseconds>,<handler_function>[,<instance>])；

其中timeout表示从现在开始固定一段时间之后执行某段函数；interval表示从现在开始每隔一段时间重复执行某段函数。两个函数的第一个参数均为时间间隔(单位毫秒)，第二个参数是待执行的函数体，第三个参数(可选)为执行处理函数时指定的this对象(事件对象)。

进一步地，在事件处理函数或计时器处理函数中，我们都可以进行数据仓库查询或插入新数据，通过全局接口DB进行，以下给出数据查询的一个例子：

由于InfluxDB提供了众多复杂而有用的查询接口，因此我们保留了在策略脚本中直接调用SQL语句的能力，数据的插入使用相对简单的insert函数进行，例如：

DB.insert(<series_name>,<data>)；

其中series_name是时间序列名称，data是数据体，data可以是一个javascript对象或对象的列表。

进一步地，所述的调用已注册的事件处理函数并执行函数题过程中，有能力对几分钟内的数据进行本地缓存(存储于策略引擎的内存中)，减少对数据仓库的依赖且实现更快速的数据访问。

进一步地，在策略释出新事件，进行后续处理时，发送事件通知以及发送控制命令都属于高度定制化的操作：针对不同的基础设施层设备以及不同的接口层模块可能有不同的处理方式。

进一步地，上述策略引擎(Policy Engine)步骤的实现采用了C语言以及一个开源的javascript引擎：SpiderMonkey。为了满足扩展性的需求，类似于data collector，这里同样采用了基于动态链接库(.so)的插件机制。一个插件可能实现了以下的一种或多种接口：

a.一个模型的数据解析函数(用于寻找/创建this变量及创建e变量)。

b.一个模型的内置javascript脚本(在初始化流程中先于所有用户自定义策略脚本执行)。

c.一些全局的工具对象定义与实现(类似于Timer/DB等工具对象)，通过C语言实现，通过javascript使用。

如图9所示，给出了本发明系统与Array APV设备一同部署的连接框图，部署及配置步骤简述如下：

a.开启APV中的数据采集器代理模块(已预先开发并安装)；

b.配置APV中的数据采集器代理模块连接至10.3.0.21:8090的可编程深度分析器(下简称PDA)；

c.配置PDA中的策略脚本，例如上述步骤1中的实例1和实例2；

d.配置PDA中的事件处理函数，添加管理员邮箱地址；

e.进一步配置APV使其处于恰当的工作模式，将APV部署至实际网络环境中。

工作过程中，如果APV中某个连接的out方向吞吐增速过快，管理员将收到报警邮件。

如图10所示，给出了本发明一种灵活记账的较佳实施例，用户利用本系统收集来自网络设备的每5分钟的虚拟服务数据吞吐量，并将数据转发给记账服务器。这里，“5分钟”这个数值可以在本系统中动态设置。同时，用户可自定义如下策略脚本：当某个虚拟服务的即时数据吞吐量持续10次达到预定义的2MB/s以上时，触发“吞吐量超限”事件，将该事件通知记账服务器后，后者可以发送邮件通知用户提高上限(付费)。

如图11所示，给出了本发明一种异常定位与自动故障恢复的较佳实施例，当最终用户的应用出现高延时等异常状况时，本系统可以结合网络各结点的监测信息做出智能的故障点定位。例如：通过某服务各连接的延时分布情况判断这是一个个例性的还是普遍性的问题；通过某虚拟服务与后台服务器的平均延时、以及前端交换机的统计数据做比对，确认延时主要发生在客户端与计算中心之间、还是发生在后台服务器。如果延时发生在后台服务器，确认相应服务器组负载过大，可以自动分别发出控制命令给ADC设备及虚拟机管理系统，分配新的后台服务器并添加至集群。

更多的应用还包括：系统容量动态调整、网络攻击监测与自动防御、服务等级协议(SLA)支持等等。

需要说明的是本发明所涉及的策略脚本与参数均可以通过用户自行开发的软件实现，本发明技术方案提供平台支持。

同时需要说明的是，本发明各设备实施方式中提到的各单元都是逻辑单元，在物理上，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现，这些逻辑单元本身的物理实现方式并不是最重要的，这些逻辑单元所实现的功能的组合才是解决本发明 所提出的技术问题的关键。此外，为了突出本发明的创新部分，本发明没有引入上述各设备实施方式以及与解决本发明所提出的技术问题关系不太密切的单元，但这并不表明不存在上述设备实施方式以及其它有关实施单元。

虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。