根因分析告警（进行根因分析的要素）

本篇文章给大家谈谈根因分析告警，以及进行根因分析的要素对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享根因分析告警的知识，其中也会对进行根因分析的要素进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、相比传统运维工具，AIOps的优势在哪里
• 2、根因分析法是什么？
• 3、IT运维平台算法背后的两大“神助攻”
• 4、系统管理提供什么,日志管理和备份恢复功能。

相比传统运维工具，AIOps的优势在哪里

所谓的AIOps，简单理解就是基于自动化运维，将AI和运维很好的结合起来。

AIOps的落地在多方面直击传统运维的痛点，AI算法承担起分析海量运维数据的重任，能够自动、准确地发现和定位问题，从决策层面提高运营效率，为企业运营和运维工作在成本、质量和效率方面的优化提供了重要支持。

可见，AIOps 在企业中的作用正在进一步放大。但事实上，很多企业对于AIOps 能解决什么问题并不清晰，今天我们就以博睿数据的AIOps 的三大场景和算法说起。

博睿数据的AIOps 实践

作为中国领先的智能可观测平台，在AIOps实践方面，多年来博睿数据积极拥抱人工智能、机器学习等新技术变革的浪潮，并基于AI和机器学习技术，自主研发了“数据接入、处理、存储与分析技术”核心技术体系，全面布局智能基线、异常检测、智能告警、关联分析、根因分析等丰富且广泛的智能运维功能，并将AIOps能力融入端到端全栈监控产品线，可为传统企业提供强大的数据处理、存储和分析的软件工具，帮助客户整合各类IT运维监控数据，实现数据的统一存储和关联分析，打破数据孤岛，构建统一的IT运维管理平台，让企业的IT运维更加智能化、自动化。

在此基础上，博睿数据还依托完整的IT运维监控能力，利用大数据和机器学习技术持续构建先进的智能运维监控产品，2021年先后推出了搭载了AI能力的新一代APM产品Server7.0和新版的统一智能运维平台Dataview，不断落地智能异常检测、根因分析、故障预测等场景。基于人工智能的能力实现运维监控场景的信息整合、特征关联和业务洞察，帮助企业确保数字化业务平稳运行，并保障良好的数字化体验。

目前，博睿数据在AIOps 技术方面主要落地了三大场景。即智能基线预测、异常检测及告警收敛。

随着企业业务规模扩大，云原生与微服务的兴起，企业IT架构复杂性呈现指数级增长。而传统的IT运维手段面临故障发生后，查找故障原因困难，故障平均修复时间周期长，已无法满足新的运维要求。因此运用人工智能赋能运维，去取代缓慢易错的人力决策，快速给出运维决策建议，降低问题的影响并提前预警问题就成为了必然。AIOps作为目前运维发展的最高阶目标，未来将会赋能运维带给用户全新的体验。

但需要注意的是，当前智能运维的很多产品和项目在企业侧落地效果并不理想，究其原因可归类为三点：一是数据采集与AI平台割裂，多源数据之间的关联关系缺失导致AI平台缺乏高质量的数据，进而导致模型训练效果不佳；二是数据采集以metric和log为主，导致应用场景较窄且存在数据孤岛问题；三是AI平台能力尚有提升空间。当前落地的场景多以异常检测与智能告警为主，未来需要进一步提升根因分析与故障预测的能力。

因此，未来企业首先要建设一体化监控运维平台，一体化是智能化的基础。基于一体化监控运维平台采集的高质量的可观测数据数据以及数据之间的关联关系，进一步将AIOps的能力落地到一体化监控运维平台中，从而实现问题精准定位与见解能力。

此外，在实际应用中，依据信通院的相关调查，其受访企业中只有不足20%的企业具有智能化监控和运维决策能力，超过70%的企业在应用系统出现故障的10分钟内一筹莫展。

各行业的数字化转型正在改变这一现状，不仅互联网企业，更多传统企业的数字化转型为智能运维开拓了更广阔的市场，智能运维有着巨大的发展空间，这也是博睿数据等行业领先企业发力的大好时机。

提升创新能力，推广智能运维不仅是相关服务商自身发展的要求，也是提升我国企业应用管理和运维水平的使命。

中国企业数字化转型加速，无论是前端的应用服务迭代更新，还是后端IT运维架构的复杂度提升，都在加速培育智能运维的成长。

根因分析法是什么？

根因分析是一项结构化的问题处理法，用以逐步找出问题的根本原因并加以解决， 而不是仅仅关注问题的表征。

所谓根本原因，就是导致我们所关注的问题发生的最基本的原因。因为引起问题的原因通常有很多，物理条件、人为因素、系统行为、或者流程因素等等，通过科学分析，有可能发现不止一个根源性原因。

分析要领：

1、提问为什么会发生当前情况， 并对可能的答案进行记录。

根本原因分析法的目的就是要努力找出问题的作用因素，并对所有的原因进行分析。这种方法通过反复问一个为什么，能够把问题逐渐引向深入，直到你发现根本原因。

2、找到根本原因后，就要 评估改变根本原因的最佳方法，从而从根本上解决问题。

这是另一个独立的过程，一般被称之为 改正和预防。当我们在寻找根本原因的时候，必须要记住对每一个已找出的原因也要进行评估，给出改正的办法，因为这样做也将有助于整体改善和提高。

以上内容参考：百度百科-根本原因分析

IT运维平台算法背后的两大“神助攻”

智能运维(AIops)是目前 IT 运维领域最火热根因分析告警的词汇根因分析告警，全称是 Algorithmic IT operations platforms根因分析告警，正规翻译是『基于算法的 IT 运维平台』，直观可见算法是智能运维的核心要素之一。
本文主要谈算法对运维的作用，涉及异常检测和归因分析两方面，围绕运维系统Kale 中 skyline、Oculus 模块、Opprentice 系统、Granger causality（格兰杰因果关系）、FastDTW 算法等细节展开。

一、异常检测

异常检测，是运维工程师们最先可能接触的地方了。毕竟监控告警是所有运维工作的基础。设定告警阈值是一项耗时耗力的工作，需要运维人员在充分了解业务的前提下才能进行，还得考虑业务是不是平稳发展状态，否则一两周改动一次，运维工程师绝对是要发疯的。

如果能将这部分工作交给算法来解决，无疑是推翻一座大山。这件事情，机器学习当然可以做到。但是不用机器学习，基于数学统计的算法，同样可以，而且效果也不差。

异常检测之Skyline异常检测模块

2013年，Etsy 开源了一个内部的运维系统，叫 Kale。其中的 skyline 部分，就是做异常检测的模块， 它提供了 9 种异常检测算法 ：

first_hour_average、

simple_stddev_from_moving_average、

stddev_from_moving_average、

mean_subtraction_cumulation、

least_squares

histogram_bins、

grubbs、

median_absolute_deviation、

Kolmogorov-Smirnov_test

简要的概括来说，这9种算法分为两类：

从正态分布入手：假设数据服从高斯分布，可以通过标准差来确定绝大多数数据点的区间；或者根据分布的直方图，落在过少直方里的数据就是异常；或者根据箱体图分析来避免造成长尾影响。

从样本校验入手：采用 Kolmogorov-Smirnov、Shapiro-Wilk、Lilliefor 等非参数校验方法。

这些都是统计学上的算法，而不是机器学习的事情。当然，Etsy 这个 Skyline 项目并不是异常检测的全部。

首先，这里只考虑了一个指标自己的状态，从纵向的时序角度做异常检测。而没有考虑业务的复杂性导致的横向异常。其次，提供了这么多种算法，到底一个指标在哪种算法下判断的更准根因分析告警？这又是一个很难判断的事情。

问题一： 实现上的抉择。同样的样本校验算法，可以用来对比一个指标的当前和历史情况，也可以用来对比多个指标里哪个跟别的指标不一样。

问题二： Skyline 其实自己采用了一种特别朴实和简单的办法来做补充——9 个算法每人一票，投票达到阈值就算数。至于这个阈值，一般算 6 或者 7 这样，即占到大多数即可。

异常检测之Opprentice系统

作为对比，面对相同的问题，百度 SRE 的智能运维是怎么处理的。在去年的 APMcon 上，百度工程师描述 Opprentice 系统的主要思想时，用了这么一张图：

Opprentice 系统的主体流程为：

KPI 数据经过各式 detector 计算得到每个点的诸多 feature；

通过专门的交互工具，由运维人员标记 KPI 数据的异常时间段；

采用随机森林算法做异常分类。

其中 detector 有14种异常检测算法，如下图：

我们可以看到其中很多算法在 Etsy 的 Skyline 里同样存在。不过，为避免给这么多算法调配参数，直接采用的办法是：每个参数的取值范围均等分一下——反正随机森林不要求什么特征工程。如，用 holt-winters 做为一类 detector。holt-winters 有α，β，γ 三个参数，取值范围都是 [0, 1]。那么它就采样为 (0.2, 0.4, 0.6, 0.8)，也就是 4 ** 3 = 64 个可能。那么每个点就此得到  64  个特征值。

异常检测之

Opprentice 系统与 Skyline 很相似

Opprentice 系统整个流程跟 skyline 的思想相似之处在于先通过不同的统计学上的算法来尝试发现异常，然后通过一个多数同意的方式/算法来确定最终的判定结果。

只不过这里百度采用了一个随机森林的算法，来更靠谱一点的投票。而 Etsy 呢？在 skyline 开源几个月后，根因分析告警他们内部又实现了新版本，叫 Thyme。利用了小波分解、傅里叶变换、Mann-whitney 检测等等技术。

另外，社区在 Skyline 上同样做了后续更新，Earthgecko 利用 Tsfresh 模块来提取时序数据的特征值，以此做多时序之间的异常检测。我们可以看到，后续发展的两种 Skyline，依然都没有使用机器学习，而是进一步深度挖掘和调整时序相关的统计学算法。

开源社区除了 Etsy，还有诸多巨头也开源过各式其他的时序异常检测算法库，大多是在 2015 年开始的。列举如下：

Yahoo! 在去年开源的 egads 库。(Java)

Twitter 在去年开源的 anomalydetection 库。(R)

Netflix 在 2015 年开源的 Surus 库。(Pig，基于PCA)

其中 Twitter 这个库还被 port 到 Python 社区，有兴趣的读者也可以试试。

二、归因分析

归因分析是运维工作的下一大块内容，就是收到报警以后的排障。对于简单故障，应对方案一般也很简单，采用 service restart engineering~ 但是在大规模 IT 环境下，通常一个故障会触发或导致大面积的告警发生。如果能从大面积的告警中，找到最紧迫最要紧的那个，肯定能大大的缩短故障恢复时间(MTTR)。

这个故障定位的需求，通常被归类为根因分析（RCA，Root Cause Analysis）。当然，RCA 可不止故障定位一个用途，性能优化的过程通常也是 RCA 的一种。

归因分析之 Oculus 模块

和异常检测一样，做 RCA 同样是可以统计学和机器学习方法并行的~我们还是从统计学的角度开始。依然是 Etsy 的 kale 系统，其中除了做异常检测的 skyline 以外，还有另外一部分，叫 Oculus。而且在 Etsy 重构 kale 2.0 的时候，Oculus 被认为是1.0 最成功的部分，完整保留下来了。

Oculus 的思路，用一句话描述，就是：如果一个监控指标的时间趋势图走势，跟另一个监控指标的趋势图长得比较像，那它们很可能是被同一个根因影响的。那么，如果整体 IT 环境内的时间同步是可靠的，且监控指标的颗粒度比较细的情况下，我们就可能近似的推断：跟一个告警比较像的最早的那个监控指标，应该就是需要重点关注的根因了。

Oculus 截图如下：

这部分使用的 计算方式有两种：

欧式距离，就是不同时序数据，在相同时刻做对比。假如0分0秒，a和b相差1000，0分5秒，也相差1000，依次类推。

FastDTW，则加了一层偏移量，0分0秒的a和0分5秒的b相差1000，0分5秒的a和0分10秒的b也相差1000，依次类推。当然，算法在这个简单假设背后，是有很多降低计算复杂度的具体实现的，这里就不谈了。

唯一可惜的是 Etsy 当初实现 Oculus 是基于 ES 的 0.20 版本，后来该版本一直没有更新。现在停留在这么老版本的 ES 用户应该很少了。除了 Oculus，还有很多其他产品，采用不同的统计学原理，达到类似的效果。

归因分析之 Granger causality

Granger causality（格兰杰因果关系）是一种算法，简单来说它通过比较“已知上一时刻所有信息，这一时刻 X 的概率分布情况”和“已知上一时刻除 Y 以外的所有信息，这一时刻 X 的概率分布情况”，来判断 Y 对 X 是否存在因果关系。

可能有了解过一点机器学习信息的读者会很诧异了：不是说机器只能反应相关性，不能反应因果性的么？需要说明一下，这里的因果，是统计学意义上的因果，不是我们通常哲学意义上的因果。

统计学上的因果定义是：『在宇宙中所有其他事件的发生情况固定不变的条件下，如果一个事件 A 的发生与不发生对于另一个事件 B 的发生的概率有影响，并且这两个事件在时间上有先后顺序（A 前 B 后），那么我们便可以说 A 是 B 的原因。』

归因分析之皮尔逊系数

另一个常用的算法是皮尔逊系数。下图是某 ITOM 软件的实现：

我们可以看到，其主要元素和采用 FastDTW 算法的 Oculus 类似：correlation 表示相关性的评分、lead/lag 表示不同时序数据在时间轴上的偏移量。

皮尔逊系数在 R 语言里可以特别简单的做到。比如我们拿到同时间段的访问量和服务器 CPU 使用率：

然后运行如下命令：

acc_count<-scale(acc$acc_count,center=T,scale=T)

cpu<-scale(acc$cpuload5,center=T,scale=T)

cor.test(acc_count,cpu)

可以看到如下结果输出：

对应的可视化图形如下：

这就说明网站数据访问量和 CPU 存在弱相关，同时从散点图上看两者为非线性关系。因此访问量上升不一定会真正影响 CPU 消耗。

其实 R 语言不太适合嵌入到现有的运维系统中。那这时候使用 Elasticsearch 的工程师就有福了。ES 在大家常用的 metric aggregation、bucket aggregation、pipeline aggregation 之外，还提供了一种 matrix aggregation，目前唯一支持的 matrix_stats 就是采用了皮尔逊系数的计算，接口文档见：

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-matrix-stats-aggregation.html

唯一需要注意的就是，要求计算相关性的两个字段必须同时存在于一个 event 里。所以没法直接从现成的 ES 数据中请求不同的 date_histogram，然后计算，需要自己手动整理一遍，转储回 ES 再计算。

饶琛琳，目前就职日志易，有十年运维工作经验。在微博担任系统架构师期间，负责带领11人的SRE团队。著有《网站运维技术与实践》、《ELKstack权威指南》，合译有《Puppet 3 Cookbook》、《Learning Puppet 4》。在众多技术大会上分享过自动化运维与数据分析相关主题。

系统管理提供什么,日志管理和备份恢复功能。

5G 网管具备以下优点：
（1）Web 方式的用户界面。
（2）统一的网络管理（如 4G / 5G 融合）。
（3）网络智能分析。
（4）开放的 API 接口。
（5）虚拟化部署
SaaS：Software as a Service（软件即服务）。
PaaS：Platform as a service（平台即服务）。
IaaS：Infrastructure as a service（基础设施即服务）。
5G 网管软硬件组成：
底层采用服务器提供基础的 CPU、内存、存储等物理资源，通过平台抽取具体资源形成 虚拟网管平台，然后向高层提供网管功能，包括系统管理、自运维管理、智能运维管理和无线 应用等 APP 功能，客户端可远程接入 5G 网管。
5G 网管系统组件包括：
（1）系统管理：提供安全管理、日志管理和备份恢复功能。
（2）自运维管理：提供应用性能管理。
（3）智能运维：提供告警根因分析、网络智能分析高级应用、开发自动化平台和全局策略管理。
（4）无线应用：提供数据采集、北向接口管理、网络智能分析、无线配置管理、无线网元
管理、无线网络运维监控、信令跟踪分析、网元开通升级中心和通用网元管理。
（5）公共应用：提供全网告警和拓扑管理。
5G 网管常用功能包括：
（1）任务说明：任务背景以及规划数据表。
（2）网络规划：规划数据表。
（3）工勘测量：模拟工程勘测及测量。
（4）设备安装：模拟硬件设备的安装。
（5）设备维护：进行数据配置，参数调整。
（6）业务验证：根据配置的数据进行业务的验证，完成任务。
任务二：配置数据
简述PnP开基站的基本流程。
第一步：确认传输是否开启DHCP relay功能。
第二步：UME网管版本入库。
第三步：UME网管前台配置制作
第四步：UME网管创建及启动开站任务，跟踪开站任务
第五步：前台上电
第六步：跟踪UME开站任务是否完成
常用参数：
（1）PLMN：公共陆地移动（通信）网络。
PLMN=MCC ＋ MNC
（2）PCI：物理小区 ID，取值范围为 0 ～ 1007
PCI=PSS ＋ 3SSS （PSS 取值为 0 ～ 2，SSS 取值为 0 ～ 335）
（3）SCTP 本端端口号 / 远端端口号：SCTP 协议端口号，本端端口号常用 38412，远端端 口号常用 38422。
（4）中心频点：小区使用频点，确定小区的中心频率。
（5）频点带宽：小区带宽，FR1 频段的频率范围是 450 MHz ～ 6 GHz，又称为 sub 6 GHz频段。FR2 频段的频率范围是 24.25 ～ 52.6 GHz，通常被称为毫米波 (mmWave)。FR1 频段可使用的最大带宽是100MHz，FR2 频段可使用的最大带宽是 400 MHz。目前现网 5G 主要采用 30 kHz 子载波间隔，带宽是 100 MHz，实际配置根据 5G 场景确定。
（6）每 10 ms 下行资源占比：下行在整个无线帧中所占的比例。与帧结构、符号配比有关。
（7）TAC 跟踪区：有 AMF 分配，若干个小区组成一个 TAC，是寻呼的基本范围。
（8）小区标识：取值为 0 ～ 255，一个基站中的小区 ID 不重复，由集团统一规划。
数据配置：
1．全局参数：
“MCC”：移动国家码，全球唯一。中国为 460。
“MNC”：移动网络码。 各国内运营商唯一，如中国移动为 00。
“OMC 服务器地址”：服务器地址，根据实际的服务器地址填写。
“OMC 前缀长度”：按照网络规划填写。
“SNTP 服务器 IP 地址”：SNTP 服务器用来做时间同步，一般运营商省公司会有 SNTP 服务器。
“时区”：东八区。
站点配置参数：
“子网 ID”：根据规划填写。
“网元 ID”：根据规划填写，网元 ID 不能重复。
“基站名称”：基站名称不是必配的，可以人为规划。
“网元模型类型”：CUDU，唯一值。
“网元 IP 地址”：基站网元地址，该地址用于和网管通信。
3.传输网络配置：
“网元 IP 地址”：根据规划填写。
“IP 前缀”：根据规划填写。
“IP 网关地址”：根据规划填写。
“IP层使用的VLAN标识”：用来隔离IP层，如果配置多个IP，那么VLAN也需要多个（比 如把网管 IP 和业务 IP 分开）。
“偶联号”：根据规划填写。
“SCTP 本端端口号 / 远端端口号”：全网常用的是 38412。
“本端地址 / 远端地址”：根据规划填写。本端地址是网元 IP 地址，远端地址是核心网
AMF 的 IP 地址。
“静态路由配置（目的 IP 地址）”：该地址是核心网 AMF 的 IP 地址。
“静态路由配置（静态路由前缀长度）”：根据规划填写。
“静态路由”：核心网远端 IP 地址和网关不是同一个网段时，需要配置成和远端地址同
一个网段，否则不通。
4.小区配置：
“小区标识”：唯一小区标识，按规划填写。一般由集团统一规划。
“物理小区识别码”：PCI 取值范围为 0 ～ 1007。复用举例内不能重复出现，相邻小区 PCI mod 3 不相等。
“跟踪区码”：一个 AMF 内唯一，由核心网规划。
“频段指示”：指示小区所使用的频段。
“频点带宽”：指示小区带宽。
“切片业务类型”：根据场景配置。
“切片分区”：根据业务填写。
任务三：业务调测
当完成 5G 数据配置之后，如何判断 5G 数据配置是否正确，5G 基站是否能正常开通。这 就需要进行业务调测，测试业务能否正常运行，从而判断 5G 基站是否正常开通。
问题 1：什么是 eMBB ？主要用在什么场景？
答：eMBB 是增强型移动带宽。eMBB 主要是服务于消费互联网，如 AR/VR、高清视频直
播、8K 高清等。对网络的速率要求高，需要大带宽的支持。
问题 2：什么是 uRLLC ？主要用在什么场景？
答：uRLLC 是低时延高可靠通信。uRLLC 主要场景，如车联网、无人机、 工业控制，远程医疗等。对网络的低时延和可靠性的要求均高。
问题 3：什么是 mMTC ？主要用在什么场景？
答：大规模机器连接。mMTC主要是服务于物联网，如：智慧城市（水表，电表，气表，路灯，红绿灯），智能家居（烟感，灯，门锁，家电），智能农业等。
学生需要知道什么场景使用哪一种验证，很关键。
eMBB验证操作：
uRLLC验证操作：
5g
人工智能
大数据


点赞文章给优秀博主打call~
高清播放机，图片大全，点击查看详情！
精选推荐
广告

LTE开站流程
35下载·1评论
2013年8月7日
华为5G基站概述及基本操作.pdf
30下载·0评论
2021年2月7日
5G缩略语 (TS38.101/104/211/212/213/214/300)
4013阅读·0评论·4点赞
2019年3月26日
移动4g华为lte站点故障处理实战手册.docx
0下载·0评论
2020年11月25日
OMC-V3版 Modbus地址功能对应表新(2).zip
3下载·0评论
2019年9月7日
5G基站邻区规划
974阅读·0评论·1点赞
2022年5月18日
你看见在哪个播放器能看？

精选推荐
广告
【通信工程】大三下课程设计-5G核心网功能设计与部署
990阅读·0评论·2点赞
2022年9月24日
智能运维平台包括哪些功能？运维平台有哪些功能模块？
657阅读·0评论·0点赞
2022年10月20日
31省 “5G基建+5G应用”实施路径！（最全汇总）
782阅读·1评论·0点赞
2021年6月4日
amf组网_【5G核心网】5G核心网SA组网方案及4G/5G互操作探讨
2.8W阅读·0评论·1点赞
2021年1月9日
Arduino的软件：Arduino IDE和Mind+图形化编程
2555阅读·0评论·1点赞
2022年8月28日
[4G5G专题-75]：流程 - 4G LTE无线接入网中运营商标识、基站标识、终端标识大全
3754阅读·0评论·5点赞
2021年5月2日
SqlPLus简介
4072阅读·1评论·0点赞
2010年11月14日
PLMN各种类型的含义及说明
1647阅读·0评论·0点赞
2020年7月13日
常见各种PLMN的含义（RPLMN,HPLMN...）以及自动选网原则
2.9W阅读·0评论·11点赞
2015年11月17日
1.springboot使用入门
85阅读·0评论·0点赞
2020年11月4日
volte信令流程详解_点点滴滴学5G——SA注册流程详解
890阅读·0评论·2点赞
2020年11月28日
去首页
看看更多热门内容 关于根因分析告警和进行根因分析的要素的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 根因分析告警的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于进行根因分析的要素、根因分析告警的信息别忘了在本站进行查找喔。