Let's take a closer look at narrowing down the scope of a rule. The use case I normally hear is, we have some important jobs, databases, etc. that we want alarms for, but we don't want alarms for the other non-important ones.
When using the Service Builder to define a service, you are picking objects to add by using UI Queries. There are pre-built queries that return objects such as SQL instances, Azure SQL Databases, etc.
In this post, UI Queries are introduced and a sample query is built to return SQL Server Agent Jobs - a list of all jobs that are monitored. We can put the pieces together now, and create a service to return the "important jobs", and then update the "DBSS - Job Failure" rule to only alert on those jobs. It will be dynamic too, so any new job matching our pattern will be included in the scope of the rule.
In this example, we create a dynamic service to return Jobs that start with "LiteSpeed" - N.B., it is case-sensitive. You can create additional rules to account for case sensitivity, to add other patterns, etc.
Testing the query, we confirm a listing of matching jobs:
We can also review the service definition in the Service Builder dashboard:
You can then use the icon in the Email column to add an email address to get notified whenever an alarm fires on the service - in this case, whenever a Job with a name starting with "Litespeed" fails.
You can rinse and repeat by creating additional services to match different patterns, that go to different emails if needed. You can re-use the same UI Query since it's just returning every job known to Foglight. And if you want a service defined with all jobs, just use "name like '%'" as your defining query.
