报警分发系统的实现和总结

报警分发系统：https://github.com/smartxff/dingding_exporter
既然是上篇博客的实现结果，就以上篇的需求为主体结构来进行实现过程的说明和总结

1. 报警输入标记

　　控制本身的东西，永远比控制本身简单。报警消息发送过来时，只会告诉我那个实例有问题，有什么问题，至于这个实例属于谁，它并不关心。因此发送过来的告警所在的实例属于谁这件事，就得我本身程序实现了。毕竟控制本身简单嘛。

2. 获取报警

　　报警的获取来源是prometheus的alertmanager。它会发送给我一个固定格式的json，而后我能够从这个json中获取，报警信息。至于其余非prometheus的告警，我怎么获取呢？只要他发送个人消息知足这个json的部分字段，我就能够处理他的报警。因此此部分是以固定格式的请求body来实现复用。

3. 获取报警与接收人对应关系

　　由于咱们prometheus主要的监控来自于docker上跑的服务的url，咱们会进行探活，而每一个docker的项目的源代码都来自于gitlab。因此报警和接收人的关系就来自于gitlab了。毕竟每一个项目都是由建立者和修改着构造的。可是一个gitlab项目不只能够属于某我的，也能够属于某个组，我确定不可能给一个组的人都发送报警。我确定会被打死。咱们提交代码时都会commit。可是这个commit属于提交代码时的本地环境。本地环境和线上环境可能不一样步，好比你gitlab中叫张三，你本地叫sanzhang，那么commit里面保存的就是sanzhang。因此从commit中获取接收人信息就pass。虽然commit里面的信息不是gitlab上的，可是push代码这个event，事件自己是属于线上自己的。因此咱们的报警总会发送给最后一次提交代码的人。简直至关完美呀。咱们prometheus除了监控docker里面的项目，还监控了一些手动加上的监控项，好比某个外网url之类的。咱们只能经过读取本地对应关系表中的数据，来查找对应关系。此处试用yaml格式存储这些数据。而后没找到对应关系的报警会发送到咱们运维所在钉钉群中，咱们收到后能够选择手动添加对应关系，和咱们本身处理报警。此处算是实现了需求分析。

4. 根据标记和对应关系发送报警

　　用户基本上就使用两种接受信息的方式，一种是短信，一种是邮件。邮件仍是比较好实现的。钉钉群的机器人接口使用特别方便，因此测试阶段以及咱们运维接受报警主要使用钉钉群。邮件实现的比较简单，整体内容固定，只有内容和发送对象不一样。钉钉由于咱们本身使用，我实现的功能就更多一点。首先有一个默认的钉钉接口，主要接受没有匹配的接收人的告警。而后能够经过配置文件自定义哪一个实例的告诉发送到那个钉钉群。

其余实现

　　有些告警信息一时半会儿处理不了，可是prometheus咱们设置的同一个报警10，若是未处理10分钟发送一次。因此此处我加入了告警过滤的功能，固然也是以配置文件的形式实现。
　　钉钉群接口每分钟只能向它发送20次消息，超过这个数，此接口就会失效，必须手动生成新的webhook。因此我打算在钉钉发送消息这上面作一个限制，每分钟最多只能发送20个消息。目前还没实现，不过具体的思路已经有了。建立一个长度为20的chan，没收到一个发送钉钉告警的请求，就起一个goroutine，从chan中获取一个值，而后发出一个钉钉告警消息，sleep 1分钟后在往chan中发送一个值。就算一秒钟发送20个请求，chan里面的值为空，下一个请求，就会一直等待chan中的有值。只有超过一分钟后，其中一个gorutine给chan发送一个值。下一次请求才可执行。此处有点滥用chan的感受。不过嘛，优秀的程序员都是从写烂代码开始的~~~

不知道本身代码烂
知道本身代码烂，不知道为什么烂
知道本身代码烂，知道怎么写好
代码已经能写好，不知道怎么写更高性能的代码
代码能写好，也能写高并发，而且高可用，无状态。
那么，我就算是成为一个合格的程序员了。
加油！