Skip to content

bearqy/gomessage

 
 

Repository files navigation

GoMessage

用途说明:

GoMessage是一款消息转发器,主要功能为:

  • 更友好的图形界面的方式补全Prometheus + Alertmanager 报警链路中的最后一个环节,接收Alertmanager报警消息推送,完成消息格式化后转发到指定客户端上。
  • 接收其它工具的消息推送(例如Git的WebHook回调),完成消息格式化后转发到指定客户端上。
  • 接收任意Json结构的消息推送,完成消息格式化后转发到指定客户端上...

软件特色:

  • 一次接收,多端推送

  • 切割AlertManager消息中的数组,把Alertmanager聚合组中聚合起来的消息切割为单条然后逐一发送

  • 原始数据劫持,可以直观的观察到上游推送过来的json数据结构

  • 模板支持if...elsefor循环等逻辑门编写

  • 模板支持Markdown语法编写

  • 模板支持文本中插入CSS样式标签来控制字体颜色或其它样式渲染



投产架构:


版本说明:

假设当前版本为:v2.3.6

  • 2代表大版本:表示底层架构发生了向前不兼容的更新或变动。
  • 3代表中版本:表示底层架构依然向前兼容,但是增加了新的功能
  • 6代表小版本:表示没有增加任何新功能,只是对已知的问题和BUG进行了修复

查看所有的版本



体验地址:

点击右侧地址进行体验:http://47.102.46.109:7077

(作者是个人开发者,体验服务器只有1MB的带宽,加载较慢请稍稍见谅~)

小提示:

  • GoMessage的设计初衷就把它定位为内网基础设施工具,因此没有设计账号密码及权限相关的模块,广大用户可以借助Nginx的Base登录来控制相关权限。
  • 不排除以后会追加设计权限控制模块,但近期更新的版本暂时不考虑权限模块的开发。
  • 加作者微信 SPE3SRU3STAY 进入GoMessage技术交流群。



安装步骤:



安装包下载:

安装包下载地址(国内):https://gitee.com/gomessage/gomessage/releases (这个地址国内访问速度快~)

安装包下载地址(国外):https://github.com/gomessage/gomessage/releases

目前提供有Linux、Mac、Windows三个版本的安装包(x86_64架构),如需支持其它版本,可以自行下载源码编译,也可以直接联系作者编译出指定版本的安装包。



界面上的使用教程

(下图是v2.0版的界面,不排除后面版本中会对界面UI进行调整)

多通道设计

v2.x.x版最大的一个特色就是可以多通道并发工作:

image-20230612224906295

每个通道都会自动生成一个独立的消息入口,如上图所示的那样:

  • default通道消息入口:http://gomessage.taycc.top/go/message
  • prometheus通道消息入口:http://gomessage.taycc.top/go/prometheus

通道的命名规则为:http://<您的服务器地址>/go/<您的通道名称>,例如:

- http://192.168.33.201:7077/go/message
 
- http://192.168.33.201:7077/go/default 

- http://192.168.33.201:7077/go/<prometheus>

- http://192.168.33.201:7077/go/<zabbix>

- http://192.168.33.201:7077/go/<dev>

- http://192.168.33.201:7077/go/<fat>

- http://192.168.33.201:7077/go/<prod>

PS:当通道名称default时,GoMessage的域名生成模块会用message来代替default这个单词拼写显示在UI界面上,二者在路由层面的功能是一样的,此时 路由/go/message == 路由/go/default ;

也就是说,您向以下两个地址推送消息时,效果是等价的:

  • http://192.168.33.201:7077/go/message

  • http://192.168.33.201:7077/go/default

这种特殊的设计,只是为了让用户在部署完GoMessage后,不用增加记忆负担,直接就可以有一个默认的default通道来进行使用。如果您不需要这个通道,随时可以进行删除。



创建一个新的通道

可以通过点击左侧的【管理推送通道】按钮,来对通道进行增、删、改、查操作。

需要注意的是:一旦删除某个通道,那么该通道下的``所有资源`都会被删除,您可以很干净的来管理您的推送通道。

会被删除的内容如下:

  • 消息模板
  • 接收客户端
  • 用户变量映射

image-20230612230804968

使用通道的正确姿势

一个通道,由以下三要素组成:

  • 消息接收入口(接收上游的消息推送,只接受Post方式推送)
  • 内容体渲染(上游推送过来的消息是json格式,此时把json渲染成人类可读的信息体)
  • 接收客户端(把渲染后的信息体,推送给指定的接收客户端)



消息接收入口

每个通道的首页有两个很醒目的内容:

  • 消息推送地址的框框:这个被全自动识别出来的地址,就是当前通道的消息入口;直接粘贴这个地址给“上游的消息推送者“使用即可,不用做任何额外的处理,直接粘贴走就能用。
  • 模拟报警的按钮:考虑到很多用好刚创建好一个GoMessage通道时,想要快速的测试一下”当前通道“是否通畅。因此这里内嵌了一个”测试按钮“,点击这个按钮就会向当前通道推送一条json信息。该json内容是截取的一段Alertmanager报警流中推送出来的信息,数据结构同时包含数组、字典、多层嵌套等等的,数据结构很具有代表性,可以做各种复杂的推送测试。

image-20230612232037784



接收客户端

image-20230612232722386

image-20230612232813206

只需要点击【添加新客户端】按钮,可以创建对应的接收客户端。具体每个客户端【输入框】中的内容应该如何填写,参见下面详细的教程说明:

如果以上的客户端不能满足您的使用需求,您可以联系作者(作者微信:SPE3SRU3STAY)喊他帮您开发对应接收客户端。



数据渲染

一些想法(可以跳过不读):

过去几年有个问题让我思考了很久:随着内网基础设施自动化覆盖面越来越广,过去的人类主动去盯梢关注某些节点的工作方式,可能会无法满应对未来海量的机器信息扑面而来的局面;自动化越先进的场景下,越会逐渐演变成人类没有多余精力来持续跟进自动化全链路中多重节点了。那我们可否换一个方式来思考:是不是能让机器自动来向人类汇报!

(请注意此处的侧重点)不再是机器把自身运行状况存储在某个中间的介质中比如Promethus,再借用Grafana用大盘展示出来;而是由机器或链路的某个节点,直接把自身某个运行状况主动的向人类推送汇报。人类只需要像读取微信消息一样,读取到机器发送的消息即可。

那么在整个 机器---通知--->人类 的这个过程中,最被琐事淹没的环节就要数【任意数据结构的json原始机器信息都可以被转换成人类可读的友好信息的这个环节】最为占用我们的时间精力。具备开发力量的团队,可以使用Pyhon、Golang(或其它的某种开发语言)来编写一段程序,专门来干这个工作。但开发这个东西,开发者要分别阅读:钉钉客户端开发文档、微信客户端开发文档、飞书客户端开发文档、甚至短信发送开发文档、语音电话开发文档、等等。同时还要知道各种协议、标准、消息限流规范;甚至有的小伙伴还要关注程序运行的稳定性、高可用性,生产应急灾备恢复、等等的一堆问题。而缺乏开发力量的团队,则只能通过增加人手去解决日益增长的需求;面对这种客观存在的状况,在一定程度上浪费了团队的时间、精力、和珍贵的生产力。

作者认为这些不同厂商的开发文档阅读消息内容的渲染零碎的代码调试重复的思维复杂度投入等等此类琐事都应该被消灭。同时消灭琐事刚好符合SRE技术哲学追求的一个重要方向,因此GoMessage在设计之初,就秉承着更加简单高效的帮助用户解放时间和精力为理念。不断地优化和打磨消息渲染模块,试图追求一种 简单、再简单、更简单、简单到优美的一种使用方式。(但由于作者的水平有限,对复杂问题的思考可能缺乏特有的视角,因此接下来的消息渲染功能在使用体验上可能依然存在某种复杂度,在此恳请各位小伙伴能够给于一些宝贵的反馈和建议,作者会在业余时间对GoMessage会不断的迭代更新下去,我们一起去做振奋人心的事~)


GoMessage尽可能的设计了比较简约、简单、且有广泛兼容性的数据渲染方式,摆脱了传统的去命令行里写配置文件(或)只能限定在较小的灵活度内去编写模板的传统方式。操作界面截图如下:

image-20230613002543541

剩下的明天再写~



交流和问题反馈:

微信扫码加入GoMessage技术交流群:

如果二维码失效可以添加作者微信号 SPE3SRU3STAY 邀请您进群。

About

一款轻量、友好、万能的消息转发器~

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • Go 54.3%
  • Vue 37.7%
  • JavaScript 4.4%
  • Makefile 2.6%
  • Other 1.0%