ここで私の事実をまっすぐにしようとしています。
Sens (ブロック上のかなり新しい子供)は、次の両方の代わりになることを意味しますか?:
これらの各プログラムの機能を要約してみましょう-
Nagiosは、プログラムをローカルで実行し、リモートシステムでプログラムを実行し(sshまたはnrpeを介して)、独立したプログラムからデータを受信する(nscaを介して)いくつかの組み合わせによってデータを収集します。 nagiosが収集するデータは、通常、状態ok、warning、critical、unknownの値0、1、2、または3です(ただし、一部のプラグインはパフォーマンスメトリックの送信をサポートしています)。 Nagiosはアラートを送信することでデータに作用します。特定のアイテムのアラートを特定の時間に受信するユーザー、アラートの確認、アラートのエスカレーションなどについては、かなりの構成可能性があります。
Collectedは、データ自体を読み取るプラグイン(Apacheステータス、CPU使用率など)を介してシステムとアプリケーションのメトリックを収集するか、他のプロセス(statsdクライアント、collectdの他のインスタンスなど)からデータを受信します。 Collectedは、必要に応じてデータを集約またはフィルタリングできます。次に、それをディスクに(csvまたはrrdファイルとして)書き出すか、いくつかのプロトコル(collectd、graphite、http、mongo、redis、riemann、amqp)を介してネットワーク経由で送信できます。アラートを送信する機能がありますが、それはかなり骨の折れる作業です。
Sensuサーバーは、サーバーで構成されたコマンドを実行するようにsensuクライアントに指示する(チェック)か、クライアントで構成されたコマンドからデータを受信する(スタンドアロンチェック)ことを組み合わせてデータを収集します。データは、nagiosが使用するような状態またはメトリックにすることができます。 Sensuは、ミューテーターを介して受信するデータを変更できます。次に、データをハンドラーに渡します。ハンドラーは、アラートの送信やデータの送信(グラファイトなど)などを実行できます。 Sensuには、オンザフライ構成用の豊富なAPIがあります。
Nagiosとsensuは同等のソフトウェアですが、collectdはそうではありません。 collectdを使用してncsa経由でnagiosデータをフィードしたり、amqp経由でsensuデータをフィードしたりすることを想像できますが、これらのいずれかを行うには、collectd用の新しいプラグインを作成する必要があります。
Nagiosの代わりにSensuを使用することは可能だと思います(チェックとアクションをサポートしています)。
CollectDを置き換える限り、おそらく。実際に取り組んでいる人に聞いてみないとわかりません。
私が最初に考えたのは、「うーん、リリース0.9だけです。本当に本番環境で使用する準備ができているのだろうか」ということでした。