--- schema_version: "1" id: b7dad9fea49a2719bd857ad8e049ad2c0445b4f768b2f75b4fd45175f3d5bd89 title: Problemen met fouten na een upgrade oplossen collection: tableau version: current locale: nl-nl portal_url: https://docs.salesforce.com/tableau/current/nl-nl/server/rmt-troubleshoot-upgrade.md canonical_url: https://help.tableau.com/current/server/nl-nl/rmt-troubleshoot-upgrade.htm source_site: help.tableau.com content_type: documentation content_hash: c00a356d5b59dae4c3bec0b76f6b6dddf6b80ead33b1e58df56c06b70d8c6f3e description: Troubleshoot errors encountered after upgrading the Resource Monitoring Tool. --- [Doorgaan naar hoofdinhoud](#main-content) # Problemen met fouten na een upgrade oplossen In de volgende secties worden problemen beschreven die vaak worden gevonden bij controles na een upgrade of die direct na een upgrade worden vastgesteld. Zie het gedeelte [Upgrade-referentie](https://help.tableau.com/current/server/nl-nl/rmt-admin-upgrade-reference.htm) voor informatie over controles vóór en na een upgrade. ## Services worden niet uitgevoerd De online gebruikersinterface van RTM is niet toegankelijk en de statusopdracht rmtadmin geeft aan dat de vereiste services zijn gestopt. Dit wordt gedetecteerd door controles #1, #2 en #16 na een upgrade Volg de onderstaande stappen om dit op te lossen: Voer voor Linux de volgende opdracht uit: sudo -u tabrmt-master XDG\_RUNTIME\_DIR=/run/user/$(id -u tabrmt-master) systemctl --user start tabrmt-master Voer voor Windows de volgende opdracht uit: Start-Service TableauResourceMonitoringTool Controleer de servicelogboeken in de logboekdirectory op opstartfouten. ## PostgreSQL accepteert geen verbindingen Wanneer de webinterface databasefouten aangeeft en de data niet worden opgeslagen. Dit wordt gedetecteerd door controles #5c en #6 na een upgrade Controleer het volgende om dit op te lossen: - Ga na of de PostgreSQL-service wordt uitgevoerd - Controleer de PostgreSQL-logboeken in de datadirectory op opstartfouten - Zorg ervoor dat de databasepoort (standaard 5555) niet wordt geblokkeerd door een ander proces ## RabbitMQ reageert niet Wanneer agents worden weergegeven als niet-verbonden en er geen nieuwe bewakingsdata worden weergegeven. Dit wordt gedetecteerd door controles #5b, #7 en #9 na een upgrade Controleer het volgende om dit op te lossen: - Het kan 30-60 seconden duren voordat RabbitMQ volledig is geïnitialiseerd na de upgrade. Wacht even en controleer dit dan opnieuw - Controleer of het Erlang-/BEAM-proces wordt uitgevoerd - Controleer op RabbitMQ-resource-alarmen (bij schijfruimte < 10 GB wordt alle berichtpublicatie geblokkeerd) - Controleer of het Erlang-cookiebestand bestaat en de juiste machtigingen heeft ## Backlog berichtenwachtrij Data worden vertraagd weergegeven in de RMT-webinterface en dashboards tonen verouderde statistieken. Dit wordt gedetecteerd door controle #8 na een upgrade. Een backlog direct na een upgrade is normaal, omdat agents opnieuw verbinding maken en gebufferde data opnieuw verzenden. Doe het volgende om dit op te lossen: - Monitor met 'rmtadmin-status': de backlog zou binnen 15-30 minuten moeten zijn weggewerkt - Als de backlog blijft bestaan, controleer dan of alle agentservices actief en verbonden zijn ## Geen verbruik door RMT Server-workers (data worden niet opgenomen na upgrade) Alle RMT-services geven 'Wordt uitgevoerd' aan en de controle na een upgrade geeft services/poorten/connectiviteit door, maar de webinterface toont geen nieuwe data en agents worden weergegeven als 'Verbindingsprobleem'. '`rmtadmin status`' toont een of meer wachtrijen met berichten die zich opstapelen, maar het aantal consumenten is \*\*0\*\*. Dit gebeurt wanneer de achtergrondworkers van de RMT-server starten, maar er niet in slagen hun RabbitMQ-consumentenkanalen opnieuw te koppelen na een lokale upgrade. Agents publiceren succesvol, berichten stapelen zich op in RabbitMQ en er komt niets in de database terecht. Dit wordt gedetecteerd door controle #8a na een upgrade Doe het volgende om dit op te lossen: - Start de master opnieuw op: `` `rmtadmin restart `` - Wacht ~60 seconden en voer dan `rmtadmin status` opnieuw uit. De gestrande wachtrijen zouden nu 'Consumers = 1' moeten weergeven en de backlog zou binnen een paar minuten moeten afnemen - Als de wachtrijen na het opnieuw opstarten nog steeds 'Consumers = 0' weergeven, controleer dan het achtergrondlogboek op uitzonderingen met consumentbinding: - Windows: `C:\Program Files\Tableau\Tableau Resource Monitoring Tool\master\logs\background\*.log` - Linux: `/var/opt/tableau/tabrmt/master/logs/background/*.log` - Zoek in het logboek naar `exception`, `channel` of `binding failed` ## FIPS-modus komt niet overeen Wanneer services niet starten vanwege cryptografische of TLS-fouten. Dit wordt gedetecteerd door controle #11 na een upgrade Doe het volgende om dit op te lossen: - Zorg ervoor dat de FIPS-instelling op besturingssysteemniveau overeenkomt met de RMT-configuratie ('isFIPSEnabled' in setup.json) - Linux: controleer `` `/proc/sys/crypto/fips_enabled `` - Windows: controleer `HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled` ## Beschadiging configuratiebestand Services starten niet met JSON-parseringsfouten. Dit wordt gedetecteerd door controle #3 na een upgrade Doe het volgende om dit op te lossen: - Valideer het configuratiebestand: `` python3 -c "import json; json.load(open('config.json'))"` `` - Herstel op basis van de back-up van voor de upgrade (we raden u aan om voorafgaand aan elke upgrade een back-up te maken) ## SSL-certificaat is verlopen of verloopt Wanneer de webbrowser certificaatwaarschuwingen weergeeft en agents geen verbinding kunnen maken vanwege TLS-fouten. Dit wordt gedetecteerd door controles #10 en #13 na een upgrade Doe het volgende om dit op te lossen: - Verleng het HTTPS-certificaat en werk dit bij met `` `rmtadmin set-ssl-certificate` `` - Voor RabbitMQ-certificaten vervangt u de PEM-bestanden in de certificaatdirectory en start u de service opnieuw ## Onvoldoende schijfruimte Wanneer services crashen of er niet in slagen om data en databasefouten naar logboeken te schrijven. Dit wordt gedetecteerd door controle #14 na een upgrade, en controles #2 en #2b vóór een upgrade Doe het volgende om dit op te lossen: - Maak schijfruimte of breid het volume uit - Schoon de database op: zorg ervoor dat `db:cleanup:type` is ingesteld op 'Purge' (en niet op 'None') in config.json - Archiveer of verwijder oude logboekbestanden ## FATAL- of CRITICAL-fouten in logboeken Onverwacht gedrag of instabiliteit van de service na de upgrade. Dit wordt gedetecteerd door controle #15 na een upgrade Doe het volgende om dit op te lossen: - 'Broker onbereikbaar'-fouten direct na de upgrade zijn doorgaans van voorbijgaande aard. Controleer of RabbitMQ nu wordt uitgevoerd - Voor andere FATAL-fouten bekijkt u de volledige logboekvermelding en neemt u contact op met de ondersteuning van Tableau met het logboekbestand ## Agent-verbindingen verbroken na RMT Server-upgrade Agents worden in de webinterface van RMT weergegeven als 'Niet verbonden'; er zijn geen bewakingsdata van specifieke Tableau Server-knooppunten. Dit wordt gedetecteerd door controles #36b, #36c en #36d vóór een upgrade Agents maken automatisch opnieuw verbinding nadat de RMT Server-upgrade is voltooid. Het kan 5-10 minuten duren voordat dit is opgelost. Controleer anders het volgende: - Controleer of de Agent-service op elke Agent-host wordt uitgevoerd - Als agents een veel oudere versie gebruiken, kunt u ze upgraden zodat ze overeenkomt met de RMT Server-versie - Controleer de netwerkconnectiviteit (AMQP-poort 5672) tussen de Agent- en RMT Server-host ## Regressie van bekend-slechte versies Wanneer specifieke functies niet werken vanwege een bekend defect in de geïnstalleerde versie. Dit wordt gedetecteerd door controle #36a vóór een upgrade Doe het volgende om dit op te lossen: - Upgrade naar de volgende patchrelease (bijvoorbeeld van 2025.3.0 naar 2025.3.1+) - Neem contact op met de Tableau-ondersteuning voor versiespecifieke patches ## Hangfire-opschoning werkt niet (W-19380780) De database groeit voortdurend en het `hangfire` \-schema is abnormaal groot (> 1 GB). Dit wordt gedetecteerd door controles #21d en #21g vóór een upgrade Doe het volgende om dit op te lossen: - Een upgrade naar een vaste versie corrigeert de volatiliteit van de `delete_hash()`\-functionaliteit - Zwevende rijen in het Hangfire-schema moeten mogelijk handmatig worden opgeschoond. Neem contact op met de ondersteuning van Tableau. ## Database opschonen uitgeschakeld De databasegrootte neemt in de loop van de tijd in onbeperkte mate toe en upgrades worden traag. Dit wordt gedetecteerd door controle #21c vóór de upgrade Doe het volgende om dit op te lossen: - Stel `db:cleanup:type` in `Purge` op `config.json` - Verkort `db:cleanup:afterDays` tot 30-90 dagen (standaard: 14) - Start de RMT Director-service opnieuw om de wijziging door te voeren ## Problemen met bestandsmachtigingen Services kunnen niet worden gestart of kunnen geen configuratie-/schrijflogboeken lezen. Dit wordt gedetecteerd door controle #4 na een upgrade, en controles #11-#16 vóór een upgrade Controleer het volgende om dit op te lossen: - Linux: controleer het eigendom en groepslidmaatschap van configuratie-, logboek- en datadirectory's - Windows: controleer of het serviceaccount lees-/schrijftoegang heeft tot de installatiedirectory's - Neem contact op met de ondersteuning van Tableau als de machtigingsproblemen zich blijven voordoen na een nieuwe installatie ## Gestrande RMT-processen na het stoppen van rmtadmin Nadat `rmtadmin stop` is uitgevoerd op basis van de vastgelegde upgradeprocedure, zijn één of meerdere `tabrmt-master`, `tabrmt-master-background`, `tabrmt-agent`\- of `tabrmt-agent-background`\-processen nog steeds actief. Als de upgrade in deze staat doorgaat, kan halverwege de uitvoering een fout in het installatieprogramma optreden vanwege fouten met het bestand in gebruik. Dit wordt gedetecteerd door controle #38a vóór een upgrade Doe het volgende om dit op te lossen: - Wacht ~30 seconden om het proces correct af te sluiten en voer vervolgens de controle vóór een upgrade opnieuw uit - Als de processen blijven bestaan: - Linux: `pkill -u tabrmt-master -f tabrmt-master ; pkill -u tabrmt-agent -f tabrmt-agent` (sla de processen over die niet van toepassing zijn op dit knooppunt) - Windows: `Stop-Process -Name tabrmt-master,tabrmt-master-background,tabrmt-agent,tabrmt-agent-background -Force` - Voer de controle vóór een upgrade opnieuw uit om te controleren of het opschonen succesvol was voordat u met de upgrade begint ## Onware fouten tijdens upgrades op dezelfde locatie Als uw RMT Master en Agent zich op dezelfde computer bevinden, kan de controle van Agent vóór de upgrade (met name controle #38a) ten onrechte Master-processen detecteren. Omdat het script scant op alle tabrmt-\*-processen in plaats van alleen te filteren op tabrmt-agent-\*, kan dit een onjuiste **FAIL**\-status activeren. De meeste omgevingen gebruiken aparte computers en zullen hier niet mee te maken krijgen. Als u echter een set-up op dezelfde locatie gebruikt en deze specifieke fout ontvangt, kunt u de controle veilig omzeilen en doorgaan met de installatie door het volgende te gebruiken: `--skip-upgrade-checks` Technische details: Onderliggende oorzaak: controleer of #38a overeenkomt met overmatig uitgebreide procesnamen (tabrmt-\*). Bereik: heeft alleen invloed op upgrades ter plekke waarbij Master en Agent dezelfde OS-instantie delen. Risiconiveau: laag. De Master-processen vallen buiten het bereik van de Agent-upgrade, dus de fout duidt niet op een daadwerkelijk conflict in het systeem.