背景
对很多公司而言,保证服务可用,在服务不可用时报警到相关服务负责人提醒其及时修复,是非常重要的一件事。在我司,看服务可不可用,是分配给员工们还停留在人眼观察阶段。由行政人员安排轮流值班,每个人负责两周。
每人两周的值班表
我觉得这个事情由人来看有三个缺点:
- 浪费了人力,值班的人不能全心全意把心思放到工作上。
- 报警不够及时,值班人员不可能时刻将注意力放在这上面。
- 值班人员只是将异常的服务截图发到群里,有可能不知道通知谁来处理,且真实的责任人看到这个截图又需要一定时间。
这眼看着很快就要轮到我了,我比较懒,于是就找旁门左道来替我处理这件事了。
Prometheus
普罗米修斯介绍
Prometheus(普罗米修斯)是一套开源的监控/报警/时间序列数据库的组合,由SoundCloud公司开发。
Prometheus基本原理是通过HTTP协议周期性抓取被监控组件的状态,这样做的好处是任意组件只要提供HTTP接口就可以接入监控系统,不需要任何SDK或者其他的集成过程。这样做非常适合虚拟化环境比如VM或者Docker。
Prometheus应该是为数不多的适合Docker、Mesos、Kubernetes环境的监控系统之一。
普罗米修斯架构图
Alertmanager模块的扩展 Email VS Wechat
普罗米修斯Alertmanager模块提供了Email通知,但是用户查Email不频繁,而且很容易将用户邮箱塞满,以至于后面被邮箱系统判为垃圾邮件,失去了通知的意义。
和邮件形成对比的是微信,微信似乎已经成了大部分人手机里使用最频繁的软件了,而且有桌面客户端,即使不看手机,在电脑上工作也能收到消息。一收到消息,特别是@到自己的消息,好奇心会趋势用户打开,看到了自己的服务出现了错误,在群聊里丢了脸,会尽力尽快修复,这也达到了及时通知的目的。
wechaty
之前美团和饿了么红包在微信里抢大红包,我那时候第一次知道微信有自动分组、回复和对消息的监听的框架。我在GitHub里搜到了一个叫wechaty的开源微信SDK,它基于微信公开的API,对接口进行了一系列的封装,提供一系列简单的接口,然后开发者可以在其之上进行微信机器人的开发。
最终促使我使用这个库的原因很简单,是一个墙外用户的评价:**”太好用,好用的想哭”。没想到我后面在墙内部署的时候,真的哭了。
|
|
配合node.js用起来真挺方便的,如果起在本地,已经可以正常的工作了。虽然有个小瑕疵,就是需要在群聊里先说一句话,才能找到这个群聊,因为群聊跟联系人还不同。
部署在docker端
因为本地机器的IP地址是会发生变化的,因此需要将这个服务部署到docker端,且wechaty宣称支持docker端部署,于是就进行了一番尝试。
部署到docker,首先遇到的问题的是无法将二维码或url实时传出来,除非通过查询log文件。于是就在代码里集成了邮件模块,将二维码的url以邮件的形式发出来。url里有个坑,刚开始发出来的url是经过替换的,需要将/r/换成/qrcode/。
wechaty是需要红芯浏览器(chromium)内核的,需要科学的上网方式,整个Image build完之后居然有2G。node的版本也需要v8,v10检查会严格一些,跑不通。
(dockerfile附录于文末)
反响和未来工作
服务投入使用第一天,值班人员觉得没他什么事了,我就觉得我做这项工作是值得的,减轻了所有人值班的压力。
报警样例与值班人员的反响
现在遇到的问题是报警给很多人,后面想实现一个基于订阅的点对点推送应用。
#附录 Dockerfile
|
|
原文作者: Chih-Hao
原文链接: http://zhihaozhang.github.io/2018/09/09/prometheusPlusWechat/
发表日期: September 9th 2018, 10:13:06 pm
版权声明: 本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可
-
Next PostMatch开发笔记 肆 极光推送接入指南(Swift版)
-
Previous Post上架沙盒化应用,重启应用后保持文件持久访问性指南