--- sourceDocument: Australia IT Operations Management sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-operations-management Release : - australia ft:locale : - en-US ft:publication_title : - Australia IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # ACC architecture # Agent Client Collector architecture {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Agent Client Collector architecture The Agent Client Collector is a ServiceNow agent installed on Windows, Linux, and macOS devices to monitor your company's infrastructure and applications. Built on the Sensu framework, it supports monitoring servers, databases, application servers, and middleware. You can extend its capabilities with additional checks from the Sensu community or Nagios-compatible plugins to tailor monitoring to your environment. Show full answer Show less ## Monitoring with Checks and Policies Monitoring is performed through checks, which are commands that run on hosts to collect data, transforming it into events or metrics. Checks are defined within the ServiceNow instance and grouped into monitoring policies---a policy links specific Configuration Items (CIs) with the checks to run on them. You can customize individual check instances within policies, such as adjusting frequency or parameters like database credentials, without altering the global check definitions. This flexibility allows targeted monitoring across various systems and scenarios. ## Data Collection and Transmission Once installed, the agent collects information on its host and running processes, then sends this data to the ServiceNow instance via the MID Server. The MID Server acts as a secure bridge, transforming and transmitting data. Within the ServiceNow instance, CIs are created for hosts and applications identified from processes. Active monitoring policies tied to these CIs are downloaded to the MID Server, which pushes them to the agent for execution. ## Data Storage and Utilization Check results are stored in the ServiceNow instance's CMDB (for CI data) and events tables (for event data such as alerts). This integration provides real-time visibility into infrastructure and application health, enabling proactive issue detection, alerting, and reporting. ## Practical Workflow for ServiceNow Customers * Define monitoring policies in the ServiceNow instance by associating CIs with checks. * The MID Server fetches check instances from the instance and delivers them to the agent. * The agent executes the checks, collects data, and sends results back through the MID Server. * The MID Server forwards data to ServiceNow, where it is stored and utilized for monitoring and alerting. By understanding this architecture, ServiceNow customers can effectively deploy and customize Agent Client Collector monitoring tailored to their infrastructure, ensuring comprehensive visibility and control over their IT environment. The Agent Client Collector is a ServiceNow agent installed on your Windows, Linux, and macOS devices to monitor your company's infrastructure and installed applications. ## Agent Client Collector architecture - overview {#acc-concept__section_o1n_hkm_5dc} The Agent Client Collector is built on a Sensu framework and comes installed with monitoring capabilities for servers, databases, application servers, and middleware. It also supports extending monitoring through additional checks from the Sensu community or Nagios-compatible plugins, allowing you to customize monitoring to your needs. ## Monitoring with checks and policies {#acc-concept__section_qhx_mlm_5dc} The agent runs checks on the host to gather relevant data, transforming it into events or metrics. These checks are defined within ServiceNow and are associated with monitoring policies. A policy is a combination of the Configuration Items (CIs) being monitored and the checks that run on those CIs. The checks are associated with policies to monitor different aspects of the system. You can customize check instances - such as adjusting the frequency or specifying parameters like login credentials for databases - without affecting the original check definition. Customization of a check instance takes effect only on the check instance associated with the policy and does not change the global check definition. This customization ensures flexibility in monitoring various CIs under different scenarios. ## Data collection and transmission {#acc-concept__section_dzd_q4m_5dc} After installation, the agent collects information on its host and processes. The agent pushes the collected data to the ServiceNow instance through the MID Server. The MID Server serves as a bridge between the agent and the ServiceNow instance, ensuring the data is transformed and securely sent for processing. On the instance, CIs are created for the host and applications classified from the running processes (such as Microsoft SQL Server). After these CIs are created, the active monitoring policies associated with the CIs are downloaded to the agent's MID Server. The MID Server then pushes the policies to the agent for execution. ## Data storage and use {#acc-concept__section_wz5_npm_5dc} The results from the checks are stored in the ServiceNow instance: * CI data: CMDB for Configuration Items. * Event data: Events table (for example, alerts triggered by threshold breaches). {#acc-concept__ul_t2v_l5r_5dc} This data can be leveraged for monitoring, alerting, and reporting. Integration ensures real-time visibility into the health of your infrastructure and applications, while also enabling proactive issue detection and remediation.
1. Define a monitoring policy in the ServiceNow instance. 2. The MID Server fetches the check instances from the instance and passes them to the agent. 3. The agent runs the checks, collects data, and sends the results back to the MID Server. 4. The MID Server sends the collected data to the ServiceNow instance, where it is stored in the CMDB or events tables. {#acc-concept__ol_hrr_p2s_5dc} The commands and their configurations that run on the Agent are called checks. The Agent comes by default with check definitions, which determine a specific command and the default frequency with which it runs. Checks are defined on the instance and are passed to the Agent via the MID Server. A policy is a combination of the CIs being monitored by the Agent Client Collector and the checks that run on those CIs. You associate check definitions with policies. Those check definitions are then referred to as check instances. You can customize check instances to meet your needs. For example, customize the running interval or the parameters specific to the policy, such as the login credentials to access a MySQL database. Customization of a check instance takes effect only on the check instance associated with the policy. It does not affect the original check definition or check instances already created in other policies.