各 Web サーバーで statsd のインスタンスが実行されていて、それらを collectrd などにプッシュするという考えはありますか?
メトリクスの呼び出しが udp であるため非常に軽いことは理解していますが、これは、ページごとに statsd に対して 3 ～ 5 回の呼び出しを行っている可能性があることを意味します。
または、udp は非常に高速であるため、1 秒あたり数千回の呼び出しを行うことができますが、それは発火して忘れるタイプの要求であるため、問題にはなりません。
質問する
342 次
3 に答える
1
一般に、管理とセットアップのオーバーヘッドが少ないため、単一のインスタンスから始めることをお勧めします。各 Web サーバーで StatsD インスタンスを実行している場合は、Graphite 側で何もオーバーライドしないように、ホスト名とメトリックを送信する必要があります。また、メトリクスを理解するためにグラファイト/ダッシュボード側でさらに多くの作業を行う必要があります。すべてのホストが 1 つの StatsD インスタンスに送信するわけではない設定では、すべてのホストを合計してすべてのログイン カウンターを取得する必要があります。これですべてが不可能になるわけではありませんが、始めるのはより複雑になります。そのため、単一のボックスで得られるパフォーマンスをすぐに超えてしまうかどうかわからない場合は、単一のインスタンスから始める方が簡単だと思います.
于 2013-10-24T22:02:17.557 に答える
0
各 Web サーバーで statsd のインスタンスが実行されていて、それらを collectrd などにプッシュするという考えはありますか?
Statsd は Collectd に代わるものです。LAN 経由で 1 つの statsd インスタンスを作成し、すべての「ページ」からメトリックを送信することができます。次の論理的なステップは、これらの指標を視覚化することです。ここでグラファイトを思い浮かべるかもしれません。
メトリクスの呼び出しが udp であるため非常に軽いことは理解していますが、これは、ページごとに statsd に対して 3 ～ 5 回の呼び出しを行っている可能性があることを意味します。
1 分あたり 1 つの statsd に対して 10,000 回の呼び出しを行っています。問題は多数ある可能性があります。サーバーが CPU、メモリ、ネットワーク、または IO バウンドになる可能性があります。はい、UDP は TCP よりもはるかに軽量です。スケールは気にしないでください。今のところ、そこにはたくさんの滑走路があります。
複数の statsd インスタンスを持つ:
スケーラビリティの観点からでない限り、複数の statsd クライアントを持つことは非常に悪い考えです。後で、構成を変更すると頭痛の種になります。n statsd のどれが正しく構成されていないかをデバッグすることも困難です。したがって、「軽量」のオーバーヘッドは、保守不可能なアーキテクチャへの招待です。堅牢性に関する限り、statsd による障害に直面することなく、現在のニーズよりもはるかに多くのことを行っている人がいます。私が言ったように、私は 1 分間に 10K のメトリクスを実行しています。
于 2013-10-23T07:10:26.357 に答える