promethues邮件告警

序言

     监控告警有很多种方式,有邮件,有短信,有电话,方式各种各样。。。接口总比方法多。


    在prometheus的监控系统中,自带就有告警系统,就是alertmanager组件,除了可以在prometheus中配置,也可以在grafna中进行配置邮件的相关信息。


    告警。。。一个系统一天发出2个故障,就已经够了,按照处理时间来算,on call超过2个故障就已经超出了on call人员的处理时间。。。邮件告警可以认为是可以延迟处理的工单,告警应该出现的原因不同,如果一个告警出现的次数超过3次,那么要么就是屏蔽这个告警,要么就应该找到本质原因,然后进行优化。

邮件告警配置

     在进行邮件告警的主要配置在alertmanager容器中:

promethues邮件告警

    配置文件内容如下:

promethues邮件告警

    运行alertmanager容器:

promethues邮件告警

    测试发送邮件(需要设置告警规则):

promethues邮件告警

    查看收到的邮件:

promethues邮件告警

promethues邮件告警

    在程序恢复之后,alertmanager中的告警自动恢复,但是不会发送邮件恢复通知。


    在使用163邮箱的时候,如果查看容器docker logs -f alertmanager,550 user permission is denied,那么表示权限不足,需要在邮箱中开启访问权限。

promethues邮件告警

    在使用镜像的时候,如果出现报错连接5001端口,表示配置文件的路径不对,没有覆盖默认的配置文件,默认的是slack的5001端口。

风言风语

   在告警的时候,我们能做什么。。。让告警系统闭嘴是最好的咯。


    告警规则的设计,尽量简单,但是又能反映出是什么组件有问题,及相应的处理方法。。。在故障发生的时候,并不能抗住多少压力,脑子一片空白,所以还是有应急预案是最好的。


    除了告警规则的设置,另外能做的就是在告警发出的时候,能做什么?如果能每次找到根本原因,从代码的层面进行修复,那么是最好的,如果不能,那就只能调用其他的系统来进行修复了。。。例如收到一个告警,一个VM宕机,那么可以找到配置中心,根据相同的配置在一个空闲的machine上拉起一个VM,能快速的恢复业务,而物理机宕机则可以慢慢的进行处理。


    区分紧急警报和工单很重要,界限在哪里,而很多情况下并不是很明确,这个需要研发部门和业务部门共同商量得出,哪些事关键的核心服务,一旦出现问题,那么必须人工介入进行处理,否则就会拖累SLA。


    babysitting。。。不会带孩子,一哭就慌了。。


上一篇:深度解锁SpringCloud主流组件 一战解决微服务诸多难题


下一篇:Alertmanager基于Webhook集成钉钉告警