The Wonderful World of Service Definitions in Foglight

A UI Query can be used to add either static or dynamic components to a service definition via the Service Builder dashboard. This in turn offers a
great range of additional things Foglight can do. This post will introduce creating a service definition and adding objects to it.

The Service Builder dashboard is accessed via Expert mode on the left hand panel, under the Services node. Although the primary purpose of the dashboard is to build service definitions, it does display some interesting data. The overall SLA on the service is shown, along with several columns for alarms. The first set of alarm columns shows the resulting alarms by applying any defined alarm filter. (Spoiler alert - this will be very important when discussing ServiceNow integration.)

The No Alarm Filters columns show all of the alarms on the underlying objects of the service. You can edit and remove service definitions of course, but you can also specify the email settings. This provides a summary email whenever an alarm occurs on the service definition - a great way to enhance alarm email delivery for non domain specific (eg. DBA, VMware Admin) personas.

  

Let's say we wanted to create a service that shows all SQL Server agent jobs, across all instances, and we want it to be dynamic so if anything new comes in, it belongs to the service. Likewise, if an agent job is removed, it gets deleted from the service. Start by clicking "Add a new category" which defines the top-level of the service definition. You can click Finish on this screen if you want to.

I've got an empty service definition that I can now add components to. A child service is just another service that can reside under the top-level service, or it can also be specified as a global service which can be used in other services. I'm just going to add some components to the top-level service, specifically SQL Agent jobs.

You can add a specific component (fixed object) or create a rule to dynamically manage the components of the service. 

To build the rule, we provide a name (SQL Jobs), and then navigate to the objects we want. I purposefully went to Services -> All Model Roots -> DBSS_Data_Model to see if I could just add all objects from the "Agent Job List". Nope. I have to pick an instance first. I've only got 6 instances in this lab, but I'd still have to do this step 5 more times. If I add an instance, I need to do it again. Anyways, we got this far so we can click the Test button to see if it's going to do anything. Can confirm that those are my agent jobs, from the 1 instance..

There has to be an easier way, right? (Yes, there is.)

In my Introduction to UI Queries  post, the building of a simple query to return all SQL Server Agent Jobs was shown.

As a refresher, that UI Query was stored in the "Darren" module and returns a list of "SQL Server Agent Jobs".

I can use the UI Query in the Service definition, by navigating to the module where it was created (Darren) and selecting the query. Clicking Test this time shows me 83 jobs from across all instances!

Clicking "Create" adds the rule to the service, which we can confirm by expanding it in the Service Builder:

But wait, there's more!

A dynamic managed component service definition can further filter the UI Query results. An example would be to take the SQL Server Agent Jobs UI
Query (which returns all jobs) and have a service definition that only shows jobs starting with a pattern (eg. LiteSpeed% jobs). All that needs to be done is put a rule condition in to the definition - (name like '%LiteSpeed%').

Now we could add an email to just get notified when there is an alarm on a LiteSpeed job, or further down the (blog) road, see how those alarms can be sent to ServiceNow.

Anonymous