イベントコンソール

Checkmk では、変更を有効にするには、まず変更をアクティブにする必要があります。 これは、複数の関連ルールに影響する変更について、ルールを「有効」にするタイミングを正確に指定できるため、デメリットではありません。 また、事前にEvent Simulator を使用して、すべてが意図したとおりに機能するかどうかをテストすることができます。

まず、ページ右上にある累積変更数の数字をクリックします。

次に、[Activate on selected sites ] をクリックして変更をアクティブにします。 イベントコンソールは、このアクションが中断されることなく実行されるように設計されています。 受信メッセージは常に確実に受信されるため、プロセスでメッセージが失われることはありません。

EC での変更をアクティブにできるのは、管理者だけです。 これは、Activate changes for event console （イベントコンソールをアクティブにする）の許可によって制御されます。

テストのために、Syslog または SNMP 経由でメッセージを送信することができます。 後でこの操作も実行してください。 ただし、最初のテストでは、EC のビルトイン機能である「Event Simulator 」を使用するとより実用的です。

ここでは 2 つのオプションがあります。Try out は、シミュレートされたメッセージに基づいて、どのルールが一致するかを評価します。 EC のセットアップ GUI の最上位レベルでは、ルールパッケージが強調表示されます。 ルールパッケージ内では、個々のルールが強調表示されます。 各パッケージまたはルールには、次の 3 つの記号のいずれかが付けられています。

[Generate event ] をクリックすると、[Try out] とほぼ同じ操作が行われますが、この場合はメッセージが実際に生成されます。 定義されているアクションが実際に実行されます。 また、イベントは監視のオープンイベントにも表示されます。 確認画面で、生成されたメッセージのソースコードを確認できます。

生成されたイベントは、[Monitor ] メニューの [Event Console > Events] に表示されます。

ネットワーク上で最初の実際のテストを行うには、別の Linux コンピュータから手動で syslog メッセージを簡単に送信することができます。 プロトコルは非常に単純なので、特別なプログラムは必要ありません。UDP を使用してnetcat またはnc にデータを送信するだけで済みます。 UDP パケットの内容は 1 行のテキストで構成されています。 これが特定の構造に従っている場合、イベントコンソールはコンポーネントをきれいに分解します。

ただし、何でも送信することもできます。 EC はそれをそのまま受け付け、メッセージテキストとして評価します。 アプリケーション、優先度などの追加情報は、当然ながら欠落します。 セキュリティ上の理由から、ステータスはCRIT と想定されます。

EC を実行している Checkmk サイト内には、echo を使用してローカルでテキストメッセージを書き込むことができる名前付きパイプがあります。 これは、ローカルアプリケーションを接続するための非常に簡単な方法であり、メッセージの処理をテストする方法でもあります。

ちなみに、ここでは syslog 形式で送信することも可能で、イベントデータのすべてのフィールドがきれいに記入されます。

Update & Acknowledge コマンドは、イベントリストの上に次の領域を表示します。

Update （更新、承認）ボタンを使用すると、1 つの操作でイベントにコメントを追加し、担当者を追加し、イベントを承認することができます。Change contact （コメント）フィールドは、意図的にフリーテキストになっています。 ここには、電話番号なども入力できます。 このフィールドは、GUI でのイベントの表示にはまったく影響しません。これは、純粋にコメント用のフィールドです。

Set event to acknowledged （承認済み）チェックボックスをオンにすると、イベントはopen （承認待ち）フェーズからacknowledged （承認済み）フェーズに切り替わり、以降、handled （承認済み）として表示されます。 これは、ホストおよびサービスの問題の承認と同様です。

その後、このチェックボックスをオフにしてコマンドを呼び出すと、承認が解除されます。

Change State コマンドを使用すると、イベントの状態を、たとえば「CRIT 」から「WARN 」に手動で変更することができます。

Custom Action コマンドを使用すると、イベントに対して自由に定義できるアクションを実行できます。 最初は、Send monitoring notification アクションのみ使用できます。 このアクションは、Checkmk 通知を送信し、アクティブに監視されているサービスからの通知と同じようにハンドルされます。 これは通知ルールを通過し、電子メール、SMS、またはそれに応じて設定した内容を送信します。 EC による通知の詳細については、以下をご覧ください。

Archive Event ボタンをクリックすると、開いているイベントリストからイベントが完全に削除されます。 イベントに対するすべてのアクション（この削除も含む）はアーカイブにも記録されるため、後でイベントに関するすべての情報にアクセスすることができます。 そのため、ここでは「削除」ではなく「アーカイブ」という表現を使用しています。

イベントリストから、個々のイベントを簡単にアーカイブすることもできます。

通常のユーザーに監視のホストおよびサービスの可視性を提供するために、Checkmk は連絡先グループを使用します。 これらのグループは、セットアップ GUI、ルール、またはフォルダ設定によってホストおよびサービスに割り当てられます。

イベントコンソールでは、イベントを連絡先グループに割り当てるという設定は存在しません。 これは、実際にどのメッセージが受信されるかは事前にわからないためです。 Syslog および SNMP のソケットはどこからでもアクセスできるため、ホストのリストも不明です。 そのため、イベントコンソールには、表示設定を定義するためのいくつかの特別な機能があります。

まず、ユーザーロールを設定する際に、「Event Console > See all events 」という許可があります。 これはデフォルトで有効になっているため、通常のユーザーはすべてのイベントを見ることができます。 これは、設定ミスによって重要なエラーメッセージが見落とされないように、意図的に設定されています。 より正確な表示にするための最初のステップは、user ロールからこの許可を削除することです。

イベントの可視性を他の監視とできるだけ一貫させるため、イベントコンソールは、イベントを受信するホストを、セットアップ GUI で設定されたホストとできるだけ一致させるよう努めます。 これは簡単に聞こえますが、実際には難しい作業です。 イベントにホスト名が記載されておらず、IP アドレスしかわからない場合もあります。 また、ホスト名がセットアップ GUI で設定されているものと異なる場合もあります。

割り当ては次のように行われます：

この割り当ては 1 つのポイントで変更できます。 つまり、ルールで連絡先グループが定義されており、ホストを割り当てることができる場合、通常はマッピングが優先されます。 これは、Precedence of contact groups オプションを使用してルールで変更できます。

さらに、通知のルールで直接設定を行うこともできます。 これにより、ホストの通常の責任よりもイベントの種類を優先させることができます。

ルールパック …​

… および個々のルール …​

…「Hits 」列には、パッケージまたはルールがメッセージと一致した回数が表示されます。 これにより、効果のないルールを削除または修正することができます。 また、一致頻度の高いルールについても、この情報は有用です。 EC のパフォーマンスを最適化するには、これらのルールをルールチェーンの先頭に配置する必要があります。 これにより、EC がすべてのメッセージに対してテストするルールの数を減らすことができます。

カウンターは、[Event Console > Reset counters ] メニュー項目でいつでもリセットできます。

ルールの試行では、Event Simulator を使用してルールの評価をチェックする方法について説明しました。 イベントコンソールの設定で、Debug rule execution の値をon に変更すると、すべてのメッセージについて、同様の情報をランタイムで取得することができます。

イベントコンソールのログファイルは、var/log/mkeventd.log にあります。このファイルには、チェックされたルールが有効にならなかった正確な理由が表示されます。

言うまでもなく、この集中的なログ記録は必要な場合にのみ、慎重に使用してください。 少し複雑な環境では、膨大な量のデータが生成されます。

テキストフィールドを含むすべての条件では、比較テキストは常に正規表現として扱われます。 比較は、大文字と小文字を区別せずに実行されます。 これは、他のモジュールにおける Checkmk の慣例とは例外です。 しかし、これにより、特にイベント内のホスト名は、各ホストでローカルに設定されている場合、中央で設定されている場合とスペルが必ずしも一致しないため、ルールの表現がより堅牢になります。 したがって、この例外はここでは非常に有用です。

さらに、インフィックス一致が常に適用されます。つまり、検索テキストの内容がチェックされます。 そのため、検索テキストの先頭または末尾に.* を記述する必要がありません。

ただし、1 つの例外があります。 ホスト名との一致に正規表現を使用せず、明示的なホスト名を使用する場合、そのホスト名は、含まれているかどうかではなく、完全一致がチェックされます。

注意：検索テキストにドット (.) が含まれている場合、それは正規表現とみなされ、インフィックス検索が適用されます。たとえば、myhost.com は、notmyhostide にも一致します。

ここで非常に重要で便利なのが、[Text to match ] フィールドのマッチグループという概念です。 これは、正規表現で括弧で囲まれた式と一致するテキストセクションを指します。

データベースのログファイルで、次のようなタイプのメッセージを監視したいとします。

WP41 はもちろん可変であり、異なるインスタンスごとに個別のルールを作成することは避けたいでしょう。 そのため、正規表現には、任意の文字列を表す「.* 」を使用します。

Database instance .* has failed

ここで、変数部分を丸括弧で囲むと、イベントコンソールは、今後のアクションのために実際の値を記憶（キャプチャ）します。

Database instance (.*) has failed

ルールが一致すると、最初のマッチグループはWP41 (またはエラーを発生させたインスタンス) の値に設定されます。

緑色のボールの上にカーソルを置くと、Event Simulator でこれらのマッチグループを確認できます。

生成されたイベントの詳細にも、これらのグループが表示されます。

マッチグループは、主に次のような用途に使用されます。

ここでヒントです。 正規表現で何かをグループ化する必要があるが、マッチグループを作成したくない場合があります。 これは、開括弧の直後に?: を配置することで実現できます。 例：式one (.*) two (?:.*) three は、one 123 two 456 three に対して、1 つのマッチグループ123 のみを作成します。

Match original source IP address フィールドでは、メッセージの送信者のIPv4アドレスを一致させることができます。 完全一致するアドレス、またはX.X.X.X/Yの表記でネットワークを指定します。たとえば、192.168.8.0/24 と指定すると、192.168.8.Xのネットワーク内のすべてのアドレスが一致します。

IP アドレスの一致は、監視対象のシステムがイベントコンソールに直接送信する場合にのみ機能することに注意してください。 別の中間 syslog サーバーがメッセージを転送している場合、そのアドレスがメッセージの送信者として表示されます。

Match syslog priority およびMatch syslog facility フィールドは、Syslog情報によって定義された標準情報です。 内部的には、8ビットフィールドは、施設（32通り）用の5ビットと優先度（8通り）用の3ビットに分割されています。

32 の事前定義された施設は、かつてはアプリケーションなど向けに用意されていました。 しかし、当時の選択は将来を見据えたものではありませんでした。 施設の一つであるuucpは、20 世紀の 90 年代初頭には既にほぼ廃れていました。

しかし、syslog 経由で送信されるすべてのメッセージには、これらのファシリティのいずれかが付いているのが現実です。 場合によっては、後でメッセージをフィルタリングできるように、メッセージの送信時にこれらのファシリティを自由に割り当てることもできます。 これは非常に便利です。

ファシリティと優先度の使用には、パフォーマンスの面でもメリットがあります。 いずれの場合も、同じファシリティまたは優先度を持つメッセージにのみ適用されるルールを定義する場合は、ルールのフィルタにこれらを追加で定義する必要があります。 そうすることで、イベントコンソールは、異なる値を持つメッセージを受信した場合に、これらのルールを非常に効率的にバイパスすることができます。 これらのフィルタが設定されているルールが多いほど、ルールの比較回数が少なくなります。

Negate match: Execute this rule if the upper conditions are not fulfilled. （条件がすべて満たされない場合にのみ有効）チェックボックスをオンにすると、条件が1 つも満たされない場合にのみルールが有効になります。 これは、実際には 2 種類のルール (ルールの [Outcome & Action ] ボックスの [Rule type ]) でしか使用できません。

ルールパックの詳細については、以下をご覧ください。

ルールが一致すると、そのメッセージに対して実行すべき処理が指定されます。 これは、[Outcome & Action ] ボックスで設定します。

Rule type （ルールの一時停止）を使用すると、その時点での評価を完全に中止したり、現在のルールパッケージの評価を中止したりすることができます。 特に最初のオプションは、最初の段階でいくつかの特定のルールを使用して、ほとんどの不要な「ノイズ」を取り除くために使用します。 このボックスの他のオプションは、「通常」のルールでのみ実際に評価されます。

State を使用すると、ルールは監視におけるイベントのステータスを設定します。 ルールでは、この状態は「WARN 」または「CRIT 」になります。OK イベントを生成するルールは、特定のイベントを純粋に情報として表現する例外として興味深い場合があります。 そのような場合、これらのイベントを自動的に期限切れにする機能と組み合わせると便利です。

明示的なステータスを設定するだけでなく、さらに 2 つの動的なオプションがあります。(set by syslog) 設定は、syslog 優先度に基づいて分類を引き継ぎます。 これは、メッセージが送信者によってすでに使用可能として分類されている場合にのみ機能します。 syslog が直接受信したメッセージには、8 つの RFC 優先度のいずれかが含まれ、次のようにマッピングされます。

syslog メッセージに加えて、Windows イベントログからのメッセージ、およびターゲットシステムで Checkmkログウォッチプラグインによってすでに分類されているテキストファイルからのメッセージも、既製のステータスとして提供されます。 SNMP トラップについては、残念ながらこの機能は利用できません。

まったく別の方法として、テキスト自体に基づいてメッセージを分類することができます。 これは、(set by message text) 設定を使用して実行できます。

ここで設定されたテキストとの一致は、Text to match およびその他のルール条件がチェックされた後にのみ行われます。そのため、これらのチェックを繰り返し行う必要はありません。

設定されたパターンが 1 つも一致しない場合、イベントはUNKNOWN状態に戻ります。

Service Level フィールドの背後にある考え方は、組織内のすべてのホストおよびサービスには、一定の重要度があるということです。 これは、ホストまたはサービスの特定のサービス契約に関連付けることができます。 Checkmk では、ルールを使用して、このようなサービスレベルをホストおよびサービスに割り当て、たとえば、通知や自己定義のダッシュボードをそれに依存させることができます。

イベントは必ずしもホストやサービスと相関するわけではないため、イベントコンソールでは、ルールを使用してイベントにサービスレベルを割り当てることができます。 その後、このレベルを使用してイベントビューをフィルタリングすることができます。

デフォルトでは、Checkmk は 4 つのレベル（0（レベルなし）、10（シルバー）、20（ゴールド）、30（プラチナ））を定義しています。 この選択は、Global settings > Notifications > Service Levels で必要に応じて変更できます。 レベルは、この数字で並べ替えられ、相対的な重要度に応じて比較されるため、レベルを表す数字が重要です。

可視化に使用される連絡先グループは、イベントの通知にも使用されます。 ここでは、ルールを使用して、連絡先グループをイベントに明示的に割り当てることができます。 詳細については、監視の章をご覧ください。

アクションは、ホストおよびサービスのアラートハンドラーとよく似ています。 ここでは、イベントが開かれたときに、自己定義のスクリプトを実行することができます。 アクションの詳細については、以下のセクションで説明します。

Delete event immediately after the actions で設定できる自動削除 (= アーカイブ) により、イベントが監視にまったく表示されなくなります。 これは、一部のアクションのみを自動的にトリガーしたい場合や、後で検索できるように特定のイベントのみをアーカイブしたい場合に便利です。

イベントがキャンセルされたときに、アクションを自動的に実行することもできます。 イベントがキャンセルされると、アクションが実行される前に、イベント内のいくつかのデータフィールドが OK メッセージの値で上書きされることに注意してください。 これにより、OK メッセージの完全なデータがアクションスクリプトで使用可能になります。 さらに、この段階では、イベントの状態は「OK 」としてフラグが付けられます。 これにより、アクションスクリプトは上書きを検出し、エラーメッセージと OK メッセージに同じスクリプトを使用することができます (チケットシステムに接続する場合など)。

OK メッセージのデータにより、以下のフィールドが上書きされます。

その他のフィールドは、イベント ID を含め、変更されません。

同じルールで書き換えとキャンセルを使用する場合は、ホスト名またはアプリケーションの書き換えに注意する必要があります。 キャンセルすると、EC は、キャンセルメッセージが開いているイベントのホスト名およびアプリケーションと一致するかどうかを常にチェックします。 しかし、これらが書き換えられている場合、キャンセルは機能しません。

そのため、イベントをキャンセルする前に、イベントコンソールはホスト名とアプリケーションの書き換えをシミュレートして、関連するテキストを比較します。 これはおそらく、ご期待どおりの動作でしょう。

エラーメッセージと後の OK メッセージのアプリケーションフィールドが一致しない場合にも、この動作を利用できます。 この場合、アプリケーションフィールドを既知の固定値に書き換えるだけです。 これにより、実際にはこのフィールドは無視されることになります。

エラーメッセージと OK メッセージのテキストがまったく同じになる状況があります (残念ながら)。 ほとんどの場合、実際のステータスはテキストではなく、syslog 優先度でコード化されています。

この目的のために、Syslog priority to cancel event オプションがあります。 ここでは、たとえば、debug …​notice の範囲を入力します。 この範囲内のすべての優先度は、通常、OKステータスとみなされます。 このオプションを使用する場合でも、 Text to cancel event(s) フィールドに適切なテキストを入力する必要があります。そうしないと、同じアプリケーションに影響するすべてのOKメッセージがルールに一致してしまいます。

Count messages in interval オプションを使用すると、頻繁に発生するメッセージのチェックを有効にすることができます。

まず、[Time period for counting ] で期間を指定し、[Count until triggered] でイベントを開くメッセージの数を指定します。 上記の例では、1 時間に 10 件のメッセージに設定されています。 もちろん、これは 10 件の任意のメッセージではなく、ルールに一致するメッセージです。

通常、一致するすべてのメッセージをグローバルにカウントするのではなく、同じ「原因」を参照するメッセージのみをカウントするのが理にかなっています。 これを制御するために、Force separate events for different …​ で始まる 3 つのチェックボックスがあります。 これらは、以下の条件で一致するメッセージのみを一緒にカウントするように事前設定されています。

これにより、「1 時間に同じホスト、同じアプリケーション、同じサイトから 10 件以上のメッセージが受信された場合、...」などのルールを策定することができます。 このルールにより、複数の異なるイベントが生成される場合があります。

たとえば、3 つのチェックボックスをすべてオフにした場合、カウントはグローバルにのみ行われ、ルールは合計 1 つのイベントしか生成できなくなります。

ちなみに、カウントには 1 を入力するとよいでしょう。 そうすることで、「イベントストーム」を効果的に把握することができます。 たとえば、短期間に 100 件の同じ種類のメッセージが受信された場合でも、生成されるイベントは 1 件のみとなります。イベントの詳細には、最初のメッセージが発生した時刻が表示されます。

ケースが閉じられた場合、2 つのチェックボックスを使用して、新しいイベントを開くタイミングを定義できます。 通常、イベントが承認されると、それ以降にメッセージが受信された場合、カウントが新たに開始され、新しいイベントがトリガーされます。 この機能は、[Continue counting when event is acknowledged] で無効にすることができます。

Discontinue counting after time has elapsed オプションを有効にすると、比較期間ごとに常に個別のイベントが開かれます。 上記の例では、1 時間あたり 10 件のメッセージという閾値が指定されています。 このオプションを有効にすると、1 時間に最大 10 件のメッセージが、すでに開いているイベントに追加されます。 1 時間が経過すると、十分な数のメッセージが受信されている場合、新しいイベントが開かれます。

たとえば、この数を 1 に、時間間隔を 1 日に設定した場合、このメッセージタイプのイベントは 1 日に 1 件しか表示されません。

Algorithm の設定は、一見すると少し意外かもしれません。 しかし、現実的に考えてみましょう。 「1時間に10件のメッセージ」とは、実際にはどういう意味でしょうか？ それはどの1時間のことでしょうか？ 1 日の 1 時間ごとですか？ 最後の 1 分間に 9 件のメッセージが受信され、次の 1 分の間にさらに 9 件のメッセージが受信された場合、2 分間で 18 件のメッセージが受信されますが、1 時間あたりでは 10 件未満であるため、このルールは適用されません。 これはあまり合理的なルールとは言えません。 この問題には唯一の解決策はないため、Checkmk では「1 時間あたり 10 件」が正確に何を意味するのかについて 3 つの異なる定義を用意しています。

この問題には単一の解決策がないため、Checkmk では「1 時間あたり 10 件のメッセージ」の正確な意味について 3 つの定義を用意しています。

では、どのアルゴリズムを選択すべきでしょうか？

設定数に達していないイベントは潜在的ですが、オペレーターには自動的に表示されません。 これらは「counting 」フェーズにあります。 イベントビューの「phase 」フィルターを使用して、このようなイベントを表示することができます。

特定のメッセージの到着が問題であることを意味する場合と同じように、メッセージの欠落も問題であることを意味する場合があります。 特定のジョブからは、1 日に少なくとも 1 件のメッセージが到着すると予想されます。 このメッセージが到着しない場合、そのジョブは実行されていない可能性が高く、早急に修正する必要があります。

これと同様の設定は、Counting & Timing > Expect regular messages で構成できます:

カウントと同様に、メッセージの出現を予想する期間を指定する必要があります。 ただし、ここではまったく異なるアルゴリズムが使用されており、この点ではより理にかなっています。 期間は常に、定義された位置に正確に合わせられます。 たとえば、hour の間隔は、常に分と秒の 0 から開始されます。 次のオプションがあります。

なぜこんなに複雑なのでしょうか？ これは、偽アラームを回避するためです。 たとえば、バックアップから 1 日に 1 件のメッセージが送信されることを想定していますか？ バックアップのランタイムには必ず若干の誤差があるため、メッセージが正確に 24 時間間隔で受信されることはありえません。 たとえば、メッセージが深夜 0 時前後 1、2 時間の間に到着すると予想される場合、00:00 から 00:00 までの間隔よりも、12:00 から 12:00 までの間隔の方がはるかに現実的です。 ただし、メッセージが表示されなかった場合、通知は正午の 12:00 にのみ受信されます。

Merge with open event オプションは、同じメッセージが繰り返し表示された場合、既存のイベントが更新されるように事前設定されています。 これを変更して、毎回新しいイベントを開くようにすることができます。

Add new action （スクリプトの実行）ボタンを使用して、新しいアクションを作成できます。 次の例は、Execute Shell Script （シェルスクリプトの実行）タイプのアクションとして、単純なシェルスクリプトを作成する方法を示しています。 イベントの詳細は、環境変数を通じてスクリプトで利用できます。 たとえば、イベントの$CMK_ID 、$CMK_HOST 、フルテキスト$CMK_TEXT 、または最初のマッチグループ$CMK_MATCH_GROUP_1 などです。 使用可能な環境変数の完全なリストについては、インラインヘルプを参照してください。

Checkmk の古いバージョンでは、環境変数だけでなく、$TEXT$ などのマクロも使用でき、スクリプトが実行される前に置き換えられていました。 攻撃者が、Checkmk プロセスの権限で実行される特別に作成された UDP パケットを介してコマンドを注入する危険性があるため、マクロは使用しないでください。 マクロは、互換性の理由から現在もサポートされていますが、Checkmk の将来のバージョンで削除される可能性があります。

スクリーンショットに示されているサンプルスクリプトは、サイトディレクトリにtmp/test.out ファイルを作成し、そのファイルに、それぞれの最後のイベントに関する変数の具体的な値を含むテキストを書き込みます。

スクリプトは、以下の環境で実行されます。

スクリプトに待機時間がある場合は、at Linux スプールを使用して、スクリプトを非同期で実行することができます。 これを行うには、スクリプトを別のlocal/bin/myaction ファイルに作成し、at コマンドで起動します。

Send Email アクションタイプは、単純なテキストの電子メールを送信します。 実際には、mail コマンドラインコマンドを使用するなど、スクリプトでもこれを行うことができます。 しかし、この方法の方が便利です。Recipient email address およびSubject フィールドにもプレースホルダーを使用できることにご注意ください。

イベントは、アクティブな監視で設定されているかどうかに関係なく、どのホストからも送信されます。 結局のところ、syslog および SNMP ポートは、ネットワーク上のすべてのホストに対して開いています。 その結果、エイリアス、ホストタグ、連絡先などの拡張ホスト属性は、最初は使用できません。 このため、特に通知ルールの条件は、必ずしも期待どおりに機能しない場合があります。

たとえば、通知を行う場合、EC は、アクティブ監視内でイベントと一致するホストを見つけようとします。 これは、イベントの可視性と同じ手順で行われます。 そのようなホストが見つかった場合、そのホストから以下のデータが取得されます。

その結果、処理された通知のホスト名は、元のメッセージのホスト名と完全に一致しない場合があります。 ただし、アクティブ監視の通知テキストと同じ形式の通知テキストを使用すると、ホスト名に適用される条件を含む、統一された通知ルールの作成が簡単になります。

マッピングは、メッセージを受信した EC と同じサイトで実行されている監視コアにライブステータスクエリを送信することで、リアルタイムに行われます。 もちろん、これは、syslog メッセージ、SNMP トラップなどが、ホストがアクティブに監視されている Checkmk サイトに常に送信されている場合にのみ機能します。

クエリが機能しない場合、またはホストが見つからない場合は、代替データが受け入れられます。

アクティブな監視でホストを割り当てることができない場合、当然、通知に問題が発生します。 その理由としては、条件が適用されなくなる場合と、連絡先の選択が問題になる場合が考えられます。 このような場合、イベントコンソールからの通知は、独自のルールで具体的に処理されるように通知ルールを変更することができます。 この目的のために、EC 通知のみに一致させる、またはその逆で除外する、別の条件があります。

EC からの通知がアクティブ監視の通知システムを通過するには、EC をそのスキームに合わせて調整する必要があります。 そのプロセスでは、通知の典型的なデータフィールドができる限り効果的に入力されます。 ホストのデータがどのように決定されるかについては、先ほど説明しました。 その他のフィールドは次のとおりです。

前述のように、イベントの連絡先を自動的に決定できない場合があります。 そのような場合は、通知に使用する EC ルールで連絡先グループを直接指定することができます。Use in notifications （通知の連絡先グループ）ボックスを必ずチェックしてください。

Master control スナップインには、通知に関する中央スイッチがあります。 これは、EC によって転送される通知にも適用されます。

ホストの割り当てと同様に、EC によるスイッチの照会には、ローカル監視コアへのライブステータスアクセスが必要です。 照会が成功すると、イベントコンソールのログファイルに次のように表示されます。

イベントコンソールは、現在スケジュールダウンタイム中のホストを検出し、そのような状況では通知を送信しません。 ログファイルでは、次のように表示されます。

もちろん、このためには、アクティブな監視でホストが正常に検出されている必要があります。 検出に失敗した場合は、ホストはダウンタイムではないとみなされ、いずれの場合も通知が生成されます。

独自の通知スクリプト、特にイベントコンソールからの通知用スクリプトを作成する場合、元のイベントを説明するいくつかの追加変数を使用できます (通常どおり、プレフィックスNOTIFY_ でアクセスします)。

パフォーマンスを測定するには、サイドバーに「Event Console Performance 」という名前の別のスナップインがあります。 これは、通常どおり次のように含めることができます。

ここに表示される値は、過去 1 分間の平均値です。 数秒しか続かないイベントストームは、ここでは直接読み取ることができませんが、数値は多少平滑化されているため、読みやすくなっています。

最大パフォーマンスをテストするには、分類されていないメッセージのストームを人工的に生成します (テストシステムでのみ行ってください)。たとえば、テキストファイルの内容をイベントパイプに連続して書き込むシェルループを使用します。

スナップインの最も重要な測定値は、次の意味があります。

イベントコンソールが 1 秒間に処理できるメッセージの数は、Processing time per message で確認できます。 この時間は、通常、メッセージが処理されるまでに試行されるルールの数に関係しています。 ここでは、最適化のためにいくつかのオプションがあります。

さらに、syslog の優先度および機能に基づいて、EC で最適化が行われます。 優先度と機能の組み合わせごとに、その組み合わせのメッセージに関連するルールのみが含まれる個別のルールチェーンが内部的に作成されます。

優先度、機能、またはできればその両方に条件を含む各ルールは、これらのルールチェーンすべてに含まれるのではなく、最適な 1 つだけに含まれます。 つまり、syslog 分類が異なるメッセージについて、そのルールをチェックする必要はありません。

再起動後、~/var/log/mkeventd.log に、最適化されたルールチェーンの概要が表示されます。

上記の例では、いずれの場合も 67 個のルールをチェックする必要があることがわかります。daemon 施設からのメッセージには 89 個のルールが関連し、daemon/emerg の組み合わせのみ 120 個のルールをチェックする必要があります。 優先度または施設に関する条件を含む各ルールにより、67 個からその数がさらに減少します。

もちろん、これらの条件は、関連するメッセージが確実に満たす場合にのみ設定してください。

イベントコンソールには、「オーバーフロー」に対する自動保護機能があります。 これにより、ホストごと、ルールごと、およびグローバルに、現在のイベントの数が制限されます。 開いているイベントだけでなく、delayed やcounting などの他のフェーズのイベントもカウントされます。 アーカイブされたイベントはカウントされません。

これにより、ネットワークの体系的な問題により、何千もの重要なイベントが殺到し、イベントコンソールが「シャットダウン」してしまうような状況から保護されます。 これにより、メインメモリに過大なイベントを保存することによるイベントコンソールのパフォーマンスの低下を防ぐことができます。 また、オペレーターの概要表示も（ある程度）保護され、ストームの一部ではないイベントは表示されたままになります。

制限に達すると、次のいずれかのアクションが実行されます：

制限および制限に達した場合の影響は、イベントコンソールの設定で、Limit amount of current events で定義します。 次の図は、デフォルトの設定を示しています。

…​create overflow event で値を有効にしている場合、制限に達すると、エラー状況をオペレーターに通知する単一の人工イベントが作成されます。

さらに、…​notify contacts の値を有効にしている場合、Checkmk 通知によって適切な連絡先に通知されます。 この通知は、Checkmk通知ルールに従って送信されます。 これらのルールは、イベントコンソールの連絡先選択に従う必要はなく、それを変更することができます。 次の表は、Notify all contacts of the notified host or service （デフォルト）を設定した場合に選択される連絡先を示しています。