CN108322350B

CN108322350B - 业务监控方法及装置和电子设备

Info

Publication number: CN108322350B
Application number: CN201810161148.1A
Authority: CN
Inventors: 陶宇田
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2018-02-27
Filing date: 2018-02-27
Publication date: 2021-06-01
Anticipated expiration: 2038-02-27
Also published as: CN108322350A

Abstract

本说明书实施例提供一种业务监控方法及装置和电子设备，业务场景标识收集系统收集业务场景标识，并将所述业务场景标识存储到通用日志系统关联的存储介质中；所述业务场景标识为发送给被监控业务的业务处理请求中携带的；所述通用日志系统根据所述存储介质中的业务场景标识，获取被监控业务响应业务处理请求的处理数据，并将所述处理数据关联业务场景标识后，生成相应的日志记录；日志采集系统采集所述通用日志系统中生成的被监控业务的日志记录；日志分析系统基于所述业务场景标识对所述日志记录中的处理数据进行处理，得到所述被监控业务中各个业务场景的监控数据。

Description

业务监控方法及装置和电子设备

技术领域

本说明书实施例涉及互联网技术领域，尤其涉及一种业务监控方法及装置和电子设备。

背景技术

随着互联网技术的不断发展，在类似互联网公司中，根据收集到的用户需求会不断推出新业务或者更新旧业务，从而提高用户体验。为了应对业务的快速迭代，互联网公司通常会提供一个统一供业务接入的服务平台。一般的，所述服务平台除了提供业务接入这一功能之外，还可以对这些业务进行监控。

现有技术中，针对每一个接入的业务，服务平台都需要配置一个监控规则，基于所述监控规则采集新业务的各项监控指标，进而达到对新业务进行监控预警的目的。可见，服务平台和接入的业务之间是强耦合的，不管是新接入业务还是旧业务的迭代，对于服务平台来说都需要进行一次监控规则的配置。然而随着不断接入新业务，以及旧业务迭代周期越来越短，频繁配置监控规则对于服务平台来说意味着增加额外开销，这些额外开销原本可以用于提供更好的服务，相对地也就降低了服务平台的性能。

发明内容

本说明书实施例提供的一种业务监控方法及装置和电子设备：

根据本说明书实施例的第一方面，提供一种业务监控方法，所述方法包括：

业务场景标识收集系统收集业务场景标识，并将所述业务场景标识存储到通用日志系统关联的存储介质中；所述业务场景标识为发送给被监控业务的业务处理请求中携带的；

所述通用日志系统根据所述存储介质中的业务场景标识，获取被监控业务响应业务处理请求的处理数据，并将所述处理数据关联业务场景标识后，生成相应的日志记录；

日志采集系统采集所述通用日志系统中生成的被监控业务的日志记录；

日志分析系统基于所述业务场景标识对所述日志记录中的处理数据进行处理，得到所述被监控业务中各个业务场景的监控数据。

可选的，所述基于所述业务场景标识对所述日志记录中的处理数据进行处理，得到所述被监控业务中各个业务场景的监控数据，具体包括：

根据所述日志记录中的业务场景标识，将所述日志记录按照业务场景标识进行划分；

基于设定的监控规则，根据各个业务场景标识对应日志记录中的处理数据，计算得到所述被监控业务中各个业务场景的监控数据。

可选的，所述处理数据至少包括处理请求的处理状态，所述处理状态包括成功或者失败；

所述基于设定的监控规则，根据各个业务场景标识对应日志记录中的处理数据，计算得到各个业务场景的监控数据，具体包括：

获取各个业务场景标识对应日志记录中的处理状态；

统计各个业务场景标识下，处理状态为失败的次数；

根据各个业务场景下所述失败的次数和日志记录的条数，计算出所述被监控业务中各个业务场景下处理请求的失败率。

可选的，所述方法还包括：

在所述失败率到达阈值时，生成所述被监控业务中失败率到达阈值的业务场景存在异常的预警信息。

可选的，所述处理数据至少包括处理请求的处理时长；

获取各个业务场景标识对应日志记录中的处理时长；

计算出所述被监控业务中各个业务场景标识下平均处理时长。

可选的，所述方法还包括：

在所述平均处理时长到达阈值的情况下，生成所述被监控业务中平均处理时长到达阈值的业务场景存在异常的预警信息。

可选的，所述采集所述通用日志系统中生成的被监控业务的日志记录，具体包括：

采集预设周期内所述通用日志系统中生成的被监控业务的日志记录。

可选的，所述方法还包括：

将所述被监控业务中各个业务场景的监控数据传输给可视化系统，所述可视化系统用于根据所述监控数据生成图表信息。

可选的，所述存储介质包括映射调试上下文。

根据本说明书实施例的第二方面，提供一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为实现如上述实施例中任一所述的业务监控方法。

本说明书实施例，通过解除服务平台与接入业务之间的耦合，并提供一套通用监控机制适用所有接入服务平台中的业务，从而保证服务平台在无需额外增加监控成本的情况下，实现业务监控。具体地，服务平台通过采集被监控业务针对业务处理请求的处理数据并关联业务场景标识，从而输出固定格式的日志记录；服务平台只需基于固定格式的日志记录进行分析处理，无需感知具体业务情况。

附图说明

图1是本说明书一实施例提供的实现业务监控的系统架构概念图；

图2是本说明书一实施例提供的服务平台的示意图；

图3是本说明书一实施例提供的业务监控方法的流程图；

图4是本说明书一实施例提供的日志记录的示意图；

图5是本说明书一实施例提供的业务监控装置的模块示意图。

具体实施方式

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

在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

如前所述，随着互联网技术的不断发展，在类似互联网公司中，根据收集到的用户需求会不断推出新业务或者更新旧业务，从而提高用户体验。为了应对业务的快速迭代，互联网公司通常会提供一个统一供业务接入的服务平台。一般的，所述服务平台除了提供业务接入这一功能之外，还可以对这些业务进行监控。

本说明书提供的一种业务监管方案，通过提供一套通用的监管机制，从而无需服务平台针对每一个接入业务都设置一套监管机制，如此服务平台无需额外增加开销以及不影响自身性能的情况下也可以应对大量业务的监控需求。

本说明书可以涉及一个或多个系统。以下请参考图1示出了本说明书中可以适用的示例性的系统架构概念图。所述系统架构概念图可以包括业务方、服务平台、用户。

所述业务方可以是指业务服务的提供方，例如提供推荐服务的推荐服务器、提供导航服务的导航服务器等。所述业务方可以将业务接入到服务平台，从而经由服务平台向用户提供业务服务。

用户可以是指业务服务的使用方，例如使用导航服务的用户的客户端。所述用户可以通过服务平台获取业务方提供的业务服务。

如图2所示的，所述服务平台可以包括业务场景标识收集系统和通用日志系统。其中，所述业务场景标识收集系统可以用于从被监控业务的业务处理请求解析出业务场景标识，并将所述业务场景标识进行存储。这些存储的业务场景标识可以供通用日志系统使用。具体地，通用日志系统可以记录包含业务处理请求的处理数据和业务场景标识的日志记录。所述服务平台还可以包括监控系统。所述监控系统可以用于获取预设周期内被监控业务的日志记录，并根据日志内容分析得出被监控业务的监控数据，以供工作人员查看。根据功能划分，所述监控系统可以分为：日志采集系统、日志分析系统。所述日志采集系统主要用于获取前述通用日志系统输出被监控业务的日志记录，并统一传输给日志分析系统。所述日志分析系统可以将日志采集系统获取的日志记录进行分析处理，从而得到被监控业务中各个业务场景的监控数据。在一种实施方式中，所述监控系统还可以包括可视化系统、预警系统等。所述可视化系统，可以根据日志分析系统计算出的监控数据，生成可视化数据。这样，工作人员可以更为直观的查看被监控业务的监控数据。所述预警系统，可以在被监控业务中业务场景的监控数据符合监控规则设定的异常情况时，直接将预警信息提供给工作人员，方便工作人员快速及时对异常的业务进行处理。

服务平台接收属于被监控业务的业务处理请求；所述业务处理请求至少包括用户标识和业务场景标识，所述被监控业务分为若干业务场景。

服务平台将所述被监控业务返回的根据所述业务场景标识匹配到的场景信息发送给所述用户标识对应的用户。

以下针对一个完整的业务处理流程加以说明：

用户可以向接入服务平台的业务方发起业务处理请求；通常该业务处理请求首先会发送到服务平台，由所述服务平台转发给对应的业务方；所述业务方可以响应所述业务处理请求，并返回业务场景标识相关的场景信息；所述返回的场景信息同样先到达服务平台，由所述服务平台发送给用户；最后用户接收并展示所述场景信息。

再结合实际例子便于用户理解，以新闻推荐业务为例。在新闻APP的页面中，所述页面根据新闻类型可以分为：热点、视频、国际、娱乐、体育等板块；这些板块名称就可以理解为业务场景标识。假设当前页面为热点板块，用户想要浏览体育板块就可以通过点击体育板块的按钮，从而向推荐系统(业务方)发起新闻获取请求；该新闻获取请求中携带有体育标识(业务场景标识)，该新闻获取请求经由服务平台转发给推荐系统，所述推荐系统从新闻库中获取体育新闻，所述体育新闻同样经服务平台返回给用户；从而当前页面就可以显示所述推荐系统返回的体育新闻。

需要说明的是，由于用户使用的终端显示能力有限，在有的实施例中，所述业务处理请求中还可以携带场景信息最大显示数目N。相应地，业务方只需返回N条场景信息。具体地，业务方可以根据业务处理请求中业务场景标识匹配相应的场景信息；从所述场景信息中筛选出N条场景信息并返回。所述筛选规则可以是人为制定的，例如优选时效性较高的场景信息、点击量或者阅读量较高的场景信息等。

以下可以结合图3所示的例子介绍本说明书一种实现业务监控的方法的实施例，如图3所示，该方法可以包括以下步骤：

步骤210：业务场景标识收集系统收集业务场景标识，并将所述业务场景标识存储到通用日志系统关联的存储介质中；所述业务场景标识为发送给被监控业务的业务处理请求中携带的。

步骤220：所述通用日志系统根据所述存储介质中的业务场景标识，获取被监控业务响应业务处理请求的处理数据，并将所述处理数据关联业务场景标识后，生成相应的日志记录。

如前述图1实施例所示，服务平台可以包括业务场景标识收集系统和通用日志系统。本步骤中，所述业务场景标识收集系统可以在服务平台接收到业务处理请求后，获取其中携带的业务场景标识。并可以存储所述业务场景标识。为了便于后续通用日志系统的操作，可以将所述业务场景标识存储到底层日志系统可以直接识别的存储介质中。例如，可以将业务场景标识存储到日志系统(如log4j)可以识别的MDC(Mapped Diagnostic Context，映射调试上下文)中。所述MDC是日志系统提供的一种在多线程条件下记录日志的机制。一般的，一个用户请求可能有多个不同的线程来进行处理，例如应用服务器(Web服务器)可能会创建一个新的线程处理请求，也可能从线程池中复用已有线程处理请求，因此多线程下如何区分不同用户所对应的日志较为困难，当需要追踪某个用户在系统中的相关日志时，也会变得很困难。为MDC就可以解决多线程下无法区分日志归属的问题。因为，MDC可以将执行线程与用户进行绑定，并且MDC中记录的内容可以被同一线程中执行的代码所访问。当前线程的子线程会继承其父线程中的MDC的内容。当需要记录日志时，只需要从MDC中获取所需的信息即可。

值得一提的是，业务场景标识收集系统存储业务场景标识，无需通知用户或者业务方，这样可以实现业务无感知。业务无感知的优点在于，业务无需关注服务平台额外做的处理。

其中，所述通用日志系统，可以采集被监控业务针对业务处理请求的处理数据，并将所述处理数据与业务场景标识关联后，输出包含所述处理数据和业务场景标识的日志记录。

其中，所述处理数据可以包括：包括处理请求的处理状态，所述处理状态包括成功或者失败；处理请求的处理时长等。

请参考图4所示的日志记录的示意图，图4中每一行都代表了输出的一条日志记录，对应一次业务处理请求；其中audit_log后面的第一列31表示业务场景标识；recommend后面的第一列32表示本次业务处理请求的处理状态(ERRPR表示失败、SUCCESS表示成功)；recommend后面的第二列33表示本次业务处理请求的处理时长。

步骤230：日志采集系统采集所述通用日志系统中生成的被监控业务的日志记录。

具体地，所述日志采集系统可以采集预设周期内所述通用日志系统中生成的被监控业务的日志记录。

在实际应用中，服务平台可以周期性地对被监控业务进行分析处理，得到被监控中各个业务场景的监控数据。一般的，服务平台可以设置一个定时器，当所述定时器到达预设时长后，就可以获取一个预设周期内输出的日志记录。所述预设周期可以是预先设置的一个时长，例如，1天，1周，1月等。

如图4所示的日志记录示意图中，每一行日志记录的第一列34可以表示日志记录的生成时刻。服务平台可以根据所述生成时刻确定日志记录是否位于周期内。

举例说明，假设预设周期为1天，上一周期为2018年1月1日至2018年1月2日，则本周期为2018年1月2日至2018年1月3日，即定时器在2018年1月3日24点整时到达预设时长，从而触发服务平台获取生成时刻在2018年1月2日0点至2018年1月3日24点之间的日志记录。

步骤240：日志分析系统基于所述业务场景标识对所述日志记录中的处理数据进行处理，得到所述被监控业务中各个业务场景的监控数据。

本实施例中，所述步骤250，具体可以包括：

A1：日志分析系统根据所述日志记录中的业务场景标识，将所述日志记录按照业务场景标识进行划分；

A2：所述日志分析系统基于设定的监控规则，根据各个业务场景标识对应日志记录中的处理数据，计算得到所述被监控业务中各个业务场景的监控数据。

在实际应用中，如前所述被监控业务可以分为若干业务场景；因此对于获取到的被监控业务的日志记录；需要根据业务场景标识进行划分。

依然以新闻推荐为例，假设业务场景可以分为:娱乐、体育、教育、军事。那么对于新闻推荐业务的日志记录，需要分为4部分：

娱乐标识的日志记录；

体育标识的日志记录；

教育标识的日志记录；

军事标识的日志记录。

在一种实现方式中，所述处理数据至少包括处理请求的处理状态，所述处理状态包括成功或者失败；

所述步骤A2：所述日志分析系统基于设定的监控规则，根据各个业务场景标识对应日志记录中的处理数据，计算得到各个业务场景的监控数据，具体包括：

所述日志分析系统获取各个业务场景标识对应日志记录中的处理状态；

所述日志分析系统统计各个业务场景标识下，处理状态为失败的次数；

所述日志分析系统根据各个业务场景下所述失败的次数和日志记录的条数，计算出所述被监控业务中各个业务场景下处理请求的失败率。

该实施例中，如前所述处理状态可以包括成功或者失败。依然沿用上一示例，所述日志分析系统依次对娱乐标识、体育标识、教育标识、军事标识的日志记录进行处理，得到监控数据。以体育标识的日志记录为例加以说明(另3种标识的处理过程类似)：

日志分析系统获取体育标识对应日志记录中的处理状态；

统计所述体育标识下，处理状态为失败的次数假设为N；

根据所述体育标识下失败的次数N和日志记录的条数M，通过公式失败率＝N/M，计算出新闻推荐业务中体育板块中，获取体育新闻请求的失败率。

其中，失败率可以反映出被监控业务处理业务请求能力的强弱；通常，如果失败率过高，说明被监控业务针对大部分用户的业务处理请求都没有成功响应，那么所述被监控业务存在问题是大概率事件。

为此，所述方法还可以包括：

该实施例中，预警系统可以及时发现异常的被监控业务，并生成该被监控业务中失败率过高的业务场景的预警信息，方便工作人员快速定位异常业务的业务场景并可以及时处理问题。

在另一种实现方式中，所述处理数据至少包括处理请求的处理时长；

所述日志分析系统获取各个业务场景标识对应日志记录中的处理时长；

所述日志分析系统计算出所述被监控业务中各个业务场景标识下平均处理时长。

该实施例中，依然沿用上一示例，所述日志分析系统依次对娱乐标识、体育标识、教育标识、军事标识的日志记录进行处理，得到监控数据。以体育标识的日志记录为例加以说明(另3种标识的处理过程类似)：

日志分析系统获取体育标识对应日志记录中的处理时长；

计算出所述体育标识下平均处理时长，包括统计体育标识下素有日志记录中处理时长的总和，再将总和除以体育标识下日记记录的数量，得出体育标识下的平均处理时长。

其中，平均处理时长可以反映出被监控业务响应业务请求所需时间的长短。通常，如果平均处理时长过长，说明被监控业务针对大部分用户的业务处理请求都没有及时响应，那么所述被监控业务存在问题是大概率事件。

为此，所述方法还可以包括：

该实施例中，预警系统可以及时发现异常的被监控业务，并生成该被监控业务中平均处理时长过长的业务场景的预警信息，方便工作人员快速定位异常业务的业务场景并可以及时处理问题。

在图3所示实施例的基础上，所述方法还包括：

将所述被监控业务中各个业务场景的监控数据传输给可视化系统。

该实施例中，所述可视化系统用于根据所述监控数据生成图表信息，所述图表信息例如可以包括柱状图、折线图、三维图等。通过可视化系统，工作人员可以直观的获知被监控业务中各个业务场景的监控数据，从而便于工作人员监控及时发现异常。

与前述业务监控方法实施例相对应，本说明书还提供了业务监控装置的实施例。所述装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，本说明书业务监控装置所在设备的一种硬件结构可以包括处理器、网络接口、内存以及非易失性存储器之外，实施例中装置所在的设备通常根据该业务监控实际功能，还可以包括其他硬件，对此不再赘述。

请参见图5，为本说明书一实施例提供的业务监控装置的模块图，所述装置对应了图3所示实施例，所述装置包括：

第一采集单元510，业务场景标识收集系统收集业务场景标识，并将所述业务场景标识存储到通用日志系统关联的存储介质中；所述业务场景标识为发送给被监控业务的业务处理请求中携带的；

生成单元520，所述通用日志系统根据所述存储介质中的业务场景标识，获取被监控业务响应业务处理请求的处理数据，并将所述处理数据关联业务场景标识后，生成相应的日志记录；

第二采集单元530，日志采集系统采集所述通用日志系统中生成的被监控业务的日志记录；

处理单元540，日志分析系统基于所述业务场景标识对所述日志记录中的处理数据进行处理，得到所述被监控业务中各个业务场景的监控数据。

可选的，所述处理单元540，具体包括：

划分日志子单元，根据所述日志记录中的业务场景标识，将所述日志记录按照业务场景标识进行划分；

分析数据子单元，基于设定的监控规则，根据各个业务场景标识对应日志记录中的处理数据，计算得到所述被监控业务中各个业务场景的监控数据。

所述分析数据子单元，具体包括：

获取子单元，获取各个业务场景标识对应日志记录中的处理状态；

统计子单元，统计各个业务场景标识下，处理状态为失败的次数；

计算子单元，根据各个业务场景下所述失败的次数和日志记录的条数，计算出所述被监控业务中各个业务场景下处理请求的失败率。

可选的，所述装置还包括：

预警子单元，在所述失败率到达阈值时，生成所述被监控业务中失败率到达阈值的业务场景存在异常的预警信息。

可选的，所述处理数据至少包括处理请求的处理时长；

所述分析数据子单元，具体包括：

获取子单元，获取各个业务场景标识对应日志记录中的处理时长；

计算子单元，计算出所述被监控业务中各个业务场景标识下平均处理时长。

可选的，所述装置还包括：

预警子单元，在所述平均处理时长到达阈值的情况下，生成所述被监控业务中平均处理时长到达阈值的业务场景存在异常的预警信息。

可选的，所述第二采集单元530，具体包括：

日志采集系统可以采集预设周期内所述通用日志系统中生成的被监控业务的日志记录。

可选的，所述装置还包括：

传输数据单元，将所述被监控业务中各个业务场景的监控数据传输给可视化系统，所述可视化系统用于根据所述监控数据生成图表信息。

可选的，所述存储介质包括映射调试上下文。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上图5描述了业务监控装置的内部功能模块和结构示意，其实质上的执行主体可以为一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

获取各个业务场景标识对应日志记录中的处理状态；

统计各个业务场景标识下，处理状态为失败的次数；

可选的，还包括：

可选的，所述处理数据至少包括处理请求的处理时长；

获取各个业务场景标识对应日志记录中的处理时长；

可选的，还包括：

可选的，所述日志采集系统采集所述通用日志系统中生成的被监控业务的日志记录，具体包括：

可选的，还包括：

可选的，所述存储介质包括映射调试上下文。

在上述电子设备的实施例中，应理解，该处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，而前述的存储器可以是只读存储器(英文：read-only memory，缩写：ROM)、随机存取存储器(英文：random access memory，简称：RAM)、快闪存储器、硬盘或者固态硬盘。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于电子设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。

应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。

Claims

1.一种业务监控方法，应用于对所有接入的业务进行监控的服务平台，所述服务平台包括业务场景标识收集系统、通用日志系统、日志采集系统和日志分析系统；所述方法包括：

所述通用日志系统根据所述存储介质中的业务场景标识，获取不同的被监控业务响应业务处理请求的处理数据，并将所述处理数据关联业务场景标识后，生成相应固定格式的日志记录；

2.根据权利要求1所述的方法，所述基于所述业务场景标识对所述日志记录中的处理数据进行处理，得到所述被监控业务中各个业务场景的监控数据，具体包括：

3.根据权利要求2所述的方法，所述处理数据至少包括业务处理请求的处理状态，所述处理状态包括成功或者失败；

所述基于设定的监控规则，根据各个业务场景标识对应日志记录中的处理数据，计算得到所述被监控业务中各个业务场景的监控数据，具体包括：

获取各个业务场景标识对应日志记录中的处理状态；

统计各个业务场景标识下，处理状态为失败的次数；

根据各个业务场景下所述失败的次数和日志记录的条数，计算出所述被监控业务中各个业务场景下业务处理请求的失败率。

4.根据权利要求3所述的方法，所述方法还包括：

5.根据权利要求2所述的方法，所述处理数据至少包括业务处理请求的处理时长；

获取各个业务场景标识对应日志记录中的处理时长；

6.根据权利要求5所述的方法，所述方法还包括：

7.根据权利要求1所述的方法，所述采集所述通用日志系统中生成的被监控业务的日志记录，具体包括：

8.根据权利要求1所述的方法，所述方法还包括：

9.根据权利要求1所述的方法，所述存储介质存储映射调试上下文。

10.一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述可执行指令，以实现上述权利要求1-7中任一项所述的方法。