私は長年複数のサーバーでmuninを使用して大きな成功を収めてきましたが、100を超えるmunin-nodeでクライアントに負荷がかかると、処理がタイムアウトします。
cronジョブとクライアントプロセスの数にいくつかのスケーリングの変更を加え、実行中のプラグインの数などを減らしましたが、よりスケーラブルなアーキテクチャを持つ代替案を探すことにしました。
提案や経験があれば歓迎します。私は基本的に、キャパシティプランニングに使用できるサーバーメトリックと、リソース使用状況の診断に関心があります。（アラート用のnagiosがあります）
回答:
2つの問題があるようです
過去にMuninを使用したことがありますが、現在はcollectdを使用しています。collectdの作者は、これらの問題の解決に多くの考えと努力を注いできました。データをRRDファイルに書き込むための適切に設計されたシステムがあり、データを失うことなく、最新のグラフを生成できます。RRDCacheDのサポートもあります。デーモンと公式プラグインはCで記述されているため、メモリやCPU時間をほとんど使用しません。私のクライアントシステムでは、RAMは2MB未満で、毎分CPU時間は約1/4秒です。私の監視サーバーでは、20MBのRAMと毎分2/3秒のCPU時間を使用しています。すべてのメトリックが収集され、監視サーバーに送信されるのは、muninのように数分間隔ではなく、10秒ごとであることに注意してください。
Muninやその他のRRDToolフロントエンド（CactiやGangliaなど）は優れたツールですが、I / Oに関する既知の問題があり、ノードの数百を監視する場合のスケーリングは困難です。
ただし、このI / Oボトルネックに対処するためのいくつかの手法があります。これらの手法の1つは、書き込みを多数のディスクに分散して、各ディスクのI / Oを削減することです。一方、多くのシステム管理者はtmpfsファイルシステムを使用してこの問題に対処しています。RRDCachedもこれに対処するための最近の優れたオプションです。このスライドをご覧になることをお勧めします。
私はMuninにはそれほど詳しくありませんが、CactiにはBoostプラグインがあります。このプラグインは、データをメモリにキャッシュし、個々の書き込みではなく、ディスクに対して大量のオンデマンド更新を実行するため、I / Oが削減されます。ムニンもこのようなものを持っていると確信しています。
余裕があれば、SSDディスクも良い選択肢です。
最後に重要なことですが、Reconnoiterを確認することもできます。Recconoiterは、新しい障害検出およびグラフ化/傾向分析ツールです。ほとんどのトレンドツールとは異なり、ReconnoiterはRRDToolベースではなく、この特定の問題を解決しようとします。私は本番環境でReconnoiterを使用していませんが、いくつかのテストを行いましたが、まだ少し「グリーン」であるにもかかわらず、特にそのスケーラビリティに関して、非常に有望に見えます。
お役に立てれば！
マルコ・ラモスはいくつかの確かなアドバイスをします。いくつかの説明を追加したいと思います。ただし、muninの大きな問題は、5分の収集スケジュールが固定されていることです。5分以内にすべてのノードが結果を返さない場合、ドロップアウトが発生し始めます。これがムニンの最大の問題です。
Gangliaのような他のrrdtoolベースのツールは、muninが行うのと同じ順番ですべてのデータソースをポーリングしないため、この同じ5分の更新ウィンドウにロックされません。
Gangliaは一般的には適切にスケーリングされているように見えるので（Gangliaを大規模にインストールする場合は、マルチキャストデータ収集をオフにする必要はありますが）、確認することをお勧めします。rrdtoolがチョークポイントであることを心配する必要がなくなる前に、神経節をかなり長い道のりで移動できると思います。その時点で、SSDドライブの使用など、マルコが提案するようなことを行うことができます。
MuninをGangliaと交換しています。Muninはサーバーを強制終了するので、Gangliaを試してみて、どのようにスケールするかを確認します。