アラートルール

最終更新日: 26 年 2024 月 XNUMX 日

アラート ルールは、どのアラートがアラート通知としてルーティングされるか、およびそれらがどのようにルーティングされるかを決定します。 着信アラートは、アラート レベル、リソース属性 (名前、グループ、またはプロパティ)、および LogicModule/datapoint 属性に基づいてルールのフィルターに一致するまで、すべてのルールを優先順位 (最小番号から開始) でフィルター処理されます。 一致が発生すると、ルールの処理が停止し、アラートが指定されたエスカレーション チェーンにルーティングされ、確認またはクリアされるまでエスカレーション チェーンの段階を進みます。

アラート ルールに一致しないアラートはルーティングされませんが、LogicMonitor ポータルに表示されます。

注: アラートがアラート ルールに一致しても、ルーティングされない可能性があります。 このシナリオは、アラート ノイズをインテリジェントに削減する LogicMonitor の AIOps 機能の XNUMX つを使用して、アラート通知の抑制が有効になっている場合に発生します。 詳細については、次を参照してください。 動的しきい値の有効化 データポイントと 根本原因分析の有効化.

LogicMonitor ポータルの設定を使用して、アラート ルールを追加、編集、または削除できます。 これらの設定により、アラート ルールが適用されるアラートと、アラート ルールが適用された後のアラートのルーティング方法と管理方法が決まります。

アラート ルールの追加

  1. MFAデバイスに移動する  設定 > アラートルール.
  2. 選択 Add.
  3. に一意の名前を入力します 名前 フィールド。
  4.  アラートの優先度 フィールドに数値を入力して、アラート ルールが他のルールに対して評価される優先順位を決定します。
    値「1」は最高の優先度を表します。 値は最大 100 桁で構成できます。 デフォルト値は「XNUMX」です。
    トリガーされたアラートがアラート ルールと一致すると、それ以上のアラート ルールは評価されません。

推奨事項:

  • 複数のルールが同じ優先度を持つことを避けるために、デフォルト値を変更します。 XNUMX つ以上のアラート ルールの優先度が同じ場合、ルールは非決定論的に適用されます。
  • 既存のアラート ルールの番号を付け直さなくても新しいアラート ルールを挿入できるように、アラート優先度の元のセットに間隔 (たとえば、10、20、および 50 の間隔) で番号を付けます。
    1. ノーザンダイバー社の レベル フィールドのドロップダウン メニューで、アラート条件の作成時に割り当てた重大度レベルに対応するレベルを選択します。
      指定されたレベルに対応する重大度レベルを持つアラートは、このアラート ルールに一致します。

    推奨事項: アラートに依存するサードパーティの統合を環境で利用している場合は、潜在的なすべてのアラート レベルの重大度に一致するようにアラートを構成します。

    1. (オプション) トリガーされたアラートがアラート ルールを適用するために一致する必要がある次の設定の値を入力します。
      • グループ— リソースが属する必要がある XNUMX つ以上のデバイスまたは Web サイト グループを指定します。
      • リソース/ウェブサイト- アラートをトリガーするリソースまたは Web サイトを XNUMX つ以上指定します。
        両方の設定でグロブ式とワイルドカード マッチングを使用できます。 詳細については、次を参照してください。 グロブ式

    注意:

  • グループ レベルのクラスタ アラートは、疑似デバイス「クラスタ」を使用します。
  • 値が入力されていない場合は、値にワイルドカード値 (*) が自動的に追加されます。 これにより、プロパティが一致する任意のリソースに関するアラートをアラート ルールで考慮することができます。
    1.  リソースプロパティフィルター アラートがアラート ルールに一致するためにリソースまたは Web サイトが持つ必要がある XNUMX つ以上のプロパティ値を指定するには、次の手順を実行します。
      1. 現在地に最も近い さらに アイコン(+).
      2. プロパティ名を 名前 フィールド。
        最大 XNUMX つのプロパティを入力できます。 複数のプロパティは「AND」演算子で結合されます。
        プロパティ値は、グロブ式とワイルドカード マッチングをサポートしています。 詳細については、次を参照してください。 グロブ式.
        LogicMonitor は、デバイス プロパティの一致結果のみをオートコンプリートしようとします。 Web サイトのプロパティ名は手動で入力する必要があります。

    重要: プロパティ名は大文字と小文字が区別され、完全に入力する必要があります。

    1.  ロジックモジュール フィールドで、アラート ルールに一致するためにアラートをトリガーする必要がある LogicModules を指定します。
      または、ワイルドカード (*) を入力して、すべての LogicModules を示すこともできます。
      glob 式とワイルドカード マッチングを使用できます。 詳細については、次を参照してください。 グロブ式.
      LogicModule を検索するための検索オプションは、 として表示 LogicModule レコードのフィールド。 詳細については、次を参照してください。 LogicModulesの概要.
    1.  インスタンス フィールドで、アラート ルールに一致するためにアラートをトリガーする必要があるインスタンスを指定します。
      または、ワイルドカード (*) を入力してすべてのインスタンスを示すこともできます。
      glob 式とワイルドカード マッチングを使用できます。 詳細については、次を参照してください。 グロブ式.

    注意:

  • インスタンスは、glob 式のインスタンス名だけではなく、DataSource-Instance 名によって識別されます。 たとえば、インターフェイス (64 ビット) DataSource のインスタンスがリソース ツリーに「enp2s0」として表示される場合、アラート ルールでは「snmp64_If-enp2s0」として識別されます。 インスタンスを一致させるには、「enp*」ではなく、グロブ式「*enp*」を使用する必要があります。 リソース ツリーでインスタンスを選択し、詳細ペインのタイトルで DataSource-Instance 名を確認します。
  • ここで確立されたインスタンスフィルターは、インスタンスに関連付けられておらず、デバイスのみに関連付けられているため、EventSourceおよびJobMonitorアラートによって無視されます。
    1.  データポイント フィールドで、アラート ルールに一致するためにアラートをトリガーする必要があるデータポイントを指定します。
      または、ワイルドカード (*) を入力して、すべてのデータポイントを示すこともできます。
      glob 式とワイルドカード マッチングを使用できます。 詳細については、次を参照してください。 グロブ式.
      ここで確立されたデータポイントフィルターは、EventSourceおよびJobMonitorアラートによって無視されます。これらのタイプのアラートは、データポイントの状態によってトリガーされないためです。
    1. 有効にします アラートがクリアされたときに通知を送信する 最初のアラート通知の受信者は、アラートがクリアされたときに通知を受け取ることもできます。 このオプションは、SDT (スケジュールされたダウンタイム) が後でアクティブ化され、問題に関する他のルーティングされたアラート通知を一時的に抑制する場合にも、アラート通知が確実に配信されるようにします。

    注: SDT ステータスに関係なく、アラートがクリアされたときに通知を受け取ることは、DataSource によってトリガーされたアラートにのみ適用されます。 トリガーするインスタンスまたはリソースが SDT に配置されている場合、EventSource の通知は配信されません。

    重要: アラートに依存するサードパーティ統合を環境で利用している場合は、このオプションを有効にして、LogicMonitor がサードパーティ ツールにアラートをルーティングできるようにします。 これは、アラートに SDT ステータスがあるかどうかに関係なく適用されます。 この設定により、アラートがクリアされたときに LogicMonitor がサードパーティ統合でインシデントをクローズできることも保証されます。

    1. 有効にします AcknowledgeまたはSDTのステータス通知を送信します アラートが確認されたとき、または SDT に入れられたときに、最初のアラート通知の受信者が通知を受信できるようにします。
    2.  エスカレーション間隔(分) フィールドに、アラートがエスカレーション チェーンの次の段階にエスカレートされるまでの経過時間を分単位で入力します。 アラートが確認またはクリアされると、エスカレーションは停止します。
      エスカレーション チェーンにステージが XNUMX つしかない場合、アラート通知は、確認されるかクリアされるまで、そのステージに繰り返し送信されます。 同様に、通知が複数段階のエスカレーション チェーンの最後に到達した場合、アラートは確認されるかクリアされるまで繰り返し最終段階に送信されます。

    重要: 環境がアラートに依存するサードパーティの統合を利用している場合は、「0」を入力します。 これにより、アラート通知がエスカレーション チェーンの最初のステージに一度ルーティングされ、手動でアラートをエスカレートしない限り再送信されません。 インテグレーションにアラート通知を繰り返し送信すると、サードパーティ ツールで動作が重複する可能性があります。

    1. ノーザンダイバー社の エスカレーションチェーン ドロップダウン メニューで、アラートをルーティングするエスカレーション チェーンを選択します。 詳細については、次を参照してください。 エスカレーションチェーン.
    2. 選択 Save.

    アラート ルールを構成するためのベスト プラクティス

    アラート ルールの構成は、環境に大きく依存します。 たとえば、環境で LM 統合を利用している場合は、アラート ルールを構成するときにアラートのライフサイクルを考慮する必要があります。 アラート ルールを構成するには、次のベスト プラクティスを使用します。

    • 早急な対応が必要なアラートのみをルーティングする— アラート ルーティングは、緊急レベルのアラートなど、すぐに対応する必要があるアラートに適しています。 一部のアラート (警告アラートなど) はすぐに対応する必要がないため、レポートで確認する方が適切です。 すべてのアラートを特定のグループに送信する「キャッチオール」ルールを使用する代わりに、特定のアラートのみがルーティングされるようにアラート ルールを設定できます。 ただし、アラートを無視していないことを確認してください。 レポートでルーティングされていないアラートを確認する必要があります。
      LogicMonitor は、アラート ノイズをインテリジェントに削減することを目的として、非常に的を絞ったベースでアラート通知を抑制する AIOps 機能も提供します。 詳細については、次を参照してください。 データポイントの動的しきい値の有効化 および 根本原因分析の有効化.
      すべてのアラートをルーティングする場合は、警告アラートのエスカレーション間隔が「0」のルールを作成することを検討してください。 これにより、すべての警告アラートが除外され、送信されます 1回だけ 指定されたエスカレーションチェーンの最初の段階に移動します。 次に、エラーアラートとクリティカルアラートのみを組織内のユーザーにルーティングする他のルールを設定できます。
    • 特定のルールに高い優先度を与える— 特定のルールの優先度を高く (数字を小さく) し、一般的なルールの優先度を低く (数字を大きく) するようにルールを編成します。 特定のルールの基準を満たさないアラートは、一般的なルールによってキャッチされます。
    • 優先順位にインデックスを付ける— 大規模な導入では、組織内のグループに対応するように優先度をインデックス化できます。 たとえば、開発関連のルールの優先度を 100 に設定し、生産関連のルールの優先度を 200 に設定し、QA 関連のルールの優先度を 300 に設定できます。 すべてのルールが特定のデバイス グループからのアラートのみに一致するように設定されていることを確認すると、各部門は優先度の範囲内で作業して、他の部門のアラートに影響を与えることなく、グループのルーティングをカスタマイズできます。
    • 優先レベル間に大きなギャップを残す— 優先度レベルが順番に近すぎる場合は、既存のルールの優先度を編集して、新しいルール用のスペースを空ける必要がある場合があります。
    • アラート ルールのテスト— アラート配信をテストして、アラートが意図したとおりにルーティングされていることを確認します。 詳細については、次を参照してください。 アラート配信のテスト.
    • (LM 統合の場合) アラート ライフサイクル全体で単一のアラート ルールを使用する— アラート ルールがエスカレーション チェーンの一部としてアラート統合への配信を参照する場合、そのルールは、すべての潜在的なアラート レベル重大度に一致するように構成する必要があります。 これにより、サードパーティ ツールでの動作の重複や孤立したインシデントが防止されます。
      LogicMonitor がアラート情報をサードパーティ ツールに配信する場合、LogicMonitor はそのアラートの外部参照 (チケット ID 番号など) を探します。 この参照は、サードパーティ ツールによって LogicMonitor に返されます。 LogicMonitor はこの参照を取得し、アラート ルール ID と統合 ID で構成されるキーを使用してアラートに関連付けます。 次に、このキーを使用して、そのアラートの今後のすべてのアクティビティを元のターゲット統合オブジェクトに結び付けます。
      アラートの外部参照が見つからない場合、統合によって新しいオブジェクトが作成されます。 外部参照が見つかった場合、統合によって既存のオブジェクトが更新されます。

    アラートルールの設定例

    次のスクリーンショットは、アラート ルールのサンプル セットを示しています。

    最も優先度の高いルールは「Production Warning Alerts」です。 運用中の子グループで重大度レベルが「警告」のすべてのアラートを除外します。 このルールは、アラートが確認されるかクリアされるまで、30 分ごとに (LM 統合を使用して) メッセージング ツールにアラート通知を送信します。

    15 番目に優先度の高いルールは、「本番データベース アラート」です。 サーバーグループの下の子グループ内のデバイスの名前に「SQL」という用語が含まれるデータソースのアラートのみに一致します。 「警告」アラートは最初のルールによって除外されるため、このルールは重大度レベルが「エラー」または「クリティカル」のデータベース アラートのみをピックアップします。 「DB 管理者」エスカレーション チェーンの第 15 段階の受信者に最初に通知されます。アラートが確認されず、XNUMX 分以内にクリアされない場合は、第 XNUMX 段階の受信者に送信されます。 XNUMX 分経過しても誰もアラートを確認せず、アラートがクリアされていない場合、アラートはステージ XNUMX にエスカレートします。 ステージ XNUMX には受信者がいないため、誰にも通知されません。 アラート通知は、アラートが確認されるかクリアされるまでステージ XNUMX に繰り返し送信されるため、最後のステージを空にすることで、アラートがステージ XNUMX を過ぎてエスカレートした後、誰にも通知されないようにすることができます。

    注: いずれかのステージでアラート通知をチケット発行システムに送信する場合は、再送信間隔がゼロであるか、別の配信方法で後続のステージがあることを確認してください。 これにより、同じ条件に対する複数のチケットが防止されます。

    次に優先度の高いルールは「Production Server Alerts」です。 これは、servers グループの下の任意の子グループ内の任意のリソースについて、重大度レベルが「Error」または「Critical」のアラートと一致します。 このルールは「本番データベース アラート」ルールよりも優先度が低い (つまり、数値が高い) ため、SQL データソース以外から発生したエラーまたは重大なアラートは、代わりにこのルールに一致します。 このアラート ルールは、オーバーフローをキャッチします。つまり、データベース チームに送信されないものはすべて、サーバー チームによって取得されます。

    XNUMX 番目のルールは、ネットワーク グループの子グループ内のリソースについて、重大度レベルが「エラー」または「クリティカル」のすべてのアラートをルーティングします。 重大度レベルが「警告」のアラートはすべて除外されるため、このルールは、データベースまたはサーバー チームにルーティングされないエラーおよび重大なアラートをキャッチします。

    記事上で