Why Service-Oriented Monitoring is here to stay

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

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.

Service-oriented monitoring

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 check-mark 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 up-time of the web shop.



Would you like to continue this blog by Daniel Örneling? Click here: http://bit.ly/2gFG07u

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.