Resource and Instance Properties

Resource and instance properties are sets of key-value pairs that store data for resources and instances being monitored on those resources. Properties serve many purposes across LogicMonitor’s operations:

Purpose	Description
Determine which LogicModules apply to which resources	Modules (DataSources, PropertySources, EventSources) query property values to determine which resources they should execute against.For more information, see How DataSources Get Applied to Resources.
Store authentication credentials	Some systems require credentials (JDBC passwords, SNMP community strings) in order to access and collect data. These credentials are stored as properties.For more information, Defining Authentication Credentials.
Dynamic grouping of resources and instances	Property values are used to dynamically organize resources and instances into groups.For more information, see Device Groups Overview and Instance Groups.
Manipulate the values of complex datapoints	Property values can be used in the calculations of complex datapoints.For more information, see Complex Datapoints.
Act as tokens for customizing alert display and messaging	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.For more information, see Managing Alerts from the Alerts Page and Tokens Available in LogicModule Alert Messages

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. 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).

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. 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.

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 (for example, JDBC passwords and SNMP community strings) in order to access and collect data. For more information on storing credentials as properties, see  Defining Authentication Credentials.

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. For example, 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.

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 (properties whose names are appended with 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.

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 (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. Click 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.
   • 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.
   • To create a brand new property, click the  +  icon, enter a property name and value, and click  Save.
   • To 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. Only manually assigned properties, with the exception of the  system.categories  property, can be edited.
7. Click  Save to exit 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.