• /
  • EnglishEspañolFrançais日本語한국어Português
  • EntrarComeçar agora

Monitor IBM MQ on Kubernetes with OpenTelemetry

When your IBM MQ queue managers run as pods in Kubernetes, you need a monitoring solution that can automatically discover and track them as your cluster scales. This guide shows you how to deploy a collector that finds your queue managers automatically and ships their metrics to New Relic without any manual configuration changes.

You can use either New Relic's Distribution of OpenTelemetry (NRDOT) or the OpenTelemetry Collector Contrib—both use the same configuration and auto-discovery approach. The collector discovers queue manager pods by annotation, gathers their metrics, and sends organized data to New Relic where it appears as IBMMQ_MANAGER and IBMMQ_QUEUE entities with ready-to-use dashboards. When you add new queue managers, the collector finds them automatically—no configuration updates needed.

Dica

If your queue managers run on traditional hosts instead, see Monitor self-hosted IBM MQ.

Before you begin

You'll need these components before setting up the collector:

Dica

We recommend enabling MQI statistics on your queue managers using ALTER QMGR STATMQI(ON) STATQ(ON) for better throughput metrics.

Set up IBM MQ monitoring

Follow these steps to deploy the collector and start shipping IBM MQ metrics to New Relic:

Create New Relic credentials secret

Create a Kubernetes Secret to store your New Relic credentials securely. The collector reads these values at runtime, keeping sensitive information out of configuration files.

  1. Ensure the ibmmq namespace exists:

    bash
    $
    kubectl get namespace ibmmq >/dev/null 2>&1 || kubectl create namespace ibmmq
  2. Create the credentials secret, replacing <YOUR_LICENSE_KEY> with your actual license key:

    bash
    $
    kubectl create secret generic newrelic-otlp-secret \
    >
    --namespace ibmmq \
    >
    --from-literal=NEW_RELIC_LICENSE_KEY="<YOUR_LICENSE_KEY>" \
    >
    --from-literal=NEW_RELIC_OTLP_ENDPOINT="https://otlp.nr-data.net:4318" \
    >
    --dry-run=client -o yaml | kubectl apply -f -

    For EU accounts, use https://otlp.eu01.nr-data.net:4318 as the endpoint value.

Configure collector Helm values

Create a local values.yaml file with the collector configuration. This file contains all settings needed to deploy the collector via the OpenTelemetry Helm chart.

Cuidado

Don't change TARGET_NAME after the initial deployment. This value forms the first segment of every IBMMQ_MANAGER and IBMMQ_QUEUE entity GUID. Changing it creates new entities and orphans existing ones, breaking dashboards and alerts.

What this configuration does

This configuration creates an auto-discovery pipeline that finds IBM MQ queue manager pods and ships their metrics to New Relic. The processing pipeline is identical to the host setup, but uses pod auto-discovery instead of static targets:

SectionRole
prometheus/ibmmq receiverAutomatically discovers queue manager pods in the ibmmq namespace that have the required annotations. Connects to each pod's metrics endpoint and gathers IBM MQ data every 60 seconds.
filter/ibmmq-overheadRemoves the exporter's internal self-metrics (such as go_* and process_*) that don't contain IBM MQ data, optimizing data ingestion costs.
filter/ibmmq-queuesExcludes internal IBM MQ system queues (SYSTEM.* and AMQ.*) so that only application queues become entities in New Relic.
transform/ibmmq-cleanupCritical component that maps metrics to the appropriate IBM MQ entities in New Relic. Without this, data appears as generic collector metrics instead of IBMMQ_MANAGER and IBMMQ_QUEUE entities with dashboards and alerts.
memory_limiter/ibmmqLimits memory usage to 400MB (below the 512Mi container limit) to prevent the collector pod from being killed by Kubernetes.
batch/ibmmqGroups metrics together before transmission to reduce network overhead by bundling up to 1000 data points per request.
otlphttp/ibmmq exporterExports processed metrics to New Relic using your license key for authentication and the configured regional endpoint.

Important Kubernetes settings:

SettingWhy it's required
replicaCount: 1With kubernetes_sd and no TargetAllocator, every replica scrapes every target, so more than one replica double-counts (and double-bills) metrics. For HA, shard targets with the OpenTelemetry TargetAllocator.
mode: deployment (not daemonset)A DaemonSet runs kubernetes_sd on every node and produces N copies of every metric for an N-node cluster.
clusterRole.create: truekubernetes_sd needs get/list/watch on pods; without it the API returns 403 Forbidden and the receiver discovers zero targets (the collector starts but emits nothing).
service.enabled: falseThis collector has no inbound receivers, so the chart would otherwise try to create a zero-port Service and fail at install time. Self-telemetry on :8888 is still reachable via kubectl port-forward.
replacement: $$1:$$2 (relabel rule 4)The $$ escapes the OTel config loader's ${...} env-var expansion so the Prometheus engine receives the literal $1:$2 capture-group syntax. A single $1:$2 would be consumed as an empty env var and break address construction.
image.tag: "latest"Good for testing; use a specific version for production.

Install collector with Helm

Add the OpenTelemetry Helm repository and install the collector into the ibmmq namespace using the values.yaml you created in the previous step:

bash
$
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
$
helm repo update
$
$
helm upgrade --install ibmmq-collector open-telemetry/opentelemetry-collector \
>
--namespace ibmmq \
>
--create-namespace \
>
--values values.yaml

If the collector pod doesn't reach 1/1 Running, see Troubleshooting below.

Verify the deployment

Confirm the collector pod is running:

bash
$
kubectl -n ibmmq rollout status deploy/ibmmq-collector-opentelemetry-collector --timeout=180s
$
kubectl -n ibmmq get pods

The collector pod should show 1/1 Running. To confirm it is actually discovering and scraping pods, port-forward its self-telemetry endpoint (exposed on :8888, reachable only via port-forward because the inbound Service is disabled) and check the accepted/exported counters:

bash
$
kubectl -n ibmmq port-forward deploy/ibmmq-collector-opentelemetry-collector 8888:8888 &
$
curl -s http://localhost:8888/metrics | \
>
grep -E 'otelcol_(receiver_accepted|exporter_sent|exporter_send_failed)_metric_points'
$
kill %1 2>/dev/null

otelcol_receiver_accepted_metric_points greater than 0 confirms the collector found and scraped at least one annotated Running pod; otelcol_exporter_send_failed_metric_points should stay at 0 (any non-zero value points to an OTLP connection or credentials problem).

Then confirm IBM MQ metrics and entities in New Relic using the verification queries in find and query your data. For the meaning of status values, see the MQ status-code reference.

View your data in New Relic

Once your collector pod is running and metrics are flowing, you'll see your queue managers as IBMMQ_MANAGER entities in New Relic, with their queues as child IBMMQ_QUEUE entities. For details on finding your data, running queries, and setting up dashboards and alerts, see View and query your data.

Metrics reference

Learn about the IBM MQ OpenTelemetry metrics available in New Relic.

View and query your data

Learn how to view and query your IBM MQ data in New Relic.

Troubleshooting

Learn how to troubleshoot IBM MQ monitoring issues in New Relic.

Copyright © 2026 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.