一种监控预警方法及装置

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种监控预警方法及装置。

背景技术

服务开放平台致力于将人工智能、大数据分析等领域的共性技术进行集中、高效地运维运营，并以API(Application Programming Interface，应用程序编程接口)形式对外开放共享，可有效解决基础能力重复开发、研发资源浪费、耗费人力进行服务运维等问题。服务开放平台的核心是API网关，API网关负责接管所有API调用的入口流量，将用户请求转发给后端的服务。API网关同时提供鉴权认证、流量限制、权限控制、熔断、协议转换、日志及监控等功能。

现有服务开放平台可提供多种对服务调用情况进行监控预警的方案，如利用API网关进行健康检查、自动熔断，基于网关历史日志提供全方位的统计分析，并支持用户自定义预警级别。通过用户自定义预警功能，运维人员即可在平台界面分别对API的访问量、流量、响应时间、错误码等信息设置阈值，当指标达到设定阈值时，平台可通过向运维人员发送邮件、短信进行预警。此方案由运维人员根据业务领域知识、经验以及对服务性能的了解，自行设定阈值，但实际上运维人员存在一定局限性，并不总能做到对阈值的合理预估。

因此，目前尚缺乏一种客观的对API调用过程中是否需要发出预警的判断方法。

本申请提供一种监控预警方法及装置，用以动态化地、客观地确定是否要发出针对使用中的API的告警信息。

第一方面，本申请实施例提供一种监控预警方法，该方法包括：获取应用程序编程接口API在监控时段的调用日志；获取所述API的调用画像，所述调用画像是根据所述API在所述监控时段之前的历史时段的调用日志进行多维度分析后生成的；在所述监控时段的调用日志不符合所述调用画像时，发送针对所述API的告警信息。

基于该方案，在对API调用的过程中，通过获取API在监控时段的调用日志，并根据对API的调用画像的获取，从而可在监控时段的调用日志不符合调用画像时而发出针对该API的告警信息。该方式中由于API的调用画像是基于监控时段之前的历史时段的调用日志进行多维度分析后生成的，因此API的调用画像可以随着时间的推移而不断进行更新，从而可以更好的满足对API的调用情况进行监控。

在一种可能实现的方法中，所述调用画像是根据所述API在所述监控时段之前的历史时段的调用日志进行多维度分析后生成的，包括：针对各预设频度中的任一预设频度，从所述历史时段的调用日志中确定所述预设频度下各维度指标的第一指标值；根据所述预设频度下的各维度指标的第一指标值，通过机器学习方式，确定所述调用画像。

基于该方案，通过多个预设频度来对历史时段的调用日志进行分析，且针对每一个预设频度，确定历史时段的调用日志在该预设频度下的各维度指标的指标值，并对该些不同维度指标的指标值使用机器学习的方式进行训练，从而确定API的调用画像，该方式中由于调用画像是通过对各维度指标的指标值进行机器学习得到的，因为可以作为对API在实际调用过程中的调用状态进行预测的预测值，从而在对监控时段的调用日志进行指标值的分析时，可以结合API的调用画像来确定对API的调用是否发生异常。

在一种可能实现的方法中，所述各预设频度包括每天的同一预设时段及每周同一天的同一预设时段；所述各维度指标包括以下至少一项：预设时段内对API的调用总次数、预设时段内API调用请求与返回结果的字节数总和、预设时段内从对API开始调用到得到响应的时间总长度、预设时段内响应码为正确的调用次数与所述调用总次数的比值。

基于该方案，在对历史时段的调用日志进行机器学习时，通过将每天的同一预设时段以及每周同一天的同一预设时段分别作为训练的维度，如此可以确定监控时段的调用日志是否符合每天的训练维度对应的调用画像，以及确定监控时段的调用日志是否符合每周同一天的训练维度对应的调用画像，从而结合监控时段的调用日志在这两种训练维度下的调用画像中的符合程度来作出是否发出告警信息的行为；以及，通过将访问量、流量、延迟和正确率作为对调用日志的评价指标，从而可以准确地对API的调用情况进行精准、客观的刻画。

在一种可能实现的方法中，通过如下方式确定所述监控时段的调用日志是否符合所述调用画像，包括：确定所述监控时段的调用日志在各预设频度下的各维度指标的第二指标值；确定所述第二指标值是否符合通过所述第一指标值构建的所述调用画像。

基于该方案，通过对监控时段的调用日志进行数据分析，确定它在多个预设频度下的各维度指标的指标值，并将计算得到的指标值与调用画像中的指标值的预测值进行比较，从而可以直观地判断是否真的要发出针对使用中的API的告警信息，若确定发出，则在通过向运维人员发送告警信息后，可以由运维人员来对该API实施一定的防护措施，以保证API的对外服务的性能。

在一种可能实现的方法中，所述方法还包括：在所述监控时段的调用日志符合所述调用画像时，根据所述监控时段的调用日志更新所述调用画像。

基于该方案，基于符合调用画像的监控时段的调用日志来对现有的调用画像进行更新，从而可以保证始终有最新、也是相对最为准确的调用画像，并用于对后续的监控时段的调用日志进行实时分析。

在一种可能实现的方法中，所述获取应用程序编程接口API在监控时段的调用日志，包括：通过消息队列获取所述API在监控时段的调用日志；通过流式计算引擎确定所述监控时段的调用日志是否符合所述调用画像。

基于该方案，在对监控时段的调用日志进行分析时，可以将用于数据分析的该监控时段的调用日志临时存储于消息队列中，如此可以在监控时段到达的时刻点从消息队列中对存储其中的调用日志进行提取并分析；以及，可以使用流式计算引擎来对存储在消息队列中的调用日志进行提取并分析，由于流式计算引擎具有实时计算的特点，因此在确定监控时段的调用日志是否符合调用画像时，具有快速处理数据的优点。

在一种可能实现的方法中，所述发送针对所述API的告警信息，包括：通过可视化界面对所述API在所述监控时段的所述第二指标值进行展示；所述可视化界面显示所述API的历史告警信息记录。

基于该方案，在确定监控时段的第二指标值不符合调用图像时，通过可视化界面来对该些各个维度指标下的第二指标值进行直观的展示，且该可视化界面中还会显示有API的历史告警信息的记录，因此接收到告警信息的运维人员可以基于历史告警信息和本次的第二指标值来综合判定是否要对本次的告警采取行动，以及若采取行动，确定所要采取的行动的具体内容。

第二方面，本申请实施例提供一种监控预警装置，该装置包括：调用日志获取单元，用于获取应用程序编程接口API在监控时段的调用日志；调用画像获取单元，用于获取所述API的调用画像，所述调用画像是根据所述API在所述监控时段之前的历史时段的调用日志进行多维度分析后生成的；处理单元，用于在所述监控时段的调用日志不符合所述调用画像时，发送针对所述API的告警信息。

基于该方案，在对API调用的过程中，通过获取API在监控时段的调用日志，并根据对API的调用画像的获取，从而可在监控时段的调用日志不符合调用画像时而发出针对该API的告警信息。该方式中由于API的调用画像是基于监控时段之前的历史时段的调用日志进行多维度分析后生成的，因此API的调用画像可以随着时间的推移而不断进行更新，从而可以更好的满足对API的调用情况进行监控。

在一种可能实现的方法中，该装置还包括调用画像生成单元；所述调用画像生成单元，用于针对各预设频度中的任一预设频度，从所述历史时段的调用日志中确定所述预设频度下各维度指标的第一指标值；根据所述预设频度下的各维度指标的第一指标值，通过机器学习方式，确定所述调用画像。

基于该方案，通过多个预设频度来对历史时段的调用日志进行分析，且针对每一个预设频度，确定历史时段的调用日志在该预设频度下的各维度指标的指标值，并对该些不同维度指标的指标值使用机器学习的方式进行训练，从而确定API的调用画像，该方式中由于调用画像是通过对各维度指标的指标值进行机器学习得到的，因为可以作为对API在实际调用过程中的调用状态进行预测的预测值，从而在对监控时段的调用日志进行指标值的分析时，可以结合API的调用画像来确定对API的调用是否发生异常。

在一种可能实现的方法中，所述各预设频度包括每天的同一预设时段及每周同一天的同一预设时段；所述各维度指标包括以下至少一项：预设时段内对API的调用总次数、预设时段内API调用请求与返回结果的字节数总和、预设时段内从对API开始调用到得到响应的时间总长度、预设时段内响应码为正确的调用次数与所述调用总次数的比值。

基于该方案，在对历史时段的调用日志进行机器学习时，通过将每天的同一预设时段以及每周同一天的同一预设时段分别作为训练的维度，如此可以确定监控时段的调用日志是否符合每天的训练维度对应的调用画像，以及确定监控时段的调用日志是否符合每周同一天的训练维度对应的调用画像，从而结合监控时段的调用日志在这两种训练维度下的调用画像中的符合程度来作出是否发出告警信息的行为；以及，通过将访问量、流量、延迟和正确率作为对调用日志的评价指标，从而可以准确地对API的调用情况进行精准、客观的刻画。

在一种可能实现的方法中，所述处理单元，具体用于确定所述监控时段的调用日志在各预设频度下的各维度指标的第二指标值；确定所述第二指标值是否符合通过所述第一指标值构建的所述调用画像。

基于该方案，通过对监控时段的调用日志进行数据分析，确定它在多个预设频度下的各维度指标的指标值，并将计算得到的指标值与调用画像中的指标值的预测值进行比较，从而可以直观地判断是否真的要发出针对使用中的API的告警信息，若确定发出，则在通过向运维人员发送告警信息后，可以由运维人员来对该API实施一定的防护措施，以保证API的对外服务的性能。

在一种可能实现的方法中，该装置还包括调用画像更新单元；所述调用画像更新单元，用于在所述监控时段的调用日志符合所述调用画像时，根据所述监控时段的调用日志更新所述调用画像。

基于该方案，基于符合调用画像的监控时段的调用日志来对现有的调用画像进行更新，从而可以保证始终有最新、也是相对最为准确的调用画像，并用于对后续的监控时段的调用日志进行实时分析。

在一种可能实现的方法中，所述调用日志获取单元，具体用于通过消息队列获取所述API在监控时段的调用日志；所述处理单元，具体用于通过流式计算引擎确定所述监控时段的调用日志是否符合所述调用画像。

基于该方案，在对监控时段的调用日志进行分析时，可以将用于数据分析的该监控时段的调用日志临时存储于消息队列中，如此可以在监控时段到达的时刻点从消息队列中对存储其中的调用日志进行提取并分析；以及，可以使用流式计算引擎来对存储在消息队列中的调用日志进行提取并分析，由于流式计算引擎具有实时计算的特点，因此在确定监控时段的调用日志是否符合调用画像时，具有快速处理数据的优点。

在一种可能实现的方法中，所述处理单元，具体用于通过可视化界面对所述API在所述监控时段的所述第二指标值进行展示；所述可视化界面显示所述API的历史告警信息记录。

基于该方案，在确定监控时段的第二指标值不符合调用图像时，通过可视化界面来对该些各个维度指标下的第二指标值进行直观的展示，且该可视化界面中还会显示有API的历史告警信息的记录，因此接收到告警信息的运维人员可以基于历史告警信息和本次的第二指标值来综合判定是否要对本次的告警采取行动，以及若采取行动，确定所要采取的行动的具体内容。

第三方面，本申请实施例提供了一种计算设备，包括：

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

处理器，用于调用所述存储器中存储的计算机程序，按照获得的程序执行如第一方面任一所述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序用于使计算机执行如第一方面任一所述的方法。

附图说明

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

图1为本申请实施例提供的一种监控预警方法；

图2为本申请实施例提供的一种API监控预警架构图；

图3为本申请实施例提供的一种监控预警装置；

图4为本申请实施例提供的一种计算设备的示意图。

具体实施方式

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

目前，用户通过服务开放平台调用API，则可以将自身发出的服务请求转发至后端服务，同时，服务开放平台可以获取到本次调用的请求、响应结果日志。其中，对可提供调用服务的API的调用日志进行多维度分析以确定API的性能，以保证API始终能以一种高效的状态来对外提供服务的接口，这具有非常重要的意义。然而，在对API的性能进行确定时，主要是由技术人员主观、简单地依据API在某次时候的指标值来作为告警时候的阈值，因此该方式无法自动化、且全面客观的来评价API的运行状态。

基于上述技术问题，本申请实施例提供一种监控预警方法，如图1所示，该方法包括以下步骤：

步骤101，获取应用程序编程接口API在监控时段的调用日志。

在本步骤中，通过获取API在监控时段的调用日志，则可以对该监控时段的调用日志进行数据分析，以确定该监控时段的调用日志在各维度指标下的实际指标值。

步骤102，获取所述API的调用画像。所述调用画像是根据所述API在所述监控时段之前的历史时段的调用日志进行多维度分析后生成的。

在本步骤中，所述调用画像是根据所述API在所述监控时段之前的历史时段的调用日志进行多维度分析后生成的。

由于服务开放平台中可包括多个API，不同的API，用户对它们的调用情况不一定相同，因此，在对服务开放平台中的某一个API的服务性能进行确定时，可获取该API在监控时段的调用日志以及该API的调用画像，以通过将该API在监控时段的调用日志与调用画像进行比较，从而就可以确定出API的服务性能如何。其中，在得到API的调用画像时，通过对该API在历史时段的调用日志进行数据处理，以得到用于评价该API服务性能的各维度指标在监控时刻下的预测指标值，基于各预测指标值从而得到该API的调用画像。

步骤103，在所述监控时段的调用日志不符合所述调用画像时，发送针对所述API的告警信息。

在本步骤中，对于研究对象为监控时段的调用日志，通过将该监控时段的调用日志与API的调用画像进行比较，具体可为针对评价该API服务性能的各维度指标，通过将该监控时段的调用日志对应的实际指标值与调用画像所确定的、该监控时段的预测指标值进行比较，并将实际指标值不满足预测指标值的情况定义为该API的服务性能欠佳，因此可通过短信、邮件等方式向运维人员发送关于该API的告警信息，以提示运维人员对服务开放平台的该API的服务状态进行检查，确定是否真的有必要对该API采取限制性行为，以保证API对外提供服务的稳定性与可靠性。

基于该方案，在对API调用的过程中，通过获取API在监控时段的调用日志，并根据对API的调用画像的获取，从而可在监控时段的调用日志不符合调用画像时而发出针对该API的告警信息。该方式中由于API的调用画像是基于监控时段之前的历史时段的调用日志进行多维度分析后生成的，因此API的调用画像可以随着时间的推移而不断进行更新，从而可以更好的满足对API的调用情况进行监控。

以下将结合示例对上述一些步骤进行详细说明。

在上述步骤101的一个实施中，通过消息队列获取所述API在监控时段的调用日志。比如，可将监控时段设置为1小时，或者其他时长，本申请不做具体限定，作为示例，本申请实施例中将监控时段设置为1小时；然后对于服务开放平台中的每一个API来说，可通过消息队列Kafka来对该API的调用日志进行记录，如以1小时为周期，Kafka可以对这1小时内的、对该API的调用请求进行一一记录。

在上述步骤102的一个实施中，所述调用画像是根据所述API在所述监控时段之前的历史时段的调用日志进行多维度分析后生成的，包括：针对各预设频度中的任一预设频度，从所述历史时段的调用日志中确定所述预设频度下各维度指标的第一指标值；根据所述预设频度下的各维度指标的第一指标值，通过机器学习方式，确定所述调用画像。

在本申请的某些实施中，所述各预设频度包括每天的同一预设时段及每周同一天的同一预设时段；所述各维度指标包括以下至少一项：预设时段内对API的调用总次数、预设时段内API调用请求与返回结果的字节数总和、预设时段内从对API开始调用到得到响应的时间总长度、预设时段内响应码为正确的调用次数与所述调用总次数的比值。

在对服务开放平台中的API的服务状态进行评估时，可以使用一些指标来对其进行评价，如访问量、流量、延迟和正确率；此外还考虑到每天的不同时段的API的服务状态可能存在差异，比如白天用户对API的调用请求比较多，而在夜间的时候用户对API的调用请求比较少，以及每周中的不同天的条件下，API的服务状态也可能存在差异，比如工作日期间的用户对API的调用请求比较多，而在周末的时候用户对API的调用请求比较少，因此，本申请实施例提供以下两种方式来确定API的调用画像。

方式1、基于时间滑动的历史时段的调用日志来确定API的调用画像。

例如，针对服务开放平台中的API_1，设它投入使用以来已经经历过了140天，并分别记为第1天、第2天、第3天……第140天，数据库已经存储有这140天中的每一天的调用日志。此时，设以10天为一个训练周期，并且以1小时为一个预设时段，则可以通过对第1天的0-1时段、第2天的0-1时段、第3天的0-1时段……第10天的0-1时段的调用日志，分别从访问量、流量、延迟和正确率等多个维度进行机器学习，从而针对每一个维度，可以得到一个预测指标值，然后针对任一个维度的预测指标值，通过将其与第11天的0-1时段的同一维度的实际指标值进行比较，确定二者之间的差距，并基于差距来对第2天的0-1时段、第3天的0-1时段、第4天的0-1时段……第11天的0-1时段的调用日志进行机器学习，如此循环往复，直到满足机器学习的训练精度，从而，可以使用第131天的0-1时段、第132天的0-1时段、第133天的0-1时段……第140天的0-1时段的调用日志来对第141天的0-1时段在各个维度下的指标值进行预测，然后针对同一维度，通过比较第141天的0-1时段的实际指标值与预测指标值，确定是否发出针对API_1的告警信息。这里不再一一描述每天当中的除去0-1时段之外的其他时段的情形的例子。

除了上述的基于每天的调用日志来对API_1的服务状态进行评估的方法，还同时可以包括：设以5周为一组训练数据，同样设以1小时为一个预设时段，则通过对第1周的星期一的0-1时段、第2周的星期一的0-1时段……第5周的星期一的0-1时段的调用日志，分别从访问量、流量、延迟和正确率等多个维度进行机器学习，从而针对每一个维度，可以得到一个预测指标值，然后针对任一个维度的预测指标值，通过将其与第6周的星期一的0-1时段的同一维度的实际指标值进行比较，确定二者之间的差距，并基于差距来对第2周的星期一的0-1时段、第3周的星期一的0-1时段……第6周的星期一的0-1时段的调用日志进行机器学习，如此循环往复，直到满足机器学习的训练精度，从而可以使用第16周的星期一的0-1时段、第17周的星期一的0-1时段……第20周的星期一的0-1时段的调用日志来对第21周的星期一0-1时段在各个维度下的指标值进行预测，然后针对同一维度，通过比较第21周的星期一0-1时段的实际指标值与预测指标值，确定是否发出针对API_1的告警信息。这里不再一一描述每天当中的0-1时段之外的其他时段的情形的例子。

方式2、基于全量的历史时段的调用日志来确定API的调用画像。

例如，针对服务开放平台中的API_1，设它投入使用以来已经经历过了140天(共20周)，并分别记为第1天、第2天、第3天……第140天，数据库已经存储有这140天中的每一天的调用日志。此时，设通过对第1天的0-1时段、第2天的0-1时段、第3天的0-1时段……第50天的0-1时段的调用日志，分别从访问量、流量、延迟和正确率等多个维度进行机器学习，从而针对每一个维度，可以得到一个预测指标值，然后针对任一个维度的预测指标值，通过将其与第51天的0-1时段的同一维度的实际指标值进行比较，确定二者之间的差距，并基于差距来对第1天的0-1时段、第2天的0-1时段、第3天的0-1时段……第50天的0-1时段及第51天的0-1时段的调用日志进行机器学习，来对第52天的0-1时段在各个维度下的指标值进行预测，如此循环往复，直到满足机器学习的训练精度，从而可以使用第1天的0-1时段、第2天的0-1时段、第3天的0-1时段……一直第140天的0-1时段的调用日志来对第141天的0-1时段在各个维度下的指标值进行预测，然后针对同一维度，通过比较第141天的0-1时段的实际指标值与预测指标值，确定是否发出针对API_1的告警信息。这里不再一一描述每天当中的除去0-1时段之外的其他时段的情形的例子。

除了上述的基于每天的调用日志来对API_1的服务状态进行评估的方法，还同时可以包括：设通过对第1周的星期一的0-1时段、第2周的星期一的0-1时段……第10周的星期一的0-1时段的调用日志，分别从访问量、流量、延迟和正确率等多个维度进行机器学习，从而针对每一个维度，可以得到一个预测指标值，然后针对任一个维度的预测指标值，通过将其与第11周的星期一的0-1时段的同一维度的实际指标值进行比较，确定二者之间的差距，并基于差距来对第1周的星期一的0-1时段、第2周的星期一的0-1时段……第10周的星期一的0-1时段及第11周的星期一的0-1时段的调用日志进行机器学习，来对第12周的星期一的0-1时段在各个维度下的指标值进行预测，如此循环往复，直到满足机器学习的训练精度，从而可以使用第1周的星期一的0-1时段、第2周的星期一的0-1时段……一直到第20周的星期一的0-1时段的调用日志来对第21周的星期一的0-1时段在各个维度下的指标值进行预测，然后针对同一维度，通过比较第21周的星期一的0-1时段的实际指标值与预测指标值，确定是否发出针对API_1的告警信息。这里不再一一描述每天当中的除去0-1时段之外的其他时段的情形的例子。

说明的是，上述方式1和方式2中的无论哪种方式，通过对各个维度的实际指标值与预测指标值进行比较，但凡其中的一个维度的实际指标值不满足该维度下的预测指标值，都需要以短信或者邮件的形式向运维人员发送告警信息，如此的话，可以起到及时地由运维人员对API_1的服务状态进行检查的目的，以防止API_1真的发生服务异常时而对服务开放平台所带来的负面效应的发生。

在上述步骤103的一个实施中，通过如下方式确定所述监控时段的调用日志是否符合所述调用画像，包括：确定所述监控时段的调用日志在各预设频度下的各维度指标的第二指标值；确定所述第二指标值是否符合通过所述第一指标值构建的所述调用画像。

在本申请的某些实施中，通过流式计算引擎确定所述监控时段的调用日志是否符合所述调用画像。

举个例子，可通过流式计算引擎，如Flink平台来对存储在消息队列Kafka中的监控时段的调用日志进行获取，并针对各个维度、对获取到的调用日志进行指标值的计算，从而得到监控时段的调用日志在各个维度下的实际指标值；接着，继续由Flink平台来对各个维度下的实际指标值与API的调用画像中的预测指标值进行比较，确定实际指标值是否在预测指标值的范围内。其中包括两种比较结果，分别为：

1、Flink平台确定实际指标值不在预测指标值的范围内，则发出针对API的告警信息。

在本申请的某些实施中，所述发送针对所述API的告警信息，包括：通过可视化界面对所述API在所述监控时段的所述第二指标值进行展示；所述可视化界面显示所述API的历史告警信息记录。

例如，可通过Mysql存储的统计分析结果、Elasticsearch存储的调用明细数据以及Flink实时统计分析数据，来定制化开发预警可视化界面。运维人员收到预警通知后，可通过可视化界面查看历史预警记录。同时，可视化界面通过动态更新的折线图将实时调用量、流量、延迟、正确率数据与每天、每周的API画像进行对比，运维人员可直观地分析API运行状况。

2、Flink平台确定实际指标值在预测指标值的范围内，也即确定监控时段的调用日志符合调用画像，因此，为了可以让调用画像对未来的监控时段的调用日志产生更好的、也更为贴合的比较效果，则可以基于该监控时段的调用日志来对调用画像进行更新。

如图2所示，为本申请实施例提供的一种API监控预警架构图，针对图2，API画像训练及实时监测数据均是基于的API网关调用日志数据，因此在搭建数据通道时，首先将调用日志实时写入消息队列Kafka，利用流式计算引擎Flink实时解析并判定调用数据是否满足预警规则，如满足预警规则即将告警信息通过邮件、短信方式发送至API运维人员；同时将日志数据存储于HDFS，利用MapReduce大数据计算引擎对历史调用日志进行统计分析，同时将统计分析结果存入Mysql、将调用明细数据存入Elasticsearch。

基于同样的构思，本申请实施例还提供一种监控预警装置，如图3所示，该装置包括：

调用日志获取单元301，用于获取应用程序编程接口API在监控时段的调用日志。

调用画像获取单元302，获取所述API的调用画像，所述调用画像是根据所述API在所述监控时段之前的历史时段的调用日志进行多维度分析后生成的。

处理单元303，用于在所述监控时段的调用日志不符合所述调用画像时，发送针对所述API的告警信息。

进一步地，对于该装置，还包括调用画像生成单元304；调用画像生成单元304，用于针对各预设频度中的任一预设频度，从所述历史时段的调用日志中确定所述预设频度下各维度指标的第一指标值；根据所述预设频度下的各维度指标的第一指标值，通过机器学习方式，确定所述调用画像。

进一步地，对于该装置，所述各预设频度包括每天的同一预设时段及每周同一天的同一预设时段；所述各维度指标包括以下至少一项：预设时段内对API的调用总次数、预设时段内API调用请求与返回结果的字节数总和、预设时段内从对API开始调用到得到响应的时间总长度、预设时段内响应码为正确的调用次数与所述调用总次数的比值。

进一步地，对于该装置，处理单元303，具体用于确定所述监控时段的调用日志在各预设频度下的各维度指标的第二指标值；确定所述第二指标值是否符合通过所述第一指标值构建的所述调用画像。

进一步地，对于该装置，还包括调用画像更新单元305；调用画像更新单元305，用于在所述监控时段的调用日志符合所述调用画像时，根据所述监控时段的调用日志更新所述调用画像。

进一步地，对于该装置，调用日志获取单元301，具体用于通过消息队列获取所述API在监控时段的调用日志；处理单元303，具体用于通过流式计算引擎确定所述监控时段的调用日志是否符合所述调用画像。

进一步地，对于该装置，处理单元303，具体用于通过可视化界面对所述API在所述监控时段的所述第二指标值进行展示；所述可视化界面显示所述API的历史告警信息记录。

本申请实施例提供了一种计算设备，该计算设备具体可以为桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理(Personal Digital Assistant，PDA)等。该计算设备可以包括中央处理器(Center Processing Unit，CPU)、存储器、输入/输出设备等，输入设备可以包括键盘、鼠标、触摸屏等，输出设备可以包括显示设备，如液晶显示器(Liquid Crystal Display，LCD)、阴极射线管(Cathode Ray Tube，CRT)等。

存储器，可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器提供存储器中存储的程序指令和数据。在本申请实施例中，存储器可以用于存储监控预警方法的程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行监控预警方法。

如图4所示，为本申请实施例提供的一种计算设备的示意图，该计算设备包括：

处理器401、存储器402、收发器403、总线接口404；其中，处理器401、存储器402与收发器403之间通过总线405连接；

所述处理器401，用于读取所述存储器402中的程序，执行上述监控预警方法；

处理器401可以是中央处理器(central processing unit，简称CPU)，网络处理器(network processor，简称NP)或者CPU和NP的组合。还可以是硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，简称ASIC)，可编程逻辑器件(programmable logic device，简称PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，简称CPLD)，现场可编程逻辑门阵列(field-programmable gate array，简称FPGA)，通用阵列逻辑(generic array logic,简称GAL)或其任意组合。

所述存储器402，用于存储一个或多个可执行程序，可以存储所述处理器401在执行操作时所使用的数据。

具体地，程序可以包括程序代码，程序代码包括计算机操作指令。存储器402可以包括易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，简称RAM)；存储器402也可以包括非易失性存储器(non-volatile memory)，例如快闪存储器(flash memory)，硬盘(hard disk drive，简称HDD)或固态硬盘(solid-state drive，简称SSD)；存储器402还可以包括上述种类的存储器的组合。

存储器402存储了如下的元素，可执行模块或者数据结构，或者它们的子集，或者它们的扩展集：

操作指令：包括各种操作指令，用于实现各种操作。

操作系统：包括各种系统程序，用于实现各种基础业务以及处理基于硬件的任务。

总线405可以是外设部件互连标准(peripheral component interconnect，简称PCI)总线或扩展工业标准结构(extended industry standard architecture，简称EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

总线接口404可以为有线通信接入口，无线总线接口或其组合，其中，有线总线接口例如可以为以太网接口。以太网接口可以是光接口，电接口或其组合。无线总线接口可以为WLAN接口。

本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行监控预警方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。