Checks and policies

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

Checks

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.

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.

For details on the Agent Client Collector Framework default checks, see Agent Client Collector Framework default checks.

For details on the Agent Client Collector for Monitoring default checks and policies, see Agent Client Collector for Monitoring default checks and policies.

For details on the Agent Client Collector for Visibility default checks and policies, see Agent Client Collector for Visibility default checks and policies.

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. For details on manually turning off data collection, see Pause Agent Client Collector data collection.

In the base system, the event's exit status indicates its severity, as follows:

• 0 = OK
• 1 = WARNING
• 2 = CRITICAL

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

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

• In a Linux system: Enable the servicenow user to run the command with sudo permissions. The following sudo configuration requirements must be met:
  • Disable tty and password requirements
  • Preserve all environment variables
  • Support dynamic PATH for executing commands
  For example, you can configure the following 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
  

  Note:

  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.

  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.

Policies

A policy is a set of CIs and the check definitions for those CIs.

To enable a single policy to support multiple credentials, you must 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 credential 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.

Alerts generated by policies with an event-type check are automatically closed when the CI monitoring stops via one 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