Alarm

alarm模块是处理报警event的，judge产生的报警event写入redis，alarm从redis读取处理，并进行不同渠道的发送。

设计初衷

报警event的处理逻辑并非仅仅是发邮件、发短信这么简单。为了能够自动化对event做处理，alarm需要支持在产生event的时候回调用户提供的接口；有的时候报警短信、邮件太多，对于优先级比较低的报警，希望做报警合并，这些逻辑都是在alarm中做的。

我们在配置报警策略的时候配置了报警级别，比如P0/P1/P2等等，每个及别的报警都会对应不同的redis队列 alarm去读取这个数据的时候我们希望先读取P0的数据，再读取P1的数据，最后读取P5的数据，因为我们希望先处理优先级高的。于是：用了redis的brpop指令。

已经发送的告警信息，alarm会写入MySQL中保存，这样用户就可以在dashboard中查阅历史报警，同时针对同一个策略发出的多条报警，在MySQL存储的时候，会聚类；历史报警保存的周期，是可配置的，默认为7天。

部署说明

alarm是个单点。对于未恢复的告警是放到alarm的内存中的，alarm还需要做报警合并，故而alarm只能部署一个实例。需要对alarm的存活做好监控。

配置说明

配置文件必须叫cfg.json，可以基于cfg.example.json修改

  1. {
  2.     "log_level": "debug",
  3.     "http": {
  4.         "enabled": true,
  5.         "listen": "0.0.0.0:9912"
  6.     },
  7.     "redis": {
  8.         "addr": "127.0.0.1:6379",
  9.         "maxIdle": 5,
  10.         "highQueues": [
  11.             "event:p0",
  12.             "event:p1",
  13.             "event:p2"
  14.         ],
  15.         "lowQueues": [
  16.             "event:p3",
  17.             "event:p4",
  18.             "event:p5",
  19.             "event:p6"
  20.         ],
  21.         "userIMQueue": "/queue/user/im",
  22.         "userSmsQueue": "/queue/user/sms",
  23.         "userMailQueue": "/queue/user/mail"
  24.     },
  25.     "api": {
  26.         "im": "http://127.0.0.1:10086/wechat",  //微信发送网关地址
  27.         "sms": "http://127.0.0.1:10086/sms",  //短信发送网关地址
  28.         "mail": "http://127.0.0.1:10086/mail", //邮件发送网关地址
  29.         "dashboard": "http://127.0.0.1:8081",  //dashboard模块的运行地址
  30.         "plus_api":"http://127.0.0.1:8080",   //falcon-plus api模块的运行地址
  31.         "plus_api_token": "default-token-used-in-server-side" //用于和falcon-plus api模块服务端之间的通信认证token
  32.     },
  33.     "falcon_portal": {
  34.         "addr": "root:@tcp(127.0.0.1:3306)/alarms?charset=utf8&loc=Asia%2FChongqing",
  35.         "idle": 10,
  36.         "max": 100
  37.     },
  38.     "worker": {
  39.         "im": 10,
  40.         "sms": 10,
  41.         "mail": 50
  42.     },
  43.     "housekeeper": {
  44.         "event_retention_days": 7,  //报警历史信息的保留天数
  45.         "event_delete_batch": 100
  46.     }
  47. }

进程管理

  1. # 启动
  2. ./open-falcon start alarm
  4. # 停止
  5. ./open-falcon stop alarm
  7. # 查看日志
  8. ./open-falcon monitor alarm

报警合并

如果某个核心服务挂了，可能会造成大面积报警，为了减少报警短信数量，我们做了报警合并功能。把报警信息写入dashboard模块，然后dashboard返回一个url地址给alarm，alarm将这个url链接发给用户，这样用户只要收到一条短信（里边是个url地址），点击url进去就是多条报警内容。

highQueues中配置的几个event队列中的事件是不会做报警合并的，因为那些是高优先级的报警，报警合并只是针对lowQueues中的事件。如果所有的事件都不想做报警合并，就把所有的event队列都配置到highQueues中即可