数据监控方法、装置、计算机设备及存储介质与流程

本申请涉及计算机技术领域，尤其涉及一种数据监控方法、装置、计算机设备及存储介质。

背景技术：

目前，在各行各业均需要统计相应的业务数据，比如金融和保险行业，需要统计某个产品或某个团队的销售数据，用该销售数据去分析管理，该业务数据统计即是业务量统计。然而，现在的业务量统计多采用手工脚本对业务数据进行采集，同时将采集的业务数据通过图形化的显示，无法做到真正对业务量突增或突减的预警，以及快速准确地分析出业务量突增突减的原因。

技术实现要素：

本申请提供了一种数据监控方法、装置、计算机设备及存储介质，旨在提供一种准确及时的业务数据异常统计分析方法。

第一方面，本申请提供了一种数据监控方法，其包括：

获取预设业务对应的多个业务管理系统的业务数据；

获取所述预设业务对应的业务流程关系，其中所述业务流程关系为多个所述业务管理系统的上下游关联关系；

根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常；

若所述业务管理系统的业务数据出现异常，获取与出现异常的业务管理系统相关的监控信息；

根据所述监控信息确定业务数据的异常原因。

第二方面，本申请提供了一种数据监控装置，其包括：

数据获取单元，用于获取预设业务对应的多个业务管理系统的业务数据；

关系获取单元，用于获取所述预设业务对应的业务流程关系，其中所述业务流程关系为多个所述业务管理系统的上下游关联关系；

异常监控单元，用于根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常；

信息获取单元，用于若所述业务管理系统的业务数据出现异常，获取与出现异常的业务管理系统相关的监控信息；

异常确定单元，用于根据所述监控信息确定业务数据的异常原因。

第三方面，本申请又提供了一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现本申请提供的任一项所述的数据监控方法。

第四方面，本申请还提供了一种存储介质，其中所述存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行本申请提供的任一项所述的数据监控方法。

本申请实施例通过获取预设业务对应的多个业务管理系统的业务数据；以及获取所述预设业务对应的业务流程关系；根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常；并获取与出现异常的业务管理系统相关的监控信息；根据所述监控信息确定业务数据的异常原因。该方法通过业务流程关系对业务数据进行监控，因此可以及时快速地分析出业务数据的异常原因，以便维护人员及时处理。

附图说明

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

图1是本申请一实施例提供的一种数据监控方法的示意流程图；

图2是图1中步骤s103的子步骤示意流程图；

图3是本申请另一实施例提供的一种数据监控方法的示意流程图；

图4是本申请又一实施例提供的一种数据监控方法的示意流程图；

图5是本申请一实施例提供的一种数据监控装置的示意性框图；

图6是本申请另一实施例提供的一种数据监控装置的示意性框图；

图7是本申请又一实施例提供的一种数据监控装置的示意性框图；

图8是本申请一实施例提供的一种计算机设备的示意性框图。

具体实施方式

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

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

请参阅图1，图1是本申请一实施例提供的一种数据监控方法的示意流程图。如图1所示，该数据监控方法包括步骤s101～s106。

s101、获取预设业务对应的多个业务管理系统的业务数据。

本实施例中，该预设业务包括养老险、车险、意外险、人寿险或其他类别的业务等。从业务的实施角度来看每个不同的业务均会包括不同的业务流程，不同的业务流程对应着不同的业务管理系统。

譬如，养老险对应的业务流程为：投保—>核保—>支付—>承保，即该养老险对应的业务流程包括四个阶段，相应地该业务流程对应的业务管理系统则包括投保管理系统、核保管理系统、支付管理系统和承保管理系统，在该预设业务进行时，每个业务管理系统均会产生业务数据，比如投保管理系统对应的业务数据为投保量，该投保量为10000，该投保量10000即是投保管理系统对应的业务数据。

在一实施例中，获取预设业务对应的多个业务管理系统的业务数据，具体是通过调用预设采集脚本获取预设业务对应的多个业务管理系统的业务数据。通过预设脚本方便用户在相同的管理子系统设备上选择不同的不同预设业务类型。

其中，该预设采集脚本包括多维度采集脚本，比如支持时间或业务类别等不同维度的采集脚本。同时还可在预设显示界面上设有调用该预设采集脚本的控件，即提供随时修改该预设采集脚本的通道，以方便管理人员随时根据业务需要对该预设采集脚本进行修改。

此外，该预设显示界面可用于显示业务数据。具体可以采用不同形式显示多个业务数据，不同形式包括不同的颜色、不同的字体或不同的线条等。

s102、获取所述预设业务对应的业务流程关系，其中所述业务流程关系为多个所述业务管理系统的上下游关联关系。

其中，多个业务管理系统的上下游关联关系是业务管理系统按照预设业务的不同阶段对应的逻辑关系。

譬如，养老险对应的业务流程为：投保—>核保—>支付—>承保，其对应的多个业务管理系统的上下游关系为：多个业务管理系统按照“投保管理系统—>核保管理系统—>支付管理系统—>承保管理系统”顺序组成工作逻辑顺序关系。

s103、根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常。

其中，该预设监控规则为根据所述业务流程关系而预设异常监控规则。不同的预设业务具有不同的业务流程关系，因此不同的预设业务对应着不同的预设监控规则。具体地，该预设监控规则可以根据上下游关联关系采用预设算法设置告警阈值方法去监控所述业务管理系统的业务数据是否出现异常，基于此，如图2所示，步骤s103包括子步骤s103a至s103c。

s103a、确定与所述业务流程关系对应的多个预设告警值，其中多个所述预设告警值与所述业务流程关系中的多个业务管理系统一一对应。

该预设告警值与所述业务管理系统相对应，即是不同的业务管理系统对应着不同的预设告警值，用于判断每个业务管理系统的业务数据是否出现异常，因此一一对应可以理解为每个业务管理系统对应着一个预设告警值。

该预设告警值还与所述业务管理系统的上下游关联关系相关，具体地可以根据上下游关联关系采用预设算法设置该预设告警阈值，其中预设算法可采用固定阈值算法、平均值算法、spc算法、四分位算法、二次移动平均法或二次指数平滑算法等。更具体地可以根据上下游关联关系获取业务管理系统对应的实时业务数据；根据实时业务数据按照所述预设算法计算出预设告警阈值。可以使得该业务数据的监控更为准确。

s103b、判断所述业务管理系统的业务数据是否低于对应的预设告警值。

其中，判断所述业务管理系统的业务数据是否低于对应的预设告警值会产生两种判断结果，若判断结果为业务数据低于对应的预设告警值，则执行步骤s103c；若判断结果为业务数据不低于对应的预设告警值，则判定所述业务数据为出现异常。

s103c、判定所述业务管理系统的业务数据出现异常。

比如，投保管理系统对应的业务数据为18000，而其对应的预设告警值为19000，则判定该投保管理系统的业务数据出现异常。

s104、若所述业务管理系统的业务数据出现异常，获取与出现异常的业务管理系统相关的监控信息。

本实施例中，监控信息包括网络信息、主机信息、应用信息、数据库信息和中间件信息等。

具体地，可以通过cmbd(configurationmanagementdatabase，配置管理数据库)获取所述出现异常的业务管理系统相关的监控信息。具体可以通过监控与该业务监控管理系统相关的监控对象的监控信息，监控对象比如网络、主机、应用、数据库和中间件等，以及其对应的防火墙策略等。

s105、根据所述监控信息确定业务数据的异常原因。

本实施例中，基于所述监控信息，根据上下游关联关系来抽取关联性高且有价值异常信息，来帮助定位问题，以确定业务数据异常的原因，即找到业务量突增突减的可能原因。

在一实施例中，根据所述监控信息确定业务数据的异常原因，包括：汇总所述监控信息中的异常信息；基于大数据库的分析所述异常信息以得到所述异常信息中的共性信息；以及根据所述共性信息确定业务数据的异常原因。

譬如，获取多个业务监控系统对应的投保量10000->核保量9000->支付2000->承保2000，根据上述预设监控规则可以监测到支付后业务量数据量明显下降，自动收集支付管理系统相关所有监控对象及其对应的监控信息。比如，a、通过网络监控：发现应用到公网支付渠道网络不通；b、通过应用日志：发现应用中大量支付请求timeout，且发现timeout报错只出现在核保量突增时间段；c、通过中间件监控：发现大量hoggingthread(独占线程)，发现大量hogging后自动打threaddump(线程转储)展示dump(备份工具)分析结果，因此可以很容易发现都在通过httpclient(http客户端)请求支付，等待支付结果。由此根据这些监控信息可以快速找到支付系统真正的异常原因，即异常原因是由于支付渠道新增几台主机没有开通网络防火墙策略导致支付失败。

上述实施例提供的数据监控方法不仅能统计业务数据量，还能根据业务的上下游关联关系及对应预设监控规则进行监控预警，在业务数据出现异常时，通过所述出现异常的业务管理系统相关的监控信息快速分析定位出异常原因，以便及时解决问题。

请参阅图3，图3是本申请另一实施例提供的一种数据监控方法的示意流程图。该数据监控方法可以运行在终端或服务器中，也可以运行在终端和服务器的交互组成的系统中，其中该终端包括台式电脑、手提电脑、平板电脑、个人数字助理(pda)或智能手机等；该服务器可以是独立的服务器，也可以是多个服务器组成的服务器集群。如图3所示，所述方法包括步骤s201～s209。

s201、获取预设业务对应的多个业务管理系统的业务数据。

本实施例中，该预设业务包括养老险、车险、意外险、人寿险或其他类别的业务等。从业务的实施角度来看每个不同的业务均会包括不同的业务流程，不同的业务流程对应着不同的业务管理系统。比如，养老险对应的业务流程为：投保—>核保—>支付—>承保，即该养老险对应的业务流程包括四个阶段，相应地该业务流程对应的业务管理系统则包括：投保管理系统、核保管理系统、支付管理系统和承保管理系统，在该预设业务进行时，每个业务管理系统均会产生业务数据，比如投保管理系统对应的业务数据为投保量，该投保量为10000，该投保量10000即是投保管理系统对应的业务数据。

s202、获取所述预设业务对应的业务流程关系，其中所述业务流程关系为多个所述业务管理系统的上下游关联关系。

比如，养老险对应的业务流程为：投保—>核保—>支付—>承保，其对应的多个业务管理系统的上下游关系为：多个业务管理系统按照“投保管理系统—>核保管理系统—>支付管理系统—>承保管理系统”顺序组成工作逻辑顺序关系。

s203、根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常。

本实施例中，该预设监控规则为根据所述业务流程关系而预设异常监控规则。不同的预设业务具有不同的业务流程关系，因此不同的预设业务对应着不同的预设监控规则。具体地，该预设监控规则可以根据上下游关联关系采用预设算法设置告警阈值方法去监控所述业务管理系统的业务数据是否出现异常。

其中，若所述业务管理系统的业务数据出现异常，则执行步骤s206；若所述业务管理系统的业务数据未出现异常，则执行步骤s204。

s204、获取预设时间段内所述业务管理系统对应的历史业务数据。

本实施例中，该预设时间段可以为当前时间之前的一段时间，比如一天、一周或一个月等。该历史业务数据为该业务管理系统采集的历史业务数据，如果预设时间段大于一天，该预设时间段的历史业务数据为总天数的总历史业务数据的平均值，比如预设时间段为30天，则该历史业务数据为总历史业务数据除以该30天。利用该总历史业务数据的平均值作为历史业务数据可以更为准确地判断业务管理系统的业务数据是否出现异常。

需要说明的是，该总历史业务数据的平均值也可以是一段时间点内平均值，比如8:00至10:00等，具体算法和以天为单位是相同的。

s205、根据所述历史业务数据判断所述业务管理系统的业务数据是否出现异常。

本实施例中，根据所述历史业务数据判断所述业务管理系统的业务数据是否出现异常，具体也可以根据预设算法设置预设告警阈值的方法，判断所述业务管理系统的业务数据是否低于该预设告警阈值，若所述业务管理系统的业务数据低于该预设告警阈值，则可判定该所述业务管理系统的业务数据是否出现异常。

根据历史业务数据判断所述业务管理系统的业务数据是否出现异常，与上述根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常相结合，以确保在业务数据出现异常时可以真正检测出，进而提高了异常的检测准确率。

s206、获取与出现异常的业务管理系统相关的监控信息。

若所述业务管理系统的业务数据出现异常，则获取与出现异常的业务管理系统相关的监控信息。具体地，可以通过cmbd(configurationmanagementdatabase，配置管理数据库)获取所述出现异常的业务管理系统相关的监控信息。具体可以通过监控与该业务监控管理系统相关的监控对象的监控信息，监控对象比如网络、主机、应用、数据库和中间件等，以及其对应的防火墙策略等。

s207、根据所述监控信息确定业务数据的异常原因。

本实施例中，基于所述监控信息，根据上下游关联关系来抽取关联性高且有价值异常信息，来帮助定位问题，以确定业务数据异常的原因，即找到业务量突增突减的可能原因。

s208、获取所述出现异常的业务管理系统对应的管理人员的身份信息。

本实施例中，该管理人员的身份信息包括用户名称、系统注册号或手机号码等。在实际应用中，每个业务管理系统均对应一个管理人员，在获取该管理人员的身份信息后，可以根据该身份信息发送通知消息等。

s209、根据所述身份信息将所述业务数据的异常原因发送至所述管理人员。

本实施例中，根据所述身份信息将所述业务数据的异常原因发送至所述管理人员以通知管理人员对异常进行及时处理，消除异常。具体可以为系统弹出信息提示管理人员，也可以邮件形式通知管理人员，或者通过手机号以短信形式发送至管理人员的手机。

上述实施例提供的数据监控方法不仅能统计业务数据量，还能根据业务的上下游关联关系及对应预设监控规则进行监控预警，同时还可以根据历史业务数据进行监测预警，通过这种双重检测以确保统计业务在出现异常时可以准确地检测出该异常，并通过所述出现异常的业务管理系统相关的监控信息快速分析定位出异常原因，以便及时解决问题。

请参阅图4，图4是本申请另一实施例提供的一种数据监控方法的示意流程图。该数据监控方法可以运行在终端或服务器中，也可以运行在终端和服务器的交互组成的系统中，其中该终端包括台式电脑、手提电脑、平板电脑、个人数字助理(pda)或智能手机等；该服务器可以是独立的服务器，也可以是多个服务器组成的服务器集群。如图4所示，所述方法包括步骤s301～s308。

s301、获取预设业务对应的多个业务管理系统的业务数据。

s302、获取所述预设业务对应的业务流程关系，其中所述业务流程关系为多个所述业务管理系统的上下游关联关系。

s303、通过第一预设显示窗口显示多个所述业务数据，其中所述第一预设显示窗口包括第一预设控件。

本实施例中，在获取到业务数据和业务流程关系之后，可以通过第一预设显示窗口显示多个所述业务数据，该预设显示窗口可以为一个web显示界面，在该显示界面中可用不同的显示方式显示多个业务管理系统对应的业务数据，以帮助用户可以清晰了解每个业务管理系统的业务统计量。

其中，第一预设控件用于触发详细显示多个业务数据。具体地，当用户点击该第一预设控件时，则从第一预设显示窗口切换至第二预设显示窗口。

s304、若接收到触发所述第一预设控件的操作，通过第二预设显示窗口按照所述业务流程关系对应的顺序显示所述每个业务管理系统的业务数据。

第二预设显示窗口是单独显示一个业务管理系统的对应的业务数据，具体地该第二预设显示窗口包括显示区和标题区，显示区用于显示业务数据，标题区用于按照业务流程关系对应的顺序显示多个业务管理系统对应的标题，比如为投保、核保或承保等，当用户选择某个标题时，则通过显示区显示用户选择的标题对应的业务管理系统对应的业务数据。

当用户选择某个标题时，还可获取所述标题对应的业务管理系统对应的历史业务数据；通过所述显示区以不同的预设显示方式显示所述业务管理系统对应业务数据和历史业务数据。进而方便用户通过当前的业务数据和历史业务数据进行比对。

其中，第二预设显示窗口包括第二预设控件以在用户触发所述第二预设控件调出预设采集脚本，该预设采集脚本用于采集业务数据。预设采集脚本设置第二预设显示窗口上，目的是为了在用户详细看到每个业务数据之后，如果还需要进行业务数据采集调整或比对，可以很方便地触发所述第二预设控件调出预设采集脚本，对所述预设采集脚本进行修改。

s305、根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常。

其中，根据所述历史业务数据判断所述业务管理系统的业务数据是否出现异常，具体也可以根据预设算法设置预设告警阈值的方法，判断所述业务管理系统的业务数据是否低于该预设告警阈值，若所述业务管理系统的业务数据低于该预设告警阈值，则可判定该所述业务管理系统的业务数据是否出现异常。

s306、若所述业务管理系统的业务数据出现异常，锁定异常业务数据并通过所述第一预设显示窗口或第二预设显示窗口显示所述异常业务数据。

在本实施例中，如果根据上述监测方法监测出某个业务管理系统的业务数据出现异常，而此时是用户是选择第一预设显示窗口显示某个业务数据，则锁定异常业务数据并通过所述第一预设显示窗口；如果此时用户是选择第二预设显示窗口显示某个业务数据，则锁定异常业务数据并通过所述第二预设显示窗口显示该异常业务数据，方便用户或管理人员及时发现数据异常，进行排查处理。

s307、获取与出现异常的业务管理系统相关的监控信息。

具体地，可以通过配置管理数据库获取所述出现异常的业务管理系统相关的监控信息。具体可以通过监控与该业务监控管理系统相关的监控对象的监控信息，监控对象比如网络、主机、应用、数据库和中间件等，以及其对应的防火墙策略等。

s308、根据所述监控信息确定业务数据的异常原因。

具体地，基于所述监控信息，根据上下游关联关系来抽取关联性高且有价值异常信息来帮助定位问题，以确定业务数据异常的原因。

上述实施例提供的数据监控方法不仅将统计业务数据量通过第一预设显示窗口和第二预设窗口显示，还能根据业务的上下游关联关系及对应的预设监控规则进行监控预警，在业务数据出现异常时，通过所述出现异常的业务管理系统相关的监控信息快速分析定位出异常原因，以便及时解决问题。

请参阅图5，图5是本申请实施例提供的一种数据监控装置的示意性框图。该数据监控装置400可以安装于服务器或终端中。如图5所示，数据监控装置400包括数据获取单元401、关系获取单元402、异常监控单元403、信息获取单元404和异常确定单元405。

数据获取单元401，用于获取预设业务对应的多个业务管理系统的业务数据。

该预设业务包括养老险、车险、意外险、人寿险或其他类别的业务等。不同的业务流程对应着不同的业务管理系统。譬如，养老险对应的业务流程为：投保—>核保—>支付—>承保，即该养老险对应的业务流程包括四个阶段，相应地该业务流程对应的业务管理系统则包括投保管理系统、核保管理系统、支付管理系统和承保管理系统。

在一实施例中，数据获取单元401具体用于通过调用预设采集脚本获取预设业务对应的多个业务管理系统的业务数据。

关系获取单元402，用于获取所述预设业务对应的业务流程关系，其中所述业务流程关系为多个所述业务管理系统的上下游关联关系。

其中，多个业务管理系统的上下游关联关系是业务管理系统按照预设业务的不同阶段对应的逻辑关系。譬如，养老险对应的业务流程为：投保—>核保—>支付—>承保，其对应的多个业务管理系统的上下游关系为：多个业务管理系统按照“投保管理系统—>核保管理系统—>支付管理系统—>承保管理系统”顺序组成工作逻辑顺序关系。

异常监控单元403，用于根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常。

其中，该预设监控规则为根据所述业务流程关系而预设异常监控规则。不同的预设业务具有不同的业务流程关系，因此不同的预设业务对应着不同的预设监控规则。具体地，该预设监控规则可以根据上下游关联关系采用预设算法设置告警阈值方法去监控所述业务管理系统的业务数据是否出现异常，基于此，异常监控单元403包括告警确定子单元4031、告警判断子单元4032和异常判定子单元4033。

告警确定子单元4031，用于确定与所述业务流程关系对应的多个预设告警值，其中多个所述预设告警值与所述业务流程关系中的多个业务管理系统一一对应。

该预设告警值还与所述业务管理系统的上下游关联关系相关，具体地可以根据上下游关联关系采用预设算法设置该预设告警阈值，其中预设算法可采用固定阈值算法、平均值算法、spc算法、四分位算法、二次移动平均法或二次指数平滑算法等。更具体地可以根据上下游关联关系获取业务管理系统对应的实时业务数据；根据实时业务数据按照所述预设算法计算出预设告警阈值。可以使得该业务数据的监控更为准确。

告警判断子单元4032，用于判断所述业务管理系统的业务数据是否低于对应的预设告警值。

异常判定子单元4033，用于若所述业务数据低于对应的预设告警值，判定所述业务管理系统的业务数据出现异常。

信息获取单元404，用于若所述业务管理系统的业务数据出现异常，获取与出现异常的业务管理系统相关的监控信息。

监控信息包括网络信息、主机信息、应用信息、数据库信息和中间件信息等。具体地，可以通过cmbd(configurationmanagementdatabase，配置管理数据库)获取所述出现异常的业务管理系统相关的监控信息。具体可以通过监控与该业务监控管理系统相关的监控对象的监控信息，监控对象比如网络、主机、应用、数据库和中间件等，以及其对应的防火墙策略等。

异常确定单元405，用于根据所述监控信息确定业务数据的异常原因。

具体地，基于所述监控信息，根据上下游关联关系来抽取关联性高且有价值异常信息来帮助定位问题，以确定业务数据异常的原因，即找到业务量突增突减的可能原因。

在一实施例中，异常确定单元405具体用于：汇总所述监控信息中的异常信息；基于大数据库的分析所述异常信息以得到所述异常信息中的共性信息；以及根据所述共性信息确定业务数据的异常原因。

请参阅图6，图6是本申请实施例提供的一种数据监控装置的另一示意性框图。如图6所示，该数据监控装置500包括：数据获取单元501、关系获取单元502、异常监控单元503、历史数据获取单元504、异常判断单元505、信息获取单元506、信息确定单元507、身份信息获取单元508和异常原因发送单元509。

数据获取单元501，用于获取预设业务对应的多个业务管理系统的业务数据。

关系获取单元502，用于获取所述预设业务对应的业务流程关系，其中所述业务流程关系为多个所述业务管理系统的上下游关联关系。

异常监控单元503，根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常。

历史数据获取单元504，用于获取预设时间段内所述业务管理系统对应的历史业务数据。

其中中，该预设时间段可以为当前时间之前的一段时间，比如一天、一周或一个月等。该历史业务数据为该业务管理系统采集的历史业务数据，如果预设时间段大于一天，该预设时间段的历史业务数据为总天数的总历史业务数据的平均值，比如预设时间段为30天，则该历史业务数据为总历史业务数据除以该30天。利用该总历史业务数据的平均值作为历史业务数据可以更为准确地判断业务管理系统的业务数据是否出现异常。需要说明的是，该总历史业务数据的平均值也可以是一段时间点内平均值，比如8:00至10:00等，具体算法和以天为单位是相同的。

异常判断单元505，用于根据所述历史业务数据判断所述业务管理系统的业务数据是否出现异常。

其中，根据所述历史业务数据判断所述业务管理系统的业务数据是否出现异常，具体也可以根据预设算法设置预设告警阈值的方法，判断所述业务管理系统的业务数据是否低于该预设告警阈值，若所述业务管理系统的业务数据低于该预设告警阈值，则可判定该所述业务管理系统的业务数据是否出现异常。

信息获取单元506，用于获取与出现异常的业务管理系统相关的监控信息。

信息确定单元507，用于根据所述监控信息确定业务数据的异常原因。

身份信息获取单元508，用于获取所述出现异常的业务管理系统对应的管理人员的身份信息。

其中，该管理人员的身份信息包括用户名称、系统注册号或手机号码等。在实际应用中，每个业务管理系统均对应一个管理人员，在获取该管理人员的身份信息后，可以根据该身份信息发送通知消息等。

异常原因发送单元509，用于根据所述身份信息将所述业务数据的异常原因发送至所述管理人员。

其中，根据所述身份信息将所述业务数据的异常原因发送至所述管理人员以通知管理人员对异常进行及时处理，消除异常。具体可以为系统弹出信息提示管理人员，也可以邮件形式通知管理人员，或者通过手机号以短信形式发送至管理人员的手机。

请参阅图7，图7是本申请实施例提供的一种数据监控装置的另一示意性框图。如图7所示，该数据监控装置600包括：数据获取单元601、关系获取单元602、第一显示单元603、第二显示单元604、异常监控单元605、第三显示单元606、信息获取单元607和异常确定单元608。

数据获取单元601，用于获取预设业务对应的多个业务管理系统的业务数据。

关系获取单元602，用于获取所述预设业务对应的业务流程关系，其中所述业务流程关系为多个所述业务管理系统的上下游关联关系。

第一显示单元603，用于通过第一预设显示窗口显示多个所述业务数据，其中所述第一预设显示窗口包括第一预设控件。

其中，在获取到业务数据和业务流程关系之后，可以通过第一预设显示窗口显示多个所述业务数据，该预设显示窗口可以为一个web显示界面，在该显示界面中用不同的显示方式显示多个业务管理系统对应的业务数据，以帮助用户可以清晰了解每个业务管理系统的业务统计量。其中，第一预设控件用于触发详细显示多个业务数据。具体地，当用户点击该第一预设控件时，则从第一预设显示窗口切换至第二预设显示窗口。

第二显示单元604，用于若接收到触发所述第一预设控件的操作，通过第二预设显示窗口按照所述业务流程关系对应的顺序显示所述每个业务管理系统的业务数据，其中第二预设显示窗口包括第二预设控件以在用户触发所述第二预设控件调出预设采集脚本。

第二预设显示窗口是单独显示一个业务管理系统的对应的业务数据，具体地该第二预设显示窗口包括显示区和标题区，显示区用于显示业务数据，标题区用于按照业务流程关系对应的顺序显示多个业务管理系统对应的标题，比如为投保、核保或承保等，当用户选择某个标题时，则通过显示区显示用户选择的标题对应的业务管理系统对应的业务数据。

异常监控单元605，用于根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常。

其中，根据所述历史业务数据判断所述业务管理系统的业务数据是否出现异常，具体也可以根据预设算法设置预设告警阈值的方法，判断所述业务管理系统的业务数据是否低于该预设告警阈值，若所述业务管理系统的业务数据低于该预设告警阈值，则可判定该所述业务管理系统的业务数据是否出现异常。

第三显示单元606，用于若所述业务管理系统的业务数据出现异常，锁定异常业务数据并通过所述第一预设显示窗口或第二预设显示窗口显示所述异常业务数据。

其中，如果根据上述监测方法监测出某个业务管理系统的业务数据出现异常，而此时是用户是选择第一预设显示窗口显示某个业务数据，则锁定异常业务数据并通过所述第一预设显示窗口；如果此时用户是选择第二预设显示窗口显示某个业务数据，则锁定异常业务数据并通过所述第二预设显示窗口显示该异常业务数据，方便用户或管理人员及时发现数据异常，进行排查处理。

信息获取单元607，用于获取与出现异常的业务管理系统相关的监控信息。

异常确定单元608，用于根据所述监控信息确定业务数据的异常原因。

上述装置可以实现为一种计算机程序的形式，计算机程序可以在如图8所示的计算机设备上运行。

请参阅图8，图8是本申请实施例提供的一种计算机设备的示意性框图。该计算机设备700设备可以是终端或服务器。

参照图8，该计算机设备700包括通过系统总线710连接的处理器720、存储器和网络接口750，其中，存储器可以包括非易失性存储介质730和内存储器740。

该非易失性存储介质730可存储操作系统731和计算机程序732。该计算机程序732被执行时，可使得处理器720执行一种数据监控方法。

该处理器720用于提供计算和控制能力，支撑整个计算机设备700的运行。

该内存储器740为非易失性存储介质中的计算机程序的运行提供环境，该计算机程序被处理器720执行时，可使得处理器720执行一种数据监控方法。

该网络接口750用于进行网络通信，如发送分配的任务等。本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备700的限定，具体的计算机设备700可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

其中，所述处理器720用于运行存储在存储器中的程序代码，以实现如下步骤：获取预设业务对应的多个业务管理系统的业务数据；获取所述预设业务对应的业务流程关系，其中所述业务流程关系为多个所述业务管理系统的上下游关联关系；根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常；若所述业务管理系统的业务数据出现异常，获取与出现异常的业务管理系统相关的监控信息；根据所述监控信息确定业务数据的异常原因。

在一实施例中，处理器720在执行根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常之后，还执行如下步骤：若所述业务管理系统的业务数据未出现异常，获取预设时间段内所述业务管理系统对应的历史业务数据；根据所述历史业务数据判断所述业务管理系统的业务数据是否出现异常；若所述业务管理系统的业务数据出现异常，则执行所述获取与出现异常的业务管理系统相关的监控信息对应的步骤。

在一实施例中，处理器720在执行所述获取所述预设业务对应的业务流程关系之后，还执行如下步骤：通过第一预设显示窗口显示多个所述业务数据，其中所述第一预设显示窗口包括第一预设控件；若接收到触发所述第一预设控件的操作，通过第二预设显示窗口按照所述业务流程关系对应的顺序显示所述每个业务管理系统的业务数据，其中第二预设显示窗口包括第二预设控件以在用户触发所述第二预设控件调出预设采集脚本；若所述业务管理系统的业务数据出现异常，锁定异常业务数据并通过所述第一预设显示窗口或第二预设显示窗口显示所述异常业务数据。

在一实施例中，处理器720在执行所述根据所述业务流程关系按照预设监控规则监控所述业务管理系统的业务数据是否出现异常时，具体执行如下步骤：确定与所述业务流程关系对应的多个预设告警值，其中多个所述预设告警值与所述业务流程关系中的多个业务管理系统一一对应；判断所述业务管理系统的业务数据是否低于对应的预设告警值；若所述业务管理系统的业务数据低于对应的预设告警值，则判定所述业务管理系统的业务数据出现异常。

在一实施例中，处理器720在执行根据所述监控信息确定业务数据的异常原因之后，还执行如下步骤：获取所述出现异常的业务管理系统对应的管理人员的身份信息；根据所述身份信息将所述业务数据的异常原因发送至所述管理人员。

应当理解，在本申请实施例中，处理器720可以是中央处理单元(centralprocessingunit，cpu)，该处理器720还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本领域技术人员可以理解，图6中示出的计算机设备700结构并不构成对计算机设备700的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

本领域普通技术人员可以理解的是实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，程序可存储于一存储介质中，该存储介质为计算机可读存储介质。如本发明实施例中，该程序可存储于计算机系统的存储介质中，并被该计算机系统中的至少一个处理器执行，以实现包括如上述各方法的实施例的流程步骤。

该计算机可读存储介质可以是磁碟、光盘、u盘、移动硬盘、随机存储记忆体(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的数据监控装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的数据监控装置和方法，可以通过其它的方式实现。例如，以上所描述的数据监控装置实施例仅仅是示意性的。例如，各个单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。

本申请实施例装置中的单元可以根据实际需要进行合并、划分和删减。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，终端，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。