Nesta página, você verá métodos de solução de problemas para erros comuns que podem ser encontrados ao usar o Cloud Storage.
Consulte o Painel do Google Cloud Service Health para informações sobre incidentes que afetam os serviços do Google Cloud, como o Cloud Storage.
Como registrar solicitações brutas
Ao usar ferramentas como a gcloud
ou as bibliotecas de cliente do Cloud Storage, grande parte das informações de solicitação e resposta é processada pela ferramenta. No entanto, às vezes é útil ver detalhes para ajudar na solução de problemas ou ao postar perguntas em fóruns como o Stack Overflow. Use as instruções a seguir para retornar cabeçalhos de solicitação e resposta da ferramenta:
Console
A visualização das informações de solicitação e resposta depende do navegador que você está usando para acessar o Console do Google Cloud. Para o navegador Google Chrome:
Clique no botão Menu principal do Chrome (more_vert).
Selecione Mais ferramentas.
Clique em Ferramentas para Desenvolvedores.
No painel exibido, clique na guia Rede.
Linha de comando
Use sinalizações globais de depuração na solicitação. Exemplo:
gcloud storage ls gs://my-bucket/my-object --log-http --verbosity=debug
Bibliotecas de cliente
C++
Defina a variável de ambiente
CLOUD_STORAGE_ENABLE_TRACING=http
para receber o tráfego HTTP completo.Defina a variável de ambiente CLOUD_STORAGE_ENABLE_CLOG=yes para gerar o registro de cada RPC.
C#
Adicione um registrador por meio de ApplicationContext.RegisterLogger
e defina as opções de geração de registros no gerenciador de mensagens HttpClient
. Para mais informações, consulte a entrada das perguntas frequentes:
Go
Defina a variável de ambiente GODEBUG=http2debug=1
. Para mais informações, consulte o pacote Go/net (em inglês).
Se você também quiser registrar o corpo da solicitação, use um cliente HTTP personalizado.
Java
Crie um arquivo chamado "logging.properties" com o seguinte conteúdo:
# Properties file which configures the operation of the JDK logging facility. # The system will look for this config file to be specified as a system property: # -Djava.util.logging.config.file=${project_loc:googleplus-simple-cmdline-sample}/logging.properties # Set up the console handler (uncomment "level" to show more fine-grained messages) handlers = java.util.logging.ConsoleHandler java.util.logging.ConsoleHandler.level = CONFIG # Set up logging of HTTP requests and responses (uncomment "level" to show) com.google.api.client.http.level = CONFIG
Usar o logging.properties com o Maven
mvn -Djava.util.logging.config.file=path/to/logging.properties insert_command
Para mais informações, consulte Transporte HTTP conectável.
Node.js
Defina a variável de ambiente NODE_DEBUG=https
antes de chamar o script Node.
PHP
Forneça seu próprio gerenciador HTTP ao cliente usando
httpHandler
e configure um middleware para registrar a solicitação
e a resposta.
Python
Use o módulo de geração de registros. Exemplo:
import logging import http.client logging.basicConfig(level=logging.DEBUG) http.client.HTTPConnection.debuglevel=5
Ruby
Na parte superior da .rb file
depois de require "google/cloud/storage"
,
adicione o seguinte:
ruby Google::Apis.logger.level = Logger::DEBUG
Como adicionar cabeçalhos personalizados
Adicionar cabeçalhos personalizados a solicitações é uma ferramenta comum para depuração, como ativar cabeçalhos de depuração ou rastrear uma solicitação. O exemplo a seguir mostra como definir cabeçalhos de solicitação para diferentes ferramentas do Cloud Storage:
Linha de comando
Use a sinalização --additional-headers
, disponível para a maioria
dos comandos. Exemplo:
gcloud storage objects describe gs://my-bucket/my-object --additional-headers=HEADER_NAME=HEADER_VALUE
Em que HEADER_NAME
e
HEADER_VALUE
definem o cabeçalho que será adicionado
à solicitação.
Bibliotecas de cliente
C++
namespace gcs = google::cloud::storage;
gcs::Client client = ...;
client.AnyFunction(... args ..., gcs::CustomHeader("header-name", "value"));
C#
O exemplo a seguir adiciona um cabeçalho personalizado a cada solicitação feita pela biblioteca de cliente.
using Google.Cloud.Storage.V1;
var client = StorageClient.Create();
client.Service.HttpClient.DefaultRequestHeaders.Add("custom-header", "custom-value");
var buckets = client.ListBuckets("my-project-id");
foreach (var bucket in buckets)
{
Console.WriteLine(bucket.Name);
}
Go
A adição de cabeçalhos personalizados às solicitações feitas pela biblioteca de cliente Go exige
que o transporte usado para o cliente seja unido com um RoundTripper
personalizado.
O exemplo a seguir envia cabeçalhos de depuração e registra os cabeçalhos de resposta
correspondentes:
package main
import (
"context"
"io/ioutil"
"log"
"net/http"
"cloud.google.com/go/storage"
"google.golang.org/api/option"
raw "google.golang.org/api/storage/v1"
htransport "google.golang.org/api/transport/http"
)
func main() {
ctx := context.Background()
// Standard way to initialize client:
// client, err := storage.NewClient(ctx)
// if err != nil {
// // handle error
// }
// Instead, create a custom http.Client.
base := http.DefaultTransport
trans, err := htransport.NewTransport(ctx, base, option.WithScopes(raw.DevstorageFullControlScope),
option.WithUserAgent("custom-user-agent"))
if err != nil {
// Handle error.
}
c := http.Client{Transport:trans}
// Add RoundTripper to the created HTTP client.
c.Transport = withDebugHeader{c.Transport}
// Supply this client to storage.NewClient
client, err := storage.NewClient(ctx, option.WithHTTPClient(&c))
if err != nil {
// Handle error.
}
// Use client to make a request
}
type withDebugHeader struct {
rt http.RoundTripper
}
func (wdh withDebugHeader) RoundTrip(r *http.Request) (*http.Response, error) {
headerName := "X-Custom-Header"
r.Header.Add(headerName, "value")
resp, err := wdh.rt.RoundTrip(r)
if err == nil {
log.Printf("Resp Header: %+v, ", resp.Header.Get(headerName))
} else {
log.Printf("Error: %+v", err)
}
return resp, err
}
Java
import com.google.api.gax.rpc.FixedHeaderProvider;
import com.google.api.gax.rpc.HeaderProvider;
import com.google.cloud.WriteChannel;
import com.google.cloud.storage.BlobInfo;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;
import java.io.IOException;
import java.nio.ByteBuffer;
import static java.nio.charset.StandardCharsets.UTF_8;
public class Example {
public void main(String args[]) throws IOException {
HeaderProvider headerProvider =
FixedHeaderProvider.create("custom-header", "custom-value");
Storage storage = StorageOptions.getDefaultInstance()
.toBuilder()
.setHeaderProvider(headerProvider)
.build().getService();
String bucketName = "example-bucket";
String blobName = "test-custom-header";
// Use client with custom header
BlobInfo blob = BlobInfo.newBuilder(bucketName, blobName).build();
byte[] stringBytes;
try (WriteChannel writer = storage.writer(blob)) {
stringBytes = "hello world".getBytes(UTF_8);
writer.write(ByteBuffer.wrap(stringBytes));
}
}
}
Node.js
const storage = new Storage();
storage.interceptors.push({
request: requestConfig => {
Object.assign(requestConfig.headers, {
'X-Custom-Header': 'value',
});
return requestConfig;
},
});
PHP
Todas as chamadas de método que acionam solicitações HTTP aceitam um argumento
$restOptions
opcional como o último argumento. É possível fornecer cabeçalhos
personalizados por solicitação ou cliente.
use Google\Cloud\Storage\StorageClient;
$client = new StorageClient([
'restOptions' => [
'headers' => [
'x-foo' => 'bat'
]
]
]);
$bucket = $client->bucket('my-bucket');
$bucket->info([
'restOptions' => [
'headers' => [
'x-foo' => 'bar'
]
]
]);
Python
from google.cloud import storage
client = storage.Client(
extra_headers={
"x-custom-header": "value"
}
)
Ruby
require "google/cloud/storage"
storage = Google::Cloud::Storage.new
storage.add_custom_headers { 'X-Custom-Header'=> 'value' }
Como acessar buckets com uma configuração do CORS
Se você definiu uma configuração do CORS no bucket e percebeu que as solicitações de entrada de navegadores de cliente estão falhando, siga estas etapas de solução de problemas:
Revise a configuração do CORS no bucket de destino. Se houver várias entradas de configuração do CORS, verifique se os valores de solicitação usados para a solução de problemas são mapeados para valores em uma única entrada de configuração do CORS.
Ao testar a emissão de uma solicitação CORS, verifique se você não está fazendo uma solicitação para o endpoint
storage.cloud.google.com
, que não permite solicitações CORS. Para mais informações sobre endpoints compatíveis com o CORS, consulte Suporte ao CORS do Cloud Storage.Revise a solicitação e a resposta usando a ferramenta da sua preferência. No navegador Chrome, é possível ver essas informações usando as ferramentas padrão para desenvolvedores:
- Clique no menu (more_vert) na barra de ferramentas do Chrome.
- Selecione Mais ferramentas > Ferramentas para desenvolvedores.
- Clique na guia Rede.
- No seu aplicativo ou na linha de comando, envie a solicitação.
- No painel que exibe a atividade da rede, localize a solicitação.
- Na coluna Nome, clique no nome que corresponde à solicitação.
- Clique na guia Cabeçalhos ou Resposta para ver, respectivamente, os cabeçalhos ou o conteúdo da resposta.
Se você não encontrar a solicitação e a resposta, é possível que o navegador tenha armazenado em cache uma tentativa de simulação de solicitação anterior que falhou. Limpar o cache de seu navegador provavelmente limpará o cache da simulação. Se isso não acontecer, defina
MaxAgeSec
na configuração do CORS para um valor menor que o valor padrão de1800
(30 minutos). Aguarde o tempo doMaxAgeSec
antigo e tente a solicitação novamente. Assim, será executada uma nova simulação de solicitação que buscará a nova configuração do CORS e limpará as entradas do cache. Após depurar o problema, aumente novamente o valor deMaxAgeSec
para reduzir o tráfego de simulação para o bucket.Certifique-se de que a solicitação tenha um cabeçalho
Origin
e que o valor do cabeçalho corresponda a pelo menos um dos valores deOrigins
na configuração do CORS do intervalo. É necessário que o esquema, o host e a porta dos valores se correspondam exatamente. Confira alguns exemplos de correspondências aceitáveis:http://origin.example.com
corresponde ahttp://origin.example.com:80
(porque 80 é a porta HTTP padrão), mas não corresponde ahttps://origin.example.com
,http://origin.example.com:8080
,http://origin.example.com:5151
ouhttp://sub.origin.example.com
.https://example.com:443
corresponde ahttps://example.com
, mas não ahttp://example.com
ouhttp://example.com:443
.http://localhost:8080
corresponde somente ahttp://localhost:8080
e não ahttp://localhost:5555
ouhttp://localhost.example.com:8080
.
Para solicitações simples, verifique se o método HTTP da solicitação corresponde a pelo menos um dos valores de
Methods
na configuração do CORS do bucket. Para solicitações de simulação, verifique se o método especificado emAccess-Control-Request-Method
corresponde a pelo menos um dos valores deMethods
.Para solicitações de simulação, verifique se elas incluem um ou mais cabeçalhos
Access-Control-Request-Header
. Em caso afirmativo, verifique se cada valor deAccess-Control-Request-Header
corresponde a um valorResponseHeader
na configuração do CORS do bucket. Todos os cabeçalhos nomeados emAccess-Control-Request-Header
precisam estar presentes na configuração do CORS para que a simulação de solicitação tenha êxito e inclua cabeçalhos do CORS na resposta.
Códigos de erro
A seguir, estão Códigos de status HTTP comuns que talvez você encontre.
301: movido permanentemente
Problema: estou configurando um site estático, e o acesso a um caminho de diretório
retorna um objeto vazio e um código de resposta HTTP 301
.
Solução: se seu navegador faz o download de um objeto de zero byte e você recebe um código de resposta HTTP 301
ao acessar um diretório, como http://www.example.com/dir/
, seu bucket provavelmente contém um objeto vazio com esse nome. Para verificar se esse é o caso e corrigir o problema, siga estas etapas:
- No console do Google Cloud, acesse a página Buckets do Cloud Storage.
- Clique no botão Ativar Cloud Shell na parte superior do Console do Google Cloud.
- Execute
gcloud storage ls --recursive gs://www.example.com/dir/
. Se a saída incluirhttp://www.example.com/dir/
, você terá um objeto vazio nesse local. - Remova o objeto vazio com o comando:
gcloud storage rm gs://www.example.com/dir/
Agora é possível acessar http://www.example.com/dir/
e fazer com que ele retorne o arquivo index.html
do diretório em vez do objeto vazio.
400: Solicitação inválida
Problema: ao executar um upload retomável, recebi este erro e
a mensagem Failed to parse Content-Range header.
Solução: o valor usado no cabeçalho Content-Range
é inválido. Por
exemplo, Content-Range: */*
é inválido e precisa ser especificado como
Content-Range: bytes */*
. Se você receber esse erro, o upload retomável
atual não estará mais ativo e será necessário iniciar um novo upload recuperável.
401: não autorizado
Problema: as solicitações para um bucket público diretamente ou por meio do Cloud CDN
falham com uma resposta HTTP 401: Unauthorized
e
Authentication Required
.
Solução: verifique se o cliente ou qualquer proxy intermediário está adicionando um
cabeçalho Authorization
às solicitações ao Cloud Storage. Qualquer solicitação com
um cabeçalho Authorization
, ainda que vazia, é validada como se fosse uma
tentativa de autenticação.
403: conta desativada
Problema: tentei criar um bucket, mas recebi um erro 403 Account Disabled
.
Solução: esse erro indica que você ainda não ativou o faturamento do projeto associado. Para ver as etapas de ativação do faturamento, consulte Ativar o faturamento para um projeto.
Se o faturamento estiver ativado e você continuar recebendo essa mensagem de erro, entre em contato com o suporte informando o ID do projeto e uma descrição do problema.
403: Proibido
Problema: devo ter permissão para acessar um determinado bucket ou objeto, mas
quando tento fazer isso, recebo um erro 403 - Forbidden
com uma mensagem
semelhante a: example@email.com does not have storage.objects.get access to the
Google Cloud Storage object
.
Solução: falta uma permissão do IAM para o bucket ou objeto necessário para concluir a solicitação. Se você espera conseguir fazer a solicitação, mas não pode, faça as seguintes verificações:
O beneficiário mencionado na mensagem de erro é o esperado? Se a mensagem de erro se referir a um endereço de e-mail inesperado ou a um "autor da chamada anônimo", sua solicitação não está usando as credenciais pretendidas. Isso pode ter ocorrido porque a ferramenta que você está usando para fazer a solicitação foi configurada com as credenciais de outro alias ou entidade, ou porque a solicitação está sendo feita em seu nome por uma conta de serviço.
Você acha que a permissão citada na mensagem de erro era necessária? Se a permissão for inesperada, provavelmente a ferramenta que você está usando precisa de acesso adicional para concluir sua solicitação. Por exemplo, para excluir objetos em massa de um bucket, primeiro o
gcloud
precisa criar uma lista de objetos no bucket para excluir. Essa parte da ação de exclusão em massa exige a permissãostorage.objects.list
, que pode ser surpreendente, já que a meta é a exclusão de objetos, que normalmente requer apenas a permissãostorage.objects.delete
. Se essa for a causa da mensagem de erro, verifique se você tem papéis do IAM com as outras permissões necessárias.Você recebeu o papel do IAM no recurso esperado ou pai? Por exemplo, se você recebeu o papel
Storage Object Viewer
de um projeto e está tentando fazer o download de um objeto, verifique se o objeto está em um bucket dentro do projeto. Você pode ter acidentalmente a permissãoStorage Object Viewer
para um projeto diferente.Você tem permissão para acessar um determinado bucket ou objeto fornecido por meio de um valor de conveniência? A remoção do acesso concedido a um valor de conveniência pode fazer com que principais ativados anteriormente percam acesso aos recursos.
Por exemplo, digamos que jane@example.com tenha o papel básico de Proprietário (
roles/owner
) de um projeto chamadomy-example-project
e a política do IAM conceda ao Criador de objetos do Storage (roles/storage.objectCreator
) para o valor de conveniênciaprojectOwner:my-example-project
. Isso significa que jane@example.com tem as permissões associadas ao papel Criador de objetos do Storage para buckets emmy-example-project
. Se essa concessão for removida, jane@example.com perderá as permissões associadas ao papel Criador de objetos do Storage.Nesse cenário, é possível recuperar o acesso ao bucket ou objeto concedendo a si as permissões necessárias no nível do bucket ou do objeto para realizar as ações necessárias.
Existe uma política de negação do IAM que impede o uso de determinadas permissões? Entre em contato com o administrador da organização para descobrir se uma política de negação de IAM foi implementada.
409: Conflito
Problema: tentei criar um bucket, mas recebi o seguinte erro:
409 Conflict. Sorry, that name is not available. Please try a different one.
Solução: o nome do bucket que você tentou usar (por exemplo, gs://cats
ou gs://dogs
) já está em uso. O Cloud Storage tem um namespace global, portanto, não é possível nomear um bucket com o mesmo nome de um atual. Escolha um nome que não esteja sendo usado.
412: Restrições personalizadas violadas
Problema: minhas solicitações são rejeitadas com um erro 412 orgpolicy
.
Problema: minhas solicitações são rejeitadas com um erro 412 Multiple constraints were violated
.
Solução: verifique com a equipe de administração de segurança se o bucket para o qual você está enviando solicitações está sendo afetado por uma política da organização que usa uma restrição personalizada. O bucket também pode ser afetado por diferentes políticas da organização que entram em conflito. Por exemplo, no cenário em que uma política especifica que os buckets precisam ter a classe de armazenamento Standard e outra política determina que eles precisam ter a classe de armazenamento Coldline.
429: Solicitações demais
Problema: minhas solicitações são rejeitadas com um erro 429 Too Many Requests
.
Solução: você está atingindo o limite do número de solicitações que o Cloud Storage permite para determinado recurso. Consulte as cotas do Cloud Storage para uma discussão sobre os limites do Cloud Storage.
Se sua carga de trabalho consiste em milhares de solicitações por segundo para um bucket, consulte as diretrizes de taxa de solicitação e distribuição de acesso para uma discussão das práticas recomendadas, incluindo aumentar gradualmente a carga de trabalho e evitar nomes de arquivos sequenciais.
Se a carga de trabalho estiver usando 50 Gbps ou mais de saída de rede para locais específicos, verifique o uso da largura de banda para garantir que você não tenha uma cota de largura de banda.
Como diagnosticar erros no Console do Google Cloud
Problema: ao usar o Console do Google Cloud para executar uma operação, recebo uma mensagem de erro genérica. Por exemplo, a mensagem de erro é exibida quando tento excluir um bucket, mas não vejo detalhes sobre o motivo da falha na operação.
Solução: use as notificações do Console do Google Cloud para ver informações detalhadas sobre a operação com falha:
Clique no botão Notificações(notifications) no cabeçalho do Console do Google Cloud.
Um menu suspenso exibe as operações mais recentes realizadas pelo Console do Google Cloud.
Clique no item do qual você quer saber mais.
Uma página é aberta e exibe informações detalhadas sobre a operação.
Clique em cada linha para mostrar as informações detalhadas do erro.
Problema: ao usar o console do Google Cloud, não vejo uma coluna específica.
Solução: para ver uma coluna específica exibida no console do Google Cloud, clique no ícone Opções de exibição de colunas (
) e selecione a coluna que você quer exibir.Pastas simuladas e gerenciadas
Problema: excluí alguns objetos do meu bucket. Agora, a pasta que os continha não aparece no Console do Google Cloud.
Solução: embora o console do Google Cloud exiba o conteúdo do bucket como se houvesse uma estrutura de diretórios, no Cloud Storage não existem pastas. Como resultado, quando você remove todos os objetos com um prefixo comum de um bucket, o ícone de pasta que representa esse grupo de objetos não aparece mais no console do Google Cloud.
Problema: não consigo criar pastas gerenciadas.
Solução: para criar pastas gerenciadas, verifique se os seguintes requisitos foram atendidos:
Você tem um papel do IAM que contém a permissão
storage.managedfolders.create
, como o papel de Administrador de objetos do Storage (roles/storage.objectAdmin
). Para instruções sobre como conceder papéis, consulte Usar permissões do IAM.O acesso uniforme no nível do bucket está ativado no bucket em que você quer criar pastas gerenciadas.
Não há condições do IAM no bucket ou no projeto que usem o tipo de recurso de bucket (
storage.googleapis.com/Bucket
) ou o tipo de recurso de objeto (storage.googleapis.com/Object
). Se algum bucket em um projeto tiver uma condição do IAM que usa um desses tipos de recurso, não será possível criar pastas gerenciadas em nenhum dos buckets desse projeto, mesmo que a condição seja removida posteriormente.
Problema: não consigo desativar o acesso uniforme no nível do bucket porque ele contém pastas gerenciadas.
Solução: o acesso uniforme no nível do bucket não poderá ser desativado se houver pastas gerenciadas no bucket. Para desativar o acesso uniforme no nível do bucket, primeiro você precisará excluir todas as pastas gerenciadas dele.
Erros de sites estáticos
Veja a seguir problemas comuns ao configurar um bucket para hospedar um site estático.
Veiculação HTTPS
Problema: quero veicular meu conteúdo por HTTPS sem usar um balanceador de carga.
Solução: é possível exibir conteúdo estático por HTTPS usando URIs diretos, como https://storage.googleapis.com/my-bucket/my-object
. Para conhecer outras
opções para veicular seu conteúdo por meio de um domínio personalizado usando SSL, faça isto:
- Use uma rede de fornecimento de conteúdo de terceiros com o Cloud Storage.
- Disponibilize o conteúdo estático do site pelo Firebase Hosting em vez do Cloud Storage.
Confirmação de domínio
Problema: não consigo confirmar meu domínio.
Solução: normalmente, o processo de confirmação no Search Console direciona você para fazer o upload de um arquivo no seu domínio. No entanto, talvez não seja possível fazer isso sem antes ter um bucket associado, que só pode ser criado depois de realizar a confirmação de domínio.
Nesse caso, verifique a propriedade usando o método de verificação do provedor de nome de domínio. Consulte Confirmação de propriedade para conhecer as etapas e executar o processo. Ela pode ser feita antes da criação do bucket.
Página inacessível
Problema: recebo uma mensagem de erro Access denied
em uma página da Web exibida pelo meu site.
Solução: verifique se o objeto está compartilhado publicamente. Se não estiver, consulte Como tornar públicos os dados para ver instruções sobre como fazer isso.
Se você fez o upload e compartilhou um objeto anteriormente, mas depois fez upload de uma nova versão dele, será necessário compartilhar o objeto publicamente. Isso ocorre porque a permissão pública é substituída pelo novo upload.
Falha ao atualizar as permissões
Problema: recebo uma mensagem de erro quando tento tornar meus dados públicos.
Solução: verifique se você tem a permissão storage.buckets.setIamPolicy
ou storage.objects.setIamPolicy
. Essas permissões são concedidas, por exemplo, no papel de Administrador do Storage (roles/storage.admin
). Se você tiver a permissão storage.buckets.setIamPolicy
ou storage.objects.setIamPolicy
e ainda receber um erro, o bucket talvez esteja sujeito à prevenção de acesso públicoprevenção de acesso público, que não permite o acesso a allUsers
ou allAuthenticatedUsers
. A prevenção de acesso público pode ser definida diretamente no bucket ou aplicada por uma política da organização definida em um nível superior.
Download de conteúdo
Problema: recebo uma solicitação para baixar o conteúdo da minha página em vez de visualizá-lo no navegador.
Solução: se você especificar um MainPageSuffix
como um objeto que não tem um tipo de conteúdo da Web, os visitantes do site serão instruídos a Baixar o conteúdo em vez de ver o conteúdo da página disponibilizado. Para resolver esse problema, atualize a entrada de metadados Content-Type
com um valor adequado, como text/html
.
Para ver instruções, consulte Como editar metadados de objetos.
Latência
Veja a seguir problemas comuns de latência que você pode encontrar. Além disso, o Painel do Google Cloud Service Health fornece informações sobre incidentes que afetam os serviços do Google Cloud, como o Cloud Storage.
Latência de upload ou download
Problema: há um aumento na latência ao fazer upload ou download.
Solução: considere as seguintes causas comuns de latência de upload e download:
Restrições de CPU ou memória: o sistema operacional do ambiente afetado precisa ter ferramentas para medir o consumo de recursos locais, como o uso da CPU e da memória.
Restrições de E/S do disco: o impacto no desempenho pode ser causado pela E/S do disco local.
Distância geográfica: o desempenho pode ser afetado pela separação física do bucket do Cloud Storage e do ambiente afetado, principalmente em casos intercontinentais. Os testes com um bucket localizado na mesma região do ambiente afetado podem identificar até que ponto a separação geográfica contribui para a latência.
- Se aplicável, o resolvedor de DNS do ambiente afetado precisa usar o protocolo EDNS(0) para que as solicitações do ambiente sejam roteadas por um Google Front End apropriado.
CLI ou latência da biblioteca de cliente
Problema: vejo uma latência maior ao acessar o Cloud Storage com a CLI do Google Cloud ou uma das bibliotecas de cliente.
Solução: a gcloud CLI e as bibliotecas de cliente fazem novas tentativas de solicitação automaticamente quando é útil, e esse comportamento pode aumentar a latência de maneira efetiva, conforme visto pelo usuário final. Use a métrica storage.googleapis.com/api/request_count
do Cloud Monitoring para ver se o Cloud Storage exibe um código de resposta repetível de maneira consistente, como 429
ou 5xx
.
Servidores proxy
Problema: estou me conectando por meio de um servidor proxy, o que preciso fazer?
Solução: para acessar o Cloud Storage por meio de um servidor proxy, permita o acesso a estes domínios:
accounts.google.com
para criar tokens de autenticação OAuth2oauth2.googleapis.com
para realizar trocas de token OAuth2*.googleapis.com
para solicitações de armazenamento
Se o servidor proxy ou a política de segurança não for compatível com a lista de permissões por domínio e aceitar apenas a lista de permissões por bloqueio de rede IP, recomendamos que você configure o servidor proxy para todos os intervalos de endereços IP do Google. É possível encontrar os intervalos de endereços consultando os dados WHOIS no site da ARIN (em inglês). Como prática recomendada, analise periodicamente suas configurações de proxy para garantir que elas correspondam aos endereços IP do Google.
Não recomendamos configurar seu proxy com endereços IP individuais recebidos de consultas únicas de oauth2.googleapis.com
e storage.googleapis.com
. Como os serviços do Google são expostos por meio de nomes DNS que mapeiam um grande número de endereços IP que podem mudar com o tempo, configurar seu proxy com base em uma consulta única pode levar a falhas na conexão com o Cloud Storage.
Se suas solicitações estiverem sendo roteadas por um servidor proxy, talvez seja necessário falar com o administrador da rede para garantir que o cabeçalho Authorization
que contém suas credenciais não seja removido pelo proxy. Sem o cabeçalho Authorization
, suas solicitações serão rejeitadas e você receberá uma erro MissingSecurityHeader
.
Erros do Storage Insights
Problema: a configuração do meu relatório de inventário gera diariamente vários relatórios de inventário.
Solução: se você tiver mais de um milhão de objetos no bucket, vários relatórios de inventário poderão ser gerados como fragmentos. Uma configuração de relatório de inventário gera um só relatório de inventário para cada 1 milhão de objetos no bucket. Por exemplo, quando você tem um bucket com 3.500.000 objetos, a configuração do relatório de inventário no bucket gera quatro fragmentos do relatório de inventário conforme a frequência especificada, com um arquivo de manifesto que contém o número de fragmentos do relatório de inventário gerados e os respectivos nomes dos arquivos.
Problema: os relatórios de inventário não estão aparecendo no bucket de destino.
Solução: se você criou uma configuração de relatório de inventário e não vê a geração desses relatórios no bucket de destino, verifique isto:
Verifique se a data de início especificada na configuração do relatório de inventário corresponde à sua expectativa de quando os relatórios de inventário precisam ser gerados. Para ver instruções sobre como especificar uma data de início, consulte Criar uma configuração de relatório de inventário.
Veja o histórico de relatórios de inventário para verificar se há falhas e as causas raízes. Para ver o histórico de relatórios de inventário, siga estas etapas:
- No console do Google Cloud, acesse a página Buckets do Cloud Storage.
Na lista de buckets, clique no nome do bucket de origem que contém a configuração do relatório de inventário.
Na página Detalhes do bucket, clique na guia Relatórios de inventário.
Na lista de configurações do relatório de inventário, clique no UUID da configuração do relatório de inventário que gerou os relatórios que você quer verificar.
Verifique se há falhas na seção Histórico de relatórios de inventário. É possível manter o ponteiro sobre Ajuda (
) para ver detalhes sobre o motivo da falha.
- No console do Google Cloud, acesse a página Buckets do Cloud Storage.
Verifique se o agente de serviço para envolvidos no projeto tem os papéis do IAM necessários para ler e gravar relatórios de inventário. Para ver instruções, consulte Conceder os papéis necessários ao agente de serviço.
Problema: percebo atrasos aleatórios na geração dos relatórios de inventário.
Solução: o intervalo de tempo entre a geração dos relatórios de inventário pode variar. Pode haver um atraso de até um dia.
A seguir
- Tire mais dúvidas nas Perguntas frequentes sobre o Cloud Storage.
- Saiba mais sobre as opções de suporte.
- Descubra como o Error Reporting pode ajudar você a identificar e entender os erros do Cloud Storage.