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

トラブルシューティング

ソースが期待されるとおりに動作しない場合は、このページを使って問題を診断し、解決します。このページでは、Data Connection で利用可能なトラブルシューティングツール、接続が機能しないときに最初に確認すべき点、および一般的な接続や証明書の問題を解決する方法を説明します。

同期や Agent に固有の問題については、機能固有の問題を参照してください。

最初に確認すること

ソースや接続が機能しない場合は、まずこのリストに沿って確認します。

ソースに到達できることを確認します。 ソースページでプレビューを選択して、接続が確立されていることを確認します。接続に失敗した場合は、ソースターミナルを開き、ソースのホスト名とポートに対して dig、curl、openssl s_client を実行します。
エグレス設定を確認します。 Foundry ワーカーのソースでは、正しいエグレスポリシーがアタッチされていること、およびそのポリシーで許可されているアドレス、ポート、プロトコルがソースの接続先と一致していることを確認します。ネットワークエグレスログを確認します。
資格情報を確認します。 資格情報が古い可能性がある場合、特に移行後は、資格情報を再入力します。
証明書を確認します。 PKIX または SSLHandshakeException エラーは、ソースに正しい証明書が設定されていないことを示します。証明書と TLS を参照してください。
OAuth 認可を確認します。 ソースがアウトバウンドアプリケーションを使用している場合、HTTP 401: Unauthorized などのエラーは通常、呼び出し元ユーザーが対話型認可フローを完了していない、アウトバウンドアプリケーションが無効になっている、または設定されたスコープが不十分であることを示します。OAuth とアウトバウンドアプリケーションを参照してください。
AI FDE に引き継ぎます。 Foundry ワーカーのソースでは、AI FDE でデバッグするを使用すると、AI FDE がこれらの確認を順に行い、具体的な修正方法を提示します。

ソースが Agent ワーカーを使用している場合は、Data Connection で Agent がオンラインと表示されていることも確認し、ステータスごとのガイダンスについて Agent のトラブルシューティングリファレンスを確認します。

トラブルシューティングツール

Data Connection には、プラットフォームを離れることなく接続、認証、データ移動の問題を調査できる組み込みツールが用意されています。

AI FDE でデバッグする

Foundry ワーカーのソースでは、Palantir の AI を活用した Forward Deployed Engineer である AI FDE にデバッグを任せることができます。AI FDE は、ソースとそれに関連するエグレスポリシーをコンテキストに読み込み、このページで説明するエグレスログとソースのデバッグツールを使用して、接続の失敗を代わりに調査します。

ソースから AI FDE のデバッグセッションを開始するには、次の手順を実行します。

Data Connection アプリケーションで、デバッグするソースを開きます。
接続情報パネルで、デバッグの横にあるドロップダウンの矢印を選択し、AI FDE でデバッグを選択します。
AI FDE が新規タブで開きます。ソースとそのエグレスポリシーはコンテキストとして事前に読み込まれ、ソース設定の確認、各エグレスポリシーの確認、ネットワークエグレスログの取得、ライブ接続テストの実行を含むデバッグ計画が提案されます。

AI FDE は、正常に動作している部分と失敗している部分を要約し、具体的な修正方法を提案します（例：必要なエグレスポリシーがない、アドレスやポートが正しくない、TLS 設定の問題、資格情報の問題）。

AI FDE でデバッグは、Foundry ワーカーのランタイムを使用するソースでのみ利用可能です。AI FDE を使用するには、エンロールメントで AIP を有効にする必要があります。AI FDE の仕組み、できること、コンテキストと権限の管理については、AI FDE の概要で詳しくはこちらをご覧ください。

ソースターミナル

ソースと同じ接続設定を使用するターミナルを利用できます。dig、curl、netcat、openssl などのコマンドを使用して、外部システムとのネットワーク接続をテストできます。

ターミナルを開くには、ソースページの接続情報にあるネットワーク接続パネルで、デバッグを選択します。

ソースターミナルには、ソースページの接続情報にあるネットワーク接続パネルでデバッグを選択してアクセスできます。

`dig`

dig コマンドは DNS 名前解決をテストし、ソースのホスト名が正しく解決されるかどうかを確認するために使用できます。たとえば、DNS が palantir.com を解決できるかどうかをテストするには、dig palantir.com を実行します。レスポンスに ANSWER SECTION が表示された場合、DNS 名前解決に成功しています。

ソースが Agent プロキシエグレスポリシーを使用している場合、dig は 10.238.0.X などの内部仮想 IP アドレスを返すことがあります。Foundry はこのアドレスを使用して Agent 経由で接続をルーティングするため、このアドレスは外部システムの実際の IP アドレスではありません。

そのため、ソースターミナルで dig のレスポンスが正常に返っても、Agent が宛先の名前を解決できることや、宛先に到達できることは確認できません。接続をテストするには、元のホスト名とポートを使用し、HTTP には curl、TLS には openssl s_client など、適切なツールを使用します。

以下は、dig コマンドに成功した例です。

appuser@localhost:/root$ dig palantir.com

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> palantir.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13561
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;palantir.com.                  IN      A

;; ANSWER SECTION:
palantir.com.           300     IN      A       151.101.129.170
palantir.com.           300     IN      A       151.101.1.170
palantir.com.           300     IN      A       151.101.193.170
palantir.com.           300     IN      A       151.101.65.170

;; Query time: 99 msec
;; SERVER: 10.100.0.53#53(10.100.0.53) (UDP)
;; WHEN: Fri Oct 31 14:56:58 UTC 2025
;; MSG SIZE  rcvd: 142

`curl`

curl コマンドは、外部システムの特定のホストとポートへの HTTP 接続をテストします。ポートを指定しない場合は、プロトコルから推定されます（たとえば、HTTP では80、HTTPS では443）。たとえば、https://palantir.com への接続を確立できるかどうかをテストするには、curl https://palantir.com を実行します。

以下は、curl コマンドに成功した例です。

appuser@localhost:/root$ curl https://palantir.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.palantir.com/">here</A>.
</BODY></HTML>

curl コマンドが応答しない場合は、--connect-timeout フラグを使用してタイムアウト（秒単位）を設定します。

Copied!1
curl --connect-timeout 10 https://palantir.com

`openssl`

openssl コマンドは SSL/TLS 接続をテストし、HTTPS 接続の証明書を検証します。たとえば、ポート 443 で palantir.com への SSL/TLS 接続を確立できるかどうかをテストするには、openssl s_client -connect palantir.com:443 -servername palantir.com を実行します。

以下は、openssl コマンドに成功した例です。

appuser@localhost:/root$ openssl s_client -connect palantir.com:443 -servername palantir.com
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Atlas R3 DV TLS CA 2024 Q2
verify return:1
depth=0 CN = *.palantir.com
verify return:1
---
Certificate chain
 0 s:CN = *.palantir.com
   i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign Atlas R3 DV TLS CA 2024 Q2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 17 16:50:15 2024 GMT; NotAfter: Jul 19 16:50:14 2025 GMT
---
SSL handshake has read 3654 bytes and written 442 bytes
---

接続に成功すると、証明書の詳細と、SSL ハンドシェイクが完了したことを示すメッセージが表示されます。コマンドが応答しない場合や、証明書の検証エラーが表示される場合は、ネットワークや証明書の設定に問題がある可能性があります。

UI で設定された証明書は、ターミナル環境に自動的には含まれません。ターミナルで使用するには、インラインで、または nano/vim を使用して手動で追加します。

Copied!1
2
3
4
5
echo "-----BEGIN CERTIFICATE-----
MIIGXjCCBUagAwIBAgIQASByQ6gv8Z6X7wEqsyBb1DANBgkqhkiG9w0BAQsFADBY
...
9lc=
-----END CERTIFICATE-----" > server-cert.pem

自己署名証明書や mTLS などのカスタム証明書を使用してテストするには、証明書ファイルを指定します。

Copied!1
2
3
4
5
openssl s_client -connect my-server.example.com:443 \
  -servername my-server.example.com \
  -CAfile server-cert.pem \
  -cert client-cert.pem \
  -key client-key.pem

これらのコマンドに成功しても接続が機能しない場合は、一部の証明書またはソースの資格情報が正しく設定されていない可能性が高いです。

ネットワークエグレスログとメトリクス

Foundry ワーカーのソースでは、ネットワークエグレスログとメトリクスによって、ソースが実際に行っているネットワーク呼び出しを把握できます。これらのツールは、ターミナルを使用したデバッグだけでは明らかにならないネットワークの問題を特定するのに役立ちます。

Build ログ： ビルドページでログを選択し、ネットワークエグレスログフィルターを適用すると、そのビルドのネットワークエグレスアクティビティが表示されます。
Control Panel： Control Panel > ネットワークのエグレスに移動し、ポリシーを選択して観測可能性タブを開くと、ソースごとに集計されたログと、そのポリシーの使用状況メトリクスを表示できます。

ソースのプレビューと探索

さらに詳しくデバッグする前に、ソースに基本的な接続ができることと、ソースが正しく設定されていることを確認します。

プレビュー： ソースページの右側のパネルでプレビューを選択し、接続の確立に成功していることを確認します。
探索：ソース探索の表示を使用して、ソースのテーブル、ファイル、プレビューを確認します。探索に成功しても特定の同期に失敗する場合は、ソースよりも同期設定に問題がある可能性が高いです。

Job tracker

実行中または最近完了した同期のステータスを調査するには、Job tracker アプリケーションを開き、同期を選択します。そこから、ステータス、実行段階、ログを確認できます。JDBC 同期では、_data-ingestion.log も確認できます。

接続とエグレス

接続に成功するには、Foundry がネットワーク経由で外部システムに到達できるように許可されている必要があります。Foundry ワーカーのソースでは、エグレスポリシーによってこれを制御します。エグレスポリシーは、ソースが接続を許可されている特定のホスト、ポート、プロトコルを許可リストに登録します。認証前に接続に失敗する場合は、通常、エグレスに問題があります。

エグレスの問題が疑われる場合は、次の手順でデバッグします。

正しいエグレスポリシーがソースにアタッチされていることと、ポリシーで許可されているホスト、ポート、プロトコルが接続先のシステムと一致することを確認します。
ソースターミナルで dig、curl、openssl s_client を使用して、そもそもホストに到達できるかどうかをテストします。
ネットワークエグレスログを確認し、ソースが実際に行っている外向きの呼び出しを把握して、どの呼び出しがブロックされているかを特定します。

エグレスポリシーを作成またはリクエストするには、エグレスポリシーを設定するを参照してください。

証明書と TLS

このセクションでは、Foundry がクライアントとして、サーバーとして動作する外部システムへの接続を確立することを前提としています。基礎となる概念については、TLS ↗、mTLS ↗、SSL ↗ を参照してください。

PKIX と SSL の例外

PKIX 例外やその他の SSLHandshakeException は、ソースでの認証に必要な証明書を Foundry が持っていない場合に発生します。正しい証明書をインストールしてください。

Foundry ワーカーのソース： ソースの設定で証明書を設定します。証明書を追加するを参照してください。
Agent ワーカーのソース：Data Connection と証明書を参照してください。

非推奨の TLSv1.0 または TLSv1.1 プロトコルのみをサポートするソースについては、安全でない TLSv1.0 および TLSv1.1 プロトコルを使用してデータソースに接続するを参照してください。Palantir は、非推奨の TLS バージョンの使用を推奨していません。

サーバー証明書とクライアント証明書

サーバー証明書とクライアント証明書の違いを理解することが重要です。

サーバー証明書 (TLS)： Foundry クライアントが外部システムとの TLS 接続を確立するとき、外部システムは自身の属性を証明し、暗号化された接続の確立に必要な公開鍵を提供するために証明書を提示します。次に、Foundry クライアントは、証明書チェーンを信頼できるルート認証局 (CA) まで検証することで、外部システムの属性を確認します。ほとんどのシステムは、よく知られた公開 CA のリストをデフォルトで信頼しています。ソース設定（Foundry の truststore）にサーバー証明書を追加する必要があるのは、外部システムが、自己署名証明書やプライベート CA または内部 CA によって発行された証明書など、これらの公開 CA のいずれによっても署名されていない証明書を提示する場合のみです。サーバー証明書は証明書のみを指定し、秘密鍵は決して指定しません。

クライアント証明書 (mTLS)： クライアント証明書は、Foundry クライアントが外部システムに対して自身の属性を証明するために使用します。mTLS では、外部システムと Foundry が互いの属性を確認します。クライアント証明書は、証明書と秘密鍵のペアとして指定します。

証明書を設定するには、証明書を追加するを参照してください。

よくある証明書エラー

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain

このエラーは、ソース設定に必要なサーバー証明書がないことを示します。Python 環境では、安全な接続を確立するときに、基盤となる OpenSSL ライブラリーが証明書チェーン ↗全体を検証します。

外部システムの証明書チェーン全体を取得するには、次のコマンドを実行します。

Copied!1
openssl s_client -connect <external_systems_hostname>:<desired_port> -showcerts < /dev/null

このコマンドは、外部システムへのネットワークアクセスが可能なホストから実行してください。Foundry ワーカーのソースの場合は、ソースターミナルから実行します。Agent ワーカーのソースの場合は、Agent ホスト、または Agent のネットワークにアクセスできる別のシステムから実行します。

OAuth とアウトバウンドアプリケーション

ソースにアウトバウンドアプリケーションが設定されている場合、呼び出し元ユーザーに代わって、認証が外部の OAuth 2.0 プロバイダーに委任されます。スケジュールされた関数や自動化などの非対話型コンテキストからソースを使用するには、その前にユーザーが対話型認可フローを少なくとも1回完了している必要があります。

よくある OAuth エラー

`HTTP 401: Unauthorized`

ソースにアウトバウンドアプリケーションが設定されているにもかかわらず、関数またはワークフローが HTTP 401: Unauthorized を返す場合は、次の点を確認してください。

関数を呼び出すユーザーが、対話型認可フローを少なくとも1回完了していること。
Control Panel でアウトバウンドアプリケーションが有効になっていること。
アウトバウンドアプリケーションに設定されたスコープに、要求された API リソースへのアクセスに必要な権限が含まれていること。

`Credentials expired and no refresh handler provided`

このエラーは、Python または TypeScript 関数からソースを呼び出すときに表示されます。キャッシュされたリフレッシュトークンの有効期限が切れているか、外部の OAuth 2.0 サーバーによって取り消されています。ユーザーは、対話型インターフェースから関数（または同じアウトバウンドアプリケーションを元にした別のワークフロー）を呼び出し、認可フローを再度完了する必要があります。

`Resolved source credentials are not present on the Source`

このエラーは、Python または TypeScript 関数からソースを呼び出すときに表示されます。ソースにアウトバウンドアプリケーションが設定されていないか、呼び出し元の属性を認可されたユーザーとして解決できなかったことを示します。ソースのドメインに OAuth 2.0 認証が設定されていること、および関数がサービスアカウントではなく、認証済みのエンドユーザーに代わって呼び出されていることを確認してください。

機能固有の問題

上記のガイダンスは、どのソースにも適用されます。特定の機能に固有の問題については、専用のリファレンスを参照してください。

同期： JDBC のインクリメンタル（差分連携）動作、断続的な失敗やハング、REQUEST_ENTITY_TOO_LARGE、BadPaddingException、予期しないデータ型については、同期のトラブルシューティングリファレンスを参照してください。
Agent ワーカー： Agent のステータス、Agent Manager および Bootstrapper の起動エラー、メモリー不足、ダウンロードの問題、権限については、Agent のトラブルシューティングリファレンスを参照してください。
その他のよくある質問： スケジュール設定、重複行、スキーマの不一致、JDBC のデータ型については、Data Connection FAQ を参照してください。

←

PREVIOUS接続のセキュリティ

NEXTFoundry ワーカーとエージェントワーカーの比較

→