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!
Grouping your devices and cloud resources in LogicMonitor can make management significantly easier and save you time when configuring alert thresholds, dashboards, reports, alert routing, and device properties.
Device groups allow you to:
As discussed in Adding Device Groups, device groups are created by navigating to Resources | Add | Group | Device Group.
There isn’t one right way to group your devices and cloud resources, but there are a couple of common ways to approach grouping that make things more efficient. Keep in mind that it is usually not too difficult to change how your devices and cloud resources are grouped so there is room for fine tuning to ensure your device group structure is the best fit for your environment.
As discussed next, there are three common strategies for group organization:
Consider grouping devices and cloud resources together based on how critical they are to your operation. Critical infrastructure with slow performance metrics are likely to be of more interest to you and have different alert thresholds than QA devices with the same slow performance. Grouping devices of similar importance will enable you to set group alert thresholds across all items in the group, allowing you to differentiate between a critical CPU alert on production infrastructure and a critical CPU alert on test environment infrastructure without configuring individual thresholds for hundreds of items.
Additionally, grouping devices of similar importance will enable you to route alerts by group. For example, you could set up an alert rule matching error/critical alerts for your production infrastructure that routes notifications to members of your operations team 24/7 (e.g. text message or phone call in the middle of the night) and set up a different rule that matches test environment error/critical alerts and routes notifications to a ticketing system if it is past 7:00pm
Consider grouping devices and cloud resources based on the structure of your organization. How does your organization operate and divide responsibility? Having a device group structure that mirrors your organizational structure will make all other areas of account configuration (especially user roles and permissions) much simpler. Such a device group structure can help teams quickly find the devices relevant to their jobs and allows you to set up roles for each group, such that each team can only make changes to the devices for which they are responsible.
Grouping based on organizational structure may mean grouping by:
Additionally, this concept extends to subgroups (which are discussed in a later section of this article). If you have a NOC team, for example, that in charge of overseeing a large number of devices and then smaller functional teams responsible for subsets of those devices, your device group structure may look like this:
Consider grouping devices and cloud resources based on how they depend on one another to expedite troubleshooting and make it easier to schedule downtime for related devices. For example, does your organization have a regular maintenance window that results in a distinct set of devices becoming unavailable? Grouping those devices together would allow you to more clearly identify downtime due to maintenance and, more importantly, more clearly identify issues that arise in devices outside of maintenance. You could also group devices that comprise a single application. In general, grouping devices based on how they relate to one another will make it easier to see how a particular event impacts your infrastructure and enable you to more quickly identify its cause.
You can add as many subgroups as you need; all of the above strategies apply to subgroups as well. Two key things to keep in mind when introducing subgroups are:
Devices and cloud resources can be members of multiple device groups. If the same property is defined across these groups, then it’s important to note that properties set at the deepest level group take precedent. If the same property is set in two groups at the same level, and a device or cloud resource is a member of both of these groups, the selection of which property will take effect is nondeterministic.
There are two types of device groups: manual and dynamic.
Manual device groups have static membership. You must manually add devices or subgroups to, or remove them from, manual groups (although devices may be automatically added to such groups as a result of a network discovery scan). You can also use LogicMonitor’s API to add and remove devices from a manual group.
Dynamic groups have dynamic membership, meaning that devices or cloud resources are automatically added or removed from the group based on specific common characteristics. Because dynamic grouping typically better enforces organization with less effort than manual grouping, it’s recommended to use dynamic grouping whenever possible.
Note: Only administrators and those with admin-level manage permissions to resources (i.e. the All option is selected at the top of the table of resources) have the ability to manage dynamic groups. For more information on Roles and Permissions for dynamic groups, see Roles.
Dynamic groups are created by specifying AppliesTo criteria for the auto-assignment of devices to the group. For more information, see AppliesTo scripting language.
Devices cannot be manually added to dynamic groups, and are automatically removed when they no longer meet the auto-assignment criteria. For example, you could create a group for your San Francisco office, with the following custom query: location =~ "San Francisco". If a device is transferred from the San Francisco to Los Angeles office and the location property is updated, it will no longer appear in the San Francisco group.
location =~ "San Francisco"
Properties and thresholds can be managed for a dynamic group the same way they are managed for a manual device group, and will be inherited by group members.
Note: To avoid circular references, the criteria that determines which devices are auto-assigned to a dynamic group (i.e. the AppliesTo script) can only evaluate properties of the host itself, not any inherited properties from those groups of which it is a member. For similar reasons, the systems.group property is also excluded from use in a dynamic group’s AppliesTo script as the query itself could change the results of the query, potentially creating an endless loop. If you wish to create a dynamic group that is dependent on group membership, use the property system.staticgroups in your AppliesTo script: join(system.staticgroups,",") =~ "production".
join(system.staticgroups,",") =~ "production"
Next are several examples of when you may want to use dynamic groups:
system.sysinfo =~ ‘’
Some examples of dynamic group queries include:
system.sysinfo =~ "Linux"
system.hostname =~ "lax"
system.hostname =~ "nyc" && system.hostname =~ "prod"
In This Article