22 November 2016 blogs Daniel Örneling 7min read
There are several approaches to improve your monitoring if you are working with Microsoft´s monitoring solution, System Center Operations Manager (SCOM).
Read our blog written by Daniel Örneling to find out how you can gain deeper insights from your SCOM data by implementing service-oriented monitoring.
Many of you are most likely running some kind of monitoring tool in your environment today to make sure that your servers are up and running as they should. Traditionally, monitoring has been focused at checking the state of single components, such as the server itself (does it respond to ping?), memory and CPU etc. This is, of course, a good start. But, if you want to dig a bit deeper, this might not provide you enough data to take you all the way.Many of you are most likely running some kind of monitoring tool in your environment today to make sure that your servers are up and running as they should. Traditionally, monitoring has been focused at checking the state of single components, such as the server itself (does it respond to ping?), memory and CPU etc. This is, of course, a good start. But, if you want to dig a bit deeper, this might not provide you enough data to take you all the way.
There are several approaches to improve your monitoring if you are working with Microsoft´s monitoring solution, System Center Operations Manager (SCOM). SCOM gives you the possibility to execute complete in-depth monitoring for each service by using Management Packs. Take an SQL Server for example. If you were to monitor the SQL Server service alone and just make sure it’s up and running, that wouldn’t be too much of a monitoring solution to rely on. However, if you could import a complete set of monitors and rules based on Microsoft best practice on how it should be functioning, you’d gain a much deeper insight.
A few examples of what you can pick up with the SQL Server Management Pack is:
- Database Log Free space
- Database free space
- Active connections to a database
- Service Pack compliance
- CPU utilization for the database engine
The list goes on and on, with almost endless possibilities, and this is just for a SQL Server. You can find management packs for almost all Microsoft services (IIS, DNS, AD and Windows Server, to name a few), but also for a lot of third party services such as VMware and Oracle, etc.
With these monitoring capabilities, a whole new world opens, and if we wanted to, we could just monitor the state of our objects as I have pictured below:
The picture above reflects that all my databases are fine at this moment. This gives me a good insight in how my single components are doing. However, there’s one more level of what you could think of.
Think about all the services you deliver to your business that your users rely on. It could be a single web page, a web shop or some other kind of system. These services, as we call them, are relying on a set of components that all need to function in order for the service to be up and running. With the traditional mindset, we would need to watch all the components individually to make sure they’re all ok. But where’s the relationship between the components?
This is where service-oriented monitoring comes into the picture. Instead of just watching the single components, we should monitor the complete service with all its underlying components. This can be done with SCOM, where we can visualize these relationships. For your web shop to function properly, you need the following components to work:
- The web site where the users navigate to create their order
- The underlying databases to where the orders are written
- The servers hosting the above components
If any of these components fail, you would lose orders, and of course, the money that comes with it.
When speaking of service-oriented monitoring, there are three layers that need to be defined:
- End-user components (where applicable)
- Application components
- Infrastructure components
Once you have defined these layers, you can start monitoring the complete service. See my example below for what you can do with a web shop. The below picture shows the “distributed application” used by SCOM to visualize and define the service.
As you can see here, I have a green checkmark on top of the service, which means everything is fine for now. This service is also something that you can tie to an SLA, which lets you measure the uptime of your service. It’s not only good to know about how the service is performing, but it also allows you to show to the business the uptime of the web shop.
Live Maps for added value
To take this even further and to help visualize the status of the business services, which you can share with different stakeholders within the business, we could bring in Live Maps from Savision. Live Maps enables service-oriented monitoring for SCOM. With Live Maps, you will not only get a more intuitive way of creating the services, but you will be able to quickly and easily visualize the status of any service monitored by SCOM.
With Live Maps Portal, which is pure HTML 5, you will be able to display the service status on a wall-mounted screen, on a tablet or basically any device you want, letting everyone in the business see the status of the service. Live Maps’ ease of use lets people know when there is a problem with the service, which means troubleshooting can start immediately.
Live Maps Service Overview looks like below:
From the Service Overview you can create single dashboards to visualize single services on separate screens etc. or to place the services on a map to see its geographical location.
Taking a deeper look into the service will also reveal performance information about the monitored components:
When thinking in terms of service-oriented monitoring instead of just traditional component monitoring, you will get a faulty service up and running faster after an outage. How is that possible by just grouping the components? You will immediately see that the service is affected by one of the underlying components, get to the root-cause of the issue, and therefore, troubleshooting can start right away by the responsible team.
The difference is that if you would only see the component, many people wouldn’t see that as affecting a complete web shop for example. Since you now have a way of seeing this relationship, you can dive into solving the problem much faster, which will result in less downtime for your services.
What I’ve shown in this article is completely possible to re-create using Live Maps. All you need is a SCOM instance monitoring your separate components, and you are good to go.
Would you like to know more about service-oriented monitoring?
Join Savision’s webinar on: Tuesday, December 6th at 9AM (US) EST | 3pm CET (EU).
About Daniel Örneling
Daniel Örneling is a specialist consultant working for Approved Consulting. He focuses on SCOM, OMS and those parts of Azure that come along with it. Follow his blog if you want to learn more about his tips and fixes for System Center Operations Manager, Operations Management Suite and much more.