Les sections suivantes expliquent en détail les problèmes fréquemment identifiés par les contrôles post-mise à niveau ou qu’on observe juste après une mise à niveau.

Pour plus d’informations sur les contrôles post et pré-mise à niveau, consultez la section Référence de la mise à niveau.

Les services ne fonctionnent pas

L’interface utilisateur Web du RMT est inaccessible, et la commande rmtadmin status montre que les services requis se sont arrêtés.

Ce problème est détecté grâce aux contrôles post-mise à niveau n° 1, n° 2 et n° 16

Pour le résoudre, procédez comme suit :

Pour Linux, utilisez la commande suivante :

sudo -u tabrmt-master XDG_RUNTIME_DIR=/run/user/$(id -u tabrmt-master) systemctl --user start tabrmt-master

Pour Windows, utilisez la commande suivante :

Start-Service TableauResourceMonitoringTool

Recherchez les erreurs de démarrage dans les fichiers journaux de service du répertoire des journaux.

PostgreSQL n’accepte pas les connexions

Lorsque l’interface utilisateur Web affiche des erreurs au niveau de la base de données et que les données ne sont pas stockées.

Ce problème est détecté grâce aux contrôles post-mise à niveau n° 5c et n° 6

Pour le résoudre, procédez comme suit :

• Vérifiez que le service PostgreSQL fonctionne

• Recherchez les erreurs de démarrage dans les fichiers journaux PostgreSQL du répertoire de données

• Vérifiez que le port de base de données (5555 par défaut) n’est pas bloqué par un autre processus

RabbitMQ ne répond pas

Les Agents s’affichent comme étant déconnectés et aucune nouvelle donnée de surveillance n’apparaît.

Ce problème est détecté grâce aux contrôles post-mise à niveau n° 5b, n° 7 et n° 9

Pour le résoudre, procédez comme suit :

• RabbitMQ peut prendre de 30 à 60 secondes à s’initialiser complètement après une mise à niveau — attendez, puis vérifiez de nouveau

• Vérifiez que le processus Erlang/beam s’exécute

• Vérifiez s’il y a des alarmes de ressources RabbitMQ (un espace disque inférieur à 10 Go bloque toute publication de messages)

• Vérifiez que le fichier témoin Erlang existe et qu’il dispose des autorisations appropriées

File d’attente des messages

Les données apparaissent de manière différée dans l’interface utilisateur Web de RMT et les tableaux de bord affichent des métriques obsolètes.

Ce problème est détecté grâce au contrôle post-mise à niveau n° 8.

Il est normal qu’il y ait une file d’attente juste après une mise à niveau, car les agents se reconnectent et renvoient les données mises en mémoire tampon. Pour le résoudre, procédez comme suit :

• Surveiller avec la commande « rmtadmin status » : la file d’attente devrait disparaître au bout de 15 à 30 minutes

• Si la file d’attente ne disparaît pas, vérifiez que tous les services des agents fonctionnent et sont bien connectés

Les workers du serveur RMT ne consomment pas les données (aucune donnée ingérée après la mise à niveau)

Tous les services RMT sont « En marche », le contrôle post-mise à niveau valide les services, les ports et la connectivité, mais l’interface utilisateur Web n’affiche aucune nouvelle donnée et les agents présentent un « Problème de connexion ». La commande `rmtadmin status` affiche une ou plusieurs files d’attente avec des messages qui s’empilent, et un nombre de consommateurs de **0**.

Cela se produit lorsque les workers en arrière-plan du serveur RMT démarrent, mais qu’ils n’arrivent pas à reconnecter leurs réseaux de consommation RabbitMQ après une mise à niveau sur place. Les agents publient avec succès, les messages s’accumulent dans RabbitMQ, mais rien n’entre dans la base de données.

Ce problème est détecté grâce au contrôle post-mise à niveau n° 8a

Pour le résoudre, procédez comme suit :

• Redémarrez le contrôleur : `rmtadmin restart`

• Attendez environ 60 secondes, puis exécutez à nouveau la commande `rmtadmin status` — les files d’attente bloquées devraient maintenant afficher `Consumers = 1` et se vider en quelques minutes

• Si les files d’attente affichent toujours `Consumers = 0` après le redémarrage, examinez le journal d’arrière-plan à la recherche d’exceptions concernant la connexion des consommateurs :

• Windows : `C:\Program Files\Tableau\Tableau Resource Monitoring Tool\master\logs\background\*.log`

• Linux : `/var/opt/tableau/tabrmt/master/logs/background/*.log`

• Vérifier le fichier journal `exception`, `channel` ou `binding failed`

Discordance du mode FIPS

Lorsque les services ne démarrent pas à cause d’erreurs cryptographiques ou d’erreurs TLS.

Ce problème est détecté grâce au contrôle post-mise à niveau n° 11

Pour le résoudre, procédez comme suit :

• Vérifiez que le paramètre FIPS sur le système d’exploitation correspond à la configuration RMT (`isFIPSEnabled` dans setup.json)

• Linux : vérifier `/proc/sys/crypto/fips_enabled`

• Windows : vérifier `HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled`

Corruption du fichier de configuration

Les services ne démarrent pas à cause d’erreurs d’analyse JSON.

Ce problème est détecté grâce au contrôle post-mise à niveau n° 3

Pour le résoudre, procédez comme suit :

• Valider le fichier de configuration : `python3 -c "import json; json.load(open('config.json'))"`

• Restaurez à partir d’une sauvegarde antérieure à la mise à niveau (recommandé avant chaque mise à niveau)

Certificat SSL expiré ou sur le point d’expirer

Lorsque le navigateur Web affiche des avertissements de certificat et que les agents n’arrivent pas à se connecter à cause d’erreurs TLS.

Ce problème est détecté grâce aux contrôles post-mise à niveau n° 10 et n° 13

Pour le résoudre, procédez comme suit :

• Renouveler le certificat HTTPS et mettez-le à jour à l’aide de `rmtadmin set-ssl-certificate`

• Pour les certificats RabbitMQ, remplacer les fichiers PEM dans le répertoire des certificats, puis redémarrer le service

Insuffisance de l’espace disque

Lorsque les services tombent en panne ou n’arrivent pas à écrire des données, et que les fichiers journaux contiennent des erreurs de base de données.

Ce problème est détecté grâce au contrôle post-mise à niveau n° 14 et aux contrôles pré-mise à niveau n° 2 et n° 2b

Pour le résoudre, procédez comme suit :

• Libérer de l’espace disque ou augmenter le volume

• Exécuter un nettoyage de la base de données : vérifier que `db:cleanup:type` est défini sur `Purge` (pas `None`) dans le fichier config.json

• Archiver ou supprimer d’anciens fichiers journaux

Erreurs FATALES ou CRITIQUES dans les fichiers journaux

Comportement indésirable ou services instables après la mise à niveau.

Ce problème est détecté grâce au contrôle post-mise à niveau n° 15

Pour le résoudre, procédez comme suit :

• Les erreurs « Broker unreachable » immédiatement après une mise à niveau sont généralement temporaires. Vérifier que RabbitMQ est en cours d’exécution

• Pour d’autres erreurs FATALES, examiner l’entrée complète du fichier journal et contacter l’assistance Tableau ainsi que le fichier journal

Déconnexions de l’agent après la mise à niveau du serveur RMT

Les agents apparaissent comme déconnectés dans l’interface utilisateur Web de RMT. Il n’y a aucune donnée de surveillance provenant de nœuds Tableau Server spécifiques.

Ce problème est détecté grâce aux contrôles pré-mise à niveau n° 36b, n° 36c et n° 36d

Les agents se reconnectent automatiquement une fois la mise à niveau du serveur RMT terminée. Attendez 5 à 10 minutes pour que ce problème soit résolu. Sinon, vérifiez les points suivants :

• Vérifier que le service d’agent s’exécute sur chaque hôte de l’agent

• Mettre à niveau les agents pour qu’ils correspondent à la version du serveur RMT s’ils exécutent une version beaucoup plus ancienne

• Vérifier la connectivité réseau (port AMQP 5672) entre les hôtes de l’agent et du serveur RMT

Régression vers une version connue comme étant défectueuse

Lorsque certaines fonctionnalités ne fonctionnent pas à cause d’un défaut connu dans la version installée.

Ce problème est détecté grâce au contrôle pré-mise à niveau n° 36a

Pour le résoudre, procédez comme suit :

• Mettre à niveau vers la prochaine version de correctif (par exemple, de 2025.3.0 à 2025.3.1+)

• Contacter l’assistance Tableau pour obtenir des correctifs spécifiques à une version

Le nettoyage Hangfire ne fonctionne pas (W-19380780)

La base de données grossit continuellement et le schéma hangfire est anormalement volumineux (>1 Go).

Ce problème est détecté grâce aux contrôles pré-mise à niveau n° 21d et n° 21g

Pour le résoudre, procédez comme suit :

• La mise à niveau vers une version corrigée rétablit le bon fonctionnement de delete_hash()

• Les lignes orphelines dans le schéma hangfire peuvent nécessiter un nettoyage manuel. Contactez l’assistance Tableau.

Le nettoyage de la base de données est désactivé

La taille de la base de données augmente indéfiniment au fil du temps et la mise à niveau ralentit.

Ce problème est détecté grâce au contrôle pré-mise à niveau n° 21c

Pour le résoudre, procédez comme suit :

• Définir db:cleanup:type sur Purge dans le fichier config.json

• Réduire db:cleanup:afterDays à 30-90 jours (valeur par défaut : 14)

• Redémarrer le service RMT Director pour que le changement s’applique

Problèmes au niveau des autorisations de fichier

Les services ne démarrent pas ou ne peuvent pas lire la configuration ni écrire les fichiers journaux.

Ce problème est détecté grâce au contrôle post-mise à niveau n° 4 et aux contrôles pré-mise à niveau n° 11 et n° 16

Pour le résoudre, procédez comme suit :

• Linux : vérifiez à qui appartiennent les répertoires de configuration, de fichiers journaux et de données et leur appartenance aux groupes

• Windows : vérifiez que le compte de service a un accès en lecture et en écriture aux répertoires d’installation

• Contacter l’assistance Tableau si les problèmes d’autorisation persistent après une nouvelle installation

Processus RMT bloqués après rmtadmin stop

Après avoir exécuté rmtadmin stop conformément à la procédure de mise à niveau documentée, un ou plusieurs processus tabrmt-master, tabrmt-master-background, tabrmt-agent ou tabrmt-agent-background continuent de fonctionner. Si la mise à niveau se poursuit dans cet état, le programme d’installation peut s'interrompre en cours d’exécution à cause d’erreurs de fichiers utilisés.

Ce problème est détecté grâce au contrôle pré-mise à niveau n° 38a

Pour le résoudre, procédez comme suit :

• Patienter environ 30 secondes pour un arrêt progressif, puis réexécuter le contrôle pré-mise à niveau

• Si les processus persistent :

• Linux : `pkill -u tabrmt-master -f tabrmt-master ; pkill -u tabrmt-agent -f tabrmt-agent` (ignorer celles qui ne concernent pas ce nœud)

• Windows : `Stop-Process -Name tabrmt-master,tabrmt-master-background,tabrmt-agent,tabrmt-agent-background -Force`

• Réexécuter le contrôle pré-mise à niveau pour confirmer que l’état est propre avant de démarrer la mise à niveau

Fausses erreurs lors des mises à niveau co-localisées

Si votre serveur principal RMT et votre agent RMT sont co-localisés sur le même ordinateur, le contrôle pré-mise à niveau de l’Agent (surtout le contrôle n° 38a) peut détecter par erreur des processus du serveur principal. Étant donné que le script analyse tous les processus tabrmt-* au lieu de filtrer strictement ceux de tabrmt-agent-*, il peut déclencher un état FAIL erroné.

La plupart des environnements utilisent des machines distinctes et ne rencontreront pas ce problème. Toutefois, si vous utilisez une configuration colocalisée et que vous obtenez cette erreur spécifique, vous pouvez contourner le contrôle en toute sécurité et poursuivre l’installation en utilisant ce qui suit :

--skip-upgrade-checks

Détails techniques :

Cause première : le contrôle n° 38a utilise des noms de processus trop généraux (tabrmt-*).

Portée : affecte uniquement les mises à niveau sur place où le contrôleur et l’agent partagent la même instance du système d’exploitation.

Niveau de risque : faible. Les processus du serveur principal ne sont pas concernés par la mise à niveau de l’agent. Cette erreur n’indique donc pas un véritable conflit système.