Device Groups Overview

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:

• Organize your devices and cloud resources within the Resources tree, improving navigation and load time.
• Manage device and cloud resource performance, alert thresholds, and properties at a group level.
• Easily create dashboard and report views of all items in a group.
• Customize user permissions based on groups or subgroups.

As discussed in Adding Device Groups, device groups are created by navigating to Resources | Add | Group | Device Group.

Common Grouping Strategies

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:

• Grouping according to criticality
• Grouping according to team/organization structure
• Grouping according to device relationships

Grouping According to Criticality

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

Grouping According to Team/Organization Structure

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:

• Function (for example a database group, networking group, servers group and so on)
• Location (for example a group for each office or data center location)
• Customer (for example you’re an MSP and have groups for each of your customers)
• Business application (for example grouping together all devices serving a particular website)

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:

• NOC
  • Database
  • Networking
  • Servers

Grouping According to Device Relationships

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.

Subgroups

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:

• When referencing device groups or subgroups throughout your account (e.g. in dashboards, reports, alert rules, user roles), you should add a wildcard to the end of the group name (e.g. ‘Production*’). A group name that is wildcarded will include devices in any of the group’s subgroups.
• Properties and thresholds set at the subgroup group level will override the values of those same properties and thresholds at the parent (or higher) group levels.

Including a Device in Multiple Groups

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.

Manual vs. Dynamic Device Groups

There are two types of device groups: manual and dynamic.

Manual Device Groups

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 Device Groups

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.

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.

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.

Next are several examples of when you may want to use dynamic groups:

• When a subset of devices use a custom port. For example, assume for a moment that all of your SQL servers whose names start with ‘ALT’ have a custom port configured for MySQL. In this scenario, you could create a dynamic group that includes all devices whose names start with ‘ALT.’ You could then clone the MySQL DataSource, edit it to use the custom port, and apply it to only that group. All existing and new MySQL servers added to the account that have a name that starts with ‘ALT’ will automatically be assigned the cloned DataSource with the custom port instead of the original MySQL DataSource.
• To generate a dashboard widget or report. For example, if you have a widget or a report in which you’d like to display data for a certain type of device, you could create a dynamic group that includes only devices of that certain type and then configure the widget or report to reference the dynamic group. New devices added to the account that match the dynamic group criteria will automatically be added to the widget or report.
• To identify devices that aren’t being monitored comprehensively. LogicMonitor applies DataSources to devices based partly on the system.sysinfo property. Typically this property is automatically set when the device is added. However, if system.sysinfo isn’t set for a device (likely because a LogicMonitor Collector wasn’t able to identify the device), LogicMonitor might only apply generic metrics that aren’t device-specific, like ping, http, etc. In this scenario, you can create a dynamic group with the query system.sysinfo =="" to include all the devices in an account that Collectors weren’t able to identify during discovery. This would allow you to identify any devices in your account that aren’t being monitored as comprehensively as they could be.

Some examples of dynamic group queries include:

• system.sysinfo =~ "Linux" – create a dynamic group of all Linux hosts.
• system.hostname =~ "lax" – create a dynamic group of all hosts in the LAX data center.
• hasCategory("Netscaler") – create a dynamic group of all Citrix NetScalers.
• system.hostname =~ "nyc" && system.hostname =~ "prod" – create a dynamic group of all production hosts in NYC.