Within SentryOne, you can create different sites and groups for your monitored environment. A site is a logical grouping of targets, instances, SMTP servers, and monitoring services in SentryOne. Once you have created sites and groups, you can begin to make changes in relation to settings and alerting based off said site or group.
A great use case for sites is when you have a SQL Server environment that spans multiple datacenters. Within each datacenter, you might have several production and test machines, but those machines are unable to interact with machines from another datacenter. For this scenario, you would create a site for each datacenter and ensure network requests for performance data collection are contained within the datacenter closest to monitoring services. This configuration can also help avoid issues with monitoring over high latency connections and it can aid with de-centralized security across untrusted AD domains.
Within each datacenter, you can group targets further into production and test categories. This is done by defining groups in the navigation hierarchy. A primary difference between groups and sites is that sites are a mechanism for controlling which monitoring services and targets communicate with each other. Groups are primarily for organizational purposes.
Both sites and groups can be used to configure settings and automation options for sets of targets rather than one at a time. The ability to configure settings at the site or group level helps ensure you manage your servers that are doing similar work together consistently.
For example, you might want to collect more data for your production machines than test and/or you might want to modify your alerts, as the threshold applied to one alert might not be ideal for both environments (e.g., alert for High CPU @ 90%). The screenshot below shows what this would like in your SentryOne installation.
Object Groups are a third type of grouping function in SQL Sentry. Object groups are ideal when you need to apply similar policies across a set of objects that do not follow the hierarchical group shown above. This blog post walks through how to create Object Groups for two production environments, even though they are in different datacenters.
Creating Object Groups
To create Object Groups in SentryOne, right click Object Groups in the Navigator Pane, select Open, and select the Add button shown in the screenshot.
In the above screenshot, I entered the name of my group and gave it a meaningful description to help identify the group in the future. In the “Applies To” drop-down box, we have two options:
- Selected group members and their “children”: Any conditions or settings you configure for the group also apply to the “children” of the group members. This makes the group’s settings and conditions inheritable.
- Selected group members only: Any conditions or setting you configure for the group only apply to the specific members of the group and have no effect on their “children.” This makes the group’s settings and conditions noninheritable.
Once the group is created, members will need to be added before the group is functional. Select the objects for the group from the provided tree view on the left of the dialog box. In the example, the Site or Group has been selected, search can be used to view the available objects, and the required objects can be selected. In this example, I only needed to add two objects. You can select multiple objects by clicking Ctrl or Shift for more complicated scenarios.
Making Use of Object Groups
Once you have created and populated an object group, it is time to start putting the group to work for you. Imagine you have decided that being alerted on High CPU @ 90% (a built-in Advisory Condition in SentryOne) for your production targets does not provide much value. At this point, you are already aware of the issue and you need to be alerted before this threshold is reached. You need to disable the built-in Advisory Condition and make use of the same condition with the threshold updated to 80%.
To do so, select the object group in the Navigator pane, and then select View Conditions. Next, select Add and select the required conditions and what action you want to enable and disable. Once both have been added, you need to make sure you have selected the correct behavior. The original High CPU condition will be set to Disabled, ensuring that when this condition is triggered, the action assigned to it will not be executed for your production targets. More information about action behaviors can be found here.
Configuring Advisory Conditions at an object group level
The condition has now been configured. The last thing to check is how this is displayed throughout the client. If you look at either of your production groups, you will notice your original condition is disabled and High CPU 80 is now displayed. Notice the Object column, which relates to how/where this has been configured.
You will also be able to see this information by running your Active Settings List report. This report is built-in and can be found under the Reports dropdown in SentryOne (Reports > General > Active Settings List).
In Summary
I hope you found this example of setting up Object Groups within SentryOne to be easy to follow. Although this blog post walked through production versus test, you can use this same process to set up alerting for your monitored environment that might require multiple sites in SentryOne.
To learn more about alerting, check out Patrick Kelley’s blog post on alert tuning here. Finally, Devon Leann Wilson has an excellent blog post on Object Groups in relation to SQL Server Agent jobs, which can be found here.
If you have not given SentryOne a try yet, download a free trial.
