---
sourceDocument: Australia IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/it-operations-management

 Release :

    - australia

ft:locale :

    - de-DE

ft:publication_title :

    - Australia IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Checks and policies

# Checks and policies {#ariaid-title1}

* Freigeben Version: Australia
* 
* Aktualisiert 12. März 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 Minuten Lesedauer

A check is a combination of a command and its configuration. The check is executed on the Agent Client Collector's devices to gather data from those devices.

## Checks {#checks-policies__section_j2b_5hb_rwb}

Checks are provided with the base system, and their commands execute scripts which provide monitoring data for your operating systems and applications. A check's default name indicates what is being monitored and measured, the
entity, and the monitoring data. For example, a check named os.linux.check-system-cpu checks the CPU data on a Linux system. The identified command in the check runs on the monitored device, providing an output and status. Each individual check is referred to as a check definition. After being
associated with policies, 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, which does not affect the original check definition or already created check instances in other policies.

The following check types are provided with the Event Management base system:

* Event: The check's result is transformed into an Event Management event.
* Metric: The values from the check result are transformed to metrics.

{#checks-policies__ul_omn_1rr_rjb}

For details on the Agent Client Collector Framework default checks, see [Agent Client Collector Framework default checks](https://servicenow-prod.fluidtopics.net/04iiIynvX19D9l4eDIYVvw "Agent Client Collector Framework provides default checks with the base system.").

For details on the Agent Client Collector Monitoring default checks and policies, see [Agent Client Collector Monitoring default checks and policies](https://servicenow-prod.fluidtopics.net/yxq6BLkNizyPNK77nLyCEw "Agent Client Collector Monitoring provides various default checks and policies.").

For details on the Agent Client Collector for Visibility - Content default checks and policies, see [Agent Client Collector for Visibility - Content default checks and policies](https://servicenow-prod.fluidtopics.net/9NCiijMfDzQVWY7UqwYpeA "Agent Client Collector for Visibility - Content (ACC-VC) provides various checks and policies as well as a business rule.").

If checks are not running on the agent's devices, your agent may be in CPU protection mode. CPU protection mode is activated when a device's CPU consumption is too high. To view a list of all disabled checks related to the
agent, navigate to the agent record on the Agent Client Collectors page (AllAgent Client CollectorAgents), select an agent and select the Disabled Checks tab at the bottom of the page.

If checks are not running on the agent's devices, your agent may be in CPU protection mode. CPU protection mode is activated automatically when a device's CPU consumption is too high. When this
happens, the agent's Data Collection status is Off (auto). Check the agent logs to determine the problematic checks. You can manually disable problematic checks, or you can modify the CPU protection mode
thresholds in the agent's acc.yml file and manually resume data collection for the agent. For details on the CPU protection mode thresholds, see [Agent Client Collector CPU protection thresholds](https://servicenow-prod.fluidtopics.net/m27EUboHfZGDR5ppMcD~Wg "When an agent meets the configured thresholds specified in the agent's acc.yml file, it enters CPU protection mode, either for an individual check or for all checks. Agents in CPU protection mode appear in the agent logs with the syntax Agent Protection."). For details on manually turning off data collection, see [Pause Agent Client Collector data collection](https://servicenow-prod.fluidtopics.net/Q5crZ3n~P~QbaAIt3F_T9Q "If CPU consumption on your server is getting too high, you can manually turn off the Agent Client Collector data collection to pause all checks performed by the agent, except for the agent's keep alive messages.").

In the acc.yml configuration file, you can modify the CPU protection mode thresholds which determine when a check is disabled. To re-enable a check, select the check and select
Re-enable disabled check in the Actions on selected rows... drop-down. For details on the CPU protection mode thresholds, see [Agent Client Collector CPU protection thresholds](https://servicenow-prod.fluidtopics.net/m27EUboHfZGDR5ppMcD~Wg "When an agent meets the configured thresholds specified in the agent's acc.yml file, it enters CPU protection mode, either for an individual check or for all checks. Agents in CPU protection mode appear in the agent logs with the syntax Agent Protection."). For details on manually turning off data collection, see [Pause Agent Client Collector data collection](https://servicenow-prod.fluidtopics.net/Q5crZ3n~P~QbaAIt3F_T9Q "If CPU consumption on your server is getting too high, you can manually turn off the Agent Client Collector data collection to pause all checks performed by the agent, except for the agent's keep alive messages.").

Configure the cpu_protection_behavior property to determine whether all checks enter CPU protection mode, or only the check that crosses the configured cpu_percentage_limit value with the highest CPU
usage within the monitoring interval. For details, see [Agent Client Collector CPU protection thresholds](https://servicenow-prod.fluidtopics.net/m27EUboHfZGDR5ppMcD~Wg "When an agent meets the configured thresholds specified in the agent's acc.yml file, it enters CPU protection mode, either for an individual check or for all checks. Agents in CPU protection mode appear in the agent logs with the syntax Agent Protection.").

A check is marked as Stale if it is no longer associated with a policy. To remove a stale check, renable it by selecting the box next to the check and selecting
Re-enable disabled checks from the Actions on selected rows... cell.  
In the base system, the event's exit status indicates its severity, as follows:

* 0 = OK
* 1 = WARNING
* 2 = CRITICAL
{#checks-policies__ul_dfd_pwr_1pb}  
You can add additional severities (such as MAJOR and MINOR) by running a customized script. The following exit statues indicate these severities:

* 13 = MAJOR
* 14 = MINOR
{#checks-policies__ul_r55_1mb_35b}

## Privileges for running check commands {#checks-policies__section_qqz_4d1_vdc}

If the servicenow base system user does not have privileges to run specific check commands, do the following for the relevant operating systems:

* In a Linux system: Enable the servicenow user to run the command with `sudo` permissions. Ensure that the following sudo configuration requirements are met:
  * Disable tty and password requirements
  * Preserve all environment variables
  * Support dynamic PATH for executing commands

  {#checks-policies__ul_yzj_f2g_n4b}  
  Example configuration in the /etc/sudoers file:

      Cmnd_Alias ACC_F = /usr/sbin/dmidecode -s baseboard-serial-number, /usr/sbin/dmidecode -s chassis-serial-number, /usr/sbin/dmidecode -s system-serial-number, /usr/sbin/dmidecode -s system-uuid, /usr/sbin/ss -tanp 
      servicenow ALL=(root) SETENV: /var/cache/servicenow/agent-client-collector/osquery/bin/osqueryi *, ACC_F
      Defaults:servicenow !requiretty
      Defaults exempt_group += servicenow

  Hinweis:  
  Command paths may vary. Consult the sudoers manual for special considerations.
  * The `SETENV:` string enables the servicenow user to preserve environment variables.
  * The `!requiretty` string disables tty.
  * Adding the servicenow user to the `exempt_group` bypasses password requirements and enables dynamic PATH for executing sudo commands.

  {#checks-policies__ul_br4_4fg_n4b}

  Ensure that you configure the must_sudo check parameter with a value of true in the check command parameters section of the check definition.
* In a macOS system: Ensure that the user running the agent service belongs to a user group with privileges to query all tcp connections on the host.
* In a Windows system: Using Windows User Management, add the servicenow user to the groups with the relevant privileges, enabling the user to execute the required commands.
{#checks-policies__ul_ynm_ysy_4mb}

## Policies {#checks-policies__section_ftj_c3b_rwb}

A policy is a combination of the CIs being monitored by the Agent Client Collector and the check definitions that run on those CIs.

To enable a single policy to support multiple credentials, assign a credential alias to the policy. For example, if you have MySQL servers for both Linux and Windows with different credentials, you must create separate policies for each credential type. However, if you use a credential alias, you can assign a single policy to the alias. The agent then matches the
relevant credential to the application being monitored. For details on credential aliases, see [Create a Connection and Credential alias](https://www.servicenow.com/docs/access?context=connection-alias&version=australia&pubname=australia-platform-security&ft:locale=en-US).  
Alerts generated by policies with an event-type check are automatically closed when the CI monitoring stops due to any of the following:

* De-activating the policy
* De-activating the check that caused the alert
* Deleting the check from the policy
* Deleting the policy
* Modifying the policy filter that determines the monitored CIs
{#checks-policies__ul_sc2_zds_j4b}