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