告警与事件集成的关系（什么是警告事件）

本文目录一览：

• 1、如何快速、灵活的实现告警通知，第一时间解决问题？
• 2、告警百科中的告警词条由哪些部分组成
• 3、有效运维的 on-call 机制
• 4、SDH告警及性能事件产生原理？

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

数据中心产生告警噪音，一般由两个大的原因所引起：1、存在大量重复的告警：大多数监控系统关注的点在快速、无遗漏地将异常告警抛出。2、大量的告警因为服务组件之间的相互依赖关系、相互影响，而产生的大量的关联告警。

所以，在告警发生的时候，可以使用告警优先级推荐算法来分析处理问题。根据规律特征进行判别，看是否需要立即关注。再配合自动化工具，将推荐等级与原始等级都高的告警加上筛选规则，进行自动化开单处置。发现推荐等级与原始等级有背离的部分，可以筛选出来做复盘，对告警原始的等级进行优化，或者转化成升降级的规则逻辑来处置告警等级。擎创告警辨析中心4.0是擎创科技研发的新一代智能告警管理、分析及处置平台，可配置能力更成熟，具有更开放的集成能力，可以将数据中心的监控系统、ITSM流程平台系统、自动化引擎系统、知识库系统、通知类平台等系统无缝集成，并驱动整个数据中心运维体系更快、更智能、更流畅运行。不仅可以满足科技能力及数据治理较强的企业需求，同时也可以通过智能化手段满足科技及数据治理较差企业的需求。

告警百科中的告警词条由哪些部分组成

告警：系统发生故障时，监控单元将视故障情况给出告警信号，所有故障均有声光告警及文字提示。告警时，监控单元上的红色告警灯亮，蜂鸣器发出报警声，并向远端监控中心发出告警信息。

告警分类

交换局的告警应按照故障的严重程度进行分类，一般应至少分为两大类，即紧急告警和非紧急告警。告警系统中，除交换设备本身外，还应包括其他告警，如电力室设备告警、空调设备告警、外线电缆故障告警、无人值守局开门告警等。

告警层次

交换局的告警层次应分为机架(柜)告警、列架告警和总告警3部分。告警信号应逐级重复，即列架告警重复机架(柜)告警信号，总告警重复列架告警信号。

对于规模较小的交换局，因设备数量较少，允许只设机架(柜)告警和总告警两种。在多层建筑的交换局中，可视和可闻总告警应接入不同楼层。紧急告警信号应能送至集中的告警中心或维护中心。

告警信号

告警信号应具备可闻和可视信号。可闻信号采用直流电铃，响铃方式应分为连续铃、断续铃和单次铃(1秒铃)3种。可视信号采用不同颜色的灯信号，灯色分为红、蓝、绿、白、黄5种。按照故障的严重程度由不同的灯色和铃声及其不同组合来表示。交换局中对某些非紧急告警或一般提示性的技术信号告警，可以只设灯信号而不同时出现可闻信号。[2]

告警设备

告警系统的设备一般包括告警控制电路、机架(柜)告警信号灯、列架告警灯盘、总告警信号盘，其中警铃只设于总告警信号盘内，各机架(柜)告警信号灯种类可根据需要设置。

告警处理单元

告警处理的功能是监视或者询问网络中与告警有关的事件或状态。系统是按照面向对象的概念来设计的，在网管系统中，如下对象和告警处理单元有关，它们是网元、设备、当前告警、鉴别器、事件前向鉴别器、日志、日志记录、告警记录等。

排除步骤

监控系统的故障包括电源系统故障和监控系统故障，监控途径有通过监控告警信息发现如市电停电等故障；通过分析监控数据发现如直流电压抖动，但没有告警等故障；观察监控系统运行情况异常，发现如监控系统误告警等故障；进行设备例行维护时发现熔断器过热等。

告警信息按其重要性和紧急程度划分为一般告警、重要告警和紧急告警。监控值班人员在发现告警时应立即确认，并进行分析判断和相应处理。

注：截止2017年5月22日，详情及更新到百度百科词条：【告警】查看。

有效运维的 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 官方博客

SDH告警及性能事件产生原理？

SDH告警是由于他自身有自检系统，可以看看关于字节编码及帧结构的组成，性能的产生同样是基于这个原则的。只不过是告警为为严重一般会影响业务，而性能的大小取决对业务影响的大小，