Looker API のトラブルシューティング

注: Looker 22.4 では、Looker API 4.0 は一般提供されています。Looker 23.18 では、Looker API 3.1 が削除されました。

このページでは、Looker API で発生する可能性がある次の問題のトラブルシューティング手順について説明します。

• API エンドポイントにアクセスできない
• API の結果が意味不明のテキストである
• API 呼び出しが応答しない
• 無効なエンコードのエラー
• Method Not Found エラー
• Bad Request（400）エラー
• Unauthorized（401）エラー
• Forbidden（403）エラー
• Not Found（404）エラー
• Method Not Allowed（405）エラー
• Conflict（409）エラー
• Validation（422）エラー
• Too Many Requests（429）エラー
• Internal Server Error（500）エラー

API エンドポイントにアクセスできない

API エンドポイントにアクセスできない場合:

• API 認証情報を確認する
• API ホストの URL を確認する
• API ポートを確認する
• API 呼び出し URL を確認する

API 認証情報を確認する

Looker API エンドポイントにアクセスできない場合は、まず API 認証情報が正しいことを確認します。API 認証情報を表示するには:

1. Looker で、左側のナビゲーション パネルから [管理者] オプションを選択して、[管理者] パネルにアクセスします。
2. [管理者] ページの左パネルで、下にスクロールし、[ユーザー] をクリックします。
3. ユーザーリストでユーザー名を検索し、クリックしてユーザーページを編集します。
4. [Edit API Keys] をクリックします。クライアント ID が表示され、目のアイコンをクリックして、構成した各 API キーのクライアント シークレットを表示できます。API 認証情報が、スクリプトで使用している認証情報と一致していることを確認します。

API の URL を確認する

API エンドポイントに到達する際のもう 1 つの一般的な問題は、API ホスト URL の誤りです。ほとんどの Looker インスタンスは、API のデフォルト URL を使用します。ただし、代替 API パスを使用した Looker インストール、ロードバランサの背後にある Looker インストール（クラスタ構成など）または他のプロキシは、デフォルトの URL を使用しない場合があります。その場合は、API ホスト URL はユーザー向けの API ホスト名とポートを示す必要があります。

Looker 管理者は、API 管理設定で API ホスト URL を確認できます（詳しくは、管理設定 - API のドキュメント ページをご覧ください）。API ホストの URL を表示するには:

1. 左側のナビゲーション パネルで [管理者] オプションを選択して、[管理] パネルにアクセスします。
2. [管理者] パネルで [API] をクリックします。

3. [API Host URL] を表示します。

   [API ホスト URL] フィールドが空白の場合、Looker インスタンスはデフォルトの形式を使用します。

   https://<instance_name>.cloud.looker.com:<port>
   

API ホスト URL をテストするには:

1. ブラウザを開いてから、ブラウザ コンソールを開きます。

2. [API ホスト URL] に続けて /alive を入力します。たとえば、[API Host URL] が https://company.cloud.looker.com の場合、次のように入力します。

   https://company.cloud.looker.com/alive
   

   [API ホスト URL] フィールドが空白の場合、デフォルトの API の URL を使用します。例えば、Google Cloud、Microsoft Azure でホストされているインスタンス、Amazon Web Service（AWS）でホストされているインスタンス（2020 年 7 月 7 日以降に作成されたもの）の場合、デフォルトの Looker API パスはポート 443 を使用します。

   https://<instance_name>.cloud.looker.com:443/alive
   

   2020 年 7 月 7 日より前に作成された AWS でホストされているインスタンスの場合、デフォルトの Looker API パスはポート 19999 を使用します。

   https://<instance_name>.cloud.looker.com:19999/alive
   

API ホスト URL が正しい場合は、この URL はエラーページではなく、空白のウェブページになります。

ブラウザ コンソールでネットワーク レスポンスを確認して、API に到達したことも確認できます。ネットワーク レスポンスは 200 になります。

これらの確認ポイントが異なる場合は、API を正しく呼び出していないか、コードに他のエラーがある可能性があります。API 呼び出しとスクリプト内のコードを確認します。正しい場合は、次のセクションでポートの確認についてご確認ください。

API ポートを確認する

前述のチェックが不合格で、セルフホスト型 Looker 環境がある場合は、ネットワーク インフラストラクチャで API ポートを開く必要がある可能性があります。

API ポートは Looker サーバーに転送する必要があります。セルフホスト型 Looker デプロイの場合は、API ポートの設定を確認するようネットワーク管理者に依頼します。最も一般的な API ポートは 443 または 19999 です。API ポートの構成設定は、Looker インスタンス ポートと同じにする必要があります（デフォルトで 9999）。ネットワーク管理者は、次の設定が Looker インスタンス ポートと API ポートで同じであることを確認する必要があります。

• プロキシ
• ロードバランサ
• ファイアウォール

API 呼び出し URL を確認する

API 呼び出しに正しい URL を使用していることを確認します。API エンドポイント URL の形式は次のとおりです。

<API Host URL>/api/<API version>/<API call>

デフォルトの API ホスト URL を使用している場合、API エンドポイント URL の形式は次のとおりです。

https://<instance_name>:<port>/api/<API version>/<API call>

API エンドポイントの URL 形式は、API Explorer または API リファレンス ドキュメントから取得できます。

たとえば、API 4.0 リファレンスでは、Get All Running Queries のエンドポイントに対して、次の相対パスが指定されます。

/api/4.0/running_queries

したがって、Looker インスタンス docsexamples.dev.looker.com の Get All Running Queries エンドポイントの完全な API エンドポイント URL は次のようになります。

https://docsexamples.dev.looker.com:443/api/4.0/running_queries

API の結果が意味不明のテキストである

API から文字化けしたテキストのレスポンスが返された場合は、PDF、PNG、JPG ファイルのバイナリ コンテンツが表示されている可能性があります。一部の HTTP REST ライブラリでは、API レスポンスがテキスト ファイルであることを想定しているため、他のタイプのファイルはバイナリ テキストとして表示されます。

この場合、HTTP REST ライブラリが API レスポンスをテキストとしてではなく、バイナリデータとして処理するようにする必要があります。場合によっては、これは、HTTP REST ライブラリにバイナリの結果であることを伝えるフラグを設定することや、結果を文字列変数に割り当てる代わりに、バイト ストリームやバイトの配列など、特別な方法で結果を処理することを意味します。

API 呼び出しが応答しない

API Explorer を開くことができるが、API 呼び出しが応答しない場合は、Looker インスタンスの [API ホスト URL] が正しく設定されていることを確認してください。Looker 管理者は、API 管理設定で API ホスト URL を確認できます（管理設定 - API のドキュメント ページをご覧ください）。

無効なエンコードのエラー

API 呼び出しを試行した際にエンコード エラーが発生した場合は、リクエスト時にヘッダーに適切な Content-Type を設定することが必要な可能性があります。HTTP プロトコル標準では、POST、PUT、または PATCH リクエストに Content-Type ヘッダーが含まれている必要があります。Looker API は一貫して JSON を使用するため、Content-Type ヘッダーは application/json に設定する必要があります。

Looker SDK を使用すると、この懸念事項に自動的に対処できます。

Method Not Found エラー

method not found: all_looks() などの Method Not Found エラーが表示された場合、最初に確認するのは API バージョンです。API 4.0 には、新規のまたは API 4.0 で削除された API 呼び出しがいくつかあります。更新の一覧については、Looker API 4.0 の一般提供開始のお知らせをご覧ください。

Bad Request（400）エラー

400 Bad Request エラーは、API 呼び出しで指定されたデータが認識できないことを示します。多くの場合、問題の原因は JSON の破損や無効な JSON です（おそらく解析エラーです）。ほとんどの場合、400 エラーはすでに認証を通過しているため、エラー レスポンス メッセージでエラーに関するより具体的な情報を確認できます。

Unauthorized（401）エラー

API 呼び出しの 401 Unauthorized エラーは、API 呼び出しが適切に認証されていないことを意味します。トラブルシューティングの詳細については、401 エラーのトラブルシューティング方法をご覧ください。コミュニティの記事。

Forbidden（403）エラー

Looker API は、ユーザーが LookML オブジェクトまたはその他の権限のないコンテンツにアクセスしようとするたびに 403 エラーを返しません。404 エラーではなく 403 エラーを返すことで、オーナーが認知されないことを選択した場合に、特定の Explore、ダッシュボード、LookML オブジェクトの存在が確認されることがあります。これを防止するために、Looker では 404 が返され、Looker UI に次のメッセージが表示されます: 「リクエストしたページが見つかりません。存在しないか、閲覧権限がありません」。

Looker インスタンスがホストされている環境や、Looker インスタンスの構成によっては、ポート番号や API にアクセスできる関連 URL が異なる場合があります。誤ったポート番号を使用すると 403 エラーが表示される場合があります。たとえば、Looker インスタンスがデフォルトの API ポート 443 で構成されている場合は、https://mycompany.looker.com:443/api/4.0/login ではなく https://mycompany.looker.com/api/4.0/login に接続すると、403 エラーが返されます。セルフホスト型 インスタンスについては、API ポートを定義できる Looker の起動オプションをご確認ください。

これは、Ruby SDK gem の古いバージョンを使用している場合にも発生する可能性があります。gem が最新のバージョンであることを確認してください。https://rubygems.org/gems/looker-sdk で確認できます。

これは、URL の /api/<version number>/ の部分を含めない場合にも発生します。この場合、ユーザーが https://mycompany.looker.com:443/login に接続しようとすると、403 レスポンスが表示されます。

Not Found（404）エラー

404 Not Found エラーは、問題（通常は権限などの問題）が発生した場合のデフォルトのエラーです。404 エラーに対するレスポンス メッセージでは、最小限の情報が提供されます（もしあれば）。404 エラーは、ログイン認証情報が正しくないか、十分な権限を持たないユーザーに表示されるため、これは意図的なものです。Looker では、特定の情報を 404 レスポンス メッセージに含めることを望んでいません。この情報が、Looker API の「攻撃対象領域」を計画するために使用される可能性があるためです。

API ログイン試行で 404 エラーが返された場合は、おそらく API クライアント ID またはクライアント シークレットが無効であることが原因です（このページで前述した API 認証情報を確認するをご覧ください）。API ログイン REST エンドポイントは次のとおりです。

• https://<your-looker-hostname>:<port>/api/4.0/login

Swagger codegen API または Looker SDK を使用している場合は、base_url 値が正しいことを確認します。

• Swagger Codegen クライアントの場合、base_url は次のようになります。

  • https://<your-looker-hostname>:<port>/api/4.0/

• looker.ini を使用する Looker SDK の実装では、api_version の値を 4.0、base_url の値を形式 https://<your-looker-hostname>:<port> 内の Looker インスタンスの URL と同じにする必要があります。looker.ini ファイルの例を次に示します。

  # api_version should be 4.0
  api_version=4.0
  base_url=https://<your-looker-hostname>:<port>
  

ログイン後に 404 エラーが発生することもあります。ログインしているときに 404 エラーが表示された場合、呼び出した API コマンドに対する権限がないことを意味します。

Method Not Allowed（405）エラー

405 Method Not Allowed エラーは、サーバーがリクエスト メソッドを認識しているものの、ターゲット リソースがこのメソッドをサポートしていないことを示します。

サーバーでは、405 ステータス コードのレスポンスに Allow ヘッダー フィールドを生成する必要があります。このフィールドには、ターゲット リソースでサポートされるメソッドのリストを含める必要があります。

たとえば、Looker でこれが発生する理由の一つは、update_dashboard() エンドポイントを使用して LookML ダッシュボードのメタデータを更新しようとしたことです。LookML ダッシュボードの id パラメータの変更は Looker API でサポートされていないため、405 エラーが発生します。

Conflict（409）エラー

409 Conflict レスポンス ステータス コードは、リクエストがターゲット リソースの現在の状態と競合することを示します。

競合が発生する可能性が最も高いのは、PUT リクエストに応答する場合です。このエラーの一般的な Looker 以外の例は、サーバー上の既存のファイルより古いファイルをアップロードすることにより、バージョン管理の競合が発生した場合に見られます。

このエラーは、API を使用して新しい git ブランチをチェックアウトしようとしたとき、または create_group() や create_dashboard() などのエンドポイントを使用しているときに Looker で発生することがあります。そのような場合は、作成しようとしているオブジェクトがすでに存在するかどうかを確認します。

Validation（422）エラー

Validation エラーは、リクエストの何かがデータ チェックの実行に失敗した場合に発生します。リクエストに次のタイプのエラーが 1 つ以上含まれています（エラー レスポンスで正確なエラーが指定されます）。

• 欠落フィールド: 指定されていない必須パラメータがあります（エラー レスポンスでは欠落しているフィールドが示されます）。
• 無効: 指定された値が既存の値と一致していないか、値の形式が正しくありません。たとえば、Look を作成しようとしたときに、API 呼び出しで指定したクエリ ID が既存のクエリと一致しない場合に、検証エラーが発生します。
• すでに存在する: API 呼び出しが、Looker インスタンスにすでに存在する ID または名前のオブジェクトを作成しようとしています。たとえば、データベース接続名は一意であることが必要です。既存の接続の名前を使用する新しいデータベース接続を作成しようとすると、already_exists コードの検証エラーが発生します。

欠落している、または必須のフィールドや、無効な値が含まれているフィールドについて詳しくは、エラー レスポンス メッセージをご覧ください。 レスポンス メッセージでは、すべての検証エラーが同時に表示されます。そのため、欠落しているフィールドや不正確なフィールドがある場合、エラー レスポンスには API 呼び出しに関するすべての問題が一覧表示されます。

以下に示すのはレスポンスの例です。

{
  "message": "Validation Failed",
  "errors": [
    {
    "field": "dialect",
    "code": "missing_field",
    "message": "This field is required.",
    "documentation_url": "http://docs.looker.com/"
    },
    {
    "field": "db_timezone",
    "code": "invalid",
    "message": "Must specify a database timezone when user timezones are activated.",
    "documentation_url": "http://docs.looker.com/"
    }
  ],
    ...

この場合、API 呼び出しに必要な dialect フィールドがなく、db_timezone に無効な値も指定されていました。

Too Many Requests（429）エラー

429 Too Many Requests レスポンス ステータス コードは、特定の時間内にユーザーが過剰な数のリクエストを送信したことを示します（「レート制限」）。Looker のレート制限ポリシーについて詳しくは、Looker コミュニティの投稿一度に送信できる API リクエストの数に制限はありますか？をご覧ください。

Internal Server Error（500）エラー

500 Internal Server Error レスポンス コードは、サーバーで予期しない状態が発生しリクエストを処理できなかったことを示します。

このエラー レスポンスは、汎用の「キャッチオール」レスポンスです。これは通常、サーバーが応答する際のより具体的な 5xx エラーコードを見つけることができないことを示します。Looker から 500 レスポンスが返されることは想定外です。そのため、Looker を操作しようとした際に一貫してこのエラーが表示される場合は、Looker サポートに問い合わせることをおすすめします。