Our enterprise integration platform currently runs on Mule Runtime 4.6.7 and includes critical workloads initiated through HTTP Listeners, Pollers, Schedulers and messaging queues. Instana currently provides infrastructure, JVM and partial generic messaging visibility; however, it does not provide the Mule-aware application and flow-level visibility required to effectively monitor and troubleshoot these workloads.
The current limitation prevents operations and SRE teams from automatically discovering Mule applications, identifying individual flows and subflows, monitoring scheduled or polling executions, and tracing transactions across HTTP endpoints, queues, databases and downstream services. It also makes it difficult to identify missed Scheduler executions, failed polling cycles, queue-processing delays, connector failures and the exact Mule component responsible for a transaction failure.
Native Mule 4.x support should provide:
- Automatic discovery of Mule runtimes, applications, APIs, flows and subflows.
- End-to-end tracing for HTTP Listener, Scheduler, Poller and queue-triggered flows.
- Visibility into Mule connector calls, including HTTP, database, JMS, file and SFTP operations.
- Distributed trace-context propagation across producers, queues, consumers and downstream services.
- Flow-level metrics for executions, processing time, errors, failures and throughput.
- Detection of missed, skipped, delayed or failed Scheduler and Poller executions.
- Queue-related visibility, including publishing, consumption, retries, redelivery and dead-letter processing.
- Correlation between Mule transactions, logs, errors and infrastructure metrics.
- Support for Mule correlation IDs and business transaction identifiers as searchable attributes.
- Dashboards and alerts that identify the affected Mule server, application, flow, connector and transaction.
Mule 4.x is widely used for business-critical API and integration workloads. Lack of native support creates a significant observability gap and requires customers to depend on generic Java instrumentation, custom metrics, log-based monitoring or separate monitoring platforms.
Providing native Mule 4.x support would enable complete application-performance monitoring, reduce mean time to detect and resolve incidents, improve operational reliability and strengthen Instana’s position as an enterprise observability platform for modern integration environments.
We request IBM to provide a supported Mule 4.x sensor or instrumentation capability, beginning with support for Mule Runtime 4.6.x and extending to currently supported Mule 4 releases. The implementation should provide functionality equivalent to, or greater than, the application and flow monitoring currently available for Mule 3.x.
Mule applications support critical integrations across APIs, databases, messaging platforms and downstream enterprise services. Without native Mule 4.x monitoring, incidents can be detected only at the JVM, infrastructure or generic messaging level, without identifying the affected Mule application, flow or component.
Native Mule 4.x support would reduce troubleshooting time, enable proactive alerting, eliminate the need for custom monitoring solutions and allow customers to standardize Mule observability within IBM Instana.
IBM Instana should automatically discover and monitor Mule 4.x runtimes, applications, APIs, flows and connectors and provide end-to-end traces for HTTP Listener, Scheduler, Poller and queue-triggered transactions. The solution should include flow-level performance metrics, error identification, trace and log correlation, distributed context propagation, dashboards and actionable alerts.
