このページでは、Cloud Storage の使用中に発生する可能性のある一般的なエラーのトラブルシューティング方法について説明します
Cloud Storage などの Google Cloud サービスに影響を与える地域的またはグローバルなインシデントについては、Google Cloud ステータス ダッシュボードをご覧ください。
## 生のリクエストのロギング
などのツールを使用する場合
gcloud または Cloud Storage クライアント ライブラリなど
リクエストとレスポンスの情報はツールによって処理されます。しかし、それは
トラブルシューティングに役立つ詳細を表示すると便利な場合があります。使用
ツールのリクエスト ヘッダーとレスポンス ヘッダーを返す手順は次のとおりです。
コンソール
リクエストとレスポンスの情報の表示は、Google Cloud コンソールへのアクセスに使用しているブラウザによって異なります。 Google Chrome ブラウザーの場合:
Chrome の
メインメニューボタン (
)
選択する
その他のツール
クリック
開発者ツール
表示されるペインで、
ネットワークタブ
コマンドライン
gcloud
リクエストでグローバル デバッグ フラグを使用します。例えば：
gcloud storage ls gsmy-bucket/my-object --log-http --verbosity=debug
gsutil
グローバルを使用する
リクエストの -D フラグ。例えば：
gsutil -D ls gsmy-bucket/my-object
クライアント ライブラリ
C++
環境変数を設定する
CLOUD_STORAGE_ENABLE_TRACING=http は完全な HTTP トラフィックを取得します
環境変数 CLOUD_STORAGE_ENABLE_CLOG=yes を設定して、各 RPC のログを取得します
C#
ロガーを追加する
ApplicationContext.RegisterLogger、およびログの設定
のオプション
HttpClient メッセージ ハンドラー。詳細については、次を参照してください。
よくある質問のエントリ
行け
環境変数を設定する
GODEBUG=http2debug=1.多くのための
詳細については、Go パッケージ net/http を参照してください。
リクエスト本文もログに記録する場合は、カスタム HTTP クライアントを使用します
ジャワ
次の内容で「logging.properties」という名前のファイルを作成します。
# JDK ロギング機能の動作を設定するプロパティ ファイル。 # システムは、システム プロパティとして指定されるこの構成ファイルを探します: # -Djava.util.logging.config.fileproject_loc:googleplus-simple-cmdline-sample}/logging.properties # コンソール ハンドラを設定します ("handlers = java.util.logging.ConsoleHandler java.util.logging.ConsoleHandler.level = CONFIG # HTTP リクエストとレスポンスのロギングを設定します (表示するには「レベル」のコメントを外します) com.google .api.client.http.level = CONFIG
Maven で logging.properties を使用する
mvn -Djava.util.logging.config.file=path/to/logging.properties
挿入コマンド
詳細については、プラグ可能な HTTP トランスポートを参照してください。
Node.js
環境変数を設定する
NODE_DEBUG=https ノードを呼び出す前に
脚本
PHP
を使用して独自の HTTP ハンドラーをクライアントに提供します。
httpHandler と、リクエストをログに記録するためのミドルウェアのセットアップ
と応答
パイソン
ロギング モジュールを使用します。例えば：
import logging import http.client logging.basicConfig(level=logging.DEBUG) http.client.HTTPConnection.debuglevel=5
ルビー
あなたの一番上に
後の.rbファイル
「google/cloud/storage」が必要です。
以下を追加します。
ruby Google::Apis.logger.level = ロガー::DEBUG
## エラーコード
以下は、発生する可能性がある一般的な HTTP ステータス コードです。
301: 恒久的に移動
**問題 静的 Web サイトをセットアップしていて、ディレクトリ パスにアクセスしています
空のオブジェクトと
301 HTTP 応答コード
**解決策 お使いのブラウザがゼロ バイト オブジェクトをダウンロードし、
301
などのディレクトリにアクセスするときの HTTP 応答コード
httpwww.example.com/dir/、バケットに空のオブジェクトが含まれている可能性が高い
その名前の。これが事実であることを確認し、問題を解決するには:
- Google Cloud コンソールで、Cloud Storage に移動します
バケットページ
- クリック
Google Cloud コンソールの上部にある Cloud Shell ボタンをアクティブにする
- 走る
gcloud storage ls --recursive gswww.example.com/dir/.出力に含まれる場合
httpwww.example.com/dir/、その場所に空のオブジェクトがあります
- 次のコマンドで空のオブジェクトを削除します。
gcloud ストレージ rm gswww.example.com/dir/
アクセスできるようになりました
httpwww.example.com/dir/ そしてそれを返すようにします
ディレクトリの
空のオブジェクトの代わりに index.html ファイル
400不正な要求
**問題 再開可能なアップロードの実行中に、このエラーが表示され、
メッセージ
Content-Range ヘッダーの解析に失敗しました
**解決策
Content-Range ヘッダーが無効です。にとって
例、
Content-Range: は無効であり、代わりに次のように指定する必要があります
Content-Range: bytes このエラーを受け取った場合、現在の再開可能
アップロードはアクティブではなくなりました。新しい再開可能なアップロードを開始する必要があります
401: 無許可
**パブリック バケットに直接、または Cloud CDN 経由でリクエストを発行します。
で失敗する
HTTP 401: 権限がなく、
認証が必要
応答
**解決策 クライアントまたは中間プロキシが追加していないことを確認します。
Cloud Storage へのリクエストに対する Authorization ヘッダー。任意の要求
を
Authorization ヘッダーは、たとえ空であっても、
認証試行
403: アカウントが無効になっています
**問題 バケットを作成しようとしたが、
403 アカウント無効エラー
**解決策 このエラーは、
関連するプロジェクト。課金を有効にする手順については、次を参照してください。
プロジェクトの課金を有効にする
課金がオンになっていて、このエラー メッセージが引き続き表示される場合は、プロジェクト ID と問題の説明を添えてサポートに連絡できます。
403禁止します
**問題特定のバケットまたはオブジェクトにアクセスする権限が必要ですが、
そうしようとすると、
403 - 次のメッセージを伴う禁じられたエラー
に似ている：
[email protected] には storage.objects.get アクセス権がありません
Google クラウド ストレージ オブジェクト
**解決策 バケットに対する IAM 権限がありません
またはリクエストを完了するために必要なオブジェクト。できると期待するなら
要求を行うができない場合は、次のチェックを実行します。
エラー メッセージで参照されている被付与者は、想定したものですか?エラー メッセージが予期しない電子メール アドレスまたは「匿名の発信者」に言及している場合、要求は意図した資格情報を使用していません。これは、リクエストを行うために使用しているツールが別のエイリアスまたはエンティティからの認証情報を使用して設定されていたことが原因である可能性があります。または、サービス アカウントによってお客様に代わってリクエストが行われていることが原因である可能性があります
エラー メッセージで参照されているアクセス許可は、必要だと思われるものでしたか?許可が予期しないものである場合は、使用しているツールが要求を完了するために追加のアクセスを必要とする可能性があります。たとえば、バケット内のオブジェクトを一括削除するには、
gcloud は、最初に削除するバケット内のオブジェクトのリストを作成する必要があります。一括削除アクションのこの部分では、
storage.objects.listpermission は、目標がオブジェクトの削除であることを考えると、驚くべきことかもしれません。
storage.objects.deleteパーミッション。これがエラー メッセージの原因である場合は、追加の必要なアクセス許可を持つ IAM ロールが付与されていることを確認してください。
目的のリソースまたは親リソースに対する IAM ロールが付与されていますか?たとえば、
プロジェクトの Storage Object Viewer ロールを持っていて、オブジェクトをダウンロードしようとしている場合は、オブジェクトがプロジェクト内のバケットにあることを確認してください。あなたはうっかり持っているかもしれません
別のプロジェクトの Storage Object Viewer 権限
403禁止します
**コンテンツのダウンロード元の問題
storage.cloud.google.com と私
を受け取る
403: ブラウザを使用して
URL を使用したオブジェクト:
httpsstorage.cloud.google.com/
BUCKET_NAME/ OBJECT_NAME **を使用したソリューション
オブジェクトをダウンロードするための storage.cloud.google.com は、
cookie ベースの認証を使用する認証済みブラウザ ダウンロード
Cloud Audit Logs でデータアクセス監査ログを追跡するように構成している場合
オブジェクトへのアクセス、その機能の制限の 1 つは、
認証されたブラウザのダウンロードを使用して、追跡対象のオブジェクトをダウンロードすることはできません。
オブジェクトが読み取り可能でない限り。 認証された 非パブリック オブジェクトのブラウザ ダウンロードは、 403 応答。 この Google ID のフィッシングを防止するための制限が存在します。 Cookie ベースの認証 この問題を回避するには、次のいずれかを実行します。 - 認証されたブラウザのダウンロードを使用する代わりに、認証されていないダウンロードをサポートする直接 API 呼び出しを使用します。 - 影響を受けるオブジェクトへのアクセスを追跡している Cloud Storage Data Access 監査ログを無効にします。 データ アクセス監査ログはプロジェクト レベル以上で設定され、複数のレベルで同時に有効にできることに注意してください。 - データ アクセス監査ログ追跡から特定のユーザーを除外するように除外を設定します。これにより、それらのユーザーは認証済みのブラウザー ダウンロードを実行できます。 - どちらかに読み取り権限を付与して、影響を受けるオブジェクトを読み取り可能にします。 すべてのユーザー すべての認証済みユーザー。 データ アクセス監査ログは、パブリック オブジェクトへのアクセスを記録しません 409:コンフリクト **問題 バケットを作成しようとしましたが、次のエラーが表示されました: 409 競合。 その名前は利用できません。 別のものを試してください **解決策 使用しようとしたバケット名 [例: gscats または gsdogs] すでに使用されている。 Cloud Storage にはグローバルな名前空間があるため、名前を付けることはできません。 既存のバケットと同じ名前のバケット。 されていない名前を選択してください 中古 429: 要求が多すぎます **問題 リクエストが拒否されました 429 要求が多すぎますエラー **解決策 リクエスト数の制限に達しています Cloud Storage は特定のリソースを許可します。 を参照してください の制限について説明するための Cloud Storage の割り当て クラウドストレージ。 ワークロードが 1 回あたり数千のリクエストで構成されている場合 ワークロードを徐々に増やしたり、連続したファイル名を避けたりするなどのベスト プラクティスについては、リクエスト レートとアクセス分散のガイドラインを参照してください。 ## Google Cloud コンソール エラーの診断 **Google Cloud コンソールを使用して 操作すると、一般的なエラー メッセージが表示されます。 たとえば、エラー メッセージが表示される バケットを削除しようとしたが、操作の理由の詳細が表示されない 失敗した。 **解決策 Google Cloud コンソールの通知を使用して詳細を確認します 失敗した操作に関する情報: クリック Google Cloud コンソール ヘッダーの通知ボタン ドロップダウンには、Google Cloud コンソールによって実行された最新の操作が表示されます 詳しく知りたい項目をクリック ページが開き、操作に関する詳細情報が表示されます 各行をクリックして、詳細なエラー情報を展開します 以下は、失敗したバケット削除操作のエラー情報の例です。これは、バケット保持ポリシーがバケットの削除を妨げたことを説明しています ## 静的 Web サイト エラー 以下は、静的 Web サイトをホストするようにバケットをセットアップするときに発生する可能性のある一般的な問題です。 HTTPS サービス ** 問題 ロード バランサーを使用せずに HTTPS 経由でコンテンツを提供したい。 **解決策 ダイレクト URI を使用して、HTTPS 経由で静的コンテンツを提供できます。 そのような httpsstorage.googleapis.com/my-bucket/my-object. SSL 経由でカスタム ドメインを介してコンテンツを提供するその他のオプションについては、次のことができます。 - Cloud Storage でサードパーティのコンテンツ配信ネットワークを使用する - Cloud Storage の代わりに Firebase Hosting から静的なウェブサイト コンテンツを提供するドメインの検証**問題 ドメインを検証できません。**解決策 通常、Search Console の検証プロセスではファイルをドメインにアップロードするように指示されますが、これを行う方法がない場合があります。ドメイン検証を実行した後にのみ作成できますこの場合、**ドメイン名プロバイダー* を使用して所有権を検証します* 検証メソッド。これを行う手順については、所有権の確認を参照してください。この検証は、バケットが作成される前に実行できますアクセスできないページ** 問題アクセスが拒否されました自分の Web サイトが提供する Web ページのエラー メッセージ**解決策 オブジェクトが共有されていることを確認してください。そうでない場合は、Making Data Public を参照してください以前にオブジェクトをアップロードして共有したが、新しいオブジェクトをアップロードした場合オブジェクトを再共有する必要があります。これは、公開許可が新しいアップロードに置き換えられたためです許可の更新に失敗しました**データを公開しようとするとエラーが発生する問題.**解決策オブジェクトまたはバケットに対するsetIamPolicy 権限があることを確認してください。この権限は、たとえばStorage Admin ロールで付与されます。setIamPolicy 権限があり、それでもエラーが発生する場合は、バケットがパブリック アクセス防止の対象になっている可能性があります。 |#|# allUsers またはallAuthenticatedUsers。パブリック アクセスの防止はバケットに直接設定されるか、より高いレベルで設定されたコンテンツのダウンロード**問題 ページのコンテンツをブラウザで表示するのではなく、ダウンロードするように求められます。**解決策Web コンテンツ タイプを持たないオブジェクトとしてMainPageSuffix を指定すると、ページを提供する代わりに、サイト訪問者はコンテンツをダウンロードするように求められます.この問題を解決するには、content-typeメタデータ エントリをtext/html などの適切な値に更新します。を参照
オブジェクトのメタデータを編集して、これを行う方法を説明しています
## レイテンシ
以下は、発生する可能性のある一般的な遅延の問題です。さらに、Google Cloud ステータス ダッシュボードは、Cloud Storage などの Google Cloud サービスに影響を与える地域的またはグローバルなインシデントに関する情報を提供します。
アップロードまたはダウンロードの遅延
**問題 アップロードまたはダウンロード時に遅延が増加しています。 **解決策
パフォーマンスを実行する gsutil perfdiag コマンド
影響を受ける環境からの診断。次の一般的な原因を考慮してください
アップロードとダウンロードの待ち時間:
CPU またはメモリの制約: 影響を受ける環境のオペレーティング システムには、CPU 使用率やメモリ使用率などのローカル リソースの消費を測定するためのツールが必要です。
ディスク IO の制約:
gsutil perfdiag コマンドで、
rthru_fileand
wthru_filetests を使用して、ローカル ディスク IO によるパフォーマンスへの影響を測定します
地理的距離: Cloud Storage バケットと影響を受ける環境が物理的に離れていると、特に大陸をまたがる場合に、パフォーマンスに影響を与える可能性があります。影響を受ける環境と同じリージョンにあるバケットを使用してテストすると、地理的な分離がレイテンシにどの程度影響しているかを特定できます
- 該当する場合、影響を受ける環境の DNS リゾルバーは EDNS(0) プロトコルを使用して、環境からのリクエストが適切な Google フロント エンド経由でルーティングされるようにする必要があります。
CLI またはクライアント ライブラリのレイテンシ
**Cloud Storage へのアクセス時にレイテンシが増加する問題
と
gcloud storage、gsutil、またはいずれかのクライアント ライブラリ
**解決策 CLI とクライアント ライブラリは自動的に再試行します
そうすることが有用であるときに要求し、この動作は効果的に増加する可能性があります
エンドユーザーから見た遅延。 Cloud Monitoring 指標を使用する
storage.googleapis.com/api/request_count かどうかを確認します
Cloud Storage は、次のような再試行可能なレスポンス コードを一貫して提供しています。
なので
429 または
5xx
## プロキシ サーバー
** 問題 プロキシ サーバー経由で接続しています。私は何をする必要がありますか？ **解決策 プロキシ サーバー経由で Cloud Storage にアクセスするには、
これらのドメインへのアクセスを許可:
accounts.google.com 経由で OAuth2 認証トークンを作成する
gsutil 構成
oauth2.googleapis.com（OAuth2 トークン交換の実行用）
*.googleapis.com ストレージ リクエスト用
プロキシ サーバーまたはセキュリティ ポリシーがドメインによるホワイトリスト登録をサポートしておらず、代わりに IP ネットワーク ブロックによるホワイトリスト登録が必要な場合は、すべての Google IP アドレス範囲に対してプロキシ サーバーを構成することを強くお勧めします。 ARIN で WHOIS データをクエリすることにより、アドレス範囲を見つけることができます。ベスト プラクティスとして、プロキシ設定を定期的に見直して、Google の IP アドレスと一致していることを確認してください。
個々の IP アドレスでプロキシを構成することはお勧めしません。
の 1 回限りのルックアップから取得する
oauth2.googleapis.com および
storage.googleapis.com. Google サービスは DNS 名を介して公開されるため、
時間の経過とともに変化する可能性のある多数の IP アドレスへのマッピング、構成
1 回限りのルックアップに基づくプロキシは、接続に失敗する可能性があります
クラウドストレージ
リクエストがプロキシ サーバー経由でルーティングされている場合は、
ネットワーク管理者に確認して、
認可
資格情報を含むヘッダーは、プロキシによって取り除かれません。それなし
の
Authorization ヘッダー、リクエストは拒否され、
MissingSecurityHeader エラー
＃＃ 次は何ですか
- サポート オプションについて学ぶ
- Cloud Storage FAQ で追加の質問への回答を見つける
- Error Reporting が Cloud Storage エラーの特定と理解にどのように役立つかを調べます。
グーグルクラウド
共有ウェブホスティング#70
