Open Monitoring Distro（OMD）を使用して新しいクラウドサーバーを自動的に監視しますか？

Question

私は、Nagios、Check_mk、およびOMDパッケージの一部としてインストールされている他のいくつかの非常に便利なツールを使用して頭を悩ませてきました。

WATOは、check_mkエージェントが手動でインストールされた後、GUIを介してすべての静的WindowsおよびLinuxベースのサーバーを管理する場合に特に役立ちます。

この監視プロセス全体を自動化するための最良の方法は何ですか？またはそれができるとしても？

シェフのレシピを使用して、定期的に新しいサーバーをプロビジョニングし、他のサーバーを頻繁に停止します。 Nagios/Check_mkを引き続き使用する場合は、インフラストラクチャを追跡および監視するための管理作業を最小限に抑えることが不可欠です。

ご協力いただき誠にありがとうございます。スティーブ

Florian Heigl · Accepted Answer

高レベル、2つの方法があります：

Chefに有効なCheck_MK構成ファイルを書き込ませ（これはすでに実行されています）、WATO自動化を介してインベントリとリロードをトリガーします。これはおそらくより透明です。
Check_MKにCMDB（プロのセットアップを実行する場合は1つあります...）またはChef構成からホストを読み取らせます。これは実現可能です。Check_MK構成では、基本的にPythonで許可されるものなら何でも可能です。したがって、LDAP、一部のAPI、Chef構成、またはフラットファイルからデータを読み取ることができます。私にとっては、よりクリーンなアプローチです。より直接的な「データ」インターフェースを備えているためです。

長い目で見れば、最初の方法はWATOに向いているので、とにかくうまくいくと思います。私はまだ2番目のものを選び、EC2vmリストなどにフックします。

ハイブリッドが可能です。つまり、一部のデーモンはVMの作成などのイベントをリッスンし、構成をWATO読み取り専用フォルダーに書き込みます。

注：そのようなデータソースをサニティチェックしないのは非常に愚かなことです。一部のInfrastructureas Codeナットケースが（infrastructure）バグを追加し、ChefからVMを100％削除するという理由だけで、それらをすぐに監視から削除するべきではありません。

littleが帯域外にあることを確認してください。

動的Check_MKインターフェースに関する2010年風のドキュメントは、次の場所にあります。 https://geni-orca.renci.org/trac/wiki/OMDeventhandlers

それは本当に古いですが、基本的な考え方をうまくレイアウトしています。

Config-mgmt --- to ---- Check_MKインターフェイスの最初の概念実証を行いました。私が望むほど良くはありませんが、Pythonを書く速度/スキルによって制限されています。 :)