In this post, alarms were configured to only fire upon the instances contained within a Database Group. These groups are created and managed from the Databases dashboard, but underneath, they are really service definitions.
Now, what if we are using the Service Builder to create service definitions - can those be used in a rule scope to limit what the rule acts upon? Of course!
We start by creating a service category using the Service Builder dashboard. This one is called "GT350". Then, a rule is created to add components to the service. This is dynamic so that if a new instance matching the rule is monitored by Foglight, the service definition is automatically updated. Same thing if an instance is removed from monitoring - it gets removed from the service. I'm using the pre-defined UI query to retrieve a list of SQL instances - and then matching any that have "PROD" in their name:
We can test our query to verify that we get the results we want:
Expanding the service "GT350" in the Service Builder, we can now see how it is structured. You could add additional components to the service - and they don't need to only be SQL Server. You could have rules for Oracle, PostgreSQL, MongoDB, etc. This will be particularly useful when using the service definition on a dashboard or as an input to a report.
The next bit of work is to update the appropriate rule(s) that we want to fire only on the instances in the service. [If we want the rule to fire for all instances (regardless of service container), but behave differently - maybe there is a different schedule or firing behavior - then a copy of the rule should be made. One rule will reference the contents of the service(s) in the rule scope; the other (copied) rule will use the "NOT" operator to reference objects NOT in the service(s)].
Clicking the green check on the rule scope returns a list of impacted objects - by default - everything. We see jobs listed from several different instances.
If we add the following code to the rule scope, and validate the scope, we get a shorter list - those from instances that have PROD in their name.
where $object within^inf (FSMService where name = 'GT350')
A couple recent use cases from customers were to limit certain rules (eg. job failure) to only jobs that "they care about", and to allow different developers to only get emails on "their jobs."
Next time around we'll look at using UI Queries with Service Builder in order to accomplish both of those.
