一种播发系统服务质量的监控方法及其系统与流程

本发明涉及数据保存和监控领域，特别涉及一种播发系统服务质量的监控方法及其系统。

背景技术：

播发系统是一套非常复杂的系统，它涉及到很多的观测节点和节点监控设备，包括接收机、算法、caster和终端。任何一次来自监控设备的差分纠偏数据都需要经过分布式的系统，而且每一次服务异常，需要从底向上对各个子系统进行遍历排查。目前针对播发系统服务质量的监控系统普遍存在下述缺陷：需要大量机器才能支持海量数据的收集、很难实现分析统计类的实时报警、报表查询率低以及无法有效支持高并发场景。因此需要提供一种方便实施、稳定运行、能够实时报警和具有灵活统计报表的播发系统服务质量的监控系统。

技术实现要素：

本发明的目的就是提供一种播发系统服务质量的监控方法及其系统，能够实现对复杂数据的分类和实时聚合，从而有效的提高了系统的运行速度，并且通过设置具备聚合类的监控报警规则可以适应于复杂场景下的数据查询和报警，例如出现系统异常时的用户影响度的报警等高并发场景；另外，由于采用了分布式实时计算框架，该监控方法及其系统可以支撑高数据量的收集和计算，从而具备了高效率的报表查询能力。

本发明提供了一种播发系统服务质量的监控方法，包括以下步骤：收集服务器获取来自业务线的状态变化数据，判断所获取的数据是否满足预先设定的条件；将满足条件的数据直接保存到数据库，将不满足条件的数据传送到集群服务器进行聚合计算，然后将聚合计算所得的数据保存到数据库；监控服务器获取数据库内保存的数据，根据所获取的数据匹配预先设定的报警规则；如果报警规则匹配成功，则监控服务器向报警服务器发送报警信息。

一实施例中，根据所获取的数据匹配预先设定的报警规则的步骤之后还包括以下步骤：如果报警规则匹配成功，则监控服务器向数据库发送表示更新报警状态的消息，数据库更新报警状态后向监控服务器回复表示更新成功的消息。

一实施例中，收集服务器采用分布式结构和缓存队列以从业务线收集日志和数据状态。

一实施例中，聚合计算的步骤包括以下子步骤：将网格异常信息发生的时间段保存到第一位集合中，变量为第一阈值；将单个用户行为的在线时间段保存到第二位集合中，变量为第二阈值；对第一和第二位集合进行位运算，得到单个用户影响度；对单个用户影响度进行再聚合，得到用户影响度；“如果报警规则匹配成功，则监控服务器向报警服务器发送报警信息”的步骤包括以下子步骤：若用户影响度超过预设门限，则监控服务器向报警服务器发送报警信息。其中，聚合计算是实时进行的。

一实施例中，监控服务器异步调用收集服务器获取的状态变化数据。

本发明还提供了一种播发系统服务质量的监控系统，包括以下模块：信息获取模块，包括收集服务器，用于获取来自业务线的状态变化数据，判断所获取的数据是否满足预先设定的条件；信息处理模块，包括集群服务器和数据库，用于将满足条件的数据直接保存到数据库，将不满足条件的数据传送到集群服务器进行聚合计算，然后将聚合计算所得的数据保存到数据库；信息查询模块，包括：监控服务器，用于获取数据库内保存的数据，根据所获取的数据匹配预先设定的报警规则；报警服务器，用于当所获取的数据与报警规则匹配成功时，监控服务器向报警服务器发送报警信息。

一实施例中，全部的模块均部署在局域网内。

一实施例中，集群服务器是jstorm集群。

一实施例中，业务线包括播发系统的播发节点和节点监控设备。

本发明实施方式与现有技术相比，主要区别及其效果在于：

1、采用了分布式框架大大节省了监控系统所需要的服务器数量，同时能够支持海量播发系统日志和状态的收集，节省了运行成本。

2、通过对海量数据进行分类聚合有效的提高了监控系统的分析效率，从而能够适用于高并发场景的需要，同时能够支持快速的实时统计分析。

3、报警规则复杂，可以更加全面的对播发系统的服务质量进行有效评估。

应理解，在本发明范围内中，本发明的上述各技术特征和在下文(如实施例)中具体描述的各技术特征之间都可以互相组合，从而构成新的或优选的技术方案。限于篇幅，在此不再一一累述。

附图说明

图1是本发明第一实施方式中的监控方法的流程图。

图2是本发明第二实施方式中的监控系统的结构图。

图3是本发明第二实施方式的一个实施例的系统结构图。

具体实施方式

目前对于播发系统的监控所采用的系统通常需要大量的服务器去支持海量数据收集，同时很难具备分析统计类的实时报警，即对实时的数据进行处理后立即发出系统异常警报，并且报表的查询性能较低，不能有效适应于高并发的场景。本发明提供了一种播发系统服务质量的监控方法及其系统，能够对收集到的海量数据进行实时聚合计算分析，从而有效调高了特定时间内的数据处理量，同时包括了高并发场景下的报警规则，进而实现对播发系统的服务质量的全面评估。

术语

如本文所用，术语“接收机”是接收卫星数据的程序。

如本文所用，术语“算法”是根据卫星数据以及专业算法进行差分纠偏数据计算的程序。

如本文所用，术语“caster”是基于ntrip协议提供播发服务的节点。

如本文所用，术语“castermonitor”是对caster的状态进行监控的模拟终端。

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

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

本发明第一实施方式涉及一种播发系统服务质量的监控方法，图1显示了该第一实施方式的监控方法流程图。如图1所示，该方法包括以下步骤：

步骤100：收集服务器获取业务线上的表示状态的数据，比如，当前在线用户数、系统服务时长和/或一周内活跃用户数等，该业务线包括参与播发的各个应用系统，例如caster和castermonitor，由于castermonitor的监控数据会包含较复杂的用户行为和用户状态，例如播发系统异常时对用户所造成的影响，因此在步骤101中，收集服务器在获取到业务线的状态数据后，会判断该数据是否满足预先设定的条件，例如分类数据和数值数据的区别，和/或用户要求查询的数据类型。在一个实施例中，收集服务器使用分布式服务框架，例如dubbo，去收集多方面的用户日志和状态数据，dubbo服务框架中还设置了缓存队列，当出现系统异常时，例如数据格式和/或内容错误、数据冗余或不足，可以达到“消峰”的目的，这里的“峰”是监控系统异常时出现的高峰压力，代表了数据异常的程度。

步骤102：收集服务器会将满足预设条件的状态数据直接保存到数据库，在一个实施例中，这里的数据库可以采用阿里云odps和/或mongo以实现大数据计算服务。应注意，收集服务器从业务线获取数据与将满足条件的状态数据直接保存到数据库是同步的，为了避免数据出错和传输过程中的干扰。

步骤103：不满足预设条件的数据会被收集服务器传送到集群服务器，用于进行聚合分析(如步骤104所示)。在一个实施例中，jstorm作为集群服务器可以支持大量的位运算，从而在海量数据运算场景下减少系统内存的使用和保证运算的高效性能，例如对于用户影响度这个监控指标而言，步骤104如下：当castermonitor上报了某一时间段网格异常信息后(比如网格grid1在10点-10点10分这一时间段发生异常)，caster会将用户行为(比如晚上8点-9点这一个小时内用户在grid0网格，而10点-11点在grid1网格)上报到收集服务器；jstorm的bolt(计算单元)将grid1的异常时间段保存到一个长度为86400的bitset中，变量设为bsgrid1；jstorm的bolt将用户1的在线时间段保存到一个长度为86400的bitset中，变量设为bsuser；对变量bsgrid1和变量bsuser1进行与运算，得到该bolt中的用户1的用户影响度；若存在用户2、3、4…n，则重复上述步骤得到多个bolt的用户影响度并对其进行再聚合，从而得到该监控系统的全用户影响度。

注意到，集群服务器所包括的聚合计算还包括但不限于：对30000个网格的实时状态进行聚合；对全部用户的在线信息进行实时聚合；对在线用户数进行聚合、去重计算并产生基数，从而产生基线(作为下文报警规则的匹配标准)；对在线用户信息和用户所在位置的播发服务器状态进行实时聚合。对于不同的监控指标，所使用的聚合计算方法各不相同，本领域的技术人员可以按照实际情况自己设置聚合公式。然后在步骤105：集群服务器会将聚合计算所得的聚合结果直接保存到数据库。

步骤106：监控服务器获取数据库里所保存的状态数据。在一个实施例中，monitorserver(监控服务器)采用dubbo分布式服务框架。

步骤107：监控服务器内设置有聚合类的报警规则，并根据所获取的状态数据匹配预先设定的报警规则。在一个实施例中，状态数据所包含的监控指标可以是监控实时在线人数、近7天活跃用户数以及用户影响度等。报警规则可以包括但不限于：判断聚合结果是否为全网可用率降低到，其中，全网可用率＝播发系统发生异常的持续时间/网格数*播发系统服务持续时间；判断实时在线用户数是否同比降低达到第一预设阈值或者环比降低达到第二预设阈值；判断近7天活跃用户数是否偏离基线达到预定数值，其中，活跃用户可以认为是每天至少登录一次的用户；以及，判断播发系统发生异常时的用户影响度是否超过预定数值，其中，当在线用户所在网格的服务发生异常时，则认为该在线用户受到影响，因此存在用户影响度在播发系统受影响时间段内随着时间的增加而增加的情况，而且用户影响度可以是异常网格所影响到的用户服务不可用时长/所有在线用户调用服务总时长。

步骤108：如果报警规则匹配成功，则监控服务器向数据库发送表示更新报警状态的消息。

步骤109：数据库更新报警状态后向监控服务器回复表示更新成功的消息。

步骤110：如果监控服务器内所获取的数据与报警规则匹配成功，则向报警服务器器发送报警信息。例如，“报警规则被匹配成功”可以是但不限于：全网可用率低于99％，触发报警；实时在线用户数同比降低10％或环比降低20％，触发报表；近7天活跃用户数偏离基线15％，触发报警；播发系统服务存在异常时，用户影响度超过5％，触发报警。通过匹配不同的报警规则，能够有效监控播发系统的服务质量，实现实时报警功能，并且所采用的分布式框架能够支持多维度报表存储和、分析和查询。

步骤111：监控服务器调用收集服务器所获取的状态变化数据，该过程与上述聚合分析的过程是异步的，确保海量状态数据能快速上传到监控服务器并且不阻塞收集服务器的收集工作。

应注意，步骤102和步骤103-105没有先后顺序，而且步骤111独立于步骤101-110，即不存在先后顺序。

本发明的各方法实施方式均可以以软件、硬件、固件等方式实现。不管本发明是以软件、硬件、还是固件方式实现，指令代码都可以存储在任何类型的计算机可访问的存储器中(例如永久的或者可修改的，易失性的或者非易失性的，固态的或者非固态的，固定的或者可更换的介质等等)。同样，存储器可以例如是可编程阵列逻辑(programmablearraylogic，简称“pal”)、随机存取存储器(randomaccessmemory，简称“ram”)、可编程只读存储器(programmablereadonlymemory，简称“prom”)、只读存储器(read-onlymemory，简称“rom”)、电可擦除可编程只读存储器(electricallyerasableprogrammablerom，简称“eeprom”)、磁盘、光盘、数字通用光盘(digitalversatiledisc，简称“dvd”)等等。

本发明第二实施方式涉及一种播发系统服务质量的监控系统，图2是本实施方式的系统200结构图，该系统包括以下模块：

信息获取模块，包括收集服务器，用于获取来自业务线的状态变化数据，判断所获取的数据是否满足预先设定的条件；

信息处理模块，包括集群服务器和数据库，用于将满足所述条件的数据直接保存到数据库，将不满足所述条件的数据传送到所述集群服务器进行聚合计算，然后将聚合计算所得的数据保存到所述数据库；

信息查询和报警模块，包括：

监控服务器，用于获取所述数据库内保存的数据，根据所获取的数据匹配预先设定的报警规则；

报警服务器，用于当所获取的数据与所述报警规则匹配成功时，所述监控服务器向所述报警服务器发送报警信息。

图3是该第二实施方式的一个实施例的系统300结构图，该系统300包括：业务线(播发节点caster和节点监控设备castermonitor)，收集服务器(collectsever)，集群服务器(jstorm)，数据库(odps和mongo)，监控服务器(monitorsever),报表服务器(reportsever)，报警服务器(alarmsever)，接收机，算法和分布式服务框架(zookeeperdubbo)。

具体地说，业务线具有播发系统的实时监控状态，播发系统的服务由caster集群完成，每个caster节点代表一个需要播发服务的区域并细分出网格以进行播发服务。注意到caster和castermonitor是一一对应的，定时对caster的相应区域的每个网格单位进行ntrip差分请求，如果得到差分纠偏数据，则标识为可用状态，否则标识为状态。

收集服务器(collectsever)收集业务线上的日志以及状态，为保证播发系统服务质量的高可用性，因此需要收集海量的数据。除了使用分布式服务框架，收集服务器还增加了缓存队列以消除异常出现时监控系统的高峰压力，实现“消峰”。另外，collectsever将不需要聚合的数据直接存储到数据库。

集群服务器(jstorm)对日志和状态进行实时聚合的分析，并将聚合的结果上传到数据库进行储存。

数据库也采用分布式框架，odps类似hadoop集群服务器，可以进行离线计算和数据储存，离线计算的结果被直接储存到mongo，在需要查询报表时，该监控系统可以直接读取mongo内的数据进行报表展示。注意到，odps虽然也是集群服务器，但是在本发明中主要进行离线计算分析和数据存储，与jstorm的实时聚合分析功能不相同。

监控服务器(monitorsever)具有多种报警规则、多种报警间隔、多种报警方式、以及多种报警人群的设置，满足对播发服务质量的多维度监控。而且，monitorsever获取数据库的状态数据后，对其进行报警规则的匹配，这里monitorsever的核心逻辑应当是高度抽象的。

报表服务器(reportsever)不需要odps去计算数据，而是直接从mongo中读取数据，而且根据报表逻辑增加相应的mongo索引，可以极大地提高展示效率。

另外，第一实施方式是与本实施方式相对应的方法实施方式，本实施方式可与第一的实施方式互相配合实施。第一的实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一的实施方式中。

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

需要说明的是，在本专利的权利要求和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

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