Config Checks

A config check monitors the availability of a config file for specific contents of the file and triggers an alert when defined criteria are met.

There are five types of config checks and the options available for each type vary depending on the file format selected in the ConfigSource editor. Choosing the file format most appropriate to the config file you are monitoring can make the process of defining config checks less prone to error.

File Formats

The following file formats are available for config checks:

Format	Description	Implicit Checks
Arbitrary text	You can use any text as the format. The format make assumptions about the text and arbitrary text assumes nothing. Use this if you’re unsure of which format to use.	There are no implicit checks. Fields and values must be specified using regular expressions.
Unix	Lines are separated by the line feeder character (\n). Lines starting with a pound sign “#” are treated as comments.	For “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-properties	Also referred to as “.properties”. Lines starting with a pound sign “#” or an exclamation point “!” are treated as comments. Text proceeding an equal sign “=” is treated as a key (field), and text following an equal sign “+” is treated as a value.	For “Any Change” config check, the following implicit rules are applied by default: – Changes to comments are ignored – Extra blank lines and spaces are ignored – Field (keys) and values are automatically recognized – The order of properties is ignored

Config Check Types

The following config check types provide a specific method to monitor the config file:

Check Type	Description	Options
Config cannot be retrieved	Generates an alert if the collection script fails. An alert remains active until the collection script completes successfully. Any ConfigSource you create benefits from having a “Config cannot be retrieved” check, unless you expect the ConfigSource to occasionally fail. This config check generates 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 Alerting on Datapoints.	You can select the severity of the alert generated.
Any change (diff check)	Generates an alert if any change is detected in the content of the config file. If the alert clear options are disabled, an alert clears when the collected config file is identical to the current version. This config check generates a warning alert if any changes are detected in the config, along with default ignore filters for the Unix file format. You can clear the alert when it is acknowledged.	You can add filters to ignore changes, like timestamps or the addition or removal of blank lines. If the file format is Unix or java-properties, some filters are included by default, and you can remove them if needed. You can configure the alert to clear on acknowledgement or after a set period. In addition, you can select the severity of the alert generated.
Missing field	Generates an alert if a specified field is not present in the config file. 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 questions. 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 clears when the specified field is found in the config file. This config check generates an alert if the field “max_memory_mib” is not present in the config file.	You can select the severity of the alert generated.
Value	Generates an alert if the value of the field does not meet the specified criteria. If the file format is set to arbitrary text or Unix, this check searches the file contents for the specified string. You 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 (field) values in the file. If neither of the alerts clear when acknowledged or clear after a set period is enabled, an alert clears when the value meets the specified criteria. This config check generates an alert if the field “max_memory_mib” is not equal to “2048”.	You can 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 on acknowledgement or after a set period. In addition, you can select the severity of the alert generated.
Groovy script	Generates an alert if the Groovy script returns “1”. The config check receives the contents of the config file through the built-in text variable “config” that provides standard Groovy string methods, such as contains, matches, and size. The Groovy script config checks require Collector version 25.200 or later. All the logic for determining if an alert must be generated is contained in the script. The check looks at the value returned by the script: “1” triggers an alert, “0” does not. An alert clears when the script returns to “0”. This config check uses a Groovy script to retrieve the value of the system.hostname resource property, then checks to see if this value is present in the config file. If the value is not present, LogicMonitor generates an alert.	You can select the severity of the alert generated.

Adding Config Checks to a ConfigSource

1. In the LogicMonitor navigation menu, select Modules.
2. Open the ConfigSource editor. For more information, see Configuring a ConfigSource.
3. On the Config Check tab, select a file format from the File Format dropdown.
   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.
4. Select + Add Checks to open the Add Checks pane and do the following:
   1. In the Name field, enter a name for the checks.
      The name defaults to “configCheck0”.
   2. In the Check Type dropdown, select the specific method to monitor the config file. For more information, see Config Check Types.
   3. In the Alert trigger interval (consecutive polls) dropdown, select whether to trigger the alert immediately (default) or select a specific number of days for the alert interval.
      Items that change frequently or require immediate attention in the event of an error (for example, supervisor/management CPU is overloaded), should have a short poll cycle, like one hour. Longer poll cycles impose less load on both the server being monitored and the collector.
   4. In the Then trigger this severity of alert dropdown, select the severity level to trigger an alert at.
   5. (Optional) Enter a description for the config check.
5. Select Save to save the check and close the Add Checks pane.
6. In the bottom right corner of the editor, select Save.
7. (Optional) Select Commit Version to save a version of this module to roll back to at a later date, and then do the following:
   1. (Optional) In the Commit a Version window, enter any version notes.
   2. (Optional) Toggle on Make this version Public to make this module available to all LogicMonitor users in LM Exchange.
   3. Select Commit Version.