IBM MQ en production : 5 erreurs fréquentes et comment les résoudre

Que vous administriez IBM MQ depuis des années ou que vous débutiez votre première installation, certaines erreurs reviennent inlassablement en production. Voici cinq situations que j’ai rencontrées régulièrement — certaines classiques, une qui m’a donné plusieurs jours de recherche en contexte OpenShift.

1. Le channel qui ne démarre pas

Symptôme : un channel reste en statut STOPPED ou RETRYING sans raison apparente. Les applications ne peuvent plus se connecter.

Causes fréquentes :

Certificat SSL expiré ou mal configuré côté SSLCIPH
Mauvais CONNAME (IP ou hostname incorrect)
Le listener n’est pas démarré
Problème de résolution DNS

Diagnostic :

DISPLAY CHSTATUS(*)

Pour comprendre la cause exacte, consulter les logs du Qmgr :

tail -100 /var/mqm/qmgrs/QMGRNAME/errors/AMQERR01.LOG

Les messages d’erreur IBM MQ sont précis — ils indiquent généralement la nature exacte du problème (SSL, réseau, authentification).

Solution : selon la cause — renouveler le certificat, corriger le CONNAME, démarrer le listener, ou vérifier la résolution DNS. Pour redémarrer un channel serveur :

START CHANNEL(MY.CHANNEL)

Pour un channel client, le redémarrage se fait côté application — relancer le processus client qui initie la connexion.

2. La Dead Letter Queue qui se remplit

Symptôme : la DLQ grossit, les messages n’atteignent pas leur destination. Les applications en aval ne reçoivent rien.

Premier réflexe — vérifier l’espace disque : une DLQ qui se remplit est souvent le symptôme d’un filesystem saturé, ou d’un PVC sous-dimensionné sur OpenShift.

# On-premise
df -h /var/mqm

# OpenShift — vérifier la taille du PVC
oc get pvc
oc describe pvc <nom-du-pvc>

Si l’espace n’est pas le problème, analyser le DLQREASON dans les messages pour comprendre pourquoi ils tombent en DLQ. Les raisons fréquentes :

MQRC_UNKNOWN_OBJECT_NAME : la queue de destination n’existe pas ou est mal nommée
MQRC_Q_FULL : la queue de destination est pleine (voir point suivant)
MQRC_NOT_AUTHORIZED : problème d’autorisation

Rejouer les messages : deux approches selon le volume et la criticité.

Pour quelques messages, un outil de browsing MQ permet de les parcourir et de les rediriger manuellement.

Pour un traitement automatisé, le DLQ Handler est la solution appropriée — il traite les messages selon des règles définies dans un fichier de configuration :

ACTION(RETRY)
INPUTQ(SYSTEM.DEAD.LETTER.QUEUE)
REASON(MQRC_Q_FULL)
DESTQ(MY.QUEUE)
RETRYCOUNT(3)

Le DLQ Handler est particulièrement utile en production pour éviter une intervention manuelle à chaque incident.

3. La file depth qui explose (QFULL)

Symptôme : une ou plusieurs queues atteignent leur MAXDEPTH. Les applications productrices reçoivent un MQRC_Q_FULL. La file depth monte en flèche dans le monitoring.

Premier réflexe — espace disque : même réflexe que pour la DLQ. Vérifier que le filesystem ou le PVC n’est pas saturé avant d’investiguer plus loin.

Diagnostic :

DISPLAY QSTATUS(*) TYPE(QUEUE) WHERE(CURDEPTH GT 0)

Pour identifier si des consommateurs sont actifs sur la queue, vérifier IPPROCS (nombre de processus en GET / lecture) et OPPROCS (nombre de processus en PUT / écriture) :

DISPLAY QSTATUS(MY.QUEUE) IPPROCS OPPROCS CURDEPTH

IPPROCS = 0 → aucun consommateur actif, c’est probablement la cause
OPPROCS élevé avec IPPROCS faible → le débit entrant dépasse le débit de traitement

Solution :

Relancer l’application consommatrice si elle est arrêtée
Augmenter le nombre de threads consommateurs si le débit est insuffisant
Augmenter temporairement le MAXDEPTH si le volume est exceptionnel
Revoir l’architecture si le problème est récurrent (scaling, parallélisation des consumers)

Sur OpenShift, vérifier également que le pod de l’application consommatrice tourne bien :

oc get pods -n <namespace>
oc logs <pod-consommateur>

4. Les paramètres sous-dimensionnés — le piège du MAXMSGL

Symptôme : les performances se dégradent en charge, ou des messages sont rejetés avec MQRC_MSG_TOO_BIG_FOR_Q alors que la queue semble correctement configurée.

Ce dernier cas est particulièrement traître. MAXMSGL se configure à plusieurs niveaux : le Qmgr, le channel, la transmission queue (XMITQ), et la queue de destination. Il suffit qu’un seul de ces objets ait une valeur trop basse pour que le message soit bloqué — même si tous les autres sont correctement dimensionnés.

C’est une erreur fréquente lors des mises en place initiales : on configure le MAXMSGL sur la queue de destination, mais on oublie de l’aligner sur le channel ou la XMITQ. Résultat : les petits messages passent, les gros sont rejetés, et le diagnostic n’est pas immédiat.

Vérification systématique :

DISPLAY QMGR MAXMSGL
DISPLAY CHANNEL(MY.CHANNEL) MAXMSGL
DISPLAY QL(MY.XMITQ) MAXMSGL
DISPLAY QL(MY.QUEUE) MAXMSGL

Tous ces objets doivent avoir une valeur cohérente avec la taille maximale des messages de vos applications.

Alignement :

ALTER QMGR MAXMSGL(104857600)
ALTER CHANNEL(MY.CHANNEL) MAXMSGL(104857600)
ALTER QL(MY.XMITQ) MAXMSGL(104857600)
ALTER QL(MY.QUEUE) MAXMSGL(104857600)

Bonne pratique : documenter les paramètres de production dans un script MQSC versionné. En cas de reconstruction du Qmgr, vous retrouvez votre configuration exacte en quelques minutes — et vous ne risquez pas d’oublier un objet.

5. Le Qmgr qui redémarre aléatoirement sur OpenShift — le cas PID limit

C’est le problème qui m’a donné le plus de fil à retordre lors d’une migration IBM MQ vers OpenShift (Azure Red Hat OpenShift).

Symptôme : le pod du Qmgr redémarre de manière apparemment aléatoire. Pas de pattern clair au début — parfois en charge, parfois au repos. Les applications perdent leur connexion, le Qmgr repart, tout semble normal.

La fausse piste : on pense d’abord à un problème réseau, un OOMKill, ou un bug de la version MQ. Les logs post-restart ne montrent rien d’anormal car le Qmgr a eu le temps de redémarrer et de libérer ses ressources.

L’indice clé : en capturant les FDC files au moment du crash, avant le restart complet :

AMQ6119E: An error occurred in a thread creation operation.
11 - EAGAIN - Resource temporarily unavailable from pthread_create

EAGAIN sur pthread_create signifie que le système ne peut plus créer de nouveau thread. Le Qmgr IBM MQ est très gourmand en threads — chaque channel actif, chaque connexion, chaque opération interne en consomme.

La cause : sur OpenShift, chaque Worker Node a une limite sur le nombre de PIDs (et donc de threads) par pod — pids_limit. La valeur par défaut peut être insuffisante pour un Qmgr MQ actif en production.

Le Qmgr consomme progressivement les threads disponibles jusqu’à atteindre la limite. Il ne peut plus créer de nouveaux threads → crash → restart → les threads se libèrent → le cycle recommence. Ce qui rend ce bug particulièrement vicieux : le symptôme disparaît au moment où on peut investiguer.

La solution : augmenter le pids_limit sur les Worker Nodes OpenShift qui hébergent le Qmgr. La procédure complète est documentée par IBM :

👉 Adjusting PID limits on OpenShift for IBM MQ

En pratique, on crée un MachineConfig pour modifier le paramètre sur les nodes concernés :

$ cat pidworker.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: overlay-size
spec:
machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: ''
containerRuntimeConfig:
   pidsLimit: 4096

$ oc create -f pidworker.yaml

Before the change
-----------------
sh-4.4$ cat /sys/fs/cgroup/pids/pids.max
1024

After the change
----------------
sh-4.4$ cat /sys/fs/cgroup/pids/pids.max
4096

En résumé

Problème	Symptôme clé	Premier diagnostic
Channel qui ne démarre pas	STOPPED / RETRYING	`DISPLAY CHSTATUS + AMQERR01.LOG`
DLQ qui se remplit	Messages perdus en aval	Espace disque / PVC → DLQREASON
QFULL	MQRC_Q_FULL côté applicatif	`DISPLAY QSTATUS + IPPROCS / OPPROCS`
MAXMSGL mal aligné	Messages rejetés en charge	Vérifier QMGR + CHANNEL + XMITQ + QUEUE
PID limit sur OpenShift	Restart aléatoire du pod	FDC : EAGAIN pthread_create

Ces cinq situations couvrent une grande partie des incidents IBM MQ que vous rencontrerez en production. Si vous êtes confronté à l’un d’eux dans un environnement critique et que vous avez besoin d’un appui, contactez-moi — c’est exactement le type de mission sur lequel j’interviens en régie.