アラートハンドラー

監視システムはイベントに介入すべきではないことは当然のことであると考えられます。 そして、それをそのままにしておくのがおそらく良い考えでしょう。

しかし、問題を確実に特定できるシステムが、自動的に機能すれば、その問題を修正することも可能であるというのは、確かに魅力的な考えです。

いくつかの適切な例は容易に想像できます：

これを容認できるのであれば、監視について別の考え方が必要になります。 単に監視するだけの、運用には「必要のない」システムから、段階的なプロセスを経て、監視はデータセンターに欠かせない器官へと変化していきます。

しかし、監視は、問題を発見した場合に自動的に問題を修正するだけではありません。 障害発生時に追加の診断データを収集することも、非常に有用であり、かつ無害です。 アラートハンドラーを起点として活用できる問題は、他にも数多くあるでしょう。

アラートハンドラーは、ご自身で作成するスクリプトで、問題が発生した場合、より正確にはホストまたはサービスのステータスが変化した場合に、Checkmk によって実行されます。 アラートハンドラーは通知とよく似ており、設定も同様ですが、いくつかの重要な違いがあります。

アラートハンドラーは通知とよく似ており、設定も同様ですが、 いくつかの重要な違いがあります。

アラートハンドラーは「非常に低レベル」であるとも言えます。 ホストまたはサービスのステータスが変更されると、設定されたアラートハンドラーが即座にアクティブになります。 このようにして、アラートハンドラーは、実際のアラートが生成される前に、修復を正常に実行することさえ可能です。

Checkmk では、いつものように、ルールを使用して、特定のハンドラーを実行する条件を定義することができます。 その方法およびアラートハンドラーに関するその他の情報については、この記事をご覧ください。

Checkmk Rawユーザー向けのヒント： 監視によってアクションを自動的に実行することもできます。 このためには、Nagios の「イベントハンドラ」を使用します。~/etc/nagios/conf.d/ で、Nagios 構文の手動設定ファイルを使用して設定してください。 イベントハンドラについては、詳細なドキュメントがあります。 情報はGoogle で簡単に見つけることができます。

アラートハンドラーは、Checkmk サーバーで実行されるスクリプトです。 これらは、~/local/share/check_mk/alert_handlers/ ディレクトリに保存する必要があり、Linux でサポートされている言語（BASH、Python、Perl など）で記述することができます。chmod +x でスクリプトを実行可能にすることを忘れないでください。

スクリプトの 2 行目にコメント（# ハッシュ）を挿入すると、そのコメントがルールの選択リストにスクリプト名として表示されます。

通知と同様に、スクリプトはホストまたはサービスに関するすべての情報を環境変数として取得します。これらの変数はすべて、ALERT_ というプレフィックスで始まります。

スクリプトにどの環境変数が表示されるかを正確にテストするには、次のアラートハンドラーを使用してテストしてください。

ハンドラーの有効化は、Setup > Events > Alert handlers を使用して行います。

以下の手順に従ってください：

アラートハンドラーを選択するフォームに直接アクセスでき、スクリプトの 2 行目に記録されるタイトルが表示されます。 さらに、テキストフィールドに引数を入力して追加することもできます。 これらは、スクリプトのコマンドライン引数として解釈されます。 シェルでは、$1 、$2 などでアクセスできます。

重要: ルールを保存すると、アラートハンドラーはすぐにアクティブになり、ホストまたはサービスのステータスが変更されるたびに実行されます。

テストするには、Fake check results をCRIT に手動で設定します。 これで、変数を含むファイルが作成されます。 その最初の 20 行は次のとおりです。

アラートハンドラーの実行（または非実行）に関するログファイルは、~/var/log/alerts.log に保存されます。 ハンドラーdebug の実行に関するセクションは、 ホストmyserver123のサービスFilesystem / について、 次のように表示されます。

いくつかの追加の役立つヒント:

アラートハンドラーは、SSH またはその他のプロトコルを使用して、影響を受けたマシンにリモートでログインし、そこでスクリプト制御のアクションを実行するために頻繁に使用されます。 このマシンは問題が発生しているため、接続に時間がかかる、あるいはタイムアウトになる可能性も排除できません。

監視が停止したり、その間に他のアラートハンドラーが停止したりすることがないように、アラートハンドラーは原則として非同期で実行されます。 この機能は、補助プロセスであるアラートヘルパーが担当し、CMC によって起動されます。 オーバーヘッドを削減するため、これは、少なくとも 1 つのアラートハンドラールールが作成されている場合にのみ発生します。cmc.log に、次の行が表示されます。

ホストまたはサービスの状態が変化するたびに、アラートヘルパーは CMC から、イベントに関連するすべての情報を含む通知を受け取ります。 その後、すべてのアラートルールを評価し、ハンドラーを起動すべきかどうかを判断します。 起動すべき場合、適切なスクリプトが起動され、外部プロセスとしてバックグラウンドで実行されます。

CMC を停止すると (omd stop 、または監視サーバーをシャットダウンするなど)、実行中のすべてのアラートヘルパーが中止されます。 これらは後で繰り返されることはありません。なぜなら、「後で」がいつになるかは誰にもわからないからです。 サービスを再起動するなどすると、有益というよりもむしろ有害になる可能性があります。

エラー状況において、あまりにも多くのプロセスが起動されるのを防ぐため、アラートハンドラーの実行中は 60 秒（設定可能）のタイムアウトが有効になります。 この時間が経過すると、ハンドラーは停止します。 具体的には、タイムアウトが終了すると、シグナル 15（SIGTERM ）がハンドラーに送信されます。 これにより、ハンドラーは正常に停止することができます。 さらに 60 秒 (2 倍のタイムアウト) 経過すると、シグナル 9 (SIGKILL) によって最終的に「終了」されます。

Checkmk は、同じホスト/サービスに適用され、同じパラメータで同じスクリプトを実行するアラートヘルパーが同時に実行されることを防止します。 このような状況は、最初のアラートハンドラーがまだ実行中であり、同じハンドラーの 2 つ目のコピーを起動しても意味がないことを示しています。2 つ目のハンドラーは即座にキャンセルされ、「失敗」と識別されます。

アラートハンドラーの出力および終了コードは確実に評価され、コアに返送されて監視ヒストリーに保存されます。 さらに、通知をトリガーすることもできます（以下を参照）。

アラートハンドラーを実行するためのグローバル設定がいくつかあります。

Alert handler log level は、アラートヘルパーのログファイル（~/var/log/alerts.log ）へのログ記録に影響します。

Master control スナップインをクリックすると、アラートハンドラーをグローバルに無効にすることができます。 現在実行中のハンドラーは影響を受けず、完了まで実行されます。

できるだけ早く小さなスイッチを緑色に戻すことを忘れないでください。 そうしないと、監視によってすべてが修正されているという誤った安心感に惑わされる可能性があります。

すべての Checkmk バージョンには、監視対象の Linux システム上でスクリプトを確実に実行するためのアラートハンドラーがビルトインされています。 このソリューションの最も重要な機能は次のとおりです。

Linux リモートアラートハンドラーは、以下の個々のエレメントで構成されています。

プロセス FOOサービスがクリティカルになったときに (これはすでに設定済みです)、myserver123 Linux システムで/etc/init.d/foo restart スクリプトを実行したいとします。 次のように進めます。

もちろん、エージェントを手動で準備することも可能です。 その場合は、テストシステムでエージェントベーカリーの手順を実行し、関連データを調べて、ご自身のシステムに手動で複製することをお勧めします。 ファイルパスのリストは、こちらでご覧いただけます。

この場合、エージェントベーカリーでリモートハンドラーをインストールするためのルールを作成することも重要です。このルールでは、アクセス用およびアラートハンドラーで使用するための SSH キーが生成されるからです。authorized_keys にインストールするための公開キーは、~/etc/check_mk/conf.d/wato/rules.mk 設定ファイル (またはrules.mk のサブフォルダ) にあります。