Graphite を使用して、さまざまなサーバーからメトリックを収集したいと思います。デフォルトでは、Carbon はすべてのインターフェイスで 2003 をリッスンしますが、これは問題ありません。
理論的には誰でもそこにメトリック データを送信できます。これを防ぐ標準的な方法 (http ベース認証に類似) はありますか。それとも、物理インターフェイスの IP ベースの制限を変更する必要がありますか。
答え1
それは、Graphite ノードをどの程度「強化」したいかによって異なります (「Graphite」とは、carbon-relays、carbon-cache、ストレージ バックエンド、および場合によっては graphite-web/api の混合トポロジのことです)。
ネットワーク内のホストがわかっている場合すべきメトリックを Graphite (通常はリレー) に送信する場合は、明示的なホスト IP のリストまたは適用可能なポートの範囲のいずれかを期待するように Graphite ホスト ファイアウォール ルールを変更できます。または、ファイアウォールまたはルーターからエッジ ネットワークで同様のことを行うこともできます。質問ではトポロジがどのようになっているかの完全な範囲が示されていないため、これについてはアドバイスできません。
別の方法としては、AMQPサポートを使用して、ノードが認証されたユーザーとしてブローカーにメトリックを公開し、Graphiteホストでホストファイアウォールを変更して、メトリックが受信されるブローカーからのTCP 2003のみを受け入れるようにすることです。ここでの利点は、Graphiteノードがのみどのブローカー メトリックがそこから来るのかを知る必要があるため、ホストのファイアウォール ルールが大幅に簡素化されます。ノードが軽量サービスを通じてメトリックを公開すると、メトリックが (正当かどうかにかかわらず) Graphite ホストに到着するかどうかではなく、フローの最上部で「信頼」に関する懸念が処理されるため、セキュリティが少し向上します。RabbitMQ は OSS であり、管理プラグインを取り込むと、設定をあまりいじる必要がなく、簡単に起動して実行できます。その設定のほとんどは、操作に必要なポートを開くことです。
ただし、これにより、Graphite トポロジへの単純なメトリック パブリッシャーがタスクに対して少し複雑になり、メトリックが Graphite に到達する方法についての pub/sub モデルが確実に確立されます (ただし、転送中のメトリックが失われないようにするという優れた副次的な利点もあります)。また、運用上の理由から、セキュリティ保護が必要なホストがさらに 1 つ追加されます。
さらに進むと、ログ監視システムを実装して、carbon-relay の listener.log ファイルを監視することができます。このファイルは、受信および処理されたすべてのメトリックについて 1 行に書き込むためです。高レベルでは、そのログを監視して、期待するメトリックの例外を探します。たとえば、server.cpu.load メトリックがある場合、それらが処理されているのがわかるはずですが、foo.bar.value というメトリックは有効ではありません。このようなイベントへの応答として、無効な名前空間用に Whisper が作成した対応するディレクトリを消去するだけで済みます (Whisper をストレージとして使用している場合)。
Graphiteのカーボンリレーとカーボンキャッシュを強化することは良いことであり、賢明なことですが、忘れてはならないのは、誰がGraphite Web アプリまたは graphite-api にアクセスして、それらのメトリックを取得できます。