ネットワーク上のサービスにNagiosを実装しましたが、うまく機能しています。通知は素晴らしく、幅広い構成オプションは非常に便利です。ここまでは、ファイルを直接変更することにより、すべての構成を手作業で行ってきました。
他の一部の管理者にこれを少し公開し始めたので、エラーの可能性を減らすGUIを実装したいと思います。私はいくつかの異なるGUIプロジェクトをチェックアウトしましたが、これまでのところNagiosQLとNConfがこれまでのトップ候補であるようです。
これら2つの間に、またはおそらく他の考慮すべき推奨事項はありますか？インストールと使用のストーリー、「落とし穴」、決定に役立つヒントについてはどうですか。
回答:
私たちは同じ決定の前にあり、現在nconfが私たちのお気に入りです。大きな分散環境向けに設計されたbeeingの大きな利点があります。
さまざまなnagiosサーバーの設定ファイルを自動的に作成します。1つはある種のコレクターであり、もう1つはモニターであり、コレッターからパッシブチェックのみを受け取ります。
マイナス面として、現在、nconfではエスカレーションを処理できません！
http://sourceforge.net/apps/mediawiki/nconf/index.php?title=Main_Page
職場ではOpsViewを使用しています。これはWebベースのGUIであり、クラスタリングを介してNagiosサービスのスケールアップなどを処理します。新しいホスト、新しいサービスをWeb経由で追加し、停止を確認できます。サーバーが定期的に必要とするCPUの量などを知りたい場合は、サービスの履歴ビューも記録します。
ただし、Web経由でNagiosスクリプトを追加することはできません。
Nagiosを管理するためにOpsviewで良い経験をしました。ただし、Nagiosの「フロントエンド」と考えるのは間違いです。代わりに、Nagiosを基礎となるエンジンとして使用する監視システムと考えてください。
Nagiosの設定はDBに保存され、Nagiosの設定ファイルはプログラムで生成されるため、たとえば、Nagiosの設定をソース管理に保存したり、独自のスクリプトを使用して生成したりする場合は、それらの手順を放棄します。
代わりに、次のものが含まれます。
-スティーブ
私が不満を持っているのは、設定フロントエンドが、後で必要になったときに手で編集するのが直観的ではない、本当にゴミのような設定ファイルを作成することがあるということです。これは、マシンで生成された構成ファイルを使用するシステムでの一種の問題であり、直感的ではない場合でもかなりよく理解されています。
Nagiosでの私の通常のアプローチは、テンプレート機能と継承機能を広範囲に使用し、構成を多数のファイルに分割することでした。
ここでは、主な開発者のリーダーシップスキルが不足しているため、Nagiosコミュニティが最近分岐したことに注意する価値があります。Icingaはおそらく新しいクールですが、私はまだ試していません。
UbuntuGeekは本日、まさにこのテーマに関する記事を投稿しました。Xerxesによるhttp://www.ducea.comの回答と同じ行に沿っていますが、新しいプロジェクトのいくつかが追加されたもう少し新しい記事です。とにかく、いくつかのNagios config guiをカバーするまともな概要良い出発点になるはずです。
http://www.ubuntugeek.com/nagios-configuration-tools-web-frontends-or-gui.html
編集する
新しい公式 nagios交換も本日オープンしました。クイックリファレンス用の構成セクションへのリンクは次のとおりです。
あなたと同じ理由で、フロントエンドを実装する必要がありました。個人的には、それらはすべて少し不器用で、構成ファイルを手で管理することを好みます（手間がかかりません）。しかし、あなたはあまり選択肢がないようです。
私たちは君主を使用しますが、私はそれがそれほど好きではありません。
私も何も試していませんが、ここから始めることができます...
CentreonをNagiosフロントエンドとしてお勧めします。設定プロセスを簡単にするだけでなく、Nagiosチェックによって返されるステータスデータの表示やパフォーマンスデータの収集にも使用でき、見栄えの良いグラフに変換できます。したがって、ある意味で、サボテンも廃止されます。