监控告警有很多种方式，有邮件，有短信，有电话，方式各种各样。。。接口总比方法多。
在prometheus的监控系统中，自带就有告警系统，就是alertmanager组件，除了可以在prometheus中配置，也可以在grafna中进行配置邮件的相关信息。
告警。。。一个系统一天发出2个故障，就已经够了，按照处理时间来算，on call超过2个故障就已经超出了on call人员的处理时间。。。邮件告警可以认为是可以延迟处理的工单，告警应该出现的原因不同，如果一个告警出现的次数超过3次，那么要么就是屏蔽这个告警，要么就应该找到本质原因，然后进行优化。
邮件告警配置
在进行邮件告警的主要配置在alertmanager容器中：
配置文件内容如下：
运行alertmanager容器：
测试发送邮件（需要设置告警规则）：
查看收到的邮件：
在程序恢复之后，alertmanager中的告警自动恢复，但是不会发送邮件恢复通知。
在使用163邮箱的时候，如果查看容器docker logs -f alertmanager，550 user permission is denied，那么表示权限不足，需要在邮箱中开启访问权限。
在使用镜像的时候，如果出现报错连接5001端口，表示配置文件的路径不对，没有覆盖默认的配置文件，默认的是slack的5001端口。
风言风语
在告警的时候，我们能做什么。。。让告警系统闭嘴是最好的咯。
告警规则的设计，尽量简单，但是又能反映出是什么组件有问题，及相应的处理方法。。。在故障发生的时候，并不能抗住多少压力，脑子一片空白，所以还是有应急预案是最好的。
除了告警规则的设置，另外能做的就是在告警发出的时候，能做什么？如果能每次找到根本原因，从代码的层面进行修复，那么是最好的，如果不能，那就只能调用其他的系统来进行修复了。。。例如收到一个告警，一个VM宕机，那么可以找到配置中心，根据相同的配置在一个空闲的machine上拉起一个VM，能快速的恢复业务，而物理机宕机则可以慢慢的进行处理。
区分紧急警报和工单很重要，界限在哪里，而很多情况下并不是很明确，这个需要研发部门和业务部门共同商量得出，哪些事关键的核心服务，一旦出现问题，那么必须人工介入进行处理，否则就会拖累SLA。
babysitting。。。不会带孩子，一哭就慌了。。
