上报应用初步选型是 go 语言,因为编译出来才一个文件方便部署。
但是对于如何上报信息有没有比较成熟的长连接方案。
本来是想要用 socketio 的。但是找了一圈发现没有成熟的 go socketio client 实现方案。
各位 v2 大佬帮忙推荐一下还有没有其他的方案?不想写最底层的 tcp 连接
1
julyclyde 2023-09-18 15:01:15 +08:00 2
重复发明轮子
用 prometheus 配套的 exporter 就行了 另外,别用“上报”,要用 pull 模式 |
2
matepi 2023-09-18 15:07:13 +08:00
如果上报指的是上报监控类信息的话,为啥要选择长连接方案?
业界标准上对于上报非关键信息的话,短连接 UDP 已经是标准做法了吧。突破现有标准做法的是有什么特殊需求目的、和环境特异性么? |
3
moonrailgun OP @julyclyde 上报的原因是可能需要把内网机器的信息上报到公网。用 pull 模式的好处是?
不用 prometheus 的原因就是不想一系列使用 prometheus + grafana + exporter 全家桶. 不同场景用不同的东西罢了 |
4
moonrailgun OP @matepi 我是想的是为了接收端能够及时感知到离线信息。我确实不是很了解业界标准。我研究一下
|
5
julyclyde 2023-09-18 15:11:38 +08:00
@moonrailgun 目标公网,push 方案倒确实是自然而然的选择
但问题是,被监控的这些目标,(正常情况下)一旦发布出去,根本都没有工程化的手段记录到底发出去多少份 一旦 push 目标的地址发生变化,想要把已经发出去的这些都更改升级,就成了无从下手的问题,总有改不尽的长尾 一开始就把这个矛盾激化,强制监控中心知道所有的被监控目标(并采取 pull 模式)可以有效的避免这个问题 我建议你解决一下“监控中心在公网”这个问题,把两边弄到同一个地址体系下 |
6
moonrailgun OP @julyclyde 了解。不过正如我前面所说,如果是比较严格的生产环境,比如 k8s 集群。我当然会选择 prometheus 全家桶。但是我目前的场景是一个轻量级的环境,我考虑的更多是如何让使用者能够方便使用。
其中 c 端启动服务/应用,s 端立马收到消息并展示是我认为比较易于使用的方式。 而 grafana 这样在 UI 中配置采样方式也需要对所有机器的 ip 都了解 这里的差异我认为并没有绝对的说 push 模式好还是 pull 模式更好。只能说场景不一样吧。 |
7
julyclyde 2023-09-18 15:22:13 +08:00 1
@moonrailgun 那你记得搞一下记录
建议别因为 go 只有一个文件,就放弃 rpm/deb 或者是这个 go 本身支持--version --dump-config 之类的参数,以便将来验尸 你说的 grafana 这段我没理解 |
8
Kinnice 2023-09-18 23:09:30 +08:00 via Android
websocket
|