告警处理思路（告警分哪几种）

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

本文目录一览：

• 1、故障恢复方法 告警
• 2、第五节 实现zabbix报警功能之页面信息报警和页面提示声音报警
• 3、电脑告警开不开机怎么办
• 4、中兴S320设备，上报NCP S接口通讯错告警，有没有大虾知道此故障产生原因及解决办法？（越详细越好，谢谢）

故障恢复方法 告警

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

第五节 实现zabbix报警功能之页面信息报警和页面提示声音报警

1.1 页面提示信息报警和页面提示声音报警

配置-----主机-----点击相应主机告警处理思路的触发器-----创建创建触发器

配置触发器

查看页面报警提示信息

工作中处理页面报警信息告警处理思路的思路

工作中遇见告警信息处理思路步骤:
第一步: 看到告警提示信息,定位主机信息
第二步: 看到主机信息之后,定位报警原因 获得监控项Key值
第三步: 根据key值信息,最终获得报警原因

1.2 页面提示声音报警

用户-----用户设置------正在发送消息--- 勾选前端信息

电脑告警开不开机怎么办

简单的说可以用以下方法得知是何问题：
1、观察法，看主机的电源灯是否正常，能正常显示那么可以排除电源问题，否则换电源(或查电源线路插座等)
2、听声音，可以根据BIOS的开机自检报警声来判断,如果没有警报声可以确定两个原因(主板故障或显卡故障或其它插卡故障)，可用第三种方法试。
3、插拔法，把CPU、内存、显卡等包括其它的插卡，拔下来(最好用刷子把灰尘扫掉，注意不要弄到水)，用橡皮擦把内存或显卡的金手指擦一遍，再插回去或换个插口，擦内存的时候要两边同时下去快速的插好，不要一边一边慢慢推下去。
4、替换法，把其它电脑正常使用的上述设备逐一替换过去，注意不要同时替换所有的设备。
5、重装系统，如果是软件问题(没有上述现象就应该是软件或系统问题)最好的办法就是重新安装系统。
常见故障：
一、开机主机显示器不显示，无报警
二、开机显示器还是不显示，有报警
三、从windows xp那个启动界面进去后就又反复重启
四、蓝屏
常见故障的分析及解决办法：
一、不能开机且无报警的检修思路：
造成不能开机且无报警故障的最大可能，也就是最值得怀疑的是：1.供电；2.CPU；3.主板。因为这三件硬件只要有一件有故障，主板就不能启动，主板没启动就不会报警。有故障不一定是配件坏了，接触不良也是故障。
所以按下面的步骤检查：
1.测量电源是否能正常输出各路电压，无测量工具时可用好电源直接代换。
电源与主板的连接是否可靠，可拔插20口插头。
面板上的电源开关是否损坏。必要时可直接短接主板上的PWR SW接针，看能否启动主板。
在确信供电正常后进行下面的检查。
2.拔插CPU，不行的话换CPU。
拔插CPU后能启动，说明是CPU接触不良。拔插CPU后不能启动，CPU有损坏的可能，所以换
CPU，换CPU还是不行，剩下的只有主板了。
3.主板检查首选应是CPU插座供电是否正常，其次是南桥北桥，各晶振，时钟发生器等。可
以借助主板诊断卡。当然这些不是一般的DIYER能完成的。只有送修了。
二、常见的PC故碍开机报警声及解决(点击)
如果是内存问题：内存没插好，把内存卡拔下来用橡皮擦擦亮金手指，或者内存坏掉
其他问题：
1.显卡未插紧.
2.检查显示器是否损坏.
3.将主板上所有连线重新插一次.
4.重插PCI,AGP,或其他连接卡.
三、可能是系统启动文件损坏或者更换硬件
1、有个朋友的把他的显示器借别人用了半个小时，拿回来就不能正常启动了，安全模式可以进去，估计显示器的分辨率被调了，后来在安全模式下卸载了显卡驱动程序，就可以了
2、我前几天是主机跟显示器的线掉了，启动才发现没插线，又急忙把主机强行关机，然后就再也进不去了，后知道启动文件坏了
3、碰到这种情况我的解决办法是，首先，开机按F8，会出来一个界面，那个界面有让你选择进入安全模式等，先选择其中“最后一次正确配置”，如果不行，再选择“安全模式”，在里面可以重装某硬件驱动程序等，再不行，那就是系统启动文件被破坏了，就如我上面的开机，还没等启动完毕又关机做法就会损坏启动文件。
4、系统启动文件损坏还有可能是有些人在杀毒的时候把一些东西删了，结果启动不了系统，那么你可以用XP启动盘的修复功能，开机，在BIOS里选择光盘启动，并放入光盘，按R有个XP修复台。

中兴S320设备，上报NCP S接口通讯错告警，有没有大虾知道此故障产生原因及解决办法？（越详细越好，谢谢）

S口通信错误为常见错误。
处理思路如下
1、首先在E300上进行通讯测试，看看是否正常
2、测试如果正常，可能是误报，在、网管侧删除告警然后刷新看看是否消失
3、如果上一步告警刷新后又再次出现，或者通讯测试未通过，先尝试软复位ncp，不行就硬复位，还不行就插拔
4、一般上述方法可以临时解决，最终还是要换ncp单板
感兴趣可以向办事处工程师要个晶振老化的检测方法文档，测试一下晶振是不是老化了，不过还是要换板的。 关于告警处理思路和告警分哪几种的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 告警处理思路的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于告警分哪几种、告警处理思路的信息别忘了在本站进行查找喔。