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