--- schema_version: "1" id: 3ae78aee5df4075a442c2e974cb53f61120a2f91d08940b515f10aa82789d3dc title: Beheben von Fehlern nach dem Upgrade collection: tableau version: current locale: de-de portal_url: https://docs.salesforce.com/tableau/current/de-de/server-linux/rmt-troubleshoot-upgrade.md canonical_url: https://help.tableau.com/current/server-linux/de-de/rmt-troubleshoot-upgrade.htm source_site: help.tableau.com content_type: documentation content_hash: 3e693f5761c7bf95920b64ac4134c434eb80e96eb3c367a8ae3b357ab91a5a61 description: Troubleshoot errors encountered after upgrading the Resource Monitoring Tool. --- [Zum Hauptinhalt springen](#main-content) # Beheben von Fehlern nach dem Upgrade 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](https://help.tableau.com/current/server-linux/de-de/rmt-admin-upgrade-reference.htm). ## 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.