「MID Server Fundamentals」関連情報 このドキュメントでは、MID サーバーの概要について説明します。また、MID サーバーの最も重要な機能についても説明します。一部のトピックに関する情報については、バージョンによって若干変更される場合がありますので、docs.servicenow.com を指すリンクがあります。[docs.servicenow.com] で、インスタンスに応じたバージョンを選択します。 追加トレーニング MID サーバーの基礎 MID の概要 管理、計測、検出 (MID : Management, Instrumentation, and Discovery) Server は、ローカルネットワークのサーバー上で Windows サービスまたは UNIX デーモンとして稼働する Java アプリケーションです。ServiceNow®MID サーバーは、ServiceNow インスタンスと外部のアプリケーション、データソース、サービスの間で行われるデータの通信や移動を可能にします。 MID サーバーは、ServiceNow® インスタンスとのすべての通信を開始します。この通信は、インスタンスと MID サーバー間の通信ログとして機能する ECC キューにレコードとして記録されます。MID サーバーは、ECC キューから実行する必要があるすべての作業を取得し、その作業の結果をキューに返します。 インストール Windows への MID サーバーのインストール Linux への MID サーバーのインストール 構成 MID サーバーパラメーターMID サーバープロパティMID サーバーの JVM メモリサイズを設定するMID サーバーの構成 アップグレード MID サーバーのアップグレードMID サーバーのアップグレードプロセス - MID サーバー自体をアップグレードすると、実際にはどうなりますか? ECC キューと AMB チャネル 外部通信チャネル (ECC) キューは、インスタンスと MID Server間の接続ポイントです。MID サーバーが実行する必要があるジョブは、MID サーバーがそれらを処理できる状態になるまでこのキューに保存されます。 MID Serverは、非同期メッセージ バス (AMB) によって発行されたメッセージに登録し、MID Serverに保留中のタスクが ECC キューにあることを通知します。その MID Serverの ECC キューにジョブが存在する場合、MID Serverはステータスを「処理中」に設定します。要求されたジョブの処理が終了すると、MID サーバーは結果とともに ECC キューにレポートします。 MID サーバーは、AMB)Client を介してインスタンスへの永続的な接続を開き、 /mid/server/<mid_sys_id> AMB チャネルでリッスンします。出力レコードがキュー [ecc_queue] テーブルに挿入されると、AMB メッセージが MID サーバーのチャネルに送信されます。MID Serverはこのメッセージを受信し、直ちに [ecc_queue] テーブルを作業用にポーリングします。 MID サーバーは、AMB メッセージアクティビティに関係なく、mid.poll.time 設定パラメーターで定義された一定の間隔で ECC キューをポーリングします。デフォルトのポーリング間隔は 40 秒に設定されていますが、再設定できます。この定期的な間隔での ECC キューのポーリングは、AMB 接続が切断された場合に行われます。 ECC キューのライフサイクル MID サーバーを使用するアプリケーションの 1 つがecc_queue出力レコードを作成しますECCQueueMonitor スレッドは、準備完了状態の出力のecc_queueをチェックしますECCQueueMonitor は、MID サーバーで使用可能なスレッドプールの 1 つに出力メッセージを送信しようとします。出力が送信されるスレッドプールは、ecc_queueレコードの優先度フィールドに基づいています。次の 3 つのスレッドプールがあります。 インタラクティブ迅速化済みStandard ECCQueueMonitor スレッドは、スレッドプールの 1 つに正常に割り当てられた出力レコードの sys_id のリストとともに入力をインスタンスに送り返します。この入力は topic=queue.processing になります。この入力が処理され、MID サーバープールに追加された出力はインスタンスで「処理中」に設定されます。 注意: MID サーバーキューが満杯の場合、出力は取得されないため、インスタンス上で準備完了として残ります。 出力メッセージは最終的にスレッドプールを離れ、実行されるワーカーに割り当てられます 注意: 実行されるコードは、ecc_queueフィールド「トピック」によって異なります 完了すると、結果は MID サーバーの出力フォルダーの 1 つ (.\agent\work\monitors\ECCSender) に保存されますECCSender スレッドは、結果をインスタンスに送り返しますビジネスルール「ECC キュー - 処理済みとマーク出力」は、ecc_queue入力フィールドresponse_toに基づいて出力を「処理済み」に設定します。また、ecc_queueテーブルのいずれかのビジネスルールが条件に従ってトリガーされ、入力の処理方法を決定します 注: ECCQueueMonitor スレッドは、ポーリング時間 (mid.poll.time) で設定されたとおりに、または AMB チャネルによってトリガーされたときに実行されます。ECC メッセージがキューに挿入されると、AMB メッセージが公開され、メッセージの優先度に基づいてポーリング頻度を調整し、ecc_queueで準備完了ステータスの出力レコードを確認するように MID サーバーに通知されます。 ECC キューのライフサイクルの詳細については、以下を参照してください。 ECC キューの仕組み:出力準備完了から入力処理までECC キューレコードを特定の機能またはジョブにリンクする方法 ECC キューのライフサイクルの例 ハートビートプローブ [インスタンス]インスタンスで、「MID サーバーモニター」ジョブによって準備完了ステータスのecc_queue出力レコードが作成される[MID] ECCQueueMonitor は出力をチェックします: ECCQueueMonitor.1 DEBUG:モニタークエリ:state=ready^queue=output^agent=mid.server.WIN-IHKAN2LQJE1^sys_created_on>=2021-08-10 10:26:38^ORDERBYpriority^ORDERBYsys_created_on [MID] 出力が取得されているのがわかります: ECCQueueMonitor.1 DEBUG: 追加された処理 (4): 8b5195cfdbf174104fa1c9db13961984ECCQueueMonitor.1 DEBUG:イベント:MessageDispatchedEvent、メッセージ:HeartbeatProbe 8b5195cfdbf174104fa1c9db13961984 [MID] 「HeartbeatProbe」javaクラスが Worker-Interactive:HeartbeatProbe-8b5195cfdbf174104fa1c9db13961984 を実行します ワーカーの起動:HeartbeatProbe [MID] 「HeartbeatProbe」の出力は次のファイルに送信されます: Worker-Interactive:HeartbeatProbe-8b5195cfdbf174104fa1c9db13961984 エンキュー:C:\ServiceNow\emprcoelhosilvaq\agent\work\monitors\ECCSender\output_0\ecc_queue.8b5195cfdbf174104fa1c9db13961984.xmlworker-interactive:HeartbeatProbe-8b5195cfdbf174104fa1c9db13961984 デバッグ:** エンキュー済み C:\ServiceNow\emprcoelhosilvaq\agent\work\monitors\ECCSender\output_0\ecc_queue.8b5195cfdbf174104fa1c9db13961984.xml [MID] 「HeartbeatProbe」処理が完了しました: Worker-Interactive:HeartbeatProbe-8b5195cfdbf174104fa1c9db13961984 ワーカーが完了しました:HeartbeatProbe 時間:0:00:00.000 [MID] HeartbeatProbe からの出力がインスタンスに送り返されます: ECCSender.1 デバッグ:** ファイル C:\ServiceNow\emprcoelhosilvaq\agent\work\monitors\ECCSender\output_0\ecc_queue. を送信しています8b5195cfdbf174104fa1c9db13961984.xmlECCSender.1 送信ecc_queue.8b5195cfdbf174104fa1c9db13961984.xmlECCSender.1 DEBUG: 送信 ecc_queue sys_id=475159cb1b7db0502fa799b61a4bcb71 [インスタンス]インスタンスで作成された sys_id 475159cb1b7db0502fa799b61a4bcb71 のecc_queue入力が表示されます。 注意: 上記の例では、 output レコードと inputecc_queue レコードのsys_idを使用して、この出力が処理されたときに MID サーバーで何が起こったかを追跡できることがわかります。 ECC キュー優先度 MID サーバーには 3 つのスレッドプールがありました。 インタラクティブ 優先度:0スレッド数パラメーター:threads.interactive.max 迅速化済み 優先度:1スレッド数パラメーター:threads.expedited.max Standard 優先度:2スレッド数パラメーター:threads.max MID サーバーは、ecc_queue レコードの優先度フィールドに基づいて、ecc_queueからさまざまなスレッドプールに作業をアサインします。スレッドプールを使用すると、MID サーバーに送信される作業をより適切に管理し、最初に完了する必要がある作業に優先順位を付けることができます。 たとえば、スケジュール済みディスカバリーはデフォルトで標準プールを使用します。大規模な検出を実行する場合、標準スレッドプールのecc_queueに作業のバックログがある可能性がありますが、迅速化済みプールにはバックログがない可能性があります。MID サーバーを使用する統合で標準プールのecc_queue出力が作成される場合、標準プールはディスカバリー出力と同じ「行」で待機します。このような統合が時間的制約がある場合は、迅速化済みプールに送信するのが最善です。このようにすると、そのような作業は「行をスキップ」し、検出が完了するのを待つ必要はありません。 ECC キューファイルのサイズ MID サーバーがインスタンスに送信する最大ファイルサイズと、インスタンスが受け入れる最大ファイルサイズを制御するプロパティがいくつかあります。 ディスカバリーとオーケストレーション mid.discovery.max_payload_size のデフォルト値は 5000000 (バイト) です。入力ペイロードエラーに次のエラーが表示されます: Payload length <Payload_Length> exceeded limit of <Max_Payload_Length> MID サーバープロパティ mid.eccq.max_payload_size は、MID サーバーがインスタンスに送り返す ECCQ ペイロード XML の最大長です。デフォルト値は 20000000 (バイト) です。この値より大きい MID サーバーの結果サイズは、インスタンスに送り返されません。代わりに、ecc_queue入力のペイロード部分が変更され、サイズの問題に関するアラートが生成されます。 結果が mid.eccq.max_payload_size での設定よりも大きい場合のペイロードの例: <payload><error>Payload size of <size_of_payload> bytes exceeded maximum of 20000000 bytes. Contents of the original payload were moved to <path> on the MID server. Maximum payload size can be set with mid config parameter: mid.eccq.max_payload_size</error></payload> システムプロパティ com.glide.attachment.max_size は、メガバイト単位で添付ファイルの最大サイズを制御します。このプロパティで構成されているサイズよりも大きい添付ファイルを作成しようとすると、次のようなエラーが発生します。 Attachment size exceeds the limit com.glide.attachment.max_get_size は、添付ファイルの最大サイズをバイト単位で制御し、ディスカバリーセンサーによって使用されます。 glide.soap.max_inbound_content_length プロパティを使用して、SOAP を介してインスタンスに送信できる最大コンテンツ長 (MB) を制御します。この値を超えると、次のエラーが表示されます。 Request body exceeded max allowed content length 注:ペイロードが非常に大きいと、インスタンスのパフォーマンスの問題が発生する可能性があります。テストは、最初に非本番インスタンスで実行する必要があります。MID サーバーからインスタンスに結果を正常に送信するには、上記の 1 つ以上のパラメーターを調整する必要があります。 ECC_QueueとAPI_INT インスタンスには、ユーザーや統合などからの要求を処理する一連のセマフォがあります。instance.service-now.com/stats.do に移動すると、セマフォsys_semaphoreに関する詳細情報が表示されます。MID サーバーは、ecc_queueレコードを取得または送信するとき、API_INTセマフォを使用します。例 (stats.do ページから): 上の画像では、MID サーバーがecc_queueレコードをアップロードするときに使用されているAPI_INTセマフォの 1 つを示しています。また、キュー深度の制限が 50 であることもわかります。このセマフォへの要求が適切に実行されない場合、キュー深度の制限に達する可能性があります。その場合、このセマフォへの要求は 429 エラーで失敗し、キューの可用性が再び高まります。したがって、API_INTを使用する統合が適切に実行されることが重要です。そうしないと、インスタンスへの MID サーバーの通信がブロックされる可能性があります。 MID サーバーエラー「コード:429 の要求が多すぎます」 認証情報 インスタンスへの認証 MID サーバーは、ベーシック認証を使用して、config.xml ファイルに設定された認証情報を使用してインスタンスに接続します。起動後、これらの認証情報はファイル内で暗号化されます。または、Quebec 以降、MID サーバーは相互認証を使用してインスタンスと通信できます。 MID サーバーの相互認証を有効にする 標準認証情報プロバイダー MID サーバーは、デバイスに対してコマンドを実行できます。ターゲットデバイスに正常にアクセスしてコマンドを実行するには、適切な認証情報が必要です。認証情報を必要とする可能性があるアプリケーションの例: DiscoveryOrchestrationスポークインポート/JDBC デフォルトでは、認証情報はインスタンスで保持され、暗号化され、必要に応じて MID サーバーに同期されます。認証情報の暗号化、順序、およびエイリアスの詳細については、以下を参照してください。 認証情報の開始 認証情報のトラブルシューティングについては、以下を参照してください。 ディスカバリー、サービスマッピング、オーケストレーションでの認証情報/権限のトラブルシューティング 外部認証情報プロバイダー 認証情報の値をインスタンスに保持する必要はありません。このような認証情報を ServiceNow インスタンスの外部に保持するオプションもあります。このような構成については、以下を参照してください。 外部認証情報ストレージ外部認証情報ストレージの構成 ステータス、ログ、およびトラブルシューティング ステータス sys_triggerジョブ「MID サーバーモニター」は 5 分ごとに実行されます。このジョブは、各 MID サーバーの topic = HeartbeatProbe のecc_queue出力レコードを作成します。HeartbeatProbe 出力は MID サーバーによって処理され、HeartbeatProbe 入力が作成されます。ハートビート入力により、MID サーバーのlast_refreshedフィールドが更新されます。また、このジョブは、最後にハートビートが送信されてからハートビートの応答がなく、そのような MID サーバーの最近のアクティビティが見られない場合にも、MID サーバーのステータスを「停止」に設定します。詳細なロジックは、スクリプトインクルード MonitorMIDServer で確認できます。 MID サーバーステータスの問題については、次の KB を参照してください。 MID サーバーのダウンのトラブルシューティング ログ MID サーバーのログは .\agent\logs フォルダーに保持されます。MID サーバーは、次の 2 つのメインログに情報を書き込みます。 エージェントログ、例:agent0.log.0 エージェントログは、MID サーバー固有のコードがメッセージ、情報、デバッグなどを書き込む場所です wrapper.log ラッパーログは、Java サービスがログを送信する場所です。これは、MID サーバーアップグレードサービスが情報を書き込む場所でもあります MID サーバーがエージェントログをローテーションします。MID サーバーは、それぞれ最大 10 MB のサイズのエージェントログを最大 10 個保持します。保持するログの数とそのようなログのサイズの構成は、.\agent\properties\glide.properties ファイルで確認できます。デフォルト値の例: ## MIDLogFileHandler settings (See https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1637658 for more details)com.service_now.mid.logging.MIDLogFileHandler.pattern=logs/agent%u.logcom.service_now.mid.logging.MIDLogFileHandler.append=truecom.service_now.mid.logging.MIDLogFileHandler.limit=10000000com.service_now.mid.logging.MIDLogFileHandler.count=10com.service_now.mid.logging.MIDLogFileHandler.compression=nonecom.service_now.mid.logging.MIDLogFileHandler.cleanupOnStart=false MID サーバーログは、インスタンスで直接取得できます。インスタンスを介してログを収集するには: 対象の MID サーバーレコード、MID サーバー>サーバーに移動します[MID ログ、ファイル、およびスレッドダンプを取得] リンクをクリックしますecc_queueでは、トピック SystemCommand とソース「grabLog」の出力レコードを確認できます関連リスト [エージェントログ] および [エージェントファイル] には、MID サーバーによってアップロードされたファイルが入力されます 注意: MID サーバーのステータスが「停止」の場合、上記の手順は利用できません トラブルシューティングの基本 MID サーバーパラメーター mid.log.level を「debug」に設定しますそれに応じて、追加のデバッグプロパティまたはパラメーターを設定します問題を再現しますMID サーバーログの確認 異なるecc_queueプローブは異なるコードによって処理されるため、デバッグ時に設定する必要があるプロパティは mid.log.level だけではありません。ただし、トラブルシューティングを行う際の出発点として適しています。