优维「Easy分析」：一款故障根因分析小神器

本文主要是介绍优维「Easy分析」：一款故障根因分析小神器，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

背景

随着微服务架构的普及，现代企业的IT基础设施已经变得越来越复杂。单一的服务可能有多个下游依赖，而这些依赖又可能有自己的子依赖，和主机资源的依赖。在这样的环境中，当某个服务发生故障，确定具体的原因变得尤为困难。传统的故障排查方法，如手动检查日志或询问开发团队，既耗时又不一定能找到真正的根源。

此外，随着DevOps和持续集成/持续部署（CI/CD）的普及，应用的发布频率大大增加，这使得发布引起的服务中断变得更为常见。同时，资源和基础设施的动态性也为故障诊断带来了挑战。

为了应对这些挑战，优维设计了“Easy分析”服务故障根因分析工具，旨在为技术团队提供一个集成、自动化的解决方案，帮助其迅速、准确地定位服务故障时的原因。

下面，从具体场景出发，详细介绍服务故障根因分析工具。

应用发布导致的服务故障

1.1 概述

应用发布可能导致服务运行出现不稳定或其他未预期的影响。当服务发出告警时，本功能将自动分析告警指标，检测服务或其下游服务在最近是否发生过变更。

1.2 核心功能

变更检测：当服务告警时，系统会自动检测与告警相关的服务是否近期有变更事件，如启动、关闭、升级或重启等。
双态部署事件联动：与双态部署系统紧密集成，获取最新的部署和变更事件信息。
告警与变更关联：为告警事件提供直接与变更事件的关联，帮助团队快速确定是否有发布活动导致的故障。
消费CMDB数据：根据cmdb的服务相关的模型，自动关联下游服务的变更事件

1.3 场景说明及配置

假设微服务集群中，提供了一个名为flounder_metric的服务。服务的请求一般是从api_gateway接入到集群中，并且基于url路由至具体的应用组件来处理请求。因此，在这个场景中，存在这样一个调用关系：api_gateway -> flounder_metric

在服务监控中，我们会对flounder_metric的接口进行拨测。配置的步骤如下：

建立内网拨测策略，指定监控的应用是「http-logic.api_gateway」，它是api_gateway应用的服务标识；
配置关于flounder_metric服务的接口，在变量定义中，通过$.subservices.ip会自动获取到服务下子服务的IP地址。

保存后即可。

此时配置基于detect_code的告警规则，即可完成对该接口的监控。

1.4 故障触发和根因分析

我们人为触发一个服务告警，通过双态部署，关闭flounder_metric服务。

稍后，将触发一个拨测告警：

我们通过事件详情，点击故障分析：

此时将看到故障分析页面，让我们来解释一下：

上方是告警事件的告警对象和告警指标持续的时间，可以看到告警持续时间范围是 11:55~12:04。

接下来就是根因分析的结论，一共发现1个结论，和应用发布的变更相关。具体来说，有两个分析：

http-logic.api_gateway有告警事件，没有变更事件，说明不是api_gatewaya变更导致；
由于api_gateway的下游是flounder_metric服务，而该服务在12:00分发生了停止操作，进而触发了告警，因此分析为：下游HTTP服务http-logic.flounder_metric的变更导致的故障（这也是此次故障的真正原因）。

1.5 结论

在微服务架构中，服务间的相互依赖和频繁的应用发布行为可能会导致复杂的故障情况。在本场景中，通过"服务故障根因分析"工具，我们成功地自动检测到flounder_metric服务的停止操作是导致api_gateway服务拨测告警的直接原因。该工具能够智能地关联告警事件与近期的应用变更，准确快速地定位到真实的故障原因。

此次案例展示了"服务故障根因分析"工具的核心功能，即自动识别与故障相关的变更，并为技术团队提供明确的、数据驱动的根因分析。此功能大大减少了故障诊断时间，并提高了故障恢复的效率。

依赖资源高负载导致的服务故障

2.1 概述

服务的性能和稳定性可能受到其运行环境的影响，特别是当它依赖的资源或子服务处于高负载状态时。本功能提供了与资源负载告警的自动关联能力，帮助识别故障的根本原因。

2.2 核心功能