Businesses rely on IBM MQ to transport data between the many disparate platforms commonly employed in data centers. IBM MQ is a rock-solid universal messaging backbone which assures delivery of every message. However, in today’s mission critical high-volume application environments, slowdowns and failures are possible. To address these cases, IBM recommends an enterprise MQ management solution to ensure that an organizations service level objectives are met.
Enterprise MQ management can be viewed in two distinct ways, resource management and observability. Resource management, where performance metrics detail the health of all IBM MQ objects, is vital in understanding the condition of the queue manager itself. This information must be provided for all platforms where IBM MQ is present. Additionally, at some level, a common user interface is necessary. The very nature of IBM MQ, delivering messages across disparate platforms, demands a monitoring perspective which can ‘show both sides’ of the application. Basic statistical data like the length of time a message spent on an application queue, dead letter queue depth, or channel status must be available for monitoring in real-time. Moving beyond the basic, complex high performance high availability implementations such as queue sharing groups in the z/OS couple facility must also be fully monitored. Below is an example, courtesy of OMEGAMON for Messaging on z/OS, displaying the status of coupling facility structures supporting queue sharing groups. This data is available in real-time and can be used to generate alerts.
A common customer requirement is the ability to identify queues which are not being serviced in a timely manner. OMEGAMON monitors the depth of queues in real-time, where threshold-based situations can generate alerts when thresholds are exceeded. Below we have an OMEGAMON situation that alerts when the queue named INSTANAQ1 has a current depth of greater than 10 messages, and no messages have been gotten from the queue for over 10 minutes.
Many pre-defined alert templates (prefixed MQSeries_ above) are delivered out of the box with OMEGAMON, providing a quick path to proactive monitoring.
Alert consolidation to a central management system is vital. OMEGAMON alerts have a built-in interface to Netcool, or any platform which accepts EIF formatted messages. Additionally, an open automation facility can be used to drive requests to any console or notification platform of your choosing. z/OS console automation is commonly used to capture alerts generated by z/OS OMEGAMON, which are then forwarded via site standard notification mechanisms.
IBM Instana Observability includes the capability to monitor IBM MQ on distributed platforms. IBM MQ objects such as queue managers, queues, connections, channels, topics, and more are monitored.
These resources can be used to generate alerts which can be forwarded to an event manager as needed. Instana agents collect the resource information displayed above, but the Instana UI features the ability to display selected metrics from z/OS queue managers as well. Using a relatively new OMEGAMON feature, OMEGAMON Data Provider, metrics are streamed in near real-time to Instana. The combination of these technologies afford a single UI the ability to display IBM MQ metrics across platforms.
Observability augments resource management by providing insight into the flow of a specific application. Application flow visualizations identify the behavior and slowdowns of an individual application. These views provide an end-to-end perspective of application performance.
In the example below, the Instana dependency view displays the topology and activity of the zEnterprise MQ application. When components of an application fall out of expected norm for designated metrics, the nodes of this display are augmented to reflect the poor performance.
To gain a deeper understanding of the application itself, Instana allows users to analyze calls and drill down to the application call stack. Below the calls for the zEnterprise application are displayed, with responsiveness of calls across all platforms being represented. The image below details calls from application initiation via HTTP Get, into the CICS regions running transactions making MQ Calls. Note that CICS function shipped I/O is also displayed below the MQ API calls shown in the stack.
Up to this point, we have focused on IBM MQ as a single entity. However, there are many aspects of applications which extend beyond IBM MQ. This is where IBM’s Z AIOps framework comes into play. The Z AIOps framework extends the reach of problem resolution to encompass all aspects of z/OS systems. Built on a mantra of ‘Detect – Decide – Act’, the Z AIOps framework provides a methodology and accompanying technologies to efficiently address problem resolution in z/OS environments. Learn more about AIOps on IBM Z solutions at https://ibm.biz/New-AIOps.
In summary, monitoring IBM MQ requires a blend of system resource monitoring and observability. All monitoring must be able to alert and drive notification to enterprise service management platforms. Finally, these capabilities must be available across the many platforms which IBM MQ is present in your environment.