告警分析与优化（告警数据分析）

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

本文目录一览：

• 1、如何快速、灵活的实现告警通知，第一时间解决问题？
• 2、如何才能做到对告警通知有效管理？
• 3、公司购买了很多安全设备，但安全运维人员还是需要面对很多无效告警，运营效率低下，有什么解决方案吗？
• 4、基于标记数据学习降低误报率的算法优化
• 5、故障恢复方法 告警
• 6、制冷系统产生低压告警的几种原因？

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

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

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

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

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

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

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

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

公司购买了很多安全设备，但安全运维人员还是需要面对很多无效告警，运营效率低下，有什么解决方案吗？

在传统的运维方式中，原始的事件里有许多重复性的、杂乱的噪音信息，而且某一个组件发生问题，往往会引发相关的组件都产生报警，这样在短时间内就会产生告警风暴，这也会严重影响运维人员的判断，因此传统的集中监控，都是依赖运维人员的经验梳理规则，并将事件归并、关联的规则运用于平台，实现告警抑制。这样就会出现你提问的这种情况，导致运营效率低下。

这时建议可以采用“智能运维”的手段，AIOps智能运维能够对传统集中监控进行智慧赋能，比如我们以擎创科技的夏洛克AIOps告警辨析中心为例，来展开分析这种AI赋能的几种方式：
1. 对既有的完全基于经验进行规则梳理的处理方式的智慧赋能

2. 对事件的精细化分析能力的智慧赋能

3. 通过建立人工和智能相融合的迭代反馈机制促使监控持续优化

综上所述，集中监控作为运维的“双眼”，应该是AIOps智慧赋能的第一站，赋能后的智能化集中监控将具备三大优势：

能够以更低的人力成本更及时有效地发现问题端倪，提高了业务保障能力；

能够更深入的洞察和分析告警，提升了故障排查效能；

能够利用人机融合的智慧，建立持续改进的机制，并且为进一步进行基础指标监控以及日志分析等其他领域的智能化改造提供了指导方向。

基于标记数据学习降低误报率的算法优化

基于标记数据学习降低误报率的算法优化
无论是基于规则匹配的策略告警分析与优化，还是基于复杂的安全分析模型告警分析与优化，安全设备产生的告警都存在大量误报，这是一个相当普遍的问题。其中一个重要的原因是每个客户的应用场景和数据都多多少少有不同的差异，基于固定判断规则对有统计涨落的数据进行僵化的判断，很容易出现误判。
在没有持续人工干预和手动优化的情况下，策略和模型的误报率不会随着数据的积累而有所改进。也就是说安全分析人员通过对告警打标签的方式，可以将专业经验传授给智能算法，自动得反馈到策略和模型当中，使之对安全事件做出更精准的判断。本文介绍利用专家经验持续优化机器学习的方法，对告警数据进行二次分析和学习，从而显著地降低安全威胁告警的误报率。
为了降低误报率，当前大体上有两种技术途径：
根据不同客户的各种特定情况修正策略和模型，提高策略或者模型的适应能力;
定期(如每月一次)对告警进入二次人工分析，根据分析结果来调整策略和模型的参数配置。
这两种方法对降低误报率都有一定的作用。但是第一种没有自适应能力，是否有效果要看实际情况。第二种效果会好一些，但是非常耗时耗力，而且由于是人工现场干预和调整策略和模型，出错的概率也非常高。
MIT的研究人员[1] 介绍了一种将安全分析人员标记后的告警日志作为训练数据集，令机器学习算法学习专家经验，使分析算法持续得到优化，实现自动识别误报告警，降低误报率的方法(以下简称“标签传递经验方法”)。这种把安全分析人员的专业智能转化成算法分析能力的过程，会让分析算法随着数据的积累而更加精确。继而逐渐摆脱人工干预，提高运维效率。如下图所示：

下面告警分析与优化我们通过基于“频繁访问安全威胁告警”模拟的场景数据来介绍一下实现机制。
什么是频繁访问模型?逻辑比较简单：一段时间内(比如1分钟)，一个攻击者对系统的访问次数显著高于普通访问者的次数。此告警规则可以用简单的基于阈值，或者是利用统计分布的离异概率。基于此，我们先模拟一些已经被安全分析人员打过标签的告警数据。根据实际应用经验，我们尽量模拟非常接近实际场景的数据。如下图：

关于模拟数据的介绍：
总共模拟了20天的告警数据，从2017-01-01到2017-01-20。前10天的数据用来训练模型，后10天的数据用来衡量模型的表现;
每个告警带有是否误报的标签。红色代表误报，蓝色代表准确告警。
关于模拟数据的假设：
误报聚集在某个时间段，模拟数据假设的范围是18:00-19:00。在安全运维实践中，的确存在某个特定的时间段，由于业务逻辑或者系统原因导致误报增多的现象。所以上述假设是合理的，告警时间可以作为有效的特征值。但并不是所有的误报都聚集在这个时间段，同时并不是这个时间段的所有告警都是误报;
误报大多来自于一批不同的IP。所以访问来源IP也是有用的特征值;
任何数据都不是完美的，所以在模拟数据中加入了~9%的噪音。也就是说再完美的智能模型，误报率也不会低于9%。
这些假设在实际的应用场景中也是相对合理的。如果误报是完全随机产生的，那么再智能的模型也不能够捕捉到误报的提出信号。所以这些合理的假设帮助我们模拟真实的数据，并且验证我们的机器学习模型。
简要模拟数据的代码实现：
下图显示利用PCA降维分析的可视化结果，可以看到明显的分类情况：

红色代表误报，蓝色代表正确告警。基于设定特征值的降维分析可以得到两个聚集，即误报和非误报有明显的区分的，也就是说误报的是有一定规律，不是完全随机的，因此是可以被机器学习捕捉到的。
简要代码实现：

基于模拟数据，我们想要达到的目的是通过持续的强化机器学习能够降低误报率。所以我们采取的策略是：
训练一天的数据2017-01-01，测试10天的数据2017-01-11到2017-01-20;
训练两天的数据2017-01-01到2017-01-02，测试10天的数据2017-01-11到2017-01-20;
以此类推，来看通过学习越来越多的数据，在测试数据中的误报率是否能够得到不断的改进。
简要代码如下：

此安全威胁场景相对简单，我们不需要太多的特征值和海量的数据，所以机器学习模型选择了随机森林(RandomForest)，我们也尝试了其他复杂模型，得出的效果区别不大。测试结果如下：

达到我们所预期的效果，当训练数据越来越多的时候，测试数据当中的误报率从20%多降低到了10%。通过对告警数据和标签的不断自学习，可以剔除很多告警误报。前面提到，数据当中引入了9%的噪音，所以误报率不会再持续的降低。
在我们的机器学习模型当中，我们利用了4个主要的特征值：
srcIP，访问源IP
timeofday，告警产生的时间
visits，访问次数
destIP，被访问IP
下图显示了特征值在模型中的重要性：

和我们的预期也是一致的，访问源IP(srcIP)和告警发生的时间(timeofday)是区分出误报告警效果最好的特征值。
另外，由于随机森林模型以及大部分机器学习模型都不支持分类变量(categoricalvariable)的学习，所以我们把srcIP和destIP这两个特征值做了二值化处理。简要代码如下：

总结
本文通过一组模拟实验数据和随机森林算法，从理论上验证了“标签传递经验方法”的有效性。即通过安全分析专家对告警日志进行有效或误报的标记，把专家的知识技能转化成机器学习模型的分析能力。和其他方法相比，此方法在完成自动化学习之后就不再需要人工干预，而且会随着数据的积累对误报的剔除会更加精确。

故障恢复方法 告警

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

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

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