私は300台のサーバーの監視を設定し、さまざまなことを行うという任務を負っています。 NagiosやMuninなど、さまざまなツールを検討してきました。そのため、最初に監視を実現する方法についてはかなり良いアイデアが得られました。
私が疑問に思っているのは、サーバーについてあまり知らない場合に、適切なデフォルトとして監視するために通常どのようなメトリックが使用されるのかということです。そして、警告に関する限り、「正しいデフォルト」とは何ですか?
私の計画は、さまざまなシステムの役割を計画する一方で、適切なデフォルトを使用して監視スキームを展開することです。これにはしばらく時間がかかると思います。
この質問は、別の方法で行うこともできます。
監視アプライアンスを設計している場合、デフォルトのLinux監視テンプレートには何を含める必要がありますか?
問題を示す通常のメトリックには、CPU使用率、メモリ使用率、負荷平均、およびディスク使用率が含まれます。メールサーバーの場合、メールキューのサイズは重要な指標です。 Webサーバーの場合、ビジー状態のサーバーの数は重要な指標です。ネットワークスループットが高すぎると、問題も発生します。時間をチェックする必要があるプロセスがある場合NTPは、クロックの同期を維持するための重要なツールになる可能性があります。
私が使用した標準の警告レベルには、(警告、クリティカル)が含まれます。いくつかの要因に基づいて値を調整することをお勧めします。値を大きくするとアラートの数が減り、値を小さくすると問題の発生に対応する時間が長くなります。これは、テンプレートの適切な開始点になる可能性があります。
Muninは、これらの統計やその他の統計を収集するのに適しています。また、しきい値を超えたときにアラームをトリガーする機能もあります。その警告機能はNagiosのものほど良くありません。履歴データの収集と表示により、現在の値が過去の値と大幅に異なるかどうかを確認できるようになります。セットアップは簡単で、警告を生成せずに実行できます。主な問題は、キャプチャされるデータの量と、情報を収集する固定頻度です。オンデマンドでグラフを生成することもできます。 Muninは、システムに問題が発生したときにsar
を使用してチェックする統計の多くを提供します。概要ページは、考えられる問題を特定するのに役立ちます。
Nagiosはアラートに非常に優れていますが、現在の値との比較に適した方法で履歴データを収集することは歴史的にあまり得意ではありませんでした。これは変化しているようで、新しいリリースはこのデータの収集にはるかに優れています。問題が発生したときに警告を生成したり、アラートが生成されない停止をスケジュールしたりする場合に適しています。 Nagiosは、サービスがダウンしたときにアラートを出すのに非常に優れています。これは、重要なサーバーやサービスに特に適しています。
私があなたなら、いくつかの理由でNagiosを使用します(ここに2つあります):
3番目の理由は、Nagiosにはデフォルトの監視スキーマがすでに付属しているため、全体的に監視したいほとんどのことを処理するため、最初に独自の監視「メトリック」を設定する必要がありません。
ただし、独自の指標を設定する場合は、サーバーの負荷、ディスクの空き容量、メモリの空き容量、スワップ領域の使用状況など、すべてのサーバーを監視し、ICMPpingを使用して外部監視も行います...
一般に、まず、サーバーの負荷、CPU使用率、メモリ、ディスクスペース、I/Oおよびネットワークトラフィックを監視します。次に、サーバーのタイプ(Web /メール/データベース/ NIS)に応じて、アプリケーション固有の統計情報と、インターフェイスエラー、待機時間、応答時間などの他の重要事項を監視します。
最初に、CPUやメモリなどのシステムリソースを監視できます。
次に、サービス固有のリソースを監視できます。たとえば、応答時間とアクティブな接続の数を監視できます。
デフォルトの監視値については、予想される使用パターンと、サーバーがビジーであると予想される量に関連している必要があると思います。