实时警报通知:微信告警通知的重要性解析
523
2023-03-20
本文目录一览:
其实在一线运维工作中,常常是福不双至,故障不单行。每有运维问题发生的时候,往往会密集发生多个告警。当这些告警来袭的时候,一线运维人员要针对它的类型、等级、告警对象和内容等进行检查并选用合适的方法来应对。
告警等级较高时,比如持续出错的应用告警,在查验后会立即分派通知相关的负责人在第一时间开具事件工单,做对应的流程追踪;而遇到低等级或次要的系统告警,则可以暂缓处置,留作观察。
传统的处置方式需要用经验来判断问题的影响范围和严重性,再通过人工进行派单以及通知下游处理人员,这样效率低下,无法满足现今业务响应速度的要求了。
究其原因,有些周期性发生的高频问题,往往并不是最棘手的,是可以延后处置的。反而偶发的问题,比较需要特别关注(如果这是原始定级较高的故障,更应该第一时间关注)。
所以,在告警发生的时候,可以使用告警优先级推荐算法来分析处理问题。根据规律特征进行判别,看是否需要立即关注。再配合自动化工具,将推荐等级与原始等级都高的告警加上筛选规则,进行自动化开单处置。发现推荐等级与原始等级有背离的部分,可以筛选出来做复盘,对告警原始的等级进行优化,或者转化成升降级的规则逻辑来处置告警等级。
[编者按]本文作者为陈伯龙,云告警平台 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 官方博客
现今工程中用的较多的有两种类型的安防集成系统告警与事件集成处理系统,一类以AD/NTK公司推出的AD5500“王者之剑”图形管理系统和 NTK22O0“天网”安防系统为代表告警与事件集成处理系统,前者对单一工作站之中的CCTV、门禁、内部通讯、报警等进行全面的控制,后者集网络通信与系统集成于一体,实现融AD切换器及各品牌门禁、可视对讲、报警、电话线传输工作于一网,全面解决安防系统集成及安防系统后期扩容的兼容问题告警与事件集成处理系统;另一类则以ADEMCO集团推出的ADEMCO安防集成系统为例,该集成系统主要是报警、门禁等系统与CCTV系统之间的联动集成,由于Javelin CCTV系统的开放性通信协议及微机设计的特点,CCTV系统非常易于其它系统联动集成。
AD5500图形管理系统
“王者之剑”V2.0版本是一个图形保安系统管理器,它为用户提供一个良好界面,在单一工作站中可给AD/NTK公司的矩阵切换系统、门禁、内部通讯系统及“王者之剑”本工作站系统内其它设备提供完整的控制服务。
“王者之剑”最多能对9个AD矩阵切换系统,1024个摄像机和128台监视器进行控制,“王者之剑”通过AD2096报警输入单元连接各个报警探测器,能根据报警触点的动作,自动调出报警区域的图形资料并产生音响和显示报警区域的图像,16种报警优先级的警报图形可以应付多个报警事件同时发生的情况。
“王者之剑”通过RS-232控制模块/驱动程序给门禁系统、内部通讯系统、灯光系统及其它 CCTV系统的附属设备如多画面处理器、录像机、数字图像处理器等提供完善的系统控制。
“王者之剑”具有完善的辅助设计程序(CAD),供用户设计所需监管区城的平面图形。
NTK2200系列系统
NTK2200系列“天网”安防网络系统是基于WindowsNT的软件包,它允许将安防工程中的管理子系统,如CCTV、门禁、报警、内部通讯以及楼宇管理系统集成在一起,只用一个简单的图形操作界面来控制,网络应用软件符合 OASIS(开放结构的安防集成标准)要求,设计成模块化结构,使系统在设计、分布式控制以及处理方面具有极大的灵活性和可扩展性。
OASIS网络标准是一个公开的开放性结构系统,可通过计算机工业标准内部处理通讯法(IPC)将安防工程的子系统集成在一起,IPC方法主要 TPC/IP和OLE2,该网络标准要求子系统管理器通讯以协调事件联接、共享的数据浑管理、操作与处理方法等,该标准使子系统之间的通讯和集成不限于一个操作系统内,就像在网络上。
“天网”软体的具体结构及联网控制原理如下:
“天网”软体与通信控制模块(CIM)、端口管理器和与CIM相通信的子系统(如CCTV、门禁等)一起组成安防联网系统。在整个系统中,“天网”的主要作用是一个集成安防系统管理器,该软件由壳程序(Shell programe),各种通信控制模块(CIM)及端口管理器(Port Manager)组成,其中壳程序是天网软件的控制部分,主要完成对CIM的控制、管理以及CIM之间的集成和通信;CIM是通信接口软件,主要与连接到天网上的子系统(CCTV、门禁等)进行通信;端口器是直接与子系统相连接的通信端口处理软件,完成与各种不同的子系统端口的物理通信连接。“天网”通过 CIM接受和发送事件信息,它可将天网产生的事件信息传给子系统,也可将子系统发生的事件信息传给大网。端口管理器不
断根据子系统的当前情况更新 CIM软件中子系统的状态,例如如果门被打开,端口管理器将通知每个相关有CIM,CIM将更新天网系统中相应图标的状态。
发表评论
暂时没有评论,来抢沙发吧~