ECC キューレコードを特定の機能またはジョブにリンクする方法Issue MID Server 経由で実行されるすべてのジョブ、およびそうでない一部のジョブは、ECC Queue テーブル [ecc_queue] を介してメッセージをやり取りします。Agent Correlator フィールド [agent_correlator] は、発生元のジョブを追跡するためにコードによって使用されます。 このリストは決して包括的なものではありませんが、ECC Queue レコードをそのレコードの発生元であるジョブにリンクし、関連するコードを理解するのに役立つはずです。プローブの起動に関係するコード、MID Server 上で実行されるプローブコード、およびインスタンス側のセンサーコードは、通常、その特定の機能を担当するチームが所有しており、MID Server プラットフォームは、それらを単に Java スレッドで実行しているだけです。 注: Zurich リリースまでに、ほとんどの OOB のレガシー Orchestration ワークフローは IntegrationHub フローへ移行されています。このドキュメントは、そうした変更のすべてに対してまだ更新されているわけではありません。 目次 IT Operations Management ITOM Visibility - Cloud License EstimatorITOM Visibility - Discovery / Service MappingITOM Visibility - Help The Helpdesk (HTHD)ITOM Visibility - Test CredentialITOM Visibility - Agent Client Collector - Visibility Content (ACC-VC)ITOM Visibility - Kubernetes Visibility AgentITOM Optimization - Cloud ManagementITOM Health - Event ManagementITOM Health - Synthetic MonitoringITOM Health/Visibility: Agent Client Collector Framework (ACC-F) / Visibility (ACC-V) / Monitoring (ACC-M)ITOM Health - Health Log AnalyticsITOM Health - Operational Intelligence Integrations AttachmentCreator SOAP web serviceCommand probeDevOps Change VelocityExport SetsImport Set / JDBCIntegrationHubJavascriptProbeLDAPOAuth2 Credential Token refreshOrchestrationOutbound REST / SOAPSyslog Integration3rd party: IT Service Management Agent Client Collector for Security Incident ResponseDigital End-User Experience (DEX)Employee Document ManagementMicrosoft Exchange Online for Security OperationsSecurity Incident Response Now Platform Source ControlMID Server IT Operations Management ITOM Visibility - Cloud License Estimator これは RESTMessageV2 をインスタンスから直接同期的に使用するため、ECC キュー経由では機能しません。送信 HTTP ログ [sys_outbound_http_log] に記録された要求を確認できます。 ITOM Visibility - Discovery / Service Mapping ECC キュートピック: ADMEPowershell アプリケーション依存関係マッピング専用の Windows PowerShell ベースのプローブ。 APIProxyProbeCimProbeCommand MID Server ホストのシェル (Linux) またはコマンドプロンプト (Windows) から[名前] フィールドのコマンドを実行します。 CommandPipelineDNSDNSLookupProbeDNSNameResolverHorizontalDiscoveryProbe source フィールドのターゲットサーバーに対して、name フィールドで指定された Discovery または Service Mapping パターンを MID Server 上で実行します。 HTTPClassyProbeJavascriptProbe ペイロードの script パラメーターから JavaScript を実行します。通常は MID Server Script Include [ecc_agent_script_include] を呼び出します。 MultiProbe 他の複数の Discovery プローブを含むプローブ PatternDebuggerProbePowerShell MID Serverで PowerShell スクリプトを実行します。これにより、ターゲットに対して処理が実行されます。 RCASmcPurgeProbeServiceDiscoveryProbeServiceWatchTraceRouteProbe ネットワークパス決定プロセスの一環としてターゲットホストから IP への ping と traceroute を実行します。 Shazzam Discovery 用のポートスキャナー SNMPSSHCommandTrafficBasedDataCollectionUnixURLCertificateScanProbe 証明書検出。名前は「URL 証明書スキャン」。 VMWareProbeWindowsCommand ソースフィールドのターゲットサーバーのコマンドラインでコマンドを実行します。 WMIRunner ソースフィールドのターゲットサーバーのパラメーターで指定された Windows Management Instrumentation (WMI) 名前空間からデータを取得します。 Agent Correlator: Discovery Status レコード [discovery_status] の sys_id ソース: プローブによって異なります。IPアドレスをDiscoveryステータス内の特定のDiscoveryデバイス履歴 [discovery_device_history] レコードに関連付けることで、CMDB CIを特定できます。 Sensors: Discovery - Sensors Priority : Interactive: パターンデザイナーのデバッグモード、ディスカバリーのキャンセル、XMLStatsExpedited: 標準優先度スケジュールのサービスマッピング、今すぐ検出、クイックディスカバリー、Shazzam ポートスキャンプローブ。Standard: スケジュール済み水平ディスカバリー (Shazzam を除く) ITOM Visibility - Help The Helpdesk (HTHD) 公式にはほぼ 10 年間非推奨になっていますが、このプラグインはディスカバリーの一部として自動的にインストールされます。 Zurich 以降、プラットフォームの Java の変更により、現在は使用できません。 KB3140095 Help The Help Desk (HTHD) does not work since Zurich ECC キュートピック: WMILoader (入力のみ) エージェント: wmi 名前: wmi.script ソース: レコードを ECC キューに送信した Windows コンピューターのホスト名 Sensor Business Rule: ECC キューリーダー - WMILoader.java で GlideappWMILoader を使用する非同期ビジネスルール ITOM Visibility - Test Credential 注意: これは Discovery スキャンでの認証情報の使用方法を前提として認証情報をテストするための Discovery 機能です。テストが何をテストしているのかを完全に理解しないと、テスト結果は誤解を招くことがよくあります。たとえば、Windows 認証情報をテストする場合、デフォルトで入力された WMI ポート 135 は実際には無視され、実際には、New-CimSession を使用してリモート PowerShell 接続の作成が試行されるため、他のほとんどのユースケースでは役に立ちません。 ECC キュートピック: CommandPipeline ソース: 認証情報がテストされているホストの IP アドレス ペイロード type="TestCredentialCommand" が含まれます ITOM Visibility - Agent Client Collector - Visibility Content (ACC-VC) ACC-F の一般的な説明を参照してください。ただし... ACC を介した Discovery Pattern ドキュメント:Application patterns for the Agent Client Collector ACC-V は、拡張ディスカバリーチェックから実行中のプロセスのリストを取得すると、それらをディスカバリーのプロセス分類子と比較し、Application Pattern をトリガーできます。ディスカバリーパターンは MID Serverで実行されますが、これは ACC-V の場合にも当てはまります。ECC キューレコードはよく似ています。通常であれば MID Server がターゲットの管理インターフェイスに接続するほとんどの操作では、代わりにエージェント自身でコマンドを直接実行するよう指示されます。主なレコードの違いは、discovery_status がないため agent_correlator がなく、ペイロードにエージェント ID のパラメーターが含まれることです。 トピック: HorizontalDiscoveryProbe 名前: Pattern Launcher:<パターン名> ペイロード: agent_id パラメーターが含まれます。これにより、どの Agent インストールで手順を実行するかを MID に通知します。 ソース: エージェントの IP アドレスの 1 つ。 Agent Correlator: 空 (このシナリオでは参照する discovery_schedule がありません) 送信元ホスト: 空。(ただし、agent_id、または特定のエージェント用であることを明確に示すその他の手がかりが含まれていて、エージェントフォームで [ECC キューを表示] がクリックされたときに一覧表示されれば便利です (拡張未定)。 センサー: ディスカバリーから再利用された Discovery - Sensors business rule 注意:パターンログ [sa_pattern_log] が通常どおり生成されます。これは、ディスカバリービューのエージェントフォームの関連リストに表示されます。この関連リストは Source IP を基に動作します(その IP は Agent レコードの IP ではない可能性があります)。 - TBC ITOM Visibility - Kubernetes Visibility Agent キュートピック: k8s_informer 詳細については次を参照してください。KB2717556 Understanding Kubernetes Visibility Agent ECC Queue records, and Sensor business rulesKB1580241 Controlling the number of "Kubernetes Visibility Agent" (formerly CNO for Visibility) concurrent worker threads ITOM Optimization - Cloud Discovery - Direct from Instance ECC キュートピック: RESTProbeSigningRESTProbeAWSRESTProbe エージェント: mid.server.NODE_AGENT Agent Correlator: TBC ITOM Optimization - Cloud Management ECC キュートピック: TBC Agent Correlator: TBC ITOM Health - Event Management ECC キュートピック: ConnectorProbeMIDExtension:VCenterExtensionMIDExtension:TrapListenerExtensionMIDExtension:PipelineManagerMIDExtension:WebServerExtension Agent Correlator: 空 ソース: コネクタの場合は、コネクタインスタンスの名前 [em_connector_instance] 名前: MID Server Extension の場合は、拡張名、および Context Name と sys_id [ecc_agent_ext_context] センサー: 「イベント管理 - コネクタ」ビジネスルールは ConnectorProbe を処理し、「MID Server Extensionステータスの処理」ビジネスルールは MIDExtension を処理します。 ITOM Health - Synthetic Monitoring Docs: Synthetic Monitoring チェックの「場所」に応じて、次のいずれかの要求が送信されます。 ホストされている場所 (インスタンスから直接) [現在のインスタンス] は ECC キューを使用しません。送信 HTTP ログ [sys_outbound_http_log] に記録された要求を確認できます。 MID Server トピック: JavascriptProbe 名前: SyntheticMonitoringCheckRunner ペイロード: synthetic_params: Base64 でエンコードされた値です。デコードすると、以下の値を含む JSON オブジェクトになります。 ci_sys_idlocation_sys_idheaderssynthetic_check_sys_idhttpMethodcredential_sys_idurl センサー: ecc_queue の「Synthetics Mid Runner Result Processor」ビジネスルール (名前 = SyntheticMonitoringCheckRunner)。これは、ServiceNow Fluent コードスクリプトの関数 midRunnerResultProcessor を使用します。 Agent Client Collector これらのプローブは、「<check name>-synthetics bg job」という名前のsn_sow_synthetics_check_single_api_sysauto_script スケジュール済みスクリプトによって sys_trigger を介してトリガーされます。 ECC キュートピック: MonitoringProbe ペイロード: チェックは「sow-synthetic.monitoring」です。 このチェックは、URL に対してSynthetic API リクエストを実行し、Synthetic Definitionに基づいてメトリクスとイベントの両方を書き込むために使用されます。このチェックの各インスタンスは、異なるコマンド引数を持つSynthetic Applicationによって作成および管理されるため、定義のコマンドは空であることに注意してください。 センサー: MID Server: SnytheticMonitoringHTTPResultParser。ACC synthetic plugin の synthetic-monitoring HTTP check の JSON 結果を解析して、メトリクス、イベント、および結果レコードに入力します。インスタンス:AgentNowHandler スクリプトインクルード、processEccRecord 関数を使用する AgentNowResponseProcessor ビジネスルール。 "SOW Synthetic Monitoring" sn_agent_check_type は、ServiceNow Fluent コードスクリプトからの checkTypeHandleBatchUpdate を使用します。 ITOM Health/Visibility: Agent Client Collector Framework (ACC-F) / Visibility (ACC-V) / Monitoring (ACC-M) エージェント: mid.server.<A MID Server Name> - ACC はオンプレミスの MID Server 経由で接続しています。次を参照してください。 Agent Client Collector アーキテクチャ mid.server.acc-cnc - ACC は MID-less で、ServiceNow のデータセンター (ACC CnC) のリージョン ITOM クラウドサービスゲートウェイを介して接続します。次を参照してください。 Configure MID-less Agent Client Collector for DEXDEX アーキテクチャ ECC キュートピック: MonitoringProbe Name/Source = on_demand_request ペイロードには、ACC で実行するチェックの名前と、チェックを実行するエージェント ID が含まれます。 ペイロードは、どの機能、チェック、エージェントが関与しているかを示す唯一のフィールドです。多くの場合入力は、ペイロードフィールドに対して大きすぎるため、最終的に payload.txt 添付ファイルにされてしまいます。つまり、ECC Queue リストで payload contains フィルターを使用すると、該当レコードを見落とします。入力内容を確認するには、添付ファイルを開く必要があります。 Name/Source = config_publish/policy_deleted sn_agent_ci_extended_info レコードの running_checks_num を更新します。Sensor business rule:MonitoringProbeSensor Name/Source = auto_mid_selection MID Server フォームの Try redistributing connected agents UI アクション センサー インスタンス:AgentNowHandler スクリプトインクルード、processEccRecord 関数を使用する AgentNowResponseProcessor ビジネスルール。sn_agent_check_type レコードは、ペイロードで指定されたチェックタイプを、そのチェックタイプのセンサーとして実行されるスクリプトインクルードにマッピングします。たとえば、「EnhancedDiscovery」タイプは EnhancedDiscoveryHandler スクリプトインクルードを使用します。「ACC Spoke」は sn_acc_spoke_action_response 内のレコードを更新するだけです。 DataInputMarkerProbe / DataInputExamplesProbe /DataInputConnectorPortCheckProbe Log Analytics で使用 MIDExtension:MonitoringExtension 拡張の停止と開始 センサー: すべての MonitoringProbe 入力は、どの機能であっても、最初に AgentNowResponseProcessor ビジネスルールによって処理されます。sn_agent_check_type レコードは、ペイロードで指定されたチェックタイプを、そのチェックタイプのセンサーとして実行されるスクリプトインクルードにマッピングします。 ITOM Health - Health Log Analytics ECC キュートピック: queue.log_streaming.stats MID のストリーミングソース統計データを収集し、インスタンスにレポートします。このデータはインスタンスの sn_occ_log_streaming_sources テーブルで使用できます。 queue.log_analytics.stats MID のログ分析サービスからメトリクスを収集し、インスタンスにレポートします。これらのメトリクスはインスタンスの xmlstats.do に反映されます。 MIDExtension:DataInputWrapperExtension MID Server Extensionの停止/開始など DataInputTestConnectionProbe データ入力をテストします。 DataInputMarkerUpdate マーカーサービスからの定期的な入力 ACC-L については、ACC のセクションを参照してください。 ITOM Health - Operational Intelligence Synchronize configuration settings rules ECC キュートピック: MetricConfigProbe - Metric Configuration Rules を MID Serverに同期します。 TBC Integrations AttachmentCreator SOAP web service AttachmentCreator SOAP web service 重要: AttachmentCreator SOAP web service は推奨されません。代わりに、Web サービスで添付ファイルを管理するには REST Attachment API を使用してください。 ECC キュートピック: AttachmentCreator 名前: 添付するファイルの名前とそのコンテンツタイプ。 ソース: 添付ファイルを追加するレコードの「<table>:<sys_id>」 ペイロード: 添付するバイナリオブジェクトを表す base64 でエンコードされた文字列。 Sensor business rule: AttachmentCreatorSensor Command probe 注意:これは通常、デバッグにのみ使用し、本番統合には使用しないでください。代わりに、スクリプトまたはコマンドに必要なユーザー名とパスワードがプレーンテキストで表示されないように、暗号化されたパラメーターの受け渡しをサポートするIntegrationHub アクションまたは PowerShell プローブを使用する必要があります。 トピック Command 名前 MID Server ホストのシェル (Linux) またはコマンドプロンプト (Windows) から「名前」フィールドのコマンドを実行します。 ペイロード コマンドがフィールドに収まらないほど長い場合に、Name フィールドを上書きするための name パラメーターとして使用されます。この場合、パラメーター値は XML 形式用にエスケープする必要があるため、html エンティティにはエンコードが必要です。例 " KB2909424 Should 'Command' topic probes be used to run Powershell scripts on MID Servers? - No. DevOps Change Velocity ドキュメント:DevOps Change Velocityとサードパーティツールの統合 これらの統合のほとんどは、統合するシステム (Rally、Split IO、Argo、SonarQube、Harness、Bitbucket、GitHub、Jenkins、GitLab、Jira、Bitbucket、JFrog、Azure など) がオンプレミスで、ファイアウォールの内側にある場合、MID Server 経由で動作するように構成する必要があります。 これらは RESTMessageV2 ベースの統合のようで、ecc_queue の入力応答を待機します。Script Include DevOpsConnector の _setUpRESTMessage 関数は頻繁に再利用されています 以下の「送信 REST/SOAP」セクションを参照してください。- 未定 Export Sets ECC キュートピック: StreamPipeline (出力)ExportSetResult (入力) ペイロードパラメーター: stream_relay_response_topic=ExportSetResultstream_relay_source attachment_sys_id = エクスポートされる sys_attachment レコードの sys_id stream_relay_transform attachment.table_sys_id = ecc_agent_attachment レコードの sys_id。このレコードの source フィールドは Export Set [sys_export_set] レコードを参照します。 stream_relay_sink パス = ファイル名/パス 優先度: Standard: これは Java で設定されているため、カスタマイズできません。(BaseStreamRelay.java/submitToEccQueue) Sensor business rule: センサーがありません。これらは同期的に実行され、MID Server が処理を実行して ecc_queue input を返すのを待機している間、インスタンススレッドをブロックします。これは MID Serverを介してジョブを実行するためのベストプラクティス実装ではなく、スケジュール設定済みデータエクスポート [scheduled_data_export] ジョブからのこの種のスタックトレースでスレッドがブロックされる可能性があるため、インスタンスでワーカースレッド/セマフォの枯渇を引き起こしたことがあります。MID Serverがビジー状態の場合、MID Serverがインスタンス側のタイムアウト内にジョブを実行できなかったため、300 秒後にタイムアウトが発生することもあります。 java.base@17.0.14/java.lang.Thread.sleep(Native Method)com.glide.ecc.ECCResponsePoller.poll(ECCResponsePoller.java:57)com.glide.export_set.MIDServerResponsePoller.poll(MIDServerResponsePoller.java:31)com.glide.export_set.MIDServerExportTargetWorker.getMidServerExportSetResponse(MIDServerExportTargetWorker.java:216)com.glide.export_set.MIDServerExportTargetWorker.pollForExportSetResponse(MIDServerExportTargetWorker.java:106)com.glide.export_set.MIDServerExportTargetWorker.runExport(MIDServerExportTargetWorker.java:93)com.glide.export_set.ExportTargetWorker.export(ExportTargetWorker.java:53)com.glide.export_set.ExportSetHandler.processExport(ExportSetHandler.java:89)com.snc.automation.ScheduledExportSetJob.runExport(ScheduledExportSetJob.java:92)com.snc.automation.ScheduledExportSetJob.execute(ScheduledExportSetJob.java:54) ... 注: このコミュニティ投稿では、この機能のコードを利用して、添付ファイル (レポートの PDF だけでなく) を非同期にエクスポートする方法を提供します。コミュニティpost:レコードの添付ファイルを MID Serverのエクスポートフォルダーにエクスポートする Import Set / JDBC ECC キュートピック: JDBCProbe - 出力は 1 つですが、入力は 1 つ以上あると想定されますJDBCProbeCompletedJDBCProbeError - インスタンス側でデータソースがタイムアウトしたときに JDBCProbe の実行を停止するよう MID Serverに指示するために使用されます。 Agent Correlator: ランダムな GUID ですが、一緒に実行されるインポートセットのレコードをグループ化するために使用できます。 エージェント: 通常は MID Server 名ですが、JDBCProbe トピックの入力には、データを含む入力として「JDBCProbeResult」が含まれます。 名前: JDBCProbe の入力の場合、これは入力に含まれる行バッチの上限行番号です。最後の入力の場合は、最後の行番号になります。 ソース: データソースレコード [sys_data_source] の Sys ID Sensor business rule: JDBCProbeSensor - JDBCProbeCompleted トピックに応答します。スクリプトインクルード JDBCProbeSensor で process() を使用して、スケジューラーワーカーで「ASYNC: JDBCProbeSensor」として非同期実行します。これにより、すべての JDBCProbe 入力のデータが結合されます。 認証情報: 認証情報は、データソース [sys_data_source] レコード (ソースフィールドで参照) から取得されます。実行時にインスタンス側で、これらはそのレコード (KMF) から復号化され、MID Server用に再暗号化 (GlideAutomationEncrypter) されてから、ECC キューの出力ペイロードパラメーターに格納されます。 IntegrationHub IntegrationHubRetry Policy ECC Queue レコードにはデータ/結果が含まれていません。IPaaSActionProbe は実行されると、インスタンスの Flow Engine REST API を使用して、実行する処理の指示を取得し、結果およびデータでフローコンテキストを更新します。このプローブの実行に関する問題をデバッグするには、実行中に行われた API_INT セマフォトランザクションについて、インスタンス側の appnode localhost ログが必要になる場合があります。 ECC キュートピック: IPaaSActionProbe フローコンテキストの実行時、およびステップ/アクションのテスト時にも使用されます。 CancelProbe ペイロードには、フローコンテキストのすべてのプローブをキャンセルするように MID Serverに指示する「理由」が含まれています。例:「Cancelling flow context due to timeout」は、フローコンテキストの開始時に作成された「Cancel flow context on timeout」sys_triggerジョブによってトリガーされます。 Agent Correlator: フローコンテキスト ID [sys_flow_context] 名前: 最初に挿入されたときの MID Server の名前。別の MID Server への MID クラスターフェイルオーバーがあった場合、これは実際に実行した MID Serverと一致しない可能性があります。(MIDSender.java legacySend) ソース: フローコンテキスト ID [sys_flow_context] Sensor business rule: IntegrationHub - SensorsIntegrationHubResponderReschedule Flow インスタンス API: /api/now/hub/plan/[sys_flow_context] 注:PowerShell スクリプトを実行するステップでは、Discovery および Orchestration と同じ低レベルの MID Server プラットフォームコードをスクリプトの実行に使用します。PowerShell ステップのログ記録と mid.log.level=debug mid server パラメーターを有効にすると、PSScript.ps1 の実行内容が正確に示されます。 JavascriptProbe Cloud Discovery などの一部の機能では JavascriptProbe が使用されますが、多くのカスタム統合も JavascriptProbe を使用して実装されています。 ECC キュートピック: JavascriptProbe ソース: setSource() API メソッドによって上書きされない限り、デフォルトでは空です。 Sensor business rule: これもカスタムであり、スクリプトに固有です。 ペイロード: ペイロードには「script」パラメーターが含まれています。これは通常、プローブで使用される MID Serverスクリプトインクルード [ecc_agent_script_include] を識別します。これらのスクリプトインクルードは、インスタンスの JAR Filesテーブルの添付ファイルを介して MID Server プラットフォームに追加された Java クラスを使用することもできます。 LDAP インポート: これらはインポートセットの設定とほぼ同じように設定され、スケジュールデータインポート [scheduled_import_set]、データソース [sys_data_source] が type=LDAP、変換マップ [sys_transform_map] に設定されます。 ECC キュートピック: LDAPProbe (出力は 1 つですが、入力は 1 つ以上あると想定されます。)LDAPProbeCompleteLDAPProbeError Agent Correlator: ランダムな GUID ですが、一緒に実行される LDAPProbe のレコードをグループ化するために使用できます。 エージェント: 通常は MID Server 名ですが、LDAPProbe トピックの入力には、データを含む入力に対して Agent = "LDAPProbeResult" が付きます。これは誤解を招く (技術的に間違っています) 。注意:エージェントでecc_queueテーブルをフィルタリングしている場合は、これらを見逃します。 名前: 入力に含まれる行バッチの上限行番号、または最後の入力の場合は最後の行番号。 ソース: データソースの Sys ID [sys_data_source] Sensor business rule: TBC 優先度: 標準 リスナー: ECC キュートピック: LDAPListenProbe 出力 + LDAPListenProbeCompleted 入力 (停止/開始コマンド用)LDAPListenProbe 入力 (ユーザー変更用) Agent Correlator: ランダムな GUID ですが、実行のレコードをグループ化するために使用できます エージェント: 通常は MID Server 名ですが、LDAPListenProbe トピックの入力には、データを含む入力に対して「LDAPListenProbeResult」が含まれます。これは誤解を招く (技術的に間違っています) 。注意:エージェントでecc_queueテーブルをフィルタリングしている場合は、これらを見逃します。 名前: LDAPListenProbe 入力の場合、これは入力に含まれる行バッチの上限行番号です。最後の入力の場合は、最後の行番号になります。LDAPListenProbe 出力。これは Stop または Start です ソース: LDAP サーバーレコード [ldap_server_config] の Sys ID Sensor business rule: LDAPListenProbe 入力は、リスナーがユーザーデータの変更をインスタンスに送信するときに、ビジネスルール「MID 変更時に LDAP リスナーを処理 (Process LDAP Listener on MID changes)」を使用します。LDAPListenProbeCompleted にはセンサーがありません。これらは同期的に実行され、MID Server が処理を実行して ecc_queue input を返すのを待機している間、インスタンススレッドをブロックします。 優先度: 標準 テスト接続: ECC キュートピック: LDAPConnectionTesterProbe Agent Correlator: ランダムな GUID。ただし、一緒に実行される LDAPConnectionTesterProbe のレコードをグループ化するために使用できます エージェント: MID Server 名。 名前: テストに失敗した場合でも、入力の値が「true」になります。(未定) ソース: LDAP サーバーレコード [ldap_server_config] の Sys ID ペイロード: 結果、またはエラーコード。MID Serverエージェントログでエラーの詳細を確認する必要があります。 Sensor business rule: LDAPConnectionTesterProbe にはセンサーがありません。これらは同期的に実行され、MID Server が処理を実行して ecc_queue input を返すのを待機している間、インスタンススレッドをブロックします。 優先度: Expedited: これは、タイムアウト (55 秒間待機しても MID Serverからの応答が得られませんでした) の可能性を減らすために、高い優先度で実行されます。タイムアウトにより、実際の接続の問題がないときに誤ったアラートが発生する可能性があり、また、MID Serverからの応答を待機してインスタンススレッドがブロックされる時間を最小限に抑えるのにも役立ちます。(PRB1331240) ブラウズ: ECC キュートピック: LDAPBrowseProbe Agent Correlator: ランダムな GUID。ただし、一緒に実行された LDAPBrowseProbe のレコードをグループ化するために使用できます エージェント: MID Server 名 ソース: LDAP サーバーレコード [ldap_server_config] の Sys ID Sensor business rule: センサーがありません。これらは同期的に実行され、MID Server が処理を実行して ecc_queue input を返すのを待機している間、インスタンススレッドをブロックします。 優先度: Expedited: これは、タイムアウトの可能性を減らすために高い優先度で実行され、MID Serverからの応答を待ってインスタンススレッドがブロックされる時間を最小限に抑えます。(PRB1331240) ディテール: LDAP クエリを発行して要素の詳細を取得します。 ECC キュートピック: LDAPDetailProbe OAuth2 Credential Token refresh Xanadu 以降では、権限許可タイプによっては、インスタンスから直接トークン URL に要求するのではなく、MID Server 経由で OAuth2.0 認証情報トークンを更新することが可能です (おそらく必要ですが、未定)。これは、認証情報レコードで [MID Server 経由で認証サーバーに接続] [use_mid] フィールドが選択されている場合に発生します。 トピック: RESTProbe 名前: post ソース: トークン更新 URL。OAuth エンティティプロファイル (TBC) の OAuth トークン URL の可能性あり ペイロード: パラメーターには transaction_name=Refresh OAuth Tokens - system が含まれます 優先度: インタラクティブ Orchestration ECC キュートピック: JDBCOrchestrationProbeJDBCOrchestrationProbeCompletedPowerShellSSHCommandSystemCommandCommandPipeline SFTP アクティビティで使用 Command MID Server 上でローカルコマンドを実行します。 DNSNameResolver 完全修飾ドメイン名 (FQDN) を IP アドレスに解決します。 SCPCommand マシン間でファイルを安全にコピーします。 SSHCommandLong SSH 経由でターゲットマシンにログインした後、コマンドラインから長時間実行されるシェルスクリプトを実行します。 Agent Correlator: ワークフローコンテキスト [wf_context] レコードの Sys ID。プリフィックス「rba.」が付いています。 ソース: Powershell:ターゲットホスト名JDBCOrchestrationProbe/JDBCOrchestrationProbeCompleted:空 Sensor business rule: 自動化 - センサー Quebec ドキュメント:廃止:Orchestration アクティビティ:Orchestration で使用されるプローブ Outbound REST / SOAP KB0694711 Outbound REST Web Services RESTMessageV2 and SOAPMessageV2 execute() vs executeAsync() KB 記事の最後にある「RESTMessageV2: MID Server, executeAsync(), setEccParameter('skip_sensor', 'true'), setEccCorrelator()」セクションは、MID Server 経由の Outbound REST/SOAP を実装する唯一の正しい方法 ですが、インスタンススレッドを危険なほどブロックする同期実装が数多く見られてきました。 ServiceNow の一部機能にもこの実装が見られます。 ECC キュートピック: RESTProbe (RESTProbe は実際のプローブではないため、MID Server内で MIDWorker スレッドとして実行されます。)SOAPProbe Agent Correlator: API の setEccCorrelator() メソッドを使用して設定しない限り、デフォルトでは空です。 ソース: REST エンドポイントの URL (API の setEccParameter() メソッドによって上書きされた場合を除く)。 エージェント: mid.server.<実際の MID Server 名> - これがジョブを処理する MID Serverになります。 次の 3 つの値は、MID Serverを経由せずに、インスタンスによってエンドポイントに直接実行されるジョブの値です。RESTClient:出力 ECC キューレコードの挿入によってトリガーされる「RESTClient」ビジネスルールによってインスタンス内で処理されます。SOAPClient - これは、ecc_queue への挿入時にインスタンスによって、SOAPMessageV2() および .execute(); を呼び出す "SOAPClient" ビジネスルールによって同期的に処理されます。 システムプロパティ glide.processor.debug.SOAPProcessor=true の場合、アプリノードの localhost ログは、そのビジネスルールによって実行されている送信要求のデバッグを提供します。ログで「OUTBOUND_HTTP:」と「SOAP Msg Outbound」を検索します。インスタンステーブルの [システムログ] --> [送信 HTTP 要求] でもログ記録を確認できます。 「mid.server.NODE_AGENT」は、MID Serverを経由しない、インスタンスからの要求も示します。 Sensor business rule: 通常はカスタム、またはエンドポイントに固有です。「Process Get Stock Quote」は、SOAPClient のインスタンスから直接実行されるジョブのすぐに利用可能なセンサーの一例です。waitForResponse() がベストプラクティスに従わない方法で使用されているか、応答を先に取得しておく必要がある応答用の呼び出しメソッドが使用されているため、センサーが存在しないことがよくあります。 Stream Connect Core / Instance Data Replication (IDR) ドキュメント: Stream Connect Message Replication この機能は、ServiceNow Hermes との間でメッセージキューをレプリケートし、MessageReplicationExtension Java クラスを使用する MID Server Extension を使用します。 ECC Queue Topics: MIDExtension:MessageReplicationExtension Kafka タイプの Connection & Credential Aliases レコードがあります。MID Server または負荷分散 MID Server Cluster が定義された、Kafka Connection タイプの Connections レコードが存在します。 Syslog Integration ドキュメント: Syslog プローブWikipedia: Syslog このプローブは、標準の UDP プロトコルを使用して UNIX syslog メッセージを送信する機能を実装しています。オプションの構造化データ表現を除いて RFC 5424 を実装し、個別のログメソッドを通じて RFC 3164 も実装します。 ECC キュートピック: Syslog ペイロード: syslog ホストとメッセージのパラメーターが含まれています。 注意: このプローブには最低限のログ記録しかなく、追加のデバッグログを有効化することはできません。mid.log.level=debug では、ログは追加されません。 このプローブが実際に何をしているのかを調査するには、MID Server ホストに Wireshark などのネットワークパケットスニファーをインストールし、ターゲットが localhost でない場合はターゲットサーバーにもインストールする必要がある場合があります。Syslog プロトコルは UDP、ポート 514 です。 3rd party: これらのツールは、ServiceNow のコードや ServiceNow のサポート責任ではありません。MID Server プラットフォームまたは Java バージョンの変更により動作しないことが判明した場合は、代替手段を探す必要があります。重要な Java コードのセキュリティ機能をオフにして、メンテナンスされていない 10 年前のコードを実行させることは、適切な解決策ではありません。 SNFilePoster / CrossfuzeFilePoster / KSFilePoster これらの JavascriptProbe Integration は、同じ元の script を基にしているようで、Apache HttpClient パッケージを使用して /sys_import.do インスタンスページへ直接リクエストを行い、レコードを XML としてインスタンスにアップロードします。元のソースは不明ですが、少なくとも 2010 年から存在しています。主な問題は次の 2 点です。 this.getConfigParameter() を使用して mid.instance.username と mid.instance.password を読み取りますが、Zurich Patch 11 / Australia Patch 4 へのアップグレード後は機能しません。これにより、2026 年にサポートケースが発生しています。MID Server がインスタンスの認証に常に Basic Auth を使用することを前提としていますが、これは今後 iPKI または mTLS を優先して非推奨になる予定です。近年、お客様が mTLS に移行した際に、この問題による障害がすでに確認されています。 HTTP クライアントの URL とユーザー認証を設定する以下のコードにより、両方の問題を回避できます。これは同様の問題があった IntegrationHub Step から取得したものです。 var Instances = Packages.com.service_now.mid.services.Instances;var primaryInstance = Instances.get().getPrimaryInstance();this.instanceUrl = primaryInstance.getURL();this.httpClient = primaryInstance.getHTTPClient(); JDBC ファイルローダー ECC キュートピック: JavascriptProbe 名前: JDBCFileLoaderProbe これは MID Serverスクリプトインクルードの名前です。 ソース: ファイルソースレコードの sys_id Sensor business rule: JDBCFileLoaderSensor スクリプトインクルード ImportSetUtilPlus を使用する非同期ビジネスルール ファイルビルダー FTP これは、2014 年に Jason Petty によって開発された ServiceNow プロフェッショナルサービス製品で、更新セットとして ShareNow で共有されました。2024 年現在、この設定に使用される定義テーブルとフォームを説明する ビデオチュートリアル が YouTube に残っています。このプローブをトリガーするコードは、通常、スケジュール設定済みスクリプトで FileBuilderFileCopyES スクリプトインクルードを呼び出すものです。ECC キュートピック: JavascriptProbe 名前: FileBuilderFileCopy Remote File Importer これはもともとパートナーの Cloud Sherpas (現 Accenture) によって作成され、開発者サイトで共有されています。 開発者サイト: Remote File Importer (Import Files from a MID Server)コミュニティサイト: Getting Error in "Input ECC Queue" as "No sensors defined". I am getting this when trying to execute one of the "Remote file import".KB1641779 Washington DC へのアップグレード後に MID Serverからファイルをインポートできません ECC キュートピック: JavascriptProbe 名前: CSRemoteFileImport ペイロード: targetImportSet:インスタンステーブル名filePath:MID Server ディスク上のファイルパスscript =var remoteFileImport = new CSMIDServerRemoteFileImport();remoteFileImport.getRemoteFileAndUploadToInstance(); プローブコードは MID Serverスクリプトインクルード「CSMIDServerRemoteFileImport」にあります。インスタンススクリプトインクルード「CSRemoteFileImport」、UI ページ「run_remote_import」、および UI アクション「今すぐインポート」も関係します。 IT Service Management Agent Client Collector for Security Incident Response このアプリは、Flow Designer ワークフローと、IntegrationHub 用の Agent Client Connector Spoke アプリを使用します。 Digital End-User Experience (DEX) DEX は、(Hermes/Stream Connect/gPRC および ITOM CnC Gateway ポッドを介して) ホストされたインスタンスに直接接続する MID-less Agent Client Collector エージェントを使用します。これらのエージェントからのメッセージは ECC キューに表示されません。 Employee Document Management KB0963986 Employee Document Management (EDM) に関する FAQ ECC キュートピック: StreamPipeline (出力) / EmployeeFileImport (入力):ef_LocalFileCaptureスクリプトインクルードの importFileUsingMid 関数によって作成されます。MID Server ディスクからインスタンスの添付ファイルテーブルにローカルファイルを取り込みます。 Agent Correlator: sn_hr_ef_import_stagingレコードのsys_id。 ペイロードパラメーター: stream_relay_response_topic = EmployeeFileImportstream_relay_source:sn_hr_ef_import_configurationレコードから。 connection.host、connection.port、crdential_tag、path、type。 stream_relay_transform attachment.table_sys_id、attachment.table_name、attachment.file_name、attachment.content_type、type=AttachmentSink stream_relay_sink パス = ファイル名/パス - sn_hr_ef_import_stagingレコードから Sensor business rule: ローカルファイルのインポートを処理 ef_LocalFileCapture スクリプトインクルードで processLocalImportResult 関数を使用します。sn_hr_ef_import_staging レコードに結果を追加します。添付ファイルデータはペイロードにありません。/now/attachment/file REST Attachment API を使用して、プローブによってインスタンス添付ファイルテーブルに直接挿入されます。 SSHCommand - SSH プロトコルを使用してファイルを MID Server ディスクにインポートするために、「ステージングローカルファイル」Orchestrationの従来のワークフローによって作成されます。 Agent Correlator: rba. + SSH Orchestration activities を含む wf_context の sys_id Microsoft Exchange Online for Security Operations ドキュメント:Microsoft Exchange Online Integration (Rome) 統合は、Powershell Orchestration ワークフローアクティビティによって実装されます。 コンプライアンス検索を診断Exchange Online で検索を作成Exchange Online 検索のステータスを確認O365 の脅威メールを検索 MID の選択基準: 機能:PowerShell、WinRM 基本認証アプリケーション:Orchestration ECC キュートピック: PowerShell 名前: Windows - PowerShell ペイロード: MIDScriptFile パラメーターは、特定のアクティビティにリンクする PowerShell スクリプト名を指定します。 Agent Correlator: ワークフローコンテキスト [wf_context] レコードの Sys ID。プリフィックス「rba.」が付いています。 ソース: ターゲットホスト名 Sensor business rule: 自動化 - センサー Security Incident Response Security Incident Response アプリケーションには、サードパーティ統合が含まれます。 ECC キュートピック: RESTProbe Agent Correlator/ソース/ペイロード: TBC Now Platform Source Control ECC キュートピック: ImportApplicationProbeSourceControlProbeRemoteCloneProbeExportApplicationProbeImportNewApplicationProbeCreateTagProbeExportNewApplicationProbeTestConnectionProbeRefreshRepositoryProbeCreateBranchProbe 名前 Source Control Sensor business rule Source Control Response MIDResponse.java および GitECCProcessor.java を使用する非同期ビジネスルール。ここで、invokeOperation は、その操作に固有の関数を呼び出します。 MID Server ECC キュー ECC キュートピック: queue.processing 入力は、どの出力が「処理中」であるかをインスタンスに通知するために使用され、その後「キャンセル」または「処理済み」になります。Sensor business rule:「ECC キュー - 出力ステータスをマーク (ECC Queue - mark outputs state)」 - ペイロードに記載されている出力レコードのステータスを更新します。 queue.stats 各 MID Serverは、現在実行中のスレッドとパフォーマンスメトリクスについて、10 分ごとにレポートします。Sensor business rule:「MID - プロセス XMLStats (MID - Process XMLStats)」 - ecc_agent_thread レコード、ecc_agent 内の JVM バージョンを更新し、AgentMetrics スクリプトインクルードを使用して ecc_agent_counter_metric、ecc_agent_scalar_metric、ecc_agent_rgr_metrice、cc_agent_memory_metric を更新します。config.file MID Server の起動時に送信される input です。MID Server が通信できなかった間に config.xml ファイルで変更された内容と一致するよう、インスタンス内の MID Server Parameter レコードを更新します。Sensor Business Rule: ECC Queue - process config file Kubernetes 展開 エージェント: これは、「MID Server Management」アプリケーションを使用して Kubernetes 展開 MID Serverとして設定された MID Serverとなっている必要があります。 ECC キュートピック: KubernetesOperationProbe 名前: 要求の mid_k8s_deployment レコードの名前フィールド。 ペイロード: deployment_request_id は、mid_k8s_deployment レコードの sys_id です。deployment_request は BASE64 でエンコードされ、暗号化されます。 Sensor business rule: KubernetesOperationResponder 展開要求 mid_server_deployment レコードのステータスを更新します。 システムコマンド ECC キュートピック: SystemCommand ソース: MID Server内部システムコマンドの名前。次が含まれます。 restart MID Serverを再起動します。 restartService MID Server サービスを再起動します。これにより、Windows サービスが完全に停止してから開始されます。 stop MID Server サービスをシャットダウンします。 threaddump Java スレッドダンプを wrapper.log に書き込みます。 gcgrabLog Name フィールドのファイルを取得します。 getResourceStatedeleteLogpause / unpause MID Serverを一時停止してジョブを実行しないようにしますが、ほとんどのシステムコマンドは引き続き実行されます。 upgradeNow 毎時のスケジュール済みジョブによる確認を待つのではなく、今すぐアップグレードする必要があるかどうかを確認するように MID Serverに指示します。 clear_queueload_propertiesload_ip_access IP アドレスのアクセス制御プラグイン。これにより、[MID Serverに適用] がオンになっているすべてのルールが MID Serverに適用されます。 cancel_discovery ディスカバリーステータスが最大ランタイムに達した場合、または手動でキャンセルされた場合に、残りのプローブをキャンセルするよう MID Serverに通知します。Discovery を実行しているかどうかに関係なく、すべての MID Serverにブロードキャストします。agent_correlator=<sys_id of discovery_status> updateConfig パラメーター/プロパティの変更を MID Serverにプッシュします。パラメーターは config.xml にも書き込まれます。 statusinvalidate_cachescript MID Server Scripts - Background ページで使用され、MID Server で JavaScript を実行し、出力を返します。 credentials_reload discovery_credentials レコードの変更によってトリガーされます。MID Serverの認証情報のローカルキャッシュを更新します。 privileged_command_reloadautomation_encryption_keys_reloadprobe_cacherange_cache 検出 IP 範囲キャッシュをクリアします。discovery_range テーブルの変更によってトリガーされます。 delete_mid_keypair キーの再生成および無効化 acls_changemibs_reload ecc_agent_mib からすべての SNMP MIB ファイルを再同期します。 FileChange すべての MID Serverのディスクに対してファイルを再同期します。[名前] の値は、同期されたファイルの変更が発生したテーブルです (JAR Files、Script Files/Includesなど)。 resetQueryWindowCitChangedCustomOperationChangedCustomParsingStrategyChangedLibsApplCategoryChangedLibsDeviceInfoCategoryChangedPatternExtensionChangedMetadataRulesChangedMigrateToIPKI Zurich Patch 11 / Australia Patch 4 以降、Basic Auth を iPKI Authentication に変換します。一部のドキュメントに記載されている migrate_ipki probe ではありません。sn_mid_infra_ipki_migration after-insert Business Rule によって呼び出されます。キーストア証明書を更新し、config.xml のユーザー名/パスワードを mid.ipki.enabled=true に置き換えた後、再起動します。 RotateIPKI 「Rotate ServiceNow Certificate」関連リンク、または通常の Certificate Rotation 時にトリガーされます。結果として IPKI rotation initiated successfully; MID restart pending が返されます。 ExtCommandChangedpauseMid MID Serverがシステムコマンド以外のジョブを実行しないようにします。 resumeMid MID Serverがすべてのジョブを実行できるようにします。 autoUpgrade 毎時のスケジュール済みジョブによる確認を待つのではなく、今すぐアップグレードする必要があるかどうかを確認するように MID Serverに指示します。 grabNdltrackedFileDefinitionChangedclear_cookies ServiceNow インスタンスへの要求を行うために SOAP クライアントによって使用される Cookie キャッシュをクリアし、MID Serverが別のアプリノードに接続できるようにします。 installNmap / uninstallNmap Credential-less Discovery で使用される MID Serverホストに NMAP をインストール/アンインストールします。 service_account_reloadfile_discovery_whitelistfile_discovery_refreshconnection_cache_updateenvironment_clearmid_status_change 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: ; } } この KB 記事の範囲では、問題の解決策を提供するところまでは踏み込みません。ただし、正しい方向へ導く助けになるでしょう。