运维就要无所不能,无所不会
先有监控,后有告警。如果说监控是一瓶红酒,那么告警就是开瓶器,不然只能望酒兴叹「哈哈,想了半天没有找到合适的比喻,刚好有喝酒撸文的习惯,一口下肚觉得很应景,特此做的借喻」。
告警很重要,想想「三体」中人类星际舰队被水滴攻击,人工智能系统却无法发现攻击源,这实在太可怕了。结合日常工作,我抛以下几个问题,作为文章的开始:
告警平台正常运行,因紧急变更、人为失误等异常情况导致告警风暴和连锁故障,那么如下:
告警,讲究:
看似简单,却和Consistency(一致性)、Avaliability(可用性)、Partition tolerance(分区容错性)「CAP原则」一样,通常只能三选二!
告警处理流程
如图,为告警处理逻辑,分三段:
事件输入:通常遇到的问题是事件太多;
事件决策:通常遇到的问题是决策名存实亡,狼来了的故事太多;
事件处理:未知因素太多,绝大多数公司都做不好,停留在表层,效果好坏,全看老板是否关注,NOC团队是比较好的解决方案之一;
所以,如下情况很常见:
告警太慢被老板骂,告警太多被同事骂。出了问题,开发比运维先知道,还老在群里喊。这谁受的了!
人人都觉得监控工作很LOW B,但却没几个做的好的!
数据精准、详实、全面、及时。为决策层夯实基础
策略有效、可自动执行、有收敛、有自愈。一句话,就是去人化!
有告警必处理! 看起来简单,但实际几乎做不到。
告警平台功能集
通知告警平台最少需要具备如下功能:
邮件、短信、电话、企微/钉钉/飞书。短信,电话必备
告警来源号码被屏蔽,标记为广告常见。虽厂商有自动换号机制,但健康检测不可少
为告警收敛打基础,减少告警信息,避免告警风暴
特别重要,依次要有告警自愈、级联告警、告警收敛
针对不同告警权重,做对应告警策略。
分业务、分模块、分团队、分时段,必不可少
包括告警通道告警和告警职级升级
告警收敛首先要解决的问题是告警风暴! 回到文首的问题,假设告警平台正常,如何在海量告警中定位到问题根源,或罪魁祸首!
分业务、分模块、分团队,简单的如DB类的告警通知DBA团队,Nginx的告警通知业务运维。精细化的案例,如:A业务模块告警只通知A运维,而非通知GROUP组。但没有解决Leader
要接受所有告警的场景。
有告警自动抑制功能,需事先做告警级联。上游告警屏蔽下流告警。但不容易解决跨团队信息同步的问题。如路由器挂了,如不通知业务侧,会造成重大生产事故无法及时处理。如DB Master挂了,如果不通知 Replication 同步失败,会容易遗漏处理主从失败问题。
有手动入口设置告警静默,如常规发布窗口,需有入口关闭告警。如明知A告警会引发B类告警,可以提前关闭B类告警。但不容易解决告警遗忘的问题。如维护期结束,告警静默却没有关闭导致告警无法发出。定时告警静默的功能,也不能覆盖全场景。且已经了出来的告警,再静默无效。
收敛有很多方式,常见的如:同属性维度收敛、时间维度收敛、次数收敛。但和告警及时性冲突,收敛做的越好,越容易造成告警不及时。导致开发比运维先发现问题,容易造成部门间关系紧张。
同属性维度收敛:zabbix相同事件名、相同主机名、相同业务名称、告警统一ID,等可以做为唯一标识的字段,做频次收敛,或告警合并
时间维度收敛:判断单位时间内告警条数,做告警合并。时间单位通常以秒为单位,和业务属性强相关。通常也会结合属性维度。
最后,总结如下: