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 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.