CN114791846B - 一种针对云原生混沌工程实验实现可观测性的方法 - Google Patents

Abstract

本发明公开了一种针对云原生混沌工程实验实现可观测性的方法，包括S1、创建云原生应用对象；S2、部署可观测性数据采集方式；S3、创建混沌工程实验的演练计划；S4、构建实验观测面板；S5、生成实验架构感知图；S6、运行演练计划；S7、演练完毕。优点是：针对云原生环境下进行混沌工程实验无法针对性的实现全面观测、无法准确验证实验效果等缺陷；本发明实现了在云原生环境下大幅提升对混沌工程实验的观测能力，协助实验人员更加准确的验证实验的稳态假说设定，进而极大提高混沌工程实验的有效性。

Description

一种针对云原生混沌工程实验实现可观测性的方法

技术领域

本发明涉及云原生技术领域，尤其涉及一种针对云原生混沌工程实验实现可观测性的方法。

背景技术

随着企业数字化转型的持续推进，云原生已经成为驱动业务增长的重要引擎。云原生K8s(Kubernetes)技术为企业信息化建设提供了高效统一的有力支撑，但同时由于其技术的复杂性，在系统优化、故障诊断、高可用性验证等众多方面也给用户带来了一定的挑战。

云原生混沌工程实验的推广，有效的缓解了此问题。客户通过在生产环境或准生产环境，主动引入各层面的故障，并结合相应的可观测手段，发现目标系统中的潜在隐患，及时优化和修正以提升目标系统的业务韧性。

目前云原生混沌工程实验的观测手段，主要基于现有监控系统或APM(Application Performance Monitoring，应用性能管理)系统，对系统性能指标、服务链路调用、系统应用日志等进行采集和监控，但无法对实验中的故障注入类型、目标对象、爆炸半径、业务影响范围等进行针对性的全面观测，无法准确验证混沌工程实验是否满足相应的稳态假说设定，实验成功率无法得到充分保证。

为满足云原生环境下混沌工程实验对可观测性的能力要求，本发明提出了一种针对云原生混沌工程实验实现可观测性的方法。

发明内容

本发明的目的在于提供一种针对云原生混沌工程实验实现可观测性的方法，从而解决现有技术中存在的前述问题。

为了实现上述目的，本发明采用的技术方案如下：

一种针对云原生混沌工程实验实现可观测性的方法，包括如下步骤，

S1、创建云原生应用对象；

实验人员结合实际业务系统的架构部署情况，基于云原生应用模型创建各个应用对象，同时采用K8s API自动检索应用对象所属的K8s集群和命名空间中包含的所有节点；将应用对象和节点存储在配置管理数据库内，作为后续实验的目标对象；

S2、部署可观测性数据采集方式；

针对K8s集群中各云原生应用，配置相应的数据采集方式；

S3、创建混沌工程实验的演练计划；

创建复杂的演练流程并配置演练必备的相关参数；

S4、构建实验观测面板；

针对指定的演练计划，采用多模型融合推荐算法，自动生成最佳观测效果的可视化的实验观测面板；

S5、生成实验架构感知图；

针对故障注入的目标对象和爆炸半径以及配置管理数据库内云原生应用的关联关系，通过调用kube-apiserver的Discovery和RESTMapper接口，自动绘制K8s集群的可观测性拓扑图，即实验架构感知图，并在可观测性拓扑图中明确标识目标对象以及爆炸半径内涉及的所有K8s资源对象；

S6、运行演练计划；

开始运行演练计划，注入实验故障和流量，结合关联的实验观测面板和实验架构感知图，实时掌控演练进度、目标对象状态、爆炸半径影响度、关联应用影响度，进而实现对实验效果的全面观测；

步骤S6中，在演练运行时实现可观测性的处理流程如下，

S61、运行演练计划，生成演练实例对象，并将实例信息传递至关联的实验观测面板和实验架构感知图；

S62、可观测性数据采集端基于兼容opentracing的协议，采集链路调用信息发送至收集端，经分析处理后存储到Elasticsearch；同时，采集性能指标和日志信息，统一收集并存储到Prometheus和Elasticsearch；

S63、加载该实验观测面板包含的所有观测部件，并传递当前演练的实例信息；各个观测部件基于自身布局属性和接口属性，结合当前实例信息将过滤后的采集数据进行渲染展示；并支持自动获取演练的实际开始时间和各个故障的注入时间，实时在观测部件的图表中进行颜色反显标域，以聚焦关键演练时段的数据；

S64、基于实时链路调用分析和相关感知接口，动态刷新实验架构感知图，进而实现演练过程中对包括集群、节点、服务层面的全局观测；

S7、演练完毕；

演练计划完成后，将全程的观测数据以图文结合的方式自动导入演练结果报告。

优选的，步骤S2中的数据采集方式包括agent、SDK、API，首选java agent的字节码注入方式；采集的信息包括链路调用、性能指标和日志。

优选的，步骤S3中的相关参数包括目标对象、注入故障类型、串行或并行方式、故障爆炸半径、周期运行方式、故障持续时间、故障应急终止条件、用于验证实验是否符合预期的稳态指标。

优选的，步骤S4具体为，针对指定的演练计划，多模型融合推荐算法采用线性加权融合算法针对注入故障与观测部件的关联性、配置管理数据库以及历史的演练数据，融合“基于关联规则的推荐算法”和“基于模型的推荐算法”进行加权、层叠和混合，自动生成最佳观测效果的可视化观测面板。

优选的，步骤S64中实验架构感知图中的要素包括k8s集群资源动态拓扑、节点与服务之间的依附关系、爆炸半径影响度指示、节点可用性动态指示。

优选的，实验架构感知图中各要素分别通过如下方式进行动态感知，

A、调用kube-apiserver的Discovery和RESTMapper接口，动态感知k8s集群资源拓扑变化；

B、基于链路调用，抽样分析各个服务接口的Trace和Span调用数据，动态感知各服务之间的依赖关系以及各服务与Pod和节点之间的依附关系；

C、调用配置管理数据库的接口获取云原生应用与k8s集群的关系，基于服务链路与Pod和节点的依附关系，动态获取爆炸半径内可能受到影响的应用列表和服务列表；

D、基于性能数据的查询接口，获取包括k8s集群、节点和pod在内的各资源的可用性和性能指标变化。

优选的，步骤S1之前还存在如下内容，

定义和准备混沌故障库、观测部件库、云原生应用模型；

混沌故障库用于存储混沌工程实验所需所有故障的实现，所述故障包括基础设施层的故障、平台层的故障以及应用层的故障；

观测部件库用于针对各层面的故障创建各类观测部件；每个观测部件基于其自身属性具有各自特定的可视化方式和数据加载能力，用以实现对常见单个故障的可视化展示和观测；观测部件库对观测部件进行统一管理，并将对自动智能创建实验观测面板提供底层支持；所述观测部件的主要属性包括部件标题、部件类别、布局参数、接口参数、扩展参数；

云原生应用模型；在配置管理数据库中定义云原生应用模型；所述云原生应用模型的主要属性包括应用名称、应用标识、所属K8s集群和命名空间、关联的数据库和中间件。

本发明的有益效果是：1、本发明将可观测性概念引入至云原生混沌工程实验领域，结合传统CMDB配置、服务调用链路采集分析，以及云原生K8S Api的智能感知，针对演练计划进行智能分析并自动生成可视化观测面板和架构感知图；针对演练的目标对象及爆炸半径，以云原生视角进行影响度分析和自动聚焦观测；针对实验中涉及的云原生资源进行精确关联和分层观测。通过此方式实现的可观测性将大幅提升混沌工程实验的观测能力，协助实验人员在云原生环境下更加准确的验证实验的稳态假说设定，进而极大提高混沌工程实验的有效性。2、本发明针对云原生环境下进行混沌工程实验无法针对性的实现全面观测、无法准确验证实验效果等缺陷；实现了在云原生环境下大幅提升对混沌工程实验的观测能力，协助实验人员更加准确的验证实验的稳态假说设定，进而极大提高混沌工程实验的有效性。

附图说明

图1是本发明实施例二中方法的原理流程示意图；

图2是本发明实施例二中在演练运行时实现可观测性的流程示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不用于限定本发明。

实施例一

本实施例中，提供了一种针对云原生混沌工程实验实现可观测性的方法，在实现该方法之前需要先定义和准备混沌故障库、观测部件库、云原生应用模型；

1、所述混沌故障库：用于存储混沌工程实验所需所有故障的实现，所述故障包括基础设施层的故障、平台层的故障以及应用层的故障；所述基础设施层的故障包括网络故障、存储故障、CPU故障等；所述平台层的故障包括k8s核心组件故障、kubelet故障、pod故障、中间件故障等；所述应用层的故障包括服务调用延迟故障、并发QPS下降故障、数据库慢sql调用故障、jvm故障等。

2、观测部件库：用于针对各层面的故障创建各类观测部件(obsv-widget)；每个观测部件基于其自身属性具有各自特定的可视化方式和数据加载能力，用以实现对常见单个故障的可视化展示和观测；观测部件库对观测部件进行统一管理，并将对自动智能创建实验观测面板(obsv-dashboard)提供底层支持；所述观测部件的主要属性包括部件标题、部件类别、布局参数、接口参数、扩展参数。

3、云原生应用模型：在配置管理数据库(Configuration Management Database，简称CMDB)中定义云原生应用模型；所述云原生应用模型的主要属性包括应用名称、应用标识、所属K8s集群和命名空间、关联的数据库和中间件等。

当混沌故障库、观测部件库、云原生应用模型定义且准备好之后，即可实现本发明方法。本发明方法包括如下步骤：

一、创建云原生应用对象

实验人员结合实际业务系统的架构部署情况，基于云原生应用模型创建各个应用对象，同时采用K8s API自动检索应用对象所属的K8s集群和命名空间(Namespace)中包含的所有节点(Node)；将应用对象和节点存储在配置管理数据库(CMDB)内，作为后续实验的目标对象。

二、部署可观测性数据采集方式

针对K8s集群中各云原生应用，配置相应的数据采集方式；数据采集方式主要包括agent、SDK、API；其中，首选java agent的字节码注入方式，可最大程度减少对目标对象的代码侵入；采集的信息包括链路调用、性能指标和日志。

三、创建混沌工程实验的演练计划

创建复杂的演练流程并配置演练必备的相关参数；相关参数包括目标对象、注入故障类型、串行或并行方式、故障爆炸半径、周期运行方式、故障持续时间、故障应急终止条件、用于验证实验是否符合预期的稳态指标等。

四、构建实验观测面板

针对指定的演练计划，采用多模型融合推荐算法，自动生成最佳观测效果的可视化的实验观测面板；

具体的，针对指定的演练计划，多模型融合推荐算法采用线性加权融合算法针对注入故障与观测部件的关联性、配置管理数据库以及历史的演练数据等，融合“基于关联规则的推荐算法”和“基于模型的推荐算法”进行加权(Weight)、层叠(Cascade)、混合(Mixed)，以提升算法的性能与准确度，最终自动生成最佳观测效果的可视化观测面板。

例如：注入故障类型为主机节点CPU高负荷，则将会对应添加相关主机节点的CPU使用率曲线观测部件、节点所涉及应用系统的相关观测部件，以及此节点输出日志的观测部件等，并结合历史演练数据分析用户的观测习惯，完成展示内容和布局的优化，最终生成演练关联的可视化观测面板，同时也支持实验人员进行手工调整。

五、生成实验架构感知图

针对故障注入的目标对象和爆炸半径以及配置管理数据库内云原生应用的关联关系，通过调用kube-apiserver的Discovery和RESTMapper等接口，自动绘制K8s集群的可观测性拓扑图(obsv-topolog)，即实验架构感知图，并在可观测性拓扑图中明确标识目标对象以及爆炸半径内涉及的所有K8s资源对象。

六、运行演练计划

开始运行演练计划，注入实验故障和流量，结合关联的实验观测面板和实验架构感知图，实时掌控演练进度、目标对象状态、爆炸半径影响度、关联应用影响度等情况，进而实现对实验效果的全面观测；

在该过程中，在演练运行时实现可观测性的处理流程如下，

1、运行演练计划，生成演练实例对象，并将实例信息传递至关联的实验观测面板和实验架构感知图；

2、可观测性数据采集端基于兼容opentracing的协议，采集链路调用信息发送至收集端(obs-collector)，经分析处理后存储到Elasticsearch；同时，采集性能指标和日志信息，统一收集并存储到Prometheus和Elasticsearch；

3、加载该实验观测面板包含的所有观测部件，并传递当前演练的实例信息；各个观测部件基于自身布局属性和接口属性，结合当前实例信息将过滤后的采集数据进行渲染展示；并支持自动获取演练的实际开始时间和各个故障的注入时间，实时在观测部件的图表中进行颜色反显标域，以聚焦关键演练时段的数据；

4、基于实时链路调用分析和相关感知接口，动态刷新实验架构感知图，进而实现演练过程中对包括集群、节点、服务层面的全局观测；

实验架构感知图中的要素包括k8s集群资源动态拓扑、节点与服务之间的依附关系、爆炸半径影响度指示、节点可用性动态指示。实验架构感知图中各要素分别通过如下方式进行动态感知，

A、调用kube-apiserver的Discovery和RESTMapper接口，动态感知k8s集群资源拓扑变化；

B、基于链路调用，抽样分析各个服务接口的Trace和Span调用数据，动态感知各服务之间的依赖关系以及各服务与Pod和节点之间的依附关系；

C、调用配置管理数据库的接口获取云原生应用与k8s集群的关系，基于服务链路与Pod和节点的依附关系，动态获取爆炸半径内可能受到影响的应用列表和服务列表；

D、基于性能数据的查询接口，获取包括k8s集群、节点和pod在内的各资源的可用性和性能指标变化。

七、演练完毕

演练计划完成后，将全程的观测数据以图文结合的方式自动导入演练结果报告，以协助实验人员进行实验预期判定、复盘分析和优化改进。同时也支持实验人员手工对实验效果进行打分和评价，以协助提升后续实验观测能力。

本实施例中，一些相关技术术语的说明如下：

K8s拥有一些内置的资源，比如说Cluster、Namespace、Node、Pod、Deployment等，其中Pod是K8s中最小管理单位，它是一个或多个容器的组合，通常通过其他类型的内置资源来创建和管理Pod。

Elasticsearch是一个分布式、高扩展、高实时的搜索与数据分析引擎。具备强大的数据搜索和分析处理能力。

Prometheus是一套开源的系统监控报警框架，作为新一代的云原生监控系统，同时也支持多种exporter采集数据，以及pushgateway进行数据上报，Prometheus性能足够支撑上万台规模的集群。

可观测性(Observability)，本质上是指系统可以根据外部输出推断内部运行状态的过程。通常可定义为对IT基础设施以及服务或应用程序的运行状态进行度量和观测的能力及相关技术，主要包括指标(Metrics)、日志(Logging)、链路追踪(Tracing)三个维度。

OpenTracing和OpenTelemetry：OpenTracing定义了Trace的数据格式，可以基于这个标准，实现不同组件的Trace数据进行兼容。另一个协议是Google发起的OpenCensus，OpenCensus除了Trace外还定义了Metric。OpenTracing和OpenCensus在云原生CNCF的大旗下最终合并成了OpenTelemetry，并成为了当今可观察性的一个准标准协议。

实施例二

如图1和图2所示，本实施例中，通过一个具体的混沌工程实验，来描述在云原生环境下如何通过本发明方法实现可观测性。

首先方法执行之前还是要先定义和准备如下相关组件：

1、混沌故障库：用于存储混沌工程实验所需所有故障的实现，包括：基础设施层、平台层、应用层的各类故障实现，例如：云原生k8s核心组件故障、kubelet故障、杀死pod、pod cpu满载、pod内存满载、node宕机、node驱逐(Node Drain)等。

2、观测部件库：针对各层面的故障，创建各类对常见单个故障具备可视化观测能力的观测部件obsv-widget，如：CPU利用率曲线、内存利用率曲线、node状态曲线等；观测部件库对obsv-widget进行统一管理，并将对自动智能创建观测面板obsv-dashboard提供底层支持。

3、云原生应用模型：在CMDB(Configuration Management Database，配置管理数据库)中定义云原生应用模型，模型主要属性包括：应用名称、应用标识、所属Kubernetes集群和Namespace命名空间、关联的数据库和中间件等。

上述三个相关组件定义和准备好之后，即可执行本发明的方法，如图1所示，具体过程如下：

一、创建云原生应用对象

梳理业务应用架构部署，具体架构情况为，在k8s-ClusterA集群中包含10个节点，分别为node01～node10，部署有三个java应用系统分别对应k8s的命名空间ns-appA、ns-appB、ns-appC。开始创建三个云原生应用对象appA、appB、appC，并设置应用模型属性值，同时采用k8s API自动检索应用对象所包含运行实例pod对应依赖的node。如获知：appA依赖node01～06，appB依赖node04～08，appC依赖node09～10。

二、部署可观测性数据采集方式

针对k8s-ClusterA集群中三个云原生应用均部署javaagent，基于字节码方式进行可观测性数据采集，收集端配置为obs-collector地址。

三、创建混沌工程实验的演练计划

创建一个混沌工程实验，本次实验主要目标为：验证appA应用的高可用性，以及单台主机节点发生宕机故障后对各应用的影响情况。

四、构建实验观测面板

针对pod CPU满载和node节点宕机故障，基于推荐算法自动从实验观测部件库中选取最佳观测部件(obsv-widget)组合，如：cpu利用率曲线、node可用性曲线、接口请求QPS曲线等，生成可视化观测面板obsv-dashboard；同时针对稳态指标设定、历史演练记录等进行深入模型计算分析，也会将节点和应用等相关观测部件进行补充，以保证对具体监控指标进行有效观测。

五、生成实验架构感知图

针对故障注入的目标对象pod，以及爆炸半径节点node01～06，以及CMDB内云原生应用appA、appB、appC的定义，通过调用kube-apiserver的Discovery和RESTMapper等接口，自动绘制Kubernetes集群可观测性拓扑图(obsv-topolog)，即实验架构感知图，并在拓扑图中明确标识目标对象和爆炸半径内node01～06节点对象。

六、运行演练计划

在正式开始故障演练前，通常首先确保可观测性数据采集正常和(非生产环境下)压测流量注入正常；然后开始注入实验故障，利用实验观测面板可实时掌控演练进度、故障注入是否成功、目标对象状态、各具体监控指标等技术细节；利用实验架构感知图可实时从集群和业务的更高维度，观测爆炸半径影响度、关联应用影响度等情况，实现对实验效果的全面掌控。

该步骤中，如图2所示，在演练运行时实现可观测性的处理流程具体为，

1、加载演练计划，并生成实例对象；

2、通过实例对象，获取(已在步骤四中构建的)当前演练实例关联的实验观测面板(obsv-dashboard)；

3、实验观测面板遍历并传递实例对象给所包含观测部件，如：cpu利用率曲线、node可用性曲线、接口请求QPS曲线等；各obsv-widget基于自身布局属性完成初始化展示；

4、实验观测面板内各个观测部件，基于接口属性配置，访问可观测性相关接口，如obs-query接口，获取可观测性相关采集数据，并完成数据的实时渲染；

4.1、当故障A(cpu满载)注入时，可显著的观测到，指定pod和所属node的CPU利用率曲线值突然升高至90％左右，而由于应用appA中服务实例均采用多副本方式部署，通过应用维度的obsv-widget观测到其各服务接口调用均返回成功(状态码200)，仅个别调用时延有些较大，但应用appA的整体QPS正常保持在100及以上：

4.2、当故障B(node关机)注入时，可观测到(被随机选中的)node06节点的CPU利用率数据获取失败，但由于k8s自身具备的负载均衡和探活机制，应用appA的服务均可用且调用时延及QPS均正常无明显影响；应用appB中部分服务会有短暂时间不可用，后续自动恢复正常；应用appC无影响；

5、通过实例对象，获取(已在步骤五中构建的)当前演练实例关联的架构感知图；

6、在明确标识目标对象和爆炸半径内node01～06节点的实验架构感知图上，基于k8s api资源接口、CMDB配置接口、链路调用接口、性能查询接口，实时获取可观测性相关采集数据，并完成实验架构感知图的实时刷新，直观的图中显示cluster、node、pod以及应用的关联关系；

6.1、当故障A(cpu满载)注入时，可在实验架构感知图中观测到pod所在node节点cpu性能指标有变化；

6.2、当故障B(node关机)注入时，可在实验架构感知图中，直接观测到(被随机选中的)node06节点变灰(不可用状态)，同时其上的所有pod均被k8s系统重新调度至其他node节点；通过图中pod与node的关联关系，可以观察到应用appA为多副本方式部署，而appB和appC均采用单副本部署，并且仅appC未依赖node06节点。这也验证了应用appB在故障B注入的前期，有短暂时间不可用的原因。

七、演练完毕

演练计划完成后，会将全程的观测数据以图文结合方式自动导入演练结果报告，以协助实验人员进行实验预期判定、复盘分析和优化改进。同时也支持实验人员手工对实验效果进行打分和评价，以协助提升后续实验观测能力。另外本次混沌工程实验也发现了应用appB和appC在高可用性方面存在缺陷。

通过采用本发明公开的上述技术方案，得到了如下有益的效果：

本发明提供了一种针对云原生混沌工程实验实现可观测性的方法，本发明将可观测性概念引入至云原生混沌工程实验领域，结合传统CMDB配置、服务调用链路采集分析，以及云原生K8S Api的智能感知，针对演练计划进行智能分析并自动生成可视化观测面板和架构感知图；针对演练的目标对象及爆炸半径，以云原生视角进行影响度分析和自动聚焦观测；针对实验中涉及的云原生资源进行精确关联和分层观测。通过此方式实现的可观测性将大幅提升混沌工程实验的观测能力，协助实验人员在云原生环境下更加准确的验证实验的稳态假说设定，进而极大提高混沌工程实验的有效性。本发明针对云原生环境下进行混沌工程实验无法针对性的实现全面观测、无法准确验证实验效果等缺陷；实现了在云原生环境下大幅提升对混沌工程实验的观测能力，协助实验人员更加准确的验证实验的稳态假说设定，进而极大提高混沌工程实验的有效性。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。

Claims (7)

1.一种针对云原生混沌工程实验实现可观测性的方法，其特征在于：包括如下步骤，

S1、创建云原生应用对象；

实验人员结合实际业务系统的架构部署情况，基于云原生应用模型创建各个应用对象，同时采用K8s API自动检索应用对象所属的K8s集群和命名空间中包含的所有节点；将应用对象和节点存储在配置管理数据库内，作为后续实验的目标对象；

S2、部署可观测性数据采集方式；

针对K8s集群中各云原生应用，配置相应的数据采集方式；

S3、创建混沌工程实验的演练计划；

创建复杂的演练流程并配置演练必备的相关参数；

S4、构建实验观测面板；

针对指定的演练计划，采用多模型融合推荐算法，自动生成最佳观测效果的可视化的实验观测面板；

S5、生成实验架构感知图；

针对故障注入的目标对象和爆炸半径以及配置管理数据库内云原生应用的关联关系，通过调用kube-apiserver的Discovery和RESTMapper接口，自动绘制K8s集群的可观测性拓扑图，即实验架构感知图，并在可观测性拓扑图中明确标识目标对象以及爆炸半径内涉及的所有K8s资源对象；

S6、运行演练计划；

开始运行演练计划，注入实验故障和流量，结合关联的实验观测面板和实验架构感知图，实时掌控演练进度、目标对象状态、爆炸半径影响度、关联应用影响度，进而实现对实验效果的全面观测；

步骤S6中，在演练运行时实现可观测性的处理流程如下，

S61、运行演练计划，生成演练实例对象，并将实例信息传递至关联的实验观测面板和实验架构感知图；

S62、可观测性数据采集端基于兼容opentracing的协议，采集链路调用信息发送至收集端,经分析处理后存储到Elasticsearch；同时，采集性能指标和日志信息，统一收集并存储到Prometheus和Elasticsearch；

S63、加载该实验观测面板包含的所有观测部件，并传递当前演练的实例信息；各个观测部件基于自身布局属性和接口属性，结合当前实例信息将过滤后的采集数据进行渲染展示；并支持自动获取演练的实际开始时间和各个故障的注入时间，实时在观测部件的图表中进行颜色反显标域，以聚焦关键演练时段的数据；

S64、基于实时链路调用分析和相关感知接口，动态刷新实验架构感知图，进而实现演练过程中对包括集群、节点、服务层面的全局观测；

S7、演练完毕；

演练计划完成后，将全程的观测数据以图文结合的方式自动导入演练结果报告。

2.根据权利要求1所述的针对云原生混沌工程实验实现可观测性的方法，其特征在于：步骤S2中的数据采集方式包括agent、SDK、API，首选java agent的字节码注入方式；采集的信息包括链路调用、性能指标和日志。

3.根据权利要求1所述的针对云原生混沌工程实验实现可观测性的方法，其特征在于：步骤S3中的相关参数包括目标对象、注入故障类型、串行或并行方式、故障爆炸半径、周期运行方式、故障持续时间、故障应急终止条件、用于验证实验是否符合预期的稳态指标。

4.根据权利要求1所述的针对云原生混沌工程实验实现可观测性的方法，其特征在于：步骤S4具体为，针对指定的演练计划，多模型融合推荐算法采用线性加权融合算法针对注入故障与观测部件的关联性、配置管理数据库以及历史的演练数据，融合“基于关联规则的推荐算法”和“基于模型的推荐算法”进行加权、层叠和混合，自动生成最佳观测效果的可视化观测面板。

5.根据权利要求1所述的针对云原生混沌工程实验实现可观测性的方法，其特征在于：步骤S64中实验架构感知图中的要素包括k8s集群资源动态拓扑、节点与服务之间的依附关系、爆炸半径影响度指示、节点可用性动态指示。

6.根据权利要求5所述的针对云原生混沌工程实验实现可观测性的方法，其特征在于：实验架构感知图中各要素分别通过如下方式进行动态感知，

A、调用kube-apiserver的Discovery和RESTMapper接口，动态感知k8s集群资源拓扑变化；

B、基于链路调用，抽样分析各个服务接口的Trace和Span调用数据，动态感知各服务之间的依赖关系以及各服务与Pod和节点之间的依附关系；

C、调用配置管理数据库的接口获取云原生应用与k8s集群的关系，基于服务链路与Pod和节点的依附关系，动态获取爆炸半径内可能受到影响的应用列表和服务列表；

D、基于性能数据的查询接口，获取包括k8s集群、节点和pod在内的各资源的可用性和性能指标变化。

7.根据权利要求1至6任一所述的针对云原生混沌工程实验实现可观测性的方法，其特征在于：步骤S1之前还存在如下内容，

定义和准备混沌故障库、观测部件库、云原生应用模型；

混沌故障库用于存储混沌工程实验所需所有故障的实现，所述故障包括基础设施层的故障、平台层的故障以及应用层的故障；

观测部件库用于针对各层面的故障创建各类观测部件；每个观测部件基于其自身属性具有各自特定的可视化方式和数据加载能力，用以实现对常见单个故障的可视化展示和观测；观测部件库对观测部件进行统一管理，并将对自动智能创建实验观测面板提供底层支持；所述观测部件的主要属性包括部件标题、部件类别、布局参数、接口参数、扩展参数；

云原生应用模型；在配置管理数据库中定义云原生应用模型；所述云原生应用模型的主要属性包括应用名称、应用标识、所属K8s集群和命名空间、关联的数据库和中间件。

Images