The last couple of months I was busy with ‘preparing for’ and ‘presenting on’ 2 events. My first presentation was on a Dutch community event called Expertslive and 2 weeks ago I presented on the 4th edition of the NIC conference. The topic of both presentations was Service Monitoring. How can we enhance our monitoring by adding Service Monitoring to our SCOM environments? In the following series of blogposts I want to share this information also through my blog. In this first part I want to look into what’s Service Monitoring.
Service monitoring is monitoring the overall health of a service or application. It’s combining all components of a service together to get an overall state. Service monitoring is also monitoring on the performance of the service. Normally we monitor the availability of our components (and sometimes services), but monitoring the performance and especially the end-user performance is most of the time not configured. It’s important to monitor both the availability and end-user performance to get a complete picture on the health of your service/application.
When you want to start with Service Monitoring probably your first step is to set-up a process around Service Monitoring. Since more parties are involved with their own responsibilities it’s good to define a process around Service Monitoring. This process must contain at least the following steps:
- Inventory the Application
- Define and implement Monitoring
- Define and implement Dashboarding
- Define and implement Reporting
It’s important to start with inventory your application components. During this phase you get to know the application. Based on this inventory you can add the monitoring of the application components to your SCOM environment. When the monitoring is added the next and most important step is to tune the monitoring. Service monitoring without a tuned monitoring will result in a failed implementation of Service Monitoring. When your monitoring is not tuned the service will not represent the actual state of the application because of incorrect health states of application components. Tuning is THE most important step!
When all monitoring is in place you can create your services in SCOM. You can do this by creating distributed applications. With distributed applications you can get an overall state of monitoring objects, sounds like service monitoring, right? In the Part 2 we will look into the implementation of Distributed Applications in SCOM.
Service Level Agreement (Objectives)
I want to end this blogpost by talking about defining and configuring Service Level Agreements. When you have defined the monitoring of the availability and performance of your services you probably also want to prove that the application is available and performing as agreed. This can be done by configuring Service Level objectives. When you configure Service Level Objectives in SCOM you can create dashboards and reports based on those objectives. With SLO’s you can prove that the availability and performance of your application is as agreed in the Service Level Agreements.
In Part 2 I want to look into the Distributed Application implementation in SCOM. What’s the structure of a Distributed Application and how can we setup Distributed Applications.
If you have any questions about Service Monitoring please let me know!
2 thoughts on “SCOM: Service Monitoring – Part 1”