Resource Group Overview

Grouping your resources in LogicMonitor can make management significantly easier and save you time when configuring alert thresholds, dashboards, reports, alert routing, and resource properties.

Resource groups allow you to:

• Organize your resources within the Resource tree, improving navigation and load time.
• Manage 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.

Common Grouping Strategies

There isn’t one correct way to group 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 resources are grouped so there is room for fine tuning to ensure your resource group structure is the best fit for your environment.

Grouping According to Criticality

Consider grouping 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 resources with the same slow performance. Grouping resources 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. See Tuning Static Thresholds for Datapoints.

In addition, grouping resources 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:00 PM.

Grouping According to Team/Organization Structure

Consider grouping resources based on the structure of your organization. How does your organization operate and divide responsibility? Having a resource group structure that mirrors your organizational structure will make all other areas of account configuration (especially user roles and permissions) much simpler. Such a resource group structure can help teams quickly find the resources relevant to their jobs and allows you to set up roles for each group, such that each team can only make changes to the resources for which they are responsible.

Grouping based on organizational structure may mean grouping by:

• Function (e.g., a database group, networking group, servers group, etc.)
• Location (e.g., a group for each office or data center location)
• Customer (e.g., you are an MSP and have groups for each of your customers)
• Business application (e.g., group together all resources serving a particular website)

Additionally, this concept extends to subgroups. For example, if you have a NOC team that in charge of overseeing a large number of resources and then smaller functional teams responsible for subsets of those resources, your resource group structure may look like this:

• NOC
  • Database
  • Networking
  • Servers

Grouping According to Resource Relationships

Consider grouping resources based on how they depend on one another to expedite troubleshooting and make it easier to schedule downtime for related resources. For example, does your organization have a regular maintenance window that results in a distinct set of resources becoming unavailable? Grouping those resources together would allow you to more clearly identify downtime due to maintenance and more clearly identify issues that arise in resources outside of maintenance. You could also group resources that comprise a single application. In general, grouping resources 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 resource 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 includes a wildcard will include resources 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 Resource in Multiple Groups

Resources can be members of multiple resource 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 resource is a member of both of these groups, the selection of which property will take effect is nondeterministic.

Static vs. Dynamic Resource Groups

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

Static Resource Groups

Static resource groups have static memberships. You must manually add or remove resources or subgroups to manual groups (although resources 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 resources from a manual group.

Dynamic Resource Groups

Dynamic groups have dynamic membership. This means that 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 resources to the group. See Adding Resource Groups and AppliesTo Scripting Overview.

Resources cannot be manually added to dynamic groups, and are automatically removed when they no longer meet the group criteria. For example, you could create a group for your San Francisco office, with the following custom query: location =~ "San Francisco". If a resource 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 resource group, and will be inherited by group members.

Next are several scenarios for when you may want to use dynamic groups:

• When a subset of resources use a custom port—For example, if all of your SQL servers names start with ‘ALT’ have a custom port configured for MySQL, you could create a dynamic group that includes all resources 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 resource, you could create a dynamic group that includes only resources of that type and then configure the widget or report to reference the dynamic group. New resources added to the account that match the dynamic group criteria will automatically be added to the widget or report.
• To identify resources that aren’t being monitored comprehensively—LogicMonitor applies DataSources to resources based partly on the system.sysinfo property. See How DataSources Get Applied to Resources. Typically this property is automatically set when the resource is added. However, if system.sysinfo isn’t set for a resource, LogicMonitor might only apply generic metrics that aren’t resource-specific, like ping, http, etc. In this scenario, you can create a dynamic group with the query system.sysinfo =~ ‘’ to include all the resources in an account that Collectors weren’t able to identify during discovery. This allows you to identify any resources 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.