Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
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:
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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
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:
Note: Properties added to system.categories can only be removed manually or via the REST API.
To manually assign or edit properties:
In This Article