アラート管理の説明Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } アラート管理の仕組み Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } すべてのリリース Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 目次 概要アラート管理の概要アラート処理のフローアラート管理ルールアラート情報アラートフィルターアクションアラート管理ルールへのアラートアクションルールの移行アラート管理のトラブルシューティング 概要 この記事では、環境でアラート管理ルールを設定および構成する手順について説明します。この記事を使用して、アラートフィルターや修正フローなどを理解します。この記事では、構成に加えて、実装とユースケースに関連する追加のベストプラクティスについても説明します。 アラート管理の概要 アラート管理は、ServiceNow の London リリースで導入された新機能で、既存の「アラートアクションルール」機能に置き換わるものです。アラート管理の目的は、アラートルールを フローデザイナーと統合することです。これにより、ユーザー定義のサブフローを使用してアラートの原因を解決できるようになります。いくつかのサブフローがベースインスタンスで提供されています。「インシデントを開く」、「ナレッジベース (KB) の作成」などです。アラートが生成されたら、アラートに関する詳細情報を表示して内容を確認し、アラートを解決するためのアクションを実行できます。次の 2 つの方法でアラートに応答できます。 手動応答：手動応答では、アラートを手動で修正してアラートを確認し、修正アクションを実行します。アラートアクションルールによる自動応答：ビジネスルール、ユーザー定義サブフローを使用して次のことを行います 注意する必要があるアラートを確認する。インシデントまたはセキュリティインシデントを作成する。アラートをクローズする。アラートに関連するすべてのインシデントを解決する。アラートを再度開く。 アラート管理ルールの実装では、既存のアラートアクションルールを引き続き使用できますが、変更することはできません。新しいアラートアクションルールを作成することはできません。アラートアクションルールをアラート管理ルールに移行できます。この機能を表示するには、次の手順に従います [ イベント管理] > [ルール] > [アラート管理] に移動しますリストビューが開き、利用可能なすべての OOTB アラート管理ルールが次のように表示されます。 アラート処理のフロー アラート管理ルールは、 アラート [em_alert] テーブルで作成されたアラートレコードで実行されます。アラート管理ルール実行の主なフローは、次のとおりです。 システムに入るイベント: イベントプロセッサー はイベントを処理し、em_alertテーブルにアラートレコードを挿入します。アラートが作成されると、 アラート管理プロセッサー は定義されたフィルターに従ってアラート管理ルールの照合を試みます。ルールが一致した場合、修復サブフロー、ワークフロー、またはアプリケーションの起動アクションが実行されます。 アラート管理ルール アラート管理ルールは、アラート情報、アラートフィルター、アクションの 3 つのセクションで構成されています。新しいアラート管理ルールを作成するには、次の手順に従います。 [ イベント管理] > [ルール] > [アラート管理] に移動します[新規] ボタンをクリックします。すべてのルールは「em_alert_management_rule」テーブルに保存されます 注：新しいアラート管理ルールを作成するには、ロール evt_mgmt_admin が必要です。 すべてのセクションとセクションに存在するフィールドについて詳しく説明します。 アラート情報アラートフィルターアクション アラート情報 [アラート情報] は、アラート管理ルールの最初の画面で、名前、順序、状態などを指定します。 ここで最も重要なフィールドは [複数のアラートルール] です。2 つのオプションの詳細は、次のとおりです。 追加のルールを検索：現在のルールを実行した後、他の一致するルールをルールの優先度 (数値が小さいほど優先度が高い) の順に実行します。追加のルールの検索を停止：現在のルールの実行後に他のルールを検索しません。 ユースケース：アラート管理ルールが実行されない理由。 フィルター条件に基づいてアラートルールを実行する必要があるのに実行されていないユースケースが表示された場合は、同じフィルター条件に一致し、[複数のアラート一致] に [追加のルールの検索を停止] の値が設定された、現在のものよりも実行順序が早い他のアラートルールがあるかどうかを確認しますこの値が設定されている場合、システムは現在のルールを実行して修正アクションを実行し、以降の処理を停止します。したがって、他のアラート管理ルールは、条件に一致しても実行されません。アラート管理リストビューにクエリを実行し、特定のフィルター条件を持つアラートを見つけるには、記事 Querying Alert Rule を参照してください。 アラートフィルター [アラートフィルター] セクションでは、このアラート管理ルールが適用されるアラートフィルターを定義します。また、さまざまなセカンダリアラートなどの関連リスト条件を指定することもできます。[関連リスト条件] 領域の条件を使用して追加のフィルターを適用し、このルールに一致するアラートをさらに定義します。 たとえば、アラートフィルターがグループの一部であるアラートと一致する場合があります。[関連リスト条件] 領域の条件を使用して、必要に応じて、プライマリアラートのみに一致するフィルター、またはセカンダリアラートのみに一致するフィルターを作成できます。詳細については、「関連リスト条件の追加」を参照してください。 [ルールがアクティブになるタイミング] フィールド値に注目しましょう。この値によって、ルールをアクティブにするタイミングが決まります。ルールは 次の場合にオープンアラートの更新時に実行されます。 フィルターに一致するアラート:アラートのコンテンツがフィルターに一致する場合。アラートが更新されるたびに、フィルターに一致した場合、ルールが実行され、更新ごとにアラートに適用されます。フィルターへのアラートの変更:アラートの内容の変更によってアラートがフィルターに一致すると、ルールが適用されます 1 回のみ 。アラートの次の更新でフィルターに一致した場合、そのルールは適用されなくなります。アラートがクローズされ、フィルターに一致した場合に再度オープンされた場合、ルールが適用されます。その後、アラートが更新され、アラートがフィルターに一致し続けると、そのルールは適用されなくなります。 ここで例を考えてみましょう。 重大度 = メジャーのアラートが存在します。「ルールがアクティブになるタイミング」の値が フィルターへのアラートの変更 に設定され、フィルター条件に Severity = Critical が含まれているアラートルールがあります 新しい Critical イベントが生成され、アラートの Severity が Major から Critical に変更された場合は、アラートフィルター条件 [Severity = Critical] が一致し、修復アクションが実行されます。同じユースケースで、アラートの重大度を Critical から Major に戻す別の新しいイベントが生成された場合、このルールは適用されません。アラート内でフィルター条件に関連する属性が変更された場合にのみ、ルールが適用されます。[ここで注意すべきことは、Severity が任意の値から Critical に変わるたびにこのルールが適用されることです]。しばらくして、別のイベントが生成されて Severity が Critical に変更されると、その場合もルールがトリガーされ、修正サブフローが実行されます。 同じ例では、フィールドの 説明 値を変更する別のイベントが生成され、重大度の値ではなく説明の値が変更されたため このルールは適用されず 修復アクションは実行されません。 ただし、[ルールがアクティブになるとき] が [アラートがフィルターに一致] に設定され、フィルター条件が同じ [Severity = Critical] の場合は、[説明] を変更するとアラート管理ルールもトリガーされます。アラートが更新されるたびに、フィルターが条件に「一致」すると、アラートルールがトリガーされ、修復アクションが実行されます。つまり、条件フィルターで使用される属性に変更を加えなくても、条件が一致していればルールは 常に実行されます。注：各修正アクションに定義されている自動実行の制限に注意してください。実行制限が 1 の場合、ルールが適用されても何も起こらない可能性があります。 この制限は、アラートが再オープンされるとリセットされます。 ユースケース：アラート条件が一致しても修正アクションが実行されない。 アラートフィルター条件が一致しているにもかかわらず、インシデントが作成されない、またはワークフローが実行されない場合は、大文字と小文字を確認する必要があります。アラートフィルター条件では大文字と小文字が区別されます。 条件値の文字列の大文字と小文字と一致しない場合、フィルターの実行は失敗し、修正フローはトリガーされません。 たとえば、アラートフィルター条件が「説明 = NRTEST」に設定されている場合、アラートの説明には、NRtest、nrtest、nrTest などではなく、NRTEST が含まれている必要があります。 注：[アラート情報] タブで [アクティブ] が選択されている場合は、少なくとも 1 つの修正アクションを指定する必要があります。修正アクションが定義されていない場合、ルールは自動的に非アクティブになります。 アクション アラートの [アクション] タブでは、アラートフィルター条件が満たされたときに実行するアクションを指定します。許可された OOTB アクションがあります。 修正サブフロー：ベースシステムで提供されるサブフロー、または以前に作成され公開されたサブフローを実行します。修正ワークフロー：以前に公開したワークフローを実行します。アプリケーションを起動：構成したアプリケーションとブラウザを開きます。注意 :フローデザイナー、サブフローなどの詳細については、「フローデザイナー」を参照してくださいインシデントの作成、ナレッジ記事を添付、アラートのクローズなどのオプションを提供する複数の OOTB サブフローが用意されています。サブフローの追加方法および関連するさまざまな構成オプションに関する詳細を次に示します。 アクション > 修復サブフローに移動し、[サブフロー] ラベルの下のセルをダブルクリックします。サブフローを検索するためのテキストを追加するオプションが表示されます。または検索アイコンをクリックすることもできます。検索オプションには、公開されているすべての OOTB の利用可能なサブフローが表示されます。目的のものを選択し、セルウィンドウで [保存] をクリックします。これにより、サブフローレコードがアラートルールに関連付けられます。これらの関係は [em_alert_man_m2m_rule_flow] テーブルに格納されます。 注意事項 実行オプション自動：サブフローは、ルールに一致するたびに自動的に実行されます。手動：サブフローの実行は手動アクションにリンクされています。例：[クイック応答] UI アクションを手動で選択してサブフローを実行します。両方：ルールに一致すると、サブフローが自動的に実行されますが、必要に応じて [クイック応答] UI アクションを使用してサブフローを再度手動で実行できます。自動実行の制限サブフローを実行できる最大回数を設定する整数値。フィールドに設定された数を超えてサブフローの実行が呼び出された場合、サブフローの実行はスキップされ、修正アクションは実行されません。ワークフロー/サブフローはいくつでもアクションに追加できますが、 各サブフローは 1 回しか追加できません。同じサブフローを 2 回追加しようとすると、次のようなエラーがトリガーされます。サブフローを特定の順序で実行することはできません。 サブフローの実行は 非同期方式です。カスタムサブフローを作成するには、誤った構文や命名の問題が原因で発生する問題を回避するために、可能な限り OOTB サブフローと OOTB アクションをコピーすることをお勧めします。これらのカスタムサブフローを適切にテストし、アクティブで公開済みであることを確認する必要があります。 同様の手順と構成を使用して、[修正ワークフロー] と [アプリケーションを起動] を選択できます。詳細については、「アラート管理ルールの作成」を参照してくださいユースケース：メンテナンスモードから本番モードに戻った CI に対してインシデントが作成されない。 CI がメンテナンスモードであり、アラートが生成されるが、サブフローに検証チェックが存在するためにインシデントが作成されない場合。ただし、CI が本番モードに戻り、アラートが生成された場合、インシデントが作成されることが想定されますが、インシデントは生成されません。これは、選択したサブフローのアラート管理ルールに存在する [自動実行の制限] フィールドの値が原因です。 メンテナンスモードの CI に対してアラートルールが実行されると、サブフローは正常に呼び出されますが、検証のためにインシデントは作成されず、試行は無駄になります。CI が本番モードに戻り、アラートが生成されると、サブフローの実行はすでに指定された回数 (1) 実行されているため、指定された回数を超えて実行されることはなく、修正サブフローは実行されません。したがって、このような場合は、実行試行の無駄を避けるために、アラートルールに Maintenance = False フィルター条件を追加することをお勧めします。 アクションを実行するように構成されていないアラート管理ルールはスキップされ、ルールは自動的に非アクティブに設定されます。 アラート管理ルールへのアラートアクションルールの移行 アラート管理では、アラートアクションルールの実行がサポートされています。アップグレード後 London 以降 古いアラートアクションルールは引き続き機能しますが、変更できず、読み取り専用です。ルールを変更する場合は、ルールをアラート管理ルールに移行する必要があります。ルールは 1 回しか移行できないことに注意してくださいフィルターはフィルターにマップされ、アクションはアクションにマップされます。アラートアクションルールにインシデントテンプレートが定義されている場合は、OOTB「タスクの作成 (従来)」サブフローによって実行されます。従来のサブフローへの入力は、アラートアクションルールのテンプレートによって提供されます。ListView で、テンプレートフィールドを追加すると、値が表示されます。 詳細については、「アラートアクションルールをアラート管理ルールに移行する」を参照してください アラート管理のトラブルシューティング アラート管理で確認される考えられる根本原因。アラート管理ジョブ [イベント管理 - スコープ対象のアラートルール管理を評価 (Event Management - Evaluate Scoped Alert Rules Management0)] が実行中/アクティブになっていることを確認します。 含まれているスクリプトは EvtMgmtAlertMgmtJobWrapper です。カスタマイズされているか、OOTB であるかを確認します。sa_hash.last_calculated_alert_management_job フィールドの更新時刻が直近 1 分以内であることを確認することも有効です。 注 :場合によっては、古い廃止ジョブ [イベント管理:アラート管理ルールの評価] が引き続き実行されることが確認されます。適切なプロセスに従って、適切なジョブを有効にし、廃止されたジョブを無効にしてください。 Alert Management Content プラグインがインストールされていることを確認します。このプラグインには、OOTB で提供されるすべての OOTB サブフローが含まれています。実行されるはずのアラートルールはアクティブかつ公開済みである必要があります。[複数のアラートルール] フィールド値に注意してください。具体的には、[追加のルールの検索を停止] の値です。修正アクションサブフローは、自動、手動、またはその両方を実行するように設定できます。手動に設定されている場合、[クイック応答] UI アクションが選択されている場合にのみフローが実行されます。クイック応答 UI アクションには、両方または手動として実行するように設定されたサブフローのみが表示されます。新しいカスタムサブフローの場合は、アラート管理テンプレートを使用し、コピーして保存することをお勧めします。ここでは、必要に応じてアクションを自由に変更したり追加したりできます。利用可能な他の OOTB サブフローをコピーして変更できます。カスタムサブフローでは、すべての名前が正しいことを確認してください。主な問題は名前にあります。変更後、テストして公開します。アクションをコピーしてサブフローに使用することができます。カスタムアクションは、Flow Designer の Add Action メニューの Global オプションで使用できます。 サブフローの実行を検証します。 アラート処理では、定義されたアラートルールに基づいて特定のアクションを実行することが期待されます。サブフロー実行の詳細は、[アラートの実行] タブで確認できます。このタブには、アラート管理ルールの名前、アクション名、Flow Designer 実行リンク、関連タスク、およびログに関する詳細が表示されます。[ログ] タブには、フローの成功または失敗が表示されます。 実行に失敗した場合、サブフローのリンクをクリックすると、Flow Designer が開き、失敗したステップのエラーが表示されます。これにより、失敗したステップに基づいて原因を特定できます。 ユースケース：アラートルールが条件と一致しても、インシデントが作成されない。 イベントによってアラートが生成されているにもかかわらず、アラートルールが実行されないシナリオです。 アラートルールフィルターの [プレビュー] ボタンをクリックすると、アラートが結果に一覧表示されますが、それでもルールは実行されません。この状況は、イベントの作成時刻が原因で発生します。同じ分に発生し、同じアラートにバインドされている 2 つのイベント (解決ステータスが新規のイベントと解決ステータスがクローズのイベント) があり、これらの 2 つのイベントが同じ処理サイクルで処理される状況では、アラート管理ルールは実行されず、インシデントは作成されません。ここでは、関連するアラートが作成され、すぐにクローズされます。このような場合、アラート管理ルールは意図的に適用されません。一般に、アラート管理ルールはクローズされたアラートには適用されません。ノイズを低減し、無関係なインシデントを開かないようにするために、アラートが迅速にクローズされるようなシナリオをサポートするための特別な処理があります。 ユースケース – アラートルールが条件に一致するが、インシデントの作成が遅延する アラート管理ルールは、アラートが更新されてから 5 秒後に実行され、その期間内に更新が発生するとタイマーがリセットされます。この遅延により、インシデントの作成などの修復アクションは、問題が明確で安定した場合にのみトリガーされ、重複や不要なノイズが削減されます。デフォルトの 5 秒の遅延を変更するには、[すべての>システムプロパティ] > [すべてのプロパティ] に evt_mgmt.alert_rule_delay プロパティを作成し、値を変更します。