Multi-tiered applications are no longer the exception but the rule. In the past, assessing application performance meant monitoring response time and health on a single server hosting one application. Now, with the applications increasingly becoming virtualized, utilizing multiple protocols, and operating over multiple servers, the approach to tracking overall application performance needs a reboot.

So how do you effectively track the health and conversations involved in a service comprised of multiple frontend web servers interfacing with middleware servers and backend database systems? Here are 7 steps for a monitoring strategy that ensures visibility and analysis into tiered applications.

1. Map out how data flows between the different application tiers.

One of the key things is being able to identify what conversations are occurring between different tiers within the application to fulfill a user’s request. For example, when a user is signing up for an online service and presses the submit button on a web form, what happens behind the scenes? Likely an HTTP web request has been issued from a client to a web server. The web server then sends that request to the middle-tier server, which converts that request from HTML to SQL so that the database server is able to interpret what the request is. When the request is processed successfully, the result is communicated back through the same set of components, and a confirmation message appears on the client’s screen.

2. Identify devices involved in sending and receiving client/server requests and responses.

For components involved in the delivery of the service, track the conversations between the devices including the ports used for communications. With large or legacy systems, manually mapping these relationships can be very time-consuming. Monitoring solutions like Observer Reporting Server streamline this process through application dependency mapping which automatically discovers and diagrams devices involved in multi-tiered applications based on how they communicate with each other.

In addition to the routers and servers, it’s critical to identify other components in the communications path, such as firewalls, load balancers, or proxy servers that can impact application performance. Having this map, you can then locate the points to visibility that will allow you to best assess application performance. For example, to assess the potential impact of a firewall on an application, capture and correlate traffic on both sides of the device.

3. Understand application-specific metrics.

Tracking performance across a multi-tiered application involves more than monitoring response times. An application can respond quickly, but be returning error codes. For example, with your web servers, are they returning 200 OK messages or 500 Internal Server Errors? Tracking and understanding specific errors will allow you to find points of application failure quicker.

4. Baseline to determine normal application performance.

Specific components and metrics to track in a multi-tiered application include:

• Application performance and response times
• Network delay
• Conversations between tiers (examples: track response times and network delay from client to web servers, web tier to middleware tier, and middleware tier to database tier)
• Traffic and usage patterns (understand how demand changes based on time of day, week, and month)

As a rule of thumb, if users are content with current performance, these metrics can serve as benchmarks for application health.

5. Set up alert thresholds to indicate degrading performance.

Thresholds can either be dynamic and based on past performance, or fixed if you have service level agreements (SLAs) to meet. Examples of thresholds and alerts to set include tracking significant network delay, slow application performance, excessive application errors.

6. Configure reports and real-time performance indicators.

Consider how you want to organize the data for effective monitoring and share with other IT teams. Here are key questions to consider when configuring reports:

• Do you need to organize the data by client location?
• Do you have multiple remote locations requiring their own reports?
• Do you need to track performance by business unit or department?
• Are there reports and indicators being used by other IT teams that require access to specific errors and metrics?
• Is it better to view multi-tiered application performance as a map or grid?

7. Track long-term application changes.

As application usage grows, it’s critical to understand when additional devices will be added to handle increased application traffic. Stay on top of whether portions of the multi-tiered application are being virtualized. Baselines, reports, and alerts all need to be actively updated to account for these changes.

Through effective mapping, monitoring, and reporting of the many moving parts within a multi-tiered application, you’ll be able to ensure successful performance now and in the future.

Thanks to Network Instruments for the article.