运维监控系统实战笔记
秦晓辉
快猫星云联合创始人,Open-Falcon、Nightingale、Categraf 核心研发
7894 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 25 讲
运维监控系统实战笔记
15
15
1.0x
00:00/00:00
登录|注册

21|事件管理(上):事件降噪的几个典型手段

你好,我是秦晓辉。
前面一章我们介绍了各个部分的监控实战,偏重如何采集数据、如何构建仪表盘。有了这些监控数据之后,下一步就是告警了,几乎所有的监控系统都具备生成告警事件的能力,但通常都不具有完备的事件后续处理能力。这里说的后续处理主要包括:多渠道分级通知、告警静默、抑制、收敛聚合、降噪、排班、认领升级、协同闭环处理等等。监控系统或多或少都有一些这方面的能力,但是通常都不完备,而这,正是 PagerDuty 这种产品存在的价值。
在事件处理方面,一般我们会遇到两个痛点,一个是告警事件太多,被过度打扰,另一个是重要告警疏漏,无法闭环处理。这个部分我会用两讲内容来介绍这两个痛点的解法。下面我们先来聊一聊告警事件太多的问题,看看通常是什么原因导致的。

告警太多的常见原因

最常见的原因,是告警规则设置得不合理。比如很多规则触发了告警之后,实际没有后续动作,只是起到常态化通知的效果,不需要排查,也不需要止损,甚至连个长线的 TODO 都没有。这类告警多了人就疲了,当重要的告警来临的时候,也容易忽略。这样的规则如果不经过治理,日积月累,就会产生很多无用的告警。
第二个常见的原因是底层出问题导致所有的上层依赖都告警,越是底层影响越大,比如基础网络如果出问题,发出几万条告警都是正常的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《运维监控系统实战笔记》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(6)

  • 最新
  • 精选
  • SICUN
    1.课后题:推送的报警信息可以带链接,链接跳转的页面添加人工介入的按钮,人工介入后对应报警就只记录不推送了,人工处理完之后把对应事件置为已处理,然后接着走监控告警规则,建议在加一个最大的单次人工介入处理时间,防止人工处理完忘记点已处理导致后续监控不推送问题。 延伸:问题解决后可以复盘问题反复出现的原因,然后对恢复脚本或是告警规则做改进。 2.想请问一下老师水平触发(Level Triggered)工作模式和边缘触发(Edge Triggered)工作模式的适用场景有哪些

    作者回复: 这俩词我第一次听说😅

    归属地:北京
    2
    2
  • 晴空万里
    老师课程里面好像没有介绍:告警触发引擎的设计逻辑吧?还是我没看见,最近公司在做监控告警平台,不知道告警触发引擎怎么设计实现

    作者回复: https://github.com/ccfos/nightingale/wiki/faq 007号问题

    归属地:广东
  • peter
    请教老师几个问题: Q1:告警处理这一块目前是否引入了AI和大数据? 告警事件需要几个月的保存,通常会积累大量的数据。请问,针对这些历史数据,公司是否会引入大数据和AI进行处理?或者目前是否有一些比较先进的公司采用了这些手段?比如阿里、京东等。 Q2:需要配置多少运维人员? 公司一般需要配置多少运维人员?可以结合具体的例子。比如极客这种规模需要多少?如果不了解极客的情况,不好回答,这时候可以根据作者自己公司的规模回答。 Q3:能否以作者自己公司作为例子讲解?即作者自己公司是怎么做监控的,比如,公司大致有什么业务,流量多大,用户量多大,机器数量等,基于这些信息,采用了什么框架进行监控、运维。老师可以以自己目前所在的公司为例子进行讲解,也可以以以前的单位为例子。如果方便的话,建议以加餐形式用一节课来讲;如果不方便,就在留言中回复即可。

    作者回复: 1,我了解的公司没有在事件这块引入ai的,即使有,也是实验性质的,效果一般,因为数据量太小 2,case by case 来看,我们公司没有运维 3,很多数据是不能对外讲的,至于用什么方案,指标层面我觉得categraf+nightingale可以解决绝大部分公司的问题

    归属地:北京
    2
  • 那时刻
    思考题:如何处理报警重复的问题,我觉得可以通过滑动平均值的方式来聚合报警,比如,报警第一次触发的时候发出报警,然后在一定的时间之内如果有相同的报警发出/解除,进行滑动平均计算,如果达到再次报警或者是报警升级的阈值,再次报警;如果达到解除报警的阈值,则解除报警。以此来减少重复报警的次数
    归属地:北京
    1
  • wayne
    之前我也一直在尝试引入AI来做告警收敛,效果不明显;最后还是通过时间线+告警层级两个维度来做收敛,效果更好些。不过大部分收敛规则是要运维同学花时间去配置的,他们也提出能否减少配置的功能,自动去聚合,老师提到的从告警接收人+告警时间维度来聚合,确实是个不错的解决方案,可以减少运维同学的配置工作。
    归属地:浙江
  • Geek_1a3949
    课后题:配置或增大告警规则的留观时长,观察一段时间后再恢复。
    归属地:上海
收起评论
显示
设置
留言
6
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部