アラート管理の説明Issue 目次 概要アラート管理の概要アラート処理のフローアラート管理ルールアラート情報アラートフィルターアクションアラート管理ルールへのアラートアクションルールの移行アラート管理のトラブルシューティング 概要 この記事では、環境でアラート管理ルールを設定および構成する手順について説明します。この記事を使用して、アラートフィルターや修正フローなどを理解します。この記事では、構成に加えて、実装とユースケースに関連する追加のベストプラクティスについても説明します。 アラート管理の概要 アラート管理は、ServiceNow の London リリースで導入された新機能で、既存の「アラートアクションルール」機能に置き換わるものです。アラート管理の目的は、アラートルールを Flow Designer と統合し、ユーザー定義のサブフローを使用してアラートの原因を解決できるようにすることです。いくつかのサブフローがベースインスタンスで提供されています。「インシデントを開く」、「ナレッジベース (KB) の作成」などです。アラートが生成されたら、アラートに関する詳細情報を表示して内容を確認し、アラートを解決するためのアクションを実行できます。次の 2 つの方法でアラートに応答できます。 手動応答：手動応答では、アラートを手動で修正してアラートを確認し、修正アクションを実行します。アラートアクションルールによる自動応答：ビジネスルール、ユーザー定義サブフローを使用して次のことを行います 注意する必要があるアラートを確認する。インシデントまたはセキュリティインシデントを作成する。アラートをクローズする。アラートに関連するすべてのインシデントを解決する。アラートを再度開く。 アラート管理ルールの実装では、既存のアラートアクションルールを引き続き使用できますが、変更することはできません。新しいアラートアクションルールを作成することはできません。アラートアクションルールをアラート管理ルールに移行できます。この機能を表示するには、次の手順に従います [イベント管理] > [ルール] > [アラート管理] に移動しますリストビューが開き、利用可能なすべての OOTB アラート管理ルールが次のように表示されます。 アラート処理のフロー アラート管理ルールは、アラート [em_alert] テーブルに作成されたアラートレコードに対して実行されます。アラート管理ルール実行の主なフローは、次のとおりです。 システムへのイベント受信：イベントプロセッサーがイベントを処理し、[em_alert] テーブルにアラートレコードを挿入します。アラートが作成されると、アラート管理プロセッサーは、定義されたフィルターに従ってアラート管理ルールの照合を試行します。ルールに一致すると、修正サブフロー、ワークフロー、またはアプリケーションの起動アクションが実行されます。 アラート管理ルール アラート管理ルールは、アラート情報、アラートフィルター、アクションの 3 つのセクションで構成されています。新しいアラート管理ルールを作成するには、次の手順に従います。 [イベント管理] > [ルール] > [アラート管理] に移動します[新規] ボタンをクリックします。すべてのルールは [em_alert_management_rule] テーブルに保存されます 注：新しいアラート管理ルールを作成するには、ロール evt_mgmt_admin が必要です。 すべてのセクションとセクションに存在するフィールドについて詳しく説明します。 アラート情報アラートフィルターアクション アラート情報 [アラート情報] は、アラート管理ルールの最初の画面で、名前、順序、状態などを指定します。 ここで最も重要なフィールドは [複数のアラートルール] です。2 つのオプションの詳細は、次のとおりです。 追加のルールを検索：現在のルールを実行した後、他の一致するルールをルールの優先度 (数値が小さいほど優先度が高い) の順に実行します。追加のルールの検索を停止：現在のルールの実行後に他のルールを検索しません。 ユースケース：アラート管理ルールが実行されない理由。 フィルター条件に基づいてアラートルールを実行する必要があるのに実行されていないユースケースが表示された場合は、同じフィルター条件に一致し、[複数のアラート一致] に [追加のルールの検索を停止] の値が設定された、現在のものよりも実行順序が早い他のアラートルールがあるかどうかを確認しますこの値が設定されている場合、システムは現在のルールを実行して修正アクションを実行し、以降の処理を停止します。したがって、他のアラート管理ルールは、条件に一致しても実行されません。[アラート管理] リストビューをクエリして特定のフィルター条件のアラートを見つけるには、「アラートルールのクエリ」の記事を参照してください。 アラートフィルター [アラートフィルター] セクションでは、このアラート管理ルールが適用されるアラートフィルターを定義します。また、さまざまなセカンダリアラートなどの関連リスト条件を指定することもできます。[関連リスト条件] 領域の条件を使用して追加のフィルターを適用し、このルールに一致するアラートをさらに定義します。 たとえば、アラートフィルターがグループの一部であるアラートと一致する場合があります。[関連リスト条件] 領域の条件を使用して、必要に応じて、プライマリアラートのみに一致するフィルター、またはセカンダリアラートのみに一致するフィルターを作成できます。詳細については、「関連リスト条件の追加」を参照してください。[ルールがアクティブになるとき] フィールドの値に注目します。この値によって、ルールをアクティブにするタイミングが決まります。このルールは、次の場合にオープンアラートの更新時に実行されます。 アラートがフィルターに一致：アラートのコンテンツがフィルターに一致した場合。アラートが更新されるたびに、フィルターに一致した場合、ルールが実行され、更新ごとにアラートに適用されます。フィルタリングするアラートの変更：ルールは、アラートのコンテンツを変更することでアラートがフィルターに一致する場合に 1 度だけ適用されます。アラートの次の更新でフィルターに一致した場合、そのルールは適用されなくなります。アラートがクローズされ、フィルターに一致した場合に再度オープンされた場合、ルールが適用されます。その後、アラートが更新され、アラートがフィルターに一致し続けると、そのルールは適用されなくなります。 ここで例を考えてみましょう。 次のアラートが存在します。重大度 = メジャー[ルールがアクティブになるとき] の値が [フィルタリングするアラートの変更] に設定されているアラートルールがあり、フィルター条件に [重大度 = 重大] が含まれている場合 新しい重大イベントが生成され、アラートの重大度がメジャーから重大に変更された場合、アラートフィルター条件 [重大度 = 重大] に一致し、修正アクションが実行されます。同じユースケースで、アラートの重大度を重大からメジャーに戻す別の新しいイベントが生成された場合、このルールは適用されません。フィルター条件をフィードするアラートの [メジャー] 属性に変更があった場合は、ルールのみが適用されます。[ここで注意すべきことは、重大度がある値から重大に変わるたびにこのルールが適用されることです]。しばらくして、別のイベントが生成されて重大度が重大に変更されると、その場合もルールがトリガーされ、修正サブフローが実行されます。 同じ例で、フィールドの [説明] 値を変更する別のイベントが生成されても、重大度の値ではなく [説明] の値に変更があるため、このルールは適用されず、修正アクションは実行されません。 ただし、[ルールがアクティブになるとき] が [アラートがフィルターに一致] に設定され、フィルター条件が同じ [重大度 = 重大] の場合は、[説明] の変更によってアラート管理ルールもトリガーされます。アラートが更新されるたびに、フィルターが条件に「一致」すると、アラートルールがトリガーされて修正アクションが実行されます。つまり、条件フィルターで使用されている属性を変更しなくても、条件が一致するとルールは常に実行されます。注：各修正アクションに定義されている自動実行の制限に注意してください。実行制限が 1 の場合、ルールは適用されますが、何も起こりません。 この制限は、アラートが再オープンされるとリセットされます。 ユースケース：アラート条件が一致しても修正アクションが実行されない。 アラートフィルター条件が一致しているにもかかわらず、インシデントが作成されない、またはワークフローが実行されない場合は、大文字と小文字を確認する必要があります。アラートフィルター条件では大文字と小文字が区別されます。 条件値の文字列の大文字と小文字と一致しない場合、フィルターの実行は失敗し、修正フローはトリガーされません。 たとえば、アラートフィルター条件が「説明 = NRTEST」に設定されている場合、アラートの説明には、NRtest、nrtest、nrTest などではなく、NRTEST が含まれている必要があります。 注：[アラート情報] タブで [アクティブ] が選択されている場合は、少なくとも 1 つの修正アクションを指定する必要があります。修正アクションが定義されていない場合、ルールは自動的に非アクティブになります。 アクション アラートの [アクション] タブでは、アラートフィルター条件が満たされたときに実行するアクションを指定します。許可された OOTB アクションがあります。 修正サブフロー：ベースシステムで提供されるサブフロー、または以前に作成され公開されたサブフローを実行します。修正ワークフロー：以前に公開したワークフローを実行します。アプリケーションを起動：構成したアプリケーションとブラウザを開きます。注：Flow Designer、サブフローなどの詳細については、「Flow Designer」を参照してくださいインシデントの作成、ナレッジ記事の添付、アラートのクローズなどのオプションを提供する複数の OOTB サブフローが用意されています。サブフローの追加方法および関連するさまざまな構成オプションに関する詳細を次に示します。 [アクション] > [修正サブフロー] に移動し、[サブフロー] ラベルの下のセルをダブルクリックします。サブフローを検索するためのテキストを追加するオプションが表示されます。または検索アイコンをクリックすることもできます。検索オプションには、利用可能なすべての OOTB サブフローが表示されます (公開されているもの)。 目的のものを選択し、セルウィンドウで [保存] をクリックします。これにより、サブフローレコードがアラートルールに関連付けられます。これらの関係は [em_alert_man_m2m_rule_flow] テーブルに格納されます。 注意事項 実行オプション自動：サブフローは、ルールに一致するたびに自動的に実行されます。手動：サブフローの実行は手動アクションにリンクされています。例：[クイック応答] UI アクションを手動で選択してサブフローを実行します。両方：ルールに一致すると、サブフローが自動的に実行されますが、必要に応じて [クイック応答] UI アクションを使用してサブフローを再度手動で実行できます。自動実行の制限サブフローを実行できる最大回数を設定する整数値。フィールドに設定された数を超えてサブフローの実行が呼び出された場合、サブフローの実行はスキップされ、修正アクションは実行されません。アクションには任意の数のワークフロー/サブフローを追加できますが、各サブフローは 1 回のみ追加できます。同じサブフローを 2 回追加しようとすると、次のようなエラーがトリガーされます。サブフローを特定の順序で実行することはできません。 サブフローの実行は非同期で行われます。カスタムサブフローを作成するには、誤った構文や命名の問題が原因で発生する問題を回避するために、可能な限り OOTB サブフローと OOTB アクションをコピーすることをお勧めします。これらのカスタムサブフローを適切にテストし、アクティブで公開済みであることを確認する必要があります。 同様の手順と構成を使用して、[修正ワークフロー] と [アプリケーションを起動] を選択できます。詳細については、「アラート管理ルールの作成」を参照してくださいユースケース：メンテナンスモードから本番モードに戻った CI に対してインシデントが作成されない。 CI がメンテナンスモードであり、アラートが生成されるが、サブフローに検証チェックが存在するためにインシデントが作成されない場合。ただし、CI が本番モードに戻り、アラートが生成された場合、インシデントが作成されることが想定されますが、インシデントは生成されません。これは、選択したサブフローのアラート管理ルールに存在する [自動実行の制限] フィールドの値が原因です。 メンテナンスモードの CI に対してアラートルールが実行されると、サブフローは正常に呼び出されますが、検証のためにインシデントは作成されず、試行は無駄になります。CI が本番モードに戻り、アラートが生成されると、サブフローの実行はすでに指定された回数 (1) 実行されているため、指定された回数を超えて実行されることはなく、修正サブフローは実行されません。したがって、このような場合は、無駄な実行の試行を避けるために、メンテナンス = False フィルター条件をアラートルールに追加することをお勧めします。 アクションを実行するように設定されていないアラート管理ルールはスキップされ、自動的に非アクティブに設定されます。 アラート管理ルールへのアラートアクションルールの移行 アラート管理では、アラートアクションルールの実行がサポートされています。London 以降へのアップグレード後、古いアラートアクションルールは引き続き機能しますが、変更することはできず、読み取り専用です。ルールを変更する場合は、ルールをアラート管理ルールに移行する必要があります。ルールは 1 回だけ移行できることに注意してくださいフィルターはフィルターにマップされ、アクションはアクションにマップされます。アラートアクションルールにインシデントテンプレートが定義されている場合は、OOTB「タスクの作成 (従来)」サブフローによって実行されます。従来のサブフローへの入力は、アラートアクションルールのテンプレートによって提供されます。ListView で、テンプレートフィールドを追加すると、値が表示されます。 詳細については、「アラート管理ルールへのアラートアクションルールの移行」を参照してください。OOTB アラート管理ルールをあるインスタンスから別のインスタンスに移行する方法については、「KB0751453 - アラート管理ルールのインポートエクスポート」を参照してください。カスタムサブフローを含むアラート管理ルールをあるインスタンスから別のインスタンスに移行する方法については、「KB0752233 - カスタムサブフローを含むアラート管理ルールのインポートエクスポート」を参照してください。 アラート管理のトラブルシューティング アラート管理で確認される考えられる根本原因。 アラート管理ジョブ [イベント管理 - アラート管理ルールの評価] が実行中/アクティブであることを確認します。EvtMgmtAlertManagementJob というスクリプトが含まれています。カスタマイズされているか、OOTB であるかを確認します。 また、更新された [sa_hash.last_calculated_alert_management_job] フィールドに移動すると役立つ場合があります。Alert Management Content プラグインがインストールされているかどうかを確認します。このプラグインには、OOTB で提供されるすべての OOTB サブフローが含まれています。起動されるはずのアラートルールがアクティブで公開されている必要があります。[複数のアラートルール] フィールドの値に注意してください。具体的には、[追加のルールの検索を停止] の値です。修正アクションサブフローは、自動、手動、またはその両方を実行するように設定できます。手動に設定されている場合、[クイック応答] UI アクションが選択されている場合にのみフローが実行されます。クイック応答 UI アクションには、両方または手動として実行するように設定されたサブフローのみが表示されます。新しいカスタムサブフローの場合は、アラート管理テンプレートを使用し、コピーして保存することをお勧めします。ここでは、必要に応じてアクションを自由に変更したり追加したりできます。利用可能な他の OOTB サブフローをコピーして変更できます。カスタムサブフローでは、すべての名前が正しいことを確認してください。主な問題は名前にあります。変更後、テストして公開します。アクションをコピーしてサブフローに使用することができます。カスタムアクションは、Flow Designer の [アクションを追加] メニューの [グローバル] オプションで使用できます。 サブフローの実行を検証します。 アラート処理では、定義されたアラートルールに基づいて特定のアクションを実行することが期待されます。サブフロー実行の詳細は、[アラートの実行] タブで確認できます。このタブには、アラート管理ルールの名前、アクション名、Flow Designer 実行リンク、関連タスク、およびログに関する詳細が表示されます。[ログ] タブには、フローの成功または失敗が表示されます。 実行に失敗した場合、サブフローのリンクをクリックすると、Flow Designer が開き、失敗したステップのエラーが表示されます。これにより、失敗したステップに基づいて原因を特定できます。 ユースケース：アラートルールが条件と一致しても、インシデントが作成されない。 イベントによってアラートが生成されているが、アラートルールが実行されないシナリオ。アラートルールフィルターの [プレビュー] ボタンをクリックすると、アラートが結果に一覧表示されますが、ルールは実行されません。この状況は、イベントの作成時刻が原因で発生します。同じ分に発生し、同じアラートにバインドされている 2 つのイベント (解決ステータスが新規のイベントと解決ステータスがクローズのイベント) があり、これらの 2 つのイベントが同じ処理サイクルで処理される状況では、アラート管理ルールは実行されず、インシデントは作成されません。ここでは、関連するアラートが作成され、すぐにクローズされます。このような場合、アラート管理ルールは目的別に適用されません。一般に、アラート管理ルールはクローズされたアラートには適用されません。ノイズを低減し、無関係なインシデントを開かないようにするために、アラートが迅速にクローズされるようなシナリオをサポートするための特別な処理があります。