Salesforce Docs Portal

Résoudre les erreurs après la mise à niveau

Les sections suivantes détaillent les problèmes fréquemment identifiés par les vérifications post-mise à niveau ou observés immédiatement après.

Pour plus d’informations sur les vérifications avant et après la mise à niveau, consultez la section Référence de mise à niveau.

Services non opérationnels

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

Le problème est détecté par les vérifications post-mise à niveau #1, #2, #16

Pour résoudre ce problème, procédez comme suit :

Pour Linux, exécutez la commande suivante :

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

Pour Windows, exécutez la commande suivante :

Start-Service TableauResourceMonitoringTool

Recherchez les erreurs de démarrage dans les fichiers journaux 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.

Le problème est détecté par les vérifications post-mise à niveau #5c, #6

Pour résoudre ce problème, vérifiez les points suivants :

  • Vérifiez que le service PostgreSQL est en cours d’exécution

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

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

RabbitMQ ne répond pas

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

Le problème est détecté par les vérifications post-mise à niveau #5b, #7, #9

Pour résoudre ce problème, vérifiez les points suivants :

  • L’initialisation complète de RabbitMQ peut prendre 30 à 60 secondes après la mise à niveau. Attendez et revérifiez

  • Vérifiez que le processus Erlang/beam est en cours d’exécution

  • Vérifiez les alarmes de ressources RabbitMQ (un espace disque <10 Go bloque toute publication de messages)

  • Vérifiez que le fichier cookie Erlang existe et qu’il dispose des autorisations correctes

Retard dans la file d’attente des messages

Les données apparaissent en retard dans l’interface utilisateur Web RMT et les tableaux de bord affichent des métriques obsolètes.

Le problème est détecté par la vérification post-mise à niveau #8.

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

  • Surveillez à l’aide de « rmtadmin status » : la file d’attente devrait être se résorber dans un délai de 15 à 30 minutes.

  • Si la file d’attente persiste, vérifiez que tous les services de l’agent sont en cours d’exécution et connectés

Les nœuds de calcul du serveur RMT ne consomment pas de données (données non ingérées après la mise à niveau)

Tous les services RMT indiquent « En cours d’exécution », la vérification post-mise à niveau affiche une réussite pour les services/les ports/la connectivité, mais l’interface utilisateur Web n’affiche aucune nouvelle donnée et les agents apparaissent comme « Problème de connexion ». « rmtadmin status » affiche une ou plusieurs files d’attente avec des messages qui s’accumulent mais un nombre de consommateurs de **0**.

Cela se produit lorsque les workers en arrière-plan du serveur RMT démarrent, mais ne parviennent pas à relier leurs canaux grand public RabbitMQ après une mise à niveau sur place. Les agents publient avec succès, les messages s’accumulent dans RabbitMQ et aucune donnée n’intègre la base de données.

Le problème est détecté par la vérification post-mise à niveau 8a

Pour résoudre ce problème, procédez comme suit :

  • Redémarrez le serveur principal : `rmtadmin restart’

  • Attendez ~60 secondes, puis relancez « rmtadmin status ». Les files d’attente bloquées devraient maintenant afficher « Consumers = 1 » et la file d’attente devrait se vider en quelques minutes

  • Si les files d’attente affichent toujours « Consumers = 0 » après le redémarrage, inspectez le journal d’arrière-plan à la recherche d’exceptions liant le consommateur :

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

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

  • Recherchez « exception », « channel » ou « binding failed » dans le journal

Discordance du mode FIPS

Lorsque les services ne démarrent pas avec des erreurs cryptographiques ou TLS.

Le problème est détecté par la vérification post-mise à niveau 11

Pour résoudre ce problème, procédez comme suit :

  • Vérifiez que le paramètre FIPS au niveau du système d’exploitation correspond à la configuration RMT (« isFIPSEnabled » dans setup.json)

  • Linux : vérifiez `/proc/sys/crypto/fips_enabled’

  • Windows : vérifiez ’HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled’

Fichier de configuration endommagé

Les services ne démarrent pas avec des erreurs d’analyse JSON.

Le problème est détecté par la vérification post-mise à niveau 3

Pour résoudre ce problème, procédez comme suit :

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

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

Certificat SSL expiré ou proche d’expirer

Lorsque le navigateur Web affiche des avertissements de certificat et que les agents ne parviennent pas à se connecter avec des erreurs TLS.

Le problème est détecté par les vérifications post-mise à niveau 10, 13

Pour résoudre ce problème, procédez comme suit :

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

  • Pour les certificats RabbitMQ, remplacez les fichiers PEM dans le répertoire des certificats et redémarrez le service

Espace disque saturé

Lorsque les services tombent en panne ou ne parviennent pas à écrire des erreurs de données et de base de données dans les journaux.

Le problème est détecté par les vérifications post-mise à niveau #14 et les vérifications pré-mise à niveau #2, #2b

Pour résoudre ce problème, procédez comme suit :

  • Libérez de l’espace disque ou augmentez le volume

  • Procédez au nettoyage de la base de données : assurez-vous que « db:cleanup:type » est défini sur « Purge » (et non « None ») dans config.json

  • Archivez ou supprimez d’anciens fichiers journaux

Erreurs FATAL ou CRITICAL dans les fichiers journaux

Comportement inattendu ou instabilité du service après la mise à niveau.

Le problème est détecté par la vérification post-mise à niveau 15

Pour résoudre ce problème, procédez comme suit :

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

  • Pour les autres erreurs FATAL, consultez l’entrée complète du fichier journal et communiquez avec l’assistance Tableau en lui fournissant le fichier journal

Déconnexions des Agents après la mise à niveau du Serveur RMT

Les Agents sont affichés comme étant déconnectés dans l’interface utilisateur Web RMT. Aucune donnée de surveillance provenant de nœuds Tableau Server spécifiques.

Le problème est détecté par les vérifications pré-mise à niveau 36b, 36c et 36d

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

  • Vérifiez que le service d’Agent est en cours d’exécution sur chaque hôte d’Agent

  • Si les agents exécutent une version beaucoup plus ancienne, mettez-les à niveau pour qu’ils correspondent à la version du Serveur RMT

  • Vérifiez la connectivité réseau (port AMQP 5672) entre les hôtes d’Agent et de Serveur RMT

Régression de version connue comme incorrecte

Lorsque des fonctionnalités spécifiques ne sont pas valides en raison d’un défaut connu dans la version installée.

Le problème est détecté par la vérification pré-mise à niveau #36a

Pour résoudre ce problème, procédez comme suit :

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

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

Nettoyage de Hangfire endommagé (W-19380780)

La base de données ne cesse de croître et le schéma hangfire est anormalement volumineux (>1 Go).

Le problème est détecté par les vérifications pré-mise à niveau #21d, #21g

Pour résoudre ce problème, procédez comme suit :

  • La mise à niveau vers une version fixe corrige la volatilité de la fonction delete_hash()

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

Nettoyage de base de données désactivé

La taille de la base de données augmente avec le temps sans limite et la mise à niveau devient lente.

Le problème est détecté par la vérification pré-mise à niveau #21c

Pour résoudre ce problème, procédez comme suit :

  • Définissez db:cleanup:type sur Purge dans config.json

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

  • Redémarrez le service Directeur RMT pour que le changement prenne effet

Problèmes d’autorisation de fichier

Les services ne démarrent pas ou ne peuvent pas lire les journaux de configuration/’écriture.

Le problème est détecté par les vérifications post-mise à niveau #4 et les vérifications pré-mise à niveau #11–#16

Pour résoudre ce problème, vérifiez les points suivants :

  • Linux : vérifiez la propriété et l’appartenance au groupe des répertoires de configuration, de fichiers journaux et de données

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

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

Processus RMT bloqués après l’arrêt de rmtadmin

Après avoir été 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 s’exécuter. Si la mise à niveau se poursuit dans cet état, le programme d’installation peut échouer en cours d’exécution avec des erreurs de fichier en cours d’utilisation.

Le problème est détecté par la vérification pré-mise à niveau 38a

Pour résoudre ce problème, procédez comme suit :

  • Attendez ~30 secondes pour un arrêt normal, puis réexécutez la vérification pré-mise à niveau

  • Si des processus persistent :

  • Linux : « pkill -u tabrmt-master -f tabrmt-master ; pkill -u tabrmt-agent -f tabrmt-agent » (ignorer ceux qui ne s’appliquent pas sur ce nœud)

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

  • Réexécutez la vérification pré-mise à niveau pour vous assurer que l’état est propre avant de lancer la mise à niveau

 

Faux échecs lors des mises à niveau en colocalisation

Si votre RMT principal et votre Agent co-localisés sur la même machine, la vérification pré-mise à niveau de l’Agent (en particulier la vérification #38a) peut détecter de manière incorrecte les processus principaux. Étant donné que le script recherche tous les processus tabrmt-* au lieu de filtrer uniquement tabrmt-agent-*, il peut déclencher un état FAIL erroné.

La plupart des environnements utilisent des machines séparées et ne rencontreront pas ce problème. Toutefois, si vous utilisez une configuration co-localisée et que vous recevez cette défaillance spécifique, vous pouvez contourner la vérification en toute sécurité et poursuivre l’installation en utilisant la commande suivante :

--skip-upgrade-checks

Détails techniques :

Cause première : la vérification #38a correspond à des noms de processus trop généraux (tabrmt-*).

Portée : affecte uniquement les mises à niveau sur site où le Serveur principal et l’Agent partagent la même instance de système d’exploitation.

Niveau de risque : faible. Les processus du Serveur principal sont hors du champ d’application de la mise à niveau de l’Agent, de sorte que l’échec n’indique pas un conflit système réel.