エージェントクライアントコレクター/DEX とクローン<!-- /*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: ; } } 目次 ACC はクローンされますか?クローンプロファイル、除外、および保持者MID サーバー経由で接続された ACC API キー拡張コンテキストレコード インスタンスに直接接続されている ACC エージェントまたは DEX クライアント 構成ファイル ACC CI およびレコード sys_class_pathの不一致ACC プラグイン (Sensu 資産)パターンスクリプトファイルアプリ/プラグインおよびインストール済みバージョン ACC-M - モニタリング / メトリックベースACC-L:ヘルスログアナリティクス クローンソースに HLA がない場合インスタンスとOccultus バージョンの非互換性 ACC はクローンされますか? いいえ すべてのエージェントクライアントコレクターのインストールは、MID サーバーのグループを指すように設定され、MID サーバーは特定のインスタンス URL 用に設定されます。ACC と MID サーバーは、インスタンスの構成が大きく異なる場合でも、クローン後も引き続き同じインスタンス URL に接続します。 ACC にはホストあたり 1 つの ACC インストールのみという制限があるため、異なるインスタンスの ACC インストールを手動でクローン作成しても機能しません。エージェントのインストールは、代わりに別の MID サーバー/インスタンス URL と通信するように手動で再構成し、効果的に別のインスタンスに切り替えることができますが、同時に異なるインスタンスの URL で設定することはできません。 クローンプロファイル、除外、および保持者 cGTM リリースまでに、ACC-F には次の除外/保持設定 (PRB1408738 によって追加) があり、すべてシステムプロファイルに含まれています。 除外済み: sn_agent_cmdb_ci_agentsn_agent_mid_infosn_agent_request_checkssn_agent_ci_extended_infosn_agent_test_resultsn_agent_requestsn_agent_policy_clientsecc_agent_ip_address (ACC-F v2.3.01 PRB1437462 以降) 保持: ecc_agent_ip_address (ACC-F v2.3.01 PRB1437462 以降) 既知の問題: KB2032995/PRB1866874 クローンソースインスタンスのエージェントに固有の ACC 関連テーブルはクローンから除外する必要があります MID サーバー拡張コンテキストの設定については、以下を参照してください。 MID サーバー経由で接続された ACC エージェントクライアントコレクターのインストールは MID サーバー経由でインスタンスに接続するため、ACC を使用してインスタンスのクローンを設定することを検討する際には、MID サーバーの潜在的なクローンに関する問題もすべて考慮する必要があります。 KB0786475 MID サーバーとクローン 各エージェントクライアントコレクターのインストールは、特定の MID サーバー上で実行されている MID Web サーバー拡張、つまり特定のインスタンス名と通信します。ACC Websocket エンドポイントと MID Web サーバーコンテキストは、クローン後も同じポートと認証情報設定でそのままにする必要があります。そうしないと、エージェントクライアントコレクターは MID サーバーおよびインスタンスと通信できなくなります。 除外済み: ecc_agent_ip_address (ACC-F v2.3.01 PRB1437462 以降) 保持: ecc_agent_ip_address (ACC-F v2.3.01 PRB1437462 以降) MID サーバー拡張コンテキストの設定については、以下を参照してください。 API キー San Diego リリースで追加されたテーブル mid_webserver_api_key_credentials はベーステーブルdiscovery_credentialsを拡張します。ベーステーブルは除外されて保持されます。 一般に、親テーブルが除外されると、そのすべての子テーブルも除外されることが文書化されています。しかし、これらが保存されていなかったため、PRB1578751がオープンされましたが、これはクローンエンジンの問題の副作用であることが判明し、2020年6月にPRB1403259によって修正されました。 それ以前は、除外/保持機能を持つテーブル ecc_agent_webserver_api_key が使用されていました。 今は問題ないはずです。 ソリューション: 特にクローンを作成する前に、API キーをバックアップすることをお勧めします。その後、再インポートすることも、後で再度追加することもできます。 拡張コンテキストレコード 次の拡張はクローンで保持または除外する必要があります。 MID Web サーバーACC Websocket エンドポイントさらに、イベント管理/オペレーショナルインテリジェンスなどに関連するその他のもの。 これらは現在除外/保持されています: 除外済み: ecc_agent_ext_context_webserversn_agent_ext_contextecc_agent_ext_context_trap (from Vancouver PRB1628241)ecc_agent_ext_context_vcenter (from Vancouver PRB1628241)ecc_agent_ext_context_metric (Vancouver PRB1628236 の拡張プロファイル)ecc_agent_ext_context_event (Vancouver PRB1628223 の拡張プロファイル) 保持: ecc_agent_ext_context_webserverecc_agent_ext_contextsn_agent_ext_contextecc_agent_ext_context_trap (バンクーバー PRB1628241 から)ecc_agent_ext_context_vcenter (バンクーバー PRB1628241 から)ecc_agent_ext_context_metric (Vancouver PRB1628236 の拡張プロファイル)ecc_agent_ext_context_event (Vancouver PRB1628223 の拡張プロファイル) インスタンスクローンの自動化は、TPC 拡張テーブル階層内の個々のクラスの除外または保持にはあまり適していません。これにより、MID サーバーで正しく開いて実行できない破損したレコードが発生し、唯一のレコードのように見える重複レコードが作成されます。 すべてがその子テーブルであるため、ecc_agent_ext_contextテーブルですべての拡張の概要を取得できます。 クローンによってこれらのレコードが破損した場合、一部のレコードが開かず、「レコードが見つかりません」というエラーが表示されることがあります。 初期設定のプリザーバー/除外に関する既知の問題: PRB1408738 エージェントクライアントコレクターテーブルにクローン除外/保持者の設定がない - ACC- F 2.1.41 以降で修正。SNMP トラップおよび vCenter イベントベースのディスカバリー MID サーバー拡張コンテキスト (ecc_agent_ext_context_trap/ecc_agent_ext_context_vcenter) でクローン除外/プリザーバーが欠落しているKB1212634/PRB1628241KB1212633/PRB1628236 メトリックインテリジェンス MID サーバー拡張コンテキストのクローン除外/プリザーバーがありません (ecc_agent_ext_context_metric)KB1212632/PRB1628223 イベント管理 MID サーバー拡張コンテキストのクローン除外/保持者がありません (ecc_agent_ext_context_event/eif_listener_context) これらはすべて Vancouver で修正されていますが、拡張テーブル階層内のすべてのテーブルが除外されてクローンで保持されていない場合、クローンエンジンの既知の問題がまだ存在する可能性があります。 ソリューション: 不良レコードを修復するには、次の KB 記事を使用してください。https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0716609 レコードを検索するには、次のようにスクリプトを設定します。findOrphans('ecc_agent_ext_context', null, false); 次に、それらを削除するには、次を使用します。findOrphans('ecc_agent_ext_context', null, false); その後、MID サーバーの拡張/コレクター/リスナーの再セットアップが必要になる場合があります。 予防: 今後これを防ぐには、ecc_agent_ext_contextとそれを拡張するすべてのテーブルのクローン除外と保持を追加する必要があります。 このリストフィルターを使用して、インスタンスにある子テーブルのリストを表示できます。https://<インスタンス名>.service-now.com/sys_db_object_list.do?sysparm_query=super_class.label%3DMID%20Server%20Extension%20Context%5EORsuper_class.super_class.label%3DMID%20Server%20Extension%20Context&sysparm_first_row=1&sysparm_view= インスタンスに直接接続されている ACC エージェントまたは DEX クライアント これらは MID サーバーをバイパスするため、それほど問題になりません。これらのエージェントはインスタンスで直接認証するため、ユーザーレコードと mTLS 証明書はクローンに保持する必要があります。 次のテーブルは cGTM リリース前は保持/除外されましたが、(PRB1728925) すべきではありません。これを行うと、Fenix はデータの処理に失敗します。 DEX Metric Definition dex_metric_definitionDEX Metric Processing Rule dex_metric_processing_ruleDEX Metric Source dex_metric_sourceDEX Metric Tag dex_metric_tagDEX Metric Tag M2M dex_metric_tag_m2mDEX Source Metric Configuration dex_source_metric_configDEX Source Tag M2M dex_source_tag_m2m 構成ファイル テーブル sn_agent_configuration_file はクローン作成されており、クローンを作成する必要があります。つまり、ターゲットインスタンスに接続するエージェントは、ソースインスタンスからコピーされた構成ファイルを使用する必要があります。 既知の問題: PRB1734261構成ファイルのメタデータがインスタンスのクローン後にエージェントに送信されないこの問題は ACC-F 3.5.3 で修正されています ACC CI およびレコード 次の 2 つのメインテーブルに ACC の詳細が記録されます。 エージェントクライアントコレクター [sn_agent_cmdb_ci_agent]メインレコード。これは CMDB CI クラスです。別のレコードから ACC を参照している場合は、このレコードを参照します。エージェントクライアントコレクター情報 [sn_agent_ci_extended_info]追加フィールド。上記の各レコードにもこれらの 1 つがあり、それを参照しています。エージェントのリストに表示されるステータス列のほとんどは、実際にはこのレコードからドット連結されています。 実際には、このテーブルのペアは同じレコードの 2 つの半分です。残念ながら、特に CMDB のような複雑な TPP 拡張テーブルでは、クローンでは単一の CI クラスを確実に除外したり保持したりすることはできません。 これは、ターゲットインスタンスと通信する、またはターゲットインスタンスの MID サーバーを介して通信するエージェントインストールのレコードがクローンで失われることを意味します。ターゲットからコピーされたレコードは、このインスタンスとは無関係になります。ただし、クローン後にエージェントがチェックインすると、自動的に再作成されるはずです。 sys_class_pathの不一致 アプリまたはプラグインが CMDB 拡張テーブルにテーブル/クラスを追加すると、そのテーブルのsys_class_path値がランダムに作成され、sys_db_objectレコードに保存されます。このようなプラグインを異なるインスタンスに個別にインストールすると、sys_class_path値が異なります。 つまり、保持されているクローンターゲットインスタンスのレコードには、クローン後に無効なsys_class_path値が設定されます。これらのレコードは引き続き cmdb のトップレベルのリストに表示されますが、「レコードが見つかりません」というエラーが発生して開くことはできません。 元の CI レコードの関連 sn_agent_ci_extended_info レコードも削除されます。 その結果、クローン後に既存の ACC インストールがインスタンスとの通信を開始すると、新しい重複 CI レコードが自動的に作成されます。 PRB1555641はACCのために開かれましたが、より一般的なTPPクローン問題PRB1411998が原因であり、現時点では「期待どおりに機能している」と見なされています。CMDB などの TPP 拡張テーブルは、少なくともクローンによって CMDB 内の各クラスのクラスパスに対して 2 つのインスタンスが同期されるまでは、プリザーバーをサポートしていません。 ソリューション: 開いたり削除したりできない破損したレコードがある場合は、sn_agent_ci_extended_infoとsn_agent_cmdb_ci_agentのクローン保持を削除し、クローンを再作成します。これにより、以前のクローンから保持されていた破損したレコードが削除されます。 両方のインスタンスに ACC-F をインストールした後、最初のクローンの sn_agent_extended_info または sn_agent_cmdb_ci_agent を保持しないでください。クローン後にエージェントが再度チェックインすると、これらは新たに作成されます。 それ以降は、sys_class_path値が両方のインスタンスで同じになるため、プリザーバーを再度追加できるようになるはずです。 ACC-F cGTM 202009であるため、agent_extended_infoとsn_agent_cmdb_ci_agentはクローンから除外され、保持されません。これらのレコードはソースからコピーされません（これらのエージェントはソース側のエージェントであるため意味がありません）。またターゲットに残すこともありません（この問題を回避するため）。 最初にクローンソースインスタンスに ACC-F をインストールします。クローン後、ターゲットインスタンスは sn_agent_cmdb_ci_agent クラスのsys_class_path値が同じになるため、ACC がターゲットインスタンスにインストールされても、将来のクローンで問題が発生することはありません。 詳細については、既知のエラーの記事を参照してください: TBC ACC プラグイン (Sensu 資産) ACC プラグイン (別名 Sensu 資産) は「コード」であるため、クローンにコピーする必要があります。sn_agent_asset内のすべてのレコードとその.tar.gzファイルの添付ファイルをクローンにコピーし、ターゲット上にあったすべてのレコードを置き換える必要があります。 しかし、これらは大きな添付ファイルとして扱われ、削除されています。 2022 年 3 月以降、クローンエンジンはこれらの添付ファイルをクローンでコピーすることを認識しているため、この問題は発生しません。 詳細については、既知のエラーの記事を参照してください。KB1002379/PRB1550798 大きな添付ファイルを除外するクローンは、sn_agent_asset の ACC プラグインレコードに添付された tar/gz ファイルを削除することで、エージェントクライアントコレクターを壊します ソリューション: すべてのエージェントクライアントコレクタープラグインを修復して、添付ファイルを元に戻します。カスタム ACC プラグインは、クローンソースから XML としてインポートできます。ACC プラグインレコードの XML エクスポートには、添付ファイルデータも含まれます。 パターンスクリプトファイル エージェントレスパターンの実行中に、スクリプトをターゲットデバイスにアップロードする必要がある場合、「sa_uploaded_file」テーブルのレコードに添付ファイルとして保存されているファイルを使用します。PRB1507034 2021 年 7 月にクローンエンジンを修正したため、クローンセットアップで [添付ファイルを除外] が true の場合でも、これらの添付ファイルは常にクローンを作成する必要があります。 ACC を介したパターン実行では「putFile」メソッドを使用できませんが、一部の (すべてではない) パターンでは、putFile に使用されるはずのファイルが、パターン実行と呼ばれる ACC プラグイン (資産) に資産として配置されるようになりました。たとえば、Oracle GLAS パターンでは、これらの添付ファイルを SQL スクリプトに使用します。 ただし、MID は引き続き最初に「sa_uploaded_file」テーブルをチェックし、そこにレコードまたは添付ファイルがない場合、MID はエージェントに独自のアセットキャッシュフォルダーのファイルを使用するように指示しません。 アプリ/プラグインおよびインストール済みバージョン クローンにより、プラグイン/アプリがダウングレードされ、プラグイン/アプリとそれに付随するテーブルが削除される可能性があります。 新しいバージョンの CC アプリ/プラグイン上にあり、それ以降のバージョンのサーバーに ACC がインストールされているクローンターゲットインスタンスは、以前のバージョンの ACC のソースインスタンスによって上書きされる可能性があります。今後のバージョンのインストールは、以前のバージョンのインスタンスにリンクされるようになり、コードとチェックに互換性がなくなる可能性があります。 ACC アプリがインストールされていないクローンソースインスタンスには ACC コードやテーブルがなく、クローン後のクローンターゲットインスタンスも同様です。これらのテーブル、そこに含まれるレコード、およびそれらに付随するコードは、クローンの一部として削除されます。MID サーバー Web サーバー拡張コンテキストと Websocket リスターコードは存在しなくなるため、ACC インストールは引き続き MID サーバーとの通信を試みますが、MID サーバーはこれらの要求に対して何も実行しません。これらの孤立した ACC は、クローン後にインスタンスで再度 ACC がセットアップされると、再インストールが必要になる場合があります。 ソリューション: クローンを作成する前に、まずソースインスタンスに ACC 関連のプラグインをインストールしてアップグレードし、ターゲットインスタンスの内容と一致させます。ACC をクローンソースインスタンスでセットアップしたり使用したりする必要はなく、存在するだけです。 ACC-M - モニタリング / メトリックベース イベントタイプ ACC チェックはイベント管理 SQL em_eventテーブルに入力されますが、メトリックインテリジェンスのメトリクスタイプチェックは、通常の Glide アプリケーションノードと SQL データベースノードとは別のノード/インスタンスであるメトリックベース (別名 Clotho) と呼ばれる時系列データベースに入力されます。 メトリックベースコンテンツは、ソースからターゲットにクローンされます。 ターゲットにメトリックベースが構成またはインストールされていない場合、メトリックベースコンテンツにアクセスするには、クローン後にメトリックベースプラグインをインストールする (または再インストールする) 必要があります。 ServiceNow サポートエンジニアは、クローン後のトラブルシューティングに役立つ次の社内記事にアクセスできます。 メトリックベースの内部サポートドキュメントKB0678880KB1582884 特定の条件下でクローンワークフローによって再インストールされるプラグイン クローン作成では、Jakarta パッチ 7 以降、sys_clotho_config の除外/プリザーバーが追加されPRB1159519メトリックベースがサポートされます。 ACC-L:ヘルスログアナリティクス HLA は複数の統合コンポーネントから構築されているため、Glide アプリケーションノードのコードや SQL データベースのデータだけではありません。 Glide アプリケーションノードで実行されている HLA プラグインとスコープ対象アプリOccultus インスタンスエラスティック検索データメトリクスベースのデータ クローンプロセス中に、上記のすべての関連コンポーネントのソースインスタンスのデータがターゲットインスタンスにコピーされます。 クローン作成プロセスでは、新しい ElasticSearch、Metric Base がプロビジョニングされ、必要に応じて Occultus インスタンスもプロビジョニングされ、関連するテーブルも新しい構成で更新されます。 詳細については、以下を参照してください。 システムクローン - ヘルスログアナリティクス | HLA Quebec ServiceNow サポートエンジニアは、クローン後のトラブルシューティングに役立つ次の社内記事にアクセスできます。 KB1002293 HLA バックアップ手順:お客様クローンのサポートKB1273656作業指示書 |クローン後にターゲットインスタンスの HLA の問題をトラブルシューティングする方法KB1119941作業指示書 |ヘルスログアナリティクス (Loom) - 手動クローンステップ 一般的に、クローンが原因で HLA にいくつかの問題があります。これは ACC-L 固有のものではありませんが、エージェントまたは MID サーバー拡張コンテキストエラーを意味する可能性があります。以下が含まれますが、これらに限定されません。 クローンソースに HLA がない場合 クローンソースにヘルスログアナリティクスプラグインがインストールされていない場合、クローン後、ターゲットにもプラグインがインストールされません。アプリ/プラグインを「保持」することはできません。ただし、ターゲットの Occultus インスタンスは残り、サービスレコードは保持されます。 この状況では、次のいずれかを実行できます ターゲットに HLA をインストールまたは、Occultus ノードを廃止します インスタンスとOccultus バージョンの非互換性 クローン作成後にターゲットインスタンスのバージョンが変更されると、既存の Occultus ノードバージョンがインスタンスバージョンと互換性がなくなる可能性があります。Occultus ノードは、それに合わせてアップグレードまたはダウングレードする必要がある場合があります。