硬化石墨（碳）
我想使用石墨從不同的伺服器收集指標。預設情況下，carbon 在所有介面上監聽 2003，這對我來說很好。
現在理論上任何人都可以在那裡發送度量數據。是否有防止這種情況發生的標準方法（類似於 http base auth ）或者我是否需要弄亂物理介面上基於 IP 的限制？
這取決於您想要“硬化”任何 Graphite 節點的程度（“Graphite”是碳中繼、碳記憶體、儲存後端和潛在的石墨網路/api 的任何混合拓撲）。
如果您知道網路中的哪些主機應該將指標發送到 Graphite（通常是中繼），您可以修改 Graphite 主機防火牆規則，以期望來自主機 IP 的明確列表或適用埠的範圍。或者您可以通過防火牆或路由器在邊緣網路上做類似的事情 - 我沒有任何建議，因為您的問題並沒有提供更全面的拓撲結構。
另一種方法是使用 AMQP 支持，讓您的節點作為經過身份驗證的使用者將其指標發佈到代理，然後讓您的 Graphite 主機修改主機防火牆以僅接受來自代理指標的 TCP 2003 正在接收。這裡的好處是您的石墨節點僅需要知道將來自哪些代理指標，這大大簡化了任何主機防火牆規則。讓節點通過輕量級服務發布指標可以更好地保護事情，因為您所關注的“信任”問題在流程的頂部得到處理，而不是指標的可能性（合法與否）到達您的 Graphite 主機（s ）。RabbitMQ 是 OSS，如果您引入管理外掛，則無需過多配置配置即可輕鬆啟動和執行。它的大部分配置都是打開必要的埠進行操作。
然而，這使得向 Graphite 拓撲的簡單指標發布者的任務更加複雜，並為您的指標如何到達 Graphite 建立了一個發布/訂閱模型（但確實帶來了一個很好的附帶好處，即允許傳輸中的指標不被可能失去）。它還增加了另一個主機以確保在操作範圍內的安全。
更進一步，您可以實現一個日誌監控系統來監視 carbon-relay 的 listener.log 文件，因為它會為接收和處理的每個指標寫入一行。在較高級別上，您會查看該日誌以查找您期望的指標的異常。就像您有一個 server.cpu.load 指標一樣，您希望看到這些指標得到處理，但發布的稱為 foo.bar.value 的指標無效。作為對此類事件的響應，您可以簡單地擦除 Whisper 為無效命名空間創建的相應目錄（如果您使用 Whisper 進行儲存）。
強化 Graphite 的 carbon-relay 和 carbon-cache 很好，而且是一件很聰明的事情，但不要忘記誰可以訪問您的 Graphite webapp 或 graphite-api 以獲取這些指標。