一种多系统集中监测方法及系统与流程

本发明涉及计算机技术领域，具体涉及一种多系统集中监测方法及系统。

背景技术：

随着计算机技术的发展，网络连接已经成为联通计算机的重要手段。在整个网络体系中，存在多种系统。目前有一些对系统进行监测的方法和系统，其采集系统的数据参数，并根据采集的结果判断各个系统的异常。但是这些监测方法和监测系统，没有考虑多个订单查询系统，无法集中监测各个订单查询系统的数据并进行相应预警。

技术实现要素：

针对现有技术中，对多系统无法进行集中监测的问题，本发明提出了一种多系统集中监测方法和系统。

一种多系统集中监测方法，所述方法包括：

后台系统从网关获取多个订单查询系统的名称、查询渠道；

所述后台系统从任务中心获取所述多个订单查询系统的订单数据；

所述后台系统判断获取的所述订单数据是否超出预警值；

所述后台系统将获取的所述订单数据发送给显示系统进行显示。

进一步地，所述订单数据包括计划查询账号数量、实际查询账号数量、订单查询成功数量、订单查无记录数量、订单查询失败数量、查询中的订单数量、当前查询时长和等待队列数量中的一个或多个。

进一步地，所述显示系统将所述订单数据中超出预警值的订单数据进行突出显示。

进一步地，所述后台系统将获取的所述订单数据发送给显示系统进行显示具体为：

首先加载基础信息；然后加载附加信息。

进一步地，所述基础信息包括所有订单查询系统的名称、查询渠道、计划查询账号数量中的一个或多个；

所述附加信息包括每个订单查询系统计划查询的各个账号名称、实际查询账号数量、订单查询成功数量、订单查无记录数量、订单查询失败数量、查询中的订单数量、当前查询时长和等待队列数量中的一个或多个。

进一步地，所述后台系统保存历史订单数据，基于新增的订单数据判断是否超出预警值。

进一步地，后台系统监测内网透传系统的状态来判断网络是否出现故障。

一种多系统集中监测系统，所述系统包括网关、任务中心、后台系统和显示系统，其中，

所述网关，用于向所述后台系统发送多个订单查询系统的名称、查询渠道；

所述任务中心，用于向所述后台系统发送所述多个订单查询系统的订单数据；

后台系统，用于判断获取的所述订单数据是否超出预警值；

所述显示系统，用于将所述后台系统将获取的所述订单数据进行显示。

进一步地，所述显示系统，还用于将超出所述预警值的订单数据进行突出显示。

进一步地，所述后台系统，还用于监测内网透传系统的状态以判断网络是否出现故障。

通过本发明的技术方案，对多个系统进行了集中监测，能够根据监测情况快速定位问题。本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所指出的结构来实现和获得。

附图说明

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

图1示出了根据本发明实施例的一种多系统集中监测的流程示意图；

图2示出了根据本发明实施例的一种多系统集中监测系统的框架图；

图3示出了根据本发明实施例的显示系统对数据进行显示的示意图；

图4示出了根据本发明实施例的报警机制流程示意图。

具体实施方式

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

如图1示出了根据本发明实施例的一种多系统集中监测方法流程示意图。如图所示，所述方法包括：后台系统从网关获取多个订单查询系统的名称、查询渠道；所述后台系统从任务中心获取所述多个订单查询系统的订单数据；所述后台系统判断获取的所述订单数据是否超出预警值；所述后台系统将获取的所述订单数据发送给显示系统进行显示。

不失一般性，本发明实施例以多个订单查询系统为例进行说明，所述订单查询系统以奥迪订单查询系统、别克订单查询系统、丰田订单查询系统为例进行示例性说明，但本发明并不限于上述三个订单查询系统，其他任意多个系统、多种订单查询系统均可适用于本发明。示例性地，上述每个订单查询系统对应有一个或多个账号，每个账号下对应有订单数量，如下表所示：

订单查询系统中存有大量订单，这些订单记录有车辆型号、发动机号、出厂日期、维修保养记录等信息。

后台系统在对各个系统进行查询时，可以随机通过多个查询渠道中的一个或多个进行查询、或者按照优先级顺序通过多个查询渠道中的一个或多个进行查询。示例性地，ch1为第一个查询渠道、ch2为第二查询渠道、ch3为第三个查询渠道。

图2示出了根据本发明实施例的一种多系统集中监测系统的框架图。如图所示所述多系统集中监测系统主要包括网关、任务中心、后台系统和显示系统，其中，所述网关用于向所述后台系统发送多个订单查询系统的名称、查询渠道，所述任务中心用于向所述后台系统发送所述多个订单查询系统的订单数据，后台系统用于判断获取的所述订单数据是否超出预警值，所述显示系统用于将所述后台系统将获取的所述订单数据进行显示。需要说明的是本发明的后台系统和显示系统并不必然表示两套系统，其可以是同一个设备内的两个系统。

所述后台系统会根据订单查询系统的名称，通过所述任务中心在相应查询渠道中对相关账号进行查询，获取相关账号中订单数量的状态，包括计划查询账号数量、实际查询账号数量、订单查询成功数量、订单查无记录数量、订单查询失败数量、查询中的订单数量、当前查询时长和等待队列数量等数据内容。

其中，查询中的所述等待队列设有优先级，示例性地，可以设置三个优先级，以30、20、10分别进行标记，其中30表示优先级最高、20表示优先级次高、10表示优先级最低。

不失一般性，针对吉普订单查询系统，通过查询渠道ch1进行了查询，计划查询账号j1中的订单信息，实际上也通过ch1对吉普订单查询系统账号j1的订单进行了查询。通过上述对吉普订单查询系统账号j1的查询，后台获得查询成功的订单数量为189个，查无记录的订单数量为5个，查询失败的次数为0，当前仍处于查询中的订单数量为0，当前查询所花费的时长为15秒，等待队列中有1个，等待队列的优先级为30。

针对奥迪订单查询系统，通过查询渠道ch1、ch2进行了查询。其中，通过渠道ch1计划查询a1这一个账号，实际上后台也查询到了该a1账号，查询成功的订单数量为149，查无记录的订单数量为13，查询失败的次数为0，处于查询中的订单数量为5，当前查询所花费的时间为30秒，等待队列有23个，其中1个队列的优先级为10、两个队列的优先级为20、其余20个队列的优先级为30；通过渠道ch2计划查询a2这一个账号，实际上后台也查询到了该a2账号，查询成功的订单数量为68，查无记录的订单数量为2，查询失败的次数为0，处于查询中的订单数量为8，当前查询所花费的时间为20秒，等待队列有2个，这两个队列的优先级为30。

针对别克订单查询系统，通过查询渠道ch2查询b1和b2账号，通过ch3渠道查询b3账号。其中，通过渠道ch2计划查询b1和b2这两个账号，实际上后台也查询到了b1和b2这两个账号，查询成功的订单数量为220，查无记录的订单数量为0，查询失败的次数为1，处于查询中的订单数量为8，当前查询所花费的时间为35秒，等待队列有1个，其优先级为30；通过渠道ch3计划查询b3这一账号，实际上后台也查询到了b3账号，查询成功的订单数量为118，查无记录的订单数量为0，查询失败的次数为0，处于查询中的订单数量为1，当前查询所花费的时间为15秒，等待队列有1个，其优先级为30。

后台系统获取到上述数据内容后，通过显示系统进行显示。图3示出了根据本发明实施例的显示系统对数据进行显示的示意图，如图所示显示系统对吉普订单查询系统、奥迪订单查询系统和别克订单查询系统查询到的数据进行了显示。

所述显示系统在对查询得到的数据内容显示时，为了提高显示页面的加载效率，可以先加载系统信息这类的基础信息，然后根据需要再加载账号信息这类的附加信息。其中，基础信息包括所有订单查询系统的名称、查询渠道、计划查询账号数量等数据内容；附加信息包括每个订单查询系统计划查询的各个账号名称、实际查询账号数量、订单查询成功数量、订单查无记录数量、订单查询失败数量、查询中的订单数量、当前查询时长、等待队列等数据内容。示例性地，显示系统首先将“吉普、奥迪、别克”加载到页面中的“系统名称”一栏中；将吉普订单查询系统的查询渠道“ch1”、奥迪订单查询系统的“ch1”、“ch2”、别克订单查询系统的“ch2”、“ch3”加载到页面中的“查询渠道”一栏；将每个订单查询系统对应查询渠道的计划查询账号数量加载到显示页面的“计划查询账号”一栏中。上述基础信息加载完成后，所述显示系统再加载附加信息。也可以根据用户需要优先加载相关附加信息。示例性地，例如需要查看吉普订单查询系统的查询数据内容，可以点击吉普订单查询系统对应的“查询成功”一栏来请求获得对吉普订单查询系统的订单查询成功的数量，后台系统得到该请求后，优先将吉普订单查询系统查询成功的订单数量发送给显示系统进行加载并显示。

后台系统可以对获取的数据进行更新，数据更新的方式为：

方式一：所述后台系统周期性(例如每个2秒、每隔5分钟、每隔2小时等)请求所述任务中心获取上述数据内容，并发送给显示系统进行显示。这种数据更新方式可以实时获取数据，方便用户及时查看数据，但是频繁地数据更新会加大整个系统的处理负担，对所述任务中心和所述后台系统的处理能力要求较高。因此，可以采用方式二进行数据更新。

方式二：基于用户的请求而进行全部数据更新。用户在需要的情况下，通过更新请求触发所述后台系统请求所述任务中心获取上述数据内容。这种更新方式的优势在于，用户不需要查看数据时，无需获取上述数据内容，从而降低所述后台系统、所述任务中心的处理负担。但是这种数据更新方式，会对所有数据都进行更新，在系统数量、账号数量较多时，例如订单查询系统数量在100个时，处理负担还是较大，造成数据获取的延时也较大，这也将会极大地降低用户的使用体验，而且对于用户来说，有些数据也并不是必须要更新查看的。因此，可以采用方式三进行数据更新。

方式三：基于用户的请求而进行部分数据更新。这种方式下，用户可以针对感兴趣的数据进行更新。示例性地，用户仅需要查看奥迪系统的相关数据内容，而对吉普系统和别克系统则并不关注。这种情况下，用户请求对奥迪系统的数据内容进行更新，例如点击如图3中“奥迪”字样左侧的“-”按键，则启动对奥迪订单查询系统各个查询渠道重新查询数据内容以实现更新。

上述几种方式可以结合使用，例如通过方式一设置后台的周期性更新时间是每2两个小时更新一次。同时，用户在需要的情况下，通过方式二或方式三对全部数据或部分数据进行更新。

本发明实施例的多系统集中监测系统还可以包括一个抓取系统，所述抓取系统将上述各个订单查询系统对应的查询账号处理过的订单数据发送给后台。

运维人员可以在后台系统维护各个订单查询系统总表，包括订单查询系统中订单及其对应的账号。所述后台系统获取到上述数据内容后，将获取的各订单查询系统的账号与其维护的总表进行对比，确定是否存在账号异常。示例性地，奥迪系统在后台维护的账号总表里有10个账号，而在抓取传来账号数为8个，那么可以判断剩余的两个账号处于异常，运维人员可以追查账号异常的原因。

进一步地，后台系统对查询完成的订单进行进一步分析，以获得订单中的内容，例如分析订单中是否有维修保养记录。如果查询到有维修保养记录，但在维护的订单内没有维修保养记录，这说明监测系统出现故障，运维人员可以介入进行故障查找。

后台系统获取到上述数据内容后，还通过制定的多维度报警机制进行报警。图4示出了根据本发明实施例的报警机制流程示意图，如图所示，所述后台系统监控各个订单查询系统的数据情况，进行正常显示或者根据报警机制进行报警。

其中，所述多维度报警机制，可以是针对多个系统或多个系统的查询渠道分别设置报警阈值，并将检测的数据与设置的报警阈值进行比较，低于报警阈值的进行正常显示，而对于高于报警阈值的进行突出显示。

示例性地，可以对查询失败队列进行监控，例如将奥迪订单查询系统连续查询失败的数量设置为5单，在后台系统查询奥迪订单查询系统过程中出现连续5单查询失败时，后台系统进行报警。

示例性地，可以针对各个订单查询系统的查询时长单独设置预警值。例如，奥迪系统因为查询较慢，将其查询时长设置为10分钟，在查询时长超过10分钟时，针对奥迪订单查询系统进行报警；而大众系统因为查询效率高，可以将其查询时长设置为5分钟，在查询时长超过5分钟时，这对大众订单查询系统报警。

示例性地，还可以针对各个订单查询系统的等待队列设置预警值。例如设置各个订单查询系统等待队列的预警阈值为2。吉普订单查询系统、奥迪订单查询系统和别克订单查询系统各个查询渠道的等待队列数量要与预警值2进行比较。由于奥迪订单查询系统中通过ch1渠道查询的等待队列有23个，这超出了预警值2，因此后台系统对奥迪订单查询系统查询渠道ch1发出报警。示例性地，还可以将查询时长预警值设置为2分钟，后台系统会将各个订单查询系统的不同查询渠道的查询时长跟预警值进行比较。在查询时长超出预警值后，启动报警流程。

后台系统还可以对账号的网络异常情况进行监控。在监测过程中，后台系统抓取将相关账号在内网透传系统(例如pptun系统)的状态，查看其状态是在线状态还是离线状态，在监测到内网透传系统的状态是离线状态时，则判断网络异常，此时可以在页面显示相关订单的账号异常。

报警方式可以是后台系统控制相关系统对超出预警值的项目进行高亮显示、闪动显示、放大显示等突出性的显示。如图3所示，由于奥迪订单查询系统中ch1查询渠道的查询中的订单数量和等待队列超出预警值，所以显示系统将“奥迪”、查询中一栏的数字“5、8”以及等待队列一栏“10:1/20:2/30:20”进行了突出显示。

如果订单查询系统较多，例如100多个订单查询系统，针对所有系统的所有数据进行报警运算将极大增加运算量。本发明实施例的后台系统可以将历史数据进行保存，针对新增的数据进行运算，即基于新增的订单数据判断是否超出预警值，进而进行预警。这样将降低运算量。

对于超出预警值的项目，可以通过人工介入的方式解决。示例性地，奥迪订单查询系统中ch1查询渠道的等待队列超出了预警值，人工可以增加其他查询渠道对等待队列进行查询。

如图4所示，在超出预警值而人工未介入的情况下进行报警，报警后仍然可以人工介入来解决报警问题。人工介入后，后台系统将查询设置为处于解决中的状态。方便用户在显示系统中直观看到问题正在处理中。

通过上述实施例中的技术方案，实现了对多个订单查询系统的集中监测。对于监测的数据能够进行集中可视化展示，这样维护人员可以根据监测情况快速定位问题。

尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。