一种面向信息系统多源目标的状态监测方法及系统架构

技术领域

本申请涉及面向网站、主机以及应用服务等不同目标的状态监测技术，更具体的，涉及一种面向信息系统多源目标的状态监测方法及系统架构。

背景技术

信息系统是企业、机构等内部运行的关键基础设施，对于提高生产效率和生产力、加强沟通与协作、数据管理与安全等具有不可或缺的重要作用。信息系统中诸如网站、主机和应用服务等各个组成部分如果在实际运营过程中因故障而产生异常，无法正常提供服务，将严重损害自身形象，因此如何及时获知上述多种目标的运行状态，及时发现异常并尽快采取应对措施成为一个非常关键的问题。对于主机是否在线、网站是否稳定运行、应用服务是否在持续提供服务等等都需要得到监管，以便于在其状态发生异常时能够及时感知从而尽快采取措施。

尤其网站是企业、机构或者个人等不同主体更好的向公众展示自身实力和品牌，及时获取用户反馈以及扩展业务的重要平台。而如果黑客入侵者对其网站进行挂马，篡改网站源代码，被窃取数据等危害网站安全的行为，不仅影响网站的正常运营和用户体验，也关系到网站的信誉和利益，甚至可能涉及国家安全和社会稳定。因此确保网站的安全运行，防范受到网络入侵成为一个非常关键的问题。网站作为众多黑客的目标，围绕网站以及其所在的主机和网络链路等相关目标产生了多种多样的攻击与嗅探手段，例如针对网站所在主机的系统漏洞、后门、病毒等、针对网站本身的恶意扫描和SQL注入等，针对网络链路而采取的网络访问分析、网络劫持分析、DDOS攻击等，各种手段与途径形形色色，各有特点，都对网站能否正常运行产生了重要影响。针对上述这些方法也随之产生了各种应对之法。但是网站受到黑客入侵或者攻击，最明显的异常就是无法访问或者访问延迟太大。因此非常有必要对网站的运行状态进行监测，从而在异常发生时能尽快获知并做出应对措施。

类似的，主机是否在线正常运行，应用服务是否持续稳定提供服务也严重影响到相关业务的开展，进而对整个信息系统产生重大影响。

而对监测目标的状态展开监测并进行异常告警，对于管理者提出了较高的技术要求，不仅需要了解掌握如何部署探针软件，如何部署采集软件，更需要在获取数据之后进行综合分析，判断何种条件下为异常或故障，以及什么条件触发异常告警。而且对于某个网站等单一目标部署这样一套系统，会消耗一定的硬件资源。因此从技术角度、经济成本角度都迫切希望能够有一套能够面向多源监测目标状态进行监测的方法与系统架构，帮助网站管理者解决这个痛点问题，使得能够从繁杂的状态监测和数据分析工作中脱离出来，将注意力集中于主营业务开展和内容维护本身。

发明内容

本发明的目的在于，对网站、主机以及应用服务等不同目标的状态进行监测，从而在异常发生时能尽快获知并做出应对措施。

为实现上述目的，一方面，本发明提供了一种面向信息系统多源目标的状态监测系统架构，该系统架构包括：

多个监测节点，获取被监测目标的运行状态数据；监测节点依据所需监测目标的数量以及占用资源情况决定部署一台或多台监测主机；每台监测主机主要设置有采集软件、探针软件和任务管理组件，监测主机通过探针软件获取被监测目标的运行状态数据，并通过采集软件进行采集，提交至上一层的智能运管中心的数据汇聚模块，并且在本地实现缓存；任务管理组件负责获取和整理所在主机的被监测目标并生成新的配置文件以启用；以及，

智能运管中心，包括负载均衡模块、数据管理与展示模块以及数据存储集群；其中，负载均衡模块，设置为第一负载均衡模块和第二负载均衡模块；数据存储集群主要完成监测数据的存储；数据管理与展示模块，包括任务分发管理模块、数据分析模块和异常告警模块，用于负责与监测节点进行交互，接收汇聚底层采集软件提交的数据，以及提交至数据存储集群以实现数据的存储，以及与用户进行交互并提供可视化展示及异常告警服务功能。

另一方面，本发明公开了一种面向信息系统多源目标的状态监测方法，该方法包括以下步骤：

通过智能运管中心提供的相关用户界面，输入需要监测运行状态的被监测目标信息，并将被监测目标信息存入用户待监测网站信息表中；

各个监测节点周期性与智能运管中心的任务分发管理模块进行交互，如果用户修改了需求导致用户待监测网站信息表的数据产生变化，那么将导致重新生成配置文件；

监测节点通过探针软件获取被监测目标的运行状态数据，然后由采集软件进行采集并提交至智能运管中心的数据汇聚模块；

智能运管中心的数据汇聚模块通过指定端口号持续接收各个被监测目标发来的运行状态数据，并存储至数据存储集群中；

智能运管中心的数据分析模块通过提取被监测目标的状态数据并展开分析处理，从中发现异常情况并记录至异常信息表中；异常告警模块则周期性查询异常信息表，如果有新的异常并经判断应该发送则发送该异常告警。

本发明通过部署一个或多个监测节点实现对指定目标运行状态的监测，并在汇聚该数据的基础上开展综合分析，及时发现其中异常，及时告知管理员采取应对措施。其优势在于彻底解放管理员，无需管理员具备较高的软件部署能力和系统研发能力，只需提供需要监测的网站网址、主机地址或者应用服务地址与端口等关键信息即可及时获知运行状态。

附图说明

图1为本发明实施例中提供的一种面向信息系统多源目标的状态监测系统架构图；

图2为本发明实施例中提供的一种面向信息系统多源目标的状态监测方法流程示意图；

图3为本发明实施例中提供的用户需求更新配置流程示意图；

图4为本发明实施例中提供的网站运行状态异常检测算法示意图；

图5为本发明实施例中提供的网站运行状态异常告警流程示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

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

图1为本发明实施例提供的一种面向信息系统多源目标的状态监测系统架构图。如图1所示，该系统架构主要分为两类节点，即检测节点和智能运营管理中心。其中监测节点主要用于采集网站运行状态并发送至智能运管中心，承担的是最基础也是最重要的数据采集功能。根据监测任务量的不同，监测节点可以由一台或者多监测主机(监测主机1、……、监测主机M)组成，而且支持动态调整主机。而智能运管中心则相当于整个多源目标状态监测系统的核心，不仅承担数据汇聚、持久化存储以及查询等功能，更重要的开展数据分析进行异常监测并进行告警通知。

具体地，该系统架构可分为三层：第一层是被监测目标，包括但不限于网站、主机和应用服务等不同类型。具体被监测目标可以由用户通过交互界面直接提交，即支持用户定制。第二层是监测节点层，主要负责获知网站运行状态数据并提交至智能运管中心。其功能模块包括：

任务管理：用于和智能运管中心的任务分发管理模块交互，获取该监测主机的任务内容。

探针软件：用于获知目标运行状态，并将相关数据以一定形式(例如网页方式)予以呈现。针对不同类型的目标，采用的探测方式各有不同，例如网站监测是基于主动访问并根据反馈进行状态判定；主机监测则是基于ICMP协议进行主动嗅探；对于应用服务端口则主动ping从而监测其可访问性。

采集软件：周期性访问探针软件的数据界面，采集运行状态数据，并提交至智能运管中心。

第三层是智能运管中心，主要负责接收被监测目标的运行状态数据，经过分析发现异常及时进行异常告警，其功能模块包括：

负载均衡模块，设置为主负载均衡模块和备用负载均衡模块；

任务分发管理：用户更新网站监测需求或者监测主机数量、闲置计算资源等发生变化的情况下，将触发本模块进行任务重新分配。监测节点内部各主机分别与本模块进行交互，可以感知用户监测目标是否有所更新，如果更新则通过本API获取新的监测目标列表。

数据汇聚：接收由监测节点发送的目标运行状态数据，并加以整合汇聚，持久化存放至对象存储系统中。

数据查询：对目标运行状态数据进行封装，提供数据查询服务。涵盖的数据包括两部分，一部分是：对象存储系统中存放的目标运行状态数据，另外一部分是仍然缓存在监测节点没有来得及提交至智能运管中心的目标运行状态数据。

数据分析：通过数据查询接口提取近期的目标运行状态数据，并运用相关算法展开分析，找到其中潜在的异常信息，包括但不限于网站不可达、网站访问时延太长、主机异常离线、应用服务不可访问等情况。

异常告警：依据数据分析之后获得的异常情况，结合发生频次与间隔等相关要素，优先依据用户自定义策略决定是否发送异常告警至管理员，如若用户没有制定自定义告警策略则使用系统默认策略。

端口转发与控制：由于监测节点所处的网络环境可能各有不同。而因为数据查询必须要访问到最新的目标运行状态数据，因此必须要访问到监测节点内的缓存数据中。如果监测节点内各主机有公网地址那么可以直接访问，但是如果没有公网地址，那么就无法让互联网中的智能运管中心数据查询模块直接访问。这种情况下就需要借助端口转发与控制模块解决数据查询模块与缓存数据之间的访问互通问题。

图2为本发明实施例中提供的一种面向信息系统多源目标的状态监测方法流程示意图。以网站运行状态监测为例，其他类型目标的状态监测与此类似。如图2所示，主要分为如下步骤：

S101：用户更新需求：用户更新(包括新增、删除或修改等)需要监测的待监测目标地址，相关信息保存至数据库中。监测节点自动发现用户新提交了监测需求或者任务分配有新调整，则主动获取新任务列表并自动更新相关配置文件，使之及时生效。

具体的，在智能运管中心提供相关用户界面，使得用户可以通过该界面输入需要监测运行状态的网站网址，用户提交至后台之后，将相关信息存入用户待监测网站信息表中，如表1所示。该表包括用户ID，用于区别不同用户输入的信息记录；网址则表示待监测的网址列表；网址Hash值则是对网址进行哈希计算得到，作用在于支持用户快捷查询，从安全角度加强安全性的同时解决网址重复的相关问题。

表1用户待监测网站信息表

优选地，每个监测主机的监测任务更新步骤，包括：

用户在前端界面按照提示进行新增、删除或者修改会触发任务更新；

监测主机周期性的主动将资源利用率提交至智能运管中心的任务分配管理模块，而智能运管中心的任务分配管理模块在针对每个监测节点内部各个监测主机的资源利用数据，自定义均衡算法autoBalance合理减轻高负载主机的任务量，适当增加低负载主机的任务量，从而实现动态调整每个监测主机的任务列表。

详细而言，资源均衡调度算法autoBalances收集各监测主机主动发送来的关键信息，包括但不限于：监测节点ID(用于标明该主机属于哪个监测节点)、CPU利用率、内存利用率、硬盘利用率以及带宽利用率。在整个监测节点启动之初，将整个监测任务列表按照监测主机的数量进行均分，例如有1000个监测任务，该监测节点内部有4台监测主机，则每台监测主机分得250个监测任务。随后依据所获取的各监测主机资源利用率情况，利用如下公式计算得出该主机总体资源利用率：

总体资源利用率＝a*CPU利用率+b*内存利用率+c*硬盘利用率+d*带宽利用率

其中上述公式中的a,b,c,d为系数，例如系数a的取值方法为：CPU利用率低于10％则a＝1；CPU利用率介于10％和30％之间则a＝3；CPU利用率介于30％至70％之间则a＝4；CPU利用率大于80％则a＝10。

其他系数b,c,d与此类似，也可以依据该资源的重要性进行适当调整，例如硬盘利用率的重要性相对较低，因此可以将其系数c取值适当调低。

上述总体资源利用率的目的在于科学衡量每个主机的资源利用情况，合理利用各主机的资源情况。如果一定时间周期内没有接收到某监测主机的发送信息，则判定为该主机离线，将其任务均分给剩余的存活主机。如果总体资源利用率超过8(以四个要素利用率均达到50％为例计算得到)，则将该主机上的任务适当减少，将删减下来的任务分配给总体资源利用率最低的主机。如果所有主机的总体资源利用率均超过8，则反馈给管理员，建议考虑增加新的监测主机。

S102:监测节点周期性与智能运管中心的任务分发管理模块进行交互，如果用户修改了需求导致表1的数据产生变化，那么将导致重新生成配置文件。该详细过程将在图3中详细介绍。

S103:监测节点通过探针软件获取网站运行状态数据，然后由采集软件进行采集并提交至智能运管中心的数据汇聚模块。

优选地，采集目标运行状态数据并提交步骤，包括：

监测节点部署的探针软件利用最新配置文件获知目标运行状态，包括但不限于网站访问状态码、网站访问时延数据、主机在线状态、应用服务可访问性等，将这些数据以网页形式予以呈现，每次访问均可获取到当前最新数据。

而采集软件则利用最新配置文件，按照指定的频率周期性的读取探针软件所呈现的网页，从而获得目标运行状态数据，并提交至智能运管中心的数据汇聚模块。S104:智能运管中心的数据汇聚模块通过指定端口号持续接收各个监测节点发来的网站运行状态数据后，将数据进行整合，并持久化存储至对象存储系统中。

优选地，接收数据并整合、存储步骤，包括：

位于智能运管中心的数据汇聚模块持续监听指定端口，在收到来自监测节点的目标运行状态数据之后，利用多标签技术进行整合，并通过对象存储系统接口写入指定的对象存储桶中予以持久化保存。多标签技术即指针对不同的目标类型，不同个体等将运行状态数据打上多个标签。标签名称可以自定义，标签值也可以自定义。例如增加一个type标签，用于区分目标类型(具体字段可以自行定义，例如网站运行状态定义为web，主机在线存活状态则定义为host，而应用服务存活状态则定义为service)。再例如可以增加一个target标签，其值用足以表明该个体的字符串代替，例如IP+端口等信息。通过多标签技术，不仅可以将存储对象系统中的众多运维数据进行有效区分，更重要的是为后续查询提供便利：支持通过查询标签值的方式对运维数据进行快速筛选和过滤，从而快速找到用户所查询检索的运维数据。

S105:智能运管中心的数据分析模块通过提取网站运行状态数据并展开分析处理，从中发现异常情况并记录至异常信息表中，该详细过程在图4中详细介绍。而异常告警模块则周期性查询异常信息表，如果有新的异常并经判断应该发送则发送该异常告警，该详细过程在图5中详细介绍。

通过以上介绍可以看出，S101、S104和S105是在智能运管中心执行，而S102和S103则是在监测节点执行，两者通过指定接口实现交互。

图3为本发明实施例中提供的用户需求更新配置流程示意图，以网站运行状态监测为例，其他类型目标的状态监测与此类似。如图3所示，其中任务分发管理模块是位于智能运管中心的关键模块之一，其他模块则都位于监测节点中。用户通过前端界面按照提示新增、删除或者修改待监测的目标地址，提交至数据库中予以保存，同时触发用户需求配置版本值更新。

具体步骤如下：

首先与任务分发管理模块进行交互，获取用户待监测网站信息表的当前版本；

将该版本与本地缓存的最新版本进行对比，看是否版本一致。

如果一致则说明用户待监测网站信息表没有变化，无需更新配置，终止即可。

如果两个版本不一致则说明用户待监测网站信息表有变化，那么需要重新与任务分发管理模块进行交互，获取当前最新的网址列表完整数据；

将该网址列表数据更新至探针软件的配置文件中；

最后调用探针软件接口实现配置文件的自动重新加载并生效。

图4为本发明实施例中提供的网站运行状态异常检测算法示意图，其他类型目标的状态监测与此类似。如图4所示，此过程完全在智能运管中心执行，与监测节点无直接关系。需要用到网站异常信息表，具体结构示例如表2所示：

表2网站异常信息表

具体算法步骤如下：

首先通过数据查询接口获取某网址的访问状态码；

判断该状态码是否等于200；

如果不相等则说明此次访问异常，直接写入异常信息表；

如果相等则说明此次访问正常，再通过数据查询接口获取此处访问的时延数据；

判断访问网站的时延数据是否超过指定值，如果是则表示访问网站耗时太久，写入异常信息表，如果否则表示此次访问探测完全正常，循环对下一个网址进行分析判断即可。

图5为本发明实施例中提供的网站运行状态异常告警流程示意图，其他类型监测与此类似。如图5所示，此过程完全在智能运管中心执行，与监测节点无直接关系。需要用到告警信息表，表结构如表3所示：

表3告警信息表

具体算法步骤如下：

首先判断指定时间内目标状态异常次数是否超过指定值(即alertNum，支持用户自定义调整该数值)，如果超过则提交一条异常数据到异常信息表；

读取异常信息表，查询是否有新的异常信息；

如果没有新的异常信息则直接终止退出即可；

如果有新的异常信息，则查询告警信息表是否已经存在该条记录。

不存在该条记录则表示该异常还没有发送过告警，这种情况下应该发送告警信息：首先写入告警信息表，然后从用户待监测网站信息表获取相关用户并发送告警通知。

如果存在该条记录则表示该异常此前已经发送过告警，这种情况下需要再判断此前发送的该条告警是否超过了alertTime小时(默认为12小时，支持用户自定义调整该数值)，如果没超过则无需发送告警，直接终止退出即可。如果已经超过alertTime小时则需再次告警：首先写入告警信息表，然后从用户待监测网站信息表获取相关用户并发送告警通知。

在一个实施例中，智能运管中心的数据分析模块通过数据查询接口获取近期的目标运行状态数据，然后利用相关分析算法，判断目标的状态是否正常。例如：网站访问状态码是否为200，否则判定为此次访问不可达，标注为网站异常。如果网站访问状态码为200，表明此次访问可达，然后读取网址访问时延(包括resolve、connect、TLS、processing、transfer等不同阶段的时延)，通过算法分析该时延是否超长，如果超过预期值则标注为网站异常，否则判定为对该网站的运行状态分析此次为正常。类似的，主机和应用服务的状态码正常为1，否则为0，对其异常状态判定步骤相同。如果数据分析模块发现目标状态异常，则会存放至异常数据表中，异常告警模块周期性读取该数据表，如果发现新的异常告警，则首先判断是否应该发送告警信息给管理员。具体判断算法如下：

首先判断该告警在指定时间内发生的次数是否超过指定值(命名为alertNum)，如果没有超过则终止发送告警。如果超过指定值，则需要读取异常告警发送信息表，判断该告警是否已经发送过，如果没有发送则发送告警，并将此次告警存放至异常告警发送信息表。如果此前已经发送过该告警，但是该告警的发送时间已经超过指定值(命名为alertTime，取值例如12小时)，则应该发送该告警，并将此次告警存放至异常告警发送信息表。支持用户通过交互界面设定alertNum和alertTime两个值进行个性化定制。若无则采用默认值。

本发明实施例通过部署一个或多个监测节点实现对指定目标运行状态的监测，并在汇聚该数据的基础上开展综合分析，及时发现其中异常，及时告知管理员采取应对措施。其优势在于彻底解放管理员，无需管理员具备较高的软件部署能力和系统研发能力，只需提供需要监测的网站网址、主机地址或者应用服务地址与端口等关键信息即可及时获知运行状态。

显而易见，在不偏离本发明的真实精神和范围的前提下，在此描述的本发明可以有许多变化。因此，所有对于本领域技术人员来说显而易见的改变，都应包括在本权利要求书所涵盖的范围之内。本发明所要求保护的范围仅由所述的权利要求书进行限定。