通知の基本

Checkmk 通知システムの複雑さの多くは、重要でない通知を回避するための数多くの調整オプションによるものです。 そのほとんどは、通知が発生した時点で既に通知が遅延または抑制されている状況です。 さらに、監視コアには、特定の通知をデフォルトで抑制するインテリジェンスがビルトインされています。 この章では、これらのすべての側面について説明します。

ホストまたはサービスがスケジュールダウンタイムにある場合、そのオブジェクトの通知は抑制されます。 これは、可用性の正しい評価と並んで、監視にダウンタイムを実際に提供するための最も重要な理由です。 これに関連するのは、以下の詳細です。

設定時に、各ホストおよびサービスについて通知期間を定義することができます。 これは、通知を行う時間枠を定義する期間です。

設定は、セットアップメニューの検索から簡単に見つけることができる、Monitoring Configuration > Notification period for hosts 、またはNotification period for services ルールセットを使用して行います。 現在通知期間にないオブジェクトには、灰色の休止アイコン が表示されます。

現在通知期間にないオブジェクトの監視イベントは通知されません。 このような通知は、通知期間が再びアクティブになったときに、ホスト/サービスがまだ問題状態にある場合、「再発行」されます。 通知期間外にオブジェクトの状態に複数の変更があった場合でも、最新の状態のみが通知されます。

なお、通知ルールでは、通知を特定の期間に制限することも可能です。 これにより、時間範囲をさらに制限することができます。 ただし、時間条件を含むルールにより破棄された通知は、後で自動的に繰り返されることはありません。

ホストが完全に故障しているか、少なくとも監視にアクセスできない場合、そのサービスの監視は当然不可能になります。 アクティブチェックは、原則として「CRIT 」または「UNKNOWN」を登録します。これは、ホストへのアクセスをアクティブに試みるため、エラーが発生するためです。 このような状況では、他のすべてのチェック（つまり大部分のチェック）は省略され、以前の状態のまま残ります。 これらは、stale （時間）アイコンでフラグが付けられます。

このような状態で、すべてのアクティブチェックが問題を通知すると、当然のことながら非常に面倒になります。 たとえば、web サーバーにアクセスできない場合、そのことはすでに通知されていますので、そのサーバーに依存する HTTP サービスごとに電子メールを追加で生成してもあまり意味がありません。

このような状況を最小限に抑えるため、監視コアは、原則として、ホストが「UP 」状態の場合にのみ、サービスに対する通知を生成します。 これが、ホストのアクセス可能性が個別に認証される理由でもあります。 特に設定がない場合、この認証はSmart Pingまたは ping によって行われます。

Checkmk Raw（または Nagios コアを搭載した商業版）を使用している場合、ごくまれに、ホストの問題が アクティブなサービスに対して通知を生成することがあります。 これは、Nagios がホストチェックの結果を、その後しばらくの間は有効であると見なすためです。 サーバーへの最後の ping が成功してから次のアクティブチェックまで数秒しか経過していない場合でも、Nagios は、実際にはホストが「DOWN 」であるにもかかわらず、ホストを「UP 」と評価します。 一方、Checkmk マイクロコア (CMC)は、ホストの状態が確認されるまでサービス通知を「待機」モードに保持するため、不要な通知を確実に最小限に抑えることができます。

何百ものホストが接続されている、企業の拠点にある重要なネットワークルーターが故障したと想像してみてください。 そのルーターに接続されているすべてのホストは、監視対象から外れ、DOWN となります。 その結果、何百もの通知がトリガーされます。 これは問題です。

このような問題を回避するために、ルーターをそのホストの親ホストとして定義することができます。 冗長ホストがある場合は、複数の親を定義することもできます。 すべての親が「DOWN 」状態になると、到達できなくなったホストは「UNREACH 」状態としてフラグが付けられ、その通知は抑制されます。 もちろん、ルーター自体の問題については引き続き通知されます。

ちなみに、CMC は内部では Nagios とは少し異なる方法で動作しています。 偽アラームを減らし、本物の通知を確実に処理するために、CMC は関連するホストのチェックの正確な時刻に細心の注意を払っています。 ホストチェックが失敗した場合、コアは親ホストのホストチェックの結果を待ってから通知を生成します。 この待機は非同期であり、一般的な監視には影響しません。 これにより、ホストからの通知の遅延を最小限に抑えることができます。

Checkmk は「デフォルト」設定では、監視イベントが発生すると、影響を受けるホストまたはサービスのすべての連絡先に通知電子メールが送信されるように設定されています。 これは確かに最初は理にかなっていますが、実際には、次のような多くの追加要件が発生します。

Checkmk は、ルールベースのメカニズムにより、このような要件を最大限の柔軟性で実装することができます。

通知設定では、通知ルールチェーンを管理し、 誰に どのように通知するかを決定します。 監視イベントが発生すると、このルールチェーンが上から下へ順番に実行されます。 各ルールには、そのルールが当該の状況に実際に適用されるかどうかを判断する条件があります。

条件が満たされた場合、ルールは 2 つのことを決定します。

重要：ホストおよびサービスのルールとは対照的に、ここでは、該当するルールが満たされた後も評価は続行されます。 後続のルールでは、さらに通知を追加することができます。 前のルールによって生成された通知も削除することができます。

ルール評価の最終結果は、次のような構造のテーブルになります。

これで、このテーブルの各エントリに対して、その方法に適したユーザー通知を実際に実行する通知スクリプトが呼び出されます。

サービスが短時間だけ問題状態になることがあるが、停止はごく短時間であり、重大ではない場合があります。 このような場合、通知は煩わしいですが、簡単に抑制することができます。Delay host notifications およびDelay service notifications ルールセットは、このような状況に対応しています。

ここでは、時間を分単位で指定します。この時間が経過するまで、通知は遅延されます。 その前にOK /UP 状態が再び発生しても、通知はトリガーされません。 当然、これは、真の問題の通知も遅延されることを意味します。

もちろん、通知を遅らせるよりも、断続的な問題の根本原因を取り除くほうがより望ましいですが、それはまた別の話です...​

通知を遅らせるもう 1 つの非常に似た方法は、サービスが問題状態になったときに複数のチェックを試みるようにすることです。 これは、Maximum number of check attempts for hosts 、またはMaximum number of check attempts for service ルールセットを使用して実現できます。

たとえば、ここで3 の値を設定すると、CRIT の結果のチェックは、最初は通知をトリガーしません。 これは、CRIT ソフトステートと呼ばれます。 ハードステートは、OK のままです。 3 回連続の試行でOK 以外の状態が返された場合にのみ、サービスはハードステートに切り替えられ、通知がトリガーされます。

遅延通知とは対照的に、ここでは、このような問題が表示されないようにビューを定義するオプションがあります。 BI アグリゲーションは、ソフトステートではなくハードステートのみを含めるように構築することもできます。

ホストまたはサービスが短期間に頻繁に状態を変化する場合、フラッピングとみなされます。 これは実際の状態です。 ここでの原則は、サービスが（完全に）安定して実行されていない段階での過剰な通知を削減することです。 このような段階は、可用性統計でも特別に評価することができます。

フラッピングオブジェクトは、アイコンでマークされます。 オブジェクトがフラッピングしている間は、連続する状態変化によって通知は発生しません。 ただし、オブジェクトがフラッピング状態になったとき、およびフラッピング状態から抜け出したときには、通知が発生します。

フラッピングの認識は、以下の方法で変更できます。

カスタマイズ可能な値の詳細については、Help > Show inline help で状況依存ヘルプを表示してください。

まず、通知のプロセスを追跡できるように、Checkmk でホストおよびサービスレベルの通知のヒストリーを表示する方法をご紹介します。

Checkmk が通知をトリガーする監視イベントとしては、たとえば、サービスの状態の変化があります。 テストのために、Fake check results コマンドを使用して、この状態の変化を手動でトリガーすることができます。

通知のテストでは、この方法でサービスを「OK 」状態から「CRIT 」状態に切り替えることができます。 ここで、Service > Service notifications を使用してサービス詳細ページでこのサービスの通知を表示すると、以下のエントリが表示されます。

最新のエントリはリストの一番上に表示されます。ただし、最初のエントリは一番下にあるため、エントリを 1 つずつ上から順に確認しましょう。

さまざまな設定オプションや基本条件のコンテキストを正しく理解し、通知が予想どおりに表示されない場合に正確な問題診断を行うために、ここでは、関連するすべてのコンポーネントを含む通知プロセスの詳細について説明します。

Checkmk 通知システムには、以下のコンポーネントが含まれます。

コアが生成した生の通知は、通知ルールのチェーンを通過し、通知のテーブルになります。 生の通知のデータに加えて、すべての通知には以下の追加情報が含まれます。

同期配信では、テーブルのすべてのエントリに対して、適切な通知スクリプトが実行されます。 非同期配信では、通知はファイルとして通知スプーラに渡されます。

商業版の強力な追加機能として、通知スプーラがあります。 これにより、通知を非同期で配信することができます。 この文脈での「非同期」とはどういう意味でしょうか？

通知スクリプトが迅速に実行され、何よりもタイムアウトが発生しない場合は、同期配信が可能です。既存のスプーラにアクセスする通知方法では、これは当然のことです。 システムのスプールサービスは、特に電子メールや SMS で使用できます。 通知スクリプトは、ファイルをスプーラに渡します。この手順では、待機状態になることはありません。

SMTPまたはネットワーク接続を確立するその他のスクリプトによる追跡可能な配信を使用する場合は、常に非同期配信を使用する必要があります。 これは、インターネット経由で HTTP によってテキストメッセージ (SMS) を送信するスクリプトにも適用されます。 ネットワークサービスへの接続を確立する際のタイムアウトは、数分かかる場合もあり、前述のようなジャムが発生します。

幸い、Checkmk では非同期配信がデフォルトで有効になっています。 まず、サイト起動時に通知スプーラ (mknotifyd) も起動します。これは、次のコマンドで確認できます。

一方、非同期配信（Asynchronous local delivery by notification spooler ）は、Global settings > Notifications > Notification Spooling で選択されています：

監視は、それが信頼できる場合にのみ有用です。 そのためには、通知が確実かつ 迅速に受信される必要があります。 しかし、残念ながら、電子メールの配信は完全に理想的とは言えません。 通常、送信は、電子メールをローカル SMTP サーバーに渡すことで処理されます。 これにより、電子メールは自律的かつ非同期的に配信が試みます。

一時的なエラー（受信 SMTP サーバーに接続できない場合など）が発生すると、電子メールはキューに入れられ、後で再送信が試みます。 この「後で」とは、原則として 15～30 分後です。 その時点で通知は遅すぎるかもしれません。

電子メールが本当に配信できない場合、SMTP サーバーはログファイルにわかりやすいエラーメッセージを作成し、「送信者」にエラー電子メールを生成しようと試みます。 しかし、監視システムは実際の送信者ではなく、電子メールを受信することもできません。 その結果、このようなエラーは単に消えてしまい、通知は届きません。

商業版では、SMTP による追跡可能な配信が可能です。 これは、ローカルメールサーバーの助けを借りずに意図的に行われます。 その代わりに、Checkmk 自体が SMTP 経由でスマートホストに電子メールを送信し、SMTP の応答を自ら評価します。

これにより、SMTP エラーがインテリジェントに処理されるだけでなく、正しい配信も正確に記録されます。 これは、書留郵便に少し似ています。 Checkmk は、SMTP スマートホスト（受信サーバー）から、電子メールが受理されたことを確認する受信確認（メール ID を含む）を受け取ります。

SMTP 経由で配信を追跡できる通知を設定する実際的なプロセスについては、グローバル通知ルールおよび 個人通知ルールで説明しています。

エラーメッセージと追跡可能性を含む同期配信は、現在まで HTML 電子メールにのみ実装されています。 自作の通知スクリプトでエラーステータスを返す方法については、独自のスクリプトの作成に関する章をご覧ください。

通知は、さまざまな方法で個別に行うことができます。 典型的な例としては、次のようなものがあります。

このため、Checkmk には、独自の通知スクリプトを作成できる非常にシンプルなインターフェースが用意されています。 これらのスクリプトは、Linux でサポートされているあらゆるプログラミング言語で作成できます。ただし、Shell、Perl、Python の 3 つで「市場」の 95% を占めています。

Checkmkに付属の標準スクリプトは、~/share/check_mk/notifications にあります。 このディレクトリはソフトウェアの構成要素であり、変更することはできません。 代わりに、独自のスクリプトは~/local/share/check_mk/notifications に保存してください。 スクリプトが実行可能であることを確認してください (chmod +x)。 そうすることで、スクリプトが自動的に検出され、通知ルールで選択可能になります。

標準スクリプトをカスタマイズする場合は、~/share/check_mk/notifications から~/local/share/check_mk/notifications にスクリプトをコピーし、コピーしたスクリプトを変更してください。 元の名前を残した場合、スクリプトは自動的に標準バージョンに置き換えられ、既存の通知ルールを変更する必要はありません。

通知の場合、スクリプトはサイトユーザーの許可で呼び出されます。 環境変数では、NOTIFY_ で始まる変数に、影響を受けるホスト/サービス、監視イベント、通知先の連絡先、および通知ルールで指定されたパラメータに関するすべての情報がスクリプトに送信されます。

スクリプトが標準出力(print 、echo など) に書き込むテキストは、通知モジュールのログファイル~/var/log/notify.log に表示されます。

通知スクリプトでは、再現可能なエラーまたは最終的なエラーが発生したかどうかを、終了コードを使用して通知することができます。

さらに、すべてのケースで、通知スクリプトの標準出力は、ステータスとともにホスト/サービスの通知ヒストリーに入力されるため、GUI で確認できます。

重要： 一括通知では、追跡可能な通知は使用できません。

ユーザーからの通知エラーの処理については、SMTP による追跡可能な配信に関する章で説明します。

例として、通知に関するすべての情報をファイルに書き込むスクリプトを作成することができます。 コーディング言語は Bash Linux シェルです。

次に、スクリプトを実行可能にしてください。

スクリプトに関する説明は、次のとおりです。

このスクリプトを使用するには、通知ルールでメソッドとして定義する必要があります。 自作のスクリプトにはパラメータ宣言がないため、HTML Email メソッドなどで提供されているようなチェックボックスはすべて表示されません。 その代わりに、NOTIFY_PARAMETER_1 、NOTIFY_PARAMETER_2 などとしてスクリプトで使用できるテキストのリストをパラメータとして入力できます。 テストのために、パラメータFröhn 、Klabuster 、Feinbein を指定します。

テストするには、ホストmyserver で、サービスCPU load をCRITに設定します —  Fake check results コマンドを使用します。 通知モジュールのログファイル~/var/log/notify.log に、パラメータを含むスクリプトの実行と、生成されたスプールファイルが表示されます。

ファイル~/tmp/foobar.out には、通知に関する情報を含むすべてのCheckmk環境変数のアルファベット順のリストが表示されます。 ここで、スクリプトで使用できる値を確認できます。 最初の10行は次のとおりです。

パラメーターも以下の場所で確認できます:

上記の例では、スクリプトに渡される環境変数のいくつかを紹介しました。 具体的にどの変数が利用可能かは、通知の種類、Checkmk のバージョンとエディション、および使用している監視コア (CMCまたは Nagios) によって異なります。env コマンドのトリックの他に、すべての変数の完全なリストを取得する 2 つの方法があります。

以下は、最も重要な変数のリストです。

スクリプトが一括通知をサポートする場合は、複数の通知を同時に配信する必要があるため、特別な準備が必要です。 このため、環境変数を使用した配信も実際には機能しません。

ヘッダーの3 行目に、以下のようにスクリプトに名前を付けます。通知モジュールは、標準入力から通知を送信します。

スクリプトは、標準入力から変数のブロックを受け取ります。 各行は、NAME=VALUE のフォームになります。 ブロックは空白行で区切られます。 テキスト内の改行は、コード 1 (\a) の ASCII 文字で表します。

最初のブロックには、一般的な変数 (呼び出しパラメータなど) のリストが含まれます。 その後の各ブロックは、変数を通知にまとめます。

データをファイルに書き込んで、データがどのように送信されるかを確認する簡単なテストで、ご自身で試してみるのが最善です。 この目的には、次の通知スクリプトを使用できます。

上記の手順でスクリプトをテストし、さらに通知ルールでNotification Bulking を有効にしてください。

Checkmk には、人気のある、広く使用されているインスタントメッセージングサービス、インシデント管理プラットフォーム、チケットシステムに接続するためのさまざまなスクリプトがすでに用意されています。 これらのスクリプトの使用方法については、以下の記事をご覧ください。

SMTP サーバーのログファイルはシステムファイルであり、その絶対パスは以下にリストされています。 ログファイルが保存される正確な場所は、お使いの Linux ディストリビューションによって異なります。