Agent Client Collector installation
Summarize
Summary of Agent Client Collector installation
The Agent Client Collector (ACC) can be installed on any supported host machine to enable data collection in your ServiceNow environment. It connects securely to a MID Server over HTTP/S, maintaining an active connection for efficient communication. Each MID Server can manage multiple agents concurrently, while each agent connects to only one MID Server at a time and can switch for failover support.
Show less
Key Features
- Scalability: The number of agents per MID Server is configurable (default 4,000 agents). Memory allocation impacts capacity—for example, a 1 GiB MID Server supports about 700 agents, while an 8 GiB MID Server can support up to 8,000 agents. Scaling out with multiple MID Servers is supported to handle tens of thousands of agents.
- Installation Details: ACC installs Ruby version 3.3.2 and runs under a local user account named servicenow with basic permissions.
- Permissions: Different OS-specific permissions are required for features such as inventory collection, process debugging, TCP connection mapping, storage device access, user session info, and package upgrades. These permissions ensure secure and effective agent operation across Windows, Linux, and macOS platforms.
- Agent Management: When reinstalling an agent in ITOM Cloud Services, the existing agent record must be deleted to allow re-registration. Agents marked as “Down” or “Disconnected” are automatically deleted after 30 days, with this period configurable via the Autoflush form.
- Security: Manual Transport Layer Security (mTLS) is used to secure authentication between the MID Web Server and agents, enhancing communication security.
- Air-Gapped Support: ACC supports deployment in air-gapped environments with specific configuration guidance available.
- Golden Image Mode: Enables cloning of agent instances for rapid deployment, with OS-specific prerequisites and modular plugin architecture.
- Domain Separation: ACC supports domain separation where the domain context is derived from the connected MID Server. User domains must be leaf domains to enable WebSocket endpoint extensions.
Practical Considerations
- Configure the
snagent.mid.maxallowedagentsproperty to match your environment’s scale needs. - Ensure appropriate OS-level permissions are granted for agents to function fully according to your deployment scenario.
- Use the Agent Client Collectors page to manage agent lifecycle, including deletion and monitoring connectivity status.
- Implement mTLS for secure agent-to-MID Server communication to safeguard data integrity and confidentiality.
- Leverage golden image mode for efficient scaling and deployment of multiple agent instances.
- Refer to platform-specific installation guides for Windows, Linux, and macOS to ensure correct setup.
You can install the Agent Client Collector on any supported host machine. The Agent Client Collector connects to a MID Server using the HTTP/S protocol, and the connection remains active after being established. One MID Server may handle several agents simultaneously, while a single agent works with one MID Server at a time and switches to a different MID Server when necessary to provide failover protection.
When an agent's IP address changes, it selects a MID Server to connect to based on the agent's MID Server list.
The maximum number of agents that can be connected to a single MID Server is configurable in the sn_agent.mid.max_allowed_agents MID Server property. The default value is 4,000.
For ACC-VC, a default 1 GiB MID Server can support 700 agents concurrently. An 8 GiB configuration for a MID Server can support 8,000 agents concurrently. You can also scale out. For example, 5 MID Servers with 8 GiB of heap size can handle up to 40k agents.
Agent Client Collector is installed with ruby version 3.3.2.
The default user account is a local user called servicenow. This user has basic level permissions.
| Feature | Windows | Linux | macOS |
|---|---|---|---|
| Basic inventory | * | * | * |
| Serial number(s) | * |
sudo dmidecode |
* |
| Running processes | Debug programs | * | * |
| Mapping TCP connections to running processes | * | sudo ss | * |
| Storage devices | LOCAL SYSTEM | * | * |
| Logged-in users | LOCAL SYSTEM | * | * |
| Package self-upgrade | LOCAL SYSTEM | sudo rpm/dpkg | Not supported |
If you completely reinstall the agent on a single host server, and you're using ITOM Cloud Services, you must delete the agent record to allow for re-registration. Delete the original agent on the Agent Client Collectors page ().
Agents whose Status = Down or Disconnected which haven't been deleted are deleted automatically after 30 days. You can modify this setting on the Autoflush form page (see Autoflush form).
Use the Manual Transport Layer Security protocol (mTLS) for secure authentication between your MID Web Server and the agent (the client). For details, see Connect the agent to the MID Server using mTLS.
For details on using Agent Client Collector in an air-gapped environment, see the Agent Client Collector Framework Air Gapped Configuration Item Management Solution [KB1585753] article in the Now Support Knowledge Base.
Golden image mode enables cloning of additional instances. Setting golden image mode is described in the installation procedure prerequisites for each OS. For information on the structure and modularity of the golden image plugin by operating system, see Golden image structure and modularity.
Agent Client Collector supports domain separation. The domain of the agent and the CIs it creates is determined by the domain of the MID Server that the agent is connected to. The user's domain must be the lowest domain level (known as a leaf domain) to enable creating a Websocket endpoint extension for the MID Server.