alert核心的功能其实非常简单,就是定时去聚合计算一个时间窗口内的数据,然后根据阈值去比较,超过阈值则发出告警,触达开发或者noc同学,让相应的同学排查相应的故障.
数据来源
log base
alert的数据可以基于打出来的日志来做聚合,比如在spring中,可以通过异常处理,将所有的异常日志打到一起,当日志写进存储后,对其进行聚合,常用的开源组件就是es,每五分钟聚合一次,统计下时间窗口为5min内的错误数,超过阈值则报警.
这种方式的优缺点都很明显,优点是很简便,开发不需要接太多的组件,除日志中间件外也不需要维护一套中间件,缺点就是一旦数据量较大时很容易将计算节点拉爆.
这种具有聚合能力的日志组件,当然也有商业的可以采用,比如大名鼎鼎的splunk,阿里云的sls,微软的Data explorer,但是价格极贵,不是一般公司能用得起的.
mertic base
基于mertic的数据做出来的alert,不会有log base这种性能很拉胯的情况,当然也存在很明显的缺点,就是需要手动埋点.常用的开源组件prometheus,能够对历史的mertic进行预测,数据不在合理的区间也能做到告警,这就很哈拉少.
alert
alert合并
福无双至，祸不单行,当一个alert被发出来的时候,如果没有问题进行修复,在接下来的一段时间,也会有很多一样的alert被发出来,相信很多小伙伴有这样的体会,某一个接口发出了一个问题,接下来的一个小时,接到了365个同样的alert,这个需要把同样的alert进行合并,根据同一个规则在短时间内理应被认为是同一个alert,而不应该是多个,在商业软件pagerDuty中,它通过在上报告警的rest接口中指定depKey来区分是否是同一类告警,如果没有指定,它也有一定的自学能力,通过告警的名称来判断是否需要合并成一个incident.
alert认领
告警认领的人通常需要去解决告警的问题,如果实在解决不了,也可以assign给熟悉这块业务的同事来处理.
自动解决
自动解决这个功能也很实用,场景如下,比如某段时间系统抖动,产生了一个告警,后来系统又恢复正常了,这个时候系统应该自动将其标为resolved,而不需要再去触达开发同学大半夜起来看问题.
事件总线
事件总线是从全局的视角来观察系统发生了哪些事情,一旦发生告警,可以通过事件总线来得知可能关联的问题,事件总线需要结合ops,将deploy等变更信息,alert等信息进行上报,然后将其串起来,以可视化的方式来进行定位问题,举个例子,比如A同学接到了一个alert,打开事件总线,发现上游服务也发生了一个alert,时间很接近,在往上看发现该服务一个小时内有变更,这个时候可以大概率推断是上游服务变更导致,再去看日志,就很容易排查出问题.
触达
触达的方式可以是电话,sms,email,微信,钉钉等等多种多样的方式,反正怎么方便怎么来
slo
slo需要解决的问题是对哪些功能进行监控,并且故障率达到多少需要产生alert,不同的功能定出来的slo是不一样的,比如订单服务,故障率超过10%就已经是很大的问题了,但是这个10%放在非核心功能上,可能连塞个牙缝都不够.