Page 2 of 2   « previous page

Monitoring Requirements
The increasing adoption of WebSphere MQ-based messaging infrastructures is driving an increase in the need for ensuring that these systems are up and running at peak performance. So enterprise IT shops need to implement a management solution that provides comprehensive visibility into production and pre-production application environments as well as the ability to share critical data with each member of the IT team who has a stake in the performance of the application and its subsystems.

Comprehensive Visibility
While there are tools that can monitor each piece of a composite application, they often present a disjointed view of the application environment. To achieve effective monitoring of Web transactions, it's important to have end-to-end visibility starting from the browser to the back-end systems and everything in between so that IT personnel can proactively detect slowdowns and failures, determine the nature of the problem, and diagnose the root cause of performance problems quickly. This whole application visibility should include the browser, JVM, application server, databases, MQ Java connectors, and WebSphere MQ itself as well as connection to back-end transaction servers and connected third-party systems.

The management solution should monitor 100% of the transactions and let you track component interactions in the individual transaction path. Another key requirement is customizable dashboards that can be tailored to fit the individual needs of users whether they're operations personnel responsible for production monitoring, application administrators responsible for problem triage and diagnosis, or WebSphere MQ administrators responsible for ensuring service levels and system availability.

The monitoring technology should use a non-intrusive monitoring mechanism so it can provide deep visibility into production systems without negatively impacting performance. The metrics reported should reflect the performance of the system in response to real user behavior rather than synthetic transactions that can't give an accurate picture of system performance.

Another key element for an effective solution is a proactive alerting mechanism that can provide incident notification before end users are affected. Whether via pager, on-screen notification, or through a systems management framework console, operations and application support personnel need to know about problems early so that performance issues can be eliminated as soon as possible. The solution should also be able to integrate performance data with framework solutions so that it fits with existing systems management processes.

Monitoring WebSphere MQ
Application administrators responsible for the health and availability of systems that use WebSphere MQ as the messaging backbone are keenly aware of the need to monitor both WebSphere MQ and the Java applications to which they connect. But these administrators tend not to be messaging system specialists, so for them the important question becomes what MQ metrics do I need to monitor? What data can help me pinpoint performance issues to the Java application, to the MQ connectors, or to the MQ system itself so that I can bet ter communicate the exact nature of the problem to the person who must fix it? And further, the tools available to application administrators tend to be best suited to MQ administration, not MQ monitoring. How do I get the metrics that I need to monitor? Many of these administrators have built their own scripts to gather data from WebSphere MQ but the process of correlating these MQ metrics with J2EE application performance metrics is often painstaking and messy.

See Figure 2

The administrator should monitor the Java connectors such as MQCCF (based on the Common Connector Framework) and MQJCA (based on the Java Connector Architecture) to ensure that the connection between the application and MQ is running smoothly with no bottlenecks affecting performance. The application administrator should also monitor WebSphere MQ components such as the Queue Manager, Queues, and Channels used by the application being monitored. This is to make sure the application messages are flowing smoothly across WebSphere MQ.

Messaging software such as WebSphere MQ can be shared between multiple applications. This poses an interesting problem for the application administrator. Administrators don't want to monitor every queue and channel in WebSphere MQ; they just want to monitor the queues that their application uses. So it's important for the monitoring software to enable administrators to filter the metrics they want to monitor by queues. The monitoring software should also be efficient in reporting static metrics that don't change. (For example, Queue Manager Name - it's not required to report the same value every monitoring cycle.)

Table 2 illustrates some of the key components of the messaging infrastructure for a given WebSphere MQ instance and their significance from an application monitoring perspective. Monitoring the performance of these components and having an understanding of their affect on overall application performance would enable an application administrator to communicate more effectively with an MQ administrator.

Collaborative and Consistent Monitoring
The fact that applications are becoming more complex and interconnected makes it difficult for one person or even a single IT team to manage the entire application environment. It's not uncommon to see various administrators working to ensure the availability of an IT application. For example, one person may be administering the application server, while a different person may be administering the messaging system. Moreover, QA managers will want to monitor the system during testing and then hand the monitoring task over to operators once the application has been deployed into production. The goals of each stakeholder are to ensure that their systems are up and running and successfully meeting performance and business objectives.

However, monitoring these components in isolation with different tools presents only a fraction of the whole picture and doesn't reveal any potential problems that can happen as a direct result of the way these components interact with each other in different environments (staging versus live production for example). For this reason, it's very important for these administrators to collaborate with each other by using a single performance management solution that can let them speak the same language and share the same data. This allows more constructive interactions, i.e., "The messaging system isn't working because this particular channel is down" as opposed to "The messages don't seem to be getting delivered."

Having a consistent mechanism for monitoring various application components is a first step towards effective communication. When administrators are monitoring applications, they shouldn't have to switch among multiple tools with different terminology or be required to use disparate tools that have been squeezed into same packaging (often the result of a poorly executed acquisition by an IT vendor). An administrator's life is hard and is becoming harder with the increasing complexity of applications. Adding extra tools can only make it worse.

Another key requirement for effective collaboration and information sharing is historical data analysis. An optimal monitoring solution would be able to store performance data for periods of up to a year so that capacity planners and application administrators can retrieve it whenever needed to perform trend analysis for future planning.

Conclusion
To ensure maximum availability, application administrators need to extend performance management visibility beyond the applications into systems such as WebSphere MQ, which are becoming increasingly important to enterprise IT organizations. When devising a monitoring strategy, IT teams should develop an understanding of how the application uses WebSphere MQ and then determine what components of the messaging infrastructure to monitor. An integrated management strategy that lets administrators monitor the entire composite application environment with one tool provides an effective means for detecting and diagnosing production problems and helps IT teams avoid playing the blame game when slowdowns occur.

Page 2 of 2   « previous page