How to Endure Application Performance 24 x 7

Do you want your applications to perform at their best 24 x 7? Would you like to boost your organization’s productivity? Of course, everyone wants this, and here’s how: continuous monitoring of the application stack. Application stack?!! What’s that? Keep reading this article and I’ll walk you through the application stack.

To understand the application stack you should first understand application deployment in a typical organization.


One of these components will be the sole reason for an application’s performance issues. Therefore, continuous monitoring of these components is a must. However, the most important will be the graphic illustration of all the components in the application deployment. The graphic illustration should show the status of all the components, giving you can get a bird’s eye view of the all components’ working status. But just a view of the statuses is not enough, you have to ensure that you have enough information when there is an issue with one of the components.

Let’s go through an example, such as an issue with one of your applications, like MS SQL.

You can first start with the server. Being an administrator you will know which server SQL is running on. Then you can directly check the performance of the server, including memory, disc, etc. But if it is running on a virtualized environment (which is mostly the case these days) you can drill down to see the host, virtual cluster, virtual datacenter, and the data store the VM belongs to. If there is an issue with any of these you should further drill down to locate the exact issue. Minute details of node, Hyper-VRegistered host, ESXRegistered host, Vserver, etc., should be checked. If everything is perfect, you can move on to the next item in the application stack.

You can check the volume the VM is using, the LUN where the data store of the concerned VM is located, storage pool, and storage arrays.

If the issue is with a Web-based application, the troubleshooting should start by tracking the application’s Web performance. You should be able to track the transitions, which indicates if it’s an issue with the application itself. Also, you can back track to see if it’s a network issue.

Basically, if you are able to monitor your system, VM, storage, Web performance, and network, the complete application troubleshooting process will fall into place. When you have information about all these components together in one console, your life as an application engineer becomes a lot easier. Moreover, you will be able to proactively troubleshoot any upcoming issues, helping you achieve consistency in your application performance.

The combination of a couple of tools will help you achieve all of the above. Switching from one application to another is difficult. However, SolarwindsRegistered has its Application Stack Management Bundle, which gives you full visibility of all components associated with an application. Want to know more about the Application Stack Management Bundle? Visit Solarwinds’ at booth HH18 at IPExpo, London.

  • Yes, App Stack is only part of the solution. QOE and SAM and the rest of the tools are needed to make a comprehensive picture from which problems can stand out.

  • This is the simple view of a service on a single server.  This needs to be able to expand to allow for multiple servers/instances that define the total business service.

    I think App Stack as named needs to evolve a bit more in order to define services...especially when portions of different services may run on the same server (a web server is a good example).

  • Monitoring is very key, no admin will leave the network to only just automations. A monitoring solution that is not compatible with checking the virtualization technology should be thrown out.

  • I think the visualization component of any monitoring solution is important.  In working with different clients to build a monitoring solution they all find a huge value in creating an at-a-glance visualization of their application including all of the different components that make that application possible (network, servers, storage, etc).  On the flip side its also important to build that visualization in such a way that you don't need to keep constantly updating the visualization every time some component is added/removed/changed.  I personally found a great way of doing this is using Dynamic Groups in Orion and then adding those groups to the visualization; by doing this the visualization is automatically updated as you add/remove/change the specific underlying components.