With this newest release, the WPM team has introduced several new features, including:
and Step Dependencies
To learn more about each of these features, head over to my WPM 2.2 Beta post. Rather than cover these features individually, I want to give a bit of color as to the power of the three in aggregate.
Using WPM to Define a Web App Workflow
When thinking about the AppStack, a WPM transaction recording is best thought of as a way of defining a web-based application workflow. Defining this workflow allows you to add great context to your AppStack environment. As in previous versions, WPM permits you to capture a series of steps you take within a web app. But now, when you complement this with WPM's newly introduced AppStack support, you are able to go one step further - tying the steps in your WPM transaction to the various components in the AppStack on which it depends.
The easiest way to demonstrate the capability of WPM 2.2 in identifying, forecasting, alerting, and reporting on issues is through an example and for that, why not use a web app with which we're all familiar - the SolarWinds Orion Console. To make it easy, I'll use an example from our wonderful online demo so you can click through. You'll find the example here.
Creating the WPM Transaction
I'm not going to step through how to record the transaction, but as mentioned previously, we built a transaction in the WPM demo to define a workflow that simulates end users visiting the Orion Console from our various office locations. The screenshot below shows the various steps in the recording as well as their statuses (we'll touch on those later):
The transaction workflow is as you would expect - login to Orion from our main Austin office, log out, and do the same from our offices in Cork and Tokyo. Now that you have the transaction and its various steps recorded, you can set your dependencies and really unleash the power of the AppStack.
Setting the AppStack Dependencies
WPM 2.2 allows you to setup both transaction and step dependencies easily. The result is a set of dependencies in your environment that are tied to the success of the execution of our Orion Console transaction - and thus our Orion products more broadly. A screenshot of a transaction level application dependency:
The screenshot above is from the main transaction details page. It shows that you that the entire transaction has an application dependency on an MSSQL instance that is sitting on our orion-main server. Now we'll set a few of our newly introduced step level dependencies, which can be applied both to nodes and applications. To do this, go to the Step Details page for any transaction step and click the Edit option, as seen in the below screenshot.
From there, scroll to the bottom, expand the "Set individual dependencies for steps" list, and add your step dependencies through the Edit menu option you see below.
Once you've set the step dependencies you need, go back to the Step Details page and you will see all the dependencies which you've set.
The screenshot above is from the "Log in to Additional Web1 - Cork" step details page. You see that we have set both node dependencies on this step (a couple of routers and a location specific Orion server, orion-web-cork) as well as one application dependency, our Cork IIS. We could have set any node or application dependency we deemed critical to the execution of this step - the list of the dependencies you can set is only limited by what your SolarWinds products can see.
So that means we set our transaction, and we set our dependencies. Time for the AppStack.
WPM + AppStack = Making Sense of it All
We did all the heavy lifting. Now it's time for AppStack to do the rest and see where it gets us. The good news is, that it gets us pretty far. Opening up our AppStack view and turning our Orion Console transaction on in the AppStack Spotlight view shows us this:
A few simple steps and we now have a view from top to bottom of what our Orion Console transaction looks like in the context of our broader environment. The applications that matter are put into focus. As are the various servers and volumes. A more complex transaction would mean that more levels of your AppStack would come into focus.
So, How Does This Help Me?
The value that the previous view in the AppStack provides is limited really only by your imagination. A few straightforward examples.
1) If you get a ticket that says that your Orion Console is unreachable (which in our demo it seems to be), you can quickly look at the transaction in the above focused view and follow the statuses down the AppStack to find the root cause - you may have noticed in earlier screenshots that our orion-web-cork server is down and thus the status of that leg of the transaction is unreachable. This is clearly represented by the red dot on the server level. Now you know your issue lies with that server and you know where to start.
2) If you would prefer using WPM's full power to get ahead of such issues rather than fight the resulting fires, you can set an alert on a transaction step and instantly be alerted when a step goes down. This will allow you to be informed of an issue as soon as that step goes down and be able to pinpoint which dependent resource may be at fault. Here's what setting up that alert would look like in our new web-based alerting front end. You'll see that it is set to alert you anytime a transaction step is in any state but up (the unreachable status in this example would have triggered this alert):
3) You know that you have a non-responsive app (you see it right in the AppStack) and are curious to see which web apps and transaction workflows may be impacted. You click and see that this Orion Console transaction has that application on its path. Immediately you know that users of the Orion Console will be impacted. While you're fixing the root cause of the issue (our orion-web-cork server), you can have WPM's reporting functionality on the Orion Console transaction build a report to show the impact (availability, SLA, etc.)
4) Mapping of these transaction dependencies allows all those using WPM and the AppStack to understand what parts of your environment are interrelated and dependent on one another. Thus, after initial setup, this information is clearly and intuitively presented even to those that are new to your environment. And if someone in your organization is trying to take down a server for maintenance, they can look at these dependencies and know exactly what will and won't be affected.
A Quick Review
So what did we accomplish? In a few easy steps, we enabled the AppStack to provide quick and easily digestible context about our environment that will help to make identifying, solving, forecasting, alerting, and reporting the root cause of an issue simple.
Above all, this is the power of the new WPM 2.2 and its features. But this is really the tip of the iceberg in the form of a simple example. We can't wait to see what our users come up with.
Leave some comments on your thoughts about this and where you think the power of WPM + AppStack could help you.
And of course, head over to your Customer Portal to get started with the the new WPM 2.2.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community.
More than 150,000 members are here to solve problems, share technology and best practices, and directly
contribute to our product development process.