以下部分详细描述了升级后检查经常发现或在升级后立即观察到的问题。

有关升级前和升级后检查的信息，请参见升级参考部分。

服务未运行

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 status”进行监控 — 积压应在 15–30 分钟内清除

• 如果积压仍然存在，请检查所有代理服务是否正在运行并已连接

RMT Server 工作线程未消耗（升级后未摄取数据）

所有 RMT 服务报告“正在运行”，升级后的服务/端口/连接检查均通过，但 Web UI 不显示新数据，并且代理显示为“连接问题”。“rmtadmin status”显示一个或多个队列，其消息正在累积，但使用者计数为 **0**。

当 RMT Server 的后台工作线程启动但在就地升级后未能重新绑定其 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 证书已过期或即将过期

当网络浏览器显示证书警告且代理因 TLS 错误无法连接时。

它由升级后检查 #10、#13 检测到

若要解决此问题，请执行以下操作：

• 续订 HTTPS 证书并使用 `rmtadmin set-ssl-certificate` 对其进行更新

• 对于 RabbitMQ 证书，请替换 certificates 目录中的 PEM 文件并重新启动服务

磁盘空间耗尽

当服务崩溃或无法写入数据，以及日志中出现数据库错误时。

它由升级后检查 #14、升级前检查 #2、#2b 检测到

若要解决此问题，请执行以下操作：

• 释放磁盘空间或扩展卷

• 运行数据库清理：确保在 config.json 中将“db:cleanup:type”设置为“Purge”（而不是“None”）

• 存档或删除旧日志文件

日志中的致命或严重错误

升级后出现意外行为或服务不稳定。

它由升级后检查 #15 检测到

若要解决此问题，请执行以下操作：

• 升级之后立即出现的“Broker unreachable”错误通常是暂时的。验证 RabbitMQ 是否正在运行

• 对于其他致命错误，请查看完整的日志条目，并与 Tableau 支持部门联系并提供日志文件

RMT Server 升级后代理断开连接

代理在 RMT Web UI 中显示为“断开连接”；没有来自特定 Tableau Server 节点的监控数据。

它由升级前检查 #36b、#36c、#36d 检测到

RMT Server 升级完成后，代理会自动重新连接。等待 5-10 分钟来解决这个问题。否则，请检查以下内容：

• 验证代理服务是否正在每个代理主机上运行

• 如果代理运行的版本要旧得多，请升级它们以与 RMT Server 版本匹配

• 检查代理和 RMT Server 主机之间的网络连接（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：验证 config、log 和 data 目录的所有权和组成员身份

• 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 Master 和代理位于同一台计算机上，则代理的升级前检查（特别是检查 #38a）可能会错误地检测 Master 进程。由于脚本会扫描所有 tabrmt-* 进程，而不是严格筛选 tabrmt-agent-*，因此可能会触发假失败状态。

大多数环境使用单独的计算机，不会遇到这种情况。但是，如果您使用的是位于同一位置的安装程序并收到此特定故障，则可以使用以下方法安全地绕过检查并继续安装：

--skip-upgrade-checks

技术细节：

根本原因：检查 #38a 匹配过于宽泛的进程名称 (tabrmt-*)。

范围：仅影响 Master 和代理共享同一操作系统实例的就地升级。

风险等级：低。Master 进程超出了代理升级的范围，因此故障并不表示实际的系统冲突。