通知のスイッチ

Checkmkの通知とは、ホストまたはサービスの状態が変化した場合に、ユーザーに積極的に通知することです。 ある時点で、ホストmywebsrv17 のサービスHTTP foo.bar がOK からCRIT に変化したとします。 Checkmk はこれを検出し、デフォルトでは、このイベントに関する最も重要なデータを含む電子メールを、このサービスのすべての連絡先に送信します。 その後、状態がCRIT からOK に再び変化すると、連絡先には別の電子メールが送信され、今回はリカバリがレポートされます。

しかし、これは最も単純な通知方法にすぎません。 これをさらに改良する方法は数多くあります。

ただし、通知の使用を開始する前に、次の点に注意してください。

最も簡単で、最も一般的な方法は、電子メールで通知を送信することです。 電子メールには、メトリックのグラフも記載するのに十分なスペースがあります。

電子メールで通知を行うには、Checkmk サーバーが電子メール送信用に設定されている必要があります。 サポートされているすべての Linux ディストリビューションでは、これは基本的に以下の手順で完了します。

メール送信が正しく設定されている場合、コマンドラインから、たとえば次のコマンドを使用して電子メールを送信できるはずです。

電子メールは遅滞なく配信されるはずです。 これが機能しない場合は、/var/log/ ディレクトリにある SMTP サーバーのログファイルで問題の原因に関する手がかりを見つけることができます。 Linux でのメール配信の設定の詳細については、通知ルールに関する記事をご覧ください。

電子メールの送信が基本的に機能したら、通知の有効化は非常に簡単です。 ユーザーが電子メールで通知を受信するには、以下の条件を満たしている必要があります。

メールアドレスと連絡先グループの割り当ては、この章の前のユーザー管理で説明したように、ユーザーのプロパティで行います。 たとえば、cmkadmin というユーザーアカウントに、自分のメールアドレスと連絡先グループEverything を追加します。Checkmk には、ホストおよびサービスの重要なステータス変更を HTML メールで各連絡先に通知する通知ルールがすでに設定されています。

「重要」の意味については、次のセクションで説明します。

実際の問題が発生するのを待ったり、テストのために問題を引き起こしたりするのは少し面倒です。Test notifications を使用すると、ホストまたはサービスの通知をシミュレートし、通知をすぐに送信することができるため、この作業が簡単になります。

まず、Setup > Events > Notifications で通知センターを開きます。

このページを初めて呼び出すと、上のスクリーンショットのように、まだ設定されていない「フォールバックメールアドレス」について通知されます。 この情報は、ここでは無視してかまいません。 このトピックについては、通知ルールに関する記事で説明します。 このセクションを読むまでは、この情報をリマインダーとして残しておき、Do not show again をクリックして削除しないことをお勧めします。

そうしないと、このページには、送信された通知や失敗した通知の数などのステータス情報が表示され、通知のトピックに関連するアクション（通知ルールの作成、通知に影響を与えるホストおよびサービスルールの呼び出しなど）を呼び出すために使用されます。

Notifications ページの下部、Global notification rules ボックスには、Checkmk が提供するグローバル通知ルールが表示されます。 「グローバル」とは、すべてのユーザーが、ユーザー定義の通知ルールを作成できることを意味します。

提供されている通知ルールにより、ホストおよびサービスの重要なステータス変更に関する通知が、すべての担当者に HTML 形式の電子メールで送信されます。DOWN およびUP へのホストのステータス変更、およびCRIT 、WARN 、OK へのサービスのステータス変更は、すべて「重要」として分類されます。

通知テストでは、表示されている通知ルールが評価されます。 通知テストには、Setup > Events > Notifications およびTest notifications ボタンからアクセスできます。

ホストを選択し、イベントとして任意の状態変更を選択してください。Trigger notification for a specific method チェックボックスをアクティブにすると、通知がシミュレーションされるだけでなく、実際に送信されるようになります。

「Test notifications 」をクリックします。 結果はページの最下部に表示されます。 最も重要なのは、上部の「Test results 」の要約です：

テストが成功するには、少なくとも 1 つの通知ルールが一致している必要があります。notification has been triggered を含むメッセージは、通知が実際に送信されたことを示しています。

Predicted notifications （通知が送信されました）の下に、通知が送信された宛先とチャンネルが表示されます。

最後に、下部のフィールドの最初の列には、どの通知ルールが有効になり、どのルールが無効になったかが表示されます。

これにより、このシミュレーションの問題に関する電子メールがすぐに送信されます。 通知テストのオプションと結果の詳細については、通知ルールに関する記事をご覧ください。

実際の監視、つまりシミュレーション以外で通知を受け取らなかった場合でも、必ずしもエラーであるとは限りません。 Checkmk からの通知が意図的に抑制される場合があります。

Checkmk の通知は、複雑なルールを用いて、お客様やお客様の組織のニーズに合わせてさまざまな方法で調整することができます。 詳細については、通知に関する記事をご覧ください。

Checkmk の通知モジュールは非常に複雑です。これは、長年の実務経験で重要であることが証明された、さまざまな要件を網羅しているためです。 そのため、「なぜ Checkmk はここで通知しなかったのか」という質問は、特に初期段階では予想以上に頻繁に聞かれるでしょう。 そのため、ここではトラブルシューティングのヒントをいくつかご紹介します。

通知に関する問題については、まず、通知の失敗がないかどうかを確認してください。 これらは、Monitor > System > Failed notifications ページにリストされています。Summary 列には、エラーの原因、または少なくとも考えられる原因が示されています。

Checkmk では、システムが最近生成し、通知ルールを通過した最新の通知を分析することで、別の可能性も確認できます。Setup > Events > Analyze recent notifications.で、分析する通知のテーブルを開きます。 ここでは、通知を再送信したり、そのコンテキストを表示したり、関連する通知ルールを分析したりすることができます。 詳細については、通知に関する記事をご覧ください。

特定のサービスによって通知がトリガーされていない場合、まずそのサービスの通知のヒストリーをチェックします。 これを行うには、監視でサービスをクリックして、そのサービスの詳細ページを開きます。 メニューから「Service > Service notifications 」を選択します。 そこでは、このサービスに関するすべての通知イベントが、新しいものから古いものの順にリスト表示されます。

以下は、通知が試みられたものの、SMTP サーバーがインストールされていないため電子メールの送信に失敗したサービスの例です。

詳細情報は、~/var/log/notifiy.log ファイルで確認できます。 これは、サイトユーザーとして、たとえば「less 」コマンドで表示できます。

lessの使い方にまだ慣れていない場合は、Shift+G キーの組み合わせでファイルの最後にジャンプし (ログファイルの場合に便利です)、Q キーでless を終了することができます。

tail -f コマンドを使用すると、実行中のファイルの内容を「ライブ」で確認することもできます。 これは、tail を入力した後にのみ表示される新しいメッセージのみに関心がある場合に便利です。

以下は、通知が正常にトリガーされた場合のnotify.log の抜粋です。

通知の設定が完了しました。これで、Checkmk システムの最終調整は完了です。 もちろん、Checkmk の全機能が完全に活用できるようになったわけではありません。

監視の拡張を続けます。