25.2. アラート条件

この 条件 は、特定のしきい値を超えるリソースの状況、イベント、またはレベルです。基本的に、条件はリソースの「正常な」動作またはパフォーマンスにパラメーターを設定します。この境界を超えると、JBoss ON はアラートを発行します。これは、望ましくないレベル、イベント、または繰り返し発生するメトリック読み取りに変更したメトリクスの値になります。

アラート定義を使用したアラートは、個別のリソースまたはリソースの互換性のあるグループに対して定義されます。アラート定義は、アラートをトリガーする条件と、トリガーする必要のある通知のタイプおよび設定を指定します。

アラートが登録されると、アラートはトリガーされたアラート定義（アラート状態を識別する）と、アラートの事前処理を行うメトリクスまたはイベント値を特定します。

アラート条件は、What、who 、 および where の 4 つの質問 に 回答します。アラート を トリガーするしきい値または 条件 です（たとえば、空きメモリーが特定の時点を下回る）。定義された組み込まれた ルール を使用してアラートを送信する頻度またはタイミングを設定する 場合。また、管理者にアラートの 通知 方法を制御する ユーザー および 場所。

1 つの条件でアラートを発行できる場合や、アラート定義では、複数の条件が同時に満たされる場合にのみアラートを発行する必要があります。これにより、アラートの発行時に非常に粒度の細かい制御が可能になり、アラート情報がより重要かつ適切なものになります。

条件は、に一覧表示されている検出可能な監視またはシステムメトリックを基にでき 「アラートの調整の理由」 ます。これらのアラート条件は、そのタイプのリソースで利用可能なモニタリングメトリクスに直接対応します。各リソースタイプに使用できるすべてのメトリクスは、「リソースモニタリングリファレンス」に一覧表示さ 『れます』。

アラートは、監視情報に基づきます。これは、管理者が通知を受け取るか、特定のイベントまたはメトリクスの値が発生した場合に実行するアクションを定義するエクステンションです。

アラートをトリガーするモニタリングポイントはアラート状態です。最も分かりやすく、アラート状態は単一のイベントまたは読み取りです。X が発生した場合は、アラートがトリガーされます。

実際、X はアラートを保証するほど不十分な場合や、リソースの状態を適切に記述できない場合があります。異なる条件で同じ応答が必要となる場合や、複数の条件が true の場合のみ重要となる場合があります。アラートは、これらの条件間で確立された関係で複数の条件を定義できるため、柔軟性が非常に高くなります。

次のレベルの複雑さは、X または Y のいずれかが true の場合にアラートを送信することです。アラート定義では、これは論理 OR の ANY オプションです。アラート定義はこれらの条件のいずれかをチェックしますが、それらの条件は相互に関連しません。

最後の複雑さのレベルは、アラートの発行のために条件が相互に関連する必要がある場合です。これは、論理 AND である ALL オプションです。アラートを発行するには、X と Y の両方が必要です。この場合、ある条件が発生すると、サーバーはその定義をロックし、2 つ目の条件が発生するまで待機を開始します。2 つ目の条件が発生すると、アラートが発行されます。

AND 演算子は異なるメトリクスに対して非常に有効ですが、条件が同時に発生する必要がないため、単純な AND 演算子は 同じ メトリクスに意味を持ちません。

たとえば、Tim（IT 管理者）では、ユーザーの負荷が │ から 60% の間にある場合に限りアラートの発行を希望します。これは、プラットフォームの負荷をわずかに増やすことを示します。AND 演算子の使用を試みると、負荷が │（上記の │ 条件を 3 回）上で増加し、15% にフォールバックすると、（以下の 60% 条件未満の 60% 条件がトリガー）にフォールバックすると、異常値が返されます。

この場合、Tim は range 条件を使用します。範囲には、指定された境界内にある同じメトリクスの 2 つの値が必要です。範囲には、内部の値(40 ~ 60%)を指定するか、または外部範囲（low └ および 60%）を指定できます。

イベント(20章イベント)はフィルターされたログメッセージです。JBoss ON の特定のリソースは、プラットフォームや JBoss EAP サーバーなどのエラーログを維持します。JBoss ON では、これらのエラーログをスキャンして、特定のパターンに一致する特定の重大度またはイベントのイベントを検出できます。これにより、JBoss ON の管理者は、重要なエラーメッセージを特定し、表示できます。

JBoss ON はログイベントを検出できるため、JBoss ON はログイベントをアラートできます。イベントベースの状況には、ログファイルメッセージの重大度と、オプションで特定のメッセージと照合するために使用するパターンが必要です。

重大度が「重大」のイベントに重大度を設定するアラートのみを設定します。これは、致命的なエラーや致命的なエラーに役に立ち、これは比較的頻度がないため、すぐに注意を促す必要があります。

依存関係はアラート状態を定義しませんが、JBoss ON サーバーに対して定期的な条件の処理方法を指示します。

アラートは、条件が満たされるたびにアラートを発行するか、管理者が承認するまでアラートを発行して無効にすることができます。状態 を破損させると、継続中の単一の状況に対して、複数のアラートおよび通知が送信されるのを防ぐのに役立ちます。

たとえば、Tim(IT Guy)は、プラットフォーム CPU の使用率が 50% を超えるかどうかをユーザーに通知するためにアラートを設定します。監視スキャンが実行されるたびに、メトリクスは再び true と判断され、新規インスタンスおよび個別インスタンスとして処理されます。メトリクススケジュールが 10 分間設定され、アラートに応答するのに 1 時間かかる場合、応答する前に 6 つまたは 7 つのアラート通知がある可能性があります。アラート応答のみがメールである場合、これは問題ではありません。

しかし、Tim(Tim)の IT Guy に、EAP 接続数が特定の時点よりも大きい場合に新しい JBoss サーバーを作成するアラート応答がある場合に、実際に 1 回実行すべき場合は、同じ応答が 6 回または 7 回取得され、条件が実際に解決されます。

依存関係は、別のアラートをトリガーする前に条件を評価する方法についてのもう 1 つの命令セットです。これは、これらのモニタリングデータを解釈する方法を JBoss ON に指示します。

同じ確認された状態に対してアラート通知が送信される頻度を制限するには、いくつかの方法があります。1 つの方法では、破損したルールがあります。別の方法として、アラートの初回起動時にアラートを無効にし、管理者が手動で実行するか、または 条件自体がリセットされた場合にのみアラートを再度有効にします。2 番目のオプション - 無効にしてからリセットする - アラートを回復します。

リカバリーアラートは 、実際には、条件の変更時に関連するアラートを無効にし、有効にするために調整を行うアラートのペアです。

いくつかのワークフローは、復旧アラートで一般的に使用されます。

たとえば、Alert A は、リソースの可用性がダウンするとアラートをトリガーします。Alert A が発生すると、それ自体が無効（または有効化）されます。Alert B は、リソースの可用性が起動するとアラートを出力します。Alert B も実行すると、それ自体を無効にし、A を復旧します。

リカバリーアラートは、問題が発生してから、解決時に管理者に通知します。可用性の例では、最初のアラートにより、管理者はリソースがオフラインであることを確認できますが、2 つ目のアラートにより、そのリソースがオンラインに戻ることを管理者が通知します。

プライマリーメールサーバー mail-server-a.example.com があり、オフライン時のみ mail-server-b.example.com オンラインにしたいだけです。その後、戻るときには予約の mail-server-a 状態に戻したいと考え mail-server-a ます。