February 12, 2021

Communicating Strategically with Manual Reporting Availability (Part 3)

Shawn Williams

Technical Evangelist, SquaredUp

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!

Relationships and the three-part application model

In my first blog, we set some ground rules for Critical Service Offerings (CSO) and Supporting Service Offerings (SSO). Those ground rules were:

1. A "Critical Service Offering" is any service or application that provides a function to the university public.
2. A "Supporting Service Offering" is any service that provides services or functions to a Critical Service Offeringor is integral to two or more Critical Service Offerings.
3. A "service" must be a Critical Service Offering or a Supporting Service Offering; it cannot be both.
4. If required, a Supporting Service Offering can report its health information "up" to an arbitrary parent object.

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:

1. The EA Root node represents the current health state of the entire application.
2. The Availability component group represents the health state of the application from the Customers perspective.
3. The Map component group represents the health state of the application from the Infrastructure's perspective.
4. The Dependencies component group represents the health state of any service or application that this application depends upon.

Here is how those nodes will change state:

1. The EA Root node will change state either manually (triggered by the Infrastructure Operations Center or IOC) or by the Availability component group.
2. The Availability component group will change state based on how it is configured, either by Simple URL Monitoring, Simple TCP Monitoring, Custom PowerShell, or Existing Monitoring.
3. Health state is based on Infrastructure monitoring when mapped using SquaredUp's Visual Application Discovery and Analysis feature.
4. The Health state is based on those objects that we want to be alerted on for this application.
5. The SLA for the application will be based on the EA Root health status.

Putting it all together

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.

Add the Dependency Relationship(s) to the EA

In SquaredUp:

1. Click on Applications, then Enterprise Applications.
2. Click on the "Banner" EA.
3. Click on the "Edit App" button.
4. Click on the "Dependcies" link.
5. In the Search for an Object box, type in "Wired Network Services."
   1. As you type, SquaredUp will attempt to show you possible choices.
   2. Choose the First option.
   3. Repeat this for the other two SSOs.
6. Click the Save button, located next to the "Unsaved Changes" banner at the top of the page.

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.

But what about those Support Team EAs?

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:

Demonstrating how to Change State Manually

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:

Manually Changing State

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

In SquaredUp:

1. Starting from either the Enterprise Application, Status, Operational Status, or Availability report dashboards, click on the EA you want to change; in this case Wired Network Services.
2. Click on the "Report Availability" button, which will open the "Report Availability" section.
3. Click on the Degraded link
   22. If appropriate, supply a reason; I entered: "Undergoing planned maintenance. Applications may be impacted. Please see change request #123F22.".
4. Click the Update button.

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:

1. First, when an SSO goes degraded (or critical), you immediately know, and so do the CSO owners.
2. Second, you can communicate with everyone because information flows to each relationship.
3. Third, you can choose how you want to communicate, via the CSO, SSO, or the Support Team EAs.

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.

TL;DR

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!

-Shawn

Shawn Williams

Technical Evangelist, SquaredUp