2. NodeSeek
  3. 探针 Agent 同时上报多个 Server，是个不错的思路

探针 Agent 同时上报多个 Server，是个不错的思路

kevinhwang 2026-10-13 17:47 1

如果一个 Agent 能同时向多个 Server 上报，两台主控分别使用独立数据库，那么其中一台主控连同数据库一起故障，另一台仍能继续接收和展示监控数据，可以降低对单个主控可靠性的依赖。


目前了解到 NodeGet 已经支持，不确定还有哪些探针项目支持类似功能。不过我个人更喜欢 Go，主要是不懂 Rust，后续想自己修改功能或排查问题，Go 项目会更容易上手。NodeGet 的功能也比我的实际需求多一些，我更希望有一个轻量的方案。


当然，多端上报也有额外开销，配置维护、告警去重和历史数据同步都需要考虑。但如果主要需求是“一台主控挂了，另一台还能看”，感觉这个思路挺实用。


大家还知道哪些支持多 Server 上报的探针？最好是 Go 写的

最新回复 (9)
  • ningyuv 10-13 17:49
    1楼

    不如cf

  • astom 10-13 17:55
    2楼

    我这个可以，但是项目不可见了 ^-^

  • kevinhwang 楼主 10-13 17:58
    3楼

    @astom #2 我也是没精力（token）去搞探针了

  • astom 10-13 18:03
    4楼

    @kevinhwang #3 我还在找能 分布式 多主控的 探针，nodeget感觉有点麻烦 ^-^

  • kevinhwang 楼主 10-13 18:04
    5楼

    @astom #4 这个复杂了，感觉没必要。多server单纯是oneman有些机器性能很强，但是不稳定，可最大化压榨server的性能

  • UPSTREAM互联网服务 10-13 18:09
    6楼

    https://github.com/Ithildur/Ithiltir

  • kevinhwang 楼主 10-13 18:25
    7楼

    @UPSTREAM互联网服务 #6

    看起来可以，你是作者？


    可以满足你现在的核心需求：Go 编写，一个 Agent 向两套主控上报，其中一台主控连同数据库故障后，另一台仍能查看监控。 不过，它的主控部署依赖比 SQLite 探针多一些。


    我看了中文 README 和 Agent 源码，具体情况如下：































    你的要求 Ithiltir 的情况
    Go 编写，方便自己修改 主控和 Agent 都是 Go
    一个 Agent 上报多个 Server 支持配置多个上报目标，每轮并行发送
    一台主控＋数据库故障，另一台继续使用 两套主控使用独立数据库、提前同时接收数据，可以实现
    网页入口故障后自动切换 未查到现成的自动切换方案，可分别访问两套面板
    数据库、历史和配置自动同步 这需要另外解决，多目标上报本身不提供复制能力

    依据：主控说明 (https://github.com/Ithildur/Ithiltir/blob/main/README_CN.md)、Agent 上报文档 (https://github.com/Ithildur/Ithiltir-node/blob/main/docs/reporting_apis_CN.md)。


    部署时，在两台机器上分别安装 Dash 和数据库，在两边分别创建节点，再把两个上报目标加入同一个 Agent。README 中的“单实例”限制，是指不能让多个 Dash 进程同时写同一套状态，不妨碍这种独立部署方式。


    有两点比较影响你的选择：



    • 主控依赖较多。 需要 PostgreSQL＋TimescaleDB，默认还使用 Redis；Redis 可以通过 --no-redis 省去。因此，Go 技术栈符合你的偏好，但部署维护不算特别简单。README (https://github.com/Ithildur/Ithiltir/blob/main/README_CN.md)

    • 慢主控可能影响上报频率。 源码确实并行发送，但每轮会等待所有目标请求结束，HTTP 请求超时设为 10 秒。如果 A 一直没有响应，B 当轮仍能收到数据，但下一轮上报可能被拖慢。上报实现 (https://github.com/Ithildur/Ithiltir-node/blob/main/internal/push/push.go)


    按你“一台挂了，另一台还能看”的目标，它值得试用。 建议重点验证主控无响应时另一端的上报间隔，以及恢复后的历史缺口。本次结论来自文档和源码核查，尚未做双机故障实测。

  • UPSTREAM互联网服务 10-13 18:29
    8楼

    @kevinhwang #7

    不是，作者朋友。

  • kevinhwang 楼主 10-13 18:33
    9楼

    @UPSTREAM互联网服务 #8 starred，单从文档上看就专业，值得研究

* 帖子来源NodeSeek
附近帖子
返回
飞读
随机推荐