Risoluzione dei problemi

Questa pagina descrive i metodi di risoluzione dei problemi relativi agli errori comuni che potresti riscontrare durante l'utilizzo di Cloud Storage.

Consulta la dashboard di Google Cloud Service Health per informazioni sugli incidenti che interessano i servizi Google Cloud come Cloud Storage.

Log delle richieste non elaborate

Quando utilizzi strumenti come gcloud o le librerie client di Cloud Storage, gran parte delle informazioni sulle richieste e sulle risposte viene gestita dallo strumento. Tuttavia, a volte è utile visualizzare i dettagli per facilitare la risoluzione dei problemi o quando si pubblicano domande su forum come Stack Overflow. Segui le seguenti istruzioni per restituire le intestazioni di richiesta e risposta per il tuo strumento:

Console

La visualizzazione delle informazioni sulle richieste e sulle risposte dipende dal browser che utilizzi per accedere alla console Google Cloud. Per il browser Google Chrome:

  1. Fai clic sul pulsante del menu principale di Chrome ().

  2. Seleziona Altri strumenti.

  3. Fai clic su Strumenti per sviluppatori.

  4. Nel riquadro visualizzato, fai clic sulla scheda Rete.

Riga di comando

Utilizza i flag di debug globali nella richiesta. Ad esempio:

gcloud storage ls gs://my-bucket/my-object --log-http --verbosity=debug

Librerie client

C++

  • Imposta la variabile di ambiente CLOUD_STORAGE_ENABLE_TRACING=http per ricevere tutto il traffico HTTP.

  • Imposta la variabile di ambiente CLOUD_STORAGE_ENABLE_CLOG=yes per ottenere il logging di ogni RPC.

C#

Aggiungi un logger tramite ApplicationContext.RegisterLogger e imposta le opzioni di registrazione sul gestore dei messaggi HttpClient. Per ulteriori informazioni, consulta la voce delle domande frequenti.

Vai

Imposta la variabile di ambiente GODEBUG=http2debug=1. Per ulteriori informazioni, consulta il pacchetto Go net/http.

Se vuoi registrare anche il corpo della richiesta, utilizza un client HTTP personalizzato.

Java

  1. Crea un file denominato "logging.properties" con i seguenti contenuti:

    # 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

  2. Utilizzare logging.properties con Maven

    mvn -Djava.util.logging.config.file=path/to/logging.properties insert_command

Per ulteriori informazioni, consulta Trasporto HTTP pluggable.

Node.js

Imposta la variabile di ambiente NODE_DEBUG=https prima di chiamare lo script Node.

PHP

Fornisci al client il tuo gestore HTTP utilizzando httpHandler e configura il middleware per registrare la richiesta e la risposta.

Python

Utilizza il modulo di logging. Ad esempio:

import logging
import http.client

logging.basicConfig(level=logging.DEBUG)
http.client.HTTPConnection.debuglevel=5

Ruby

Nella parte superiore del file .rb file, dopo require "google/cloud/storage", aggiungi quanto segue:

ruby
Google::Apis.logger.level = Logger::DEBUG

Aggiunta di intestazioni personalizzate

L'aggiunta di intestazioni personalizzate alle richieste è uno strumento comune per il debug, ad esempio per attivare le intestazioni di debug o per eseguire il tracing di una richiesta. L'esempio seguente mostra come impostare le intestazioni di richiesta per diversi strumenti Cloud Storage:

Riga di comando

Utilizza il flag --additional-headers, disponibile per la maggior parte dei comandi. Ad esempio:

gcloud storage objects describe gs://my-bucket/my-object --additional-headers=HEADER_NAME=HEADER_VALUE

Dove HEADER_NAME e HEADER_VALUE definiscono l'intestazione che stai aggiungendo alla richiesta.

Librerie client

C++

namespace gcs = google::cloud::storage;
gcs::Client client = ...;
client.AnyFunction(... args ..., gcs::CustomHeader("header-name", "value"));

C#

Il seguente esempio aggiunge un'intestazione personalizzata a ogni richiesta effettuata dalla libreria client.

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);
}

Vai

L'aggiunta di intestazioni personalizzate alle richieste effettuate dalla libreria client Go richiede di avvolgere il trasporto utilizzato per il client con un RoundTripper personalizzato. L'esempio seguente invia intestazioni di debug e registra le intestazioni di risposta corrispondenti:

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

Tutte le chiamate ai metodi che attivano le richieste HTTP accettano un argomento facoltativo $restOptions come ultimo argomento. Puoi fornire intestazioni personalizzate su base per richiesta o per 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' }

Accesso ai bucket con una configurazione CORS

Se hai impostato una configurazione CORS nel tuo bucket e noti che le richieste in arrivo dai browser client non vanno a buon fine, prova a seguire questi passaggi per la risoluzione dei problemi:

  1. Esamina la configurazione CORS nel bucket di destinazione. Se sono presenti più voci di configurazione CORS, assicurati che i valori di richiesta utilizzati per la risoluzione dei problemi corrispondano a quelli di una singola voce di configurazione CORS.

  2. Quando testi l'emissione di una richiesta CORS, verifica di non inviare una richiesta all'endpoint storage.cloud.google.com, che non consente le richieste CORS. Per ulteriori informazioni sugli endpoint supportati per CORS, consulta Supporto CORS di Cloud Storage.

  3. Esamina una richiesta e una risposta utilizzando lo strumento che preferisci. In un browser Chrome, puoi utilizzare gli Strumenti per sviluppatori standard per visualizzare queste informazioni:

    1. Fai clic sul menu di Chrome () nella barra degli strumenti del browser.
    2. Seleziona Altri strumenti > Strumenti per sviluppatori.
    3. Fai clic sulla scheda Rete.
    4. Invia la richiesta dall'applicazione o dalla riga di comando.
    5. Individua la richiesta nel riquadro che mostra l'attività di rete.
    6. Nella colonna Nome, fai clic sul nome corrispondente alla richiesta.
    7. Fai clic sulla scheda Intestazioni per visualizzare le intestazioni di risposta o sulla scheda Risposta per visualizzare i contenuti della risposta.

    Se non vedi una richiesta e una risposta, è possibile che il browser abbia memorizzato nella cache un precedente tentativo di richiesta di preflight non riuscito. Se svuoti la cache del browser, viene svuotata anche la cache di preflight. In caso contrario, imposta il valore MaxAgeSec nella configurazione CORS su un valore inferiore rispetto al valore predefinito di 1800 (30 minuti), attendi il tempo del vecchio MaxAgeSec e riprova a effettuare la richiesta. Viene eseguita una nuova richiesta di preflight, che recupera la nuova configurazione CORS ed elimina le voci della cache. Una volta risolto il problema, imposta nuovamente MaxAgeSec su un valore più elevato per ridurre il traffico di preflight nel bucket.

  4. Assicurati che la richiesta abbia un'intestazione Origin e che il valore dell'intestazione sia uguale ad almeno uno dei valori Origins nella configurazione CORS del bucket. Tieni presente che lo schema, l'host e la porta dei valori devono corrispondere esattamente. Ecco alcuni esempi di corrispondenze accettabili:

    • http://origin.example.com corrisponde a http://origin.example.com:80 (perché 80 è la porta HTTP predefinita), ma non corrisponde a https://origin.example.com, http://origin.example.com:8080, http://origin.example.com:5151 o http://sub.origin.example.com.

    • https://example.com:443 corrisponde a https://example.com, ma non a http://example.com o http://example.com:443.

    • http://localhost:8080 corrisponde esattamente solo a http://localhost:8080 e non corrisponde a http://localhost:5555 o http://localhost.example.com:8080.

  5. Per le richieste semplici, assicurati che il metodo HTTP della richiesta corrisponda almeno a uno dei valori Methods nella configurazione CORS del bucket. Per le richieste di preflight, assicurati che il metodo specificato in Access-Control-Request-Method corrisponda ad almeno uno dei valori Methods.

  6. Per le richieste di preflight, controlla se sono incluse una o più intestazioni Access-Control-Request-Header. In questo caso, assicurati che ogni valore Access-Control-Request-Header corrisponda a un valore ResponseHeader nella configurazione CORS del bucket. Affinché la richiesta preflight vada a buon fine e includa le intestazioni CORS nella risposta, tutte le intestazioni indicate in Access-Control-Request-Header devono essere presenti nella configurazione CORS.

Codici di errore

Di seguito sono riportati i codici di stato HTTP comuni che potresti riscontrare.

301: Spostato definitivamente

Problema: sto configurando un sito web statico e l'accesso a un percorso di directory restituisce un oggetto vuoto e un codice di risposta HTTP 301.

Soluzione: se il browser scarica un oggetto di zero byte e ricevi un codice di risposta HTTP 301 quando accedi a una directory, ad esempio http://www.example.com/dir/, è molto probabile che il tuo bucket contenga un oggetto vuoto con quel nome. Per verificare che sia così e risolvere il problema:

  1. Nella console Google Cloud, vai alla pagina Bucket in Cloud Storage.

    Vai a Bucket

  2. Fai clic sul pulsante Attiva Cloud Shell nella parte superiore della console Google Cloud.
  3. Esegui gcloud storage ls --recursive gs://www.example.com/dir/. Se l'output include http://www.example.com/dir/, in quella posizione è presente un oggetto vuoto.
  4. Rimuovi l'oggetto vuoto con il comando: gcloud storage rm gs://www.example.com/dir/

Ora puoi accedere a http://www.example.com/dir/ e far restituire il file index.html della directory anziché l'oggetto vuoto.

400: Bad Request

Problema: durante l'esecuzione di un caricamento riavviabile, ho ricevuto questo errore e il messaggio Failed to parse Content-Range header.

Soluzione: il valore utilizzato nell'intestazione Content-Range non è valido. Ad esempio, Content-Range: */* non è valido e deve essere specificato come Content-Range: bytes */*. Se ricevi questo errore, il caricamento con possibilità di ripresa corrente non è più attivo e devi avviarne uno nuovo.

401: Non autorizzato

Problema: le richieste a un bucket pubblico direttamente o utilizzando Cloud CDN non vanno a buon fine con una risposta HTTP 401: Unauthorized e Authentication Required.

Soluzione: verifica che il client o qualsiasi proxy intermedio non stia aggiungendo un'intestazione Authorization alle richieste a Cloud Storage. Qualsiasi richiesta con un'intestazione Authorization, anche se vuota, viene convalidata come se fosse un tentativo di autenticazione.

403: Account disattivato

Problema: ho provato a creare un bucket, ma ho ricevuto un errore 403 Account Disabled.

Soluzione: questo errore indica che non hai ancora attivato la fatturazione per il progetto associato. Per la procedura di attivazione della fatturazione, consulta Abilitare la fatturazione per un progetto.

Se la fatturazione è attiva e continui a ricevere questo messaggio di errore, puoi rivolgerti all'assistenza fornendo il tuo ID progetto e una descrizione del problema.

403: Forbidden

Problema: dovrei avere l'autorizzazione per accedere a un determinato bucket o oggetto, ma quando provo a farlo, ricevo un errore 403 - Forbidden con un messaggio simile a: example@email.com does not have storage.objects.get access to the Google Cloud Storage object.

Soluzione: manca un'autorizzazione IAM per il bucket o l'oggetto necessaria per completare la richiesta. Se ritieni di poter effettuare la richiesta, ma non ci riesci, esegui i seguenti controlli:

  1. Il concesso a cui si fa riferimento nel messaggio di errore è quello che ti aspettavi? Se il messaggio di errore fa riferimento a un indirizzo email imprevisto o a "Chiamata anonima", significa che la richiesta non utilizza le credenziali previste. Questo potrebbe essere dovuto al fatto che lo strumento che utilizzi per effettuare la richiesta è stato configurato con le credenziali di un altro alias o di un'altra entità oppure che la richiesta viene effettuata per tuo conto da un account di servizio.

  2. L'autorizzazione a cui fa riferimento il messaggio di errore è quella che pensavi di aver bisogno? Se l'autorizzazione non è prevista, è probabile che lo strumento che stai utilizzando richieda un accesso aggiuntivo per completare la richiesta. Ad esempio, per eliminare collettivamente gli oggetti in un bucket, gcloud deve prima creare un elenco degli oggetti da eliminare nel bucket. Questa parte dell'azione di eliminazione collettiva richiede l'autorizzazione storage.objects.list, il che potrebbe sorprendere, dato che l'obiettivo è l'eliminazione di oggetti, che in genere richiede solo l'autorizzazione storage.objects.delete. Se questa è la causa del messaggio di errore, assicurati di disporre dei ruoli IAM con le autorizzazioni aggiuntive necessarie.

  3. Ti è stato concesso il ruolo IAM sulla risorsa o sulla risorsa padre prevista? Ad esempio, se ti è stato concesso il ruolo Storage Object Viewer per un progetto e stai tentando di scaricare un oggetto, assicurati che l'oggetto si trovi in un bucket del progetto. Potresti avere inavvertitamente l'autorizzazione Storage Object Viewer per un altro progetto.

  4. L'autorizzazione ad accedere a un determinato bucket o oggetto viene fornita tramite un valore di convenienza? La rimozione dell'accesso concesso a un valore di comodità può causare la perdita dell'accesso alle risorse da parte dei principali abilitati in precedenza.

    Ad esempio, supponiamo che jane@example.com abbia il ruolo di base Proprietario (roles/owner) per un progetto denominato my-example-project e che il criterio IAM del progetto conceda il ruolo Creatore di oggetti archiviazione (roles/storage.objectCreator) al valore di convenienza projectOwner:my-example-project. Ciò significa che jane@example.com ha le autorizzazioni associate al ruolo Creatore oggetti Storage per i bucket all'interno di my-example-project. Se questa concessione viene rimossa, jane@example.com perde le autorizzazioni associate al ruolo Creatore oggetti Storage.

    In questo caso, puoi riottenere l'accesso al bucket o all'oggetto concedendoti le autorizzazioni necessarie a livello di bucket o di oggetto per eseguire le azioni necessarie.

  5. Esiste un criterio di rifiuto IAM che ti impedisce di utilizzare determinate autorizzazioni? Puoi contattare l'amministratore della tua organizzazione per scoprire se è stato implementato un criterio di rifiuto IAM.

409: conflitto

Problema: ho provato a creare un bucket, ma ho ricevuto il seguente errore: 

409 Conflict. Sorry, that name is not available. Please try a different one.

Soluzione: il nome del bucket che hai provato a utilizzare (ad es. gs://cats o gs://dogs) è già in uso. Cloud Storage ha uno spazio dei nomi globale, pertanto non puoi assegnare a un bucket lo stesso nome di un bucket esistente. Scegli un nome che non sia in uso.

412: vincoli personalizzati violati

Problema: le mie richieste vengono rifiutate con un errore 412 orgpolicy.

Problema: le mie richieste vengono rifiutate con un 412 Multiple constraints were violated errore.

Soluzione: rivolgiti al team di amministratori della sicurezza per verificare se il bucket a cui invii le richieste è interessato da un criterio dell'organizzazione che utilizza una limitazione personalizzata. Il bucket potrebbe essere interessato anche da diversi criteri dell'organizzazione in conflitto tra loro. Ad esempio, se un'impostazione specifica che i bucket devono avere la classe di archiviazione Standard e un'altra che devono avere la classe di archiviazione Coldline.

429: Too Many Requests

Problema: le mie richieste vengono rifiutate con un errore 429 Too Many Requests.

Soluzione: hai raggiunto il limite di richieste consentito da Cloud Storage per una determinata risorsa. Consulta le quote di Cloud Storage per una discussione sui limiti di Cloud Storage.

Diagnostica degli errori della console Google Cloud

Problema: quando utilizzo la console Google Cloud per eseguire un'operazione, viene visualizzato un messaggio di errore generico. Ad esempio, vedo un messaggio di errore quando provo a eliminare un bucket, ma non vedo i dettagli del motivo per cui l'operazione non è riuscita.

Soluzione: utilizza le notifiche della console Google Cloud per visualizzare informazioni dettagliate sull'operazione non riuscita:

  1. Fai clic sul pulsante Notifiche () nell'intestazione della console Google Cloud.

    Un menu a discesa mostra le operazioni più recenti eseguite dalla console Google Cloud.

  2. Fai clic sull'elemento di cui vuoi saperne di più.

    Si apre una pagina che mostra informazioni dettagliate sull'operazione.

  3. Fai clic su ogni riga per espandere le informazioni dettagliate sull'errore.

Problema: quando utilizzo la console Google Cloud, non vedo una determinata colonna.

Soluzione: per visualizzare una determinata colonna nella console Google Cloud, fai clic sull'icona Opzioni di visualizzazione delle colonne () e seleziona la colonna da visualizzare.

Cartelle simulate e cartelle gestite

Problema: ho eliminato alcuni oggetti nel mio bucket e ora la cartella che li conteneva non viene visualizzata nella console Google Cloud.

Soluzione: anche se la console Google Cloud mostra i contenuti del bucket come se esistesse una struttura di directory, le cartelle non esistono fondamentalmente in Cloud Storage. Di conseguenza, quando rimuovi tutti gli oggetti con un prefisso comune da un bucket, l'icona della cartella che rappresenta quel gruppo di oggetti non viene più visualizzata nella console Google Cloud.

Problema: non riesco a creare cartelle gestite.

Soluzione: per creare cartelle gestite, assicurati che siano soddisfatti i seguenti requisiti:

  • Hai un ruolo IAM che contiene l'autorizzazionestorage.managedfolders.create, ad esempio il ruolo Amministratore oggetti archiviazioneroles/storage.objectAdmin. Per istruzioni su come concedere i ruoli, consulta Utilizzare le autorizzazioni IAM.

  • L'accesso uniforme a livello di bucket è abilitato nel bucket in cui vuoi creare le cartelle gestite.

  • Non sono presenti condizioni IAM sul bucket o sul progetto che utilizzano il tipo di risorsa bucket (storage.googleapis.com/Bucket) o il tipo di risorsa oggetto (storage.googleapis.com/Object). Se un bucket all'interno di un progetto ha una condizione IAM che utilizza uno di questi tipi di risorse, non è possibile creare cartelle gestite in nessuno dei bucket all'interno del progetto, anche se la condizione viene rimossa in un secondo momento.

Problema: non riesco a disattivare l'accesso uniforme a livello di bucket perché nel mio bucket sono presenti cartelle gestite.

Soluzione: l'accesso uniforme a livello di bucket non può essere disattivato se nel bucket sono presenti cartelle gestite. Per disattivare l'accesso uniforme a livello di bucket, devi prima eliminare tutte le cartelle gestite nel bucket.

Errori del sito web statico

Di seguito sono riportati alcuni problemi comuni che potresti riscontrare quando configuri un bucket per ospitare un sito web statico.

Pubblicazione tramite HTTPS

Problema: voglio pubblicare i miei contenuti tramite HTTPS senza utilizzare un bilanciatore del carico.

Soluzione: puoi pubblicare contenuti statici tramite HTTPS utilizzando URI diretti come https://storage.googleapis.com/my-bucket/my-object. Per altre opzioni per pubblicare i tuoi contenuti tramite un dominio personalizzato su SSL, puoi:

Verifica del dominio

Problema: non riesco a verificare il mio dominio.

Soluzione: in genere, la procedura di verifica in Search Console ti chiede di caricare un file sul tuo dominio, ma potresti non avere un modo per farlo senza prima avere un bucket associato, che puoi creare solo dopo aver eseguito la verifica del dominio.

In questo caso, verifica la proprietà utilizzando il metodo di verifica del provider del nome di dominio. Per scoprire come procedere, consulta la sezione Verifica della proprietà. Questa verifica può essere eseguita prima della creazione del bucket.

Pagina non accessibile

Problema: ricevo un messaggio di errore Access denied per una pagina web pubblicata dal mio sito web.

Soluzione: verifica che l'oggetto sia condiviso pubblicamente. In caso contrario, consulta la sezione Rendere pubblici i dati per istruzioni su come procedere.

Se hai caricato e condiviso un oggetto in precedenza, ma poi ne carichi una nuova versione, devi condividerlo di nuovo pubblicamente. Questo perché l'autorizzazione pubblica viene sostituita dal nuovo caricamento.

Aggiornamento autorizzazione non riuscito

Problema: ricevo un errore quando tento di rendere pubblici i miei dati.

Soluzione: assicurati di disporre dell'autorizzazione storage.buckets.setIamPolicy o storage.objects.setIamPolicy. Queste autorizzazioni vengono concesse, ad esempio, nel ruolo Amministratore dello spazio di archiviazione (roles/storage.admin). Se disponi dell'autorizzazione storage.buckets.setIamPolicy o dell'autorizzazione storage.objects.setIamPolicy e continui a ricevere un errore, il tuo bucket potrebbe essere soggetto alla prevenzione dell'accesso pubblico, che non consente l'accesso a allUsers o allAuthenticatedUsers. La prevenzione dell'accesso pubblico può essere impostata direttamente sul bucket o applicata tramite un criterio dell'organizzazione impostato a un livello superiore.

Download di contenuti

Problema: mi viene chiesto di scaricare i contenuti della mia pagina anziché poterli visualizzare nel browser.

Soluzione: se specifichi un MainPageSuffix come oggetto che non ha un tipo di contenuti web, ai visitatori del sito viene chiesto di scaricare i contenuti anziché poter vedere i contenuti della pagina pubblicati. Per risolvere il problema, aggiorna la voce dei metadati Content-Type con un valore appropriato, ad esempio text/html. Per le istruzioni, vedi Modificare i metadati degli oggetti.

Latenza

Di seguito sono riportati alcuni problemi di latenza comuni che potresti riscontrare. Inoltre, la dashboard di Google Cloud Service Health fornisce informazioni sugli incidenti che interessano i servizi Google Cloud come Cloud Storage.

Latenza in upload o download

Problema: riscontro un aumento della latenza durante il caricamento o il download.

Soluzione: tieni presenti le seguenti cause comuni della latenza di caricamento e download:

  • Limitazioni della CPU o della memoria: il sistema operativo dell'ambiente interessato deve avere strumenti per misurare il consumo di risorse locali, come l'utilizzo della CPU e della memoria.

  • Limitazioni di I/O del disco: l'impatto sulle prestazioni potrebbe essere causato dall'I/O del disco locale.

  • Distanza geografica: le prestazioni possono essere influenzate dalla separazione fisica del bucket Cloud Storage e dell'ambiente interessato, in particolare in casi transcontinentali. I test con un bucket situato nella stessa regione del tuo ambiente interessato possono identificare la misura in cui la separazione geografica contribuisce alla latenza.

    • Se applicabile, il resolver DNS dell'ambiente interessato deve utilizzare il protocollo EDNS(0) in modo che le richieste provenienti dall'ambiente siano inoltrate tramite un Google Front End appropriato.

Latenza dell'interfaccia a riga di comando o della libreria client

Problema: noto un aumento della latenza quando accedo a Cloud Storage con Google Cloud CLI o una delle librerie client.

Soluzione: la gcloud CLI e le librerie client riprovano automaticamente le richieste quando è utile farlo e questo comportamento può aumentare efficacemente la latenza dal punto di vista dell'utente finale. Utilizza la metrica storage.googleapis.com/api/request_count di Cloud Monitoring per verificare se Cloud Storage restituisce in modo coerente un codice di risposta ripetibile, ad esempio 429 o 5xx.

Server proxy

Problema: mi connetto tramite un server proxy. Che cosa devo fare?

Soluzione: per accedere a Cloud Storage tramite un server proxy, devi consentire l'accesso a questi domini:

  • accounts.google.com per creare token di autenticazione OAuth2
  • oauth2.googleapis.com per eseguire scambi di token OAuth2
  • *.googleapis.com per le richieste di spazio di archiviazione

Se il tuo server proxy o i tuoi criteri di sicurezza non supportano la lista consentita per dominio e supportano invece solo la lista consentita per blocco di rete IP, ti consigliamo vivamente di configurare il server proxy per tutti gli intervalli di indirizzi IP di Google. Puoi trovare gli intervalli di indirizzi eseguendo una query sui dati WHOIS su ARIN. Come best practice, devi esaminare periodicamente le impostazioni del proxy per assicurarti che corrispondano agli indirizzi IP di Google.

Sconsigliamo di configurare il proxy con singoli indirizzi IP ottenuti da ricerche una tantum di oauth2.googleapis.com e storage.googleapis.com. Poiché i servizi Google sono esposti utilizzando nomi DNS che mappano a un numero elevato di indirizzi IP che possono cambiare nel tempo, la configurazione del proxy in base a una ricerca una tantum potrebbe comportare errori di connessione a Cloud Storage.

Se le richieste vengono inoltrate tramite un server proxy, potresti dover verificare con l'amministratore di rete che l'intestazione Authorization contenente le tue credenziali non venga rimossa dal proxy. Senza l'intestazione Authorization, le richieste vengono rifiutate e ricevi un MissingSecurityHeader errore.

Errori di Storage Insights

Problema: la mia configurazione dei report sull'inventario genera più report sull'inventario ogni giorno.

Soluzione: se il bucket contiene più di 1.000.000 di oggetti, è possibile generare più report sull'inventario come parti. Una configurazione del report sull'inventario genera un report per ogni 1000000 di oggetti nel bucket. Ad esempio, se hai un bucket con 3.500.000 oggetti, la configurazione del report sull'inventario nel bucket genererà quattro frammenti di report sull'inventario in base alla frequenza specificata, insieme a un file manifest contenente il numero di frammenti di report sull'inventario generati e i relativi nomi file.

Problema: i report sull'inventario non vengono visualizzati nel bucket di destinazione.

Soluzione: se hai creato una configurazione dei report di inventario e non vedi i report di inventario generati nel bucket di destinazione, controlla quanto segue:

  • Assicurati che la data di inizio specificata nella configurazione dei report di inventario sia in linea con le tue aspettative in merito al momento in cui devono essere generati i report di inventario. Per istruzioni su come specificare una data di inizio, consulta Creare una configurazione di report dell'inventario.

  • Visualizza la cronologia dei report di inventario per verificare la presenza di errori e le relative cause. Per visualizzare la cronologia dei report sull'inventario:

    1. Nella console Google Cloud, vai alla pagina Bucket in Cloud Storage.

      Vai a Bucket

    2. Nell'elenco dei bucket, fai clic sul nome del bucket di origine contenente la configurazione del report sull'inventario.

    3. Nella pagina Dettagli bucket, fai clic sulla scheda Report sull'inventario.

    4. Nell'elenco delle configurazioni dei report sull'inventario, fai clic sull'UUID della configurazione dei report sull'inventario che ha generato i report da controllare.

    5. Controlla la presenza di errori nella sezione Cronologia report sull'inventario. Puoi tenere premuto il cursore sopra Guida () per visualizzare i dettagli sul motivo dell'errore.

  • Assicurati che all'agente di servizio a livello di progetto siano concessi i ruoli IAM necessari per leggere e scrivere i report sull'inventario. Per le istruzioni, consulta Concedere all'agente di servizio i ruoli richiesti.

Problema: riscontro ritardi casuali nella generazione dei report sull'inventario.

Soluzione: l'intervallo di tempo tra la generazione dei report sull'inventario può variare. Potresti notare un ritardo fino a un giorno.

Passaggi successivi