Agent Client CollectorSummary 目次 ACC アプリケーション メリット機能 アーキテクチャの概要 セットアップと展開拡張性パフォーマンスとフットプリントコマンドとログ 構成 エージェント構成テーブルインスタンスのスケジュール済みジョブ： チェック ポリシーAgent Client Collector プラグイン/資産 Web サーバー MID Web サーバーフェイルオーバー構成 ライフサイクル エージェント (sn_agent_cmdb_ci_agent と sn_agent_ci_extended_info) のレコードはどのように作成され、更新されますか？エージェント内でポリシーとチェックはどのように更新されますか？MID Web サーバー内でポリシーとチェックはどのように更新されますか？資産はエージェントにどのようにダウンロードされますか？結果はエージェントからインスタンスにどのように送信されますか？ トラブルシューティング エージェントのダウン インスタンスのクローン Q&A Agent Client Collector (ACC) は、複数のユースケースに対応する Sensu ベースのエージェントです。エージェントがインストールされているホストの監視、エンドポイントの監視、エージェントがインストールされているホストの検出などに使用できます。 ACC アプリケーション Agent-Client-Collector Framework (ACC-F) ACC-F は、エージェントフリートを管理するストアアプリです。SN アプリがエージェントプログラムとやり取りするための UI と API を提供します Agent-Client-Collector Monitoring (ACC-M) ACC-M は、ACC-F 上で実行されるストアアプリです。ServiceNow イベント管理にイベントをフィードするため、サーバー上で実行されている OS とアプリケーションを監視します Agent-Client-Collector Visibility (ACC-V) ACC-V は、ACC-F 上で動作するストアアプリです。CMDB に入力するためにサーバーとエンドポイントに関する情報を収集しますACC-V の詳細については、以下を参照してください。 Agent Client Collector Visibility メリット ACC のメリットには次のようなものがあります。 エンドツーエンドの監視高度な機能の活用効率的な CI バインディングサードパーティ製監視ツールへの依存度を軽減エンドツーエンドの AIOps ソリューションのワンストップショップエージェントホストの認証情報をインスタンスに保存する必要がない 機能 サーバー、アプリケーション、ネットワークデバイスなどの健全性を監視サーバー以外のデバイス (ネットワークデバイスなど) の監視は、対象デバイスに SNMP/REST コールを送信するプロキシエージェントを使用して実行可能プロキシエージェントからのリモート HTTP コールを使用したエントリーポイントの監視Operational Intelligence を使用した測定基準コレクターと例外検出 アーキテクチャの概要 注意：上の画像の Clotho とイベントは、ACC-M で使用されるコンポーネントの一部を表しています。 セットアップと展開 必要なプラグインをインストールMID サーバーをインストールMID サーバーに移動して [Agent Client Collector Listener のセットアップ] をクリック これにより「MID Web サーバー」がインストールされます。後のステップでエージェントの接続を構成します 監視/検出対象のホストにエージェントをインストール インストールは、インスタンスのバージョンによってわずかに異なる場合があります。インストール手順については、以下を参照してください。 Agent Client Collector のインストール コマンドのユーザー/パスワードの組み合わせ (キーの代わりにユーザー/パスワードを使用する場合) は、「MID Web サーバー」用に設定されたユーザーと一致している必要があります。これは MID サーバーユーザーと同じではありません[Agent Client Collector] > [展開] > [エージェントのダウンロード] に移動して、Agent Client Collector インストーラーをダウンロードします。 MID、MID Web サーバー、エージェントのインストールと接続が完了してから、ポリシーとチェックを構成します。 注意：ポリシーとチェックの構成は、この順序以外でも実行できます。ただし、MID サーバーとエージェントがセットアップされていないと、テストが行えません。 拡張性 エージェントフレームワークは、エージェントから情報を収集して SN データベースに保存するフローを追加できるように設計されています。このフレームワークは、初期インストールの一部ではないエージェントスクリプト/実行可能ファイルである「資産」の配布手段を備えています。コマンドが実行されてペイロードが作成されると、開発者は MID、インスタンス、またはその両方でスクリプトを実行してこのペイロードを処理できます。このフレームワークは、チェックがポリシーの一部であるかどうかに関係なく、指定したエージェントでチェックを実行する API を備えています。 パフォーマンスとフットプリント インストールされている Agent Client Collector については、フットプリントに関するドキュメントのページを参照してください。 Agent Client Collector のフットプリント コマンドとログ WindowsLinuxMacOS ログフォルダー C:\ProgramData\ServiceNow\agent-client-collector\ /var/log/servicenow/agent-client-collector/ /var/log/servicenow/agent-client-collector/acc.log インストールフォルダーC:\Program Files\ServiceNow\agent-client-collector\/etc/servicenow/agent-client-collector/ /opt/servicenow/agent-client-collector/ 停止 サービス経由 (Agent Client Collector サービス)sudo systemctl stop acc sudo <installPath>/bin/acc stop 開始 サービス経由 (Agent Client Collector サービス) sudo systemctl start acc sudo <installPath>/bin/acc stop または、スタートアップ時に「/Library/LaunchDaemons/com.sn.acc.plist」で launchctl を構成 構成ファイル <installation_folder>\acc.yml <installation_folder>/acc.yml /Library/Application Support/servicenow/agent-client-collector/acc.yml 許可リスト パスは acc.yml parameter allow-list にあります パスは acc.yml parameter allow-list にあります /Library/Application Support/servicenow/agent-client-collector/check-allow-list.json 構成 エージェントを使用して、インストールされているホストの監視と検出を行えます。エージェントによって実行されるアクションは、「チェック」で実行されます。チェックに失敗してアラートがトリガーされた場合、イベントを作成できます。チェックはポリシーにグループ化されます。ポリシーは、チェックを実行するエージェント (Linux、Windows、アプリケーションなど) と頻度を決定します。 エージェント構成 エージェントの主な構成ファイルは、acc.yml と check-allow-list.yml です。check-allow-list.yml は、エージェントが実行できるコマンドを決定します。チェックが作成されたら、関連リンク [許可リストコンテンツを生成] をクリックし、次に生成された値で check-allow-list.yml ファイルを更新し、エージェントでチェックを実行できるようにします。 ログパラメーター： log-fileログファイルの場所。デフォルト値： Windows：C:/ProgramData/ServiceNow/Agent-client-collector/logLinux：/var/log/servicnow/agent-client-collector/acc.log log-file-and-stdoutstdout ファイルにログを書き込みます。デフォルト値：false。log-file-max-ageログファイルが維持される最大経過時間 (日数)。これを超えると、ログがローテーションされて、システムメモリから削除されます。デフォルト値：3。log-file-max-backupsシステムに格納できるログファイルの最大数。この数を超えると、ログがローテーションされて、システムから削除されます。デフォルト値：3。log-file-max-sizeログファイルの最大サイズ (MB)。これを超えると、ログがローテーションされて、システムメモリから削除されます。デフォルト値：10。log-levelログの対象となるログレベル。使用可能なオプション：Panic、Fatal、Error、Warn、Info、Debug。デフォルト値：Info。 指定されたログレベルは、ログに表示されるイベントの最も低いレベルを表します。例えば、「Error」を指定したユーザーには、すべての Error イベントと、Fatal および Panic イベントが表示されます。 テーブル https://yourInstance.service-now.com/sys_db_object_list.do?sysparm_query=nameLIKEsn_agent インスタンスのスケジュール済みジョブ： https://yourInstance.service-now.com/sysauto_script_list.do?sysparm_query=sys_package%3Ddeb59787c317030039a3553a81d3aee9&sysparm_view= Agent Client Collector キープアライブエージェント機能のサポートステータスの計算モニタリングポリシーの更新と公開ポリシーインポート後の MID サーバー同期とドラフト削除すべてのエージェントの MID リスト更新すべての新しいエージェントの MID リスト更新要求の処理済みチェックの更新 チェック チェックとは、コマンドとその構成の組み合わせです。チェックは Agent Client Collector のサーバーで実行されます。チェックはベースシステムで提供され、そのコマンドはオペレーティングシステムとアプリケーションの監視データを提供するスクリプトを実行します。チェックのデフォルト名は、監視や測定の対象、エンティティ、および監視データを示します。例えば、「os.linux.check-system-cpu」という名前のチェックは、Linux システムの CPU データをチェックします。チェックで識別されたコマンドが監視対象サーバーで実行され、出力とステータスが提供されます。 チェック定義の作成 ポリシー ポリシーは、Agent Client Collector によって監視される CI と、それらの CI で実行されるチェックで構成されます。ポリシーを作成するときに、チェックを実行する特定の CI を決定するフィルターを設定します。例えば、すべての Apache Web サーバーでチェックを実行するようにポリシーを設定できます。必要に応じて、新しいポリシーを作成したり、デフォルトのポリシーを編集したりすることができます。 新しいポリシーを作成 ポリシーのライフサイクル Agent Client Collector プラグイン/資産 Agent Client Collector プラグインは、追加のエージェント機能を提供するスクリプトまたはスクリプトのグループです。例えば、より多くの測定基準を収集したり、より多くのチェックを実行したり、アプリケーションキューサイズが 60% または 80% に達している場合にイベントを生成したりします。チェックとプラグインの間に依存関係を作成して、チェックをプラグインに関連付けます。プラグインは、一度に複数のチェックとの依存関係を持つことができます。同様に、チェックは一度に複数のプラグインに依存できます。プラグインは、チェックと同じエージェントで実行されます。 必要に応じて Agent Client Collector プラグインを作成します。プラグインは tar.gz ファイルとしてフォーマットされ、関連するチェックとともに実行されます。 プラグイン/資産は、テーブル sn_agent_asset によって、または [Agent Client Collector] > [構成] > [ACC プラグイン] に移動して確認できます。 プラグインの作成と編集 Web サーバー Web サーバーは、エージェントが接続する「エンドポイント」です。Web サーバーを確認するには、[Agent Client Collector] > [展開] > [MID Web サーバー] に移動します。そこでは、実行中の Web サーバーのリストを確認できます。これらは、エージェントが接続できるサーバーとポートです。 このフォームの関連リンクを使用して、パラメーターの停止、開始、再起動、テスト、更新が行えます。 MID Web サーバーフェイルオーバー構成 エージェントの構成ファイルである acc.yml によって、エージェントが接続する MID Web サーバーが決まります。エージェントの構成ファイルでは、複数の Web サーバーを構成できます。MID Web サーバーへの通信を確立できない場合は、acc.yml ファイルで次に設定されている MID Web サーバーが使用されます。エージェントは、ロードバランサーの後方にある仮想 IP アドレスにも接続できます。 acc.yml に 1 つ以上の MID サーバーフェイルオーバー URL を指定します。エージェントは次の URL を使用して MID サーバーと通信します。このリストは反復的です。つまり、エージェントは最初の URL を試行し、失敗した場合は 2 番目の URL に移動します。自動 MID 選択機能がオンである (ファイル mid.list.json が存在する) 場合、エージェントによって接続テストが実行され、バックエンド URL リストが書き換えられます。リストの順序は、まず ping の時間、次に MID に既に接続されているエージェントの数によって決まります。つまり、この機能が有効である場合、リストの最初にある MID サーバーの ping の時間が最も短く、エージェントの数が最小であることになります。 ServiceNow インスタンスから既存のエージェントへの定期的な MID サーバー更新情報の送信を無効にするには、次の操作を実行します。 [システムプロパティ] > [すべてのプロパティ] に移動します。sn_agent.enable_auto_mid_selection プロパティを「false」に設定します。 個々のエージェントの自動 MID サーバー選択を無効にするには、次の操作を実行します。 エージェントの acc.yml ファイルで、enable_auto_mid_selection プロパティを見つけます。プロパティ値を「false」に設定します。 ライフサイクル エージェント (sn_agent_cmdb_ci_agent と sn_agent_ci_extended_info) のレコードはどのように作成され、更新されますか？ 注意：詳細なデバッグメッセージを表示するには、エージェントセット acc.yml ファイルで log-level = "debug" を設定し、MID サーバーで mid.log.level = debug を設定します。 エージェントは、acc.yml の構成を使用して MID Web サーバーに接続します。エージェントはキープアライブイベントを ip:port/ws/events に送信します。エージェントが最初に立ち上がるときには、キープアライブループの開始が次のように表示されます。 {"component":"agent","level":"info","msg":"Starting keepalive loop","time":"2021-07-26T09:43:49-07:00"} MID サーバーエージェントログには、MID サーバーが要求を受信し、以下のように応答することが表示されます。 07/26/21 10:29:53 (772) qtp540917385-156 DEBUG: (156) com.service_now.mid.webserver.jetty.WebServer - SERVER onFillable()...07/26/21 10:29:53 (773) qtp540917385-156 DEBUG: (156) com.service_now.mid.webserver.jetty.WebServer - onBinaryMessage(HeapByteBuffer@4079c03a[p=0,l=2293,c=2293,r=2293]={<<<keepalive\n{"timestamp":16...nse_required":"true"}}}>>>})07/26/21 10:29:53 (791) qtp540917385-156 DEBUG: handleKeepalive: payload [{"timestamp":1627320593,"entity":{"entity_class":"agent","system":{"hostname":"......"}}}] MID サーバーは、インスタンスに更新を送信します (Last refreshed フィールドまたは更新が必要なその他のフィールドを更新します)。 インスタンスで以下を実行します。 Agent Client Collector API (/api/sn_agent/agents) は、MID サーバーが送信した更新を受信し、エージェント情報を更新します。 API は、/sys_ws_definition.do?sys_id=cf0d4208c3e3030039a3553a81d3ae9a で定義されています。 REST リソースは、それに応じてエージェントを更新/作成します。 最後に、MID サーバーがエージェントに次のように応答します。 07/26/21 10:29:53 (791) qtp540917385-156 DEBUG: Publishing message [{ }] to client:WIN-IHKAN2LQJE1. remote: org.eclipse.jetty.websocket.jsr356.JsrAsyncRemote@3efeb95707/26/21 10:29:53 (792) qtp540917385-156 DEBUG: (156) com.service_now.mid.webserver.jetty.WebServer - sendText("keep_alive_response{ }") エージェントには次のように表示されます。 {"component":"agent","content_type":"application/json","level":"debug","msg":"message received","payload_size":3,"time":"2021-07-26T09:46:54-07:00","type":"keep_alive_response"}{"component":"agent","level":"debug","msg":"keepalive response received from the backend.Setting the read deadline to 1627318314","time":"2021-07-26T09:46:54-07:00"} 注意：スケジュール済みジョブ「Agent Client Collector キープアライブ」は毎分実行され、前回のキープアライブ以降に last_refreshed フィールドが更新されていないエージェントをチェックし、それに応じてステータスを設定します。 エージェント内でポリシーとチェックはどのように更新されますか？ キープアライブプロセスの一環として、MID サーバーはエージェント構成の更新 (チェック、ポリシーなどの更新) をチェックします。MID サーバーはキープアライブに応答し、エージェントに送信する更新がある場合は追加情報を送信します。MID サーバーログでは、次のように表示されます。 07/26/21 12:32:53 (776) qtp540917385-157 DEBUG: Publishing config {"checksum":"826562631","check_requests":[{...}]} to client: name {...}, agent_id 5d06b30ec6c4ce0b MID Web サーバー内でポリシーとチェックはどのように更新されますか？ ジョブ「モニタリングポリシーの更新と公開」(sysauto_script.do?sys_id=126cee2bc3b513002a6f741e81d3ae87) が毎分実行されます。ジョブは MonitoringConfig.syncPoliciesToMid() を呼び出して、MID サーバーに更新を送信する必要があるかどうかをチェックします。MID サーバーに更新を送信する必要がある場合は、topic "MonitoringProbe" と source = "config_publish" で ecc_queue 出力レコードを作成します。MID サーバーは出力を処理し、エージェントポリシーを更新します。 資産はエージェントにどのようにダウンロードされますか？ 資産ファイルは、FileSyncer を経由して MID サーバーと同期します。 FileSyncer は、MID サーバーファイルとインスタンスファイルの同期を維持するプロセス/スレッドです。資産は次の MID サーバーフォルダーで確認できます。 %INSTALL_FOLDER%/agent/static/acc_plugin インスタンスのエージェントレコードとエージェントクライアントのポリシー/チェックを最新の状態に保つキープアライブプロセスには、「asset」セクションも含まれています。ペイロードの asset セクションは、次のようにエージェントに対してどの資産のダウンロードが必要かを指示します。： "assets" : [ { "sha512" : "c5149676070a227ab75a6c2979a568404e6710c9c8d57766d85a7c759504b833788ad133b99caa8d53cbd134fe42817b84eef1880b41d29a8e0e2f51fe8d5c73", "url" : "{{MID_URL}}/static/acc_plugin/windows/all/all/all/acc-visibility-modules-windows.tar.gz", "metadata" : { "name" : "acc-visibility-modules-windows", "namespace" : "default" } } エージェントは IP:PORT/static から資産をダウンロードします。エージェントでは、ファイルは「キャッシュ」フォルダーにダウンロードされます。 Windows：C:/ProgramData/ServiceNow/Agent-client-collector/cacheLinux：/var/log/servicnow/agent-client-collector/cache このファイル同期では、既存の MID サーバー同期機能が使用されます。この一般的な仕組み、既知の問題、デバッグのヒントの詳細については、以下を参照してください。KB0852276 MID サーバーのファイル同期の仕組み (トラブルシューティング支援) 結果はエージェントからインスタンスにどのように送信されますか？ チェックは、ポリシーで構成されているとおりに実行されます。エージェントは、WebSocket 接続を使用してチェック結果を MID サーバーに送信します。 エージェントの acc.log では、実行結果と送信結果を確認できます。例： {"component":"agent","level":"info","msg":"Running check, name: policy: Windows OS Metrics, check:os.windows.metrics-system-cpu-load ...{"component":"agent","level":"debug","msg":"{winchecks metric-windows-cpu-load [AGENT_DIR=C:\\Program Files\\ServiceNow\\agent-client...{"component":"agent","content_type":"application/json","level":"info","msg":"sending message","payload":"{\"timestamp\":1628002490,\"... MID サーバーでは受信した結果を確認できます。 DEBUG: handle result from client [WIN-IHKAN2LQJE1] agent_id [5d06b30ec6c4ce0b], check result is [{"timestamp":1628004950,"check":{"co...DEBUG: MID Script Include cache hit for name=MonitorResultParser MID サーバーでは、MID スクリプトインクルード MonitorResultParser により、チェック結果に mid_script フィールドが入力されているかどうかがチェックされます。これはテーブル sn_agent_check_type で構成されますmid_script フィールドに入力されていますか？ はい：mid_script を実行して結果を処理します。 結果は mid_script によって異なります。例： 入力として ecc_queue に送り返すイベントとして送り返す測定基準として送り返す いいえ：結果を ecc_queue に送信します。 結果がインスタンスに入ると、sn_agent_check_type インスタンススクリプトが結果を処理 トラブルシューティング 注意：詳細なデバッグメッセージを表示するには、エージェントセット acc.yml ファイルで log-level = "debug" を設定し、MID サーバーで mid.log.level = debug を設定します。 エージェントのダウン エージェントが接続する MID Web サーバーをメモします。これは、エージェントリストまたはテーブル sn_agent_ci_extended_info で確認できますMID サーバーは稼働していますか？ はい：次のステップに進みます。いいえ：MID サーバーを起動します。 MID サーバーは正常に起動し、稼働中と表示されている？ はい：次のステップに進みます。いいえ：MID サーバーの起動に関する問題をトラブルシューティングします。次を参照してください。 MID サーバーダウンのトラブルシューティング [Agent Client Collector] > [展開] > [MID Web サーバー] に移動します。MID Web サーバーは起動していますか？ はい：次のステップに進みます。いいえ：[スタート] をクリックして MID Web サーバーを起動します。 MID Web サーバーが正常に起動し、設定されたポートでリッスンしているプロセスがオペレーティングシステムに表示されましたか？ はい：次のステップに進みます。いいえ：MID サーバーエージェントとラッパーログで Web サーバーの起動に関する問題を確認します。 ホスト上でエージェントが実行されていますか？(Windows では services.msc で、UNIX/Linux オペレーティングシステムでは top や ps などのツールで確認可能) はい：acc.log ファイルを確認します。いいえ：acc.log ファイルを確認します。 acc.log にネットワークエラーが表示されていますか？ はい：エージェントを実行中のサーバーが、構成されている Web サーバーホストとポートにも通信できることを確認します。 その他のエラーを解決します (実行するアクションはエラーによって異なります) インスタンスのクローン インスタンスが別のインスタンスにクローンされる場合、MID サーバーと ACC のインストールはクローンされません。直接関連するファイルと構成は保持されますが (保持されるはずですが、そうでない場合もあります)、多くのコードと設定はソースインスタンスからクローンされます。既知の問題の詳細と、クローンが ACC でどのように機能するかについては、以下を参照してください。 KB1002549 Agent Client Collector とクローンKB0786475 MID サーバーとクローン Q&A エージェントが接続できない場合はどうなりますか？ エージェントは、MID サーバーに再度接続できるようになるまで情報をキューに入れます。 エージェントが MID にデータを送信しても、MID サーバーがインスタンスに接続できない場合はどうなりますか？ ecc_queue に書き込むチェックの場合、MID サーバーは同じメカニズムを使用してインスタンスにデータを送信し、かなりの回数まで再試行します。 Windows 用 Agent Client Collector ユーザーアカウントのパスワードは何ですか？ Windows 用 ACC をインストールする場合、既存のアカウントを選択するか、インストールによってアカウントを作成することができます。インストールで作成されるローカルアカウントは「servicenow」になります。このアカウントのパスワードは動的に生成されます。サービスの開始や停止は Windows サービス経由で行えるため、このパスワードは不要です。パスワードを更新する必要がある場合は、Windows ユーザー構成で実行でき、その後サービスを停止および更新して、一致するパスワードを設定できます。 [トップに戻る]