告警分析处理包括（告警分类）

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

本文目录一览：

• 1、华为设备有如下告警,期间并没有修改配置,请分析大概是什么原因
• 2、如何处理7602告警
• 3、如何快速、灵活的实现告警通知，第一时间解决问题？
• 4、主变轻瓦斯告警了，该怎么分析和查找故障
• 5、火警处理步骤是什么报警操作流程有哪些
• 6、故障恢复方法 告警

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

磁盘空间告警
告警信息：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校验
以上，就是给大家整理的华为设备故障分析与排除方法，希望对你能有所启发。

如何处理7602告警

7602 高频告警的处理分析绝大多数的告警均是来自于风扇方 面的问题。其具体处理可以分为以下几种情况：
一、风扇转速不受 BOI 主控板控制、调节，或高速或低速运转。表现为： Cooling fan speed has reduced from the set speed.， 反复间断上传告警， 此类问题触 发告警数量较大，主要出现在载频、电源板及 BB2F 后背板的风扇，载频背后风 扇需要经常调节风扇转速。同时注意有的风扇在处理时恰好处于告警消除时间， 短时间可能发现不了告警，此种情况需要联系网管查看近 2 天的历史告警，找出 告警风扇的位置再行更换。
二、风扇转速恒定，表现为 Cooling fan is broken，始终上传告警，或者有些 风扇不受电源板及 BOI 主控板有无的控制，即：即使关闭电源板开关也在始终 高速运转，更换好的风扇后即正常，有的虽无告警也应视为风扇故障。 其他的比如风扇完全停转，表现为：Cooling fan is broken。完全停转的风扇 由于只有一个告警产生时间，所以实际上传告警的次数并不太多。但载频背面的 风扇停转会使 TRX 内部温度过高，而引发其他问题及告警。还有的就是基站卫 生环境也可能造成风扇运转的异常，有的机柜的风扇叶上吸附着厚厚的灰尘，有 些风扇则可能已经处于好与坏的临界状态。个别风扇在对 BOI 进行初始化重新 启动风扇后会正常工作一至两天，甚至更长。 综上所述，对于基站出现 7602 高频告警的处理，若条件允许的话，尽量用 新的风扇更换。

如何快速、灵活的实现告警通知，第一时间解决问题？

数据中心产生告警噪音，一般由两个大的原因所引起：1、存在大量重复的告警：大多数监控系统关注的点在快速、无遗漏地将异常告警抛出。2、大量的告警因为服务组件之间的相互依赖关系、相互影响，而产生的大量的关联告警。
所以，在告警发生的时候，可以使用告警优先级推荐算法来分析处理问题。根据规律特征进行判别，看是否需要立即关注。再配合自动化工具，将推荐等级与原始等级都高的告警加上筛选规则，进行自动化开单处置。发现推荐等级与原始等级有背离的部分，可以筛选出来做复盘，对告警原始的等级进行优化，或者转化成升降级的规则逻辑来处置告警等级。擎创告警辨析中心4.0是擎创科技研发的新一代智能告警管理、分析及处置平台，可配置能力更成熟，具有更开放的集成能力，可以将数据中心的监控系统、ITSM流程平台系统、自动化引擎系统、知识库系统、通知类平台等系统无缝集成，并驱动整个数据中心运维体系更快、更智能、更流畅运行。不仅可以满足科技能力及数据治理较强的企业需求，同时也可以通过智能化手段满足科技及数据治理较差企业的需求。

主变轻瓦斯告警了，该怎么分析和查找故障

一般来说，运行中的变压器轻瓦斯保护动作的原因主要有下列几种：(1)变压器内部有轻微程度的故障，如匝间短路、铁芯局部发热、漏磁导致油和变压器油箱壁发热等产生微量的气体；(2)空气侵入变压器内部；(3)长期漏油或渗油导致油位过低；(4)变压器绕组接头焊接不牢，接触电阻过大，引起发热；(5)二次回路发生两点接地，导致误发信号等；(6)因滤油，加油或冷却系统不严密以致空气进入变压器；(7)因温度下降或漏油致使油面低于气体继电器轻瓦斯浮简以下；(8)发生穿越性短路；(9)气体继电器故障。变压器在运行中，轻瓦斯保护信号动作后，应尽快查明原因，并做好记录，对变压器做外部检查并取气体分析，再根据检查结果采取相应的处理措施。1、变压器外部检查检查电流、电压表的指示情况，直流系统绝缘情况，有无其他保护动作信号。检查变压器油色、油位是否正常，上层油温是否有明显升高。检查变压器声音有无异常。检查变压器的油枕、防爆管有无喷油、冒油，盘根和塞垫有无变形。检查瓦斯继电器内有无气体，若有应取气体检查分析。若检查其他都无异常，瓦斯继电器内充满变压器油，但无气泡上冒，则属误动作。如果上述外部检查无明显异常现象，应立即取气体分析，取气体应在停电后进行，若检查有严重异常，应汇报调度，投入备用电源或备用变压器，退出故障变压器，不经检查处理并试验合格后的变压器，不得投入运行2、取气体分析判定变压器内部轻微故障时析出的气体或进入的空气积聚在瓦斯继电器内，至使轻瓦斯继电器动作发出信号。取气体时，观察记录瓦斯继电器内气体的容积后，打开放气阀进行取气体，然后鉴别气体的颜色和可燃性，气体的颜色和可燃性的鉴别应迅速进行，以防有色物质沉淀，经一定时间消失。取气体分析判定如下：气体无色、无味，不可燃，属变压器内部进入空气。可能是由于变压器新安装或检修、加油等工作后进入空气，工作完毕后未完全排出。也可能是运行中冷却，潜油泵等密封不严进入空气。所取气体有颜色，不可燃，不能确定为是空气，应取油样送交专业人员化验。如发现一氧化碳含量增大，可能为固体（本质）绝缘过热损坏而分解的气体。所取气体有色、有气味，可燃，属内部轻微故障，应停电检修。检查气体是否可燃时，应远离变压器。3、根据检查结果处理对变压器外部检查未发现任何异常和故障现象，瓦斯继电器内充满油，但无气体，可能属于误动。这时应检查瓦斯继电器内部及接点位置，直流系统绝缘情况及瓦斯信号掉牌是否能复归，如果检查瓦斯继电器接点在打开位置，瓦斯信号掉牌不能复归，是直流系统绝缘不良，可能属于直流多点接地造成的误动；瓦斯继电器接点在打开位置，瓦斯信号掉牌不能复归，直流系统绝缘正常，可能属二次回路短路引起的误动，应查明短路点并排除之；瓦斯继电器接点在打开位置，瓦斯信号掉牌能复归，检查直流系统绝缘良好，可能属振动过大等而引起的轻瓦斯误动，检明故障点原因并排除之。如果检查瓦斯继电器在闭合位置，瓦斯信号掉牌不能复归，检查直流系统绝缘又良好，可能属瓦斯继电器本身问题（如浮子进油等故障），这种情况，应停电处理。检查变压器，发现变压器油枕中无油、油位低于瓦斯继电器，其他无任何异常现象，轻瓦斯报出信号，可能属油位过低而引起瓦斯动作，这时应投入备用变压器或备用电源，退出故障变压器，有漏油，处理漏油，然后加油至所需油位。未发现明显异常和故障现象，瓦斯继电器内发现有气体。取气体检查分析，如果检查气体无色、无味，不可燃，可能属进入空气，放出气体，监视信号报出时间的间隔，如信号动作时间间隔逐渐短时，说明变压器内部有故障，可能会跳闸，此时应将每次信号动作时间做详细记录，并立即向有关调度和上级领导汇报，若是瓦斯继电器内进入空气，应查找进气原因和进气点，无备用变压器，可根据调度命令，将重瓦斯改投信号位置。如果检查气体颜色很淡，不可燃，不能确定是空气时，汇报调度及上级主管，严密监视变压器。取油样送交专业人员进行化验，有问题应立即停电检修。如果检查气体有色、有味，可燃，可能属于变压器内部轻微故障，这时应投入备用变压器及备用电源，故障变压器停电检修。发现变压器有异常和明显的故障，投入备用变压器或备用电源，退出故障变压器，取气体检查分析判断。对于所检查出的问题，值班员不能擅自处理，应进行汇报，并请专业人士进行处理。主变轻瓦斯告警了，该怎么分析和查找故障

火警处理步骤是什么报警操作流程有哪些

拨打“119”火警电话 与公安消防队出警灭火都是免费的。发生火警的时候我们一定不能着急，也不要慌张，最主要的就是自救。下面是我整理的火警处理步骤，欢迎阅读。
火警处理步骤
第一节、火警处理流程

1、自动报警系统显示火警信号或接到火情 报告 后，应按下“消音”键，确认火灾信号部位;

2、消控室值班员主管应立即派一值班员或通知消防巡查员前往火警现场观察;

3、火情确认后，应立即报告值班室主管，由值班主管抽向主管领通报;

4、值班主管确认火灾后应立即拨打119火警电话向消防部门报警;

5、接通相关部位的消防应急广播系统，通知火灾及相关区域人员疏散。

6、根据火灾发生的位置及状态启动相应的联动设备，如消防栓系统、喷淋系统、防排烟系统等消防设施。

7、主管值班员应留在控制监视系统运行，并做好火警记录。

第二节、火警误报处理步骤

1、火灾报警控制器显示火警信号或接到火情报告后，应首 先在系统报警图形中核实所对应的位置;

2、消控室值班员主管应立即派一值班员或通知消防巡查员 持通讯工具和灭火器前往报警现场观察情况，主管值班员 留在控制室随时准备实施系统操作;

3、值班员或通知消防巡查员在现场核实火警时为误报时， 应及时通知消防控制室;

4、主值班员接到误报通知后应将系统恢复到正常工作状态;

5、在值班记录中对误报时间、部位、原因及处理 方法 进行详细记录;

6、消防值班员应及时将系统误报的原因、处理情况向上级领导汇报。

第三节、火灾报警处理程序

1、消音;

2、接到报警后应立即携带对讲机，消防电话等通讯工具， 迅速到达报警点确认;

3、如未发生火情，应查明原因，采取相应处理 措施 ，并认 真做好记录;

4、如确实发生了火灾，应立即用通讯工具向消控室主管值 班员报告，并立即用现场灭火器灭火;

5、消防控制室值班人员应根据火情启动相关消防设备，通 知相关人员，报告领导，拨打119报警;

6、处理完毕，恢复系统到正常运行状态。

第四节、 其它 情况处理方法

一、值班员到现场确认火警与消防控制室失去联系统处理程 序

1、如果同一探测区域内另外探测器继续报警，应按火灾确 认程序处理;

2、通知有关人员并报告值班领导处置。

二、不同探测区域同时报警应如何处置

1、若应急方案有规定的按应急方案处理;

2、优先处理重点防火区域的报警，然后再处理另外区域报 警。

三、同一区域多个探测器相继报警处理办法

1、立即通知相关人员到现场确认;

2、按火警确认程序处理。

第五节、系统检查

一、日检

1、系统运行日检内容：设备运行正常还是有故障，分析报 警性质是火警、误报、故障报警，是否有漏报、报警原 因和处理方法并作好记录。

2、控制器运行日检内容：自检、消音、复位、故障报警、 巡检、主备电等是否正常。
火警紧急处理方案
1、初期火警扑救无效，火势无法控制并进一步蔓延时，在场当值负责人应该第一时间向中心领导汇报;第一时间向消防局报警。讲清楚市场地点、起火楼层、火势、起火材料等。

2、关闭防火分区的防火门或卷闸;安排人员携带灭火工具检查相邻房间和上下楼层通道是否有火势蔓延;检查电梯有无困人。

3、灭火行动组以最快速度到达现场，组织灭火，针对燃烧性质不同采取相应的灭火方法，防止火灾蔓延。

4、救护疏散组指挥人员疏散，疏散顺序先从着火层以上各层开始，安抚暂不需要疏散楼层的人员;指导着火房()间或楼层人员安全疏散，随后查漏;引导人员从消防通道疏散到首层，无法从消防通道疏散到首层时，引导用户疏散到天台上风处等待营救，并组织水枪掩护。

5、交通指挥组消除路障，指挥无关车辆离开现场，维持市场外围秩序;禁止无关人员进入市场，指挥疏散人员离开市场;引导消防局消防员到火灾现场。
火警报警操作流程
消防控制室值班人员在接到火警显示后，应保持镇定，不得慌乱，并按照相应的处理程序经行工作。

1接到控制设备报警显示后，应首先在系统点位置平面图中何时报警点所对应的部位。

2由手动变为自动，消防控制室一名值班人员或通知保安人员迅速赶到报警部位核实情况，自动消防系统操作人员在控制室内随时准备实施系统操作。

3现场核实报警部位确实起火后，应立即通知消防控制室，并立即拨打119，向公安消防机构报警，说明发生火灾的单位名称，座落地点，起火部位，联系电话等基本情况。

4发生火灾后及时通知上级领导。

5报警后，消防控制室一名值班人员应利用火灾事故广播系统通知有关部门和有关人员组织疏散和自救工作。

6消防控制室的自动消防系统操作人员要监视系统的运行状态，保证火灾情况下建筑自动消防设施的自动运行。

操作流程

1按自动键显示输入密码，密码为00000。

2然后看指示灯查看是否在自动指示灯上。

3确认后FT8304总线置手动控制盘所相对区域(如排烟口 按下排风口键然后按下卷帘门键。超过80度自动喷淋系统启动)

4拿起红色报警电话显示输入几级密码(如 2级，输入2222。) 5按下确认键，输入号码119后按下拨号键，最后按下通话键，接通后说明发生火灾的单位名称，座落地点，起火部位，联系电话等基本情况。

故障恢复方法 告警

‍测试环境中出现告警分析处理包括了一个异常的告警现象：一条告警通过 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 组件，那么需要对源码文件进行定制化修改。

关于告警分析处理包括和告警分类的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 告警分析处理包括的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于告警分类、告警分析处理包括的信息别忘了在本站进行查找喔。