Tableau Server in a Container - トラブルシューティング

概要

Tableau Server in a Container は、Tableau 初のコンテナーベースのサーバー製品です。Tableau Server in a Container は、Linux Docker コンテナ内で実行されるオールインワンの Tableau Server インスタンスです。つまり、Tableau Server in a Container のイメージは、自己完結型の Tableau Server アプリケーション全体を実行する Docker イメージです。Tableau Server in a Container は、コンテナーベースの環境で Tableau Server の実行をサポートする数多くのステップの中の最初のステップとなります。Tableau Server in a Container の概念は、Tableau Server が事前にインストールされた VM のようなものと考えると、簡単に理解することができます。イメージは UBI 8 イメージ (バージョン 2022.1 以前は CentOS 7.x) に基づいており、コンテナー内で (systemd ではなく) supervisord を実行します。コンテナーが supervisord を開始すると、直ちに Tableau Server を初期化して起動しようとします。ここにあるドキュメントの多くは、Docker 環境に合わせて Tableau Server を実行できるように、構成を提供して自動化の活用方法を説明するためのものです。

Tableau Server in a Container のイメージのセットアップ ツールを使用すると、カスタム パッケージとアーティファクトを含むようにコンテナー イメージを作成してカスタマイズすることができます。このツールの主な機能の 1 つは、コンテナー イメージを構築し、カスタム データ コネクタをインストールすることです。

概念実証シナリオで Tableau Server in a Container をすばやくテストするには、Tableau Server in a Container のクイック スタートを参照してください。

制限事項

  • Tableau Server in a Container では、サーバー ATR を使用した ライセンス認証のみがサポートされます。これを行うには、コンテナーからインターネットにアクセスできる必要があります。したがって、エアギャップ環境におけるオフラインのライセンス認証はできません。
  • Tableau Server in a Container では現在、Resource Monitoring Tool (RMT) エージェントはサポートされていません。
  • Kerberos は、Tableau Server in a Container ではサポートされていません

トラブルシューティング

Tableau Server の実行中に問題が発生した場合、解決策を追求するための方法がいくつかあります。このセクションでは、ログの場所やログの意味など、Tableau Server のトラブルシューティングに関する一般的なアドバイスについて説明します。また、いくつかの特定の既知のシナリオと軽減パスについても説明します。

Tableau Support を使用して問題をデバッグしている場合は、以下を提供すると役立つ場合があります。

  • Tableau Server ログ (これらのログの収集については、以下で説明します)。
  • Docker コンテナー stdout ログ。
  • Tableau Server の Dockerfile (カスタマイズが行われている場合)。
  • 以下を含む展開構成:

    • Kubeconfig (または同等の展開構成)。
    • Tableau Server コンテナーを構成する静的構成ファイル。

インストールと初期化の失敗

Tableau Server を初めて初期化する場合、またはコンテナー内で新規インストールを実行した場合、サーバーはコンテナーを再起動するだけでは回復しません。インストールを試みるときは必ず、クリーンなデータ ディレクトリを使用する必要があります。これにより、以前のコンテナーの実行から永続的なボリューム データが削除される場合もあります。これを行う場合は、デバッグに役立つ可能性のあるログと情報を必ず保存してください。

失敗したインストールをデバッグする

Tableau Server コンテナーは、インストールの失敗が発生すると終了するように設計されています。このパターンによって、インストールの失敗がいつ発生したのかを特定する作業を簡単に自動化することができます。しかし、コンテナーが終了すると、調査可能なランタイム状態が残されないため、デバッグが困難になる可能性があります。初期化中に失敗した実行中のコンテナー内でデバッグ セッションを実行する場合は、次のステップに従います。

  1. コンテナー展開で新しい Tableau Server を準備します。
  2. コンテナーを環境変数 TSM_ONLY=1 を使用して実行するように構成します。環境変数 TSM_ONLY=1 は、TSM のみを初期化するように Tableau Server に指示します。これは、コンテナーを使用していない標準インストールの initialize-tsm スクリプトを実行している場合と同じ操作です。
  3. Tableau Server container を実行します。
  4. コンテナー内でシェルを開きます。
  5. Tableau Server が初期化されていなくても、TSM コマンドを実行できるようになりました。初期化中に通常行われる自動化を再開するには、tsm-commands スクリプト: "${DOCKER_CONFIG}"/config/tsm-commands を実行します

Tableau Support と Kubernetes

Tableau Server in a Container は、Kubernetes を使用して実行できますが、必須条件ではありません。今後、大半のお客様が、Kubernetes または関連するマネージド クラウド環境 (EKS、AKS、または GKS) のいずれかを使用して、Tableau Server in a Container を実行および管理していくことになるでしょう。

Kubernetes では、実行やデバッグするための環境が複雑になる可能性があり、多くの場合、個々の企業のインフラストラクチャとセットアップに対する依存関係が含まれています。このため、Tableau Support は、Tableau Server in a Container の実行に関連する Kubernetes (またはインフラストラクチャの展開) の問題を解決するための支援ができません。ただし、Docker コンテナー内の Tableau Server の実行はサポートされています。したがって、Kubernetes を使用して Tableau Server in a Container 実行する際に問題が発生した場合、Tableau Support は、Docker コンテナー自体が正しく機能しているかの検証のみを行います。

Kubernetes を使用して Tableau Server in a Container を実行する方法については、次の Github サイトを参照してください https://github.com/tableau/tableau-server-in-kubernetes(新しいウィンドウでリンクが開く)

ログ

ログは、Tableau Server の問題を見つけ、理解し、解決するために不可欠なリソースです。サポート チームはこれらを使用することで、発生した問題の根本原因を見つけることができます。ログは、独自のデバッグやトラブルシューティングにも役立つ場合があります。

すべてのログを抽出する

デバッグをさらに進めたり、サポート チームに送信したりするためにすべてのログを抽出する必要がある場合は、いくつかの方法でこの情報を取得することができます。

Ziplogs

TSM は、関連するすべてのサーバー ログを含む圧縮アーカイブを作成できます。これをトリガーするには、tsm maintenance ziplogs コマンドを実行します。コマンドが完了すると、ログ アーカイブのファイル パスが報告されます。アーカイブは、状況に最も適したファイルの転送方法を使用してコピーする必要があります。Ziplogs の詳細については、tsm maintenance ziplogsを参照してください。

コンテナ内で実行されるコマンドの例:

tsm maintenance ziplogs
手動の tar コマンド

ziplogs コマンドを実行できない場合、たとえば、サーバーが一貫性のある状態に到達できない場合でも、コンテナー内で tar コマンドを実行するとログを取得できます。アーカイブは、状況に最も適したファイルの転送方法を使用してコピーする必要があります。

コンテナ内で実行されるコマンドの例 (tar をコンテナのデータ ディレクトリの一時ディレクトリに書き込みます):

tar -zcvf /var/opt/tableau/tableau_server/temp/<archive_name>.tar.gz \
/var/opt/tableau/tableau_server/data/tabsvc/logs/. \
/var/opt/tableau/tableau_server/supervisord/ \
/var/opt/tableau/tableau_server/data/tabsvc/config/ \
/docker/.metadata.conf \
--exclude='*keystores' --exclude='*.jks' --exclude='*.tks' \
--exclude='*asset_keys.yml' --exclude='*.ks' --exclude='*.ts' \
--exclude='*.crt' --exclude='*cacerts' --exclude='*.key'
ログの操作とデバッグのヒント

Tableau Server のほぼすべての問題を診断できる一般的なステップがあります。サーバー ログを確認することを検討している場合は、サーバー ライフサイクルのどこでエラーが発生したかに応じて、検索する情報を分類することができます。

コンテナーを起動する (初期/インストール)

コンテナーがすぐにクラッシュしたり、インストールや初期化に失敗したりする場合は、次のリソースを確認してください。

コンテナーの stdout

Dockerコンテナーの stdout を調べます。stdout にはたいてい、コンテナー オーケストレーション システム (Kubernetes など) によって収集されたコンテナー出力を確認することでアクセスできます。Tableau Server はコンテナ内で実行されるマルチプロセス システムであるため、起動時に壊滅的な障害が発生しない限り、stdout はそれほど有用ではなく、問題の根本原因も報告されません。Tableau Server ログをさらに掘り下げる前に、問題が発生しているコンテナーの stdout をチェックすることをお勧めします。

例:

docker logs <container-name>

Tableau Server コンテナーの起動ログ

Tableau Server Container の起動ログは、Tableau Server の初期化、構成、および起動を行う自動化からの出力を取得します。コンテナーを初めて起動または実行しているときに問題が発生していることがわかった場合、最初に以下のログを確認します。

/var/opt/tableau/tableau_server/supervisord/run-tableau-server.log

ログの下部をチェックして、報告された障害があるかどうかを確認します。ログのエラー報告によって、問題がすぐに明らかになる場合もあります。ログでエラーが明らかになっていない場合は、根本的な原因がステージ固有またはサービス固有のログ ファイルにのみ表示されている可能性があります。このような可能性に該当するのは、以下にリストされているログです。

Tableau Server インストール ログ

起動ログに、TSM の初期化ステージを処理する自動化に問題があったことが示されている場合は、次のログを確認してください。

/var/opt/tableau/tableau_server/logs/app-install.log

Tableau Server コントローラー ログ

起動ログにサーバー ステージ (CLI のみ) の初期化と起動に問題があったことが示されている場合は、tabadmincontroller サービス ログを確認してください。

/var/opt/tableau/tableau_server/data/tabsvc/logs/tabadmincontroller/tabadmincontroller_node1-0.log

このログ ファイルは、tabadmincontroller と呼ばれる特定のサービス向けのものです。Tabadmincontroller は、サーバーの初期化および起動機能の調整を行います。このログは複雑で冗長になる可能性があります。このログ ファイルのエラーは、まだ根本的な原因を示していない可能性があります。エラーは、tabadmincontroller が特定のタスクを完了するために依存しているサービスが原因で発生する場合があります。詳細については、以下のサーバー ランタイムのセクションを確認してください。

サービスログ - サーバー ランタイム

Tableau Server で通常の実行時に問題が発生した場合、またはサービスがタスクを完了できないか、ダウンしている場合は、サービス ログで詳細を確認できます。Tableau Server の一部として実行されているすべてのサービスには、サービス ログ ファイルがあります。調べるサービスがわかっている場合は、次の一般的なディレクトリでそのサービスのログを見つけることができます。

/var/opt/tableau/tableau_server/data/tabsvc/logs/<service_name>

ファイル パスの引数 <service_name> にサービスの名前を入力します。どのサービスでも、複数のタイプのログ ファイルを書き込むことができます。また、同じサービスを複数 (複数のインスタンス) 実行している場合は、すべてのサービス ログが同じサービス ディレクトリに書き込まれます。

一般的なサービス固有のログ ファイルの分類

この表では、Tableau Server サービスの最も一般的なサービス ログファイル名、タイプ、および説明について説明します。[Failure types (障害のタイプ)] 列は、特定の障害シナリオで役立つ可能性が高いログ ファイルを示します。

名前ファイル名の形式説明障害のタイプ
Control-Appcontrol_<service_name>_<node_id>-<instance_id>.logサービスのインストールと構成を行う control-app プロセスの情報が含まれています。これは多くの場合、サービス関連の情報が書き込まれる最初のログです。サービスのインストールと構成の失敗については、最初に以下を参照してください。インストール、構成、ステータスcontrol_backgrounder_node1-0.log
サービス ログ<service_name>_<node_id>-<instance_id>.log実行中のサービスのプライマリ ログ。多くの場合、このログには、spring/java アプリケーション レイヤーからの出力が含まれています。開始、ランタイム、ステータスbackgrounder_node1-1.log
Stdout ログstdout_<service_name>_<instance_id>.logサービスの stdout 出力が含まれています。ほとんどのサービスは stdout にそれほど多くのコンテンツを出力しません。代わりに、プライマリ ログに書き込みます。このログには、サービスの終了時に役立つ情報が含まれている場合があります。起動、停止stdout_backgrounder_0.log
Native API ログnativeapi_<service_name>_<instance_id>.txt一部のサービスは、ネイティブ コード レイヤーを実行します。このログは、アプリケーションのランタイムのその部分を取得します。ライセンス発行、開始、ランタイム、ステータスnativeapi_backgrounder_1-1_2021_05_10_00_00_00.txt
Tomcat ログtomcat_<service_name>_<node_id>-<instance_id>.logこれは、Tomcat コンテナ内で実行されていて Tomcat ログを含むサービスのみに使用するログです。このログから、サービス障害に関する情報が提供されることはほとんどありません。これは、ネットワークの問題をデバッグする際に役に立ちます。ネットワーク、開始tomcat_backgrounder_node1-0.2021-05-10.log
停止したコンテナー

コンテナーが停止している場合、またはコマンドの実行が難しい場合でも、サーバーのデータ ディレクトリがマウントされたボリュームに外部化されていれば、ログを確認できます。それ以外の場合は、コンテナーの stdout は、コンテナーのオーケストレーション システムで調査できますが、多くの場合、根本的な原因は含まれていません。

認証プロパティの設定に失敗しました

アイデンティティ ストアを最初に設定せずに Tableau Server で認証プロパティを設定することに問題があるようです。この問題を回避するには、初期化前のフックにアイデンティティ ストアを設定します。

  1. Tableau Server イメージ ビルド ツールの customer-files ディレクトリで ./customer-files/pre_init_command というファイルを作成し、以下を含むように編集します。

    #!/bin/bash
    tsm configuration set -k wgserver.authenticate -v local --force-keys
  2. スクリプトを実行可能に設定します。

    chmod +x ./customer-files/pre_init_command
  3. イメージを構築して実行します。

新しい起動時のエラー (Tableau Server が起動しない理由など)

  • Tableau Server の初期化または起動に関する問題が発生する場合は、問題の発見に役立つトラブルシューティングオプションが多数あります。
  • コンテナーをまったく起動できない場合は、docker logs <container-name> コマンドを使用して PID 1 プロセスから stdout をチェックします。
  • コンテナーが実行中で、Tableau Server が初期化されていないか、正しく実行されていない場合、エラーを確認する 2 番目の場所は次のファイルです。
${DATA_DIR}/supervisord/run-tableau-server.log

例:

docker exec -it <container-name> bash -c 'cat $DATA_DIR/supervisord/run-tableau-server.log'

このログ ファイルには、Tableau Server の起動を処理する、さらに、コンテナーに提供した任意のセットアップスクリプトまたはカスタム設定を実行する、 tableau コンテナー初期化サービスによって調整されたすべてのイベントが含まれます。ほとんどのスタートアップ エラーは、ここで問題を報告します。エラーが TSM または Tableau Server プロセスに関連している場合は、詳細な情報を確認する別のログ ファイルが提案される場合があります。

既存のデータを使用してコンテナーを再起動または起動する際の障害

サーバーが Postgres (または他のプロセス) を起動しない

データがコンテナーの外部に永続化され、その古いデータを使用して別の Tableau Server in a Container イメージ のンスタンスを開始する場合、新しいコンテナーの内部ホスト名が、永続化されたデータを初期化したコンテナーのホスト名と一致する必要があることに注意してください。Tableau Server では動的ホスト名の変更をうまく処理しないため、内部ホスト名が異なる新しいコンテナーを起動すると、そのシナリオが実際に発生します。

この問題を解決するには、単に、コンテナーのホスト名が、そのデータで以前に実行されていたコンテナーと同じ値に設定されていることを確認します。これはマルチノードと混同しないように、ワーカーは互いに異なるホスト名を持つことができます(そしておそらく必要があります)。重要なのは、特定のコンテナが再起動されるか、後続のコンテナが先行コンテナと同じホスト名を持つ必要がある場合です。

展開構成の例

Docker

Tableau Server in a Container の基本的な使用例
docker run \
-e LICENSE_KEY=<key>
-p 8080:8080
--hostname=<static (internal) name of host machine> \
-d <Tableau Server in a Container image ID or tag>
自動化された初期管理ユーザーによる Tableau Server in a Container の基本的な使用例
docker run \
-e LICENSE_KEY=<key> \
-e TABLEAU_USERNAME=<myadmin> \
-e TABLEAU_PASSWORD_FILE=/etc/tableau-admin-secret \
-v <full-path-to-pw-file>:/etc/tableau-admin-secret \
--hostname=<static (internal) name of host machine> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>
TSM 専用モード
docker run \
-e TSM_ONLY=1 \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>
マルチノードの基本的な使用例
最初のノード

オプション 1: サーバー構成 (CONFIG_FILE) でマルチノード トポロジが指定される場合にこれを使用します。

docker run \
-v <network-shared-directory>:/docker/config/bootstrap \
-v <full-path-to-config-file>:/docker/config/config.json:ro \
-e LICENSE_KEY=<key> \
-p 8080:8080 -p 8800-9000:8800-9000 -p 27000-27010:27000-27010 \
--hostname=<name-of-host-machine> \
-d <Tableau Server in a Container image ID or tag>

オプション 2: サーバー構成でマルチ ノードトポロジが指定されていない場合でも、マルチノード展開が必要な場合は、これを使用します。

docker run \
-v <network-shared-directory>:/docker/config/bootstrap \
-e LICENSE_KEY=<key> -e ALWAYS_WRITE_BOOTSTRAP_FILE=1 \
-p 8080:8080 -p 8800-9000:8800-9000 -p 27000-27010:27000-27010 \
--hostname=<name-of-host-machine> \
-d <Tableau Server in a Container image ID or tag>
追加ノード
docker run \
-v <network-shared-directory>:/docker/config/bootstrap \
-e BOOTSTRAP_INSTALL=1 \
-p 8080:8080 -p 8800-9000:8800-9000 \
--hostname=<static (internal) name of host machine> \
-d <Tableau Server in a Container image ID or tag>
データ使用の外部化
docker run \
-v <empty-data-dir>:/var/opt/tableau \
-e LICENSE_KEY=<key> \
---hostname=<static (internal) name of host machine> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>
Init コンテナーの基本的な使用例

Init コンテナー

docker run \
-v <empty-data-dir>:/var/opt/tableau \
-e LICENSE_KEY=<key> \
-e INIT_CONTAINER=1 \
--hostname=<static (internal) name of host machine> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>

コンテナーの実行

docker run \
-v <empty-data-dir>:/var/opt/tableau \
--hostname=<static (internal) name of host machine> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>
シングルノード バックアップからの基本的な復元
docker run \
-v <full-path-to-backup-file>:/docker/config/backup/backup-file.tsbak \
-v <full-path-to-config-only-file>:/docker/config/config.json:ro \
-e LICENSE_KEY=<key> \
-p 8080:8080 -d <Tableau Server in a Container image ID or tag>

Docker の構成

version: '3.2'
services:
    tableau-server:
         hostname: localhost
         volumes:
              - <your-tsm-command-file>:/docker/config/tsm-commands:ro
              - <your-config-file >:/docker/config/config.json:ro
         ports:
              - "8080:8080"
         image: ${IMAGE_NAME}
         environment:
              - LICENSE_KEY=<license-key>