Config Checks

Last updated on 07 December, 2022

Overview

ConfigSources generate alerts based on config checks. Much like a datapoint and threshold in a DataSource, a config check monitors the availability of a config file or specific contents of the file and triggers an alert when defined criteria are met. There are five types of config checks, each providing a specific method to monitor the config file.
The options available for each type of config check vary depending on the file format selected in the ConfigSource definition. Choosing the file format most appropriate to the config file you are monitoring can make the process of defining config checks easier and less prone to error.

Note: If the ability to monitor and alert on configuration files is not currently available in your LogicMonitor platform and you would like to learn more, reach out to your customer success manager.

File Formats

Three file formats are available: arbitrary text, java-properties, and Unix. Using the java-properties or Unix file format provides some implicit checks that may make it easier to set up your ConfigSource. The default file format is arbitrary text.

Note: The file format must be selected when the ConfigSource is created. In addition, the file format cannot be modified once the ConfigSource has been saved.

File Format Descriptions

Unix: Lines are separated by the line feed character (\n), as opposed to the DOS format which uses a combination of carriage return and line feed characters (\r\n) to separate lines. Lines starting with “#” are treated as comments.

java-properties: Also referred to as “.properties”. Lines starting with “#” or “!” are treated as comments. Text preceding “=” is treated as a key (field), text following “=” is treated as a value.
Following is a sample of text in java-properties format:

# You are reading the ".properties" entry.
! The exclamation mark can also mark text as comments.
website = https://en.wikipedia.org/
language = English
# The backslash below tells the application to continue reading
# the value onto the next line.
message = Welcome to \
          Wikipedia!
# Add spaces to the key
key\ with\ spaces = This is the value that could be looked up with the key "key with spaces".
# Unicode
tab : \u0009
Java-properties format example

Implicit Checks by File Format

Format Description
arbitraryThe default format. There are no implicit checks. Fields and values must be specified using regular expressions.
unixAny line starting with “#” is treated as a comment line. For an “Any Change” config check, the following implicit rules are applied by default:

  • Changes to comments are ignored
  • Extra blank lines and spaces are ignored
  • Fields and values must be specified using regular expressions

java-propertiesAny line starting with “#” or “!” is treated as a comment line. For an “Any Change” config check, the following implicit rules are applied by default:

  • Changes to comments are ignored
  • Extra blank lines and spaces are ignored
  • Fields (keys) and values are automatically recognized
  • The order of properties is ignored

Config Check Types

There are five types of config checks, each providing a specific method to monitor the config file.

Check Type: Config cannot be retrieved

Description: Generates an alert if the collection script fails to complete successfully.

Options: You can select the severity of the alert generated.

Comments: An alert will remain active until the collection script completes successfully.

Example

This config check will generate a warning alert if the config file cannot be retrieved. You can also add an alert trigger interval to control when the alert is triggered. For more information, see Alert Trigger Interval.

Check Type: Any Change (diff check)

Description: Generates an alert if any change is detected in the content of the config file.

Options: You can add filters to ignore changes like timestamps or the addition or removal of blank lines. However, if the file format is Unix or java-properties, some filters will be included by default, and you can remove them if needed.
You can configure the alert to clear upon acknowledgment after a set period has passed, or either (whichever event occurs first). In addition, you can select the severity of the alert generated.

Comments: If neither of the alert clear options is enabled, an alert will clear when the collected config file is identical to the current version.

Example

This config check will generate a warning alert if any changes are detected in the config, along with default ignore filters for the Unix file format.
The option to clear the alert when it is acknowledged has been enabled.

Check Type: Missing Field

Description: Generates an alert if a specified field is not present in the config file.

Options: You can select the severity of the alert generated.

Comments: If the file format is set to arbitrary or Unix, this check searches the file contents for the specified string. A regular expression may be necessary to unambiguously identify the field in question.
If the file format is java-properties, the check compares the specified string with the list of field (key) names in the file.
An alert will clear when the specified field is found in the config file.

Example

This config check will generate a warning alert if the text “Ubuntu17-9ab76122-” is not present in the config file.

Check Type: Value

Description: Generates an alert if the value of a field does not meet the specified criteria.

Options: You may select a comparison operator for the value or an alert if the value changes from one version of the config file to the later version.
If the alert is generated by a change in the value, you can configure the alert to clear upon acknowledgment after a set period has passed, or either (whichever event occurs first).
You can select the severity of the alert generated.

Comments: If the file format is set to arbitrary or Unix, this check searches the file contents for the specified string. You will need a regular expression with a capture group to extract the field value. If the file format is java-properties, the check compares the specified string with the list of key values in the file.
If neither of the alerts clear when acknowledged or clear after a set period is enabled, an alert will clear when the value meets the specified criteria.

Example

This config check will generate a critical alert if the value of the community string changes.
The use of a regular expression with the value of the community string is specified as a capture group.

Check Type: Groovy script

Description:

Generates an alert if the Groovy script returns 1. The config check receives the contents of the config file via the built-in text variable “config” that provides standard Groovy string methods such as contains, matches, and size. For more information, see Docs.groovy-lang.org.

Note: The Groovy script config checks require Collector version 25.200 or higher.

Options: You can select the severity of the alert generated.

Comments: All the logic for determining if an alert must be generated is contained in the script. The check itself merely looks at the value returned by the script: 1 triggers an alert, 0 does not. An alert will clear when the script returns 0.

Example

This config check uses a Groovy script to retrieve the value of the system.hostname device property and then checks to see if this value is present in the config file. If it is not, an error alert is generated.

In This Article