In den folgenden Abschnitten werden Probleme beschrieben, die häufig bei Post-Upgrade-Überprüfungen oder unmittelbar nach einem Upgrade festgestellt werden.

Informationen zu Pre-Upgrade- und Post-Upgrade-Überprüfungen finden Sie im Abschnitt Upgrade-Referenz.

Dienste werden nicht ausgeführt

Auf die RMT-Webbenutzeroberfläche kann nicht zugegriffen werden, und der Befehl „rmtadmin status“ zeigt an, dass die erforderlichen Dienste beendet wurden.

Dies wird durch die Post-Upgrade-Überprüfungen #1, #2, #16 erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

Führen Sie für Linux den folgenden Befehl aus:

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

Führen Sie für Windows den folgenden Befehl aus:

Start-Service TableauResourceMonitoringTool

Überprüfen Sie die Dienstprotokolle im Protokollverzeichnis auf Startfehler.

PostgreSQL akzeptiert keine Verbindungen

Wenn die Webschnittstelle Datenbankfehler anzeigt und die Daten nicht gespeichert werden.

Dies wird von den Post-Upgrade-Überprüfungen #5c, #6 erkannt

Überprüfen Sie Folgendes, um dieses Problem zu beheben:

• Prüfen Sie, ob der PostgreSQL-Dienst ausgeführt wird

• Überprüfen Sie die PostgreSQL-Protokolle im Datenverzeichnis auf Startfehler

• Stellen Sie sicher, dass der Datenbankport (Standard: 5555) nicht durch einen anderen Prozess blockiert wird

RabbitMQ reagiert nicht

Wenn Agenten mit getrennter Verbindung dargestellt und keine neuen Überwachungsdaten angezeigt werden.

Dies wird durch die Post-Upgrade-Überprüfungen #5b, #7, #9 erkannt

Überprüfen Sie Folgendes, um dieses Problem zu beheben:

• Es kann 30 bis 60 Sekunden dauern, bis RabbitMQ nach dem Upgrade vollständig initialisiert ist – warten Sie und führen Sie eine erneute Überprüfung durch

• Prüfen Sie, ob der Erlang/Beam-Prozess ausgeführt wird

• Prüfen Sie, ob RabbitMQ-Ressourcenalarme vorhanden sind (Festplattenspeicherplatz < 10 GB blockiert das Veröffentlichen von Nachrichten)

• Vergewissern Sie sich, dass die Erlang-Cookie-Datei vorhanden ist und über die erforderlichen Berechtigungen verfügt.

Rückstand in der Nachrichtenwarteschlange

Die Daten erscheinen in der RMT-Weboberfläche verzögert, und die Dashboards zeigen veraltete Metriken.

Dies wird durch die Post-Upgrade-Überprüfung #8 erkannt.

Ein Rückstau unmittelbar nach dem Upgrade ist normal, da Agenten erneut eine Verbindung herstellen und gepufferte Daten erneut senden. Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Überwachen Sie dies mit „rmtadmin status“ – der Rückstand sollte innerhalb von 15 bis 30 Minuten verschwunden sein

• Wenn der Rückstand weiterhin besteht, überprüfen Sie, ob alle Agentendienste ausgeführt werden und verbunden sind

RMT-Server-Worker verarbeiten keine Daten (Daten werden nach dem Upgrade nicht aufgenommen)

Alle RMT-Dienste melden „Wird ausgeführt“, die Post-Upgrade-Überprüfung für Dienste/Ports/Konnektivität ist erfolgreich, aber die Weboberfläche zeigt keine neuen Daten und Agenten weisen ein „Verbindungsproblem“ auf. rmtadmin status zeigt eine oder mehrere Warteschlangen mit sich ansammelnden Nachrichten, aber eine Konsumentenanzahl von **0**.

Dies tritt auf, wenn die Background-Worker des RMT-Servers zwar starten, aber nach einem In-Place-Upgrade ihre RabbitMQ-Consumer-Channels nicht erneut binden. Agenten veröffentlichen erfolgreich, Nachrichten stapeln sich in RabbitMQ und nichts landet in der Datenbank.

Dies wird von der Post-Upgrade-Überprüfung #8a erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Starten Sie den Server neu: `rmtadmin restart

• Warten Sie ~60 Sekunden, und führen Sie dann rmtadmin status erneut aus – die hängengebliebenen Warteschlangen sollten jetzt „Consumers = 1“ anzeigen, und der Rückstand sollte innerhalb weniger Minuten abgebaut sein

• Wenn die Warteschlangen nach dem Neustart immer noch „Consumers = 0“ anzeigen, überprüfen Sie das Hintergrundprotokoll auf Ausnahmen für die Konsumenten-Bindung:

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

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

• Durchsuchen Sie das Protokoll nach exception, channel oder binding failed

FIPS-Modus stimmt nicht überein

Wenn Dienste mit kryptografischen oder TLS-Fehlern nicht gestartet werden können.

Dies wird durch die Post-Upgrade-Überprüfung #11 erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Stellen Sie sicher, dass die FIPS-Einstellung auf Betriebssystemebene mit der RMT-Konfiguration übereinstimmt („isFIPSEnabled“ in setup.json)

• Linux: Prüfen Sie `/proc/sys/crypto/fips_enabled

• Windows: Prüfen Sie HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled

Beschädigte Konfigurationsdatei

Dienste können mit Fehlern bei der JSON-Analyse nicht gestartet werden.

Dies wird durch die Post-Upgrade-Überprüfung #3 erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Validieren Sie die Konfigurationsdatei: python3 -c "import json; json.load(open('config.json'))"`

• Wiederherstellen aus dem Pre-Upgrade-Backup (vor jedem Upgrade empfohlen)

SSL-Zertifikat abgelaufen oder läuft ab

Wenn der Webbrowser Zertifikatswarnungen anzeigt und Agenten aufgrund von TLS-Fehlern keine Verbindung herstellen können.

Dies wird von den Post-Upgrade-Überprüfungen #10, #13 erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Erneuern Sie das HTTPS-Zertifikat und aktualisieren Sie es mit `rmtadmin set-ssl-certificate`

• Ersetzen Sie bei RabbitMQ-Zertifikaten die PEM-Dateien im Zertifikatsverzeichnis und starten Sie den Dienst neu

Kein freier Speicherplatz mehr verfügbar

Wenn Dienste abstürzen oder Daten und Datenbankfehler nicht in Protokolle geschrieben werden.

Dies wird von der Post-Upgrade-Überprüfung #14 und den Pre-Upgrade-Überprüfungen #2 #2b erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Geben Sie Festplattenspeicherplatz frei oder erweitern Sie das Volume

• Führen Sie eine Datenbankbereinigung aus: Stellen Sie sicher, dass db:cleanup:type in config.json auf „Purge“ (nicht auf „None“) festgelegt ist.

• Archivieren oder Löschen Sie alte Protokolldateien

SCHWERWIEGENDE oder KRITISCHE Fehler in Protokollen

Unerwartetes Verhalten oder Instabilität des Dienstes nach dem Upgrade.

Dies wird durch die Post-Upgrade-Überprüfung #15 erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• „Broker unreachable“-Fehler unmittelbar nach dem Upgrade sind in der Regel vorübergehend. Überprüfen Sie, ob RabbitMQ jetzt ausgeführt wird

• Bei anderen schwerwiegenden Fehlern überprüfen Sie den vollständigen Protokolleintrag, und wenden Sie sich mit der Protokolldatei an den Tableau-Support

Trennung der Agentenverbindungen nach dem RMT-Server-Upgrade

Agenten werden in der RMT-Webschnittstelle als getrennt angezeigt: keine Überwachungsdaten von bestimmten Tableau Server-Knoten.

Dies wird durch die Pre-Upgrade-Überprüfungen #36b, #36c #36d erkannt

Agenten stellen die Verbindung automatisch wieder her, nachdem das RMT-Server-Upgrade abgeschlossen ist. Warten Sie 5 bis 10 Minuten, bis dies behoben ist. Andernfalls überprüfen Sie Folgendes:

• Vergewissern Sie sich, dass der Agentendienst auf jedem Agent-Host ausgeführt wird

• Falls die Agenten eine wesentlich ältere Version ausführen, aktualisieren Sie sie auf die gleiche Version wie den RMT-Server.

• Überprüfen Sie die Netzwerkkonnektivität (AMQP-Port 5672) zwischen Agenten und RMT-Server-Hosts

Regression in bekannte fehlerhafte Versionen

Wenn bestimmte Funktionen aufgrund eines bekannten Fehlers in der installierten Version nicht funktionieren.

Dies wird durch die Pre-Upgrade-Überprüfung #36a erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Führen Sie ein Upgrade auf die nächste Patch-Version durch (z. B. von 2025.3.0 auf 2025.3.1+)

• Wenden Sie sich für versionsspezifische Patches an den Tableau-Support

Hangfire-Bereinigung fehlerhaft (W-19380780)

Die Datenbank wächst kontinuierlich, und das Schema hangfire ist ungewöhnlich groß (> 1 GB).

Dies wird von den Pre-Upgrade-Überprüfungen #21d, #21g erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Ein Upgrade auf eine feste Version behebt die Instabilität der Funktion delete_hash()

• Verwaiste Zeilen im Hangfire-Schema müssen möglicherweise manuell bereinigt werden. Wenden Sie sich an den Tableau-Support.

Datenbankbereinigung deaktiviert

Die Größe der Datenbank nimmt im Laufe der Zeit zu, und Aktualisierungen werden langsam.

Dies wird durch die Pre-Upgrade-Überprüfung #21c erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Stellen Sie db:cleanup:type auf Purge in config.json ein

• Verkürzen Sie db:cleanup:afterDays auf 30–90 Tage (Standard: 14)

• Starten Sie den RMT-Director-Dienst neu, damit die Änderung wirksam wird

Fehler bei Dateiberechtigungen

Dienste können nicht gestartet werden oder können Konfigurations-/Schreibprotokolle nicht lesen.

Dies wird von der Post-Upgrade-Überprüfung #4 und den Pre-Upgrade-Überprüfungen #11–#16 erkannt

Überprüfen Sie Folgendes, um dieses Problem zu beheben:

• Linux: Überprüfen Sie den Besitz und die Gruppenmitgliedschaft von Konfigurations-, Protokoll- und Datenverzeichnissen

• Windows: Überprüfen Sie, ob das Dienstkonto über Lese-/Schreibzugriff auf die Installationsverzeichnisse verfügt

• Wenden Sie sich an den Tableau-Support, wenn Berechtigungsprobleme nach einer Neuinstallation weiterhin bestehen

Hängengebliebene RMT-Prozesse nach „rmtadmin stop“

Nach dem Ausführen von rmtadmin stop gemäß dem dokumentierten Upgrade-Verfahren werden noch ein oder mehrere tabrmt-master-, tabrmt-master-background-, tabrmt-agent- oder tabrmt-agent-background-Prozesse ausgeführt. Wenn das Upgrade in diesem Zustand fortgesetzt wird, kann das Installationsprogramm mitten in der Ausführung mit Dateifehlern fehlschlagen.

Dies wird durch die Pre-Upgrade-Überprüfung #38a erkannt

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

• Warten Sie ~30 Sekunden, bis das System ordnungsgemäß heruntergefahren wurde, und führen Sie dann die Pre-Upgrade-Überprüfung erneut aus

• Wenn die Prozesse weiterhin bestehen:

• Linux: pkill -u tabrmt-master -f tabrmt-master ; pkill -u tabrmt-agent -f tabrmt-agent (überspringen Sie diejenigen, die auf diesen Knoten nicht zutreffen)

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

• Führen Sie die Pre-Upgrade-Überprüfung erneut durch, um vor Beginn des Upgrades einen sauberen Zustand sicherzustellen.

Fehlalarme bei parallel durchgeführten Upgrades

Wenn RMT-Server und Agent auf demselben Rechner installiert sind, kann die Pre-Upgrade-Überprüfung des Agenten (insbesondere Überprüfung #38a) fälschlicherweise Server-Prozesse erkennen. Da das Skript nach allen tabrmt-*-Prozessen scannt, anstatt streng nach tabrmt-agent-* zu filtern, kann ein falscher FAIL-Status ausgelöst werden.

In den meisten Umgebungen werden separate Rechner verwendet, sodass dies nicht vorkommt. Wenn Sie jedoch ein Setup am gleichen Ort verwenden und diesen speziellen Fehler erhalten, können Sie die Überprüfung sicher überspringen und mit der Installation fortfahren, indem Sie Folgendes verwenden:

--skip-upgrade-checks

Technische Details:

Ursache: Die Überprüfung #38a verwendet zu weit gefasste Prozessnamen (tabrmt-*).

Bereich: Betrifft nur In-Place-Upgrades, bei denen der Server und Agent dieselbe Betriebssysteminstanz gemeinsam nutzen.

Risikoniveau: Gering. Die Server-Prozesse sind für das Agenten-Upgrade nicht relevant, daher weist der Fehler nicht auf einen tatsächlichen Systemkonflikt hin.