我想使用 graphite 收集来自不同服务器的指标。默认情况下，carbon 在所有接口上监听 2003，这对我来说没问题。
现在理论上任何人都可以向那里发送度量数据。有没有标准方法可以防止这种情况发生（类似于 http base auth ）或者我是否需要处理物理接口上基于 IP 的限制？
答案1
这取决于您想要多大程度上“强化”任何 Graphite 节点（“Graphite”是碳中继、碳缓存、存储后端以及潜在的 graphite-web/api 的混合拓扑）。
如果你知道你的网络中有哪些主机应该向 Graphite 发送指标（通常是中继），您可以修改 Graphite 主机防火墙规则，以便从主机 IP 的明确列表或适用端口的范围中进行选择。或者，您可以在边缘网络上从防火墙或路由器执行类似操作 - 我没有建议，因为您的问题没有提供您的拓扑的更全面范围。
另一种方法是使用 AMQP 支持，让您的节点以经过身份验证的用户身份将其指标发布到代理，然后让您的 Graphite 主机修改主机防火墙，以仅接受来自代理指标的 TCP 2003。这样做的好处是您的 Graphite 节点仅有的需要知道代理指标来自哪里，这大大简化了主机防火墙规则。让节点通过轻量级服务发布指标可以更好地保证安全，因为您所关心的“信任”问题在流程的顶部得到处理，而不是指标（无论合法与否）到达您的 Graphite 主机的可能性。RabbitMQ 是 OSS，如果您引入管理插件，启动和运行非常简单，无需过多地处理配置。它的大部分配置都是打开操作所需的端口。
但是，这使得简单的指标发布者到 Graphite 拓扑的任务变得稍微复杂一些，并牢固地建立了指标如何到达 Graphite 的发布/订阅模型（但确实带来了一个很好的附带好处，即允许传输中的指标不会丢失）。它还增加了另一个主机以在操作范围内进行保护。
更进一步，您可以实施日志监控系统来监视 carbon-relay 的 listener.log 文件，因为它将为收到和处理的每个指标写一行。在高层次上，您会观察该日志以查找您期望的指标的异常。例如，如果您有一个 server.cpu.load 指标，您希望看到它们得到处理，但发布的名为 foo.bar.value 的指标无效。作为对此类事件的响应，您可以简单地擦除 Whisper 为无效命名空间创建的相应目录（如果您使用 Whisper 进行存储）。
强化石墨的碳中继和碳缓存是明智之举，但别忘了，这同样令人担忧WHO可以访问您的 Graphite webapp 或 graphite-api 来获取这些指标。