业务的监控方法和服务器与流程

本发明涉及数据处理技术领域，尤其涉及一种业务的监控方法和服务器。

背景技术：

以用户体验为中心是互联网公司业务持续高速发展和盈利的重要保障。以互联网电视业务为例，如今互联网电视应用向广大电视消费者提供了越来越丰富的电视应用服务，如何有效地实时监控互联网电视应用的业务服务状态、可用性与稳定性是互联网电视公司服务提供商持续发展所面临地重要问题。

现有技术中，在实时对互联网电视应用的业务服务状态、可用性与稳定性进行监控时，先获取通过电视的客户端或者提供商的服务端埋点上报的各种业务的日志数据，由于各种业务的日志数据无法自动进行路由，需要工程师手动对每一种业务的日志数据进行配置至提供商的hadoop集群中，之后，才能通过工作流调度引擎(如airflow)在hadoop集群中发起工作流计算任务进行分析与计算，从而根据业务的日志数据对业务服务状态、可用性与稳定性进行监控。

因此，采用现有的处理方法，由于需要工程师手动对每一种业务的日志数据进行配置，会导致业务的监控效率较低。

技术实现要素：

本发明实施例提供一种业务的监控方法和服务器，在对业务的运行状态进行监控时，提高了业务的监控效率。

第一方面，本发明实施例提供一种业务的监控方法，该业务的监控方法可以包括：

获取m种业务中每一种业务的业务日志数据；m为大于或者等于1的整数。

若所述m种业务中存在第一业务的业务日志数据包括第一日志标签路由，且所述第一日志标签路由与日志元数据库中所述第一业务的预设标签路由匹配，则根据所述第一业务的业务日志数据对所述第一业务的运行状态进行监控。

根据监控结果输出提示信息。

第二方面，本发明实施例还提供一种服务器，该服务器可以包括：

采集模块，用于获取m种业务中每一种业务的业务日志数据；m为大于或者等于1的整数。

监控模块，用于若所述m种业务中存在第一业务的业务日志数据包括第一日志标签路由，且所述第一日志标签路由与日志元数据库中所述第一业务的预设标签路由匹配，则根据所述第一业务的业务日志数据对所述第一业务的运行状态进行监控。

告警模块，用于根据监控结果输出提示信息。

第三方面，本发明实施例还提供一种服务器，该服务器可以包括存储器和处理器。

存储器，用于存储计算机程序。

处理器，用于读取存储器存储的计算机程序，并根据所述存储器中的计算机程序执行上述第一方面任一项所述的业务的监控方法。

第四方面，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，执行上述第一方面任一项所述的业务的监控方法。

本发明实施例提供的业务的监控方法和服务器，在获取到m种业务中每一种业务的业务日志数据后，若m种业务中存在第一业务的业务日志数据包括第一日志标签路由，且第一日志标签路由与日志元数据库中第一业务的预设标签路由匹配，则根据第一业务的业务日志数据对第一业务的运行状态进行监控，并根据监控结果输出提示信息。与现有技术相比，无需工程师手动对每一种业务的日志数据进行配置，而是由于需要监控的业务的业务日志数据中标注有日志标签路由，使得服务器可以直接根据该日志标签路由在多种业务中确定需要监控的业务，从而提高了业务的监控效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1为本发明实施例提供的一种应用场景的示意图；

图2为本发明实施例提供的一种业务的监控方法的流程示意图；

图3为本发明实施例提供的另一种业务的监控方法的流程示意图；

图4为本发明实施例提供的一种服务器的结构示意图；

图5为本发明实施例提供的另一种服务器的结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本发明的实施例中，“至少一种”是指一种或者多种，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况，其中a，b可以是单数或者复数。在本发明的文字描述中，字符“/”一般表示前后关联对象是一种“或”的关系。

鉴于现有技术中存在的问题，为了实现在对业务的运行状态进行监控时，提高业务的监控效率，本发明实施例提供了一种业务的监控方法，该业务的监控方法可以应用在业务监控及告警系统，示例的，请参见图1所示，图1为本发明实施例提供的一种应用场景的示意图，该业务监控告警系统可以安装在服务器，服务器可以从消息集群，例如kafka集群中采集多种业务的业务日志数据后，会根据业务日志数据中是否包括日志标签路由，或者当业务日志数据中包括日志标签路由时，该日志标签路由是否与日志元数据库中该业务的预设标签路由是否匹配，对多种业务的业务日志数据进行分类，将不需要监控的业务的业务日志数据存储至离线数据仓库中，以通过离线数据仓库对该不需要监控的业务的业务日志数据进行离线分析；将需要监控的业务的业务日志数据存储至实时数据仓库中，并基于实时数据仓库中的业务日志数据对业务的运行状态进行监控，从而根据监控结果向用户输出提示信息。示例的，离线数据仓库可以为hive；实时数据仓库可以为druid集群。

可以看出，与现有技术不同的是，本发明实施例中，在对业务的运行状态进行监控时，无需工程师手动对每一种业务的日志数据进行配置，而是由于需要监控的业务的业务日志数据中标注有日志标签路由，使得服务器可以直接根据该日志标签路由在多种业务中确定需要监控的业务，并基于该业务的业务日志数据对该业务的运行状态进行监控，从而提高了业务的监控效率。

下面以具体地实施例对本发明的技术方案以及本发明的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。

图2为本发明实施例提供的一种业务的监控方法的流程示意图，示例的，请参见图2所示，该业务的监控方法可以包括：

s201、获取m种业务中每一种业务的业务日志数据。

其中，m为大于或者等于1的整数。

示例的，服务器的采集模块可以通过埋点或者sdk从kafka集群中采集多种业务中每一种业务的业务日志数据，该业务日志数据是可以直接用于监控的服务明细状态数据。示例的，业务日志数据可以为用户支付业务的业务日志数据、会员权益业务的业务日志数据，视频点播和轮播业务的业务日志数据以及其他用户行为的业务日志数据等。可以理解的是，对于一种业务而言，其业务日志数据的个数可以为一个，也可以为多个，具体可以根据实际需要进行设置，在此，对于一种业务对应的业务日志数据的个数，本发明实施例不做具体限制。

在获取到m种业务中每一种业务的业务日志数据之后，就可以根据每一种业务的业务日志数据中是否包括日志标签路由，或者当业务日志数据中包括日志标签路由时，该日志标签路由是否与日志元数据库中业务的预设标签路由是否匹配，对多种业务的业务日志数据进行分类，以确定需要被监控的业务，即执行下述s202：

s202、若m种业务中存在第一业务的业务日志数据包括第一日志标签路由，且第一日志标签路由与日志元数据库中第一业务的预设标签路由匹配，则根据第一业务的业务日志数据对第一业务的运行状态进行监控。

可以理解的是，本发明实施例中的监控可以为实时监控，也可以为非实时监控，具体可以根据实际需要进行设置，在此，本发明实施例不做具体限制。

示例的，在确定某一种业务是否需要被监控时，可以先判断m种业务中的每一种业务的业务日志数据中是否包括日志标签路由，若确定m种业务中存在某一个或者多个第一业务的业务日志数据包括第一日志标签路由，此时还不能确定该第一业务是需要被监控的业务，而是可以通过日志标签识别模块，将该第一日志标签路由与日志元数据中存储的需要监控的第一业务的预设标签路由进行匹配，若该第一日志标签路由与日志元数据中存储的需要监控的第一业务的预设标签路由匹配，说明该第一业务是需要被监控的业务，则可以根据该第一业务的业务日志数据对该第一业务的运行状态进行监控，从而实现对该第一业务的运行状态的监控。

可以理解的是，在判断m种业务中的每一种业务的业务日志数据中是否包括日志标签路由时，若确定m种业务中存在某一个或者多个第二业务的业务日志数据包括第二日志标签路由，但是该第二日志标签路由与日志元数据库中第二业务的预设标签路由不匹配，说明该第二业务不是需要被监控的业务，则将第二业务的业务日志数据存储至离线数据仓库中，以通过离线数据仓库对该第二业务的业务日志数据进行离线的统计分析。

当然，在判断m种业务中的每一种业务的业务日志数据中是否包括日志标签路由时，若m种业务中存在一个或者多个第三业务的业务日志数据根本不包括日志标签路由，在该种情况下，说明该第三业务不是需要被监控的业务，也无需再与日志元数据库中第三业务的预设标签路由进行匹配，而是直接将第三业务的业务日志数据存储至离线数据仓库中，以通过离线数据仓库对该第三业务的业务日志数据进行离线的统计分析。

可以理解的是，在上述描述中，当第一业务是需要被监控的业务时，可以根据该第一业务的业务日志数据对该第一业务的运行状态进行监控。在根据该第一业务的业务日志数据对该第一业务的运行状态进行监控时，可以根据第一业务的业务日志数据中的所有日志数据对该第一业务的运行状态进行监控；也可以根据第一业务的业务日志数据中的部分日志数据对该第一业务的运行状态进行监控。

示例的，在根据第一业务的业务日志数据中的部分日志数据对该第一业务的运行状态进行监控时，可以先确定第一业务的业务日志数据中需要被监控的部分日志数据。在确定第一业务的业务日志数据中需要被监控的部分日志数据时，由于日志元数据中预先存储有第一业务的预设标签路由与业务日志数据的预设字段之间的映射关系，这样在第一业务的业务日志数据中第一日志标签路由与日志元数据库中第一业务的预设标签路由匹配时，可以根据预设标签路由与业务日志数据的预设字段之间的映射关系，确定第一业务的业务日志数据中预设字段指示的部分日志数据，该预设字段指示的部分日志数据即为第一业务的业务日志数据中需要被监控的部分日志数据，这样就可以将日志数据中被监控的字段通过任务接入到实时数仓中，并根据该部分日志数据对第一业务的运行状态进行监控。

在对第一业务的运行状态进行监控，得到监控结果之后，就可以向工作人员输出相应的提示信息，即执行下述s203：

s203、根据监控结果输出提示信息。

示例的，在根据监控结果输出提示信息时，若监控结果指示第一业务的运行状态存在异常，则输出告警信息；告警信息用于指示第一业务的运行状态存在异常。当然，若监控结果指示第一业务的运行状态不存在异常，则输出正常提示信息；该正常提示信息用于指示第一业务的运行状态正常。

示例的，在向工作人员输出提示信息时，可以通过微信、邮件或者短信的方式输出提示信息，以便工作人员可以及时地获取到第一任务的运行状态。当然，在第一任务的运行状态存在异常时，为了便于工作人员快速查找到异常所在，还可以进一步输出异常日志明细数据，这样工作人员就可以根据该异常日志明细数据快速查找到第一业务的异常所在，为工作人员提供了查询依据。其中，异常日志明细数据包括第一任务的整体运行情况、成功次数、失败次数以及相关异常信息。可以理解的是，针对不同的业务告警需求，可以为其配置不同的告警策略，例如，不同的告警策略中的最大告警次数、告警级别，或者不同时段告警值不同。

由此可见，本发明实施例提供的业务的监控方法，在获取到m种业务中每一种业务的业务日志数据后，若m种业务中存在第一业务的业务日志数据包括第一日志标签路由，且第一日志标签路由与日志元数据库中第一业务的预设标签路由匹配，则根据第一业务的业务日志数据对第一业务的运行状态进行监控，并根据监控结果输出提示信息。与现有技术相比，无需工程师手动对每一种业务的日志数据进行配置，而是由于需要监控的业务的业务日志数据中标注有日志标签路由，使得服务器可以直接根据该日志标签路由在多种业务中确定需要监控的业务，从而提高了业务的监控效率。

基于图2所示的实施例，上述s202中，若m种业务中存在第一业务的业务日志数据包括第一日志标签路由，且第一日志标签路由与日志元数据库中第一业务的预设标签路由匹配，说明该第一业务为需要被监控的业务，则根据第一业务的业务日志数据对第一业务的运行状态进行监控。在实际应用过程中，可以先将第一业务的业务日志数据缓存在实时数据仓库中，通过从实时数据仓库中查找该第一业务的业务日志数据，并根据第一业务的业务日志数据对第一业务的运行状态进行监控。示例的，请参见图3所示，图3为本发明实施例提供的另一种业务的监控方法的流程示意图，该业务的监控方法还可以包括：

s301、通过n个任务进程将第一业务的业务日志数据缓存在实时数据仓库中。

其中，n为大于或者等于1的整数。示例的，实时数据仓库可以为实时分析引擎库。

结合上述s202中的相关描述，示例的，在确定第一业务为需要被监控的业务后，可以自动生成实时接入任务配置项，并基于该实时接入任务配置项自动生成该第一业务的n个任务进程，以通过该n个任务进程将该第一业务的业务日志数据缓存至实时分析引擎库中。

示例的，实时接入任务配置项可以包括时间列、维度列以及指标列。其中，时间列：druid集群是时间序列数据仓库，需要指定时间列，选取kafka集群的业务日志数据中某个字段作为时间列。维度列，kafka集群的业务日志数据中字段值较多，只需选择与实时需求相关的字段接入到druid集群中，无法将所有字段接入，以免造成资源的浪费，该维度列通常为字符串类型字段。维度列可用于多维分组统计。指标列，用于聚合与计算等操作，聚合字段为非必须项，可选择添加或不添加，该指标列通常为数值类型字段。

在通过该n个任务进程将该第一业务的业务日志数据缓存至实时分析引擎库中后，就可以从实时分析引擎库中查找该第一业务的业务日志数据，并根据第一业务的业务日志数据对第一业务的运行状态进行监控，即执行下述s302：

s302、从实时数据仓库中查找第一业务的业务日志数据，并根据第一业务的业务日志数据对第一业务的运行状态进行监控。

示例的，在自动生成该第一业务的n个任务进程后，通知服务器的监控模块自动部署实时查询调度工作流，并指示服务器的工作流调度引擎airflow从实时分析引擎库中查找该第一业务的业务日志数据，以通过自动分析系统(例如sparrow交互式分析系统)根据第一业务的业务日志数据对第一业务的运行状态进行监控分析，有效地简化监控业务操作步骤，这样就可以根据监控结果输出提示信息。其中，sparrow交互式分析系统为基于metabase的二次开发自研系统，可以更好地支持与实时分析引擎进行对接，研发和工作人员可通过sparrow交互式分析系统界面化交互式地查询异常日志明细数据，更直观地定位异常原因。

示例的，服务器的监控模块自动部署实时查询调度工作流，并指示服务器的工作流调度引擎airflow从实时分析引擎库中查找该第一业务的业务日志数据时，可以针对工作流调度引擎airflow的数据配置监控模块的告警逻辑。该告警逻辑可以包括以下配置项：任务标志、实时分析引擎、数据源、告警逻辑、窗口周期以及开始执行时间。其中，任务标志用于标识任务、以便于后续查找该任务；实时分析引擎用于对接多个实时分析引擎集群；数据源用于实施分析引擎中的数据源名称；告警逻辑通过sql编写，用于自动化提示数据源中含有的字段，校验查询逻辑执行的正确性；窗口周期用于定制任务执行周期与查询数据时间范围，分钟级别；开始执行时间用于指示任务开始时间。

可以看出，本发明实施例提供的业务的监控方法，与现有技术相比，无需工程师手动对每一种业务的日志数据进行配置，而是由于需要监控的业务的业务日志数据中标注有日志标签路由，使得服务器可以直接根据该日志标签路由在多种业务中确定需要监控的业务，从而提高了业务的监控效率。

需要说明的是，上述s301中，在通过n个任务进程将第一业务的业务日志数据缓存在实时数据仓库中时，该任务进程的个数n的取值不是一个固定值，而是随着任务进程的消费延迟变化而变化。示例的，服务器的延迟监控模块可以周期性采集n个任务进程中，每一个任务进程的消费延迟，得到n个任务进程各自的消费延迟，并计算n个任务进程的消费延迟的总和；若总和大于第一阈值，说明当前消费延迟较大，该n个任务进程无法满足业务的需求，需要通过更多的任务进程执行并行操作，以降低当前消费延迟，则可以增大n的取值，从而增多任务进程的数量；相反的，若总和小于第二阈值，且n大于或者等于2，说明当前消费延迟较小，当前n个任务进程足以满足业务的需求，为了降低多余的任务进程所占用的资源，可以减小n的取值，使得可以通过较少后的任务进程处理业务；当然，若总和大于第二阈值，且小于第一阈值，则说明前消费延迟合理，该n个任务进程刚好可以满足业务的需求，无需对任务进程的数量进行调整，即无需调整n的取值，从而实现了对任务进程的数量的灵活调整。其中，第一阈值大于第二阈值。

图4为本发明实施例提供的一种服务器40的结构示意图，示例的，请参见图4所示，该服务器40包括：

采集模块401，用于获取m种业务中每一种业务的业务日志数据；m为大于或者等于1的整数。

监控模块402，用于若m种业务中存在第一业务的业务日志数据包括第一日志标签路由，且第一日志标签路由与日志元数据库中第一业务的预设标签路由匹配，则根据第一业务的业务日志数据对第一业务的运行状态进行监控。

告警模块403，用于根据监控结果输出提示信息。

可选的，告警模块403，具体用于若监控结果指示第一业务的运行状态存在异常，则输出告警信息；告警信息用于指示第一业务的运行状态存在异常。

可选的，该服务器40还可以包括处理模块404。

处理模块404，用于若m种业务中存在第二业务的业务日志数据包括第二日志标签路由，且第二日志标签路由与日志元数据库中第二业务的预设标签路由不匹配，则将第二业务的第二业务日志数据存储至离线数据仓库中；离线数据仓库用于离线分析第二业务日志数据；若m种业务中存在第三业务的业务日志数据不包括日志标签路由，则将第三业务的业务日志数据存储至离线数据仓库中；离线数据仓库还用于离线分析第三业务的业务日志数据。

可选的，日志元数据库中存储有预设标签路由与业务日志数据的预设字段之间的映射关系。

监控模块402，具体用于第一日志标签路由与日志元数据库中第一业务的预设标签路由匹配，且根据预设标签路由与业务日志数据的预设字段之间的映射关系，确定第一业务的业务日志数据中预设字段指示的部分日志数据；并根据部分日志数据对第一业务的运行状态进行监控。

可选的，监控模块402，具体用于通过n个任务进程将第一业务的业务日志数据缓存在实时数据仓库中；n为大于或者等于1的整数；从实时数据仓库中查找第一业务的业务日志数据，并根据第一业务的业务日志数据对第一业务的运行状态进行监控。

可选的，处理模块404，还用于周期性采集n个任务进程中，每一个任务进程的消费延迟；并根据每一个任务进程的消费延迟，更新n的取值。

可选的，处理模块404，具体用于计算n个任务进程的消费延迟的总和；若总和大于第一阈值，则增大n的取值；若总和小于第二阈值，且n大于或者等于2，则减小n的取值；其中，第一阈值大于第二阈值。

本发明实施例所示的服务器40，可以执行上述任一附图所示的实施例中业务的监控方法的技术方案，其实现原理以及有益效果与业务的监控方法的实现原理及有益效果类似，此处不再进行赘述。

图5为本发明实施例提供的另一种服务器50的结构示意图，示例的，请参见图5所示，该服务器50可以包括存储器501和处理器502。

存储器501，用于存储计算机程序。

处理器502，用于读取存储器501存储的计算机程序，并根据所述存储器501中的计算机程序执行上述任一实施例所示的业务的监控方法。

可选地，存储器501既可以是独立的，也可以跟处理器502集成在一起。当存储器501是独立于处理器502之外的器件时，服务器还可以包括：总线，用于连接存储器501和处理器502。

可选地，本实施例还包括：通信接口，该通信接口可以通过总线与处理器502连接。处理器502可以控制通信接口来实现上述服务器的接收和发送的功能。

本发明实施例所示的服务器50，可以执行上述任一附图所示的实施例中业务的监控方法的技术方案，其实现原理以及有益效果与业务的监控方法的实现原理及有益效果类似，此处不再进行赘述。

本发明实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，执行如上述任一实施例所述的业务的监控方法，其实现原理以及有益效果与业务的监控方法的实现原理及有益效果类似，此处不再进行赘述。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所展示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元展示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本发明各个实施例方法的部分步骤。

应理解的是，上述处理器可以是中央处理单元(英文：centralprocessingunit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digitalsignalprocessor，简称：dsp)、专用集成电路(英文：applicationspecificintegratedcircuit，简称：asic)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速ram存储器，也可能还包括非易失性存储nvm，例如至少一个磁盘存储器，还可以为u盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(industrystandardarchitecture，isa)总线、外部设备互连(peripheralcomponent，pci)总线或扩展工业标准体系结构(extendedindustrystandardarchitecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本发明附图中的总线并不限定仅有一根总线或一种类型的总线。

上述计算机可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

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