在任何情况下，这似乎都是无用的微优化，在出现实际实际问题之前您不应该担心，这可能永远不会出现。

但是，纯粹从学术上讲，您应该将 snmp 轮询器放在它正在轮询的设备附近，因为它是受 RTT 约束的请求/响应协议。轮询器可以聚合轮询的数据，并使用 TCP 和 windows 将大量数据快速发送到 DB。

FWIW 这是一个很好的问题，我不能不同意 @ytti 的观点，因为它有很大的潜力让理论/学术界陷入困境。

从实际的角度来看，将轮询器靠近被轮询的对象是您想要做的。我不是分布式系统专家/SDE，但我想任何设计为分布式的 NMS 都应该已经具有将数据库插入时间戳与实际轮询 SNMP 数据及其自己的时间戳分开的功能。这仍然不是一个容易解决的问题，但正如 ytti 已经说过的（我同意），执行数据库插入不应优先于从轮询收集的数据。那些被包裹在 TCP 中以获得更好的数据完整性保护的奢侈。通过实际的 SNMP 轮询和陷阱，您需要“尽力而为”两次来应对 - 第一个显然是 UDP，第二个是进程管理/“数据完整性” （即计数器准确等）在您正在投票的盒子上。有时，一个盒子开始卡住并通过 SNMP 返回数字让其他事情退居二线。

使用的轮询器数量应基于被轮询的节点数量和轮询频率。此外，一些供应商不支持远离数据库的轮询器。Solarwinds 有此限制。

离轮询设备更近也意味着由于较低的延迟，您可以获得更高的轮询频率。我发现当我试图以 5 或 10 秒的间隔在我们的跨大西洋线路上轮询设备时，走桌子需要很长时间。