Salesforce Docs Portal

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.

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.