Resource and Instance Properties

Overview

Resource and instance properties are sets of key-value pairs that store data for resources (i.e. devices, application hosts, cloud accounts, etc.) and the instances being monitored on those resources.

Properties serve many purposes across LogicMonitor’s operations, including:

• Determining which LogicModules apply to which resources. As discussed in How DataSources Get Applied to Resources, DataSources, PropertySources, EventSources, and other types of LogicModules typically query property values to determine which resources they should execute against.
• Storing authentication credentials. Some systems require that LogicMonitor provide credentials (e.g. JDBC passwords, SNMP community strings, etc.) in order to access and collect data. As discussed in Defining Authentication Credentials, these credentials are stored as properties.
• Dynamically grouping resources and instances. As discussed in Device Groups Overview and Instance Groups respectively, property values are used to dynamically organize resources and instances into groups.
• Manipulating the values of complex datapoints. As discussed in Complex Datapoints, property values can be used in the calculations of complex datapoints.
• Acting as tokens for customizing alert display and messaging. As discussed in Managing Alerts from the Alerts Page and Tokens Available in LogicModule Alert Messages respectively, properties can be used as tokens in the alert table and in alert messages, allowing their values to dynamically render at the time of alert generation.

Note: This article focuses on properties set on resources and their monitored instances; however, monitored websites can also have properties, as discussed in Website Properties.

Automatically Assigned Properties

The majority of properties assigned to a device or instance are automatically assigned by LogicMonitor (as compared to manually assigned by you). There are three primary mechanisms by which LogicMonitor auto-assigns properties to resources or instances:

• Basic system information discovery
• PropertySource execution
• Active Discovery

Basic System Information Discovery

When a resource is added into monitoring, LogicMonitor immediately runs a series of basic queries to determine basic system information about the resource such as operating system version, IP address, sysOID, supported SNMP version, system category, and so on. This basic information is stored as properties that are associated with the resource.

▲ The names of properties that result from basic system information discovery are typically prepended with “system.” and, with exception of the system.categories property, are not available for editing.

There are four queries that run on a resource as part of LogicMonitor’s basic system information discovery process:

• SNMP query. This query detects the resource’s sysinfo, IP addresses, sysOID, sysname, and SNMP version. If all SNMP versions are supported by the resource, LogicMonitor will assign version 3; all subsequent SNMP queries will use the version assigned.

  Note: As discussed in SNMP sysOID Maps, the returned sysOID is looked up in LogicMonitor’s SNMP sysOID Maps and corresponding values are assigned to the system.categories property.

• WMI query. This query uses WMI. If the resource responds, the resource’s Windows operating system version, IP addresses, domain, model, and other resource-specific information is captured as properties.
• ESX query. This query detects if the resource is a VMware ESX Server. If it is, the resource’s system.virtualization property will be assigned a corresponding value, among other resource-specific property assignments such as model, vendor, memory, version, etc.
• XenServer query. This query detects if the resource is a Cisco XenServer. If it is, the the resource’s system.virtualization property will be assigned a corresponding value, among other resource-specific property assignments.

All of these queries run at the same time. If values for the same property are returned by more than one query, priority conflict determinators come into play. For example, if both the WMI and SNMP query return sysinfo, the system.sysinfo property will reflect the WMI response, not the SNMP response.

Some LogicMonitor configurations also get assigned to a resource as basic system properties. Examples include LogicMonitor Collector configurations (e.g. Collector version as stored by system.collectorversion) and groups that the resource is a member of (as stored by system.groups).

Note: In addition to running when a new resource is placed into monitoring, basic system information discovery also runs (1) once every 24 hours to rediscover properties for resources that have previously responded to any of the above query types, (2) whenever properties are updated on a resource, and (3) upon manual initiation of Active Discovery for the resource.

PropertySource Execution

Once basic system information has been determined and assigned to a resource, it’s likely that one or more PropertySources will assign further properties (or additional values to existing properties) to the resource. PropertySources are LogicModules that auto-assign and/or update properties at the resource level based on the output of a Groovy or PowerShell script.

▲ The names of new properties that are created and assigned by PropertySources are typically prepended with “auto.” and are not available for editing.

PropertySources use previously-assigned properties to determine which resources they should run against. Specifically, the Applies To field found in PropertySource definition is evaluated. The expression in this field designates which properties the PropertySource should evaluate; if the expression in this field evaluates to TRUE, then the PropertySource is applied to the resource. For detailed information on using this field (including its wizard and test functionality), along with an overview of the AppliesTo scripting syntax, see AppliesTo Scripting Overview.

▲ This PropertySource queries any resource that was previously identified as Windows to identify whether it is running Microsoft Exchange. If Microsoft Exchange is discovered, a new value is assigned to the resource’s system.categories property that identifies the Exchange version. This new value will then signal LogicMonitor’s various pre-built Microsoft Exchange DataSources that there are instances they should monitor on this resource.

There can be up to a 24-hour delay before PropertySources are automatically matched to a newly-added or -updated resource. However, as discussed in Creating PropertySources, there are ways to manually initiate PropertySource association.

Active Discovery

Properties can be automatically assigned to instances as part of the Active Discovery process, which programmatically collects instance-specific metadata. For more information on this process and the instance information it gathers, see Active Discovery.

Note: As with resource properties automatically assigned by PropertySources, instance properties automatically assigned by Active Discovery are prepended with “auto.” and not available for editing.

Manually Assigned Properties

Resource and instance properties can also be manually created when the need arises. A common use case for manually assigning properties to resources is the storage of authentication credentials for systems that require LogicMonitor to provide credentials (e.g. JDBC passwords, SNMP community strings, etc.) in order to access and collect data. For more information on storing credentials as properties, see Defining Authentication Credentials.

Note: Instructions for manually assigning properties are provided in the Manually Assigning or Editing Properties section of this support article.

Understanding Property Hierarchy

Whether properties are assigned automatically or manually, all follow the same hierarchical rules. Properties cascade from the root account level all the way down to instances. This means that when you view the properties for an instance, you are also viewing the properties that have been previously set and passed down for that instance’s parent resource or resource groups, as well as for the global LogicMonitor account. Properties set at the deepest level in the Resources tree trump properties set higher up (e.g. properties set at the resource level will override properties set at the group level; properties set at the group level override properties set at the global (account) level).

Note: A resource that is a member of multiple groups with the same property defined uses the properties set at the deepest level group. If the same property is set in two groups at the same level, and a resource is a member of both of these groups, the selection of which property the resource will inherit is nondeterministic.

Viewing Properties

Properties assigned to an entity (e.g. resource, instance, group, etc.) are available for viewing from the Info tab that is found on the Resources page. Custom properties (i.e. properties that have been manually assigned display first, followed by the properties that LogicMonitor has automatically applied.

▲ Properties that are inherited or assigned by PropertySources are expandable, allowing you to see details on the assigning parent(s) or PropertySource. For example, the highlighted snmp.community property shown here was inherited from the root account, but overridden by the resource’s parent “Discovery” group. The highlighted auto.contact property is assigned by the “SNMP Basic Information” PropertySource.

Manually Assigning or Editing Properties

Before you set properties for your resources, you should understand where to set them, which depends on how many resources that property applies to. For example, if you have the same SNMP community string set for all of your Linux resources, it doesn’t make sense to go and set that as a property individually for each Linux resource in your account. It is likely more efficient to instead set this community string at the global account level so that it applies to all Linux resources (and instances). See the previous Understanding Property Hierarchy section of this support article for more information on how properties cascade down the Resources tree.

You cannot directly assign or edit the values of properties that are automatically created by LogicMonitor (that is properties whose names are appended with either “system.” or “auto.”). However, there are two exceptions to this rule:

• The system.categories can be manually edited. For example, you could add a value to the system.categories property to indicate that a Collector is installed on the resource.
• The !hostproperty debug command (available from the Collector Debug Facility) can be used to add, update, or delete any system property for a resource. For more information on the Collector Debug Facility, see Using the Collector Debug Facility.

Note: Properties added to system.categories can only be removed manually or via the REST API.

To manually assign or edit properties:

1. Navigate to the Resources page.
2. In the Resources tree, navigate to the entry-level (e.g. root account node, group, resource, instance) at which you want the property to initially apply (and begin its cascade downward). See the previous Understanding Property Hierarchy section of this support article for more information on how properties cascade down the Resources tree.
3. Open the Info tab. Here, you’ll see a table of all assigned properties.
4. Click the gear icon located immediately above the table.
5. From the Manage dialog that displays, scroll down to the Properties section.
   • Note: When editing properties, you’ll only see properties that have either been manually assigned at this level (that is the property does not exist at a higher level in the Resources tree) or previously updated at this level to override the value inherited from a higher level.
6. You can edit any of the property values displayed by clicking into the Value field. Or, if your goal is to:
   • Create a brand new property, click the + icon, enter a property name and value, and click Save.
   • Override (or add to) the value of an existing property that is inherited from a parent resource, group, or from the LogicMonitor account, enter that property’s name along with the new value, and click Save. (Remember, only manually assigned properties (with the exception of the system.categories property) can be edited.)
7. Click Save again to exit out of the Manage dialog. The value you set is inherited downward in the hierarchy until it is overridden at a deeper level. For example, if you apply a location property at the global level, LogicMonitor will attempt to use that location for all resources except those with the location property defined at the resource or parent group.

Note: While adding the property to the device via UI, the character limit is 24,000, and you can view property information up to 24,000.
In LogicModules, when you add a property using the script, the character limit for the complete script is 65535 and the property value that is added using this script has a limit of 4000 characters.