--- schema_version: "1" id: ea7f1827f555ddfe3e4348e6a2ae75797a54cb2f7ee8920de8134c51f132d5bb title: Felsöka fel efter uppgradering collection: tableau version: current locale: sv-se portal_url: https://docs.salesforce.com/tableau/current/sv-se/server-linux/rmt-troubleshoot-upgrade.md canonical_url: https://help.tableau.com/current/server-linux/sv-se/rmt-troubleshoot-upgrade.htm source_site: help.tableau.com content_type: documentation content_hash: 294188d4bb0f0040d40bc1c31d46179656712fd4b6b3550e1ac2585fbb8c05b5 description: Troubleshoot errors encountered after upgrading the Resource Monitoring Tool. --- [Hoppa till huvudinnehåll](#main-content) # Felsöka fel efter uppgradering I följande avsnitt beskriver vi problem som ofta identifieras vid kontroller efter uppgradering eller omedelbart efter en uppgradering. Mer information om kontroller före och efter uppgradering finns i avsnittet [Referens för uppgradering](https://help.tableau.com/current/server-linux/sv-se/rmt-admin-upgrade-reference.htm). ## Tjänster som inte körs RMT-webbanvändargränssnittet är inte tillgängligt och rmtadmin-statuskommandot indikerar att de nödvändiga tjänsterna har stoppats. Felet detekteras genom kontroll efter uppgradering #1, #2 och #16. Åtgärda felet genom att följa de här stegen: För Linux, använd följande kommando: sudo -u tabrmt-master XDG\_RUNTIME\_DIR=/run/user/$(id -u tabrmt-master) systemctl --user start tabrmt-master För Windows, använd följande kommando: Start-Service TableauResourceMonitoringTool Kontrollera om det finns startfel i tjänstloggarna i loggkatalogen. ## PostgreSQL accepterar inte anslutningar När webbgränssnittet visar databasfel och data inte lagras. Felet detekteras genom kontroll efter uppgradering #5c och #6. Kontrollera följande för att åtgärda detta: - Kontrollera att PostgreSQL-tjänsten körs - Kontrollera om det finns startfel i PostgreSQL-loggarna i datakatalogen - Kontrollera att databasporten (standard 5555) inte blockeras av en annan process ## RabbitMQ svarar inte När agenter visas som frånkopplade och inga nya övervakningsdata visas. Felet detekteras genom kontroll efter uppgradering #5b, #7 och #9. Kontrollera följande för att åtgärda detta: - Det kan ta 30–60 sekunder för RabbitMQ att initieras helt efter uppgraderingen – vänta och kontrollera igen - Kontrollera att Erlang-/strålprocessen körs - Kontrollera om det förekommer RabbitMQ-resurslarm (diskutrymme < 10 GB blockerar all meddelandepublicering) - Kontrollera att Erlang-cookiefilen finns och har rätt behörigheter ## Eftersläpning i meddelandekön Data visas med fördröjning i RMT-webbgränssnittet och instrumentpaneler visar inaktuella mätvärden. Felet detekteras genom kontroll efter uppgradering #8. Eftersläpning omedelbart efter en uppgradering är normalt när agenter återansluter och skickar buffrade data igen. Gör följande för att åtgärda detta: - Övervaka med ”rmtadmin-status” – kvarvarande uppgifter bör försvinna inom 15–30 minuter - Om kvarvarande uppgifter kvarstår ska du kontrollera att alla agenttjänster körs och är anslutna ## RMT Server-system förbrukar inte (data inhämtas inte efter uppgradering) Alla RMT-tjänster rapporterar att de körs och kontrollen efter uppgradering godkänner tjänster/portar/anslutning, men webbgränssnittet visar inga nya data och agenterna visar ”anslutningsproblem”. ”`rmtadmin status`” visar en eller flera köer med meddelanden som ackumuleras men ett konsumentantal på \*\*0\*\*. Felet inträffar när RMT Servers bakgrundssystem startar men inte lyckas binda om sina RabbitMQ-konsumentkanaler efter en uppgradering. Agenter publicerar, meddelanden samlas på hög i RabbitMQ och ingenting hamnar i databasen. Felet detekteras genom kontroll efter uppgradering #8a. Gör följande för att åtgärda detta: - Starta om styrenheten: `` `rmtadmin restart `` - Vänta ~60 sekunder och kör sedan ”`rmtadmin status`” igen – de strandade köerna bör nu visa ”Konsumenter = 1” och kvarvarande uppgifter bör tömmas inom några minuter - Om köerna fortfarande visar ”Konsumenter = 0” efter omstarten ska du kontrollera bakgrundsloggen avseende konsumentbindande undantag: - Windows: `C:\Program Files\Tableau\Tableau Resource Monitoring Tool\master\logs\background\*.log` - Linux: `/var/opt/tableau/tabrmt/master/logs/background/*.log` - Sök i loggen efter ”`exception`”, `channel`” eller `binding failed`” ## Matchningsfel med FIPS-läge När tjänster inte kan starta med kryptografiska fel eller TLS-fel. Felet detekteras genom kontroll efter uppgradering #11. Gör följande för att åtgärda detta: - Kontrollera att FIPS-inställningen på operativsystemnivå matchar RMT-konfigurationen (”isFIPSEnabled” i setup.json) - Linux: Kontrollera `` `/proc/sys/crypto/fips_enabled `` - Windows: Kontrollera `HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled` ## Skadade konfigurationsfiler Tjänsterna kan inte starta med JSON-tolkningsfel. Felet detekteras genom kontroll efter uppgradering #3. Gör följande för att åtgärda detta: - Validera konfigurationsfilen: `` python3 -c "import json; json.load(open('config.json'))"` `` - Återställ från säkerhetskopian före uppgraderingen (säkerhetskopiering rekommenderas innan varje uppgradering) ## SSL-certifikatet har upphört att gälla eller är på väg att göra det När webbläsaren visar certifikatvarningar och agenter inte kan ansluta till TLS-fel. Felet detekteras genom kontroll efter uppgradering #10 och #13. Gör följande för att åtgärda detta: - Förnya HTTPS-certifikatet och uppdatera det med `` `rmtadmin set-ssl-certificate` `` - För RabbitMQ-certifikat ska du ersätta PEM-filerna i certifikatkatalogen och starta om tjänsten ## Slut på diskutrymme När tjänster kraschar eller inte kan skriva data- och databasfel i loggar. Felet detekteras genom kontroll efter uppgradering #14 och kontroll före uppgradering #2 och #2b. Gör följande för att åtgärda felet: - Frigör diskutrymme eller utöka volymen - Kör en databasrensning: Kontrollera att `db:cleanup:type` är inställt på ”Rensa” (inte ”Ingen”) i config.json - Arkivera eller ta bort gamla loggfiler ## ALLVARLIGA eller KRITISKA fel i loggar Oväntat beteende eller instabilitet i tjänsten efter uppgraderingen. Felet detekteras genom kontroll efter uppgradering #15. Gör följande för att åtgärda detta: - ”Mäklaren kan inte nås”-fel omedelbart efter en uppgradering är vanligtvis övergående. Kontrollera att RabbitMQ nu körs. - För andra allvarliga fel ska du granska den fullständiga loggposten och kontakta Tableau Support med loggfilen ## Agentfrånkopplingar efter RMT Server-uppgradering Agenter visas som frånkopplade i RMT-webbgränssnittet. Inga övervakningsdata från specifika Tableau Server-noder. Felet detekteras genom kontroll före uppgradering #36b, #36c och #36d. Agenter återansluter automatiskt när uppgraderingen av RMT Server har slutförts. Vänta 5–10 minuter tills detta har åtgärdats. Kontrollera annars följande: - Kontrollera att agenttjänsten körs på varje agentvärd - Om agenter kör en mycket äldre version uppgraderar du dem så att de matchar RMT Server-versionen - Kontrollera nätverksanslutningen (AMQP-port 5672) mellan Agent- och RMT Server-värdar ## Regression av känd dålig version När specifika funktioner inte fungerar på grund av en känd defekt i den installerade versionen. Felet detekteras genom kontroll före uppgradering #36a. Gör följande för att åtgärda detta: - Uppgradera till nästa korrigeringsversion (t.ex. från 2025.3.0 till 2025.3.1+) - Kontakta Tableau Support för versionsspecifika korrigeringar ## Trasig hangfire-rensning (W-19380780) Databasen växer kontinuerligt och schemat `hangfire` är onormalt stort (> 1 GB). Felet detekteras genom kontroll före uppgradering #21d och #21g. Gör följande för att åtgärda detta: - Uppgradera till en fast version för att korrigera `delete_hash()`\-funktionens rörlighet - Överblivna rader i hangfire-schemat kan kräva manuell rensning. Kontakta Tableau Support. ## Databasrensning har inaktiverats Databasstorleken växer med tiden utan gränser och uppgraderingen blir långsam. Felet detekteras genom kontroll före uppgradering #21c. Gör följande för att åtgärda detta: - Ställ in `db:cleanup:type` till `Purge` i `config.json` - Minska `db:cleanup:afterDays` till 30–90 dagar (standard: 14) - Starta om RMT-tjänsten för att ändringen ska tillämpas ## Fel med filbehörighet Tjänsterna startar inte eller kan inte läsa konfigurationen/skriva loggar. Felet detekteras genom kontroll efter uppgradering #4 och kontroll före uppgradering #11–#16. Kontrollera följande för att åtgärda detta: - Linux: Verifiera ägarskap och gruppmedlemskap för konfigurations-, logg- och datakataloger - Windows: Kontrollera att tjänstkontot har läs-/skrivåtkomst till installationskatalogerna - Kontakta Tableau Support om behörighetsproblemen kvarstår efter en ny installation ## Strandade RMT-processer efter rmtadmin-stopp Efter att ha kört `rmtadmin stop` enligt den dokumenterade uppgraderingsproceduren körs fortfarande en eller flera `tabrmt-master`\-, `tabrmt-master-background`\-, `tabrmt-agent`\- eller `tabrmt-agent-background`\-processer. Om uppgraderingen fortsätter i det här tillståndet kan installationsprogrammet misslyckas mitt i körningen med filanvändningsfel som konsekvens. Felet detekteras genom kontroll före uppgradering #38a. Gör följande för att åtgärda detta: - Vänta ~30 sekunder för en korrekt avstängning och kör sedan kontrollen före uppgradering igen - Om processerna återstår: - Linux: `pkill -u tabrmt-master -f tabrmt-master ; pkill -u tabrmt-agent -f tabrmt-agent` (hoppa över de som inte gäller på den här noden) - Windows: `Stop-Process -Name tabrmt-master,tabrmt-master-background,tabrmt-agent,tabrmt-agent-background -Force` - Kör kontrollen före uppgradering igen för att bekräfta ett rensat tillstånd innan du inleder uppgraderingen ## Falska fel vid samlokaliserade uppgraderingar Om RMT Master och Agent är samlokaliserade på samma dator kan Agents kontroll före uppgradering (specifikt kontroll #38a) felaktigt identifiera Master-processer. Eftersom skriptet söker efter alla tabrmt-\*-processer i stället för att filtrera strikt efter tabrmt-agent-\*, kan en falsk **FAIL**\-status utlösas. De flesta miljöer använder separata datorer och kommer inte att stöta på det här problemet. Men om du använder en samlokaliserad konfiguration och får det här specifika felet kan du kringgå kontrollen på ett säkert sätt och fortsätta med installationen med hjälp av följande: `--skip-upgrade-checks` Teknisk information: Grundorsak: Kontroll #38a matchar alltför breda processnamn (tabrmt-\*). Omfattning: Påverkar endast uppgraderingar på plats där Master och Agent delar samma operativsystemsinstans. Risknivå: låg. Master-processerna ligger utanför Agent-uppgraderingens omfattning, så felet indikerar inte en faktisk systemkonflikt.