---
schema_version: "1"
id: 2b50528bcc88d2c9d2b2d0c6b38f5a3ae20ed3e9c7a62a42fe4ab36eb475306f
title: アップグレード後のエラーのトラブルシューティング方法
collection: tableau
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/tableau/current/ja-jp/server/rmt-troubleshoot-upgrade.md
canonical_url: https://help.tableau.com/current/server/ja-jp/rmt-troubleshoot-upgrade.htm
source_site: help.tableau.com
content_type: documentation
content_hash: de47c3f4beac2d0bf8c7d3a51ef1d7c7daae232a06526f916f4a08e6b94813b2
description: Troubleshoot errors encountered after upgrading the Resource Monitoring Tool.
---
[メイン コンテンツに進む](#main-content)

# アップグレード後のエラーのトラブルシューティング方法

次のセクションでは、アップグレード後のチェックで頻繁に特定される問題、またはアップグレード直後に見られる問題について詳しく説明します。

アップグレード前後のチェックについては、[「アップグレード リファレンス」](https://help.tableau.com/current/server/ja-jp/rmt-admin-upgrade-reference.htm)セクションを参照してください。

## サービスが稼動していない

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 クッキー ファイルが存在し、正しいパーミッションが設定されていることを確認します

## メッセージ キューのバックログ

RMT Web UI でデータが遅延して表示され、ダッシュボードに古いメトリクスが表示されません。

これは、アップグレード後のチェック #8 で検出されます

アップグレード直後にバックログが生じるのは、エージェントが再接続してバッファ内のデータを再送信するため、正常な動作です。これを修正するには、次の手順を実行します。

- 「rmtadmin status」で監視します。バックログは 15 ～ 30 分以内にクリアされます。
- バックログが解消しない場合は、すべてのエージェント サービスが実行され、接続されていることを確認します。

## RMT サーバーのワーカーがデータを消費していない (アップグレード後にデータが取り込まれていない)

すべての RMT サービスが「実行中」と報告され、アップグレード後のチェックでサービス/ポート/接続が合格しますが、Web UI には新しいデータが表示されず、エージェントには「接続の問題」として表示されます。\``rmtadmin status`\` を実行すると、メッセージが蓄積されているが、コンシューマー数が \*\*0\*\* のキューが 1 つ以上表示されます。

これは、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 で検出されます

これを修正するには、次の手順を実行します。

- OS レベルの 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」ではなく) に設定されていることを確認してください
- 古いログ ファイルをアーカイブするか、削除します

## ログ内の FATAL (致命的な) エラーまたは CRITICAL (重大な) エラー

アップグレード後に予期しない動作が発生したり、サービスが不安定になったりします。

これは、アップグレード後のチェック #15 で検出されます

これを修正するには、次の手順を実行します。

- アップグレードの直後に発生する「ブローカーに到達できません」エラーは、通常、一時的なものです。RabbitMQ が稼動していることを確認します
- その他の FATAL (致命的な) エラーについては、ログ エントリ全体を確認し、ログ ファイルを添えて 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 Support に連絡して、バージョン固有のパッチを入手してください。

## Hangfire のクリーンアップの破損 (W-19380780)

データベースが継続的に増大しており、 `hangfire` スキーマのサイズが異常に大きくなっています (1 GB 超)。

これは、アップグレード前のチェック #21d と #21g で検出されます

これを修正するには、次の手順を実行します。

- 固定バージョンにアップグレードすると、`delete_hash()` 関数の不安定な動作が修正されます
- hangfire スキーマで孤立した行は、手動によるクリーンアップが必要になる場合があります。Tableau サポートにお問い合わせください。

## データベースのクリーンアップが無効化される

データベースのサイズが時間の経過とともに際限なく増大し、アップグレードが低速になります。

これは、アップグレード前のチェック #21c で検出されます

これを修正するには、次の手順を実行します。

- `db:cleanup:type` で `Purge` を `config.json` に設定します。
- `db:cleanup:afterDays` を 30 ～ 90 日に短縮します (既定: 14)
- 変更を反映させるには、RMT Director サービスをもう一度起動してください

## ファイル パーミッションに関する問題

サービスの開始に失敗するか、構成の読み取りまたはログの書き込みができません。

これは、アップグレード後のチェック #4、アップグレード前のチェック #11 ～ #16 で検出されます

これを修正するには、以下を確認してください。

- Linux: 構成、ログ、データのディレクトリの所有権とグループ メンバーシップの確認してください
- Windows: サービス アカウントにインストール ディレクトリへの読み取り/書き込みアクセス権があることを確認してください。
- 新規インストール後にパーミッションの問題が解決しない場合は、Tableau サポートにお問い合わせください

## rmtadmin の停止後に RMT プロセスが残る

文書化されたアップグレード手順に従って `rmtadmin stop` を実行しても、1 つまたは複数の `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-agent-\* を厳密にフィルタリングするのではなく、すべての tabrmt-\* プロセスをスキャンするため、誤った **FAIL** ステータスが発生する可能性があります。

ほとんどの環境では個別のマシンが使用されているため、これは発生しません。ただし、コロケーション セットアップを使用していて、この特定のエラーが発生した場合は、次を使用してチェックを安全にバイパスし、インストールを続行できます。

`--skip-upgrade-checks`

技術的な詳細は次のとおりです。

根本原因: チェック #38a が、範囲が広すぎるプロセス名 (tabrmt-\*) と一致しています。

範囲: マスターとエージェントが同じ OS インスタンスを共有しているインプレース アップグレードにのみ影響します。

リスクレベル: 低。マスター プロセスはエージェントのアップグレードの対象外であるため、このエラーは実際のシステムの競合を示すものではありません。