Agent Client Collector Visibility (エージェントクライアントコレクターヴィジビリティ)ヴィジビリティ/ディスカバリーに固有ではない Agent Client Collector の詳細については、以下を参照してください。 エージェントクライアントコレクター Agent Client Collector for Visibility (ACC-V) は、ホスト上でプッシュベースのディスカバリーを実行するために Windows および Linux サーバーにインストールされる ServiceNow エージェントです。ACC-V は、OS クエリーコマンドと OS 固有のコマンドを実行して情報を収集する Ruby スクリプトを展開します。さまざまなファイルシステムとストレージデバイス、TCP 接続、実行中のプロセス、およびターゲットホストに関するその他の情報からデータを検出できます。 ACC-V プッシュベースのモデルを使用して、ServiceNow 構成管理データベース (CMDB) にターゲットシステムを登録して管理できます。資格情報の提供、スケジュールの構成、IP 範囲のスキャンなどは必要ありません。 ACC-V は、ディスカバリーを実行するための追加メカニズムです。これは、システム情報、ネットワークインターフェイス、実行中のプロセスなどの OS 関連属性の水平 IP ベースのディスカバリーに代わるものです。ACC-V は、オンプレミスサーバーおよびクラウドインスタンスに適しています。ACC-V を使用するには、ターゲットホストに ServiceNow エージェントクライアントコレクター (ACC) をインストールする必要があります。 Quebec パッチ 3 以降、CI が ACC-V によって検出されたことを明確に示すために、discovery_source ACC-Visibility が導入されました。 プッシュディスカバリーと SAM の併用の詳細については、以下を参照してください。 プッシュベースのディスカバリーと SAM の併用 目次 メリット要件ACC-V の仕組みトラブルシューティング メリット エージェントが通信を開始し、MID サーバー経由で ServiceNow インスタンスへの接続を維持します。ACC とともにインストールされたエージェントは自己認識型であり、ディスカバリーデータをパッケージ化し、ACC-V ポリシーで設定された事前決定されたスケジュールに従って、MID サーバー経由でこのデータを ServiceNow インスタンスに送り返します。ターゲットホストで興味深いイベント (長時間シャットダウンした後にオンラインに戻るなど) が発生すると、ディスカバリーがトリガーされます。アプリケーションは、ACC をインストールし、MID サーバーと通信する特定のターゲットを既に追跡しています。 要件 ディスカバリー [com.snc.discovery] プラグインをインストールしてアクティブ化する必要があります。Agent Client Collector Framework (ACC-F) を ServiceNow インスタンスにインストールする必要があります。エージェントをターゲットホストにインストールする必要があります。Quebec パッチ 3 以降にアップグレードしていることを確認します。ITOM-Discovery または ITOM-Visibility SKU (SU ベースのライセンス) が必要です ACC-V の仕組み 大まかに言うと、ACC-V は以下と連携して機能します。 ServiceNow インスタンスServiceNow MID サーバーターゲットホストマシン前述のターゲットホストマシン上で実行される ServiceNow Agent Client Collector ACC-V アーキテクチャ ACC-V は、Discovery をスケジュールして実行するためにチェックとポリシーを適用します。ディスカバリーは、次の場合にトリガーされます。 定期的なスケジューリング:ディスカバリーが定期的にトリガーされるポリシーベースのアプローチCI 削除時：コンピューターまたはサーバーの CI レコードが削除されたとき [拡張検出 - CI 削除時 (Enhanced Discovery – On CI Delete)] ビジネスルールは、指定された CI に関連付けられた CI がsn_agent_cmdb_ci_agentから削除されたエンドポイント検出チェックをトリガーします。 MID サーバーサイクル:MID サーバーがダウンして復帰した場合ターゲットホストサイクル：ターゲットホストが停止して復旧した場合ネットワーク切断：ターゲットへのネットワークリンクに切断がある場合 エージェントのディスカバリーの実行頻度/ディスカバリーのトリガー方法 「拡張検出ポリシー」で設定されているとおり ポリシーを表示するには、「エージェントクライアントコレクター>構成>ポリシー」に移動しますチェックインスタンス「間隔を上書き」は、ポリシー間隔を上書きできますポリシーによって検出がトリガーされたときに ECC キュー出力が作成されない ディスカバリーは、エージェントレコードを開いて [ディスカバリーの実行] をクリックすることでオンデマンドで実行できます。 オンデマンドでトリガーされると、トピック「MonitoringProbe」と名前「on_demand_request」のecc_queue出力レコードが作成されます出力ペイロードには、実行するエージェントやポリシーなど、ディスカバリーを実行するために必要な情報が含まれますペイロードでは、sn_agent_cmdb_ci_agentのエージェント ID である json に「clients_cis」が表示されます 入力の処理方法 ビジネスルール「AgentNowResponseProcessor」がecc_queue入力を処理します。ビジネスルールはスクリプトインクルード AgentNowHandler.processEccRecord(current); を呼び出します。スクリプトインクルードは、ペイロードを使用してcheck_type_idを取得し、sn_agent_check_typeをクエリします。 検出の場合は、sn_agent_disco_check_type下のタイプになります。 チェックタイプ ID は、ペイロードを処理するスクリプトを呼び出すために使用されます。 EnhancedDiscoveryHandler.handleDiscovery(checkResults)使用される他のスクリプトインクルード: MainDiscoveryHandlerEnhancedDiscoveryHandlerEndpointDiscoveryCloudHelper スクリプトは、識別および調整エンジンに渡される最終的な JSON ペイロードを構築します。 Properties (プロパティ) sn_agent.disco_minimum_threshold_for_rediscovery_minutes システムの検出頻度が高すぎないようにするため sn_agent.disco_disable_ci_clobber_of_agentless_disco 競合を避けるために、ACC-V は、水平 IP ベースのディスカバリーによって検出された CI がターゲットホストの IP に既に存在する場合 (ServiceNow discovery_source)、ディスカバリーを実行しません。この動作をオーバーライドするには、システムプロパティ sn_agent.disco_disable_ci_clobber_of_agentless_disco を false に設定します sn_agent.disco_ci_clobber_of_agentless_disco_threshold_days 水平 IP ベースのディスカバリーが特定の時間にわたって実行されなかった場合、この設定は無視されます。必要に応じて、システムプロパティ [sn_agent.disco_ci_clobber_of_agentless_disco_threshold_days] を更新します。デフォルトは 14 日です トラブルシューティング 入力ペイロードecc_queueデータは正常に返されましたが、それに応じて CI が更新されません 注: 次の手順では、管理者権限が必要になる場合があります。本番インスタンスでスクリプトを実行する前に、非本番インスタンスでスクリプトをテストします。 ペイロードが処理されたときにシステムログ/ノードログを確認し、エラーを探します。 エラー:エラーを解決します。アクションはエラーの内容によって異なります。エラーなし:次のステップに進みます。 による入力ペイロード処理のデバッグ ecc_queue入力のsys_idを取得します (正しい入力を見つけるには、ecc_queueでエージェント ID を含む入力ペイロードを検索します)。スクリプトインクルード AgentNowHandler を開いています。スクリプトセクションで、[Open Script Debugger] (バグのあるアイコン) をクリックします。processEccRecord() 関数にブレークポイントを設定します。[System Definition > Scripts - Background] に移動します。スコープを「sn_agent」に設定します。次のスクリプトを実行します。 // In the following line, place the sys_id of the ecc_queue inputvar payloadSysID = ""; var eccRecord = new GlideRecord('ecc_queue'); eccRecord.get(payloadSysID); var ANH = new AgentNowHandler(); ANH.processEccRecord(eccRecord); 必要に応じて、問題があると思われるスクリプトにデバッグステートメントを追加します。 Linux デバイスのシリアル番号と TCP 接続がない エージェントが、関連する実行中のプロセスとともに OS シリアル番号と TCP 接続を取得するには、Linux システムで「dmidecode」と「ss」の sudo アクセスが必要です。たとえば、このコンテンツを /etc/sudoers または /etc/sudoers.d/ の個別ファイルに追加できます。 Cmnd_Alias AGENT_ACC_V = /usr/sbin/dmidecode,/usr/sbin/ss servicenow ALL=(root) NOPASSWD:AGENT_ACC_V ペイロードが出力セクションにエラーで返される エラーの例: "output" : "C:/Program Files/ServiceNow/agent-client-collector/embedded/lib/ruby/gems/2.7.0/gems/json-2.3.0/lib/json/common.rb:156:in `parse': 783: unexpected token at '' (JSON::ParserError) トラブルシューティング例 01 - ホスト上のファイルにデバッグを送信: endpoint_discovery.rb を更新します。次のコードを見つけます。 $logger = Logger.new(STDOUT)$logger.level = options.log_level.nil? ? "FATAL" : options.log_level 次のコードに置き換えます。 $logger = Logger.new('pathAccountCanWriteTo')#Comment out log level or set to debug#$logger.level = options.log_level.nil? ? "FATAL" : options.log_level 問題を再現します。作成されたログファイルを確認します。 トラブルシューティング例 02 - デバッグステートメントをさらに追加します。 デバッグパラメーターを渡すように拡張ディスカバリーチェックを更新します。 (例: endpoint_discovery.rb --compact --select=basic_inventory,installed_software,file_systems,serial_numbers,network_adapters,tcp_connections,storage_devices,running_processes --log-level DEBUG エージェントクライアントコレクターのcheck-allow-list.jsonファイルを更新して、上記のコマンドを実行できるようにします。新しいテスト検出を実行します。新しい出力とacc.logファイルを確認します。必要に応じて、endpoint_discovery.rb スクリプト、またはスクリプトによって呼び出される他のスクリプトにデバッグステートメントを追加します。 デバッグをさらに追加する例: # Creating a logger to log information to C:\temp\accDebug.log # in a path the acc service user can write to$logger = Logger.new('C:\temp\accDebug.log')# Log additional information$logger.info('variableOrStringToGetMoreInformation') 作成された新しいログファイルを確認します。 トラブルシューティング例 03 - ホスト上で直接チェックを実行する: 拡張検出チェックのファイルはエージェントのキャッシュディレクトリにダウンロードされるため、エージェントで直接チェックを実行してトラブルシューティングを行うこともできます。 次の画像は、osquery コマンドを実行した結果を示しています。 osqueryi --json --logger_min_status 1 "select hostname,hardware_vendor,hardware_model,hardware_version,physical_memory,cpu_brand from system_info" Rubyスクリプトは、トラブルシューティングのためにコマンドラインから直接実行することもできます。ただし、これは ACC が実行する場合とまったく同じではなく、異なる結果やエラーが生じる可能性があることに注意してください。 endpoint_discovery.rb スクリプトは、パラメーター「--select」の配列を受け取ります。これらは、endpoint_discovery.rb によって呼び出される他のスクリプトの名前です。これらの各スクリプトは、サーバー内のデータを検出し、JSON ファイルを返します。これらの結果はすべて合算され、インスタンスに返されます。完全なコマンド: endpoint_discovery.rb --compact --select=basic_inventory,installed_software,file_systems,serial_numbers,network_adapters,tcp_connections,storage_devices,running_processes 次の例では、endpoint_discovery.rb によって呼び出されたスクリプトの 1 つをテストします。 ACC キャッシュディレクトリでosqueryi.exeパスを検索し、ユーザーパスに追加します。見つからない場合は、ファイルが見つからないというエラーが発生する可能性がありますACC サービスユーザーでコマンドプロンプトを開きますbasic_inventory だけを渡して endpoint_discovery.rb を実行し、出力をファイル endpoint_discovery.rb --log_level DEBUG --compact --select=basic_inventory >> basicInventoryOutput.txt ファイルを確認します。出力例: