我想使用石墨從不同的伺服器收集指標。預設情況下，carbon 在所有介面上監聽 2003，這對我來說沒問題。
現在理論上任何人都可以在那裡發送指標數據。是否有一種標準方法可以防止這種情況發生（類似於 http base auth ），或者我是否需要擾亂實體介面上基於 IP 的限制？
答案1
這取決於您想要「強化」任何 Graphite 節點的程度（「Graphite」是碳中繼、碳緩存、儲存後端和潛在的石墨網路/API 的任何混合拓撲）。
如果您知道網路中有哪些主機應該將指標傳送至 Graphite（通常是中繼）時，您可以修改 Graphite 主機防火牆規則，以期望來自主機 IP 的明確清單或適用連接埠的範圍。或者您可以在防火牆或路由器的邊緣網路上執行類似的操作 - 我沒有任何建議，因為您的問題沒有提供更全面的拓撲結構。
另一種方法是使用 AMQP 支援來讓您的節點以經過驗證的使用者身分將其指標發佈到代理，然後讓您的 Graphite 主機修改主機防火牆以僅接受來自代理指標的 TCP 2003。這裡的好處是你的石墨節點僅有的需要知道代理指標將來自哪些，這大大簡化了任何主機防火牆規則。讓節點透過輕量級服務發布指標可以更好地保護事情，因為您所關心的「信任」問題是在流程的頂部處理的，而不是指標的偶然性（合法與否）到達您的 Graphite 主機） 。 RabbitMQ 是 OSS，如果您引入管理插件，則啟動和運行非常簡單，無需進行太多配置。它的大部分配置都是打開操作所需的連接埠。
然而，這使得Graphite 拓撲的簡單指標發布者的任務變得更加複雜，並為您的指標如何到達Graphite 牢固地建立了一個發布/訂閱模型（但確實帶來了一個很好的副作用，即允許傳輸中的指標不被可能會遺失）。它還添加了另一個主機以確保操作合理。
為了更進一步，您可以實作一個日誌監控系統來監視carbon-relay的listener.log文件，因為它會為接收和處理的每個指標寫入一行。在較高層級上，您將觀察該日誌以查找您期望的指標的異常情況。就像如果您有 server.cpu.load 指標一樣，您希望看到這些指標得到處理，但發布的名為 foo.bar.value 的指標無效。作為對此類事件的回應，您可以簡單地擦除 Whisper 為無效命名空間建立的相應目錄（如果您使用 Whisper 進行儲存）。
硬化石墨的碳繼電器和碳緩存很好而且是明智之舉，但不要忘記它同樣令人擔憂世界衛生組織可以存取您的 Graphite Web 應用程式或 Graphite-api 來取得這些指標。