準備完了ステータスのイベント管理イベントIssue イベント管理イベントは処理されません。このようなイベントは処理されないため、アラートもインシデントも作成されません。Cause01 スケジュール済みジョブ「イベント管理 - プロセスイベント」の問題 (パッシブノードによって停止、スタック、要求など)。 また、ジョブ数の更新後またはインスタンスのアップグレード後に、ジョブが正しく再作成されない可能性もあります。 これが、イベントが「準備完了」ステータスでスタックする正しい根本原因であることを確認するには、次のようにします。 [System Scheduler >スケジュール済みジョブ>今日のスケジュール済みジョブ] に移動します。 「イベント管理 - プロセスイベント」のようなジョブを検索します。 [次のアクション] 列と [要求元] 列を確認します。 このジョブのデフォルト設定 (OOB) は 5 秒ごとに実行する必要があります。したがって、「次のアクション」はそこから数秒後になります。「次のアクション」が過去の時間である場合、ジョブは行き詰まっている可能性があります。 「システム ID」が「アクティブノード」であるジョブは、過去に「次のアクション」を持つことができますが、問題ありません。これらは「親」ジョブであり、実際には実行されません。 ジョブがパッシブノードで要求されている場合、ジョブもスタックしています。最後に、「マルチノードイベント処理を有効にする = true」の場合、(<number_of_jobs_configured> * (1 + <active_worker_nodes>)) ジョブがあることを確認します。 例: ノード当たり4つのジョブがイベントを処理するように構成された6つのアクティブなワーカー・ノードを持つインスタンスは、(4 * (1 + 6)) = 28になります。 注意: アクティブなワーカー・ノードの数に追加された上記の1は、システム「アクティブ・ノード」に対してもジョブが作成されるためです。 [マルチノードイベント処理を有効にする = true] の場合、複数のイベント処理ジョブが作成されます。イベントは、ジョブによって処理される「バケット」に分割されます。ジョブに問題がある場合、関連する「バケット」のイベントは処理されません。したがって、場合によっては、処理されているイベントと処理されていないイベントがあることがあります。 02 ノードキャッシュが同期されておらず、1 つ以上のノードにノード数に関する誤った情報があります。 03 カスタムビジネスルールとスクリプトインクルードにより、イベント処理に余分なオーバーヘッド遅延が追加されます ベストプラクティスとして、em_eventテーブルとem_alertテーブルにカスタムビジネスルールを設定することはお勧めしません。カスタムビジネスルールを追加する必要がある場合は、高速に実行されることを確認してください。イベント負荷が高い場合、マルチノードイベント処理とマルチスレッドが有効になっている場合でも、追加されたオーバーヘッドが最小限であれば、イベント処理に大きな遅延が生じる可能性があります。Resolution01 スケジュール済みジョブ「イベント管理 - プロセスイベント」の問題 (パッシブノードによって停止、スタック、要求など)。 簡単な解決策は、次のようにジョブを再作成することです。 「イベント管理>設定>プロパティ」に移動します[イベントを処理するスケジュール済みジョブの数] オプションを検索し、現在の値とは異なる数に更新して保存します。 上記は、アクティブなノードによって要求されるジョブを再作成します。この値は後で元に戻すことができます。 イベント管理は、デフォルトでは、過去 2 日以内に作成されたイベント (現在のシャードと前のシャード) を処理します。そのため、ジョブが正常に再作成された後でも、処理されない古いイベントが発生する可能性があります。イベント管理がすべてのシャードでイベントを処理するように、この動作を変更できます。次のプロパティを設定すると、2 日以上経過したイベント管理プロセスイベントが含まれます (すべてのシャードでイベントを処理します)。イベント処理が追いついたら、デフォルトの動作に戻すことをお勧めします。 evt_mgmt.events_processing_all_shards = true 02 ノードキャッシュが同期されておらず、1 つ以上のノードにノード数に関する誤った情報があります。 キャッシュをフラッシュするには、ナビゲーションフィルターに「cache.do」と入力します。 03 カスタムビジネスルールとスクリプトインクルードにより、イベント処理に余分なオーバーヘッド遅延が追加されます カスタムビジネスルールとスクリプトインクルードにタイミングロジックを追加して、各イベントに追加された遅延を確認します。スケジュール済みジョブのイベントレートとイベント処理サイクルを考慮し、カスタマイズを可能な限り最適化します。Related Linksイベント管理イベントプロセスフローのレビューについては、次のドキュメントを参照してください。 イベントプロセスフロー イベント処理ジョブの作成に関する次の情報にも注意してください。 イベント処理ジョブの作成方法: デフォルトでは、(特定のノードに関連付けられていない) 1 つのジョブを作成します。[マルチノードイベント処理を有効にする] は false で、[イベントを処理するスケジュール済みジョブの数] は 1 です。これらのプロパティのいずれかが変更されると、ビジネスルール「イベント管理 - スケジュール済みジョブの作成」によって古いジョブが削除され、新しいジョブが作成されます。[マルチノードイベント処理を有効にする] を [はい] に設定すると、特定のノードに関連付けられたジョブが作成されます。今後は、ノードが起動/停止/追加/削除するときに削除/挿入するのはプラットフォームの役割です。 イベントが READY ステータスで、過去 2 日以内に作成された場合 (イベントは 7 日間のローリングテーブルで、今日と昨日のイベントのみを処理します) を処理するため、2 日より前にステータスが READY のイベントがある場合、イベントは処理されません。ロンドンから、そのようなケースで共有されるすべてのテーブルを処理するかどうかを制御できるプロパティがあります(PRB PRB1235220を見てください。イスタンブールでは、これらすべてのイベントを再度作成するしかありません(ただし、順序が正しくならず、間違ったアラートステータスなどで終了する可能性があります..)イベント管理には、実行する処理ジョブの数を構成するための 2 つのオプションがあります [イベント管理] プロパティで、[マルチノードイベント処理を有効にする] の場合、false の場合、ジョブの数は [イベントを処理するスケジュール済みジョブの数] プロパティで定義された数である必要があります。[イベント管理] プロパティで、[マルチノードイベント処理を有効にする] が true の場合、ジョブの数は、[イベントを処理するスケジュール済みジョブの数] プロパティで定義された数値にアクティブなノード (ステータスが「オンライン」でスケジューラーが「任意」のノード) を掛けた値である必要があります。つまり、実行するように定義された 2 つのジョブで、2 つのアクティブノードがある場合、ジョブの数は 2*2=4 + 2 (「システム ID」=「すべてのノード」のノードごとに別のジョブ) = 6 である必要があります。 READY状態のイベントがある場合は、ジョブの数が正しいかどうかを確認する必要があります(上記のEMプロパティに従って)。正しくない場合は、[イベントを処理するスケジュール済みジョブの数] で定義されている数を変更してから (たとえば、2 から 3)、古い数に戻してみてください。これで問題は解決するはずです。(古いジョブを削除し、新しいジョブを作成)このような状況 (プロパティを変更して新しい処理ジョブを作成する) があり、過去 2 日以内に QUEUED 状態のイベントがある場合は、これらのイベントを READ 状態に変更すると、処理する必要があります。ジョブの数が正しくない場合(またはジョブがまったく実行されていない場合)、ほとんどの場合、プラットフォームの問題です(ノードがダウンしたときにプラットフォームによってジョブが削除/挿入される必要があります)。 関連リンク インシデントの作成が遅れたか、アラートからインシデントが作成されていない