WebSphere MQ Observability | Germain Documentation

ℹ️ IBM MQ Observability

GermainUX monitors the availability, performance, capacity, and operational health of IBM MQ, formerly known as WebSphere MQ.

It helps teams detect queue backlogs, aging messages, unavailable queue managers, stopped channels, connection problems, resource constraints, and messaging failures before they significantly affect applications and business processes.

📈 Business outcomes

Outcome	How GermainUX helps
Protect business-process continuity	Detect messaging conditions that can delay or stop orders, payments, reservations, integrations, and other critical transactions.
Reduce message-processing delays	Identify increasing queue depth, message age, and queue time.
Improve reliability	Monitor queue managers, queues, channels, listeners, logs, and supporting infrastructure.
Accelerate incident resolution	Correlate IBM MQ conditions with applications, integrations, logs, hosts, and business processes.
Prevent capacity incidents	Detect queues, filesystems, connections, and system resources approaching operational limits.
Prioritize issues	Rank conditions according to duration, recurrence, affected services, and business impact.
Automate operations	Notify teams and execute approved diagnostic or remediation actions when defined conditions occur.

🔎 Monitoring coverage

Monitoring availability depends on the IBM MQ version, operating system, enabled administrative interfaces, permissions, and GermainUX configuration.

⚙️ Queue managers

GermainUX can monitor:

Item
Queue-manager availability and operating status
Queue-manager uptime
Local and remote connectivity
Command execution failures
Connection and authentication problems
Queue-manager errors detected in accessible logs
Repeated stops, starts, or unexpected status changes

📥 Queues and messages

Metric or condition	Purpose
Queue depth	Identifies messages waiting to be consumed and potential processing backlogs.
Maximum queue depth	Provides context for queue-capacity and queue-full risks.
Queue utilization	Measures current depth as a percentage of the configured capacity.
Queue time	Measures how long messages remain in a queue before being processed when the required data is available.
Oldest-message age	Identifies messages that have remained unprocessed beyond an acceptable duration.
Put and get activity	Helps identify changes in producer and consumer activity when IBM MQ exposes the required statistics.
Put or get inhibition	Detects queues that are not accepting or delivering messages as expected.
Dead-letter queue depth	Identifies messages that could not be delivered to their intended destination.
Message persistence and size	Provides additional context when exposed by the configured IBM MQ data source.

Thresholds should be configured for each queue according to its normal workload and business purpose. A queue depth of zero may be expected for one queue, while a persistent backlog may be normal for another.

🔗 Channels and listeners

Depending on the configured monitoring access, GermainUX can monitor:

Item
Channel status
Sender and receiver channel availability
Repeated channel retries
Stopped or inactive channels
Connection failures
Listener availability
Transmission-queue depth
Last message or channel activity
Channel errors found in IBM MQ logs

An inactive channel is not always an error. Configure SLAs according to the expected channel type, schedule, workload, and business requirements.

📄 Logs and errors

Configure File and Log Monitoring for accessible IBM MQ error and operational logs.

GermainUX can detect and categorize events such as:

Event
Queue-manager startup or shutdown failures
Channel and listener errors
Queue-full conditions
Authentication and authorization failures
Connection failures
Undelivered messages
Disk and filesystem problems
Damaged objects or recovery problems
Repeated warning or error codes
Unusual changes in error volume

Log availability and location depend on the operating system, IBM MQ version, and deployment configuration.

🖥️ Infrastructure

Extend IBM MQ monitoring to its supporting environment using:

Integration
AIX Monitoring
Linux Monitoring
Windows Monitoring
Docker Monitoring
Kubernetes Monitoring
Network Monitoring

Relevant infrastructure metrics can include:

Metric
CPU and memory utilization
Disk and filesystem capacity
Network connectivity
IBM MQ processes
Container and pod health
Process restarts
File-descriptor and connection limits

🚚 Collection methods

The GermainUX Engine supports local and remote IBM MQ monitoring.

🏠 Local monitoring

Use local monitoring when the GermainUX Engine runs on the IBM MQ server and has permission to execute the required IBM MQ status and administrative commands.

🔒 Remote monitoring through SSH

Use SSH monitoring when the GermainUX Engine runs on another server.

The configured account must:

Requirement
Be authorized to connect to the IBM MQ server
Have only the permissions required to execute approved monitoring commands
Have read-only access wherever possible
Be protected according to the organization’s credential-management requirements

See SSH Execution for related GermainUX configuration.

📋 Logs and external metrics

IBM MQ data can also be collected from:

Source
Accessible IBM MQ logs
Customer-provided scripts
Authorized administrative endpoints
Prometheus-compatible metrics when an appropriate IBM MQ exporter is deployed
Infrastructure and container platforms
Application and integration telemetry

See Prometheus Metrics Monitoring when Prometheus-compatible metrics are available.

🔗 Business-process correlation

IBM MQ typically supports transactions spanning multiple applications and integrations. GermainUX can correlate messaging conditions with other monitored activity when the required identifiers and data sources are available.

Examples include:

Example
Order submitted but not processed
Payment request delayed in a queue
Reservation message not consumed
Customer update waiting for a downstream system
Integration failure associated with a stopped channel
Business-process delay associated with increasing message age
Application errors occurring during an IBM MQ incident

Correlation can use timestamps, queue names, application names, transaction identifiers, message identifiers, correlation identifiers, or customer-defined attributes when those values are accessible and approved for collection.

📉 Analytics and outlier detection

GermainUX Analytics and outlier detection can identify:

Detection
Unusual increases in queue depth
Abnormal message age
Changes in producer or consumer activity
Repeated queue-manager or channel instability
New IBM MQ errors
Resource patterns associated with messaging degradation
Queues behaving differently from their historical baseline
Relationships between IBM MQ degradation and application or business-process failures

Thresholds and baselines should reflect the workload pattern of each queue manager, queue, channel, and environment.

🚨 Alerts

Configure alerts for conditions such as:

Condition
Queue manager unavailable
Queue depth above an approved threshold
Queue approaching maximum capacity
Oldest message exceeding its processing SLA
Dead-letter queue receiving messages
Channel or listener unavailable
Repeated channel retries
Authentication or connection failures
IBM MQ errors detected in logs
Disk or filesystem capacity risk
Failed synthetic messaging transaction

Notifications can be delivered through email or SMS, Slack, ServiceNow, or other configured integrations.

🤖 Automated actions

GermainUX Automation can execute customer-defined and approved actions, including:

Action
Collecting current queue-manager, queue, and channel status
Capturing recent IBM MQ errors
Retesting connectivity
Creating or updating an incident
Calling an authorized HTTP endpoint
Executing an approved script
Running a permitted command through SSH
Notifying an application or integration owner

Actions that start or stop queue managers, channels, listeners, or other IBM MQ resources must be explicitly authorized, tested, and protected by appropriate operational controls. Avoid automated actions that could interrupt message processing or cause duplicate transaction execution.

🔧 Configuration

Prerequisites

Before configuring IBM MQ monitoring:

Identify the queue managers, queues, channels, listeners, and logs to monitor.
Document the expected workload and availability requirements.
Select local or remote monitoring.
Create a least-privilege monitoring account.
Confirm that the GermainUX Engine can access the IBM MQ server.
Identify the applications and business processes that depend on IBM MQ.
Define which identifiers may be collected for correlation.
Identify maintenance and batch-processing schedules.

⚙️ Configure the monitor

In GermainUX:

Go to Workspace > Settings > Wizards.
Select Monitor Server.
Select the monitoring node and GermainUX Engine.
Select the applicable IBM MQ Monitor:
- IBM MQ Monitor—Local
- IBM MQ Monitor—SSH
Select or create the monitored IBM MQ server.
Select the required credentials for remote monitoring.
Enter the queue-manager and monitoring configuration.
Select the queues, channels, or objects to monitor.
Configure the execution schedule and timeout.
Review and submit the monitor.
Confirm that the component is running and producing data.

The exact fields depend on the selected component type and installed GermainUX version.

🏆 Configure KPIs and SLAs

Configure KPIs and SLAs for the IBM MQ objects important to the environment.

KPI	Example SLA
Queue-manager availability	Queue manager must be available during its service window.
Queue depth	Depth must remain below the approved queue-specific threshold.
Queue utilization	Queue must remain below the approved percentage of maximum capacity.
Oldest-message age	Oldest message must remain below the business-processing SLA.
Queue time	Message-processing time must remain below the approved threshold.
Dead-letter queue depth	Alert when new messages appear or the depth increases.
Channel availability	Required channels must be running during their expected service window.
Error volume	Alert when critical or unusual IBM MQ errors are detected.

Use queue-specific thresholds rather than applying the same threshold to every queue.

✅ Validate the configuration

After deployment:

Confirm that every expected queue manager is visible.
Verify queue depth against an authorized IBM MQ administrative view.
Confirm that oldest-message age and queue time are interpreted correctly.
Validate channel and listener status.
Confirm that IBM MQ logs are being read from the correct locations.
Verify host or container telemetry when configured.
Generate a controlled test message and confirm that the expected metrics change.
Test alerts using safe thresholds or a non-production environment.
Verify application and business-process correlation.
Confirm that maintenance periods suppress expected operational alerts.

🔒 Security considerations

Consideration
Use a dedicated, least-privilege monitoring account.
Prefer read-only administrative access.
Protect SSH keys, passwords, and IBM MQ credentials in GermainUX credential storage.
Restrict network access to the required IBM MQ and SSH endpoints.
Do not collect message payloads unless explicitly required and approved.
Mask or exclude sensitive message identifiers and attributes.
Review logs for personal, financial, authentication, or regulated information.
Limit automated actions to approved commands and resources.
Audit changes to IBM MQ monitoring and automation configuration.

See Compliance, Privacy, and Security.

🚀 Deployment and configuration

For your IBM MQ environment
Deploy or select a GermainUX Engine with access to the IBM MQ environment.
Select local monitoring or remote monitoring through SSH.
Configure the queue managers, queues, channels, listeners, and service windows to monitor.
Configure File and Log Monitoring for accessible IBM MQ logs.
Configure the applicable AIX, Linux, Windows, Docker, Kubernetes, and network monitoring.
Define queue-specific KPIs and SLAs for depth, utilization, message age, processing time, availability, and errors.
Configure automated analytics and outlier detection.
Correlate IBM MQ conditions with dependent applications, integrations, and business processes.
Configure alerts, incident integrations, and approved automated actions.
Define maintenance windows for planned IBM MQ, application, and infrastructure changes.
Validate collection, thresholds, alerts, correlations, and automation in a safe environment.

Component requirements and monitoring coverage depend on the IBM MQ version, operating system, permissions, enabled statistics, accessible logs and interfaces, and desired monitoring depth.

ℹ️ Get More Information

GermainUX can help determine which monitoring, analytics and automation capabilities are appropriate for your WebSphere environment.

Contact GermainUX Support.

Component: Engine, JS Profiler, Mobile App, RPA Bot Recorder, RUM JS

Feature Availability: 2015.4