Dépannage

Cette page décrit les méthodes de dépannage des erreurs courantes que vous pouvez rencontrer lors de l'utilisation de Cloud Storage.

Consultez le tableau de bord Service Health de Google Cloud pour en savoir plus sur les incidents affectant les services Google Cloud tels que Cloud Storage.

Journalisation des requêtes brutes

Lorsque vous utilisez des outils tels que gcloud ou les bibliothèques clientes Cloud Storage, la plupart des informations sur les requêtes et les réponses sont gérées par l'outil. Cependant, il est parfois utile d'afficher les détails pour faciliter le dépannage ou lorsque vous publiez des questions sur des forums tels que Stack Overflow. Suivez les instructions ci-dessous pour renvoyer des en-têtes de requête et de réponse pour votre outil :

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

import logging
import http.client

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

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

Ajouter des en-têtes personnalisés

L'ajout d'en-têtes personnalisés aux requêtes est un outil courant pour le débogage, par exemple pour l'activation des en-têtes de débogage ou pour le suivi d'une requête. L'exemple suivant montre comment définir des en-têtes de requête pour différents outils Cloud Storage :

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

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

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

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
}

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

const storage = new Storage();

storage.interceptors.push({
  request: requestConfig => {
    Object.assign(requestConfig.headers, {
      'X-Custom-Header': 'value',
      });
    return requestConfig;
  },
});

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'
       ]
   ]
]);

from google.cloud import storage

client = storage.Client(
    extra_headers={
        "x-custom-header": "value"
    }
)

require "google/cloud/storage"

storage = Google::Cloud::Storage.new

storage.add_custom_headers { 'X-Custom-Header'=> 'value' }

Accéder aux buckets avec une configuration CORS

Si vous avez défini une configuration CORS sur votre bucket et que vous remarquez que les requêtes entrantes des navigateurs clients échouent, essayez les étapes de dépannage suivantes:

1. Vérifiez la configuration CORS sur le bucket cible. Si vous disposez de plusieurs entrées de configuration CORS, assurez-vous que les valeurs de requête que vous utilisez pour le dépannage sont mappées avec les valeurs d'une seule entrée de configuration CORS.

2. Lorsque vous testez l'émission d'une requête CORS, vérifiez que vous n'envoyez pas de requête au point de terminaison storage.cloud.google.com, qui n'autorise pas les requêtes CORS. Pour plus d'informations sur les points de terminaison compatibles avec le CORS, consultez la section Compatibilité du CORS avec Cloud Storage.

3. Examinez une requête et sa réponse à l'aide de l'outil de votre choix. Dans un navigateur Chrome, vous pouvez utiliser les outils de développement standards pour afficher ces informations :

   1. Cliquez sur le menu Chrome (more_vert) dans la barre d'outils du navigateur.
   2. Sélectionnez Plus d'outils > Outils de développement.
   3. Cliquez sur l'onglet Réseau.
   4. À partir de votre application ou de votre ligne de commande, envoyez la requête.
   5. Dans le volet affichant l'activité du réseau, localisez la requête.
   6. Dans la colonne Name (Nom), cliquez sur le nom correspondant à la requête.
   7. Cliquez sur l'onglet Headers (En-têtes) pour voir les en-têtes de réponse ou sur l'onglet Response (Réponse) pour voir le contenu de la réponse.

   Si vous ne voyez ni requête ni réponse, il est possible que votre navigateur ait mis en cache une tentative de requête de pré-vérification ayant échoué précédemment. Si vous videz le cache de votre navigateur, cela devrait également vider le cache de pré-vérification. Dans le cas contraire, diminuez la valeur MaxAgeSec dans votre configuration CORS à une valeur inférieure à la valeur par défaut de 1800 (30 minutes), attendez pendant la durée de l'ancienne valeur MaxAgeSec, puis renouvelez la requête. Cela entraîne l'exécution d'une nouvelle requête de pré-vérification, qui récupère la nouvelle configuration CORS et purge les entrées du cache. Une fois que vous avez résolu votre problème, augmentez à nouveau la valeur MaxAgeSec afin de réduire le trafic de pré-vérification dans le bucket.

4. Assurez-vous que la requête comporte un en-tête Origin et que la valeur de celui-ci correspond à au moins l'une des valeurs Origins figurant dans la configuration CORS du bucket. Notez que le schéma, l'hôte et le port des valeurs doivent correspondre exactement. Voici quelques exemples de correspondances acceptables:

   • http://origin.example.com correspond à http://origin.example.com:80 (car 80 est le port HTTP par défaut), mais ne correspond pas à https://origin.example.com, ni à http://origin.example.com:8080, http://origin.example.com:5151 et http://sub.origin.example.com.

   • https://example.com:443 correspond à https://example.com, mais pas à http://example.com ni à http://example.com:443.

   • http://localhost:8080 ne correspond exactement qu'à http://localhost:8080 et ne correspond pas à http://localhost:5555 ni à http://localhost.example.com:8080.

5. Pour les requêtes simples, assurez-vous que la méthode HTTP de la requête correspond à au moins l'une des valeurs Methods figurant dans la configuration CORS du bucket. Pour les requêtes de pré-vérification, assurez-vous que la méthode spécifiée dans Access-Control-Request-Method correspond à au moins l'une des valeurs Methods.

6. Pour les requêtes de pré-vérification, vérifiez si elles incluent un ou plusieurs en-têtes Access-Control-Request-Header. Le cas échéant, assurez-vous que chaque valeur Access-Control-Request-Header correspond à une valeur ResponseHeader de la configuration CORS du bucket. Tous les en-têtes nommés dans Access-Control-Request-Header doivent figurer dans la configuration CORS pour que la requête de pré-vérification aboutisse et pour inclure les en-têtes CORS dans la réponse.

Codes d'erreur

Vous trouverez ci-dessous des codes d'état HTTP courants que vous pouvez rencontrer.

301 Moved Permanently

Problème : Je configure un site Web statique, et l'accès à un chemin de répertoire renvoie un objet vide et un code de réponse HTTP 301.

Solution : Si votre navigateur télécharge un objet de zéro octet et que vous obtenez un code de réponse HTTP 301 lors de l'accès à un répertoire, par exemple http://www.example.com/dir/, votre bucket contient probablement un objet vide portant ce nom. Pour vérifier que c'est bien le cas et résoudre le problème, procédez comme suit :

1. Dans la console Google Cloud, accédez à la page Buckets Cloud Storage.
   

   Accéder à la page "Buckets"

2. Cliquez sur le bouton Activer Cloud Shell en haut de la console Google Cloud.
3. Exécutez gcloud storage ls --recursive gs://www.example.com/dir/. Si le résultat inclut http://www.example.com/dir/, un objet vide se trouve à cet emplacement.
4. Supprimez l'objet vide avec la commande suivante : gcloud storage rm gs://www.example.com/dir/

Vous pouvez maintenant accéder à http://www.example.com/dir/. Le fichier index.html de ce répertoire est renvoyé à la place de l'objet vide.

400 Bad Request

Problème : lors d'une importation avec reprise, j'ai reçu cette erreur et le message Failed to parse Content-Range header..

Solution : la valeur que vous avez utilisée dans l'en-tête Content-Range n'est pas valide. Par exemple, la valeur Content-Range: */* n'est pas valide et doit être spécifiée sous la forme Content-Range: bytes */*. Si vous rencontrez cette erreur, votre importation avec reprise actuelle n'est plus active, et vous devez en lancer une nouvelle.

401 Unauthorized

Problème : Les requêtes adressées directement à un bucket public ou via Cloud CDN échouent avec une erreur HTTP 401: Unauthorized (HTTP 401 : Opération non autorisée) et une réponse Authentication Required (Authentification requise).

Solution : Vérifiez que votre client ou tout proxy intermédiaire n'ajoute pas d'en-tête Authorization aux requêtes à Cloud Storage. Toute requête comportant un en-tête Authorization, même si elle est vide, est validée comme s'il s'agissait d'une tentative d'authentification.

403 Account Disabled

Problème : J'ai essayé de créer un bucket, mais une erreur 403 Account Disabled s'est affichée.

Solution : Cette erreur indique que vous n'avez pas encore activé la facturation pour le projet associé. Pour connaître la procédure à suivre, consultez la section Activer la facturation pour un projet.

Si la facturation est activée et que vous continuez à recevoir ce message d'erreur, vous pouvez contacter l'assistance en incluant l'ID du projet et une description de votre problème.

403 Forbidden

Problème : Je devrais être autorisé à accéder à un bucket ou à un objet spécifique, mais lorsque j'essaie d'y accéder, une erreur 403 - Forbidden s'affiche avec un message semblable à celui-ci : example@email.com does not have storage.objects.get access to the Google Cloud Storage object.

Solution : il vous manque une autorisation IAM, pour le bucket ou l'objet, requise pour traiter la requête. Si vous pensez pouvoir effectuer la requête mais que cela s'avère impossible, effectuez les vérifications suivantes :

1. Le bénéficiaire mentionné dans le message d'erreur est-il celui auquel vous vous attendiez ? Si le message d'erreur fait référence à une adresse e-mail inattendue ou à un "appelant anonyme", votre requête n'utilise pas les identifiants prévus. Cela peut être dû au fait que l'outil que vous utilisez pour effectuer la requête a été configuré avec les identifiants d'un autre alias ou d'une autre entité, ou que la requête est effectuée en votre nom par Compte de service.

2. L'autorisation référencée dans le message d'erreur est-elle bien celle dont vous aviez besoin ? Si l'autorisation est inattendue, il est probable que l'outil que vous utilisez nécessite un accès supplémentaire pour traiter votre requête. Par exemple, pour supprimer des objets d'un bucket de manière groupée, gcloud doit d'abord créer une liste d'objets dans le bucket à supprimer. Cette partie de l'action de suppression groupée nécessite l'autorisation storage.objects.list, ce qui peut être assez surprenant, étant donné que l'objectif est la suppression d'objet, qui ne nécessite normalement que l'autorisation storage.objects.delete. Si c'est la cause de votre message d'erreur, assurez-vous que les rôles IAM disposant des autorisations supplémentaires nécessaires vous sont bien attribués.

3. Disposez-vous du rôle IAM sur la ressource prévue ou la ressource parente ? Par exemple, si vous disposez du rôle Storage Object Viewer pour un projet et que vous essayez de télécharger un objet, assurez-vous que l'objet se trouve dans un bucket situé dans le projet. L'autorisation Storage Object Viewer vous a peut être été attribuée par inadvertance pour un autre projet.

4. Votre autorisation d'accéder à un bucket ou à un objet spécifique est-elle donnée via une valeur d'usage ? La suppression de l'accès accordé à une valeur d'usage peut entraîner la perte d'accès aux ressources pour les comptes principaux précédemment activés.

   Par exemple, supposons que jane@example.com dispose du rôle de base Propriétaire (roles/owner) pour un projet nommé my-example-project et que la stratégie IAM du projet accorde le rôle de créateur de l'espace de stockage (roles/storage.objectCreator) à la valeur d'usage projectOwner:my-example-project. Cela signifie que jane@example.com dispose des autorisations associées au rôle Créateur des objets de l'espace de stockage pour les buckets dans my-example-project. Si cette autorisation est supprimée, jane@example.com perd les autorisations associées au rôle "Storage Object Creator".

   Dans un tel scénario, vous pouvez récupérer l'accès au bucket ou à l'objet en vous accordant les autorisations au niveau du bucket ou de l'objet nécessaires pour effectuer les actions dont vous avez besoin.

5. Existe-t-il une stratégie de refus IAM qui vous empêche d'utiliser certaines autorisations ? Vous pouvez contacter l'administrateur de votre organisation pour savoir si une stratégie de refus IAM a été mise en place.

409 Conflict

Problème : J'ai essayé de créer un bucket, mais l'erreur suivante s'est affichée :

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

Solution : Le nom de bucket que vous avez essayé d'utiliser (par exemple, gs://cats ou gs://dogs) est déjà attribué. Cloud Storage utilise un espace de noms global. Vous ne pouvez donc pas nommer un bucket avec le même nom qu'un bucket existant. Choisissez un nom qui n'est pas déjà utilisé.

412 Custom constraints violated

Problème : Mes requêtes sont rejetées avec une erreur 412 orgpolicy.

Problème : Mes requêtes sont rejetées avec une erreur 412 Multiple constraints were violated.

Solution : Vérifiez auprès de votre équipe d'administrateurs de la sécurité si le bucket auquel vous envoyez des requêtes est affecté par une règle d'administration utilisant une contrainte personnalisée. Votre bucket peut également être affecté par différentes règles d'administration qui entrent en conflit. Par exemple, une règle spécifie que les buckets doivent utiliser la classe de stockage standard, et une autre règle que les buckets doivent avoir la classe de stockage Coldline.

429 : Too Many Requests

Problème : Mes requêtes sont rejetées avec une erreur 429 Too Many Requests.

Solution : Vous atteignez la limite du nombre de requêtes autorisées par Cloud Storage pour une ressource donnée. Consultez la section sur les quotas Cloud Storage pour plus d'informations sur les limites dans Cloud Storage.

• Si votre charge de travail comprend des milliers de requêtes par seconde envoyées à un bucket, consultez les consignes liées au taux de requêtes et à la distribution des accès pour en savoir plus sur les bonnes pratiques, y compris l'augmentation progressive de votre charge de travail, et pour éviter les noms de fichiers séquentiels.

• Si votre charge de travail utilise potentiellement 50 Gbit/s ou plus de sortie réseau vers des emplacements spécifiques, vérifiez votre utilisation de la bande passante pour vous assurer que vous ne dépassez pas un quota de bande passante.

Diagnostiquer les erreurs liées à Google Cloud Console

Problème : Lorsque j'utilise la console Google Cloud pour effectuer une opération, un message d'erreur générique s'affiche. Par exemple, un message d'erreur s'affiche lorsque j'essaie de supprimer un bucket, mais je ne vois pas les raisons de l'échec de l'opération.

Solution : Utilisez les notifications de Google Cloud Console pour afficher des informations détaillées sur l'opération ayant échoué :

1. Cliquez sur le bouton Notifications (notifications) dans l'en-tête de la console Google Cloud.

   Un menu déroulant affiche les dernières opérations effectuées par la console Google Cloud.

2. Cliquez sur l'élément dont vous souhaitez en savoir plus.

   Une page s'ouvre et affiche des informations détaillées sur l'opération.

3. Cliquez sur chaque ligne pour développer les informations détaillées sur l'erreur.

Problème: Lorsque vous utilisez la console Google Cloud, aucune colonne particulière ne s'affiche.

Solution: Pour afficher une colonne particulière affichée dans la console Google Cloud, cliquez sur l'icône Options d'affichage des colonnes (view_column), puis sélectionnez la colonne. que vous souhaitez afficher.

Dossiers gérés et simulés

Problème : J'ai supprimé certains objets de mon bucket, et le dossier qui les contient n'apparaît plus dans la console Google Cloud.

Solution : Bien que la console Google Cloud affiche le contenu de votre bucket comme s'il existait une structure de répertoires, les dossiers n'existent pas fondamentalement dans Cloud Storage. Par conséquent, lorsque vous supprimez tous les objets ayant un préfixe commun d'un bucket, l'icône de dossier représentant ce groupe d'objets n'apparaît plus dans la console Google Cloud.

Problème : Je ne parviens pas à créer de dossiers gérés.

Solution : pour créer des dossiers gérés, assurez-vous que les conditions suivantes sont remplies :

• Vous disposez d'un rôle IAM contenant l'autorisation storage.managedfolders.create, par exemple le rôle Administrateur des objets de l'espace de stockage (roles/storage.objectAdmin). Pour obtenir des instructions sur l'attribution des rôles, consultez la page Utiliser les autorisations IAM.

• L'accès uniforme au niveau du bucket est activé sur le bucket dans lequel vous souhaitez créer des dossiers gérés.

• Il n'existe aucune condition IAM sur le bucket ou le projet qui utilise le type de ressource de bucket (storage.googleapis.com/Bucket) ou le type de ressource d'objet (storage.googleapis.com/Object). Si un bucket d'un projet dispose d'une condition IAM qui utilise l'un de ces types de ressources, les dossiers gérés ne peuvent être créés dans aucun des buckets de ce projet, même si la condition est supprimée ultérieurement.

Problème : Je ne parviens pas à désactiver l'accès uniforme au niveau du bucket, car mon bucket contient des dossiers gérés.

Solution : L'accès uniforme au niveau du bucket ne peut pas être désactivé s'il existe des dossiers gérés dans le bucket. Pour désactiver l'accès uniforme au niveau du bucket, vous devez d'abord supprimer tous les dossiers gérés du bucket.

Erreurs de site Web statique

Vous trouverez ci-dessous une liste des problèmes courants que vous pouvez rencontrer lors de la configuration d'un bucket pour héberger un site Web statique.

Diffusion HTTPS

Problème : Je souhaite diffuser mon contenu via HTTPS sans utiliser d'équilibreur de charge.

Solution : Vous pouvez diffuser du contenu statique via HTTPS à l'aide d'URI directs tels que https://storage.googleapis.com/my-bucket/my-object. Pour les autres options permettant de diffuser votre contenu à travers un domaine personnalisé via SSL, vous pouvez :

• utiliser un réseau de diffusion de contenu tiers avec Cloud Storage ;
• diffuser le contenu statique de votre site Web à partir de Firebase Hosting au lieu de Cloud Storage.

Validation de domaine

Problème : Je ne parviens pas à valider mon domaine.

Solution : Le processus de validation dans Search Console vous oblige à importer un fichier dans votre domaine. Toutefois, vous ne pourrez peut-être pas le faire sans disposer au préalable d'un bucket associé, que vous ne pourrez créer qu'après avoir effectué la validation du domaine.

Dans ce cas, confirmez la propriété du domaine à l'aide de la méthode de validation du fournisseur de nom de domaine. Consultez la section Validation de la propriété pour en savoir plus sur les étapes à suivre. Cette validation peut être effectuée avant la création du bucket.

Page inaccessible

Problème : Un message d'erreur Access denied s'affiche pour une page Web diffusée par mon site Web.

Solution : Vérifiez que l'objet est partagé en mode public. Si ce n'est pas le cas, consultez la page Rendre des données publiques pour en savoir sur les étapes à suivre.

Si vous avez précédemment importé et partagé un objet, mais que vous en avez ensuite importé une nouvelle version, vous devez repartager l'objet en mode public. En effet, l'autorisation publique est remplacée par la nouvelle importation.

Impossible de modifier les autorisations

Problème : Je reçois un message d'erreur lorsque j'essaie de rendre mes données publiques.

Solution : Assurez-vous de disposer de l'autorisation storage.buckets.setIamPolicy ou storage.objects.setIamPolicy. Ces autorisations sont accordées, par exemple, dans le rôle Administrateur de l'espace de stockage (roles/storage.admin). Si vous disposez de l'autorisation storage.buckets.setIamPolicy ou de l'autorisation storage.objects.setIamPolicy et que vous obtenez toujours une erreur, votre bucket peut être soumis à la protection contre l'accès public, qui n'autorise pas l'accès à allUsers ou allAuthenticatedUsers. La protection contre l'accès public peut être définie directement sur le bucket, ou appliquée via une règle d'administration définie à un niveau supérieur.

Téléchargement du contenu

Problème : Je suis invité à télécharger le contenu de ma page au lieu de pouvoir l'afficher dans mon navigateur.

Solution : Si vous spécifiez un MainPageSuffix en tant qu'objet n'ayant pas de type de contenu Web, les visiteurs du site sont invités à télécharger le contenu au lieu de pouvoir le consulter directement sur la page. Pour résoudre ce problème, mettez à jour l'entrée de métadonnées Content-Type avec une valeur appropriée, par exemple text/html. Pour obtenir des instructions, consultez la section Modifier des métadonnées d'objets.

Latence

Vous trouverez ci-dessous des problèmes de latence courants que vous pouvez rencontrer. En outre, le tableau de bord Service Health de Google Cloud fournit des informations sur les incidents qui affectent les services Google Cloud tels que Cloud Storage.

Latence d'importation ou de téléchargement

Problème : J'ai constaté une latence accrue lors de l'importation ou du téléchargement.

Solution : Tenez compte des causes courantes de latence d'importation et de téléchargement suivantes :

• Contraintes de processeur ou de mémoire : le système d'exploitation de l'environnement concerné doit disposer d'outils permettant de mesurer la consommation des ressources locale, telles que l'utilisation du processeur et de la mémoire.

• Contraintes d'E/S disque : l'impact sur les performances peut être dû aux E/S du disque local.

• Distance géographique : les performances peuvent être affectées par la séparation physique de votre bucket Cloud Storage et de l'environnement affecté, en particulier dans les cas intercontinentaux. Les tests effectués avec un bucket situé dans la même région que votre environnement concerné peuvent déterminer dans quelle mesure la séparation géographique contribue à votre latence.

  • Le cas échéant, le résolveur DNS de l'environnement concerné doit utiliser le protocole EDNS(0) afin que les requêtes de l'environnement soient acheminées via un serveur Google Front End approprié.

Latence de la CLI ou des bibliothèques clientes

Problème : J'ai constaté une latence accrue lorsque j'accède à Cloud Storage avec la Google Cloud CLI ou l'une des bibliothèques clientes.

Solution : La gcloud CLI et les bibliothèques clientes relancent automatiquement les requêtes lorsqu'il est utile de le faire. Ce comportement peut augmenter de manière importante la latence telle qu'elle est perçue par l'utilisateur final. Utilisez la métrique Cloud Monitoring storage.googleapis.com/api/request_count pour vérifier si Cloud Storage diffuse de manière cohérente un code de réponse récupérable, tel que 429 ou 5xx.

Serveurs proxy

Problème : Je me connecte via un serveur proxy. Que dois-je faire ?

Solution : Pour vous connecter à Cloud Storage via un serveur proxy, vous devez autoriser l'accès aux domaines suivants :

• accounts.google.com pour créer des jetons d'authentification OAuth2
• oauth2.googleapis.com pour les échanges de jetons OAuth2
• *.googleapis.com pour les requêtes de stockage

Si votre serveur proxy ou votre stratégie de sécurité ne prennent pas en charge l'ajout à la liste d'autorisation par domaine, mais uniquement par bloc réseau IP, nous vous recommandons vivement de configurer votre serveur proxy pour toutes les plages d'adresses IP Google. Vous pouvez trouver les plages d'adresses en interrogeant les données WHOIS sur le site ARIN. Il est recommandé de vérifier régulièrement les paramètres de votre serveur proxy afin de vous assurer qu'ils correspondent aux adresses IP de Google.

Nous vous déconseillons de configurer votre serveur proxy avec des adresses IP individuelles obtenues à partir de recherches ponctuelles sur oauth2.googleapis.com et storage.googleapis.com. Les services Google étant exposés via des noms DNS mappés sur un grand nombre d'adresses IP susceptibles de changer au fil du temps, la configuration de votre serveur proxy sur la base d'une recherche ponctuelle peut entraîner des échecs de connexion à Cloud Storage.

Si vos requêtes sont acheminées via un serveur proxy, vous devrez peut-être contacter votre administrateur réseau pour vous assurer que l'en-tête Authorization contenant vos identifiants n'est pas supprimé par le serveur. Si l'en-tête Authorization n'est pas présent, vos requêtes sont rejetées, et vous recevez une erreur MissingSecurityHeader.

Erreurs Storage Insights

Problème : Ma configuration de rapport d'inventaire génère plusieurs rapports d'inventaire quotidiennement.

Solution : Si vous avez plus de 1 000 000 d'objets dans votre bucket, plusieurs rapports d'inventaire peuvent être générés en tant que segments. Une configuration de rapport d'inventaire génère un rapport d'inventaire pour chaque 1 000 000 d'objets dans le bucket. Par exemple, si vous disposez d'un bucket avec 3 500 000 objets, la configuration de rapport d'inventaire sur le bucket génère quatre segments de rapport d'inventaire selon la fréquence spécifiée, ainsi qu'un fichier manifeste qui contient le nombre de segments de rapport d'inventaire générés et leurs noms de fichier.

Problème : Les rapports d'inventaire n'apparaissent pas dans le bucket de destination.

Solution : Si vous avez créé une configuration de rapport d'inventaire et constatez que les rapports d'inventaire ne sont pas générés dans le bucket de destination, vérifiez les points suivants :

• Assurez-vous que la date de début spécifiée dans la configuration de rapport d'inventaire correspond à vos attentes quant au moment où les rapports d'inventaire doivent être générés. Pour savoir comment spécifier une date de début, consultez la section Créer une configuration de rapport d'inventaire.

• Consultez l'historique de rapports d'inventaire pour rechercher des défaillances et leur cause. Procédez comme suit pour consulter votre historique de rapports d'inventaire :

  1. Dans la console Google Cloud, accédez à la page Buckets Cloud Storage.
     

     Accéder à la page "Buckets"

  2. Dans la liste des buckets, cliquez sur le nom du bucket source contenant la configuration de rapport d'inventaire.

  3. Sur la page Informations sur le bucket, cliquez sur l'onglet Rapports sur l'inventaire.

  4. Dans la liste des configurations de rapport d'inventaire, cliquez sur l'UUID de la configuration de rapport d'inventaire qui a généré les rapports que vous souhaitez vérifier.

  5. Recherchez les échecs dans la section Historique de rapports d'inventaire. Vous pouvez placer le pointeur sur Aide (help) pour obtenir des détails sur les raisons de l'échec.

• Assurez-vous que l'agent de service au niveau du projet dispose des rôles IAM requis pour lire et écrire des rapports d'inventaire. Pour obtenir des instructions, consultez la section Attribuer les rôles requis à l'agent de service.

Problème : Je constate des délais aléatoires concernant la génération des rapports d'inventaire.

Solution : L'intervalle de temps qui sépare chaque génération de rapport d'inventaire peut varier. Vous pouvez constater un délai allant jusqu'à un jour.

Étape suivante

• Trouvez des réponses à d'autres questions sur Cloud Storage sur la page "Questions fréquentes".
• Découvrez les options d'assistance.
• Découvrez comment Error Reporting peut vous aider à identifier et à comprendre les erreurs Cloud Storage.