告警根因分析法（故障根因分析）

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

本文目录一览：

• 1、制冷系统产生低压告警的几种原因？
• 2、运维告警管理——告警的灵活分派
• 3、智能运维是如何抑制告警风暴的？
• 4、运维监控工具太多，根因定位不够智能和快速，如何解决？
• 5、故障恢复方法 告警
• 6、华为设备有如下告警,期间并没有修改配置,请分析大概是什么原因

制冷系统产生低压告警的几种原因？

制冷系统产生低压告警的原因有这几种，空调低压故障常见原因有以下九点：
1、空调制冷系统铜管管道过长。
2、空调室内机过滤网脏堵。
3、空调制冷系统中的干燥过滤器脏堵或者铜管管道油堵。
4、空调制冷系统中的低压保护器故障。
5、空调制冷系统中的电磁阀打不开。
6、空调制冷系统中的膨胀阀故障。
7、空调制冷系统中的制冷剂泄露。
8、空调制冷系统冷凝器散热效果太好。
9、空调制冷系统中的回液管道压扁导致回液不顺畅。
归根结底，我们可以从以下两个方面来分析：
01）、蒸发器制冷剂不足；
02）、蒸发器蒸发不完全；
以下是对空调出现低压告警的分析,希望对您有所帮助：
1、空调制冷系统铜管管道过长：
在调试过程中，有些空调出厂设置的低压告警时间比较低（一般为120秒）；当调试的空调铜管管道较长，导致制冷剂回到蒸发器的时间延长，产生低压告警故障。
解决方案：可以增加低压告警时间到180秒，遇到天气变化的环境中，还需要适当的增加低压告警时间。
2、空调室内机过滤网脏堵：
空气循环会将环境中灰尘吸附空调过滤网表面，一些用户会忽视这个问题，日复一日，空调过滤太脏，蒸发器结冰，导致空调低压告警故障。
解决方案：更换空调室内机过滤网。
3、干燥过滤器脏堵或者铜管管道油堵：
铜管连接需要烧焊，有些铜渣不能完全靠吹污就能处理干净，制冷系统中的赃物会集聚在干燥过滤器中，空调制冷系统运行过程中，该过滤器两端会有温差。
解决方案：过滤器特别脏的情况，需要对制冷系统重新进行吹污或者清洗，一般的处理方法是更换同型号同规格的干燥过滤器。
4、空调制冷系统中的低压保护器故障：
我们对空调制冷系统进行挂表检测，压力正常的情况下，用万用表对低压保护器线路进行测量，或者短接低压保护器，开启压缩机运行，如果制冷循环正常就说明低压保护器故障。
解决方案：更换同规格同型号的低压保护器。
5、空调制冷系统中的电磁阀打不开：
制冷系统运行时，能听到电磁阀打开的声音；假如电磁阀没有开启，低压压力会逐渐下降，直至低压告警产生；在空调控制面板进行报警复位，低压压力不会回升，此时对电磁阀线圈进行测量，有阻值说明正常，无穷大说明该线圈已烧毁。
解决方案：更换同规格同型号的电磁阀线圈
6、空调制冷系统中的膨胀阀故障：
如果膨胀阀故障，在制冷系统运行时，低压压力上不来，高压压力上不去，追加制冷剂低压压力也无法上升。
解决方案：先调整膨胀阀开启度，如还是没有效果，需要更换同规格同型号的膨胀阀（注意：需要排除膨胀阀是否脏堵或冰堵）。
7、空调制冷系统中的制冷剂泄露：
首先对空调制冷系统进行挂表检测，一挂表就没有压力显示，说明制冷系统中的制冷剂已经漏光；假如此时还有压力，制冷系统勉强可以运行，追加制冷剂，压力立马上升，也说明制冷剂泄漏。
解决方案：先对制冷系统各个位置进行检测，检测有无漏油迹象，用洗洁精对漏油位置重点排查；必要的时，对制冷系统进行分段保压，再进行排查。查到漏点后，烧焊补漏，制冷系统重新调试。
8、空调制冷系统冷凝器散热效果太好：
主要发生在环境温度较低的情况，比如冬季。我们经常可以看到，到了冬季有一些冷却塔设备就要关闭风扇，原因也是冷凝压力太低了。
解决方案：调高空调启动压力；或者对室外风机进行整改，改为调速风机，这样能够较好的解决问题。
9、空调制冷系统中的回液管道压扁导致回液不顺畅：
这种情况发生的机率较小，需要对铜管管道进行排查，找到压扁的位置。
解决方案：找到压扁的铜管位置，换掉同规格的铜管
空调低压报警是维护工作中最常见的问题之一，产生的原因也是多方面，合理的判断，以上是个人工作中对低压告警判断的一些见解。

运维告警管理——告警的灵活分派

当下运维人员的一大头疼事，便是复杂而凌乱的告警，无法将告警信息进行灵活分类，通知给不同的人，这样就加大了 IT运维 人员对告警信息的判断难度，进而无法快速的的定位到根因，也就无法快速的解决问题。

睿象云 智能告警 平台Cloud Alert（简称CA）快速接入各类事件，通过人工智能算法自动发现、诊断、修复IT系统运行事故，并能帮助企业形成最佳事件管理流程，让业务运行更加安全可靠；

灵活的分派策略：

在CA的分派策略当中，用户可以根据不同的应用，选定不同的筛选条件，将条件相结合，让指定的告警通知到特定的人；例如：在zabbix应用中，用户可以选择告警级别、告警内容、主机、服务、告警对象、hostgroups、applications等筛选条件，将告警条件相结合，使得告警通知到的人。用户也可以选择将告警通知到组、排班、钉钉、企业微信等协作通知方式；为了防止重要的告警遗漏，CA平台也推出了分派升级策略，当告警在用户指定的时间内未被认领或关闭时，会通知到第二负责人，同样的也可以设置第三、第四负责人，以此类推。

功能详情见视频： http://video.aiops.com/CA.assignment.mp4

更多功能欢迎登陆睿象云官网进行体验～

智能运维是如何抑制告警风暴的？

通常智能运维中告警根因分析法的告警收敛场景，以机器学习算法为驱动，对海量的告警事件进行降噪和关联分析，辅助根因定位并可沉淀故障处理的知识，从而提升企业的运维效率，降低运维成本。 告警产生后，AIOps系统通过算法甄别 内容相关性（重复性、相似性）、时序相关性和拓扑相关
性 事件来进行告警事件的自动化抑制。这类收敛抑制，往往能得到99%的告警压缩率，极大地提高告警根因分析法了告警有效性。

在一个完整的智能运维告警产品里，除告警根因分析法了告警收敛，还可以基于故障传播链及拓扑信息 ( 可选 ), 智能发现突发故障场景；基于告警“熵值”算法，实现告警的动态优先级推荐；通过时序以及拓扑关系定位故障场景根因，并进行根因标记。当这些都可以完成时，由告警事件一步步引导的根因定位和排障，才是真正智能运维发挥了作用。

运维监控工具太多，根因定位不够智能和快速，如何解决？

常规的运维监控工具，基本都是监控某一种设备或某种应用的数据，并且通过阈值的设置来进行故障告警。这样虽然也达到了监控的目的，但在实际使用中，常遇到一个个设置阈值特别麻烦、阈值设置不合理造成告警过少或过多、不同监控数据之间没有关联，出一个故障各系统都在告警，难以判断根因的情况。

智能运维AIOps系统，能通过“数字运维中台”，将原有的分散的运维监控数据统一采集、存储、归档到中台内，并且利用“统一监控平台”对这些数据进行分析管理，如果原来有CMDB数据，还能建立关联并生成拓扑图。

当故障发生、系统告警时，告警辨析中心能利用规则和算法，锁定最重要的那些告警信息，并根据统一监控平台梳理的数据关系，协助查询日志及其他故障数据，更快定位根因。

AIOps平台架构和各数据层关系

故障恢复方法 告警

‍测试环境中出现了一个异常的告警现象：一条告警通过 Thanos Ruler 的 HTTP 接口观察到持续处于 active 状态告警根因分析法，但是从 AlertManager 这边看这条告警为已解决状态。按照 DMP 平台的设计，告警已解决指的是告警上设置的结束时间已经过了当前时间。一条发送至 AlertManager 的告警为已解决状态有三种可能：1. 手动解决了告警2. 告警只产生了一次，第二次计算告警规则时会发送一个已解决的告警3. AlertManager 接收到的告警会带着一个自动解决时间，如果还没到达自动解决时间，则将该时间重置为 24h 后首先，因为了解到测试环境没有手动解决过异常告警，排除第一条；其次，由于该告警持续处于 active 状态，所以不会是因为告警只产生了一次而接收到已解决状态的告警，排除第二条；最后，告警的告警的产生时间与自动解决时间相差不是 24h，排除第三条。那问题出在什么地方呢？

分析

下面我们开始分析这个问题。综合第一节的描述，初步的猜想是告警在到达 AlertManager 前的某些阶段的处理过程太长，导致告警到达 AlertManager 后就已经过了自动解决时间。我们从分析平台里一条告警的流转过程入手，找出告警在哪个处理阶段耗时过长。首先，一条告警的产生需要两方面的配合：

metric 数据

告警规则

将 metric 数据输入到告警规则进行计算，如果符合条件则产生告警。DMP 平台集成了 Thanos 的相关组件，数据的提供和计算则会分开，数据还是由 Prometheus Server 提供，而告警规则的计算则交由 Thanos Rule（下文简称 Ruler）处理。下图是 Ruler 组件在集群中所处的位置：

看来，想要弄清楚现告警的产生到 AlertManager 之间的过程，需要先弄清除 Ruler 的大致机制。官方文档对 Ruler 的介绍是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。

不难推测，Ruler 应该是在 Prometheus 上封装了一层，并提供一些额外的功能。通过翻阅资料大致了解，Ruler 使用 Prometheus 提供的库计算告警规则，并提供一些额外的功能。下面是 Ruler 中告警流转过程：

请点击输入图片描述

请点击输入图片描述

请点击输入图片描述

首先，图中每个告警规则 Rule 都有一个 active queue（下面简称本地队列），用来保存一个告警规则下的活跃告警。

其次，从本地队列中取出告警，发送至 AlertManager 前，会被放入 Thanos Rule Queue（下面简称缓冲队列），该缓冲队列有两个属性：

capacity（默认值为 10000）：控制缓冲队列的大小，

maxBatchSize（默认值为 100）：控制单次发送到 AlertManager 的最大告警数

了解了上述过程，再通过翻阅 Ruler 源码发现，一条告警在放入缓冲队列前，会为其设置一个默认的自动解决时间（当前时间 + 3m），这里是影响告警自动解决的开始时间，在这以后，有两个阶段可能影响告警的处理：1. 缓冲队列阶段2. 出缓冲队列到 AlertManager 阶段（网络延迟影响）由于测试环境是局域网环境，并且也没在环境上发现网络相关的问题，我们初步排除第二个阶段的影响，下面我们将注意力放在缓冲队列上。通过相关源码发现，告警在缓冲队列中的处理过程大致如下：如果本地队列中存在一条告警，其上次发送之间距离现在超过了 1m（默认值，可修改），则将该告警放入缓冲队列，并从缓冲队列中推送最多 maxBatchSize 个告警发送至 AlertManager。反之，如果所有本地队列中的告警，在最近 1m 内都有发送过，那么就不会推送缓冲队列中的告警。也就是说，如果在一段时间内，产生了大量重复的告警，缓冲队列的推送频率会下降。队列的生产方太多，消费方太少，该队列中的告警就会产生堆积的现象。因此我们不难猜测，问题原因很可能是是缓冲队列推送频率变低的情况下，单次推送的告警数量太少，导致缓冲队列堆积。下面我们通过两个方面验证上述猜想：首先通过日志可以得到队列在大约 20000s 内推送了大约 2000 次，即平均 10s 推送一次。结合缓冲队列的具体属性，一条存在于队列中的告警大约需要 (capacity/maxBatchSize)*10s = 16m，AlertManager 在接收到告警后早已超过了默认的自动解决时间（3m）。其次，Ruler 提供了 3 个 metric 的值来监控缓冲队列的运行情况：

thanos_alert_queue_alerts_dropped_total

thanos_alert_queue_alerts_pushed_total

thanos_alert_queue_alerts_popped_total

通过观察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丢失的总数，也能佐证了缓冲队列在某些时刻存在已满的情况。

解决通过以上的分析，我们基本确定了问题的根源：Ruler 组件内置的缓冲队列堆积造成了告警发送的延迟。针对这个问题，我们选择调整队列的 maxBatchSize 值。下面介绍一下这个值如何设置的思路。由于每计算一次告警规则就会尝试推送一次缓冲队列，我们通过估计一个告警数量的最大值，得到 maxBatchSize 可以设置的最小值。假设告警根因分析法你的业务系统需要监控的实体数量分别为 x1、x2、x3、...、xn，实体上的告警规则数量分别有 y1、y2、y3、...、yn，那么一次能产生的告警数量最多是(x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn)，最多推送（y1 + y2 + y3 + ... + yn）次，所以要使缓冲队列不堆积，maxBatchSize 应该满足：maxBatchSize = (x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn) / (y1 + y2 + y3 + ... + yn)，假设 x = max(x1,x2, ...,xn), 将不等式右边适当放大后为 x，即 maxBatchSize 的最小值为 x。也就是说，可以将 maxBatchSize 设置为系统中数量最大的那一类监控实体，对于 DMP 平台，一般来说是 MySQL 实例。

注意事项

上面的计算过程只是提供一个参考思路，如果最终计算出该值过大，很有可能对 AlertManager 造成压力，因而失去缓冲队列的作用，所以还是需要结合实际情况，具体分析。因为 DMP 将 Ruler 集成到了自己的组件中，所以可以比较方便地对这个值进行修改。如果是依照官方文档的介绍使用的 Ruler 组件，那么需要对源码文件进行定制化修改。

华为设备有如下告警,期间并没有修改配置,请分析大概是什么原因

磁盘空间告警
告警信息：IGWB介质空间不足。
告警分析：主用IGWB在剩余磁盘空间小于15%的时候就会出磁盘空间告警告警根因分析法，省公司要求话单保存时间：原始话单15天(D盘)告警根因分析法，格式转换后的话单15天(E盘)，最终话单90天。
告警处理：删除部分格式转换后的话单(E：\backsave\Second\X3KM\)，剪切部分最终话单到应急工作站(暂时)，建议增加IGWB硬盘空间。
02备用IGWB磁盘空间不足
故障现象：备用IGWB磁盘空间不足
故障分析：备用IGWB是实现话单双备份的组成，并且如果备用IGWB磁盘剩余空间过小，主用IBWG异常的时候将无法倒换。
故障处理：清理备用IGWB磁盘空间。
03单板故障
告警信息：例如WSMU 板故障、单板CPU自检故障。
告警分析：无
告警处理：1.复位 2.拔插 3.更换
04电源故障
告警信息：-48V 电压过高告警。
告警分析：
告警产生原因：
· 动力进行例行放电测试，致电压临时过高
· 电压已恢复正常，但告警未自动消除，出现假告警
· 电压过高导致。根据指令DSP PDB可以查询到系统的电压正常范围是-42V～-57V,经常观察如果电压过高后，告警会在电压降到-54V的时候消除。如果告警长时间未自动恢复，可以用万用表测电压，看是否在正常范围内，如果电压已正常，可以手动把电压的门限值进行调高，使告警恢复后再把门限值调到正常范围内。
告警处理：
1.联系动力专业，确认是否在进行电池放电测试。如是，在测试完成后观察告警是否消除
2. 根据指令DSP PDB可以查询到系统的电压正常范围是-42V～-57V，经常观察如果电压过高后，告警会在电压降到-54V的时候消除。如果告警长时间未自动恢复，可以用万用表测电压，看是否在正常范围内，如果电压已正常，可以手动把电压的门限值进行调高，使告警恢复后再把门限值调到正常范围内。(现在配电框监控板默认的告警上限目前定义为57V，产品设置时，可在此基础上加3V，设置为60V比较合适。
MSOFTX3000可以通过软调修改电压告警上限。
软调命令如下：
STR SFTD: LT=MN, MN=2, PID="166", CTRL="36", PM0="1", PM1="60", PM2="42";
STR SFTD: LT=MN, MN=2, PID="166", CTRL="36", PM0="2", PM1="60", PM2="42";)
3.观察一段时间，如告警不会自动恢复就联系动力室处理。
05IGWB倒换
告警信息：iGWB双机倒换
告警分析：双机倒换通常是主用IGWB异常引起，可能原因：磁盘空间不足，重要目录被改动，网络故障，进程异常。
告警处理：清理磁盘空间，恢复被改动目录，检查处理网络，重启IGWB进程。
06传输故障
告警信息：E1端口故障或信号丢失。
告警分析：无
告警处理：自环检测，通过LOP E1对本端端口进行软件环回，如正常则表示单板端口硬件正常，再在各段DDF架端进行环回测试，逐段排除线缆原因，如是本端问题则重做线缆接口、换线或者换板，如是传输问题则转传输室处理。
07IGWB内存过载
告警信息：iGWB 内存过载。
告警分析：IGWB上运行的主要进程有om_proc.exe，ap_proc.exe，cfg_proc.exe，cls_proc.exe，knl_proc.exe。主要检查这些进程有没有大量占用内存空间。现在SZS09,SZS12的om_proc.exe进程占用大量内存不释放。
告警处理：暂时的处理办法是重启om_proc.exe，最终解决方法等待华为工程师补丁解决。
08IGWB备份失败
告警信息：iGWB备份连接失败。
告警分析：IGWB备份有两份，都是从主用IGWB以FTP方式备份到备用IGWB。一份保存在备机的E:\billforbs，保存1000个文件，通过smartback实现；一份保存在E:\ finabill_bak，保存时间为90天，通过igwb.ini文件的配置信息实现。
告警处理：检查smartback备份的路径和用户名密码是否正确；重启smartback软件；重启IGWB进程。
09网络故障
告警信息：BAM到主机连接中断、TCP链路故障。
告警分析：故障可能原因lanswitch异常，网口松动，网卡运行异常。
告警处理：拔插BAM主机网线，拔插lanswitch端口网线，禁用启用网卡，重启BAM。
10MTP、SCCP、M3UA故障
告警信息：M3UA路由传输禁止 路由不可用；MTP链路故障/MTP 链路定位失败；SCCP目的信令点禁止。
告警分析：故障可能原因传输故障引起，配置数据变更，链路负荷过高。
告警处理：检查传输，检查数据配置信息，检查是否为垃圾数据产生的告警。
11话单文件校验错误或话单文件丢失
告警信息：无
告警分析：可能是话单文件传送到计费中心出错，需要重传计费文件
告警处理：重传相应计费文件
12更换单板时程序加载不成功
告警信息：单板程序加载不成功
告警分析：可能原因:1.单板加载软开关未打开.2. 加载文件丢失
告警处理：1.通过MOD LSS修改单板加载软开关,设置为”程序不可用，数据不可用 ,数据可写, 程序可写”,加载完成修改为” 程序可用，数据可用，数据可写，程序不可写”
2.主机加载文件都存于BAM的D:/data 目录下，在此目录下查找所要加载的单板的程序文件，如未找到，说明文件因其他原因丢失，通过在其他同类型同版本局上能找到该单板的程序文件，将文件拷贝至该目录下，重新复位加载单板。
13硬盘故障
故障现象：故障磁盘灯亮红灯。
故障分析：华为软交换的硬盘都采用磁盘阵列方式对数据进行保护，硬盘支持热拔插，坏一块磁盘不影响系统运行，但是要尽快安排更换。
故障处理：更换硬盘。
14主机时间偏差
故障现象：检查主机系统时间发现网元的主机时间和北京时间相差较大。
故障分析：主机系统时间就是话单产生时间，华为认为偏差在正负5秒是正常的，超过这个范围需要校正。
故障处理：主机时间和BAM时间同步，更正其中一个就可以达到校正的目的。可以通过DSP TIME查看系统时间，通过指令SET TIME修改，或者直接改BAM的系统时间。
15CRC校验错误
故障现象：CRC校验错误告警。
故障分析：交换机数据与BAM机数据不一致，可能是由于工程引起的故障。
故障处理：通过SND SPD指令对校验出错的数据表进行强制发送，再次执行STR CRC进行CRC校验
以上，就是给大家整理的华为设备故障分析与排除方法，希望对你能有所启发。 关于告警根因分析法和故障根因分析的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 告警根因分析法的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于故障根因分析、告警根因分析法的信息别忘了在本站进行查找喔。