 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
2. 通知のセントラルビュー
Setup > Events > Notification から、通知の概要ページにアクセスできます。 このトピックに関する重要な情報はすべて、ここにまとめられています。
機能する通知システムは、すべて設定が必要な複数のコンポーネントの相互作用に基づいています。 この概要ページにより、Checkmk のさまざまな領域で個々のルールやパラメータなどを検索する手間が省けます。 ここから、通知に関するすべての情報にアクセスできます。
2.1. 通知のステータス
通知の現在のステータスの概要は、ページの左側に表示されます。
表示される内容は以下の通りです:
Failed notifications |
通知の失敗件数。 通知の失敗がある場合、その概要へのリンクが下に表示されます。 |
Total sent notifications |
送信された通知の数。 失敗した通知がある場合、過去 7 日間にフィルタリングされたNotifications of host & services へのリンクが下に表示されます。 これを使用して、送信された通知の詳細を確認できます。 |
Core status of notifications |
通知がアクティブになっている Checkmkサイトの数を表示します。 マスターコントロールのスナップインなどでサイト上で無効になっている場合、サイト名が表示されます。 これにより、これが意図した動作であるかどうかを確認できます。 |
2.2. 通知ルール
ステータス表示の右側には、Checkmk に存在するすべての通知ルールへのリンクがあります。
ここから、通知を最適化するためのルール、および通知に関連するその他のすべてのルールにアクセスできます。
 |
ここに表示されるルールは、Checkmk の他の場所で既にご覧になったことがあるかもしれません。 ここでは新しいルールは作成されておらず、既存のルールがわかりやすくまとめられています。 |
2.3. グローバルおよび定義済みの通知ルール
概要ページの最後の部分は、既存のグローバルルールで構成されています。
Checkmk を新しくインストールした場合、正確に 1 つのルールが事前定義されています。
このようなルールは、次のように構成されています。
条件 |
ホストのすべてのステータスが「DOWN 」および「UP 」に、サービスのすべてのステータスが「CRIT 」、「WARN 」、および「OK 」に変化した場合。 |
方法 |
HTML 形式の電子メール (メトリックグラフが埋め込まれたもの) を送信します。 |
連絡先 |
影響を受けるホスト/サービスのすべての連絡先。 |
通常どおり、ルールを編集、複製、削除、または新しいルールを作成することができます。 複数のルールがある場合は、アイコンを使用してドラッグアンドドロップで処理順を変更することができます。
|
通知ルールの変更は、変更をアクティブにする必要はなく 、すぐに有効になります。 |
3. 電子メールによる簡単な通知
しかし、より複雑な通知に進む前に、非常にシンプルなフォームの通知、つまり単純な電子メールから始めてください。
Checkmk から送信される HTML 形式の電子メール通知は、次のようなものです。
この例のように、電子メールには、影響を受けたサービスの現在のメトリックも記載されています。
Checkmk からこのような電子メールを受信するには、以下で説明するいくつかの準備が必要です。
3.1. 事前準備
Checkmk のデフォルト設定では、以下の前提条件が満たされている場合、ユーザーは電子メールで通知を受け取ります。
Checkmk サーバーに、電子メール送信のための設定が正しく行われています。
ユーザーにメールアドレスが設定されています。
この連絡先グループに割り当てられたホストまたはサービスで監視イベントが発生し、通知がトリガーされます。
3.2. Linux でのメール送信の設定
電子メールを正常に送信するには、Checkmk サーバーに SMTP サーバーが正しく設定されている必要があります。 Linux のディストリビューションによっては、Postfix、Qmail、Exim、Nullmailer などが利用される場合があります。 設定は、お使いの Linux ディストリビューションのリソースを使用して行います。
通常、設定は、すべての電子メールが送信される「スマートホスト」（SMTP リレーサーバーとも呼ばれる）の登録だけで完了します。 これが、貴社の社内 SMTP メールサーバーとなります。 通常、スマートホストは LAN では認証を必要としないため、設定は簡単です。 一部のディストリビューションでは、インストール時にスマートホストが問い合わせられます。 Checkmk アプライアンスでは、web インターフェイスからスマートホストを簡単に設定できます。
コマンドラインで「mail 」コマンドを使用すると、電子メールの送信を簡単にテストできます。
Linux ではこのコマンドにはさまざまな実装があるため、標準化のために Checkmk では、Heirloom mailxプロジェクトのバージョンをサイトユーザーの検索パス（~/bin/mail ）に直接提供しています。
対応する設定ファイルは「~/etc/mail.rc 」です。
通知スクリプトは後で同じ許可で実行されるため、これをテストするにはサイトユーザーとして実行するのが最適です。
電子メールの内容は標準入力から読み込まれ、-s で指定された件名が、コマンドラインの最後に引数として追加されます。
OMD[mysite]:~$ echo "content" | mail -s test-subject harry.hirsch@example.com電子メールは遅延なく配信されるはずです。
これが機能しない場合は、/var/log ディレクトリにある SMTP サーバーのログファイルで情報を見つけることができます (「ファイルとディレクトリ」を参照してください)。
3.3. メールアドレスと連絡先グループ
ユーザーのメールアドレスおよび連絡先グループは、ユーザー管理で定義します。
新しく生成された Checkmk サイトには、最初はEverything 連絡先グループのみが存在します。 このグループのメンバーは、すべてのホストおよびサービスについて自動的に責任を持ち、関連するすべての監視イベントについて電子メールで通知されます。
3.4. 特殊なケース：チケットシステム、メッセンジャー、イベントエンジン
電子メールや SMS の代わりに、チケットシステム（Jira や ServiceNow など）、メッセンジャー（Slack、Mattermost）、イベントエンジン（イベントコンソール）に通知を送信することもできます。
これらの特別なケースにはそれぞれ個別の通知方法があり、通知ルールで選択できます。 ただし、ルールを作成する際には、次の 2 つの点に注意してください。
連絡先を選択する際には、通知が1 つの連絡先（たとえば、1 人のユーザー）にのみ送信されるようにしてください。 チケットシステムなどの通知方法では、連絡先の選択は、通知を送信することを指定するだけの役割を果たします。 ただし、通知は、選択したユーザーには送信されず、チケットシステムに送信されます。 連絡先グループ、オブジェクトのすべての連絡先などを介して連絡先を選択すると、通常、1 つのイベントに対して複数の同一の通知が生成され、チケットシステムに 2 回、3 回、あるいはそれ以上送信されることにご注意ください。
最初の条件が満たされているにもかかわらず、同じ方法に対して複数の通知ルールでユーザーが使用されている場合、その場合はそれぞれ最後のルールのみが適用されます。 したがって、これらの通知ルールごとに個別の機能ユーザーを作成することをお勧めします。
3.5. HTML 電子メールの微調整
HTML 電子メールを送信する場合、追加情報を追加したり、問い合わせ用の返信先アドレス (Reply to) を特定の連絡先に柔軟に定義したりしたい場合があります。 このためには、Setup > Notifications > Parameters for notification methods > HTML Email ルールと、通知ルールでHTML 電子メール通知方法を使用します。 これらのルールを使用すると、応答アドレス、詳細を含む追加フィールド、HTML 形式のフリーテキストなど、さまざまなパラメータを追加できます。
Custom HTML section (e.g. title, description…) フィールドでは、セキュリティ上の理由から、使用できる HTML タグはごく一部のみです。 使用できるタグは次のとおりです。
| タグ | 機能 | ヒント |
|---|---|---|
|
|
|
|
||
|
||
|
||
|
廃止されました。このタグは使用しないでください。 |
|
|
||
|
||
|
||
|
廃止されました。このタグは使用しないでください。 |
|
|
スペースとインデントは保持されます。 |
|
|
||
|
||
|
||
|
以下のリスト内でのみ使用してください。 |
|
|
||
|
Checkmk のすべてのルールと同様に、非常にきめ細かな適用が可能であるため、ホストやサービスに対して、必要に応じて詳細な通知セットを個別設定することができます。
4. ルールによる通知の制御
単純な電子メール通知に加え、Checkmk ではより複雑な通知システムを設定することもできます。
4.1. 簡略化されたルールの作成
通知のルールを簡単に作成できるように、Checkmk は他の領域で慣れているものとは外観が異なります。Setup > Events > Notifications > Add notification rule を使用して、通知の作成を開始できます。
現在、選択が必要です。
Guided mode, を選択すると、セクションごとに通知ルールの作成手順が案内されます。 各セクションでは、通知の 1 つの側面について具体的に説明しています。 お使いの環境に関連するデータを、それぞれのセクションに入力してください。 個々のトピックの説明は、この記事の後半で説明します。 セクションの編集が完了したら、[Next step…] をクリックします。 技術的に必須である場合、入力した内容が検証されます。 たとえば、使用するメールアドレスなどの技術的に必要なデータが不足している場合、エラーメッセージが表示されます。 必要な基本データを正しく入力すると、次のセクションに進み、最後に通知ルールが完全に作成されます。 その後、[Apply & test notification rule ] または [Apply & create another rule] で作成を完了してください。
または、Overview mode を使用することもできます。 これは、既存の通知ルール内の個々のパラメータをターゲットに編集する場合、およびルール作成に精通しており、ガイドを必要としない場合に特に便利です。Overview mode では、すべての編集セクションが同時に表示され、すべてのフィールドとオプションを直接編集できます。 技術的な認証は、[保存] または [キャンセル] をクリックすると、すべてのセクションに対して一度だけ実行されます。Apply & test notification rule またはApply & create another rule
4.2. 通知ルールの構造
以下では、条件、イベントタイプ、フィルタ、通知方法、連絡先、および一般的なプロパティの定義とともに、通知ルールの一般的な構造について説明します。
条件
条件は、ルールが使用されるタイミングを決定します。 条件は、すべてのルールの基礎となります。 理解のために、ソースは常に具体的なホストまたはサービスの監視イベントであることを覚えておくことが重要です。
条件は、以下の項目を指定します。
オブジェクトの静的属性（サービス名に「
/tmp」というテキストが含まれているかどうか、ホストが特定のホストグループに属しているかどうかなど）現在の状態または状態の変化（サービスがOK からCRIT に変更されたかどうかなど）、
または、まったく異なる事項（たとえば、「作業時間」の期間が現在アクティブであるかどうか）
条件を設定する際に考慮すべき 2 つの重要なポイントがあります。
条件が定義されていない場合、ルールはすべての監視イベントに対して有効になります。
1 つの条件でも選択すると、すべての条件が満たされた場合にのみルールが有効になります。 選択したすべての条件は AND で連結されます。 この重要なルールには 1 つの例外がありますが、これについては後で説明しますので、ここでは考慮しません。
つまり、選択した条件が同時に満たされ、目的の場合に通知がトリガーされるかどうか、細心の注意を払う必要があります。
イベントタイプの定義
次の通知ルールの構造の例では、2 つのステータス変更によって通知がトリガーされます。
DOWN 状態に変化したホスト
CRIT 状態に変化したサービス。
これはステップ1で定義されます：
AND 演算の例外
Checkmk では、一般的に以下のことが適用されます。 監視イベントが設定されたすべての条件を満たした場合にのみ、通知ルールが適用されます。 この一般的なルールには、Host events およびService events 条件に関する 1 つの重要な例外があります。
Host eventsのみを選択した場合、ルールはどのサービスイベントとも一致しません。 同様に、Service events およびホストイベントの選択にもこれが適用されます。 ただし、両方の条件を有効にした場合、2つの条件のいずれかでイベントが定義されていると、ルールは一致します。 この例外的な場合、これらの条件は論理ANDではなく、ORでリンクされます。 これにより、1つのルールでホストとサービスの通知を簡単に管理できます。
ホストおよびサービスフィルタの設定
ステップ 2 では、さまざまなフィルタを使用して、通知ルールを適用するホストおよびサービスを決定します。
NTP で始まるサービスの監視イベントが、Main フォルダ内のホストで発生した場合にのみ通知が送信されるようにフィルタを設定するとします。
3 つの個別条件 (ステータス変更、サービス名、フォルダ) を含むこの通知ルールの結果、サービスがCRITになった場合にのみ通知が送信され、ホストのステータス変更は無視されます。これは、ホストのステータス変更とサービス名NTP を含む監視イベントがないためです。
上の画像にあるContact group filters オプションに関するもう 1 つのヒントです。 ここでチェックされる条件は、対象のホスト/サービスに特定の連絡先が割り当てられているかどうかです。 これを使用して、「連絡先グループ Linux のホスト通知は SMS で送信しない」などの機能を実装することができます。 これは、上記の連絡先選択とは関係ありません。
通知方法
ステップ 3 の通知方法は、通知の送信に使用する手法を指定します。たとえば、HTML 電子メールなどです。
通知方法通知方法では、通知の送信に使用する手法を指定します。 Checkmk には、あらかじめ定義されたスクリプトがいくつか用意されています。 また、独自の通知を実装するために、任意のプログラミング言語でカスタムスクリプトを簡単に作成することもできます。たとえば、通知を自社のチケットシステムにリダイレクトする場合などです。
一部の通知方法には、パラメータを含めることができます。
たとえば、ASCII および HTML 電子メールの方法では、送信者アドレス (From:) を明示的に指定することができます。
パラメータを設定する適切なページは、[Create] をクリックすると、方法を選択するとすぐに表示されます。
ただし、ここで個々の通知ルールを設定する前に、Checkmk には、通知方法に関するパラメータを 2 つの場所で設定できることをご承知おきください。
この記事の後半で説明する「通知方法のパラメータ」で設定できます。 通知ルールで、Select parameters で目的のパラメータ定義を選択してから、 Create をクリックして、この通知ルールの選択したパラメータ定義を変更します。
ホストおよびサービスのルール： 「Setup > Services > Service monitoring rules 」の下の「Notifications 」セクションには、各通知方法に関するルールセットがあり、これを使用して、ホストまたはサービスに応じて、通常どおりの同じ設定を定義できます。
通知ルールのパラメータ定義は、個々のケースでこれらの設定から変更したい場合にのみ変更してください。 たとえば、電子メールの件名をグローバルに定義し、個々の通知ルールで別の件名を定義することができます。
Send notification の代わりに、Suppress all previous を選択することもできます。 この方法を使用した以前のルールからの通知は、破棄されます。 詳細については、「ルールによる通知の削除」セクションを参照してください。
|
他のシステムに転送するための多くの通知方法については、別の記事で詳しく説明しています。 記事のリストは、「通知スクリプト」の章にあります。 |
連絡先の選択
通知は、通常、それぞれのホスト/サービスの連絡先として登録されているすべてのユーザーに送信されます。 これは「通常の」論理的な手順です。なぜなら、各ユーザーが GUI ディスプレイで受信するオブジェクト（つまり、そのユーザーが担当するオブジェクト）も連絡先によって定義されているからです。
Add recipient で連絡先を選択する際に、いくつかのオプションを指定して、通知の対象を他の連絡先にも拡大することができます。 Checkmk は、重複する連絡先を自動的に削除します。 ルールが有効になるには、少なくとも 1 つは選択する必要があります。
Restrict previous options to の 2 つのオプションは、機能が多少異なります。
ここでは、他のオプションで選択した連絡先が再び制限されます。
これらを使用すると、連絡先グループ間に AND オペレーターを作成することもできます。たとえば、Linux とData center の両方のグループに属するすべての連絡先に通知を送信できるようにします。
Explicit email addresses （ユーザー以外のユーザー）を入力すると、Checkmk で実際にユーザーとして指定されていないユーザーにも通知することができます。 もちろん、これは実際に電子メールを送信する通知方法で使用する場合にのみ意味があります。
選択した方法でSuppress all previous を選択した場合、ここで選択した連絡先に対する通知のみが削除されます。
|
通知方法として チケットシステム、メッセンジャー、イベントエンジン を使用する場合は、これらの特別なケースに関する注意事項もご参照ください。 |
通知の送信条件
単純なルールについては、当面は「Sending conditions 」の手順をスキップしてください。 これは主に、エスカレーションを設定する場合に有用です。
一般プロパティ
Checkmk のすべてのルールと同様に、ここでは、ルールの説明やコメントを追加したり、ルールを一時的に無効にしたりすることができます。
Allow users to deactivate this notification オプションを使用すると、ユーザーがこのルールによって生成される通知の「購読解除」を許可することができます。 その方法については、個人用通知で説明します。
4.3. 通知方法のパラメータを設定する
通知方法ごとに個別のパラメータを定義することができます。 これらのパラメータは、Checkmk の実際の通知ルールとは別々に定義および管理されます。 これにより、複数のルールで同時にパラメータを使用することができます。 1 か所で変更を行うだけで、トリガーとなるルールに関係なく、同じタイプのすべての通知に統一された外観が適用されます。
Setup > Events > Notifications および「Parameters for notifications methods 」ボタンをクリックして、カスタマイズ可能なすべてのパラメータの概要を開きます。
ここから、各方法に関する一般的なパラメータを作成、編集、およびルールで使用されていない場合は削除することができます。
4.4. 通知ルールのテスト
通知ルールのテストには、Checkmk のTest notifications というスマートなツールを使用できます。 このツールを使用すると、ホストまたはサービスの通知をシミュレートして、どの通知ルールが有効であるかを確認できます。 シミュレーションに加えて、通知を実際に送信することもできます。
通知テストにアクセスする最も簡単な方法は、Setup > Events > Test notifications を使用することです。 さらに、[Monitoring] (サービスリストおよびサービス詳細) および [Setup] (ホストプロパティ) の各ビューから、[Host > Test notifications] メニューで呼び出す他のオプションもあります。
まず、2 つのボタンのいずれかをクリックして、通知が「Host 」か「Service 」かを決定します。 次に、対象とするホストまたはサービスを選択します。 イベントとして、状態の変化またはスケジュールされたダウンタイムの開始を選択できます。 イベントの説明は、「Plugin output 」に追加できます。 「Send out notification for specific method 」チェックボックスを使用して、通知をシミュレーションのみにするか、実際に送信するか指定します。
最後に、[Advanced condition simulation ] に、通知の時間と回数を定義するための 2 つのオプションがあります。 これにより、特定の期間（営業時間外など）にのみ適用される通知ルール、または指定した回数だけ通知が繰り返された後にエスカレーションを開始する通知ルールをテストすることができます。
[Test notifications ] をクリックしてテストを開始します。このオプションを選択した場合は、送信も開始されます。 結果は、[Test notifications ] ボックスの下に表示されます。
まず、概要が表示されます。Test results （通知の送信）には、適用される通知ルールの数と、それらから生成される通知の数が表示されます。
Send out notification（通知を送信）を選択した場合、対応するメッセージ「notifications have been sent out （通知が送信されました）」がここに表示されます。
これにより、この問題に関する電子メールがすぐに送信されます。
その下の行には、入力内容から生成された通知が要約表示されます。 アイコンをクリックすると、通知のコンテキストを表示できます。 これにより、この通知のコンテキストで有効な環境変数とその値を確認できます。
次の 2 つのセクションでは、詳細が表示されます。
Predicted notifications （通知の送信先）には、通知の送信先と送信方法が表示されます。 通知の送信を選択していない場合でも、シミュレーションに関するこの情報を受け取ります。
[Global notification rules ] には、ここで作成した通知ルールがリスト表示されます。 この時点では、テーブルの最初の列のみが重要で、アイコンでどのルールが適用され、どのルールが適用されないかが示されています。
|
通常どおり、シミュレーションによる通知のテストの代わりに、GUI から直接通知をトリガーし続けることもできます。たとえば、Send custom notification およびFake check results コマンドを使用します。 |
4.5. 定期的に繰り返される通知とエスカレーション
一部のシステムでは、ホストタグ「Criticality 」が「Business critical 」に設定されているホストなど、問題が長期間続く場合、1 つの通知だけで対応するのは不適切である場合があります。
定期的に繰り返される通知の設定
Checkmk は、問題が承認または解決されるまで、一定間隔で通知を連続して発行するように設定できます。
この設定は、Periodic notifications during host problems 、またはPeriodic notifications during service problems ルールセットで行います。
このオプションを有効にすると、持続的な問題に対して、Checkmk は設定された間隔で定期的に通知をトリガーします。 これらの通知には、1 から始まる連番が付けられます (最初の通知は 1)。
定期的な通知は、問題について注意を喚起する（そしてオペレーターを煩わせる）だけでなく、エスカレーションの基礎としても役立ちます。つまり、定義した時間が経過すると、通知を他の受信者にエスカレーションすることができます。
エスカレーションの設定と理解
エスカレーションを設定するには、Restrict to notification number 条件を使用する追加の通知ルールを作成します。
連番の範囲として 3 から 99999 を入力すると、このルールは 3 回目の通知から有効になります。 エスカレーションは、別の方法（SMS など）を選択するか、他のユーザーに通知（連絡先の選択）することで実行できます。
Throttling of 'Periodic notifications' （通知間隔）オプションを使用すると、指定した時間後に通知の繰り返し頻度を減らすことができます。たとえば、最初は 1 時間ごとに電子メールを送信し、その後 1 日 1 通に減らすことができます。
複数の通知ルールを設定することで、エスカレーションモデルを構築することができます。 しかし、このエスカレーションは実際にはどのように機能するのでしょうか？ 誰に、いつ通知されるのでしょうか？ ここでは、周期的に繰り返される通知用の 1 つのルールと 3 つの通知ルールを使用して実装した例をご紹介します。 例：
サービスで問題が発生した場合、問題が解決または承認されるまで、60 分ごとに電子メール形式の通知が送信されます。
通知 1 から 5 は、そのサービスを担当する 2 人に送信されます。
通知 6 から 10 は、関連するチームリーダーにも送信されます。
通知 11 以降、毎日、会社の経営陣にメールが送信されます。
午前 9 時に、施設で問題が発生しました。 2 人の担当者に問題が発生したことを通知しましたが、何らかの理由で応答がありません。 そのため、10 時、11 時、12 時、13 時に、2 人にそれぞれ新しい電子メールが送信されました。 14 時の 6 回目の通知からは、チームリーダーにも電子メールが送信されるようになりましたが、それでも問題には変化はありません。 午後 3 時、4 時、5 時、6 時にも、チームメンバーとチームリーダーにさらに電子メールが送信されます。
午後 7 時に、3 番目のエスカレーションレベルが発動します。 この時点から、チームメンバーおよびチームリーダーには電子メールは送信されません。 その代わりに、問題が解決するまで、会社の管理者に毎日午後 7 時に電子メールが送信されます。
問題が解決し、Checkmk のサービスが「OK 」に戻ると、最後に通知されたグループに「問題解決」が自動的に送信されます。 したがって、上記の例では、問題が午後 2 時までに解決した場合は 2 人のチームメンバーに、午後 2 時から 7 時の間に解決した場合はチームメンバーとチームリーダーに、午後 7 時以降は会社の経営陣にのみ通知が送信されます。
4.6. ルールによる通知の削除
通知方法の選択で既に述べたように、Suppress all previous （通知の削除）という選択オプションもあります。 このようなルールの機能を理解するには、通知テーブルを視覚化するのが最善です。 具体的な監視イベントのルールの処理が一部完了し、いくつかのルールにより、次の 3 つの通知がトリガーされたとします。
| 誰（連絡先 | 方法 (方法) |
|---|---|
ハリー・ヒルシュ |
電子メール |
Bruno Weizenkeim |
電子メール |
ブルーノ・ヴァイゼンケーム |
SMS |
次に、SMS （SMS メッセージ）の方法とCancel previous notifications （連絡先グループ）の選択による次のルールを設定します。 連絡先選択では、Bruno Weizenkeim がメンバーである「Windows」グループを選択します。 このルールの結果、テーブルから「Bruno Weizenkeim / SMS」のエントリが削除され、テーブルは次のようになります。
| 誰 (連絡先) | 方法 (方法) |
|---|---|
ハリー・ヒルシュ |
電子メール |
Bruno Weizenkeim |
電子メール |
後続のルールで Bruno への SMS 通知が再び定義された場合、このルールが優先され、SMS がテーブルに新たに追加されます。
要約:
ルールは、特定の通知を抑制（削除）することができます。
削除ルールは、通知を作成するルールの後に指定する必要があります。
削除ルールは、それ以前のルールを実際に「削除」するわけではなく、それ以前の（複数の）ルールによって生成された通知を抑制します。
後続のルールでは、以前に抑制された通知を復活させることができます。
4.7. HTML 電子メールの同期配信
通知方法 HTML 電子メールについて、SMTP による追跡可能な配信を選択および設定するには、スマートホスト（名前とポート番号）およびアクセスデータと暗号化方法を入力します。
その後、関連するサービスのヒストリーで、配信状況を正確に追跡することができます。 ここでは、テストのために、サービスが手動でCRIT に設定された例をご紹介します。 以下のスクリーンショットは、このサービスの通知です。これは、Service > Service Notifications でサービス詳細ページに表示することができます。
ここでは、通知の基本に関する記事の通知履歴の章で既に紹介したように、4 つの個々のステップが時系列で下から上に表示されています。
重要な違いは、最上位のエントリで、電子メールがスマートホストに正常に配信され、その応答がsuccess であることが確認できることです。
~/var/log/notify.log ファイルでも、個々の手順を追うことができます。
以下の行は最後のステップに属し、SMTP サーバーの応答が含まれています。
2021-08-26 10:02:22,016 [20] [cmk.base.notify] Got spool file d3b417a5 (mysrv;CPU load) for local delivery via mail
2021-08-26 10:02:22,017 [20] [cmk.base.notify] executing /omd/sites/mysite/share/check_mk/notifications/mail
2021-08-26 10:02:29,538 [20] [cmk.base.notify] Output: success 250 - b'2.0.0 Ok: queued as 1BE667EE7D6'メッセージ ID1BE667EE7D6 は、スマートホストのログファイルに表示されます。
ここで、必要に応じて、電子メールがどこに届いたかを調査することができます。
いずれの場合も、電子メールが Checkmk から正しく送信されたこと、および送信された時刻を確認することができます。
上記のテストをもう一度繰り返しますが、今回は、スマートホストへの SMTP 転送用のパスワードを誤って設定しています。
ここでは、スマートホストからの SMTP エラーメッセージ「Error: authentication failed 」がプレーンテキストで表示されます。
通知の失敗についてはどうすればよいでしょうか？ ここでも、電子メールによる通知は明らかに良い解決策ではありません。 その代わりに、Checkmk は、概要スナップインに赤い背景色の明確な警告を表示します。
ここでは、以下の操作が可能です：
テキスト「… failed notifications 」をクリックすると、配信に失敗したメッセージのリストが表示されます。
アイコンをクリックしてこれらのメッセージを確認し、開いた概要で「Confirm 」をクリックして通知を削除します。
重要：エラー発生時に SMTP による直接配信を行うと、通知スクリプトの実行時間が非常に長くなり、タイムアウトになる場合があります。 そのため、通知スプーラを使用し、通知の非同期配信を選択することを強くお勧めします。
SMTP タイムアウトなどの繰り返し発生するエラーの対処方法は、通知方法ごとに [Global settings > Notifications > Notification spooler configuration ] で定義できます。
オプションのタイムアウト (デフォルトは 1 分) および最大再試行回数とともに、スクリプトを同時に複数実行して複数の通知を送信することを許可するかどうか (Maximum concurrent executions) も定義できます。 通知スクリプトの実行が非常に遅い場合は、並行実行が有効である可能性があります。ただし、スクリプトは、複数の実行が正常に実行されるように (たとえば、スクリプトが特定のデータを自身用に予約しないように) プログラムする必要があります。
SMTP による複数の並列配信は、ターゲットサーバーが複数の並列接続を管理できるため、問題はありません。 ただし、追加のスプーラーを使用せずにモデムから SMS 経由で直接配信する場合は、この限りではありません。この場合は、設定 1 をそのまま使用してください。
重要：SMTP による追跡可能な配信は、一括通知では使用できません。
5. 一括通知
5.1. 概要
監視業務に携わる方なら、孤立した問題によって（連続した）通知が殺到した経験があるでしょう。 親ホストの原則は、特定の状況下でこれを軽減する方法ですが、残念ながら、すべてのケースで有効というわけではありません。
Checkmk プロジェクト自体を例にとってみましょう。 Checkmk では、サポートしているすべての Linux ディストリビューション用のインストールパッケージを 1 日 1 回ビルドしています。 当社の Checkmk 監視は、適切な数のパッケージが正しく構築された場合にのみ、OK となるサービスとして設定されています。 ソフトウェアの一般的なエラーによりパッケージングが妨げられ、43 のサービスが同時にCRIT 状態になる場合があります。
このような場合、43 件の通知をすべて順番にリストした 1 通の電子メールのみ送信されるように通知を設定しています。 これは、43 通の電子メールを個別に送信する場合よりも当然わかりやすく、また「戦いの最中」にまったく別の問題に関する 44 通目の電子メールを見逃してしまうリスクも軽減されます。
この一括通知の動作モードは非常にシンプルです。 通知が発生すると、まずその通知はしばらく保留されます。 その間に発生した通知は、同じ電子メールにすぐに追加されます。 このコレクションは、ルールごとに定義することができます。 たとえば、日中は個別の電子メールで運用し、夜間は一括通知で運用することができます。 一括通知が有効になっている場合、通常、以下のオプションが表示されます。
待機時間は、必要に応じて設定できます。 多くの場合、1 分で十分です。遅くともその時間までに、関連する問題はすべて表示されるはずです。 もちろん、より長い時間を設定することもできますが その場合は、通知が根本的に遅れることになります。
当然のことながら、すべてを 1 つのポットに投げ込むことは意味がありません。そのため、まとめて通知する問題のグループを指定することができます。Host オプションは、非常に一般的に使用されています。これにより、同じホストからの通知のみがバンドルされます。
一括通知に関する追加情報：
ルールで一括通知が有効になっている場合、その有効化は後続のルールで無効にすることができます。その逆も同様です。
一括通知は、常に連絡先ごとに実行されます。 各連絡先には、それぞれ独自の「プライベートコレクションポット」が有効になっています。
ポットのサイズ（Max. notifications per bulk ）を制限することができます。 最大値に達すると、一括通知がすぐに送信されます。
5.2. 一括通知と期間
通知が通知期間内にあるが、この通知を含む一括通知 — 少し遅れて送信される — が通知期間外にある場合はどうなりますか？ 逆の場合も考えられます…
ここでは、非常に単純な原則が適用されます。 通知を期間に制限するすべての設定は、実際の通知にのみ有効です。 その後の一括通知は、すべての期間に関係なく、常に配信されます。
6. 適用可能なルールがない場合はどうなりますか？
設定を行う者にもミスはあり得ます。 通知設定のミスとして考えられるのは、重大な監視問題が見つかったにもかかわらず、通知ルールが 1 つも有効になっていない場合です。
このような場合から保護するために、Checkmk では「Fallback email address for notifications 」という設定を用意しています。 これは、Notifications セクションの「Setup > General > Global settings 」にあります。 ここにメールアドレスを入力してください。 このメールアドレスには、通知ルールが適用されない通知が送信されます。
|
あるいは、ユーザーの個人設定でユーザーを受信者として指定することもできます。 ユーザーに登録されているメールアドレスがフォールバックアドレスとして使用されます。 |
ただし、フォールバックアドレスは、ルールが適用されない場合にのみ使用され、通知がトリガーされなかった場合は使用されません。 通知の削除に関するセクションで示したように、通知を明示的に抑制することは望ましいことであり、設定ミスではありません。
フォールバックアドレスの入力は、Notifications ページで、画面上の警告とともに「推奨」されます。
何らかの理由で警告を削除したいが、同時に予備アドレスにも電子メールを受信したくない場合は、まず予備アドレスを入力し、次に最初のルールとして、以前の通知をすべて削除する新しいルールを作成してください。 このルールは、まだ通知が作成されていないため、通知設定には効果はありません。 しかし、これにより、少なくとも 1 つのルールが常に適用されるようになり、この警告を削除することができます。
ルールチェーンに抜けがある可能性があるので、この方法はお勧めできません。
|
自分だけ通知をオフにしたい場合は、個人用通知ルールを使用して設定できます。 |