In my prior two blog posts, we focused on creating a bunch of Enterprise Applications (EAs), tagging those EAs, and then updating the Status dashboard to only show those EAs that are Critical Service Offerings (CSO).
For this blog post, we will create some relationships and demonstrate how alerting behaves using SquaredUp’s Manual Reporting Availability functionality available in the EAM tier of the product.
For this post, we’re going to do amazing stuff!
In my first blog, we set some ground rules for Critical Service Offerings (CSO) and Supporting Service Offerings (SSO). Those ground rules were:
We also wanted a notification model for the support teams.
Be sure to check out what the three-part application model is in SquaredUp: Enterprise Applications
For review, here is a simple Visio diagram of an EA:
When we view the EA in SquaredUp, it looks like this:
And when we look at the Availability report, we see:
Finally, here is the operational status dashboards (which will be particularly important further down in the blog):
Since we’re using SquaredUp’s Enterprise Applications (EAs) model, we will be working with a pre-defined structure. Keep in mind that this topic can get complicated fairly quickly, but to keep things unambiguous, let’s spell it out.
We have four nodes, here are what those nodes represent:
Here is how those nodes will change state:
Now that we have our foundation let’s create some relationships! Since each CSOs might have a “dependency” with one or more Supporting Service Offerings (SSOs), we need to map everything out.
Please Kindly Note: For this blog’s purposes, we will be creating fake relationships to make things interesting.
Here is a (not so) simple chart:
That looks like a mess. Let’s zoom in on the Banner CSO, which has three SSOs: Wired Network, Active Directory, and BoilerKey.
First, a list of possible choices.
Second, Dependencies after our selections.
That’s it. When the state for either Wired Network Service, Active Directory, or BoilerKey changes, the “Dependencies” component group for Banner will turn red, which we will see in action shortly. But for now, update all of the other CSOs with their SSO relationships. Once complete, we can demonstrate how it all comes together.
At this point, you probably thought I forgot about those Support Team EAs? To recap, these are the EAs that a Support Team would use to check that their SSOs function correctly.
For these EAs, we want their Root health state to change when an SSO changes state. Instead of adding the SSOs to the Dependency component group, add them to the Availability component group (via the Existing Monitoring option) in the Support Team EA. That way, the SSO’s health flows to the root of the Support Team EA, which is also an innovative way of communicating with your support teams.
Health state will roll up in this way for the Support Team EAs:
Now that your CSOs have been updated with their SSO dependencies check out the Diagram View in your SCOM console. When you open a diagram view for one of your EAs, you will see something similar to this:
Now let’s demonstrate how to manually change the state so we can see how it looks. Looking at our chart, we’re going to focus on the Wired Network Services SSO and change its state to “degraded.”
Be sure to check out the SquaredUp Knowledge Base article if you run into issues: How to manually set the health state of an application
I’ve put together a (busy looking) dashboard to demonstrate what just happened:
A few things are happening on this dashboard. The first is that our comment shows up under the Wired Network SSO on the right. Second, you can immediately see which CSOs have the Wired Network Services SSO as a dependency. Third, the Support Team EA for the Networking team has gone degraded, and the comment shows up there too.
Here’s what the dashboard looks like from a CSOs when a dependencies is having an issue:
But if you’re asking yourself what does this really get you, well, you get three things:
For example, what if the Networking team is working on an issue. Just put their Support Team EA into a degraded state. Since the Support Team health state doesn’t flow to the CSOs or SSOs, everyone knows that Networking is doing ‘something.’ If their work goes poorly and causes an outage, but none of the CSOs or SSOs change state, you have communicated, and you have documentation. To put it another way, it means that you can share with different parts of the organization without sending a flurry of emails or making numerous phone calls.
Lastly, you might have also noticed that the Wired Network Services outage didn’t impact the Availability status for the CSOs. That’s because our three-part application doesn’t roll-up the health of the Dependency component group, only the Availability component group. That also means we can relate the two issues, but the “outage” impacts the Networking Team’s SLA, not the Application Team.
In our last post, we tagged our CSOs and SSOs. In this blog post, we reviewed our ground rules, set up some additional controls, and went a step further by setting up the relationships between the CSOs and SSOs. Finally, we demonstrated how to manually change an EA health state and what would happen with all of those relationships.
Now that we have a fantastic framework, some of the topics we can cover might be how to create some availability tests to inform us from the Customers perspective? Or maybe we could look into using SquaredUp’s Visual Application Discovery and Analysis (VADA) tile to quickly and easily add in our infrastructure objects? Putting my “Enterprise” thinking cap on, we could also drop down to SCOMs Data Warehouse and create some custom SLA reports. Hmm. Choices, choices, what should we do next?
Till next time!