一种面向微服务应用的智能运维系统、方法、设备、终端

1.本发明属于系统运维技术领域，尤其涉及一种面向微服务应用的智能运维系统、方法、设备及终端。


背景技术：

2.目前，计算机及网络技术飞速发展，互联网应用日渐普及，涉及基础服务、商务交易、网络娱乐、公共服务等各行业。据idc预测，到2022年，90％的应用程序将采用微服务架构，35％的产品应用将是云原生的，服务提供商需要以一种平台化的方式构建企业级云原生能力。在进行应用系统平台化构建的过程中，it运维扮演提升整个平台运营和服务水平的重要角色。
3.it运维，作为应用系统服务生命周期的一个阶段，对基础设施和业务组件通过一系列流程、技术、方法进行管理，来提供质量、成本、效率和安全等方面的保障。it运维经历手工运维、自动运维及devops(一组软件开发和运维团队之间的自动化流程实践)发展过程，但始终无法改变“基于人为指定规则”的既定事实。
4.aiops(artificial intelligence for it operations，智能运维)，将人工智能应用于it运维领域，基于已有的运维数据(应用信息、系统日志、监控指标等)，通过机器学习的方式来深入解决自动化运维无法处理的问题。aiops不依赖于人为定义的规则，主张通过机器学习模型从海量的运维数据中自动、持续的学习，不断的对运维场景知识进行提炼和总结。机器学习模型可以视为aiops的中枢，负责指挥采集所需的运维数据，做出实时的分析与决策，并指定相应脚本、模块进行执行操作，从整体上达到运维系统的智能化目标。
5.通过上述分析，现有技术存在的问题及缺陷为：
6.(1)现有技术面对复杂性高、动态性强的应用系统架构及海量运维数据难以实现实时、高效的在线异常检测，使得不能及时捕获系统异常状态，对潜在故障做出预测。
7.(2)现有技术在处理复杂系统所发生的故障时，无法进行更加全面、精确的故障根因定位，运维人员难以清晰的了解故障发生的位置、原因等，阻碍进行后续的故障恢复，造成进一步的损失。


技术实现要素：

8.针对现有技术存在的问题，本发明提供了一种面向微服务应用的智能运维系统、方法、设备及终端。
9.本发明是这样实现的，一种面向微服务应用的智能运维方法，所述面向微服务应用的智能运维方法包括：
10.首先，利用数据采集器收集应用系统正常的执行轨迹和多维指标数据，利用检测器通过执行轨迹数据进行模型训练，利用分析器通过多指标构建正常的实例相关图，并将对应的执行轨迹和图存入运维数据库；
11.其次，利用数据采集器采集实时的执行轨迹数据和多维指标数据，利用检测器对
当前的执行轨迹进行异常检测及解释；
12.然后，利用分析器构建当前实例相关图，通过和运维库中历史实例相关图对当前图进行优化；
13.最后，从异常结果开始，在优化后的图中进行随机游走定位输出根因列表。
14.进一步，所述面向微服务应用的智能运维方法包括以下步骤：
15.步骤一，通过在服务编排器、服务网格的基础上整合prometheus、zipkin进行执行轨迹数据和多维指标数据的获取，达到采集多维运维数据进行系统状态分析的目的；
16.步骤二，获取应用系统正常执行轨迹数据，并构建异常检测模型；利用所述应用系统正常执行轨迹数据对所述异常检测模型进行训练，或得能够对系统运行状态进行监测的模型；
17.步骤三，利用训练好的异常检测模型对实时执行轨迹数据进行检测，判断应用系统是否存在异常，达到对系统运行状态进行实时监控、捕获异常信息的目的；若异常，则转向步骤四；
18.步骤四，从数据库中寻找最相关的参考序列进行差异化分析，输出具备可解释检测结果，以便更充分的利用相关异常信息；
19.步骤五，同时基于获取的多维指标数据对异常发生的根本原因进行定位并输出根因列表，并对执行轨迹数据、多维指标数据以及生成的图数据进行存储以用于系统分析。
20.进一步，所述步骤一中，通过在服务编排器、服务网格的基础上整合prometheus、zipkin进行执行轨迹数据和多维指标数据的获取包括：
21.在服务编排器、服务网格istio的基础上整合prometheus、zipkin，利用zipkin同istio进行整合收集并存储执行轨迹数据；利用prometheus同istio整合通过推/拉两种方式获取数据，并通过一定规则进行数据的整理和清理；
22.同时利用zipkin的内存存储器将处理后的执行轨迹数据数据存储至新的时间序列中；利用prometheus的内存存储器对多维指标数据进行存储。
23.进一步，所述步骤五中，基于获取的多维指标数据对异常发生的根本原因进行定位并输出根因列表包括：
24.(1)当应用系统异常时，获取当前应用系统中主机、容器和服务实例的系统属性，通过属性的相关性构建实例关系，并生成实例相关图；
25.(2)结合历史数据判断是否能进行实例相关图的优化，若不能优化实例相关图，则转向步骤(4)；否则，转向步骤(3)；
26.(3)对生成的实例相关图进行聚合与去冗余处理，并从数据库中寻找相似异常对当前图中的权重进行优化，令游走过程有效参考相关的历史异常；
27.(4)基于优化后的实例相关图结合具备可解释检测结果，通过随机游走策略进行故障定位，并输出根因列表。
28.进一步，所述步骤五中，对执行轨迹数据、多维指标数据、图数据进行存储包括：
29.利用数据库对执行轨迹数据进行存储；利用时序数据库对多维指标数据进行存储；利用图数据库对生成的图数据进行存储。
30.进一步，所述面向微服务应用的智能运维方法还包括：
31.创建实例以半自动化的方式进行不同类型的故障的注入，并且通过测试用例验证
引发的故障是否符合预期的故障；若符合则生成相关实例的故障版本，并通过发布故障版本，利用测试用例便复现相关故障。
32.本发明实施例提供的面向微服务应用的智能运维系统，所述面向微服务应用的智能运维系统包括：
33.基础设施层，用于通过容器化技术对硬件资源进行管理；
34.应用层，用于利用微服务技术进行应用的开发；
35.管理层，用于收集基础设施层和应用层的数据；同时用于对应用实例进行注册、调度、运维管理；
36.所述管理层包括：
37.数据采集模块，用于采集应用运行时的执行轨迹数据、资源和应用监控指标数据；同时用于对采集的数据进行整理和清理；
38.异常检测模块，用于利用异常检测算法和异常差异性解释算法根据执行轨迹数据进行实时的异常检测；
39.故障定位模块，用于根据监控指标数据对故障发生的根本原因进行定位；
40.运维数据库模块，用于对异常检测和故障定位过程中利用的括执行轨迹数据、监控指标数据、图数据进行存储；
41.所述基础设施层、应用层与管理层之间相互通信。
42.本发明的另一目的在于提供一种计算机设备，所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行所述面向微服务应用的智能运维方法的步骤。
43.本发明的另一目的在于提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行所述面向微服务应用的智能运维方法的步骤。
44.本发明的另一目的在于提供一种信息数据处理终端，所述信息数据处理终端用于实现所述面向微服务应用的智能运维系统。
45.结合上述的技术方案和解决的技术问题，请从以下几方面分析本发明所要保护的技术方案所具备的优点及积极效果为：
46.第一、针对上述现有技术存在的技术问题以及解决该问题的难度，紧密结合本发明的所要保护的技术方案以及研发过程中结果和数据等，详细、深刻地分析本发明技术方案如何解决的技术问题，解决问题之后带来的一些具备创造性的技术效果。具体描述如下：
47.本发明能够实现统一的应用运维：通过三层系统架构监控运维，采用多种形式采集运维相关的执行轨迹、资源指标、应用指标等数据，对跨域应用进行全面的监测及分析，实现对多应用的统一、集中化管理，降低运维成本。
48.本发明能够实现实时的异常检测：能够对应用的异常状态进行实时、主动的捕获，减少因异常分析造成的时间消耗。
49.本发明能够实现精准的故障定位：能够对故障发生的根本原因进行准确的定位，便于对系统故障进行恢复。
50.第二，把技术方案看做一个整体或者从产品的角度，本发明所要保护的技术方案具备的技术效果和优点，具体描述如下：
51.本发明的能够保证系统的高可用性，节省运维人力成本，减少因系统故障造成的经济损失，加速智能化转型。
52.第三，作为本发明的权利要求的创造性辅助证据，还体现在以下几个重要方面：
53.本发明的技术方案解决了人们一直渴望解决、但始终未能获得成功的技术难题：
54.微服务、容器化等云原生技术成为当前构建应用系统的主流方式，系统复杂性从服务内部转移到服务交互及系统架构层次，传统人工运维、devops等运维方式不仅造成较高的人力资源开销，且很难对系统故障做出预测，当故障发生后难以及时找到故障发生的原因，带来巨大的经济损失，迫切的需要一种智能化的运维方法。
55.本发明围绕运维中异常检测及故障定位的相关设计及实现，以一种自动化的方式对系统进行状态检测，及时捕获异常并在故障发生后进行全面、精确的定位，运维人员根据分析结果以进行后续的故障恢复等流程，从而实现更加智能的运维方式。且在异常检测过程中克服了当前方法在实时性、扩展性、解释性等方面的难题，在故障定位过程中克服了准确性、全面性、稳定性方面的难题。
附图说明
56.图1是本发明实施例提供的面向微服务应用的智能运维系统架构图；
57.图2是本发明实施例提供的面向微服务应用的智能运维系统模块交互时序图；
58.图3是本发明实施例提供的面向微服务应用的智能运维方法流程图；
59.图4是本发明实施例提供的数据采集实现架构示意图；
60.图5是本发明实施例提供的异常检测实现流程示意图；
61.图6是本发明实施例提供的故障定位实现流程示意图。
62.图7是本发明实施例提供的应用系统数据流及架构图。
63.图8是本发明实施例提供的应用系统场景对应的数据处理流程图。
64.图9是本发明实施例提供的应用系统异常检测效果图。
65.图10是本发明实施例提供的应用系统故障定位图构建效果图。
66.图11是本发明实施例提供的应用系统故障定位故障分析效果图。
具体实施方式
67.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
68.一、解释说明实施例。为了使本领域技术人员充分了解本发明如何具体实现，该部分是对权利要求技术方案进行展开说明的解释说明实施例。
69.如图1-图2所示，本发明实施例提供的面向微服务应用的智能运维系统包括：基础设施、应用和管理三层。基础设施层通过容器化等技术实现对硬件资源的管理；应用层使用微服务等技术实现应用的开发；管理层则对应用实例进行注册、调度、运维等操作。三层之间相互通信，管理层以收集来自基础设施层和应用层的数据。
70.本发明实施例提供的管理层还包括：智能运维中心；智能运维中心通过对来自基础设施层和应用层的状态数据进行采集，对发布在平台上的系统应用提供异常检测和故障
定位服务，来保证系统的可用性。
71.本发明实施例提供的智能运维中心主要分为4个子模块：数据采集模块、异常检测模块、故障定位模块和运维数据库模块。数据采集模块对应用的运行时数据进行采集，包括执行轨迹数据、资源和应用监控指标数据等。异常检测模块根据执行轨迹数据对系统进行实时的异常检测，包括异常检测算法和异常差异性解释算法。故障定位模块根据监控指标数据对故障发生的根本原因进行定位，包括应用服务间的关系图进行构建算法、随机游走定位算法。运维数据库模块负责对异常检测和故障定位过程中使用的数据进行存储，包括执行轨迹数据、监控指标数据、图数据。
72.本发明实施例提供的面向微服务应用的智能运维系统的实现包括两个阶段：
73.在准备阶段，数据采集器收集系统正常的执行轨迹和多维指标数据，检测器通过执行轨迹数据进行模型训练，分析器通过多指标构建正常的实例相关图，并将对应的执行轨迹和图存入运维数据库。
74.在使用阶段，数据采集器采集实时的执行轨迹数据和多维指标数据，通过检测器对当前的执行轨迹进行异常检测及解释后，分析器构建当前实例相关图，通过和运维库中历史实例相关图来对当前图进行优化，最后从异常结果开始，在优化后的图中进行随机游走定位给出根因列表。
75.如图3所示，本发明实施例提供的面向微服务应用的智能运维方法包括以下步骤：
76.s101，在服务编排器、服务网格的基础上整合prometheus、zipkin，利用zipkin同istio进行整合收集并存储执行轨迹数据；利用prometheus同istio整合通过推/拉两种方式获取数据，并通过一定规则进行数据的整理和清理；
77.s102，获取应用系统正常执行轨迹数据，并构建异常检测模型；利用所述应用系统正常执行轨迹数据对所述异常检测模型进行训练；
78.s103，利用训练好的异常检测模型对实时执行轨迹数据进行检测，判断应用系统是否存在异常；若异常，则转向步骤s104；
79.s104，从数据库中寻找最相关的参考序列进行差异化分析，输出具备可解释检测结果；同时基于获取的多维指标数据对异常发生的根本原因进行定位并输出根因列表；
80.s105，利用数据库对执行轨迹数据进行存储；利用时序数据库对多维指标数据进行存储；利用图数据库对生成的图数据进行存储。
81.步骤s104中，本发明实施例提供的基于获取的多维指标数据对异常发生的根本原因进行定位并输出根因列表包括：
82.(1)当应用系统异常时，获取当前应用系统中主机、容器和服务实例的系统属性，通过属性的相关性构建实例关系，并生成实例相关图；
83.(2)结合历史数据判断是否能进行实例相关图的优化，若不能优化实例相关图，则转向步骤(4)；否则，转向步骤(3)；
84.(3)对生成的实例相关图进行聚合与分离处理，并从数据库中寻找相似异常对当前图中的权重进行优化，令游走过程有效参考相关的历史异常；
85.(4)基于优化后的实例相关图结合具备可解释检测结果，通过随机游走策略进行故障定位，并输出根因列表。
86.本发明实施例提供的面向微服务应用的智能运维方法还包括：应用故障注入方
法，通过对微服务架构系统的代码以及相关基础组件的操控，以半自动化的方式将不同类型的故障引入整个系统的不同部分，生成相关的一系列系统故障版本。构建故障注入策略需考虑如下信息：
87.(1)故障类型，整个系统存在基础组件、业务组件等多种实例，根据系统中实例间的交互及作用方式定义故障类型；
88.(2)故障注入位置，根据不同的故障类型及系统真实环境来选择适当的注入位置；
89.(3)故障注入方式，系统在运行过程中通过变更执行代码或配置等方法来生成故障；
90.(4)预期异常表现，故障成功注入后对系统产生的影响，即在本系统执行轨迹、多维指标数据的异常变化情况；
91.通过修改代码或环境配置等方式创建实例并将故障引入应用系统，并且通过测试用例来验证引发的故障是否符合预期的故障，如果符合便生成了相关实例的故障版本，在后续的检测器及分析器验证阶段，通过发布故障版本，并使用测试用例便可以复现相关故障。
92.本发明实施例提供的管理层的数据采集模块、异常检测模块、故障定位模块和运维数据库模块具体采用的方法如下：
93.数据采集模块负责对系统中的执行轨迹数据和多维指标数据进行获取，实现方式为在服务编排器(k8s)+服务网格(istio)的基础上整合prometheus、zipkin。如图4，服务实例被服务编排器封装为pod容器运行，服务网格为每个实例分配一个代理envoy进行服务实例通信，mixer作为istio的组件负责提供策略控制和遥测数据。zipkin同istio进行整合来收集执行轨迹数据，同时提供内存存储服务，并通过api接口对外提供调用查询。prometheus同istio整合通过推/拉两种方式获取数据，通过一定规则进行数据的整理和清理，并把得到的结果存储到新的时间序列中，采集到的数据有两种用途，一个是告警服务，另一个是通过promql提供对数据的操作。
94.异常检测模块通过对正常执行轨迹的学习，完成检测模型的训练，同时进行数据的存储服务，当系统进行实时检测时，通过训练成的模型对序列进行检测，当被判定为异常时，通过从数据库中寻找最相关的参考序列来进行差异化分析，输出具备可解释检测结果。具体流程如图5。
95.本发明实施例提供的故障定位模块根据监控指标数据对故障发生的根本原因进行定位，包括应用服务间的关系图进行构建算法、随机游走定位算法。故障定位模块当检测器发现系统异常时，分析器获取当前系统中主机、容器和服务实例的系统属性，通过属性的相关性构建实例关系，生成实例相关图用于故障定位分析，同时结合历史数据进行图优化，基于优化后的实例相关图，结合检测器得到的异常检测结果，通过随机游走策略进行故障定位。其过程如图6。其中图操作分为聚合操作和分离操作，聚合操作的目的是提取实例的特性，分离操作是为了剔除当前图中与异常无关的信息来提取异常特性，然后从数据库中寻找相似异常对当前图中的权重进行优化，使游走过程有效参考相关的历史异常。
96.本发明实施例提供的运维数据库模块负责对异常检测和故障定位过程中使用的数据进行存储，包括执行轨迹数据、监控指标数据、图数据。运维数据库模块负责对检测器和分析器工作过程中的数据进行存储。对于检测阶段的执行轨迹数据，zipkin有内存存储
器进行存储，同时可以通过对接mysql进行数据持久化；对于多指标数据，prometheus同样提供了内存存储，并通过influxdb进行远端存储；对于生成的图数据，通过dgraph进行存储。
97.二、应用实施例。为了证明本发明的技术方案的创造性和技术价值，该部分是对权利要求技术方案进行具体产品上或相关技术上的应用实施例。
98.将本发明实施例提供的面向微服务应用的智能运维系统应用于微服务应用系统aiops进行异常检测和故障定位；能够满足微服务应用平台化、智能化运维场景需求，进行实时、高效的在线异常检测以及更加全面、精确的故障根因定位。
99.本发明专利已成功应用与内部开发的智慧园区应用系统等，系统通过微服务架构开发，如智慧园区-道路监控子系统数据流架构图如图7所示，针对图8行人及车辆监控及记录场景，做出异常检测及故障定位相关功能测试，异常检测测试结果如图9所示，故障定位在图构架阶段的测试结果如图10所示，在故障分析阶段的测试结果如图11所示。
100.三、实施例相关效果的证据。本发明实施例在研发或者使用过程中取得了一些积极效果，和现有技术相比的确具备很大的优势，下面内容结合试验过程的数据、图表等进行描述。
101.为证明本发明的有效性及先进性，同相关前沿方法进行对比分析，主要在异常检测及故障定位两个方面进行对比。在开源微服务系统sock shop、trainticket中进行实验验证。
102.在异常检测阶段，本发明同方法mepfl及方法traceanomaly在实时性、可扩展性、可解释性方面分别做出对比方案，评估指标选取通过混淆矩阵构建的准确率、精确率及召回率。实验结果如下所示：
103.表1 sock shop开源系统中的异常检测实时性效果验证
[0104][0105]
本发明方法相比另外两种方法，在保证较高精确度和召回率的情况下，降低了异常检测耗时成本。
[0106]
表2 sock shop及trainticket开源系统中的异常检测扩展性效果验证
[0107][0108]
本发明方法以统一方式对两系统进行管理，在不同的系统中，本发明方法精确度及误报率优于另外两种方法，有较好的扩展性。
[0109]
表3 sock shop开源系统中的异常检测解释性效果验证
[0110][0111]
本发明方法解释性不如mepfl，因为mepfl通过三种有监督方法对异常进行更详细的分类、提取。但相比同样的无监督方法traceanomaly有所提升，尤其在相对复杂的系统环境。
[0112]
在故障定位阶段，本发明方法同方法cloudranger及方法microscope做出对比方案，评估指标设定为平均精度(map)及平均误报(mfp)。实验结果如下所示：
[0113]
表4 sock shop场景下故障定位方法比较
[0114][0115][0116]
因交互故障通常是直接故障类型，所以各方法在平均精度和平局误报相差不大。本发明通过考虑指标等优化了服务间的间接关系，相比另外两种方法有所提高，并考虑服
务实例之间的状态关系，在多实例故障等当面有较大提升。
[0117]
表5 trainticket场景下故障定位方法比较
[0118][0119]
在相对更复杂的系统环境中，通过历史数据进行图操作优化，其增益效果更大，平均精度和平均误报有更明显的提升。
[0120]
应当注意，本发明的实施方式可以通过硬件、软件或者软件和硬件的结合来实现。硬件部分可以利用专用逻辑来实现；软件部分可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域的普通技术人员可以理解上述的设备和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、cd或dvd-rom的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本发明的设备及其模块可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合例如固件来实现。
[0121]
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，都应涵盖在本发明的保护范围之内。