MID Server の基礎MID について このドキュメントでは、MID Server の概要について説明します。また、MID Server の最も重要な機能についても説明します。一部のトピックについては、バージョンによって若干変更される可能性があるため、docs.servicenow.com へのリンクを参照してください。docs.servicenow.com で、インスタンスに応じてバージョンを選択します。 その他のトレーニング MID Server Fundamentals MID の概要 管理、計測、検出 (Management, Instrumentation, and Discovery / MID) サーバーは、ローカルネットワーク内のサーバーで Windows のサービスまたは UNIX のデーモンとして動作する Java アプリケーションです。ServiceNow®MID Server を使用すると、ServiceNow インスタンスと外部アプリケーション、データソース、およびサービスとの間でデータの通信と移動が可能になります。 MID Server は、ServiceNow® インスタンスとのすべての通信を開始します。この通信は、インスタンスと MID Server 間の通信ログとして機能する ECC キューにレコードとして記録されます。MID Server は、ECC キューから実行する必要があるすべての作業を取得し、その作業の結果をキューに返します。 インストール Windows への MID Server のインストールLinux への MID Server のインストール 構成 MID Server パラメーターMID Server プロパティMID Server JVM メモリサイズを設定MID Server を構成 アップグレード MID Server のアップグレードMID Server のアップグレードプロセス - MID Server 自体がアップグレードされると、実際にはどうなるか？ ECC キューと AMB チャネル 外部通信チャネル (External Communication Channel / ECC) キューは、インスタンスと MID Server間の接続ポイントです。MID Server が実行する必要があるジョブは、MID Server がそれらを処理できる状態になるまでこのキューに保存されます。 MID Server は、非同期メッセージバス (Asynchronous Message Bus / AMB) によって公開されたメッセージをサブスクライブします。これにより、ECC キューに保留中のタスクがあることが MID Server に通知されます。MID Server の ECC キューにジョブが存在する場合、MID Server はステータスを「処理中」に設定します。要求されたジョブの処理が終了すると、MID Server は結果とともに ECC キューにレポートします。 MID Server は、AMB クライアントを介してインスタンスへの永続的な接続を開き、/mid/server/<mid_sys_id> AMB チャネルでリッスンします。 出力レコードがキュー [ecc_queue] テーブルに挿入されると、AMB メッセージが MID Server のチャネルに送信されます。MID Server はこのメッセージを受信し、直ちに [ecc_queue] テーブルを作業のためにポーリングします。 MID Server は、AMB メッセージアクティビティに関係なく、mid.poll.time 設定パラメーターで定義された定期的な間隔で ECC キューをポーリングします。デフォルトのポーリング間隔は 40 秒に設定されていますが、再設定できます。この定期的な間隔での ECC キューのポーリングは、AMB 接続が切断された場合に行われます。 ECC キューのライフサイクル MID Server を利用するアプリケーションの 1 つが ecc_queue 出力レコードを作成します。ECCQueueMonitor スレッドは、ecc_queue をチェックし、準備完了ステータスとなっている出力レコードを確認します。ECCQueueMonitor は、MID Server で利用可能ないずれかのスレッドプールに出力メッセージを送信しようとします。出力の送信先スレッドプールは、ecc_queue レコードの [優先度] フィールドに基づいています。3 つのスレッドプールがあります。 InteractiveExpeditedStandard ECCQueueMonitor スレッドは、いずれかのスレッドプールに正常に割り当てられた出力レコードの sys_id のリストとともに入力をインスタンスに送り返します。この入力は topic=queue.processing になります。この入力は処理され、MID Server プールに追加された出力はインスタンスで「処理中」に設定されます。 注意： MID Server キューがいっぱいの場合、出力は取得されず、インスタンスで準備完了のままになります。 出力メッセージは最終的にスレッドプールを離れ、ワーカーにアサインされて実行されます。 注意： 実行されるコードは ecc_queue フィールド「topic」によって異なります。 結果は、完了すると MID Server の出力フォルダーの 1 つ (.\agent\work\monitors\ECCSender) に保存されます。ECCSender スレッドは結果をインスタンスに送り返します。ビジネスルール「ECC Queue - mark outputs processed」は、ecc_queue 入力フィールド response_to に基づいて出力を処理済みに設定します。また、ecc_queue テーブル内のいずれかのビジネスルールが条件に従ってトリガーされ、入力の処理方法が決定されます 注意： ECCQueueMonitor スレッドは、ポーリング時間 (mid.poll.time) で設定されたとおりに、または AMB チャネルによってトリガーされたときに実行されます。ECC メッセージがキューに挿入されると、AMB メッセージが公開され、メッセージの優先度に基づいてポーリング頻度を調整するように MID Server に通知し、ecc_queue で準備完了ステータスの出力レコードを確認します。 ECC キューのライフサイクルの詳細については、次を参照してください。 どのように ECC キューテーブルのレコードは処理されるか: 準備完了の出力から処理済みの入力までECC キューに戻されたレコードを特定の機能またはジョブにリンクする方法 ECC キューのライフサイクルの例 ハートビートプローブ [インスタンス] インスタンスで、「MID Server Monitor」ジョブが準備完了ステータスの ecc_queue 出力レコードを作成します。[MID] ECCQueueMonitor 出力のチェック： ECCQueueMonitor.1 DEBUG: Monitor query: 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: Added processing (4): 8b5195cfdbf174104fa1c9db13961984ECCQueueMonitor.1 DEBUG: Event: MessageDispatchedEvent, message: HeartbeatProbe 8b5195cfdbf174104fa1c9db13961984 [MID] The "HeartbeatProbe" Java クラスを実行します。: Worker-Interactive:HeartbeatProbe-8b5195cfdbf174104fa1c9db13961984 Worker starting：HeartbeatProbe [MID] "HeartbeatProbe" の出力がファイルに送信されます。： Worker-Interactive:HeartbeatProbe-8b5195cfdbf174104fa1c9db13961984 Enqueuing: C:\ServiceNow\emprcoelhosilvaq\agent\work\monitors\ECCSender\output_0\ecc_queue.8b5195cfdbf174104fa1c9db13961984.xmlWorker-Interactive:HeartbeatProbe-8b5195cfdbf174104fa1c9db13961984 DEBUG: ** enqueued C:\ServiceNow\emprcoelhosilvaq\agent\work\monitors\ECCSender\output_0\ecc_queue.8b5195cfdbf174104fa1c9db13961984.xml [MID] "HeartbeatProbe" の処理が完了しました。： Worker-Interactive:HeartbeatProbe-8b5195cfdbf174104fa1c9db13961984 Worker completed: HeartbeatProbe time: 0:00:00.000 [MID] HeartbeatProbe の出力がインスタンスに送り返されます。 ECCSender.1 DEBUG: ** sending file C:\ServiceNow\emprcoelhosilvaq\agent\work\monitors\ECCSender\output_0\ecc_queue.8b5195cfdbf174104fa1c9db13961984.xmlECCSender.1 Sending ecc_queue.8b5195cfdbf174104fa1c9db13961984.xmlECCSender.1 DEBUG: Sent ecc_queue sys_id=475159cb1b7db0502fa799b61a4bcb71 [インスタンス] インスタンスに作成された、sys_id 475159cb1b7db0502fa799b61a4bcb71 の ecc_queue 入力が表示されます。 注意： 上記の例では、出力および入力 ecc_queue レコードの sys_id を使用して、この出力が処理されたときに MID Server で何が起こったかを追跡できます。 ECC キュー優先度 MID Server に 3 つのスレッドプールがありました： Interactive 優先度：0スレッド数パラメーター：threads.interactive.max Expedited 優先度：1スレッド数パラメーター：threads.expedited.max Standard 優先度：2スレッド数パラメーター：threads.max MID Server は、ecc_queue レコードの優先度フィールドに基づいて、ecc_queue からさまざまなスレッドプールに作業を割り当てます。スレッドプールを使用すると、MID Server に送信される作業をより適切に管理し、最初に完了する必要がある作業に優先順位を付けることができます。 たとえば、スケジュール設定済みディスカバリーでは、デフォルトで standard プールが使用されます。大規模なディスカバリーを実行すると、standard スレッドプールの ecc_queue に作業のバックログが存在する一方で、expedited プールにはバックログがない場合があります。MID Server を利用する統合が standard プールの ecc_queue 出力を作成する場合、ディスカバリー出力と同じ「列」で待機します。このような統合が時間的制約のあるものである場合は、 Expedited プールに送信することが最善です。このようにすると、そのような作業は「列をスキップ」し、ディスカバリーの完了を待つ必要がなくなります。 ECC キューファイルサイズ MID Server がインスタンスに送信する最大ファイルサイズと、インスタンスが受け入れる最大ファイルサイズを制御するプロパティがいくつかあります。 ディスカバリーとオーケストレーション mid.discovery.max_payload_size のデフォルト値は 5000000 (バイト) です。入力ペイロードエラーに次のエラーが表示されます。： Payload length <Payload_Length> exceeded limit of <Max_Payload_Length> MID Server のプロパティ mid.eccq.max_payload_size は、MID Server がインスタンスに送り返す ECCQ ペイロード XML の最大長です。デフォルト値は 20000000 (バイト) です。この値より大きい MID Server の結果サイズはインスタンスに返されません。代わりに、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 Server からインスタンスに結果を正常に送信するには、上記のパラメーターの 1 つ以上を調整する必要がある場合があります。 ECC_Queue と API_INT インスタンスには、ユーザー、統合などからの要求を処理する一連のセマフォがあります。instance.service-now.com/stats.do に移動すると、セマフォ sys_semaphore の詳細が表示されます。MID Server は、ecc_queue レコードを取得または送信するときに、API_INT セマフォを使用します。例 (stats.do ページから)： 上の画像では、ecc_queue レコードをアップロードするときに MID Server で使用されている API_INT セマフォの 1 つが表示されています。キュー深度の制限が 50 であることも表示されています。このセマフォへの要求がうまく機能しない場合、キュー深度の制限に達する可能性があります。これが発生した場合、このセマフォへの要求は、キューが利用可能となるまで 429 エラーで失敗します。したがって、API_INT を使用する統合が適切に機能することが重要です。そうしないと、インスタンスへの MID Server 通信がブロックされる可能性があります。 MID Server のエラー "Too Many Requests with code: 429" 資格情報 インスタンスへの認証 MID Server は、config.xml ファイルに設定された資格情報を使用してインスタンスに基本認証で接続します。起動後、これらの資格情報はファイル内で暗号化されます。または、Quebec 以降、MID Server は相互認証を使用してインスタンスと通信できます。 MID Server 相互認証を有効にします 標準資格情報プロバイダー MID Server は、デバイスに対してコマンドを実行できます。ターゲットデバイスに正常に到達してコマンドを実行するには、適切な資格情報が必要です。資格情報が必要なアプリケーションの例： ディスカバリーオーケストレーションスポークインポート/JDBC デフォルトでは、資格情報はインスタンスに保持され、暗号化され、必要に応じて MID Server に同期されます。資格情報の暗号化、順序、およびエイリアスの詳細については、以下を参照してください。 資格情報 資格情報のトラブルシューティングについては、以下を参照してください。 ディスカバリー、サービスマッピング、オーケストレーションにおける資格情報/権限のトラブルシューティング 外部資格情報プロバイダー 資格情報の値をインスタンスに保持する必要はありません。このような資格情報を ServiceNow インスタンスの外部に保持するオプションもあります。このような構成については、以下を参照してください。 外部資格情報ストレージ外部資格情報ストレージ構成 ステータス、ログ、およびトラブルシューティング ステータス sys_trigger ジョブ「MID Server Monitor」は 5 分ごとに実行されます。このジョブは、各 MID Server のトピックが HeartbeatProbe である ecc_queue 出力レコードを作成します。HeartbeatProbe 出力は MID Server によって処理され、HeartbeatProbe 入力が作成されます。ハートビート入力は、MID Server の last_refreshed フィールドを更新します。また、前回ハートビートが送信されてからハートビート応答がなく、そのような MID Server で最近のアクティビティが確認されていない場合、ジョブは MID Server のステータスを「Down」に設定します。詳細なロジックは、スクリプトインクルード MonitorMIDServer で確認できます。 MID Server のステータス異常に関する下記 KB をご参照ください。 MID Server Down のトラブルシューティング ログ MID Server のログは .\agent\logs フォルダーに保持されます。MID Server は、次の 2 つのメインログに情報を書き込みます。 エージェントログ (例：agent0.log.0 エージェントログは、MID Server 固有のコードがメッセージ、情報、デバッグなどを書き込む場所です wrapper.log ラッパーログは、Java サービスがログを送信する場所です。これは、MID Server アップグレードサービスが情報を書き込む場所でもあります。 MID Server はエージェントログをローテーションします。MID Server は、それぞれ最大 10 MB のサイズの最大 10 個のエージェントログを保持します。保持するログの数とサイズの構成は、.\agent\properties\glide.properties ファイルで確認できます。デフォルト値の例： java.util.logging.FileHandler.pattern=logs/agent%u.logjava.util.logging.FileHandler.append=truejava.util.logging.FileHandler.limit=10000000java.util.logging.FileHandler.count=10 MID Server のログは、インスタンスで直接取得できます。インスタンスを介してログを収集するには： [MID Server] > [サーバー] を選択し、目的の MID Server レコードに移動します。[MID ログ、設定、およびスレッドダンプを取得] リンクをクリックします。ecc_queue には、トピック SystemCommand とソース「grabLog」の出力レコードが表示されます。関連リスト「エージェントログ」と「エージェントファイル」には、MID Server によってアップロードされたファイルが作成されます。 注意： MID Server のステータスが「Down」の場合、上記の手順は使用できません。 トラブルシューティングの基本 MID Server パラメーター mid.log.level を「debug」に設定します。追加のデバッグプロパティまたはパラメーターを適宜設定します。問題を再現させます。MID Server ログを確認します。 異なる ecc_queue プローブは異なるコードによって処理されるため、デバッグ時に設定する必要があるプロパティは mid.log.level だけではない場合があります。ただし、これはトラブルシューティングの開始点として適しています。