データ接続と統合Data ConnectionAgentトラブルシューティングリファレンス

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

トラブルシューティングリファレンス

このページでは、Agent ログの設定方法、Agent 設定に関する一般的な問題、およびデバッグの手順について説明します。

Agent Manager は、インストール先のサーバーでは「bootvisor」と呼ばれます。

ここで説明する手順は、Agent がインストールされているホストに SSH で接続してから実行する必要があります。ほかのトラブルシューティング項目を調べる前に、まず ./var/diagnostic/launch.yml を確認し、Agent が Foundry に正常に接続したことを確認することを推奨します。接続に失敗した場合は、enhancedMessage フィールドに記載されている手順に従ってください。

証明書の有効期限が切れた後に Agent の接続を復旧する

Agent 設定に関する一般的な問題

Agent と Agent Manager のステータスが「オフライン」と表示されるが、Agent ホストでは「実行中」が返される
Agent Manager のステータスが「オフライン」と表示される
Bootstrapper のステータスが「報告なし」と表示される
Agent が「オンライン」と表示されるが、再起動に応答しない
Agent のステータスが「異常」と表示される
Agent パッケージをダウンロードできない
Agent を管理できない
PERMISSION_DENIED エラーにより Agent を作成できない

Agent 設定リファレンス

安全でない TLSv1.0 および TLSv1.1 プロトコルを使用してデータソースに接続する
Agent ログを設定する
Agent がインストールされているホストがクラッシュすると、キャッシュされたファイルはどうなりますか？

証明書の有効期限が切れた後に Agent の接続を復旧する

Foundry への接続に必要な証明書が、代わりの証明書をインストールする前に有効期限切れになったり、ローテーションされたりすると、Agent Manager は Foundry に接続できなくなることがあります。これには、Foundry を信頼するために使用する証明書と、TLS トラフィックを検査するプロキシの証明書が含まれます。Agent 証明書を管理から代わりの証明書を追加するだけでは、接続が切れた Agent Manager を復旧できません。更新を取得するには、有効な接続が必要です。

ホスト上の Agent Manager ログで、SSLHandshakeException、PKIX path building failed、CertificateExpiredException などの証明書の検証エラーを確認します。現在の認証局 (CA) の証明書を、Foundry の場合は Palantir サポートから、プロキシの場合はネットワーク管理者から取得します。Foundry またはプロキシが引き続き有効期限切れのサーバー証明書を提示している場合、Agent の接続を復旧する前に、その管理者が証明書を更新する必要があります。

Data Connection のAgent 証明書を管理を使用して、影響を受けている Agent に必要な証明書を追加し、以下の復旧方法のいずれかを選択します。影響を受けている Agent ごとにこの手順を繰り返します。

ホスト上のトラストストアを更新する

ホストと Agent Manager のトラストストアにアクセスできる場合は、デフォルトの Linux インストールに対して次の手順を使用します。これにより、既存のインストールを修復し、ソースの資格情報を保持します。

Agent Manager を実行するユーザーとしてホストに接続します。インストールディレクトリに移動し、自動再起動が設定されている場合は無効にして、Agent Manager を停止し、トラストストアをバックアップします。
```
Copied!1
2
3
4
cd <agent-manager-install-directory>
./service/bin/auto_restart.sh clear
./service/bin/init.sh stop
cp var/security/truststore.jks var/security/truststore.jks.bak
```
必要な CA 証明書をそれぞれ別の PEM ファイルとしてホストに保存します。同梱の Java を使用して各証明書を Agent Manager のトラストストアにインポートし、証明書ごとに未使用のエイリアスを選択します。
```
Copied!1
2
cd jdk/amazon-corretto*
./bin/keytool -importcert -alias <CERT_ALIAS> -file /path/to/certificate.pem -keystore ../../var/security/truststore.jks
```
このトラストストアのデフォルトのパスワードは truststore です。インポートを受け入れる前に、証明書の提供元にフィンガープリントを確認してください。トラストストアで別のパスワードが使用されていて、そのパスワードを取得できない場合は、Agent を再インストールする手順に従ってください。
Agent Manager のインストールディレクトリに戻り、起動します。
```
Copied!1
2
cd <agent-manager-install-directory>
./service/bin/init.sh start
```
Data Connection で、Agent Manager が再接続したことを確認します。Agentを再起動を選択し、Agent 証明書を管理から追加した証明書を適用してから、Agent Manager と Agent の両方が接続されていることを確認します。以前に自動再起動が有効だった場合は、再度有効にします。

現在の証明書で再インストールする

ローカルのトラストストアを更新できない場合は、現在の証明書を含む新しいパッケージを使用して、既存の Agent を再インストールします。

Data Connection で証明書を追加した後、既存の Agent の概要ページで Agent を再インストールを選択し、新しいダウンロード URL を取得します。新しいパッケージをダウンロードします。古いパッケージには引き続き以前の証明書が含まれています。
Agent を再インストールするの手順に従い、古いインストールの停止とソース暗号化キーの保持も行います。既存のソースの資格情報を引き続き使用できるように、古いインストールの var/data/source-encryption-key と var/data/source-encryption-key.private を保持してください。
Data Connection で、Agent Manager と Agent の両方が再接続したことを確認します。

Agent 設定に関する一般的な問題

Agent と Agent Manager が「オフライン」ステータスを表示するが、Agent ホストでは「実行中」を返す

まず、Agent がインストールされているホストから Foundry にアクセスできることを確認します。そのためには、Agent がインストールされているホストで curl -s https://<your domain name>/magritte-coordinator/api/ping > /dev/null && echo pass || echo fail を実行します。
- すべてが正常に動作している場合、出力として pass が表示されます。その場合は、次の手順を実行します。
  - Foundry にアクセスするためにプロキシが必要かどうかを確認します。必要な場合は、Agent がプロキシを使用するように設定されているかどうかを確認します（Agent がプロキシを使用するように設定する手順は、プロキシ設定ページに記載されています）。Unix ベースのマシンのコマンドラインで echo $http_proxy を実行すると、プロキシが使用されているかどうかを確認できます。
  - プロキシは不要だと考えられる場合、またはすでにプロキシを設定している場合は、Palantir の担当者にお問い合わせください。
- ホストから Foundry にアクセスできない場合、curl: (6) Could not resolve host: ... のようなエラーが表示されることがあります。この場合、接続をブロックしているもの（ファイアウォールやプロキシなど）がある可能性が高いため、Palantir の担当者にお問い合わせください。

Agent Manager が「オフライン」ステータスを表示する

<agent-manager-install-location>/var/log/startup.log ファイルの内容を確認します。
- Caused by: java.net.BindException: {} Address already in use というエラーが表示される場合、Agent Manager がバインドしようとしているポートですでにプロセスが実行されています。
  - この問題を解決するには、まず Agent Manager がどのポートにバインドしようとしているかを確認します。<agent-manager-directory>/var/conf/install.yml ファイルの内容を確認し、port パラメーターを探すことで確認できます（例：port: 1234 — ここでは1234がポートです）。ポートパラメーターが定義されていない場合、Agent Manager はデフォルトのポート7032を使用します。
  - Agent Manager がバインドしようとしているポートがわかったら、そのポートですでに実行されているプロセスを特定します。次のコマンドを実行すると特定できます：ps aux | grep $(lsof -i:<PORT> |awk 'NR>1 {print $2}' |sort -n |uniq)。ここで、<PORT> は Agent Manager がバインドしようとしているポートです。
    - 上記のコマンドが返すレスポンスに com.palantir.magritte.bootvisor.BootvisorApplication が含まれる場合、別の Agent Manager がすでに実行されています。
    - この場合、それが意図したものかどうかを確認します。意図したものである場合は、以下の手順に従って設定内のポートを変更し、2つの Agent Manager の競合を解消する必要があります。そうでない場合は、このホストで使用する Agent Manager のインストールを特定し、実行中のほかの Agent Manager を停止して、今後使用するものだけを起動する必要があります。
- BindException エラーを修正するには、Agent Manager 用に、現在使用されていない新しいポートを見つける必要があります。
  - ポート番号は1025から65536の範囲である必要があります（ポート番号0から1024は特権サービス用に予約されており、ウェルノウンポートとして指定されています）。
  - 次のコマンドを実行すると、ポートですでにプロセスが実行されているかどうかを確認できます：lsof -i :<PORT>。ここで、<PORT> は選択したポート番号です。
- 利用可能なポートが見つかったら、<agent-manager-directory>/var/conf/install.yml に保存されている設定に port パラメーターを追加（または更新）する必要があります。
- 以下は、ポートを 7032 に設定した Agent Manager の設定スニペットの例です。
```
Copied!1
2
3
...
port: 7032
auto-start-agent: true
```
- 上記の設定を保存したら、<agent-manager-root>/service/bin/init.sh stop && <agent-manager-root>/service/bin/init.sh start を実行して Agent Manager を再起動します。

Bootstrapper が「報告なし」ステータスを表示する

<agent-manager-directory>/var/data/processes/<latest-bootstrapper-directory>/var/log/startup.log ファイルの内容を確認します。
- Caused by: java.net.BindException: {} Address already in use というエラーが表示される場合、Bootstrapper がバインドしようとしているポートですでにプロセスが実行されています。
  - この問題を解決するには、まず Bootstrapper がどのポートにバインドしようとしているかを確認します。Data Connection アプリケーション内の Agent 概要ページに移動して確認できます。そこで「詳細」設定ボタンを選択し、最後に「Bootstrapper」タブをクリックします。Bootstrapper がバインドしようとするポートは、port パラメーターで定義されています（例：port: 1234 — ここでは1234がポートです）。Bootstrapper のデフォルトのポートは7002です。
  - Bootstrapper がバインドしようとしているポートがわかったら、そのポートですでに実行されているプロセスを特定します。次のコマンドを実行すると特定できます：ps aux | grep $(lsof -i:$PORT |awk 'NR>1 {print $2}' |sort -n |uniq)。ここで、$PORT は Bootstrapper がバインドしようとしているポートです。
    - 上記のコマンドが返すレスポンスに com.palantir.magritte.bootstrapper.MagritteBootstrapperApplication が含まれる場合、別の Bootstrapper がすでに実行されています。
    - この場合、それが意図したものかどうかを確認します。意図したものである場合は、以下の手順に従って設定内のポートを変更し、2つの Bootstrapper の競合を解消する必要があります。そうでない場合は、このホストで使用する Bootstrapper のインストールを特定し、実行中のほかの Bootstrapper を停止して、今後使用するものだけを起動する必要があります。
- BindException エラーを修正するには、Bootstrapper 用に、現在使用されていない新しいポートを見つける必要があります。
  - ポート番号は1025から65536の範囲である必要があります（ポート番号0から1024は特権サービス用に予約されており、ウェルノウンポートとして指定されています）。
  - 次のコマンドを実行すると、ポートですでにプロセスが実行されているかどうかを確認できます：lsof -i :<PORT>。ここで、<PORT> は選択したポート番号です。
- 利用可能なポートが見つかったら、Bootstrapper の設定で port パラメーターを設定する必要があります。これには、Data Connection アプリケーションの Agent 概要ページに移動します。そこで詳細設定ボタンを選択し、最後に「Bootstrapper」タブに移動します。
- 以下は、ポートを 7002 に設定した Bootstrapper の設定スニペットの例です。
```
Copied!1
2
3
4
server:
  adminConnectors:
    ...
    port: 7002 #This is the port value
```
- 設定を更新したら、変更を保存し、Agent を再起動して変更を反映する必要があります。

Agent が「オンライン」を表示するが、再起動に応答しない

多くの場合、これは Agent の別の「ゴースト」インスタンスが実行されていることが原因です。このインスタンスを見つけて停止する必要があります。

古いプロセスを見つけて終了するには、以下の手順に従います。

<agent-manager-install-location>/service/bin/init.sh stop を実行して Agent Manager を停止します。
<agent-manager-install-location>/var/data/processes/index.json ファイルを削除します。
for folder in $(ls -d <agent-manager-root>/var/data/processes/*/); do $folder/service/bin/init.sh stop; done を実行して古いプロセスを停止します。
Data Connection に戻り、Agent からの報告が停止したことを確認します（2〜3分かかります）。
Agent Manager を起動します（<agent-manager-install-location>/service/bin/init.sh start）。

Data Connection を介さずに、Agent がインストールされているホストで手動で Agent を起動すると、「ゴースト」プロセスが作成されることがあります。

Agent のステータスが「異常」と表示される

Agent プロセスが「異常」と表示される場合、多くはクラッシュしたか、オペレーティングシステムまたはウイルス対策ソフトウェアなどの別のソフトウェアによって停止されたことが原因です。

オペレーティングシステムがプロセスを停止する理由はいくつかありますが、最も一般的なのは、プロセスの実行に必要なメモリーが不足していることです。これは OOM（Out Of Memory）による強制終了と呼ばれます。

Agent または Explorer のサブプロセスがオペレーティングシステムによって OOM で強制終了されたかどうかを確認するには、次のコマンドを実行できます：grep "exited with return code 137" -r <agent-manager-directory> --include=*.log。このコマンドは、Agent Manager ディレクトリー内のすべてのログファイルから「exited with return code 137」を含むエントリーを検索します（リターンコード137は、プロセスが OOM で強制終了されたことを示します）。

上記のコマンドによる出力例を次に示します。この例では、Agent サブプロセスが OOM で強制終了されています：./var/data/processes/bootstrapper~<>/var/log/magritte-bootstrapper.log:ERROR [timestamp] com.palantir.magritte.bootstrapper.ProcessMonitor: magritte-agent exited with return code 137。このような出力が表示された場合は、以下のヒープサイズを調整する手順に沿って進めてください。

次のコマンドを実行して、オペレーティングシステムのログに OOM による強制終了のエントリーがあるかどうかを確認することもできます：dmesg -T | egrep -i 'killed process'。このコマンドは、カーネルのリングバッファーから「killed process」というログエントリーを検索します。このエントリーは、プロセスが OOM で強制終了されたことを示します。

OOM で強制終了されたプロセスの実際のログエントリーは、次のようになります。

[timestamp] Out of memory: Killed process 9423 (java) total-vm:2928192kB, anon-rss:108604kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:1232kB oom_score_adj:0
上記のログ行は、強制終了されたプロセスの PID が9423であったことを示しています（注：ログメッセージは、Linux ディストリビューションやシステム設定によって異なる場合があります）。
この場合、強制終了されたプロセスが Agent に関連しているかどうかを確認してください。最も簡単な方法は、タイムスタンプを揃えて比較することです。つまり、エントリーのタイムスタンプが Agent のステータスが異常になった時刻と一致していれば、両者は関連している可能性が高いと考えられます。なお、(java) を含まないエントリーは Agent に関連していないため、無視できます。

ヒープサイズを調整する

ヒープの割り当てを変更する前に、まず次のことを行ってください。

ホストで利用可能なメモリー量を計算します。
ホストで利用可能なメモリー量を確認するには、free -h を実行できます。6 GB のシステムでは、出力は次のようになります。

Copied!1
2
3
                total        used        free      shared  buff/cache   available
Mem:          5.8Gi       961Mi       2.8Gi       9.0Mi       2.1Gi       4.6Gi
Swap:         1.0Gi          0B       1.0Gi

free コマンドの出力では、available 列に、新しいアプリケーションの起動に使用できるメモリー量が表示されます。Agent に割り当てられるメモリー量を判断するには、Agent を停止し、システムが通常から高負荷の状態にあるときに free -h を実行することを推奨します。available の値は、すべての Agent プロセスに合計で割り当てられる最大メモリー量を示します。システム上のほかのプロセスが追加のメモリーを必要とする場合や、Agent プロセスがオフヒープメモリーを使用する場合に備えて、可能であれば約2 - 4 GB の余裕を残すことを推奨します。free のすべてのバージョンで available 列が表示されるわけではないため、同等の情報を確認する方法について、お使いのシステムのバージョンに対応するドキュメントを確認する必要がある場合があります。

Agent Manager、Bootstrapper、Agent、Explorer の各サブプロセスに割り当てられているメモリー量を確認します。

Agent および Explorer のサブプロセスに割り当てられているメモリー量を確認するには、Data Connection 内の Agent 設定ページに移動し、詳細設定ボタンを選択して、Bootstrapper タブを選択します。各サブプロセスにはそれぞれ設定ブロックがあり、各ブロック内の jvmHeapSize パラメーターで、関連するプロセスに割り当てるメモリー量が定義されています。

デフォルトでは、Bootstrapper サブプロセスには 512mb のメモリーが割り当てられています。これを確認するには、まず <agent-manager-directory>/var/data/processes/ ディレクトリーに移動し、ls -lrt を実行して、最後に作成された bootstrapper~<uuid> ディレクトリーを探します。最後に作成された bootstrapper~<uuid> ディレクトリーに移動したら、./var/conf/launcher-custom.yml ファイルの内容を確認できます。このファイルの Xmx 値が、Bootstrapper に割り当てられているメモリー量です。

デフォルトでは、Agent Manager サブプロセスにも 512mb のメモリーが割り当てられています。これは、<agent-manager-directory>/var/conf/launcher-custom.yml ファイルの内容を確認することで確認できます。このファイルの Xmx 値が、Agent Manager に割り当てられているメモリー量です。

Windows マシンにインストールされた Agent は launcher-custom.yml ファイルを使用しないため、デフォルトでは、Java が Agent Manager と Bootstrapper の各プロセスに、システムで利用可能な総メモリーの25%を割り当てます。これを修正するには、Agent Manager と Bootstrapper のヒープサイズを手動で設定する必要があります。次の手順で設定できます。

すべての Agent プロセス（Agent Manager、Bootstrapper、Agent、Explorer）を強制終了したことを確認してください。
JAVA_HOME を設定します：setx -m JAVA_HOME "{BOOTVISOR_INSTALL_DIR}\jdk\{JDK_VERSION}-win_x64\"
Agent Manager のヒープサイズを設定します：setx -m MAGRITTE_BOOTVISOR_WIN_OPTS "-Xmx512M -Xms512M"
Bootstrapper のヒープサイズを設定します：setx -m MAGRITTE_BOOTSTRAPPER_OPTS "-Xmx512M -Xms512M"
コマンドプロンプトを閉じ、新しく開き直します。これは、上記の設定を有効にするために必要です。
Agent Manager を起動します：.\service\bin\magritte-bootvisor-win

ホストで利用可能なメモリー量と、上記の各サブプロセスに割り当てられているメモリー量を確認したら、上記のプロセスに割り当てるメモリー量を減らすか、ホストで利用可能なメモリー量を増やすかを判断します。

Agent プロセスが使用するメモリー量を安全に減らせるかどうかは、Agent の設定（たとえば、同時同期の最大数やファイルアップロードの並列度）、同期するデータの種類、および Agent の通常の負荷によって異なります。ヒープサイズを減らすと、OS がプロセスを強制終了する可能性は低くなりますが、Java プロセスがヒープ領域を使い切る可能性は高くなります。適切な値を見つけるために、異なる値をテストする必要がある場合があります。この値の調整について支援が必要な場合は、Palantir の担当者にお問い合わせください。

1個または複数のサブプロセスに割り当てるメモリー量を減らすには、次の手順を実行します。

前述の各サブプロセスに割り当てるメモリー量を決めます。
- 注：ヒープサイズを、以下に示すデフォルト値より小さくすることは推奨しません。
次に、Data Connection 内の Agent に移動し、詳細設定ボタンを選択して、Bootstrapper タブを選択します。
ここで、各サブプロセスの jvmHeapSize パラメーターを設定できます。
以下は、Agent の jvmHeapSize を3gbに設定した Bootstrapper 設定スニペットの例です。
```
Copied!1
2
3
agent:
    ....
    jvmHeapSize: 3g #This is jvm heap size value
```
設定を更新したら、変更を保存し、Agent を再起動して変更を有効にする必要があります。

デフォルトのヒープ割り当て

デフォルトでは、Agent には約3gbのメモリーが必要で、次のように割り当てられます。

Agent サブプロセスに1gb
Explorer サブプロセスに1gb
Bootstrapper サブプロセスに512mb
Agent Manager サブプロセスに512mb

Java プロセスはオフヒープメモリーも使用するため、これらのプロセス用に少なくとも4gb以上の空きメモリーを確保することを推奨します。

Agent パッケージをダウンロードできない

Agent のダウンロードに失敗する主な原因は、ネットワーク接続とリンクの有効期限切れの2つです。

Foundry に接続できても、ダウンロードした tar.gz ファイルが無効だったり、ダウンロード時にエラーメッセージが表示されたりする場合は、リンクの有効期限が切れているか、リンクが無効化されている可能性があります。

有効期限切れのリンク： ダウンロードリンクの有効期限は10分です。
無効化されたリンク： ダウンロードリンクは、1回限りのダウンロード用シークレットで保護されています。Microsoft Teams などのアプリケーションに Agent のダウンロードリンクを貼り付けると、リンクが無効化されることがあります。これらのアプリケーションは、プレビューできるかどうかを確認するためにリンクをスキャンしようとするためです。このスキャンによって、1回限りのダウンロード用シークレットが無効化されます。リンクが無効な場合は、UI でリンクを再生成し、リンク全体をコピーする代わりに、2つのシークレット単語を再入力してみてください。

Agent パッケージのダウンロード中に disconnected unexpectedly エラーが発生した場合は、ダウンロードコマンドに --http1.0 フラグを追加して、curl が HTTP 1.0 を使用するようにしてみてください。これにより、特定のネットワーク環境で発生する可能性があるプロトコルネゴシエーションの問題を解決できる場合があります。

Agent を管理できない

プロジェクト内に Agent を作成するには、そのプロジェクトの編集者である必要がありますが、プロジェクト内の Agent を管理するには、そのプロジェクトの所有者である必要があります。そのため、Agent を作成できても、その Agent のダウンロードリンクの生成やその他の管理タスクを実行できない場合があります。Agent の権限の詳細については、権限リファレンスドキュメントのガイダンスを参照してください。

PERMISSION_DENIED エラーにより Agent を作成できない

Agent を作成しようとした際に PERMISSION_DENIED エラーが表示された場合は、以下を確認してください。

組織レベルのロール： 組織管理者、データフロー管理者、または Agent を作成ワークフローを含むカスタムロールが割り当てられている必要があります。組織のロールは、Control Panel の組織権限ページで管理します。
プロジェクトレベルのロール： 新しく作成する Agent の保存先プロジェクトの編集者または所有者である必要があります。

既存のプロジェクトで編集者権限しか持っておらず、必要な組織レベルのロールがない場合は、適切な権限を持つ別のプロジェクトで Agent を作成してみるか、管理者に必要なロールをリクエストしてください。

Agent の権限の詳細については、権限リファレンスドキュメントのガイダンスを参照してください。

Agent 設定リファレンス

安全でない TLSv1.0 および TLSv1.1 プロトコルを使用してデータソースに接続する

TLSv.1.0 および TLSv1.1 は古く、安全でないプロトコルのため、Palantir はこれらに対応していません。Data Connection の Agent が使用する OpenJDK の Amazon Corretto ビルドでは、java.security ファイルの jdk.tls.disabledAlgorithms セキュリティプロパティで、TLSv1.0 および TLSv1.1 がデフォルトで明示的に無効化されています。

TLSv1.0 および TLSv1.1 のみをサポートするデータソースシステムへの接続は、Error: The server selected protocol version TLS10 is not accepted by client preferences などのさまざまなエラーで失敗します。

非推奨の TLS バージョンは使用しないことを強く推奨します。Palantir は、その使用に伴うセキュリティリスクについて責任を負いません。

TLSv1.0 および TLSv1.1 を一時的にサポートすることが不可欠な場合は、次の手順を実行します。

Agent の概要ページから Agent 設定に移動し、設定の管理セクションで詳細を選択します。次に、Bootstrapper タブを選択します。
agent と explorer の両方の設定ブロックに tlsProtocols エントリーを追加し、その値として有効にするプロトコルを指定します。TLSv1.2 を使用しているソースが動作しなくなることがないよう、TLSv1.2 も必ず含めてください。例：

Copied!1
2
3
4
5
6
7
8
9
10
11
12
agent:
    tlsProtocols:
      - TLSv1
      - TLSv1.1
      - TLSv1.2
...
explorer:
    tlsProtocols:
      - TLSv1
      - TLSv1.1
      - TLSv1.2
...

カスタムのレガシー TLS プロトコルが設定された Agent

Agentを再起動を選択します。

この設定により、Agent のアップグレードや再起動後も、TLSv1.0 および TLSv1.1 が引き続き許可されます。データソースが新しい TLS バージョンに移行したら、Agent の詳細設定に加えた変更をすべて元に戻してください。

Agent のログを設定する

Agent のホストマシン上のログ保存設定を調整するには、以下の手順を実行します。

Data Connection で、Agent ページに移動します。設定する Agent の名前を選択します。
設定パネルで、詳細を選択します。
ログの設定オプションは、ログブロックにあります。ここでは、ログの破棄を開始する条件となる上限、ログをアーカイブするかどうかとその方法、およびその他の設定を指定できます。
- 設定にあたっては、Agent のホストマシンに割り当てられたリソース、希望するログレベルの粒度、およびログ保持方針を考慮する必要があります。詳細情報とガイダンスについては、Dropwizard 設定リファレンス ↗ を参照してください。
画面の右上隅にある Agentを再起動を選択して、Foundry で Agent を再起動します。

これで新しい設定が有効になります。

Agent が停止（利用不可）してからどのくらい経っていますか？

Agent が利用できない理由はいくつかあります。たとえば、Agent が再起動中であるか、Agent を実行しているハードウェアがオフラインまたは再起動中である可能性があります。

Agent が最初に利用できなくなった時点を特定するには、2つの方法があります。

Data Connection の UI で Agent を選択すると、メトリクスタブで、稼働時間と可用性に関連するメトリクスを視覚的に確認できます。
Data Connection の UI の概要セクションでは、Agent のステータスと、そのステータスが最後に報告された日時を確認できます。

Agent がインストールされているホストがクラッシュすると、キャッシュされたファイルはどうなりますか？

ファイルは、Bootvisor が古いプロセスフォルダーをクリーンアップするまでディスク上に残ります（30日が経過するか、古いフォルダーが10個になるとクリーンアップが実行されます）。これらのファイルは暗号化されており、復号に必要なキーは、終了したプロセスのメモリー内にのみ存在していました。

←

PREVIOUSAgent プロキシの設定リファレンス

NEXTソース / ソースのセットアップ

→