以下區段詳細介紹升級後檢查經常發現或在升級後立即觀察到的問題。

有關升級前和升級後檢查的詳情，請參閱升級參考區段。

服務未執行

無法存取 RMT Web 使用者介面，且 rmtadmin status 命令表示所需的服務已停止。

升級後檢查 #1、#2、#16 會偵測到此錯誤

若要解決此問題，請採取以下步驟：

對於 Linux，使用以下命令：

sudo -u tabrmt-master XDG_RUNTIME_DIR=/run/user/$(id -u tabrmt-master) systemctl --user start tabrmt-master

對於 Windows，使用以下命令：

Start-Service TableauResourceMonitoringTool

檢查記錄目錄中的服務記錄是否有啟動錯誤。

PostgreSQL 不接受連線

Web UI 顯示資料庫錯誤並且資料未儲存時。

升級後檢查 #5c #6 會偵測到此情況

若要解決此問題，請檢查以下內容：

• 驗證 PostgreSQL 服務是否正在執行

• 檢查資料目錄中的 PostgreSQL 記錄檔是否有啟動錯誤

• 確保資料庫埠（預設為 5555）未被其他程序封鎖

RabbitMQ 沒有回應

當代理程式顯示為已中斷連線並且未出現新的監視資料時。

升級後檢查 #5b、#7、#9 會偵測到此錯誤

若要解決此問題，請檢查以下內容：

• 升級後，RabbitMQ 可能需要 30-60 秒才能完全初始化 — 請稍候並重新檢查

• 驗證 Erlang/beam 處理序是否正在執行

• 檢查 RabbitMQ 資源警示（磁碟空間不足 10 GB 將阻止所有訊息發佈）

• 請驗證 Erlang Cookie 檔案存在並具有正確的權限

訊息佇列待處理項目

資料在 RMT Web UI 中顯示延遲，儀表板顯示過時指標。

升級後檢查 #8 會偵測到此問題。

升級後立即出現積壓是正常的，因為代理程式會重新連線並重新傳送緩衝資料。若要解決此問題，請執行以下內容：

• 使用 `rmtadmin 狀態` 進行監視 — 列待處理項目應在 15-30 分鐘內清除

• 如果列待處理項目仍然存在，請檢查所有代理程式服務是否都在執行並連線

RMT 伺服器工作者不使用（升級後未擷取資料）

所有 RMT 服務都報告升級後檢查正在執行，會傳遞服務/連接埠/連線，但 Web UI 未顯示任何新資料，且代理程式顯示為「連線問題」。`rmtadmin status` 顯示一個或多個佇列，其中訊息正在累積，但取用者計數為 **0**。

當 RMT 伺服器的背景工作啟動但在就地升級後未能重新繫結其 RabbitMQ 取用者管道時，就會發生這種情況。代理程式發佈成功，訊息堆積在 RabbitMQ 中，但資料庫中沒有任何內容。

升級後檢查 #8a 偵測到它

若要解決此問題，請執行以下內容：

• 重新啟動主伺服器：`rmtadmin restart`

• 等待 ~60 秒，然後重新執行 `rmtadmin status` — 擱淺的佇列現在應該顯示 `Consumers = 1`，並且待辦項目應該會在幾分鐘內清空

• 如果重新啟動後佇列仍顯示 `Consumers = 0`，請檢查背景記錄中是否存在取用者繫結例外狀況：

• Windows: `C:\Program Files\Tableau\Tableau Resource Monitoring Tool\master\logs\background\*.log`

• Linux: `/var/opt/tableau/tabrmt/master/logs/background/*.log`

• 在記錄中搜尋 `exception`、`channel` 或 `binding failed`

FIPS 模式不相符

服務因加密或 TLS 錯誤而無法啟動時。

升級後檢查 #11 偵測到此方法

若要解決此問題，請執行以下內容：

• 確保作業系統層級 FIPS 設定符合 RMT 設定（setup.json 中的 `isFIPSEnabled`）

• Linux：核取 `/proc/sys/crypto/fips_enabled`

• Windows：勾選 `HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled`

設定檔損壞

服務啟動失敗，並出現 JSON 剖析錯誤。

升級後檢查 #3 偵測到此方法

若要解決此問題，請執行以下內容：

• 驗證設定檔: `python3 -c "import json; json.load(open('config.json'))"`

• 從升級前備份還原（建議在每次升級之前進行備份）

SSL 憑證已過期或即將過期

當 Web 瀏覽器顯示憑證警告並且代理程式無法連線時出現 TLS 錯誤。

升級後檢查 #10、#13 會偵測到此值

若要解決此問題，請執行以下內容：

• 更新 HTTPS 憑證，並使用 `rmtadmin set-ssl-certificate` 進行更新

• 如果是 RabbitMQ 憑證，請取代憑證目錄中的 PEM 檔案並重新啟動服務

磁碟空間消耗

當服務當機或無法在記錄檔中寫入資料和資料庫錯誤時。

升級後檢查 #14、升級前檢查 #2 偵測到 #2b

若要解決此問題，請執行以下內容：

• 釋放磁碟空間或擴充磁碟區

• 執行資料庫清理：確保 config.json 中的 `db:cleanup:type` 設定為 `Purge`（而不是 `None`）

• 封存或刪除舊記錄檔檔案

記錄中的嚴重或嚴重錯誤

升級後出現意外行為或服務不穩定。

升級後檢查 #15 偵測到此方法

若要解決此問題，請執行以下內容：

• 升級後立即出現的「代理程式無法連線」錯誤通常是暫時性的。驗證 RabbitMQ 現在是否正在執行

• 對於其他嚴重錯誤，請檢閱完整記錄項目，並攜帶記錄檔聯絡 Tableau 支援服務

RMT 伺服器升級後代理程式中斷連線

代理程式在 RMT Web UI 中顯示為已中斷連線；沒有來自特定 Tableau Server 節點的監視資料。

升級前檢查 #36b、#36c #36d 會偵測到此錯誤

RMT 伺服器升級完成後，代理程式會自動重新連線。請等待 5-10 分鐘以修復此問題。否則，請檢查以下內容：

• 驗證代理程式服務是否正在每個代理程式主機上執行

• 如果代理程式執行的版本要舊得多，請升級它們以與 RMT 伺服器版本相符

• 檢查代理程式與 RMT 伺服器主機之間的網路連線（AMQP 連接埠 5672）

已知錯誤版本回歸

由於已安裝版本中的已知缺陷而導致特定功能中斷時。

升級前檢查 #36a 偵測到它

若要解決此問題，請執行以下內容：

• 升級到下一個修補程式版本（例如，從 2025.3.0 升級到 2025.3.1+）

• 請聯絡 Tableau 支援以取得特定版本的修補檔

Hangfire 清理失敗 (W-19380780)

資料庫持續成長，且 hangfire 結構描述異常大 (>1 GB)。

升級前檢查 #21d 偵測到它，#21g

若要解決此問題，請執行以下內容：

• 升級到固定版本可 delete_hash() 修正函數波動性

• hangfire 結構描述中的孤立列可能需要手動清理。請與 Tableau 支援部門聯絡。

資料庫清理已停用

資料庫大小會隨著時間的推移而無限制地增長，並且升級變得緩慢。

升級前檢查 #21c 偵測到它

若要解決此問題，請執行以下內容：

• 在 config.json 中將 db:cleanup:type 設定為 Purge

• 縮短 db:cleanup:afterDays 至 30-90 天（預設值：14）

• 請重新啟動 RMT Director 服務以使變更生效。

檔案權限問題

服務無法啟動或無法讀取設定/寫入記錄。

升級後檢查 #4、升級前檢查 #11–#16 偵測到此問題

若要解決此問題，請檢查以下內容：

• Linux：驗證設定、記錄和資料目錄的擁有權和群組成員資格

• Windows：驗證服務帳戶是否具有安裝目錄的讀/寫權限

• 如果全新安裝後權限問題仍然存在，請聯絡 Tableau 支援

rmtadmin 停止後擱淺的 RMT 處理序

按照記載的升級處理序執行 rmtadmin stop 後，一個或多個 tabrmt-master、 tabrmt-master-background、 tabrmt-agent或 tabrmt-agent-background 處理序仍在執行。如果在此狀態下進行升級，安裝程式可能會在執行中途失敗，並出現檔案使用中錯誤。

升級前檢查 #38a 偵測到它

若要解決此問題，請執行以下內容：

• 等待 ~30 秒進行正常關機，然後重新執行升級前檢查

• 如果程序持續存在：

• Linux: `pkill -u tabrmt-master -f tabrmt-master ; pkill -u tabrmt-agent -f tabrmt-agent`（跳過不適用於此節點的那些）

• Windows: `Stop-Process -Name tabrmt-master,tabrmt-master-background,tabrmt-agent,tabrmt-agent-background -Force`

• 在開始升級之前，重新執行升級前檢查以確認乾淨狀態

相同位置升級期間發生錯誤

如果 RMT 主要伺服器和代理程式位於同一台電腦上，則代理程式的升級前檢查（特別是檢查 #38a）可能會錯誤地偵測主要處理序。由於指令碼會掃描所有 tabrmt-* 處理序，而不是嚴格篩選 tabrmt-agent-*，因此可能會觸發錯誤的FAIL狀態。

大多數環境使用單獨的機器，不會遇到這種情況。但是，如果使用相同位置的安裝程式並收到此特定故障，則可以使用以下命令安全地略過檢查並繼續安裝：

--skip-upgrade-checks

技術細節：

根本原因：檢查 #38a 符合過寬的處理序名稱 (tabrmt-*)。

範圍：僅影響主要伺服器和代理程式共用相同作業系統執行個體的就地升級。

風險等級：低。主要處理序不在代理程式升級的範圍內，因此失敗並不表示存在實際的系統衝突。