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

注: Looker API 4.0 は、Looker 22.4 のベータ版から一般提供に移行し、追加や互換性を破る可能性のある変更が行われました。一般提供のお知らせで、お客様への影響についてご確認ください。

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

• API エンドポイントにアクセスできません
• API の結果が意味をなさないテキストである
• API 呼び出しが応答しない
• 無効なエンコード エラー
• メソッドが見つからないエラー
• 不正なリクエスト（400）エラー
• Forbidden（403）エラー
• 見つかりませんでした（404）エラー
• 許可されていないメソッド（405）のエラー
• 競合（409）エラー
• 検証（422）エラー
• リクエストが多すぎます（429）エラー
• 内部サーバーエラー（500）エラー

API エンドポイントにアクセスできません

API エンドポイントに到達できない場合:

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

API 認証情報を確認する

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

1. Looker で、左側のナビゲーション パネルの [Admin] オプションを選択して、管理パネルにアクセスします。
2. [管理] ページの左パネルで、下にスクロールして [ユーザー] をクリックします。
3. ユーザーリストでユーザー名を検索し、クリックしてユーザーページを編集します。
4. [API キーを編集] をクリックします。クライアント 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 Host URL] フィールドが空白の場合、Looker インスタンスではデフォルトの形式が使用されます。

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

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

1. ブラウザを開き、ブラウザ コンソールを開きます。（ブラウザのコンソールを開く方法については、ConcreteCMS.org のこの記事をご覧ください）。

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

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

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

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

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

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

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

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

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

API ポートを確認する

前述のチェックに失敗し、顧客がホストする Looker デプロイがある場合は、ネットワーク インフラストラクチャで API ポートを開く必要がある可能性があります。

API ポートを Looker サーバーに転送する必要があります。お客様がホストする Looker のデプロイの場合は、ネットワーク管理者に API ポートの設定を確認するよう依頼してください。API ポートは通常、443 または 19999 です。API ポートの構成は、Looker インスタンス ポートと同じ構成にする必要があります（デフォルトでは 9999）。ネットワーク管理者は、次の設定が API インスタンスと Looker インスタンス ポートで同じ設定になっていることを確認する必要があります。

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

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、Looker のデベロッパー ポータル、API リファレンスのドキュメントで確認できます。

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

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

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

API の結果が意味をなさないテキストである

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

この場合、HTTP REST ライブラリが API レスポンスをテキストではなくバイナリデータとして処理できるようにする必要があります。場合によっては、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: all_looks() などのメソッド未検出エラーが表示された場合は、まず API のバージョンを確認します。API 4.0 で新しく追加された API 呼び出しや、API 4.0 で削除された API 呼び出しがいくつかあります。更新の一覧については、Looker API 4.0 の一般提供のお知らせをご覧ください。

不正なリクエスト（400）エラー

400 Bad Request エラーは、API 呼び出しで指定されたデータを認識できないことを示します。この問題の原因は多くの場合、壊れているか無効な JSON であり、解析エラーである可能性があります。ほとんどの場合、400 エラーはすでに認証に合格しているため、エラー レスポンス メッセージにエラーに関する具体的な情報が表示されます。

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 エラーが返されます。お客様がホストするインスタンスの場合は、Looker の起動オプションで API ポートの定義に関する説明をご覧ください。

これは、Ruby SDK の gem の古いバージョンを使用している場合にも発生することがあります。これらの宝石は最新の状態に維持してください。https://rubygems.org/gems/looker-sdk でご確認いただけます。

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

見つかりませんでした（404）

404 Not Found エラーは、問題が発生した場合に発生するデフォルトのエラーで、通常は権限などの問題があります。404 エラーのレスポンス メッセージでは、最低限の情報が提供されます。ログイン認証情報が正確でないユーザーや、十分な権限がないユーザーには 404 エラーが表示されるため、これは意図的なものです。Looker は、404 レスポンス メッセージに特定の情報を提供しません。この情報は、Looker API の「攻撃対象領域」をマッピングするために使用できるためです。

API ログイン試行で 404 エラーが返される場合、API3 クライアント ID またはクライアント シークレットが有効でない可能性があります（前述の API 認証情報を確認するをご覧ください）。API ログイン REST エンドポイントは、使用している API のバージョンに応じて、次のいずれかになります。

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

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

• Swagger codegen クライアントの場合、base_url は、使用する API のバージョンに応じて次のいずれかになります。
  • https://<your-looker-hostname>:<port>/api/4.0/
  • https://<your-looker-hostname>:<port>/api/3.1/

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

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

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

許可されていないメソッド（405）のエラー

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

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

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

競合（409）エラー

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

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

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

検証エラー（422）

検証エラーは、リクエスト内の何かがデータのチェックに失敗した場合に発生します。リクエストに次のいずれかのエラーが 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 の値も無効でした。

リクエストが多すぎます（429）エラー

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

内部サーバーエラー（500）エラー

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

このエラー レスポンスは一般的なキャッチオール レスポンスです。通常、これはレスポンスで返すより具体的な 5xx エラーコードをサーバーが検出できないことを示します。Looker から 500 レスポンスが返されることは想定外です。このため、Looker の操作中にこのエラーが繰り返し表示される場合は、Looker のサポートにお問い合わせください。