MID サーバー関連のジョブが動かなくなり、ECC キュー入力が準備完了ステータスのままになるのはなぜですか？Issue この記事は、MID サーバーから戻った入力が処理されない理由の解明を目的としています。症状には次のようなものがあります。 プローブが返した結果である ECC キューテーブル [ecc_queue] の入力が準備完了ステータスのままになるその結果： ディスカバリースケジュールの動作が止まり、タイムアウトになるサービスマップが再検出されないOrchestration アクティビティでワークフローの動作が停止するイベントがイベント管理に保存されなくなるインポートセットに JDBC データソースからのデータが届かないMID サーバー関連リストがスレッドリストなどの統計情報で更新されない。さらに他の影響もあります。 Resolutionセンサーが非アクティブである ステータスを [準備完了] から [処理済み] に変更する入力には、「センサー」が必要です。センサーは常に ecc_queue テーブルの挿入ビジネスルールとして実装されます。MID サーバーを使用する初期設定の機能のほとんどには、次のようなセンサーがあります。 機能ビジネスルールディスカバリープローブディスカバリー - センサーOrchestration アクティビティオートメーション - センサーMID サーバーシステムMID - ハートビート、MID - プロセス XMLStats などインポートセットJDBCProbeSensorイベント管理イベント管理 - コネクタ統合ECC キューの再試行ポリシー ソリューション：ビジネスルールがアクティブであることを確認します。 バージョン関連リストをチェックして、ビジネスルールがカスタマイズされているかどうかを確認し、初期設定のバージョンに戻します。 センサーがない センサーがない場合、入力は準備完了状態のままになります。結果の記録や処理の必要がない、発信のみのアウトバウンドの統合であれば、これで問題ありません。とはいえ、入力が処理されたことをマークするだけであっても、センサーを設けることがベストプラクティスです。 RESTMessageV2 または SOAPMessageV2 API からの入力の場合、初期設定の汎用センサーはありません。応答が不要であり、かつ API が executedAsync() であった場合は、これらも無視できます。しかし、応答を処理する必要がある場合は、これらの API を使用する統合にセンサーが必要です。 ソリューション：パフォーマンスの問題を発生させずに MID サーバーを非同期で使用できるよう、センサーを実装します。ServiceNow KB：RESTMessageV2 および SOAPMessageV2 向けベストプラクティス (KB0716391) 注意：初期設定の SystemCommand プローブには、センサーがなく入力が準備完了ステータスのままであることが想定されるものがあります。その中には次のような一般的なプローブなどが含まれます。clear_cookiescredentials_reloaddeleteExpiredIHubPlansrange_cacheresetQueryWindowsignature_validation_certs_reloadupdateConfig スケジューラーワーカーにバックログが溜まっている... MID サーバーは、インスタンスの API-INT セマフォを使用して入力を SOAP 経由で ECC キューに挿入します。これらの入力をブロックしないよう、ほとんどのセンサービジネスルールは「非同期」で実行されます。つまり、スケジューラーワーカースレッドで実行されます。バックログは次の方法で確認できます。 [システム診断] に移動します。ページで [システムの概要] を見つけます。スケジューラーがバックアップされている場合、[処理待ちイベント] は赤で表示されます。 キューに格納されているものを正確に把握するために、スケジューラーテーブル [sys_trigger] に準備完了ジョブと実行中のジョブがあり、ecc_queue 関連ジョブにはセンサービジネスルールと類似の名前が付けられます。例えば、「ディスカバリー - センサー」ビジネスルールは、「ASYNC: Discovery - Sensors」という名前の sys_trigger レコードを作成します。それらが存在するかどうかを確認できます。 [システムスケジューラー] -> [スケジュール済みジョブ] に移動します。次のフィルターを追加します。 ステータスが準備完了、またはステータスが実行中次のアクションは今日次のアクション「相対指定」が 1 分以上前 最終的に、次のようなリスト URL になります。/sys_trigger_list.do?sysparm_query=stateIN0,1^next_action>javascript:gs.endOfYesterday()^next_actionRELATIVELE@minute@ago@1 これにより、今日のスケジューラーワーカージョブのバックログが得られます。センサーがわかっている場合は、[名前に含まれるもの] でフィルタリングできます。 ジョブが [準備完了] ステータスにある場合は、まだ実行されていません。考えられる原因：- ...インスタンスがワークロードに対応していないため スケジューラーワーカースレッドは共有リソースであり、プラットフォーム内のすべての非同期ビジネスルールとスケジュール設定済みジョブが使用するため、MID サーバーのジョブとはまったく関係のないものによって処理の遅延やブロックが発生する可能性があります。 上のリストは、スケジューラーキューの名前と経過時間の概要を示したものです。これをステータスが「実行中」のジョブだけにフィルター処理すれば、現在スケジューラーワーカーで実行されているものがわかります。 ソリューション：リストから実行時間の長いジョブを特定できる場合や、類似した即時実行ジョブの大量実行のためキューが実質的にブロックされていることが判明する場合があります。 現在実行中のものを確認することで、正常に機能しているかどうか調査すべきジョブを特定できます。例えば、非常に大規模なインシデントのバッチ更新によって、CMDB オーナー向けメール通知の膨大なカスケードがトリガーされる可能性があります。見つかるかもしれない原因はさまざまです。 バックログが特に悪化している場合は、サポートインシデントをオープンしてバックログの原因を特定することを検討してください。 しかし、現在何も実行されていない場合は... ...インスタンスが一時停止しているため 通常、スケジューラーはアップグレードによってのみ一時停止し、後から自動的に再開します。 これを確認するには、アドミンユーザーとしてバックグラウンドスクリプトを実行します。 [システム定義] -> [スクリプト - バックグラウンド] に移動します。[スクリプトを実行 (JavaScript はサーバーで実行)] ボックスにこのスクリプトを貼り付けます。 gs.log(gs.isPaused()); [スクリプトを実行] をクリックします。 「true」が返された場合は、誰か (何か) がワーカーを一時停止させているため、ジョブが処理されなくなっています。 ソリューション：インスタンスが現在アップグレードの途中ではないことを確認します。[システム診断] -> [アップグレードモニター] に移動し、アップグレード中の場合は終了まで待ちます。 インスタンスがアップグレードの途中でない場合は、問題が発生しているため、サポートインシデントをオープンする必要があるでしょう。 トピックは LDAPConnectionTesterProbe で、55 秒以上かかりました デフォルトでは、MID サーバーを使用する LDAP サーバーの「テスト接続」機能は、結果が出るまで 55 秒しか待機しません。これは定期的に実行され、LDAP サーバーフォームのリンクをクリックすると実行されます。 プローブの入力がインスタンスに戻るまでにそれ以上の時間がかかる場合、入力の処理を待機していたコードが既に待機を放棄しているため、その入力は [準備完了] ステータスのままになります。 参照：KB0743756/PRB1331240 LDAP「テスト接続」および「ブラウズ」機能がタイムアウトし、標準で実行されているため LDAP モニターの接続ステータスが「未接続」と表示される (2) MID サーバーの優先度：55 秒待っても MID サーバーの応答がありません センサーがクラッシュした 時折、センサーが実行されているものの、ステータスが [処理中] または [処理済み] に更新される前にクラッシュしてしまうケースがあります。この場合、[エラー文字列] フィールドに理由が入力されることはほとんどありません。 ソリューション：多くの場合、システムログまたはアプリノードの localhost ログを確認することが、何が起こったかを確認する唯一の方法です。次に、見つかったエラーに関連する既知の問題をナレッジベースで検索します。 入力ペイロードデータが大きすぎる 入力ペイロードが特に大きい場合、SOAP テーブル API は値を実際のレコードのペイロードフィールドではなく、添付ファイルに移動します。その添付ファイルもプラットフォームの上限を超えてしまう場合、添付ファイルは保存されません。添付するとセンサーがクラッシュする可能性があります。 添付ファイルが作成された場合、大量のデータの解析と処理のためセンサーに問題が発生することがあり、実行時間が長くなったり、メモリの問題が発生したりして、センサーに障害が生じる可能性があります。 ソリューション：さまざまなシステムプロパティによって上限を上げることができますが、複数のジョブをデータのサブセットに対して実行することで入力サイズを小さく保つジョブを実装する方がよいでしょう。 ドメイン分離にセンサーが依存する非表示のレコードがある 通常、関連するすべてがグローバルドメインにある場合や、すべてが同じドメインに属している場合には、問題になりません。ただし、MID サーバーとデータが異なるドメインにある場合は、センサーが MID サーバーユーザーのドメインとして実行されるときに問題が発生する可能性があります。例えば、親ドメイン内のタスクに対して実行されているワークフローコンテキストが、ジョブのために子ドメイン内の MID サーバーを使用する場合です。子ドメインで実行されるセンサーでは親ドメインのレコードを確認できないため、センサーが停止します。 ソリューション：各ドメインに専用の MID サーバーをインストールし、各 MID サーバーの [アプリケーション]、[ケイパビリティ]、[IP 範囲] を入力して、自動的に選択されるようにします。一般に、リーフドメインの MID サーバーの方が、ドメインツリーの中間レベルの MID サーバーよりも効率的に動作します。