一种接口状态的生成方法、装置、计算机设备和存储介质与流程

一种接口状态的生成方法、装置、计算机设备和存储介质
【技术领域】
1.本发明涉及通信技术领域，尤其涉及一种接口状态的生成方法、装置、计算机设备和存储介质。


背景技术：

2.能力开放平台是对所开放的业务能力进行统一管控。业务能力通过能力开放平台以应用程序接口(application program interface，api)的形式与合作渠道实现对接，随着平台接入渠道的数量增长，维护能力开放对接的效能与稳定性成为了业务高质量发展的关键支撑点，从技术层面监测api的异常是主要运维手段。对于api的异常监测，目前主要根据api调用动态进行基于字典的行为匹配，以对api进行异常监测，单一依托于字典文件的监测准确率和监测灵活性较低，增加系统负荷。


技术实现要素：

3.有鉴于此，本发明实施例提供了一种接口状态的生成方法、装置、计算机设备和存储介质，可以提高接口状态的监测准确率和监测灵活性并减少系统负荷。
4.一方面，本发明实施例提供了一种接口状态的生成方法，所述方法包括：
5.按照预设时间间隔从消息队列中获取接口日志；
6.将接口日志添加至分布式搜索引擎；
7.根据分布式搜索引擎，生成接口数据；
8.根据接口数据和构建的隐马尔可夫模型，生成指定时间段内的接口状态。
9.可选地，在按照预设时间间隔从消息队列中获取接口日志之前，还包括：
10.获取接口请求日志、接口应答日志和告警日志；
11.将接口请求日志、接口应答日志和告警日志作为接口日志；
12.将接口日志异步添加入设置的消息队列。
13.可选地，分布式搜索引擎包括统计索引；根据分布式搜索引擎，生成接口数据，包括：
14.通过分布式搜索引擎，根据统计索引查询出接口数据。
15.可选地，还包括：
16.在统计索引与日志索引之间设置服务序列号，服务序列号用于关联统计索引与日志索引。
17.可选地，在根据接口数据和构建的隐马尔可夫模型，生成指定时间段内的接口状态之前，还包括：
18.判断接口数据是否满足设置的异常触发条件；
19.若判断出接口数据满足异常触发条件，获取历史接口日志；
20.将历史接口日志输入马尔可夫链进行训练，生成隐马尔可夫模型。
21.可选地，分布式搜索引擎包括日志索引；还包括：
22.若判断出接口数据满足异常触发条件，通过分布式搜索引擎，根据日志索引查询出日志数据；
23.根据日志数据，生成告警日志。
24.可选地，还包括：
25.若判断出接口数据不满足异常触发条件，继续执行按照预设时间间隔从消息队列中获取接口日志的步骤。
26.另一方面，本发明实施例提供了一种接口状态的生成装置，包括：
27.第一获取单元，用于按照预设时间间隔从消息队列中获取接口日志；
28.第一添加单元，用于将接口日志添加至分布式搜索引擎；
29.第一生成单元，用于根据分布式搜索引擎，生成接口数据；
30.第二生成单元，用于根据接口数据和构建的隐马尔可夫模型，生成指定时间段内的接口状态。
31.另一方面，本发明实施例提供了一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行上述接口状态的生成方法。
32.另一方面，本发明实施例提供了一种计算机设备，包括存储器和处理器，所述存储器用于存储包括程序指令的信息，所述处理器用于控制程序指令的执行，其特征在于，所述程序指令被处理器加载并执行时实现上述接口状态的生成方法。
33.本发明实施例的方案中，按照预设时间间隔从消息队列中获取接口日志；将接口日志添加至分布式搜索引擎；根据分布式搜索引擎，生成接口数据；根据接口数据和构建的隐马尔可夫模型，生成指定时间段内的接口状态，可以提高接口状态的监测准确率和监测灵活性并减少系统负荷。
【附图说明】
34.为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
35.图1为本发明实施例提供的一种接口状态的生成的系统架构图
36.图2为本发明实施例提供的一种接口状态的生成方法的流程图；
37.图3为本发明实施例提供的又一种接口状态的生成方法的流程图；
38.图4为本发明实施例提供的一种hmm模型的示意图；
39.图5为本发明实施例提供的一种接口状态的生成装置的结构示意图；
40.图6为本发明实施例提供的一种计算机设备的示意图。
【具体实施方式】
41.为了更好的理解本发明的技术方案，下面结合附图对本发明实施例进行详细描述。
42.应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
43.在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。
44.应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
45.应当理解，尽管在本发明实施例中可能采用术语第一、第二等来描述设定阈值，但这些设定阈值不应限于这些术语。这些术语仅用来将设定阈值彼此区分开。例如，在不脱离本发明实施例范围的情况下，第一设定阈值也可以被称为第二设定阈值，类似地，第二设定阈值也可以被称为第一设定阈值。
46.图1为本发明实施例提供的一种接口状态的生成的系统架构图，如图1所示，该系统包括：分布式搜索引擎层100、应用程序接口(application program interface，api)定位层200和异常识别层300。
47.分布式搜索引擎层100包括多个分布式节点，如图1所示，分布式节点包括主(master)节点、客户端(client)节点和数据(data)节点。其中，master节点用于维护源数据，管理集群节点状态；client节点用于数据任务分发和结果汇聚，可以为data节点分担压力；data节点用于向上层写入数据或查询数据。分布式搜索引擎层100用于向api定位层200传输源数据。
48.api定位层200包括多个api，如图1所示，api定位层200包括第一接口(api_1)、第二接口(api_2)和第三接口(api_3)。api可以根据接收到的源数据和自身特征定位出指定异常事件。
49.异常识别层300包括多个异常事件，如图1所示，异常事件包括异常事件a、异常事件b和异常事件c。例如：api_1和api_3根据接收到的源数据和自身特征定位出异常事件b；api_2根据接收到的源数据和自身特征定位出异常事件a；api_3根据接收到的源数据和自身特征定位出异常事件c。
50.本发明实施例中，图1所示的系统架构图还用于执行下述图2或图3所示的接口状态的生成方法，在此不再赘述。
51.本发明实施例提供的技术方案中，按照预设时间间隔从消息队列中获取接口日志；将接口日志添加至分布式搜索引擎；根据分布式搜索引擎，生成接口数据；根据接口数据和构建的隐马尔可夫模型，生成指定时间段内的接口状态，可以提高接口状态的监测准确率和监测灵活性并减少系统负荷。
52.图2为本发明实施例提供的一种接口状态的生成方法的流程图，如图2所示，该方法包括：
53.步骤101、按照预设时间间隔从消息队列中获取接口日志。
54.步骤102、将接口日志添加至分布式搜索引擎。
55.步骤103、根据分布式搜索引擎，生成接口数据。
56.步骤104、根据接口数据和构建的隐马尔可夫模型，生成指定时间段内的接口状态。
57.本发明实施例提供的技术方案中，按照预设时间间隔从消息队列中获取接口日
志；将接口日志添加至分布式搜索引擎；根据分布式搜索引擎，生成接口数据；根据接口数据和构建的隐马尔可夫模型，生成指定时间段内的接口状态，可以提高接口状态的监测准确率和监测灵活性并减少系统负荷。
58.图3为本发明实施例提供的又一种接口状态的生成方法的流程图，如图3所示，该方法包括：
59.步骤201、获取接口请求日志、接口应答日志和告警日志。
60.本发明实施例中，各步骤由服务器执行。
61.本发明实施例中，从平台服务器日志中获取接口请求日志和接口应答日志；从设备故障告警信息获取告警日志。其中，平台服务器日志属于业务侧源数据，告警日志属于硬件侧源数据。
62.本发明实施例中，考虑到在实际生产应用中对api调用状态产生影响的前台业务侧调用因素和硬件设备故障隐私，将业务侧源数据和硬件侧源数据同时作为api异常监测的源数据，可以兼顾业务特性和硬件设备对api的影响，使得源数据更加可靠。
63.步骤202、将接口请求日志、接口应答日志和告警日志作为接口日志。
64.本发明实施例中，接口日志包括接口请求日志、接口应答日志和告警日志。
65.本发明实施例中，接口日志为api异常监测的源数据。
66.步骤203、将接口日志异步添加入设置的消息队列。
67.本发明实施例中，通过消息系统将接口日志异步添加入消息队列。作为一种可选方案，消息系统为开源流处理平台(kafka)消息系统。
68.本发明实施例中，将多源数据异步添加入消息队列，可以降低系统负荷，缓解系统压力。
69.步骤204、按照预设时间间隔从消息队列中获取接口日志。
70.本发明实施例中，预设时间间隔可根据实际情况进行设置。
71.本发明实施例中，开源日志管理平台(logstash)按照预设时间间隔从消息队列中获取接口日志。
72.本发明实施例中，接口日志经消息队列由api服务网关传输至logstash，logstash将接口日志中的数据分为api调用统计类数据与api调用报文日志类数据两部分，将api调用统计类数据与api调用报文日志类数据存储至内存数据库，可以实现多源数据的归档收集。作为一种可选方案，内存数据库为redis。
73.步骤205、将接口日志添加至分布式搜索引擎。
74.作为一种可选方案，分布式搜索引擎为elastic search搜索引擎。
75.本发明实施例中，通过分布式节点部署搭建elastic search搜索引擎，将接口日志添加至分布式搜索引擎。
76.本发明实施例中，分布式搜索引擎可以为api异常监控分析的机制构建和算法设计提供底层架构支撑。
77.步骤206、通过分布式搜索引擎，根据统计索引查询出接口数据。
78.本发明实施例中，分布式搜索引擎包括分布式节点，在分布式节点中，可以设置多个索引进行数据管理。作为一种可选方案，在分布式搜索引擎的分布式节点中设置两个索引进行数据管理，分别为统计索引和日志索引。
79.本发明实施例中，api具备api码(api id)，统计索引可以以api id为维度对接口数据进行实时搜索。
80.本发明实施例中，日志数据和接口数据显示于可视化用户界面，用户可以通过该可视化用户界面对日志数据和接口数据进行管理，若检测到用户操作导致api状态转换，状态以秒级关联至api网关进行状态同步。作为一种可选方案，可视化用户界面为kibana。
81.进一步地，在统计索引与日志索引之间设置服务序列号，服务序列号用于关联统计索引与日志索引，实现了接口数据和日志数据之间的关联能力。
82.本发明实施例中，平台使用服务序列号可以对接口数据和日志数据进行匹配，匹配成功的消息处理流程可以记录在调用日志中，实现了使用服务序列号跟踪后台调用日志以定位业务故障的运维途径，降低了对日志数据的交互访问频次，提高了安全性，且使平台日志数据的访问与管理具备可追踪性。
83.步骤207、判断接口数据是否满足设置的异常触发条件；若是，执行步骤208；若否，执行步骤204。
84.本发明实施例中，异常触发条件可根据实际情况进行设置。作为一种可选方案，当接口数据包括api调用时延时，异常触发条件包括api调用时延大于或等于时延阈值；当接口数据包括响应时长时，异常触发条件包括响应时长大于或等于响应时长阈值；当接口数据包括api调用是否有响应时，异常触发条件包括但不限于、和api调用无响应中之一或其任意组合。
85.本发明实施例中，若判断出接口数据满足异常触发条件，表明api发生异常，继续执行步骤208；若判断出接口数据不满足异常触发条件，表明api未发生异常，继续监控，执行步骤204。
86.进一步地，若api发生异常，则通过分布式搜索引擎，根据日志索引查询出日志数据；根据日志数据，生成告警日志，并将告警日志添加至设备故障告警信息。其中，日志数据包括api调用日志、请求报文和响应报文。
87.步骤208、获取历史接口日志。
88.本发明实施例中，历史接口日志包括历史日志数据和历史接口数据。
89.步骤209、将历史接口日志输入马尔可夫链(ctcm)进行训练，生成隐马尔可夫(hmm)模型。
90.本发明实施例中，将历史日志数据和历史接口数据输入ctcm对api状态变化建模训练，构建出hmm模型。其中，api状态包括正常、异常事件发生、异常事件检测、运维调整和恢复，历史日志数据中记录有api状态变化。
91.步骤210、根据接口数据和构建的hmm模型，生成指定时间段内的接口状态。
92.本发明实施例中，指定时间段包括从当前时刻至未来某个时刻的时间段。
93.本发明实施例中，将接口数据输入hmm模型，输出指定时间段内的接口状态，接口状态包括状态正常或状态异常。
94.图4为本发明实施例提供的一种hmm模型的示意图，如图4所示，该模型从上到下表示时间序列，即：时间段，时间序列包括多个时刻，分别是时刻1至τ，各时刻τ的api调用状态的特征γ的特征值f
γ,τ
作为可见状态，对应的瞬时状态标签t
γ,τ
作为隐藏状态，t
γ,τ
的状态转移以ctmt进行描述，hmm模型如图4所示，得到api的调用状态标签集t＝{t1，t2，
…
,tτ}，
其中，t表示api的调用状态标签序列集合，即：接口状态，标签值“0”表示状态正常，标签值“1”表示状态异常。
95.本发明实施例中，由于可以生成指定时间段内的接口状态，因此，可以预测出未来某个时刻的api调用状态。
96.进一步地，将hmm模型算法于python脚本中编写，并在kibana的工作台中实现web请求调用脚本程序，通过hmm模型输出接口状态，在kibana平台上实现api状态数据可视化，以供运维人员更加便捷地定位异常根源、观测修复效果，同时可以实现api异常检测事件的可视化页面封装，从运维与运营两方面对api状态进行检测监控。
97.本发明实施例提供的接口状态的生成方法的技术方案中，按照预设时间间隔从消息队列中获取接口日志；将接口日志添加至分布式搜索引擎；根据分布式搜索引擎，生成接口数据；根据接口数据和构建的隐马尔可夫模型，生成指定时间段内的接口状态，可以提高接口状态的监测准确率和监测灵活性并减少系统负荷。
98.图5为本发明实施例提供的一种接口状态的生成装置的结构示意图，该装置用于执行上述接口状态的生成方法，如图5所示，该装置包括：第一获取单元11、第一添加单元12、第一生成单元13和第二生成单元14。
99.第一获取单元11用于按照预设时间间隔从消息队列中获取接口日志。
100.第一添加单元12用于将接口日志添加至分布式搜索引擎。
101.第一生成单元13用于根据分布式搜索引擎，生成接口数据。
102.第二生成单元14用于根据接口数据和构建的隐马尔可夫模型，生成指定时间段内的接口状态。
103.本发明实施例中，该装置还包括：第二获取单元15、确定单元16和第二添加单元17。
104.第二获取单元15用于获取接口请求日志、接口应答日志和告警日志。
105.确定单元16用于将接口请求日志、接口应答日志和告警日志作为接口日志。
106.第二添加单元17用于将接口日志异步添加入设置的消息队列。
107.本发明实施例中，第一生成单元13具体用于通过分布式搜索引擎，根据统计索引查询出接口数据。
108.本发明实施例中，该装置还包括：设置单元18。
109.设置单元18用于在统计索引与日志索引之间设置服务序列号，服务序列号用于关联统计索引与日志索引。
110.本发明实施例中，该装置还包括：判断单元19、第三获取单元20和第三生成单元21。
111.判断单元19判断接口数据是否满足设置的异常触发条件；若判断出接口数据不满足异常触发条件，触发第一获取单元11继续执行按照预设时间间隔从消息队列中获取接口日志的步骤。
112.第三获取单元20用于若判断单元19判断出接口数据满足异常触发条件，获取历史接口日志。
113.第三生成单元21用于将历史接口日志输入马尔可夫链进行训练，生成隐马尔可夫模型。
114.本发明实施例中，该装置还包括：查询单元22和第四生成单元23。
115.查询单元22用于若判断单元19判断出接口数据满足异常触发条件，通过分布式搜索引擎，根据日志索引查询出日志数据。
116.第四生成单元23用于根据日志数据，生成告警日志。
117.本发明实施例的方案中，按照预设时间间隔从消息队列中获取接口日志；将接口日志添加至分布式搜索引擎；根据分布式搜索引擎，生成接口数据；根据接口数据和构建的隐马尔可夫模型，生成指定时间段内的接口状态，可以提高接口状态的监测准确率和监测灵活性并减少系统负荷。
118.本发明实施例提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述接口状态的生成方法的实施例的各步骤，具体描述可参见上述接口状态的生成方法的实施例。
119.本发明实施例提供了一种计算机设备，包括存储器和处理器，存储器用于存储包括程序指令的信息，处理器用于控制程序指令的执行，程序指令被处理器加载并执行时实现上述接口状态的生成方法的实施例的各步骤，具体描述可参见上述接口状态的生成方法的实施例。
120.图6为本发明实施例提供的一种计算机设备的示意图。如图6所示，该实施例的计算机设备30包括：处理器31、存储器32以及存储在存储32中并可在处理器31上运行的计算机程序33，该计算机程序33被处理器31执行时实现实施例中的应用于接口状态的生成方法，为避免重复，此处不一一赘述。或者，该计算机程序被处理器31执行时实现实施例中应用于接口状态的生成装置中各模型/单元的功能，为避免重复，此处不一一赘述。
121.计算机设备30包括，但不仅限于，处理器31、存储器32。本领域技术人员可以理解，图6仅仅是计算机设备30的示例，并不构成对计算机设备30的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如计算机设备还可以包括输入输出设备、网络接入设备、总线等。
122.所称处理器31可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
123.存储器32可以是计算机设备30的内部存储单元，例如计算机设备30的硬盘或内存。存储器32也可以是计算机设备30的外部存储设备，例如计算机设备30上配备的插接式硬盘，智能存储(smart media,sm)卡，安全数字(secure digital,sd)卡，闪存卡(flash card)等。进一步地，存储器32还可以既包括计算机设备30的内部存储单元也包括外部存储设备。存储器32用于存储计算机程序以及计算机设备所需的其他程序和数据。存储器32还可以用于暂时地存储已经输出或者将要输出的数据。
124.在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如，多个单元或组
件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
125.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
126.另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
127.以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。