技术方案求推荐，简单上报服务器信息到 node 服务

[moonrailgun]

上报应用初步选型是 go 语言，因为编译出来才一个文件方便部署。

但是对于如何上报信息有没有比较成熟的长连接方案。

本来是想要用 socketio 的。但是找了一圈发现没有成熟的 go socketio client 实现方案。

各位 v2 大佬帮忙推荐一下还有没有其他的方案？不想写最底层的 tcp 连接

[julyclyde]

重复发明轮子
用 prometheus 配套的 exporter 就行了

另外，别用“上报”，要用 pull 模式

[matepi]

如果上报指的是上报监控类信息的话，为啥要选择长连接方案？

业界标准上对于上报非关键信息的话，短连接 UDP 已经是标准做法了吧。突破现有标准做法的是有什么特殊需求目的、和环境特异性么？

[moonrailgun]

@julyclyde 上报的原因是可能需要把内网机器的信息上报到公网。用 pull 模式的好处是？

不用 prometheus 的原因就是不想一系列使用 prometheus + grafana + exporter 全家桶. 不同场景用不同的东西罢了

[moonrailgun]

@matepi 我是想的是为了接收端能够及时感知到离线信息。我确实不是很了解业界标准。我研究一下

[julyclyde]

@moonrailgun 目标公网，push 方案倒确实是自然而然的选择
但问题是，被监控的这些目标，（正常情况下）一旦发布出去，根本都没有工程化的手段记录到底发出去多少份
一旦 push 目标的地址发生变化，想要把已经发出去的这些都更改升级，就成了无从下手的问题，总有改不尽的长尾

一开始就把这个矛盾激化，强制监控中心知道所有的被监控目标（并采取 pull 模式）可以有效的避免这个问题

我建议你解决一下“监控中心在公网”这个问题，把两边弄到同一个地址体系下

[moonrailgun]

@julyclyde 了解。不过正如我前面所说，如果是比较严格的生产环境，比如 k8s 集群。我当然会选择 prometheus 全家桶。但是我目前的场景是一个轻量级的环境，我考虑的更多是如何让使用者能够方便使用。

其中 c 端启动服务/应用，s 端立马收到消息并展示是我认为比较易于使用的方式。
而 grafana 这样在 UI 中配置采样方式也需要对所有机器的 ip 都了解

这里的差异我认为并没有绝对的说 push 模式好还是 pull 模式更好。只能说场景不一样吧。

[julyclyde]

@moonrailgun 那你记得搞一下记录
建议别因为 go 只有一个文件，就放弃 rpm/deb
或者是这个 go 本身支持--version --dump-config 之类的参数，以便将来验尸

你说的 grafana 这段我没理解

[Kinnice]

websocket