サポートセンターホーム


アラートルール

概要

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

アラートがアラートルールと一致しない場合、アラートはルーティングされませんが、LogicMonitorインターフェイスに表示されます。

注意: アラートがアラートルールに一致する可能性がありますが、それでもLogicMonitorのインターフェイスを超えてルーティングされない可能性があります。 このシナリオは、アラートノイズをインテリジェントに低減するために機能するLogicMonitorのAIOps機能のXNUMXつを介してアラート通知抑制が有効になっている場合に発生します。 詳細については、を参照してください。 データポイントの動的しきい値の有効化 影響により 根本原因分析の有効化 それぞれ。

アラートルールの追加または編集

アラートルールを追加、編集、または削除できます。 設定| アラートルール あなたのアカウントで。 次に示す(そして説明する)ように、アラートルールを構成するために確立する必要のあるいくつかの設定があります。 これらの設定は、アラートルールが適用されるアラート、およびアラートルールが適用された後のアラートのルーティングと管理の方法を決定します。

お名前

メディア お名前 フィールドに、アラートルールの名前を入力します。 この名前は、他のすべてのアラートルールの中で一意である必要があります。

アラートの優先度

メディア アラートの優先度 フィールドに数値の優先度値を入力して、アラートルールが評価される順序を決定します(他のすべてのアラートルールと比較して)。 「1」の値は最高の優先度を表します。 値は最大XNUMX桁で構成できます。

トリガーされたアラートがアラートルールと一致すると、それ以上のアラートルールは評価されません。 既存のアラートルールに番号を付け直すことなく新しいアラートルールを簡単に挿入できるように、元のアラート優先度のセットに間隔(10、20、50などの間隔)で番号を付けることをお勧めします。

注意: 新しいルールを作成するとき、このフィールドのデフォルトは「100」ですが、このデフォルト値をそのままにしないでください。そうしないと、複数のルールが同じ優先度を持つという望ましくない状況になります。 XNUMXつ以上のアラートルールの優先度が同じである場合、適用されるルールの選択は非決定性です。

レベル

から利用可能なレベル レベル フィールドのドロップダウンメニューは、アラート条件の作成時に割り当てた重大度レベルに対応しています。 ここで指定されたレベルに対応する重大度レベルのアラートのみが、このアラートルールに一致します。

注意: 作成しているアラートルールが、それに関連付けられたエスカレーションチェーンによって確立されたアラート統合に配信される場合は、すべての潜在的なアラートレベルの重大度に一致するようにここで構成する必要があります。 アラートルールをアラート統合に関連付けるためのガイドラインの詳細については、を参照してください。 アラート統合の概要.

グループ

メディア グループ フィールドで、アラートがこのルールに一致するためにリソースまたはWebサイトが属している必要があるXNUMXつ以上のデバイス/ Webサイトグループを指定します。 グロブ式 このフィールドでは、ワイルドカードマッチングがサポートされています。 グループでフィルタリングしたくない場合は、このフィールドを空白のままにしてください。

リソース/ウェブサイト

メディア リソース/ウェブサイト フィールドに、このアラートルールが一致するために、アラートがトリガーされる必要があるXNUMXつ以上のリソース(デバイス、クラウドリソースなど)および/またはWebサイトを指定します。 グループレベルのクラスターアラートは、疑似デバイスの「クラスター」を使用することに注意してください。 グロブ式 ここでは、ワイルドカードマッチングがサポートされています。 リソースやWebサイトでフィルタリングしたくない場合は、このリストを空のままにしておくことができます。

リソースプロパティフィルター

クリックします。 + 「リソースプロパティフィルター」見出しの下にあるアイコン。このアラートルールが一致するためにリソースまたはWebサイトが所有する必要があるXNUMXつ以上のプロパティ値を指定します。 プロパティ名は、大文字と小文字を区別して完全に入力する必要があります。 プロパティ値のサポート グロブ式 およびワイルドカードマッチング。

プロパティ名を入力すると、LogicMonitorは一致する結果をオートコンプリートしようとします。 ただし、現在の制限により、検索結果にはデバイスのプロパティのみが表示されます。 これは、プロパティフィルタをWebサイトに適用できないことを意味するのではなく、Webサイトのプロパティ名全体を手動で入力する必要があることだけを意味します。

注意: 最大XNUMXつのプロパティフィルターのみを指定できます。 複数のプロパティフィルターは、AND論理演算子によって結合されます。

注意: XNUMXつ以上のプロパティでアラートルールをフィルタリングすることを選択したが、 グループ および リソース/ウェブサイト フィールドが空白の場合、ワイルドカード値(*)がこれらのフィールドに自動的に追加され、プロパティが一致するリソースに関するアラートがこのルールによって考慮されることを示します。

ロジックモジュール

メディア ロジックモジュール フィールドで、このアラートルールが一致するためにアラートをトリガーする必要があるLogicModuleを指定します。 グロブ式 このフィールドでは、ワイルドカードマッチングがサポートされています。 LogicModuleでフィルタリングしたくない場合は、デフォルトのワイルドカード(つまりアスタリスク)をそのままにして、すべてのLogicModuleを示します。

インスタンス

メディア インスタンス フィールドで、このアラートルールが一致するためにアラートがトリガーされる必要があるインスタンスを指定します。 グロブ式 このフィールドでは、ワイルドカードマッチングがサポートされています。 インスタンスでフィルタリングしたくない場合は、すべてのインスタンスを示すために、フィールドにアスタリスク(*)を入力します。

glob式を使用してインスタンスを照合する場合、インスタンスはインスタンス名だけではなく、DataSource-Instance名で識別されることに注意してください。 たとえば、インターフェイス(64ビット)データソースのインスタンスがリソースツリーに「enp2s0」として表示される場合、アラートルールでは「snmp64_If-enp2s0」として識別されます。 したがって、このようなインスタンスに一致させるには、「enp *」ではなく「* enp *」というglob式を使用する必要があります。 特定のインスタンスのDataSource-Instance名に疑問がある場合は、リソースツリーでインスタンスを選択し、詳細ペインのタイトルを確認してください。

注意: ここで確立されたインスタンスフィルターは、インスタンスに関連付けられておらず、デバイスのみに関連付けられているため、EventSourceおよびJobMonitorアラートによって無視されます。

データポイント

メディア データポイント フィールドで、このアラートルールが一致するためにアラートがトリガーされる必要があるデータポイントを指定します。 グロブ式 このフィールドでは、ワイルドカードマッチングがサポートされています。 データポイントでフィルタリングしたくない場合は、デフォルトのワイルドカード(つまりアスタリスク)をそのままにして、すべてのデータポイントを示します。

注意: ここで確立されたデータポイントフィルターは、EventSourceおよびJobMonitorアラートによって無視されます。これらのタイプのアラートは、データポイントの状態によってトリガーされないためです。

アラートがクリアされたときに通知を送信する

もし アラートがクリアされたときに通知を送信する オプションがチェックされている場合、アラートルールを介して最初のアラート通知が配信された受信者は、アラートクリア通知も受信します。

さらに、このオプションをオンにすると、アラートルールを介して最初のアラート通知が配信された受信者は、SDT(スケジュールされたダウンタイム)が後でアクティブ化されて他のルーティングされたアラート通知を一時的に抑制した場合でも、アラートクリア通知を受信するようになります。問題。 SDTはアラートルーティングを抑制するように設計されていますが、サードパーティアプリケーションでチケットを開いたり閉じたりするためにルーティングされたアラート通知に依存するアラート統合では、SDTステータスに関係なくアラートクリア通知をルーティングする動作が重要です。 このため、サードパーティのアラート統合へのアラート通知のルーティングを担当するアラートルールについて、このオプションを確認することが重要です。 アラート統合の詳細については、を参照してください。 アラート統合の概要.

注意: 前の段落で説明したSDTオーバーライド動作は、データソースによってトリガーされたアラートにのみ適用されます。 たとえば、トリガーとなるインスタンス/リソースがSDTに配置された場合、EventSourcesのアラートクリア通知は配信されません。

AcknowledgeまたはSDTのステータス通知を送信します

もし AcknowledgeまたはSDTのステータス通知を送信します オプションがチェックされている場合、最初のアラート通知を受信した人は誰でも、確認応答またはスケジュールされたダウンタイムの通知を受信します。

エスカレーション間隔(分)

アラート通知がエスカレーションチェーン内のステージに送信された後、入力された値 エスカレーション間隔(分) フィールドは、アラートが次のステージにエスカレートされるまでに経過する必要がある時間を定義します。 アラートが確認またはクリアされると、エスカレーションは停止します。

エスカレーションチェーンにステージがXNUMXつしかない場合、アラート通知は、確認またはクリアされるまで、そのステージに繰り返し送信されます。 同様に、通知がマルチステージエスカレーションチェーンの最後に到達した場合、アラートは、確認またはクリアされるまで、最終ステージに繰り返し送信されます。

注意: 「0」のエスカレーション間隔は、アラート通知をエスカレーションチェーンの最初のステージに一度だけルーティングし、そのアラートを手動でエスカレーションしない限り、再送信しません。 これは、エスカレーションチェーンがアラート統合への出力を表すXNUMXつのステージのみで構成されている場合に推奨される設定です。 そうしないと、アラート統合にアラート通知を繰り返し送信すると、重複チケットが作成され、通常は理想的ではありません。 アラート通知をサードパーティのアラート統合にルーティングする方法の詳細については、を参照してください。 アラート統合の概要.

エスカレーションチェーン

ノーザンダイバー社の エスカレーションチェーン フィールドのドロップダウンメニューで、このルールに一致するアラートの送信先となるエスカレーションチェーンを選択します。 (エスカレーションチェーンの詳細については、を参照してください。 エスカレーションチェーン).

アラートルール戦略

環境に基づいてアラートルールを構成することをお勧めします。 アラートルールを追加/編集するときは、次のガイドラインに留意することをお勧めします。

1.すべてのアラートをルーティングする必要はありません

アラートルーティングは、重大な(場合によってはエラー)レベルのアラートなど、早急な対応が必要なアラートに適しています。 警告アラートなど、一部のアラートはすぐに注意を払う必要がないため、レポートでより適切に表示されます。 特定のグループの人々にすべてのアラートを送信する「すべてをキャッチ」ルールを設定する代わりに、特定のアラートのみがルーティングされるようにアラートルールを設定できます。 ただし、アラートを無視していないことを確認してください。 レポートでルーティングされていないアラートを確認する必要があります。

LogicMonitorは、アラートノイズをインテリジェントに削減することを目的として、非常に的を絞ったベースでアラート通知を抑制するAIOps機能も提供します。 これらの機能の詳細については、を参照してください。 データポイントの動的しきい値の有効化 影響により 根本原因分析の有効化 それぞれ。

すべてのアラートをルーティングする場合は、次のルールを作成することを検討してください。 エスカレーション間隔 警告アラートのためだけに「0」の。 これにより、すべての警告アラートが除外され、送信されます 1回だけ 指定されたエスカレーションチェーンの最初の段階に移動します。 次に、エラーアラートとクリティカルアラートのみを組織内のユーザーにルーティングする他のルールを設定できます。

2.特定のルールに高い優先順位を与える

特定のルールの優先度が高く(番号が小さい)、一般的なルールの優先度が低い(番号が大きい)ようにルールを整理する必要があります。 このようにして、特定のルールの基準を満たさないアラートは、一般的なルールによってキャッチされます。

3.優先順位にインデックスを付けます

大規模な展開の場合、組織内のグループに対応するように優先順位にインデックスを付けることができます。 たとえば、開発関連のルールを100年代に優先順位を設定し、本番関連のルールを200年代に優先順位を設定し、QA関連のルールを300年代に優先順位を設定するように設定できます。 すべてのルールが特定のデバイスグループからのアラートのみに一致するように設定されている場合、各部門は、他の部門のアラートに影響を与えることなく、優先順位の範囲内でグループのルーティングをカスタマイズできます。

4.優先度レベル間に大きなギャップを残す

優先度レベルの間に大きなギャップを残すことが非常に重要です。 そうしないと、優先度レベルが順番に近すぎると、既存のルールの優先度を編集して、新しいルール用のスペースを確保する必要があります。

5.アラートルールをテストします

一般的には次のことをお勧めします テストアラート配信、アラートが意図したとおりにルーティングされていることを確認します。

アラートルールの設定例

次のスクリーンショットは、アラートルールのサンプルセットを示しています。 ここに表示されている各アラートルールの設定を使用して、それらが互いにどのように組み合わされて機能するかを説明します。

上のスクリーンショットに示されている最も優先度の高いルールは、「ProductionWarningAlerts」ルールです。 実稼働中の子グループで重大度レベルが「警告」のすべてのアラートを除外します。 このルールは、アラートが確認またはクリアされるまで、30分ごとに(アラート統合を介して)チャットルームにアラート通知を投稿します。

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

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

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

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

記事上で