关于告警分组合并效果的信息

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

本文目录一览：

• 1、爱立信分集接收告警怎样解决啊？谢谢
• 2、智能运维是如何抑制告警风暴的？
• 3、怎样才能做到抑制告警风暴？
• 4、有效运维的 on-call 机制
• 5、alertmanager-配置文件

爱立信分集接收告警怎样解决啊？谢谢

分集接收告警
1、分集接收告警分组合并效果的定义
所谓分集接收告警分组合并效果，是指接收端对它收到的多个衰落特性互相独立（携带同一信息）的信号进行特定的处理告警分组合并效果，以降低信号电平起伏的办法。
分集有两重含义：
1、分散传输：使接收端能获得多个统计独立、携带同一信息的衰落信号。
2、集中处理：即接收机把收到的多个统计独立的衰落信号进行合并（包括选择与组合）以降低衰落的影响。
分集方式
1、宏分集：一种减小慢衰落影响的分集技术。
2、微分集：一种减小快衰落影响的分集技术。
又可以分为：场分量分集，时间分集，极化分集，空间分集，角度分集，频率分集。
合并方式：1、最大比值合并 2、选择式合并3、增益合并等。
2、故障代码分析
故障代码：SO CF I2A：33
故障名称：RX diversity lost
故障原因： 产生分集接收告警的条件为：基站的一个或若干载频的2路接收信号A、B的强度相差至少为12dB（即≥12 dB），并且持续50分钟以上，基站就会产生分集接收告警。产生分集接收告警的TRU的接收机灵敏度会因此降低大约3.5dB。注意：当如下几种告警产生时，此分集接收告警就不会再出现。它们是：SO CF I2A：7（RXDA），SO CF I2A：11（TMA current），SO CF I2A：34（TMA voltage），SO CF I2A：39（RX cable）。
3、故障处理流程：
进行如下检查和测试
（1）首先，对机架中的每个TRU打开OMT的分集接收监测功能，测量SSI值（signal strength imbalance），即每个TRU的接收分路RX A减去RX B，如为正值，表明B路接收分路存在问题，如为负值，表明A路接收分路存在问题。这样的测量每5分钟更新一次，但必须是在基站有话务量的情况下才能测量出
（2）一个小区中，如果只有单个TRU的SSI值过高，则很可能是这个TRU的故障，更换这个TRU。如果一个小区中所有TRU的SSI值均过高，则可能是天馈线接错了，或CDU A、C、C+、D的接收部分存在故障导致连接在这个CDU上的所有或部分TRU测量的SSI值过高。这就需要重点检查天馈线系统和CDU的射频连接线是否有错误，必要时更换怀疑有问题的CDU，对于CDU D问题会出在DU上。
（3）检查天馈线是否有进水现象，对于2111设备还需检查跳线帽是否安装正确。
（4）进行完每一步分集接收故障排查的步骤后，都要重新检测所有TRU的SSI值，以确认刚才所做的排查工作是否取得了消除分集接收告警的效果。最好等待OMT自动的连续测量2-3次（5分钟一次），便可确认告警是否消除，否则再接着进行其它步骤的

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

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

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

怎样才能做到抑制告警风暴？

所谓告警风暴是指在短时间内系统产生大量的告警消息，这些消息有的是由某种共同因素引发，互相之间存在一定的关联，有的也可能没有任何关系。一些中大型企业的IT应用系统庞大而复杂，设备数量成千上万，任何一个小小的IT问题都有可能会引发告警风暴。当告警风暴产生时，运维人员每天接受各类告警消息多达上万条，这就导致了运维人员的疲倦和重要消息遗漏。听云AIOps智能运维平台的告警抑制产品可针对海量的、持续的告警信息，通过智能算法结合固定规则的方式对告警消息进行告警合并，在保证核心告警消息的前提下抑制告警消息数量。你可以去了解看看。

有效运维的 on-call 机制

[编者按]本文作者为陈伯龙，云告警平台 OneAlert 创始人，著《云计算与 OpenStack 》，在IT运营管理、云计算方面从业10多年。

互联网技术的发展，离不开运维支撑工作，没有零bug的程序，没有不出问题的系统，问题故障不可怕，可怕的是没能有序的处理：

如何有效处理紧急事件驱动的工作，成为（特别是运维主管）运维工作的关键。我接触了大量的各类型公司运维，从初创、中小、大型公司，总结和分享一些大多公司通用的on-call机制，帮助有序的处理紧急事件：

基本上都是围绕人、流程、工具三方面进行，参考了ITIL的管理思路，大家感兴趣也可以参考下，特别是其中的ITIL V3的运营管理。

大多公司都用了zabbix和nagios、open-falcon等监控工具，对硬件、网络、应用进行监控。可能会存在监控分散问题：

告警集中化，就是所有的生产监控发现的告警事件集中到一起，这样我们盯着一个平台就够了，同样也容易分析问题，是不是相同和类似原因。

如果监控工具单一，集中化不是最必要的，如何有序处理才是最核心的。特别运维团队是3-5人到数十／百人，就很有必要梳理下支撑流程和响应机制了。

如果管理比较细一些，还会进行业务拆分，形成一个矩阵，例如一线、二线根据不同专业，如负责网络和负责不同应用的团队。
另外还要考虑告警严重的程度级别，进行差异化处理，要求严格的同学一般会建立响应级别[1-3]或[1-5]：

那么问题来了，规划和设计挺好，如何落地呢？目前看zabbix、nagios、open-falcon等监控工具更多是聚焦如何发现问题，支撑流程属于处理问题的范畴，或者是说管理范畴，这一点目前市面上合适工具较少：

接触过一个互联网金融公司，设计了非常规范化的流程和P0-P5级别应急处理方案，涉及了网络、云平台、近50个应用研发团队。

分派升级

排班管理

再好的流程和设计，当时没有及时收到通知和处理，那么就会很郁闷了，最后一公里问题解决方式：

还支持几点：不同级别、不同时间段的设置，例如晚上严重的电话通知，白天工作时间就不用了。
这里面还存在一个问题，当告警规模大了后，特别是告警风暴的话，很容易撑爆邮箱或者是手机短信了，所以接下来就聊下告警风暴规避的问题。

这个问题比较大，基本上有些监控工具做了一部分，目前看也是一个业界难题，简单来说：

我们目前做了一些尝试分享下：

机器学习告警合并

如果告警量很大，告警后续处理和跟踪往往会依赖于外部团队（部门外或公司外）。但是监控告警粒度太细了，可能很多告警都是一个事情。如上面的告警风暴中，由于应用程序故障，引发引发了大量的异常，之后又产生连锁反应，其实就是一个事情，只需要处理一个事情就行。
一般来说一线人员会采用邮件或者电话方式，直接通知对应负责人，但是这个就很难追踪和事后分析，所以一套事件管理机制。
ITIL规范的事件Incident流程很有参考价值，感兴趣同学参考下。事件工单需要：

事件单

影响范围和紧急程度的交叉矩阵影响到优先级

On-Call机制建立后，通过告警和事件数据分析、建立起以数据指标驱动的团队文化，有机会和大家分享。

OneA lert 是 OneAPM 旗下产品，是国内第一个 SaaS 模式的云告警平台，集成国内外主流监控/支撑系统，实现一个平台上集中处理所有 IT 事件，提升 IT 可靠性。想阅读更多技术文章，请访问 OneAPM 官方技术博客 。

本文转自 OneAPM 官方博客

alertmanager-配置文件

alertmanager启动时，通过参数--config.file指定alertmanager要加载的配置文件

alertmanager启动时，常用的启动参数配置

--config.file：alertmanager要加载的配置文件，是一个yaml格式的配置文件

--web.lister-address：监听Web接口和API的地址端口

--web.external-url：用于返回alertmanager的相对和绝对链接地址，可以在后续告警中直接点击链接地址访问Alertmanager Web UI

--data.retention：历史数据最大保留时间，默认为120h

--storage.path：数据存储路径

配置文件格式

alertmanager的配置主要分为5个部分，分别是全局配置(global)、告警路由(route)、抑制规则(inhibit_rules)、接收者(receivers)、模板（templates）

1）全局配置(global)：用于定义一些全局的公共参数，如全局的SMTP配置、Slack配置等

2）告警路由（route）:根据标签匹配，确定当前告警应该如何处理

3）抑制规则（inhibit_rules）:合理设置抑制规则可以减少垃圾告警的产生

4）接收者（receivers）：接收者是一个抽象的概念，它可以是一个邮箱，也可以是微信或者Webhook等。接收者一般配置告警路由使用

5）模板（templates）：用于定义告警通知时的模板，如HTML模板，邮件模板等

global:

   #可以配置alertmanager通知的目的地，比如可以配置邮件发送信息
#每个告警信息进入的根路由，用于设置告警的分发策略

route:

  #根路由不能有任何匹配器，因为它是所有告警的入口点。它需要配置一个接收器（也即receiver），以便不匹配任何子路由的告警发送出去。

  receiver: 'xxx' #告警的接收人，支持邮箱、webhook
  #将告警进行分组，避免海量告警，group_by这里指定的标签key对应的标签值相同的告警会被分到同一个组中，并且在发送告警时，聚合到一条告警中

  group_by: ['xxx']
  #当一个新的告警组被创建时，需要等待<duration的时长，然后将告警组中的告警发送出去

  group_wait: <duration
  #已经存在的告警组上一次发送告警时间是T，如果在最近一段时间内（即：<duration）alertmanager有接收到新的告警，则在T+<duration将告警组中的告警发送出去，如果T+<duration时间点没有数据，在T+<duration+<0.1duration时间点有新的告警，那么告警会立即发出，并且下一次检测发送的时间点是T+<duration+<0.1duration+<duration

  group_interval: <duration
  #已经存在的告警组上一次发送告警时间是T，如果在T ~ T+<duration时间段内告警组内都没有接收到新的告警，就在T+<duration时间点重新发送上一次发送的告警通知

  repeat_interval: <duration
  #上述属性是根路由的属性，由所有子路由继承，并且可以覆盖到每个子路由

  routes:

   #此路由对告警标签执行正则表达式匹配，以捕获与服务列表相关的告警

  - match_re:

     <label_key: <regex
   #此子路由捕获到告警时，需要通知的对象

   receiver: xxx
#抑制规则，如果发出的告警是由已发出的告警导致的，则匹配到的告警都不会被发送出去

inhibit_rules:

  #已经发出的告警的标签

- source_match:

   <label_key: <label_value

  #如果还没发出的告警满足这里的标签，并且满足source_match中标签的告警已经发出，那么target_match匹配的告警不会被发送出去

  target_match:

   <label_key1: <label_value1
#告警接收者

receivers:

- name:告警接收人名称

  <具体发送告警的目的地，支持email、webhook等
#template块保存告警模板的目录列表

templates:

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