アラートルール
最終更新日: 04 年 2024 月 XNUMX 日アラート ルールは、どのアラートがアラート通知としてルーティングされるか、およびそれらがどのようにルーティングされるかを決定します。 着信アラートは、アラート レベル、リソース属性 (名前、グループ、またはプロパティ)、および LogicModule/datapoint 属性に基づいてルールのフィルターに一致するまで、すべてのルールを優先順位 (最小番号から開始) でフィルター処理されます。 一致が発生すると、ルールの処理が停止し、アラートが指定されたエスカレーション チェーンにルーティングされ、確認またはクリアされるまでエスカレーション チェーンの段階を進みます。
アラート ルールに一致しないアラートはルーティングされませんが、LogicMonitor ポータルに表示されます。
ご注意： アラートがアラート ルールに一致しても、ルーティングされない可能性があります。 このシナリオは、アラート ノイズをインテリジェントに削減する LogicMonitor の AIOps 機能の XNUMX つを使用して、アラート通知の抑制が有効になっている場合に発生します。 詳細については、次を参照してください。 動的しきい値の有効化 データポイントと 根本原因分析の有効化.
LogicMonitor ポータルの設定を使用して、アラート ルールを追加、編集、または削除できます。 これらの設定により、アラート ルールが適用されるアラートと、アラート ルールの適用後にアラートがどのようにルーティングおよび管理されるかが決まります。 さらに、LogicMonitor がテーブルにアラート ルールを表示する方法をカスタマイズできます。
アラート ルールの追加
- MFAデバイスに移動する 設定 > 警告 > アラートルール.
- 選択 アラートルールの追加
. - に一意の名前を入力します 名前 フィールド。
- 優先 フィールドに数値を入力して、アラート ルールが他のルールに対して評価される優先順位を決定します。
値「1」は最高の優先度を表します。 値は最大 100 桁で構成できます。 デフォルト値は「XNUMX」です。
トリガーされたアラートがアラート ルールと一致すると、それ以上のアラート ルールは評価されません。
推奨事項：
- ノーザンダイバー社の レベル フィールドのドロップダウン メニューで、アラート条件の作成時に割り当てた重大度レベルに対応するレベルを選択します。
指定されたレベルに対応する重大度レベルを持つアラートは、このアラート ルールに一致します。
推奨事項： アラートに依存するサードパーティの統合を環境で利用している場合は、潜在的なすべてのアラート レベルの重大度に一致するようにアラートを構成します。
- (オプション) トリガーされたアラートがアラート ルールを適用するために一致する必要がある次の設定の値を入力します。
- グループ— リソースが属する必要がある XNUMX つ以上のデバイスまたは Web サイト グループを指定します。
- リソース/ウェブサイト- アラートをトリガーするリソースまたは Web サイトを XNUMX つ以上指定します。
両方の設定でグロブ式とワイルドカード マッチングを使用できます。 詳細については、次を参照してください。 グロブ式.
注意：
- リソースプロパティフィルター アラートがアラート ルールに一致するためにリソースまたは Web サイトが持つ必要がある XNUMX つ以上のプロパティ値を指定するには、次の手順を実行します。
- プロパティ名を 名前 フィールド。
最大 XNUMX つのプロパティを入力できます。
LogicMonitor は、デバイス プロパティの一致結果のみをオートコンプリートしようとします。 Web サイトのプロパティ名は手動で入力する必要があります。
重要： プロパティ名は大文字と小文字が区別され、完全に入力する必要があります。 - プロパティに必要な値を 値 フィールド。
プロパティ値は、グロブ式とワイルドカード マッチングをサポートしています。 詳細については、次を参照してください。 グロブ式.
- プロパティ名を 名前 フィールド。
- ロジックモジュール フィールドで、アラート ルールに一致するためにアラートをトリガーする必要がある LogicModules を指定します。
または、ワイルドカード (*) を入力して、すべての LogicModules を示すこともできます。
glob 式とワイルドカード マッチングを使用できます。 詳細については、次を参照してください。 グロブ式.
LogicModule を検索するための検索オプションは、 として表示 LogicModule レコードのフィールド。 詳細については、次を参照してください。 LogicModulesの概要.
- インスタンス フィールドで、アラート ルールに一致するためにアラートをトリガーする必要があるインスタンスを指定します。
または、ワイルドカード (*) を入力してすべてのインスタンスを示すこともできます。
glob 式とワイルドカード マッチングを使用できます。 詳細については、次を参照してください。 グロブ式.
注意：
- データポイント フィールドで、アラート ルールに一致するためにアラートをトリガーする必要があるデータポイントを指定します。
または、ワイルドカード (*) を入力して、すべてのデータポイントを示すこともできます。
glob 式とワイルドカード マッチングを使用できます。 詳細については、次を参照してください。 グロブ式.
ここで確立されたデータポイントフィルターは、EventSourceおよびJobMonitorアラートによって無視されます。これらのタイプのアラートは、データポイントの状態によってトリガーされないためです。
- トグル アラートがクリアされたときに通知を送信する 最初のアラート通知の受信者が、アラートが解除されたときにも通知を受信できるようにするためのスイッチです。 このオプションにより、その後 SDT (スケジュールされたダウンタイム) がアクティブ化されて、問題に関してルーティングされた他のアラート通知が一時的に抑制された場合にも、アラート通知が確実に配信されます。
ご注意： SDT ステータスに関係なく、アラートがクリアされたときに通知を受け取ることは、DataSource によってトリガーされたアラートにのみ適用されます。 トリガーするインスタンスまたはリソースが SDT に配置されている場合、EventSource の通知は配信されません。
重要： アラートに依存するサードパーティ統合を環境で利用している場合は、このオプションを有効にして、LogicMonitor がサードパーティ ツールにアラートをルーティングできるようにします。 これは、アラートに SDT ステータスがあるかどうかに関係なく適用されます。 この設定により、アラートがクリアされたときに LogicMonitor がサードパーティ統合でインシデントをクローズできることも保証されます。
- トグル AcknowledgeまたはSDTのステータス通知を送信します アラートが確認されたとき、または SDT に入れられたときに、最初のアラート通知の受信者が通知を受信できるように切り替えます。
- エスカレーション間隔（分） フィールドに、アラートがエスカレーション チェーンの次の段階にエスカレートされるまでの経過時間を分単位で入力します。 アラートが確認またはクリアされると、エスカレーションは停止します。
エスカレーション チェーンにステージが XNUMX つしかない場合、アラート通知は、確認されるかクリアされるまで、そのステージに繰り返し送信されます。 同様に、通知が複数段階のエスカレーション チェーンの最後に到達した場合、アラートは確認されるかクリアされるまで繰り返し最終段階に送信されます。
重要： 環境がアラートに依存するサードパーティの統合を利用している場合は、「0」を入力します。 これにより、アラート通知がエスカレーション チェーンの最初のステージに一度ルーティングされ、手動でアラートをエスカレートしない限り再送信されません。 インテグレーションにアラート通知を繰り返し送信すると、サードパーティ ツールで動作が重複する可能性があります。
- ノーザンダイバー社の エスカレーションチェーン ドロップダウン メニューで、アラートをルーティングするエスカレーション チェーンを選択します。 詳細については、次を参照してください。 エスカレーションチェーン.
- 選択 Save.
テーブル設定のカスタマイズ
- MFAデバイスに移動する 設定 > 警告 > アラートルール.
- 選択
. - 以下をせよ：
- 列を並べ替えるには、
必要な順序にドラッグします - 列を表示または非表示にするには、
.
- 列を並べ替えるには、
アラート ルールを構成するためのベスト プラクティス
アラート ルールの構成は、環境に大きく依存します。 たとえば、環境で 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 番目のルールは、ネットワーク グループの子グループ内のリソースについて、重大度レベルが「エラー」または「クリティカル」のすべてのアラートをルーティングします。 重大度レベルが「警告」のアラートはすべて除外されるため、このルールは、データベースまたはサーバー チームにルーティングされないエラーおよび重大なアラートをキャッチします。