 |
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. |
1. 概要
Checkmk の通知システムの便利な機能の一つは、管理者権限を持たないユーザーでも通知をカスタマイズできることです。 ユーザーは次のことができます。
通常では受信しない通知を追加する（「購読」）。
通常受信する通知を削除する（制限されていない場合）
通知のパラメータをカスタマイズする
通知を完全に使用不能にする
2. 個人ルールによる通知の制御
ユーザーの視点からのエントリポイントは、ユーザーメニューの「Notification rules 」です。Your personal notification rules ページで、「Add rule 」を使用して新しいルールを作成できます。
個人用通知ルールの内容は、グローバル通知ルールと似ていますが、1 つの違いがあります。それは、連絡先選択が含まれていないことです。 連絡先は、ユーザー自身が自動的に選択されます。 つまり、ユーザーは自分の個人用通知のみを追加または削除することができます。
ただし、ユーザーは、通知を作成する (グローバル) ルールで [Allow users to deactivate this notification ] オプションが有効になっている場合にのみ、通知を削除できます。
通知ルールの順序では、個人用ルールは常にグローバルルールよりも後に来るため、これまでに生成された通知テーブルを調整することができます。 したがって、前述の削除のブロックを除き、グローバルルールは、ユーザーがカスタマイズできるデフォルト設定として常に適用されます。
 |
通知ルールの変更は、変更をアクティブにする必要はなく 、すぐに有効になります。 |
2.1. 通知ルールの構造
以下では、一般的なプロパティ、通知方法、および条件の定義とともに、個人用通知ルールの一般的な構造について説明します。
一般的なプロパティ
Checkmk のすべてのルールと同様に、ここでは、ルールの説明やコメントを追加したり、ルールを一時的に無効にしたりすることができます。
通知方法
通知方法では、通知の送信に使用する手法を指定します。たとえば、HTML 電子メールなどです。
各方法は、スクリプトを使用して実現されます。 Checkmk には、いくつかのスクリプトが含まれています。 また、独自のチケットシステムに通知をリダイレクトするなど、特別な通知を実装するために、任意のプログラミング言語でカスタムスクリプトを簡単に作成することもできます。
方法には、ASCII および HTML 電子メールを送信する方法で送信者のアドレスを明示的に設定する (From:) などのパラメータを含めることができます。
通知ルールで直接設定を行う前に、通知方法のパラメータは、ホストおよびサービスのルールでも指定できることをご承知おきください。Setup > Services > Service monitoring rules の「Notifications 」セクションには、各通知方法のルールセットがあり、これを使用して同じ設定を定義できます。通常どおり、ホストまたはサービスに依存することができます。
通知ルールのパラメータ定義により、これらの設定を個別に変更することができます。 たとえば、電子メールのグローバルな件名を定義し、個別の通知ルールで代替の件名を定義することができます。
パラメータの代わりに、Cancel previous notificationsを選択することもできます。これにより、この方法に関する以前のルールによるすべての通知が削除されます。 詳細については、トピック「通知の削除」を参照してください。
|
他のシステムに転送するための多くの通知方法については、別の記事で詳しく説明しています。 記事のリストは、「 通知スクリプト」の章にあります。 チケットシステム 、メッセンジャー、イベントエンジン を通知方法として使用する場合は、これらの特殊なケースに関する注意事項もご参照ください。 |
条件
条件は、ルールが使用されるタイミングを決定します。理解のために、ソースは常に具体的なホストまたはサービスの監視イベントであることを覚えておくことが重要です。
条件は、
条件を設定する際に考慮すべき 2 つの重要なポイントがあります。
条件が定義されていない場合、ルールはすべての監視イベントに対して有効になります。
1 つの条件でも選択すると、すべての条件が満たされた場合にのみルールが有効になります。 選択したすべての条件は AND で連結されます。 この重要なルールには 1 つの例外がありますが、これについては後で説明しますので、ここでは考慮しません。
つまり、選択した条件が同時に満たされるかどうか、つまり、希望するケースで通知がトリガーされるかどうか、細心の注意を払う必要があります。
たとえば、Main フォルダ内のホストで、NTP で始まるサービスの監視イベントが発生した場合に通知をトリガーしたいとします。
さらに、この条件を拡張して、ホストのすべての状態がDOWN 状態になった場合にも通知するようにします。
3 つの単一の条件を含むこの通知ルールの結果、ホストの状態変化と NTP を含むサービス名を含む監視イベントは発生しないため、通知は決して発生しません。
このユーザーガイドでは、以下の注意が随時繰り返されます。 ただし、通知の設定に関しては、再度強調しておきます。Help > Show inline help でインラインヘルプを表示して、さまざまな条件の効果の詳細を確認してください。Match services オプションのインラインヘルプからの以下の抜粋は、この動作を非常によく説明しています。 「注：このオプションを使用している場合、ホスト通知はこのルールと一致することはありません。
AND 演算の例外
監視イベントが設定されたすべての条件を満たした場合にのみ、通知ルールが適用されます。 前述のように、この一般的なルールには 1 つの重要な例外があります。それは、Match host event type およびMatch service event type 条件の場合です。
Match host event typeのみを選択した場合、ルールはどのサービスイベントとも一致しません。 同様に、Match service event type とホストイベントの選択にもこれが適用されます。 ただし、両方の条件を有効にした場合、2つのチェックボックスリストのいずれかでイベントタイプが有効になっていると、ルールは一致します。 この例外的な場合、これらの条件は論理ANDではなく、ORでリンクされます。 このようにして、1つのルールでホストとサービスの通知を簡単に管理することができます。
Match contacts （ホストがアクティブ）およびMatch contact groups （ホストがアクティブ）の条件に関するもう 1 つのヒントです。
ここでチェックされる条件は、該当するホスト/サービスに特定の連絡先が割り当てられているかどうかです。 これを使用して、「連絡先グループ Linux のホスト通知は SMS で送信しない」などの機能を実装することができます。 これは、上記の連絡先選択とは関係ありません。
2.2. ルールによる通知の削除
通知方法の選択で既に述べたように、Cancel previous notifications （ルールによる削除）オプションもあります。 このようなルールの機能を理解するには、通知テーブルを視覚化するのが最善です。
特定の監視イベントに関するいくつかのルールがすでに処理されていると仮定しましょう。 これにより、ユーザーに対して 2 つの通知（1 つは電子メール、もう 1 つは SMS）が生成されました。
次に、方法「SMS 」と選択「Cancel previous notifications 」が設定された次のルールが実行されます。 このルールの結果、ユーザーへの SMS 通知は削除され、電子メールのみが生成されます。
後続のルールで Bruno に対する SMS 通知が再び定義された場合、このルールが優先され、SMS がテーブルに新たに追加されます。
要約すると：
ルールは、特定の通知を抑制（削除）することができます。
削除ルールは、通知を作成するルールの後に設定する必要があります。
削除ルールは、それ以前のルールを実際に「削除」するのではなく、それ以前の（複数の）ルールによって生成された通知を抑制します。
後続のルールでは、以前に抑制された通知を復活させることができます。
2.3. HTML 電子メールの同期配信
通知方法 HTML 電子メールで SMTP による追跡可能な配信を選択および設定するには、スマートホスト (名前とポート番号) およびアクセスデータと暗号化方法を入力します。
Checkmk ユーザーインターフェースおよびログファイルで配信の成功または失敗を追跡する方法の詳細については、グローバル通知ルールに関する記事をご覧ください。
重要： 一括通知では、追跡可能な通知は使用できません。
3. 一括通知
3.1. 概要
監視業務に携わる方なら、孤立した問題によって（連続した）通知が殺到した経験があるでしょう。 親ホストの原則は、特定の状況下でこれを軽減する方法ですが、残念ながら、すべてのケースで有効というわけではありません。
Checkmk プロジェクト自体を例にとってみましょう。 Checkmk では、サポートしているすべての Linux ディストリビューション用のインストールパッケージを 1 日 1 回ビルドしています。 当社の Checkmk 監視は、正しい数のパッケージが正しく構築された場合にのみ、OK となるサービスとして設定されています。 ソフトウェアの一般的なエラーによりパッケージングが妨げられ、43 のサービスが同時にCRIT 状態になる場合があります。
このような場合、43 件の通知をすべて順番にリストした 1 通の電子メールのみ送信されるように通知を設定しています。 これは、43 通の電子メールを個別に送信する場合よりも当然わかりやすく、また「戦いの最中」にまったく別の問題に関する 44 通目の電子メールを見逃してしまうリスクも軽減されます。
この一括通知の動作モードは非常にシンプルです。 通知が発生すると、まずその通知はしばらく保留されます。 その間に発生した通知は、同じ電子メールにすぐに追加されます。 このコレクションは、ルールごとに定義することができます。 したがって、たとえば、日中は個別の電子メールで運用し、夜間は一括通知で運用することができます。 一括通知が有効になっている場合、通常、以下のオプションが表示されます。
待機時間は、必要に応じて設定できます。 多くの場合、1 分で十分です。遅くともその時間までに、関連する問題はすべて表示されるはずです。 もちろん、より長い時間を設定することもできますが その場合は、通知が根本的に遅れることになります。
当然のことながら、すべてを 1 つのポットに投げ込むことは意味がありませんので、まとめて通知する問題のグループを指定することができます。Host オプションは、非常に一般的に使用されています。これにより、同じホストからの通知のみがバンドルされます。
一括通知に関する追加情報：
ルールで一括通知が有効になっている場合、その有効化は後続のルールで無効にすることができます。その逆も同様です。
一括通知は、常に連絡先ごとに実行されます。 各連絡先には、それぞれ独自の「プライベートコレクションポット」が有効になっています。
ポットのサイズ（Maximum bulk size ）を制限することができます。 最大値に達すると、一括通知がすぐに送信されます。
3.2. 一括通知と期間
通知が通知期間内にあるが、この通知を含む一括通知が、その通知よりも少し遅れて通知期間外になった場合はどうなりますか？ 逆の場合も考えられます…
ここでは、非常に単純な原則が適用されます。 通知を期間に制限する設定は、実際の通知にのみ有効です。 その後の一括通知は、すべての期間に関係なく、常に配信されます。
4. 管理者設定
4.1. 通知の一時的な無効化
ユーザーによる通知の完全な無効化は、General Permissions > Disable all personal notificationsという許可によって保護されています。この許可は、デフォルトではユーザーロールuser にno に設定されています。
ユーザーには、user ロールにこの権限を明示的に割り当てた場合のみ、個人設定に該当するチェックボックスが表示されます。
ユーザーの個人設定にアクセスできる管理者として、上記の許可がない場合でも、ユーザーに代わって使用不能にする操作を行うことができます。 この設定は、[Setup > Users > Users ]、そしてユーザープロファイルのプロパティで確認できます。
これにより、たとえば、実際の設定を変更することなく、休暇中の同僚の通知をすばやく無音にすることができます。
4.2. ユーザー定義のカスタマイズを防止する
カスタマイズを完全に防止したい場合は、user ロールの「General Permissions > Edit personal notification settings 」の許可を取り消してください。
管理者として、[Setup > Events > Notifications]、[Display > Show user rules ] メニューの順に選択すると、すべてのユーザールールを表示できます。
グローバルルールに続いて、個人ルールがリスト表示されます。このリストも で編集できます。