グラファイト - statsd - collectd スタックを使用して分散システムを監視することを研究しています。
コンポーネント (graphite-web、carbon、whisper、statsd、collectd、および grafana) をローカル インスタンスでテストしました。
ただし、分散システムでこれらのコンポーネントをどのように分散する必要があるかについて混乱しています。- すべてのワーカー ノード: statsd と collectd がリモート モニター ノードの Carbon バックエンドにデータを送信します。
このスキームは正しいですか？許容可能なネットワーク使用量 (tcp/udp、1 秒あたりのパケット数など) を取得するには、statsd と collectd を何を構成する必要がありますか?
ワークロードが比較的軽いと仮定すると、graphite-web、grafana、および carbon (それ自体がウィスパー データベースを管理する) を管理するノードがあれば問題ありません。
次に、statsd 用に別のノードが必要です。各マシン/アプリケーションには、メトリックをこの statsd ノードに送信する statsd クライアント コードが必要です。この statsd ノードは、これらのメトリクスをカーボン ノードに転送する必要があります。
単一のノードに負荷をかける大規模なワークロードの場合は、垂直方向にスケーリングする (carbons/statsd インスタンスをホストするためのより強力なノードを取得する) か、これらのサービスのクラスター化を開始する必要があります。
Carbon クラスターは、クラスターへのメトリクスの転送を管理する何らかのリレーを使用する傾向があります (通常はコンシステント ハッシュを使用します)。同様の設定を使用して、メトリックを statsd サーバーのクラスターに一貫してハッシュすることができます。