告警数量预测分析（告警次数）

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

本文目录一览：

• 1、如果测试中某个测试点的信号异常，如何判断故障点在哪
• 2、运维告警等级详解
• 3、lte告警类型有哪些，以及会产生什么影响
• 4、如何处理7602告警
• 5、如何才能做到对告警通知有效管理？

如果测试中某个测试点的信号异常，如何判断故障点在哪

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

‍‍

运维告警等级详解

互联网时代 IT 相关的衍生产品有很多，监控工具为其中的佼佼者。很多监控工具对于确保网站和应用的平稳运行做了非常多的工作，但是，对于告警产生到通知用户的过程，还有很大的改进空间。

在合理评估告警严重程度的基础上，确保通知合适的运维汪，对于快速有效解决事件至关重要。但是我们对告警等级的重要性以及如何设置告警等级来提高团队效率，还缺少必要的认识。针对该问题，以下几条快速指南可以供大家参考。

什么是告警等级？有什么重要性？

简单来说，告警等级是表征事件严重性的指标之一，取决于事件对用户体验以及网站或应用整体性能造成的负面影响的大小。

例如，导致网站崩溃的事件，被认为负面影响极大，告警等级也就较高；而一个Ping的问题有时不会很明显，被认为负面影响略小，告警等级也就较低。

告警等级的重要性体现在以下方面：

有助于减少和控制告警噪声的数量。

使得错误处理流程更为顺畅。

使你解决问题更有效率。

总而言之，根据告警等级不同，可以优先处理重要事件，避免干扰到不在职责范围内的无关人员。

怎样创建合适的团队告警等级规则？

确定告警等级的重要性，相信大家已经了解了，但如何创建一个适合整个团队事件严重程度的评估方法，是监控工具开发人员的棘手问题。

一般来说，评估告警等级过程需考虑以下3个方面：

1.严重性等级结构

2.团队结构

3.通信结构

1）严重性等级结构

严重性等级的主要目的是确保合适的人员能够知道问题，并按照严重程度来处理问题。一般来说，设置严重程度等级结构的最简单方法是根据商业价值来确定网站或应用的最关键部分。并且在团队中，并没有所谓的正确或错误的方式来判定严重性等级。要知道，重要的是了解团队如何划分具体的事件，并确保每个人都达成共识。

2）团队结构

清晰地认识团队结构并对告警进行有序分派，将提高整个团队的执行效率。为了更有序和有效的分派告警，我们应该注意几个问题：

告警处理需要涉及哪些人？

处理事件时，每个人的责任是什么？

告警要求在哪个环节通知哪些人？

3）通信结构

如果你不知道告警在团队结构内应该如何通信，那么建立通信结构将是创建严重性等级过程中最为困难的一环。

你可以这样考虑：

严重性等级结构：这个问题有多严重？

团队结构：这是谁的责任？

通信结构：如果问题发生，如何以及何时联系团队成员？

创建通信结构能将不同事件与团队中的不同角色联系起来，并根据时间紧迫度与错误频率添加更明确的操作。这样，可以确保通过恰当的渠道联系到合适的人员，且符合当前的情况。如果一个响应者不在线上，可通过告警升级机制确保团队中的其他成员得到通知。

根据团队结构，选择合适的通知渠道与阈值配置，意味着问题解决能更加高效，且不会牵涉到无关人员。
RIIL是国内领先的IT综合管理解决方案，通过IT资源综合监控、运维流程管理、3D数据中心管理三大模块帮助客户实现IT部门人财物的全面管理，提升IT服务质量以及运维管理绩效

lte告警类型有哪些，以及会产生什么影响

1、用户面承载链路故障告警，警告影响：该用户面承载的业务无法正常进行。产生告警原因：自建立模式下，当检测到本端无法和对端正常通讯时，产生此告警。

2、 SCTP链路故障告警，警告影响：导致SCTP链路上无法承载信令。产生告警原因：当基站检测到SCTP（Stream Control Transmission Protocol，流控制传输协议）链路无法承载业务时，产生此告警。

3、 X2接口故障告警，警告影响：基站释放正在通过产生告警的X2接口进行切换的用户，在该告警恢复前，基站将无法继续支持与对应基站间的X2接口切换流程，无法继续支持与对应基站间的小区干扰协调过程。产生告警原因：X2AP（X2 Application Protocol）连接在底层SCTP链路资源可用时，eNodeB将向对端eNodeB发起连接建立请求；对端eNodeB对连接请求做合法性检查，检查不通过，将无法建立连接；eNodeB收到对端eNodeB的响应后，如果发现对端eNodeB在黑名单中将无法建立连接。

当底层SCTP链路故障、X2AP协议层因配置错误或者对端eNodeB异常无法建立连接时，产生此告警。

4、 小区不可用告警，警告影响：小区状态与基带资源、射频资源、CPRI资源和传输资源这些物理资源有关，也与License有关。在物理资源不足、物理资源故障或物理资源被闭塞的情况下，小区状态会因为无可用的物理资源而变为不可用。即使物理资源可用但License不足时，也会导致小区不可用。多模场景下，由于共享资源受限（如频率、功率），也会导致小区不可用。当小区状态变为不可用，且该状态持续90秒（默认）未恢复时，将产生该告警。当小区状态变为可用，且该状态持续15秒（默认）一直可用时，则上报告警恢复。告警产生和恢复的时长可以通过SET ALMFILTER命令进行设置。产生告警原因：供电后自恢复,OMC920每隔1分钟会向被管网元发送握手请求，当被管网元三次无应答时判定通信状态为断连，上报本告警。本告警上报后，只要断连未恢复，OMC920不会因断连期间的故障原因变更而上报新的告警。OMC920会每隔2分钟重连已断开的连接，如果重连成功则自动清除本告警。

5、 S1接口故障告警，警告影响：基站将主动去激活所有与异常的S1接口相关的小区，并释放此前已经成功接入到这些小区内的所有在网用户。新的用户将无法接入到这些小区。

6、 射频单元驻波告警，警告影响：天馈接口的回波损耗过大，系统根据配置决定是否自动关闭射频单元发射通道开关，当“驻波比告警后处理开关”取值为“打开”时，射频单元发射通道开关被关闭且告警无法自动恢复，该发射通道承载的业务中断。当“驻波比告警后处理开关”取值为“关闭”时，射频单元会启动降额（默认3dB，具体由当前的业务状态决定），从而防止硬件损坏， 且告警可以自动恢复。天馈接口的回波损耗较大，导致实际输出功率减小，小区覆盖减小。产生告警原因：当射频单元与对端设备（上级/下级射频单元或BBU）间接口链路（链路层）数据收发异常时，产生此告警。

7、 射频单元维护链路异常告警， 警告影响：射频单元承载的业务中断。产生告警原因：BBU和射频单元之间通过电缆或者光纤进行连接。当BBU与射频单元间的维护链路出现异常时，产生此告警。

8、 BBU IR接口异常告警， 警告影响：在链形组网下，下级射频单元的连接链路中断，下级射频单元承载的业务中断。如果基站工作在CPRI

MUX特性的组网，本制式为汇聚方且故障端口为提供汇聚功能的端口时，会造成对端制式的业务中断。在环形组网下，射频单元连接链路的可靠性下降，下级射频

单元的激活链路将倒换到备份链路上，在热环配置下对业务没有影响，在冷环配置下业务会出现短暂中断。BBU与下级射频单元的光模块的收发性能轻微恶化，可

能导致下级射频单元承载的业务质量出现轻微恶化。产生告警原因：当BBU与下级射频单元之间的光纤链路（物理层）的光信号接收异常时，产生此告警。

9、星卡锁星不足告警，警告影响：如果该告警一直存在，最终会导 致基站GPS时钟源不可用

10、 小区退服告警 ，警告影响：小区建立失败，所有业务中断。产生告警原因：当小区建立失败或小区退出服务，并且原因不是配置管理员人为闭塞时，产生此告警。

另外还有 BBU IR光模块收发异常告警， 基站控制面传输中断告警，网元连接中断，小区服务能力下降告警，射频单元IR接口异常告警，同类告警数量超出门限， BBU IR光模块/电接口不在位告警等警告类型。

如何处理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 高频告警的处理，若条件允许的话，尽量用 新的风扇更换。

如何才能做到对告警通知有效管理？

其实在一线运维工作中告警数量预测分析，常常是福不双至，故障不单行。每有运维问题发生的时候，往往会密集发生多个告警。当这些告警来袭的时候，一线运维人员要针对它的类型、等级、告警对象和内容等进行检查并选用合适的方法来应对。

告警等级较高时，比如持续出错的应用告警，在查验后会立即分派通知相关的负责人在第一时间开具事件工单，做对应的流程追踪告警数量预测分析；而遇到低等级或次要的系统告警，则可以暂缓处置，留作观察。

传统的处置方式需要用经验来判断问题的影响范围和严重性，再通过人工进行派单以及通知下游处理人员，这样效率低下，无法满足现今业务响应速度的要求了。

究其原因，有些周期性发生的高频问题，往往并不是最棘手的，是可以延后处置的。反而偶发的问题，比较需要特别关注（如果这是原始定级较高的故障，更应该第一时间关注）。

所以，在告警发生的时候，可以使用告警优先级推荐算法来分析处理问题。根据规律特征进行判别，看是否需要立即关注。再配合自动化工具，将推荐等级与原始等级都高的告警加上筛选规则，进行自动化开单处置。发现推荐等级与原始等级有背离的部分，可以筛选出来做复盘，对告警原始的等级进行优化，或者转化成升降级的规则逻辑来处置告警等级。

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