イベント処理ジョブへのイベントの割り当てと、イベント処理ジョブのハング/遅延を識別する方法Summary受信イベントをイベント処理スケジュール済みジョブに割り当てる方法: (1) イベントを受信すると、各イベントにバケット番号が割り当てられます。これは、イベントレコードのフィールド 「バケット」 に反映されます。 (2) 利用可能なイベント処理スケジュール済みジョブにバケットを分配します。各ジョブに割り当てられたバケット範囲は、 sys_trigger テーブルのスケジュール済みジョブレコードで確認できます。ジョブは イベント管理 - プロセスイベント #: バケット範囲は特定のジョブ名に割り当てられます。例: イベント管理 - プロセスイベント - #1 は、0 〜 25 の範囲でアサインできます。クラスター内の各ノードには、同じジョブ名が割り当てられます。 [イベント管理>プロパティ] > [マルチノードイベント処理を有効にする] が [はい] に設定されている場合このジョブが特定のノードで実行されると、(NodeloadInfo で) サブ範囲が計算されます。Match.ceil(range_size/#of nodes) です。4 ノードクラスターの場合、各イベント管理 - プロセスイベント - #1 には 7 つのバケットのサブ範囲があります。ノード 1 は 0-6、ノード 2 は 7-13、ノード 3 は 14-20、ノード 4 は 21-24 に割り当てることができます。このようにして、各ノードの各イベント管理 - プロセスイベント - #1 は、独自の専用バケットを処理します。クラスターに変更がない場合、特定のバケットを処理できるノードは 1 つだけです。この設計では、何らかの理由でノードで子ジョブが再作成されない場合、特定のバケット範囲が処理されないという問題が発生しやすくなります。(これは、ノードが停止、起動、または追加されている場合に発生する可能性があります) (3) これらのスケジュール済みジョブの数は、システムプロパティ evt_mgmt.event_processor_job_count を使用して構成できます。また、次の場所からも表示できます。 イベント管理>プロパティ> イベントを処理するスケジュール済みジョブの数 [イベント管理>プロパティ] > [マルチノードイベント処理を有効にする] が [はい] に設定されている場合、[イベント管理 - イベントの処理] ジョブの数必要があります。 イベント管理>プロパティ > スケジュール済みジョブの数 アクティブノードを乗算します (アクティブノードは、ステータスがオンラインで、スケジューラーがシステムクラスターステータスで「任意」のノードです)。 + イベント管理>プロパティ > スケジュール済みジョブの数 (SYS ID = "ACTIVE NODES" のジョブ) (4) イベントは、割り当てられたバケットに従ってスケジュール済みジョブによって要求されます。 NewYork リリースの前に、ジョブがイベントを処理するときに、現在の実行で処理されるすべてのイベントがステータス queued.the_sys_id_of_the_scheduled_job で最初にマークされます。その結果、特定のノードで実行されなくなったスケジュール済みジョブによって要求されたため、イベントがスタックしました。 New York リリース以降、キューに入れられたステータスはなくなりました。また30 秒ごとに実行され、構成された設定に従ってすべてのイベント管理 - プロセスイベント # ジョブが実行されていることを確認する「イベント管理 - コーディネーター ジョブ」が導入されました。 問題が見つかった場合は、ジョブの数が修正されます。ジョブの数が修正されると、コーディネーター ジョブを待機しているすべてのジョブを実行できるようになります。 (5) em_event 7 日間設定されたローリングテーブル (テーブルは 24 時間ごとに変更される) である場合、イベント処理ジョブは、現在または以前のテーブル (2 日前) にのみ存在するイベントを処理し、イベントはこれらのテーブルに~5.5 日間保持されます。 イベント処理ジョブの問題を特定する方法: 表示される場合: 長時間処理されず、READY または QUEUED ステータスのイベント。 (1) em_event テーブルでハングするイベントのレコードを開き、イベントのレコードのバケット項目の値をメモします。 (2) sys_trigger テーブルに移動します: System Scheduler > Scheduled Jobs > Today scheduled jobs および Event Management – process eventsで始まるジョブをフィルタリングします (3)それらの仕事について: 上記の情報に基づいて、スケジュール済みジョブの数が正しく反映されているかどうかを確認します。 そうでない場合は、欠落しているジョブがあるノードを特定します。これを行うには、[要求元] 列でグループ化し、どのノードに欠落しているジョブがあるかを確認します。 [次のアクション] 列と [要求元] を確認して、次にジョブをトリガーするタイミングと、このジョブを要求しているノードを確認します。 ジョブは 5 秒ごとに実行される必要があるため、次のアクション」が今から 5 秒後でない場合、ジョブはスタックしています。ジョブがパッシブノードによって要求された場合、ジョブもスタックします。ジョブのステータスがエラーまたはキューに格納されていないことを確認します ワークアラウンド 実行中のイベント処理ジョブの数が正しくない場合は、スケジュール済みジョブの数 イベント管理>プロパティ>変更し、元の数に戻します(つまり、2から3に変更してから2に変更します)。これにより、実行中のすべてのジョブが消去され、設定に従って再度作成されます。実行 cache.do問題のあるイベントのステータスが「処理済み」に変更し始めることを確認します。処理されていないキューに格納されたイベントが表示された場合は、これらのイベントを (スクリプトを使用して) 再作成し、イベント処理ジョブがこれらのイベントを処理できるようにする必要があります。作成時間が 2 日より短い (つまり、ジョブが処理しない) READY ステータスのイベントが表示された場合は、プロパティ evt_mgmt.events_processing_all_shards を true に設定すると、イベント処理ジョブはすべてのテーブルのイベントを処理します。すべてのイベントが処理されたら false に設定します。 Related Linksイベント管理機能の一部の健全性を監視する機能がデフォルトで用意されています。この機能を有効にすると、潜在的な問題が検出されたときに作成されたアラートが表示されます。このトピックで注目する2つのアラートは、「イベント処理ジョブ」と「イベント処理の遅延」です。 次の情報を使用して作成されたアラートのem_alertテーブルを確認できます。イベント管理処理で遅延が発生している場合は、上記の回避策の手順に従ってください。それでも問題が発生する場合は、ServiecNow サポートでケースをオープンしてください。 ソース: EMSelfMonitoring 説明に「イベント処理の遅延:」または「誤ったイベント処理ジョブ数」が含まれています この機能が環境で有効になっているかどうかを確認するには: イベント管理>設定>プロパティ>イベント管理セルフヘルスモニタリングの有効化