One of the features that Quest’s Foglight is built upon is services. If you have ever seen one of our product demonstrations (and if not, you can visit the new view website to see one) you will have heard that one of our main concepts is grouping together all the elements of an application (the app server, infrastructure, database etc) so that you can quickly understand the health of your applications and begin your diagnostic process. This power is brought to you by the services model.
So what is a ‘service’?
The easiest way to think of a service is as a grouping of ‘stuff’. Although we pitch them as the way to display your applications and business services the product doesn’t limit you to just that. Using the service builder dashboard you can group any monitored object into any grouping you choose.
In the following mini series I want to explore some of the ways I find services used in the field, and some of the ways the Foglight field team use services to help the product meet customer’s needs.
Services for Applications
So before we get too involved with all the possibilities, lets first understand how you create services and get used to the service builder. In this example we’re going to create a service model for our company containing our key business app. Then we’ll look at the out of the box views available to us to look at this data.
What you’ll need
No massive requirements for this exercise, all you’ll need is a working install of Foglight which is monitoring something (it could be anything, but you might want to alter the example to suit whatever Foglight is monitoring in your organisation).
Method
Inside Foglight, open up services in your lower-left hand menu and click on service builder. You may see some services already exist in here, this is because some cartridges create their own services which they then use to power their dashboards.
The first thing we need to do is create our category, this is a special type of service that exists at the top level and groups services together. Click “add a category” at the top of the dashboard
Name your category, and choose “no” from the radios boxes below (more on that in a minute) and click create.
You should see your new category has been added to the dashboard. Next we want to create our application underneath this. Click the green + icon on the far right next to your category (in the add column) and choose “add a new service contained by this service” and then choose global service.
Name this service after the application we are modelling, again select “no” at the bottom and click ok. Now we want to add the tiers for this application. In my example I’m modelling my website, so I’m going to have the traditional web, app and db tiers.
To add a new tier I click the add icon next to my application, and choose “create a new service”, and a new local service (I’ll explain the difference between global and local services later on). The popup that follows is the same as before but now I want to set a few extra options. in the tier drop-down I’m choosing app, and this time I’m choosing “yes” from the radio buttons:
Do this for each of your tiers. You should end up with a structure that resembles this:
Now we can add some monitored objects to each of our tiers. Once again, click the “add” button next to our tier, and this time choose “add a specific component”. In the popup that follows you’ll see Foglight has selected objects in app tier for you to add to your service, you can either choose one of these or use the many search options to add whatever you like to this tier. In my demo environment I have a limited number of agents, so I have chosen a custom agent that I’ll pretend is monitoring my application code:
When I click add components and go and look at my service structure, I can see my monitored object, but Foglight has done something else – it has dynamically added the host that this object resides on. This is what the yes/no options were doing for us, by choosing yes, we asked Foglight to automatically add any hosts that are also involved in this service. You can go through and add all the other items to the other tiers of your application (database objects etc). Go ahead, I’ll wait here.
When you’re done, you should have something that looks like this (note that you can add more than one thing to a service, as I did in my DB tier)
Congratulations, you’ve built your first service model!
Global Vs Local
As you saw earlier, we chose to create our application as a global service, and the tiers as local services, but what’s the difference? The difference is that global services can be reused in other service models, but local services can only be used once. If you go into the add components popup you’ll see there is an option for global services that you can add into your services.
Why would you do this? Imagine you had a shared middleware application that is used by many of your business applications. Rather than add all the elements of that application into each service, it would be much easier to build it once as a global service and simply add that global service to any of the applications that rely on it. This way any changes to the service will be reflected in all the services it is being used.
Putting them to Use
So you’ve built a service, what now?
Well now we can make use of the service operations console (SOC) to give us an overview of the health of our application. The SOC allows each user to create their own services dashboard depending on their responsibilities and interest, and you can find it in your homes menu and use the link at the top of the dashboard to choose your newly created service.
Note that Foglight completes the tier columns using the tiers you set for each of your services, displays health states for each, and even builds you a service dependency graph. If you click on the alarms tab you will see the alarms for everything in this service model.
There are many other dashboards for services, explore the services menu and you will see views for monitoring SLA’s and much more.
Other examples
In this exercise we built a model for an application made up of tiers, however this isn’t the only use case for services. Using the service model and the SOC you can quickly build services for Production vs. UAT, so that only production alarms appear on the dashboard for you (and help you identify business critical alarms). Some companies also use services to divide monitored objects by responsibility, or even by customer (in an MSP environment).
In short, in any situation where you think it would be good to group objects together, for whatever reason, services are usually your answer in Foglight.
This post is part of a mini series on Foglight Services, the complete listing for this series can be found on the services contents page.