一种业务量的异常监测方法及相关设备

技术领域

本申请涉及告警监控技术领域，尤其涉及一种业务量的异常监测方法及相关设备。

背景技术

在告警监控技术领域，运维人员对于系统监控的主要关注点是中央处理器(central processing unit，CPU)、内存使用率、磁盘空间占用率和错误日志输出等，对于此类指标的监控已经有很多成熟优秀的软件工具。

但是，对于特有系统业务处理情况缺少一个能够直观显示其变化的工具。随着可视化监控工具的优势逐渐被人们所熟知，图形化的监控预警成为了运维人员不可缺少的技术手段之一。

目前针对高性能库存查询系统，如果通过现有的监控方式监控，则监控的指标为监控CPU、内存使用率、磁盘攻坚占用率和错误日志输出等指标，对于查询系统来说，这些并不是重点，这样就使得在分析高性能库存查询系统的业务量时，不容易及时的发现系统业务量异常变化。

发明内容

本申请提供了一种业务量的异常监测方法及相关设备，可以及时的发现系统业务量的异常变化，进行排查修复。

本申请实施例第一方面提供了一种业务量的异常监测方法，包括：

从N个日志服务器中读取针对于至少一个监视指标所对应的业务日志，其中，N为大于或等于1的整数；

对至少一个监视指标所对应的业务日志进行处理，以得到与至少一个监视指标所对应的文本数据；

对至少一个监视指标所对应的文本数据进行整合计算，以得到针对于第一目标指标的请求数和应答数，第一目标指标为至少一个监视指标中的任意一个监视指标；

若针对于第一目标指标的请求数和应答数之间的差异大于预设阈值，则基于针对于第一目标指标的请求数和应答数之间的差异发出告警信息。

本申请实施例第二方面提供了一种业务量异常监测装置，其特征在于，包括：

读取单元，用于从N个日志服务器中读取针对于至少一个监视指标所对应的业务日志，其中，N为大于或等于1的整数；

处理单元，用于对至少一个监视指标所对应的业务日志进行处理，以得到与至少一个监视指标所对应的文本数据；

整合计算单元，用于对至少一个监视指标所对应的文本数据进行整合计算，以得到针对于第一目标指标的请求数和应答数，第一目标指标为至少一个监视指标中的任意一个监视指标；

告警单元，用于若针对于第一目标指标的请求数和应答数之间的差异大于预设阈值，则基于针对于第一目标指标的请求数和应答数之间的差异发出告警信息。

本申请第三方面提供了一种计算机装置，其包括至少一个连接的处理器和存储器，其中，所述存储器用于存储程序代码，所述程序代码由所述处理器加载并执行以实现上述各方面所述的业务量的异常监测方法的步骤。

本申请实施例第四方面提供了一种机器可读介质，其包括指令，当其在机器上运行时，使得机器执行上述各方面所述的业务量的异常监测方法的步骤。

综上所述，可以看出，本申请提供的实施例中，可以直接从日志服务器获取日志内容信息，无需生成文件，省去了后续清理过期文件的操作，同时可以清楚的显示出接收到针对某个指标的请求数量和应答数量，并根据请求数量和应答数量的差异发出告警信息，使得用户可以及时的发现系统业务量的异常变化，进行排查修复。

附图说明

结合附图并参考以下具体实施方式，本申请各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1为本申请实施例提供的业务量异常监测系统的架构图；

图2为本申请实施例提供的业务量的异常监测方法的流程示意图；

图3为本申请实施例提供的业务量异常监测装置的结构示意图；

图4为本申请实施例提供的机器可读介质的结构示意图；

图5为本申请实施例提供的服务器的硬件结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的实施例。虽然附图中显示了本申请的某些实施例，然而应当理解的是，本申请可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本申请。应当理解的是，本申请的附图及实施例仅用于示例性作用，并非用于限制本申请的保护范围。

本申请中使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本申请中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本申请中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

请参阅图1，图1为本申请实施例提供的业务量异常监测系统的架构图，包括：数据提取组件101、数据收集组件102和存储展示组件103；

其中，数据提取组件101包括日志读取模块和数据文本整理模块，其中，数据读取模块用于将某些需要监视的数据指标从日志服务器的业务日志中提取出来，数据文本整理模块用于对从日志服务器的业务日志中提取的数据指标进行预处理形成固定格式的文本单元，此文本单元仅是字符输出，不存储成文件。

数据收集组件102包括数据传输模块和数据整合模块，其中，数据传输模块用于远程指令和执行结果的传递，数据整合模块通过数据传输向各日志服务器上的数据提取组件101发送收集指令，接收到执行结果后进行数据处理，最后向存储展示组件103发送数据存储请求。数据传输模块采用服务器-客户机(Client-Server，C/S)分布式模式，采用套接字(socket)接口通信。每个日志服务器上都部署着一个客户端程序，随时接收采集指令并转发到数据提取组件101，数据提取组件101根据接收到的采集指令读取被监控的日志服务器所产生的审计(audit)日志，从该audit日志中提取出监控指标对应的日志数据，并按照固定格式生成字符串，最后通过数据传输模块反馈给数据整合模块。数据整合模块把所有日志服务器获得的指标数据收齐后进行整合计算，这里可以根据需要设置不同的计算逻辑(不同的计算逻辑，例如可以是以地区将相同指标的指标数据进行整合，或者按照指标的类型进行分类统计，例如某个指标包括A子指标和B子指标，则可以分别统计A子指标的指标数据和B子指标的指标数据)，最终生成数据存储请求并发往存储展示组件103。

存储展示组件103包括数据存储模块、数据显示模块和告警模块，该存储展示组件103用于接收数据存储请求，并将请求中的数据存储至时序性数据库，并通过前端页面将该请求中的数据展示成可视化画面，另外该前端设备上可以设置预设阈值，且可以在该请求中的数据达到预设阈值时，发出告警信息。

下面从服务器的角度本申请提供的业务量的异常监测方法进行说明，请参阅图2，图2为本申请实施例提供的业务量的异常监测方法的一个流程示意图，包括：

201、从N个日志服务器中读取针对于至少一个监视指标所对应的业务日志。

本实施例中，业务量异常监测装置在需求对查询系统中的业务量进行异常监测时，从N个日志服务器中读取针对于至少一个监视指标所对应的业务日志，其中，N为大于或等于1的整数。可以理解的是，该日志服务器中存储有所有的监视指标的请求数、应答数及其他的相关日志信息，该至少一个监视指标包括但不限于航班状态查询系统(Availability Engine Module，AVE)请求、AVE应答、tode_AV请求(TransactionOperating&Distributing Engine航信C++交易中间件，是一个容器，此处指代部署在tode容器上的应用请求)、航信云计算应用平台(TravelSky Application Platform，TAP)_AV请求(该TAP_AV请求指代部署在TAP上的应用请求)、tode_UV请求、tode_AV耗时、TAP_AV耗时、tode_UV耗时以及IV数据接收量。可以理解的是，从N个日志服务器中读取至少一个监视指标所对应的业务日志可以根据用户的监视指令进行触发，也可以周期性的进行读取，具体不做限定。

需要说明的是，当周期性的读取至少一个监视指标所对应的业务日志时，可以对至少一个监视指标的数据提取频率进行设置，例如设置30分钟读取一次，或者1小时读取一次等等。

还需要说明的是，在从N个日志服务器中提取至少一个监控指标所对应的业务日志时，可以首先在N个日志服务器上部署数据提取组件，该数据提取组件具备读取N个日志服务器中业务日志的权限，之后配置N个日志服务器中每个日志服务器的地址信息，进而使得该业务量异常监测装置可以基于N个日志服务器中每个日志服务器的地址信息从N个日志服务器中读取针对于至少一个监视指标所对应的业务日志。该数据提取组件包括日志服务器信息、该日志服务器中的日志路径以及期望从该日志服务器中采集到的数据指标，该日志服务器信息例如可以为网际互连协议(Internet Protocol，IP)地址以及端口等信息。

202、对至少一个监视指标所对应的业务日志进行处理，以得到与至少一个监视指标所对应的文本数据。

本实施例中，业务量的异常监测装置在读取到针对于至少一个监视指标所对应的业务日志之后，可以对至少一个监视指标所对应的业务日志进行处理，以得到与至少一个监视指标所对应的文本数据。可以理解的是，此处的处理指的是，首先将至少一个监视指标对应的指标数据从对应的业务日志中进行提取，之后将提取到的指标数据按照固定格式生成字符串，该字符串即为第一目标指标所对应的文本数据。

203、对至少一个监视指标所对应的文本数据进行整合计算，以得到针对第一目标指标的请求数和应答数。

本实施例中，业务量异常监测装置在获取到至少一个监视指标所对应的文本数据之后，可以对该至少一个监视指标所对应的文本数据进行整合计算，以得到针对于第一目标指标的请求数和应答数，其中，该第一目标指标为至少一个监视指标中的任意一个监视指标。可以理解的是，此处的整合计算指的是将不同日志服务器中获取到与第一目标指标相对应的指标数据进行整合计算，得到该第一目标指标对应的所有的请求数和所有的应答数。

204、若针对于第一目标指标的请求数和应答数之间的差异大于预设阈值，则基于针对于第一目标指标的请求数和应答数之间的差异发出告警信息。

本实施例中，业务量异常监测装置在确定针对于第一目标指标的请求数和应答数之后，可以判断针对于第一目标指标的请求数和应答数之间的差异是否大于预设阈值，例如该第一目标指标的请求数为100，第一目标指标的应答数为20，预设阈值为10，则可以确定该第一目标指标的请求数与第一目标指标的应答数的差异大于预设阈值，说明对于该第一目标指标的处理出现异常，由此基于针对于第一目标指标的请求数和应答数之间的差异发出告警信息，该告警信息包括第一目标指标的请求数和应答数之间的差异。

可以理解的是，该告警信息可以通过发出报警提示音的方式或者直接通过邮件、短信、即时通信等方式将告警信息发送至发送管理员的终端设备，当然也还可以直接将告警信息通过前端设备进行展示，具体不做限定。

需要说明的是，业务量异常监测装置还可以提前配置时序性数据库的存储统一资源定位器(Uniform Resource Locator，URL)，之后基于该时序性数据库的存储URL将第一目标指标所对应的请求数和应答数进行存储，也就是说，业务异常监测装置在得到第一目标指标的请求数和应答数之后，可以直接将该第一目标指标的请求数和应答数存储至提前配置的时序性数据库，方便用户从时序性数据库中获取指标的数据并进行展示。

一个实施例中，业务量异常监测装置还执行如下操作：

响应数据展示指令，从时序性数据库中获取与预设时间内与第二目标指标所对应的请求数和应答数；

通过前端设备将当前周期内与第二目标指标所对应的请求数和应答数进行可视化展示。

本实施例中，业务量异常监测装置可以根据数据展示指令，从时序性数据库中一段时间内获取第二目标指标所对应的请求数和应答数，并通过前端设备将与第二目标指标所对应的请求数和应答数进行可视化展示，例如业务量异常监测装置可以将最近30分钟内与AVE指标的请求数和应答数发送至前端设备，进行可视化展示。也就是说，业务量异常监测装置可以持续的获取目标指标的指标数据，并将各个时间点获取的目标指标的指标数据进行图形化展示，正常情况下，请求数和应答数是基本相同的，接近稳定，如果出现异常，可视化展示的图形就会出现波动，此时则说明出现问题，则可以发出告警信息。

一个实施例中，生成数据展示指令的操作至少包括手势操作、滑动操作、点击操作以及声控操作中的一种，例如用户在前端设备进行点击操作时，业务量异常监测装置可以接收到该点击操作，此时，该点击操作即生成该数据展示指令，也就是说，可以提前定义操作指令，例如提前定义滑动操作为生成数据展示指令的操作(如左滑操作、右滑操作、上滑操作以及下滑操作等等)，或者定义点击操作为生成数据展示指令的操作(如双击操作、鼠标滑动操作、长按操作、单击操作、鼠标左右键同时按操作以及滚轮鼠标中键等等)，或者定义手势操作为生成数据展示指令的操作(如向左摆动手腕或手臂，向右摆动手腕或手臂，如四根手指收缩操作或者三根手指上滑操作等等)，或者定义声控操作为生成数据展示指令的操作(如收到展示预设时间内某个指标的指标数据的声音)，上述仅为举例说明，并不代表对生成数据展示指令的操作进行限定。当然该数据展示指令还可以通过在输入设备上设置对应的快捷键进行生成，例如该输入设备为键盘，通过设置键盘上的“CTRL+A键”作为生成数据展示指令的操作，具体不限定。

综上所述，可以看出，本申请提供的实施例中，可以直接从日志服务器获取日志内容信息，无需生成文件，省去了后续清理过期文件的操作，同时可以清楚的显示出接收到针对某个指标的请求数量和应答数量，并根据请求数量和应答数量的差异发出告警信息，使得用户可以及时的发现系统业务量的异常变化，进行排查修复。

可以理解的是，附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本申请实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。

应当理解，本申请的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本申请的范围在此方面不受限制。

另外，本申请还可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

上面从业务量的异常监测方法的角度对本申请实施例进行说明，下面从业务量异常监测装置的角度对本申请实施例进行说明。

请参阅图3，图3为本申请实施例提供的业务量异常监测装置的虚拟结构意图，该业务量异常监测装置300包括：

读取单元301，用于从N个日志服务器中读取针对于至少一个监视指标所对应的业务日志，其中，N为大于或等于1的整数；

处理单元302，用于对所述至少一个监视指标所对应的业务日志进行处理，以得到与所述至少一个监视指标所对应的文本数据；

整合计算单元303，用于对所述至少一个监视指标所对应的文本数据进行整合计算，以得到针对于第一目标指标的请求数和应答数，所述第一目标指标为所述至少一个监视指标中的任意一个监视指标；

告警单元304，用于若针对于所述第一目标指标的请求数和应答数之间的差异大于预设阈值，则基于针对于所述第一目标指标的请求数和应答数之间的差异发出告警信息。

可选地，所述处理单元302具体用于：

从所述至少一个监视指标所对应的业务日志中提取所述第一目标指标所对应的指标数据；

将所述第一目标指标所对应的指标数据按照预设格式组成字符串；

将所述字符串确定为所述第一目标指标所对应的文本数据。

可选地，所述读取单元301，还用于在所述N个日志服务器上部署数据提取组件，所述数据提取组件具备读取所述N个日志服务器中业务日志的权限；

所述读取单元301，还用于配置所述N个日志服务器中每个日志服务器的地址信息；

所述读取单元301从N个日志服务器中读取针对于所述至少一个监视指标所对应的业务日志包括：

基于所述N个日志服务器中每个日志服务器的地址信息，通过所述数据提取组件从所述N个日志服务器中读取针对于所述至少一个监视指标所对应的业务日志。

可选地，所述处理单元302还用于：

配置时序性数据库的存储统一资源定位器URL；

基于所述时序性数据库的存储URL将所述第一目标指标所对应的请求数和应答数进行存储。

可选地，所述处理单元302还用于：

响应数据展示指令，从所述时序性数据库中获取与预设时间内与第二目标指标所对应的请求数和应答数，所述第二目标指标为所述至少一个监控指标中的任意一个指标；

通过前端设备将与所述第二目标指标所对应的请求数和应答数进行可视化展示。

综上所述，可以看出，本申请提供的实施例中，可以直接从日志服务器获取日志内容信息，无需生成文件，省去了后续清理过期文件的操作，同时可以清楚的显示出接收到针对某个指标的请求数量和应答数量，并根据请求数量和应答数量的差异发出告警信息，使得用户可以及时的发现系统业务量的异常变化，进行排查修复。

需要说明的是，描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定，例如，获取单元还可以被描述为“获取目标用户的证件信息的单元”。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

请参阅图4，图4为本申请实施例提供的一种机器可读介质的实施例示意图。

如图4所示，本实施例提供了一种机器可读介质400，其上存储有计算机程序411，该计算机程序411被处理器执行时实现上述图2中所述业务量的异常监测方法的步骤。

需要说明的是，本申请的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

需要说明的是，本申请上述的机器可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

请参阅图5，图5是本申请实施例提供的一种服务器的硬件结构示意图，该服务器500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)522(例如，一个或一个以上处理器)和存储器532，一个或一个以上存储应用程序542或数据544的存储介质530(例如一个或一个以上海量存储设备)。其中，存储器532和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器522可以设置为与存储介质530通信，在服务器500上执行存储介质530中的一系列指令操作。

服务器500还可以包括一个或一个以上电源526，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口558，和/或，一个或一个以上操作系统541，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。

上述实施例中由业务量异常监测装置所执行的步骤可以基于该图5所示的服务器结构。

还需要说明的，根据本申请的实施例，上述图2的流程示意图描述的所述业务量的异常监测方法的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行上述图2的流程示意图中所示的方法的程序代码。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本申请的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。