In our latest Coffee Break session, Bruce Cullen, Director of Engineering here at SquaredUp, was joined by Monitoring and Automation Consultant Keith Rochester.

Having worked with SCOM a long time, Keith developed an idea for his own set of Standard Monitoring Framework Management Packs, a “much needed solution” according to the man himself.

From Keith’s GitHub page:

“With SMF:

• The Application SME creates a set of registry keys on the servers where the service needs to be monitored, describing:
  • Which Windows service to monitor.
  • When to monitor it.
  • What priority/severity the alerts should be.
  • The team that alerts should be routed to.
  • The business service the Windows service is part of.

• SCOM discoveries run and discover the Windows Service, monitoring configuration, and the business service it is part of.
• SCOM monitors the service and includes its health in the business service (Visible in the SCOM console and SquaredUp dashboards)”

With these Packs now built, Keith walked Bruce through them, as well as gave a broader overview of how it enables application teams to own, build and review the monitoring for their business services – all without complex MP authoring.

What is monitoring and what makes for good monitoring?

The tenets for good monitoring are delivering the right message (whether that be a ticket, a notification, an alert, or something else), to the right people, at the right time.

One of the key tenets of good monitoring is to not fall into the trap of monitoring for the sake of monitoring. Monitoring should always be relevant to the people consuming it, not unnecessarily used just because a relevant management pack exists. It is very easy to fall into this trap, and one way to avoid it is to hand over responsibility to the users, making them responsible for their own monitoring configuration and deployment. By working in this way, it means that SCOM admins will no longer have to fix issues within pieces of monitoring, caused by users changing the application.

Monitoring and Authoring Tools 

There are several great tools for deploying for building and deploying monitoring, each with their own set of advantages and disadvantages. 

As shown in the table above, these tools vary in complexity, with some being impractical or nearly impossible to be implemented by application owners. Another common theme is the need for SCOM knowledge. To successfully and efficiently use these tools, you need to know why it does what it does, which cannot always be the most straightforward thing to comprehend. 

Standard Monitoring Framework 

What Keith wanted from the tool he wanted to build was to reduce the amount of time he spent authoring the same types of monitoring. Broadly speaking, people want the same types of monitoring, with a few personal tweaks, every time, which left Keith feeling like he was in a “reinventing the wheel” situation.  

Knowing there was a better solution to these frequently occurring issues, and to save himself from falling into the rut of copying and pasting the same solutions repeatedly, he developed the Standard Monitoring Framework Management Packs. This would be a way to empower users to take charge of their own monitoring, without having to tackle the daunting hurdle of learning SCOM authoring tools. 

Most importantly, he wanted the MPs to be consistent in their look, function, and integration. By reducing friction and providing a consistent service model for end users, with the same set of rules for all, this would drastically simplify the process of getting end users to take control of their own monitoring. 

How it works 

Keith then jumped into a demo environment to show off exactly what Standard Monitoring Framework can do. 

This demo can be viewed in full on the webinar recording, beginning at 20:00 and finishing at 55:12. 

He first demonstrated a completed business service to show what a potential user should try to aim for. 

Keith next opened a Windows Server and demonstrated how to add a Windows Service Monitor task to it, first overriding the task parameters to be able to add in custom properties.  

To explain the various parameters, Keith was referencing a document he had created in GitHub that outlines the process of implementing the SMF packs, but also provides definitions of all the tools and parameters used. 

A particularly useful area of the documentation focused on scheduling, highlighting the ability to control when workflows run. By setting scheduled times to run this negates the need to put workflows into maintenance mode outside of operational hours.  

With the custom parameters set, the task is then run, and registry keys generated. 

Keith then showed the registry keys within the virtual machine he was using for the demo. 

The entire process is very straightforward, making it suitable for an end user. 

The next demonstration showed how to add in monitoring that already exists, and setting the owners to ensure that the right people are sent the right alerts. For Keith’s example, this was achieved by using the SMF pack’s “Add SQL Database to Business Service” task. 

Having once again set the parameters and run the wizard as before, the SQL database was now appearing in registry. 

We then moved over to SquaredUp to demonstrate what Keith described as the “big driver” for SMF, the consistent look and feel of the monitoring processes.  

Within SquaredUp Keith showed the two dashboards he had created, Business Services and Teams. The Teams dashboard shows every team that have been created, with each team showing the individual business services that have been created for them.  

Looking at the Business Services dashboard, we then went into the Trading Desk service, demonstrating the look that every monitored business service within SquaredUp shows.  

The webinar then concluded with a Q&A, which you can view from 55:13 in the webinar recording. 

You can check out the Standard Monitoring Framework Management Pack for yourself here.