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 HealthGoogle 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 liées aux requêtes et réponses sont gérées par l'outil. Cependant, il peut être 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 :

Console

L'affichage des informations des requêtes et des réponses dépend du navigateur que vous utilisez pour accéder à la console Google Cloud . Pour le navigateur Google Chrome :

  1. Cliquez sur le bouton Menu principal de Chrome ().

  2. Sélectionnez Plus d'outils.

  3. Cliquer sur Outils de développement.

  4. Dans le volet qui s'affiche, cliquez sur l'onglet Réseau.

Ligne de commande

Utilisez des flags de débogage globaux dans votre requête. Exemple :

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

Bibliothèques clientes

C++

  • Définissez la variable d'environnement CLOUD_STORAGE_ENABLE_TRACING=http pour obtenir le trafic HTTP complet.

  • Définissez la variable d'environnement CLOUD_STORAGE_ENABLE_CLOG=yes pour obtenir la journalisation de chaque appel de procédure à distance (RPC).

C#

Ajoutez un logger via ApplicationContext.RegisterLogger et définissez les options de journalisation sur le gestionnaire de messages HttpClient. Pour en savoir plus, consultez la documentation de référence sur la bibliothèque cliente C#.

Go

Définissez la variable d'environnement GODEBUG=http2debug=1 : Pour en savoir plus, consultez Package Go net/http.

Si vous souhaitez également consigner le corps de la requête, utilisez un client HTTP personnalisé.

Java

  1. Créez un fichier nommé "logging.properties" avec le contenu suivant :

    # 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. Utiliser logging.properties avec Maven

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

Pour en savoir plus, consultez Transport HTTP connectable.

Node.js

Définissez la variable d'environnement NODE_DEBUG=https avant d'appeler le script Node.

PHP

Fournissez votre propre gestionnaire HTTP au client à l'aide de httpHandler, puis configurez un middleware pour consigner la requête et la réponse.

Python

Utilisez le module de journalisation. Exemple :

import logging
import http.client

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

Ruby

En haut de votre fichier .rb file, après require "google/cloud/storage", ajoutez ceci :

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 une approche courante dans un objectif de 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 :

Ligne de commande

Utilisez le flag --additional-headers, disponible pour la plupart des commandes. Exemple :

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

Où HEADER_NAME et HEADER_VALUE définissent l'en-tête que vous ajoutez à la requête.

Bibliothèques clientes

C++

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

C#

L'exemple suivant ajoute un en-tête personnalisé à chaque requête effectuée par la bibliothèque 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

Vous pouvez ajouter des en-têtes personnalisés à n'importe quel appel d'API effectué par le package Storage en utilisant callctx.SetHeaders sur le contexte transmis à la méthode.

package main

import (
  "context"

  "cloud.google.com/go/storage"
  "github.com/googleapis/gax-go/v2/callctx"
)

func main() {
  ctx := context.Background()

  client, err := storage.NewClient(ctx)
  if err != nil {
    // Handle error.
  }
  ctx = callctx.SetHeaders(ctx, "X-Custom-Header", "value")

  // Use client as usual with the context and the additional headers will be sent.
  _, err = client.Bucket("my-bucket").Attrs(ctx)
  if err != nil {
    // Handle error.
  }
}

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

Tous les appels de méthode qui déclenchent des requêtes HTTP acceptent un argument $restOptions facultatif comme dernier argument. Vous pouvez fournir des en-têtes personnalisés pour chaque requête ou pour chaque client.

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' }

Accéder aux buckets avec une configuration CORS

Si vous avez défini une configuration CORS sur votre bucket et que vous constatez 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'envoi d'une requête CORS, vérifiez que vous n'envoyez pas de requête au point de terminaison storage.cloud.google.com, lequel n'autorise pas les requêtes CORS. Pour plus d'informations sur les points de terminaison compatibles avec CORS, consultez 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 () 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 qui affiche l'activité 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 En-têtes pour voir les en-têtes de réponse ou sur l'onglet 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 préliminaire ayant échoué précédemment. Si vous videz le cache de votre navigateur, cela devrait également vider le cache des requêtes préliminaires. Dans le cas contraire, diminuez la valeur MaxAgeSec dans votre configuration CORS (valeur par défaut : 3600 (60 minutes)), attendez pendant une durée égale à l'ancienne valeur (MaxAgeSec), puis renouvelez la requête. Cela entraîne l'exécution d'une nouvelle requête préliminaire, 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 requêtes préliminaires 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 associés à ces 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 non à 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 de la configuration CORS du bucket. Pour les requêtes préliminaires, 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 préliminaires, vérifiez qu'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 préliminaire aboutisse et que les en-têtes CORS soient inclus dans la réponse.

Codes d'erreur

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

301 : Déplacé définitivement

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 :

  1. Dans la console Google Cloud , accédez à la page Buckets de 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 : Requête incorrecte

Problème : Lors d'une importation avec reprise, cette erreur et le message Failed to parse Content-Range header. m'ont été renvoyés.

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.

400 : Erreurs spécifiques à Storage Intelligence

Les sections suivantes décrivent les erreurs courantes que vous pouvez rencontrer lorsque vous configurez ou gérez Storage Intelligence pour une ressource.

400 : Nom de bucket non valide

Problème : Lorsque vous configurez ou gérez Storage Intelligence pour une ressource, cette erreur et le message The specific bucket is not valid. peuvent vous être renvoyés.

Solution : L'URL que vous avez utilisée dans la requête n'est pas valide. L'URL doit répondre aux exigences suivantes :

  • locations/global est le seul emplacement accepté pour Storage Intelligence. Aucun autre emplacement n'est accepté.
  • Storage Intelligence est au singulier dans l'URL, et non au pluriel.

Voici un exemple d'URL valide :

curl -X PATCH -H "Content-Type: application/json" -d
    '{"edition_config": "STANDARD" }'
    -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://storage.googleapis.com/v2/projects/my-project/locations/global/storageIntelligence?updateMask=edition_config"

400 : Argument non valide – masque de mise à jour vide

Problème : Lorsque vous configurez ou gérez Storage Intelligence pour une ressource, cette erreur et le message Empty UPDATE_MASK in the request. peuvent vous être renvoyés.

Solution : UPDATE_MASK est la liste des noms de champs (séparés par une virgule) mis à jour par la requête. Les noms de champs utilisent le format FieldMask et font partie de la ressource intelligenceConfig. Pour mettre à jour la configuration Storage Intelligence d'une ressource, utilisez un UPDATE_MASK valide dans la requête. Vous ne pouvez pas utiliser de valeur vide.

400 : Chemin du masque de mise à jour non valide

Problème : Lorsque vous configurez ou gérez Storage Intelligence pour une ressource, cette erreur et le message Invalid UPDATE_MASK paths. peuvent vous être renvoyés.

Solution : Si vous utilisez un nom de champ non valide pour la valeur UPDATE_MASK, un message d'erreur s'affiche. UPDATE_MASK est la liste des noms de champs (séparés par une virgule) mis à jour par cette requête. Les noms de champs utilisent le format FieldMask et font partie de la ressource IntelligenceConfig. Pour mettre à jour la configuration Storage Intelligence d'une ressource, assurez-vous que chaque nom de champ listé dans UPDATE_MASK correspond à un champ valide de la ressource IntelligenceConfig.

400 : Le champ n'est pas modifiable

Problème : Lorsque vous configurez ou gérez Storage Intelligence pour une ressource, cette erreur et le message Invalid UPDATE_MASK: UPDATE_TIME field is not editable. peuvent vous être renvoyés.

Solution : UPDATE_MASK est la liste des noms de champs (séparés par une virgule) mis à jour par la requête. Les noms de champs utilisent le format FieldMask et font partie de la ressource IntelligenceConfig. Si vous essayez de mettre à jour un champ non modifiable, un message d'erreur s'affiche. Supprimez le champ non modifiable de Update_Mask, puis réessayez.

400 : Valeur non valide

Problème : Lorsque vous configurez ou gérez Storage Intelligence pour une ressource, cette erreur et le message Invalid value at storage_intelligence.edition_config. peuvent vous être renvoyés.

Solution : Si vous essayez d'utiliser une valeur non valide pour le champ edition_config, un message d'erreur s'affiche. Les valeurs autorisées sont INHERIT, STANDARD et DISABLED. Vérifiez la valeur, puis réessayez.

400 : Filtre non vide

Problème : Lorsque vous mettez à jour la configuration Storage Intelligence pour une ressource, cette erreur et le message Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration. peuvent vous être renvoyés.

Solution : Lorsque vous mettez à jour la edition_config Storage Intelligence vers INHERIT ou DISABLED, vous ne pouvez pas utiliser de filtres de bucket dans la requête. Supprimez les filtres de la requête, puis réessayez.

400 : Valeurs d'emplacement ou de bucket vides dans le filtre

Problème : Lorsque vous mettez à jour la configuration Storage Intelligence pour une ressource, cette erreur et le message Empty location or bucket values in filter. peuvent vous être renvoyés.

Solution : Lorsque vous mettez à jour la configuration Storage Intelligence et que vous utilisez un filtre de bucket dans la requête, une erreur se produit si la valeur de location ou bucket est une chaîne vide. Indiquez une valeur valide pour location ou bucket, puis réessayez.

401 : Non autorisé

Problème : Les requêtes adressées à un bucket public directement ou via Cloud CDN échouent avec une erreur HTTP 401: Unauthorized et une réponse Authentication Required.

Solution : Vérifiez que ni votre client ni un proxy intermédiaire n'ajoutent d'en-têtes Authorization aux requêtes adressées à 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 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 : Interdit

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 et un message semblable à celui-ci me sont renvoyés : example@email.com does not have storage.objects.get access to the Google Cloud Storage object.

Solution : Il vous manque une autorisation IAM sur le bucket ou l'objet, laquelle est 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 de l'accès, 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 un 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 attribué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 d'objets Storage (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 d'objets Storage pour les buckets de my-example-project. Si cette autorisation est supprimée, jane@example.com perd les autorisations associées au rôle "Créateur d'objets Storage".

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

  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.

403 : Autorisation refusée

Problème : L'erreur "Autorisation refusée" vous est renvoyée lorsque vous configurez ou gérez la configuration Storage Intelligence pour une ressource.

Solution : Si vous recevez une erreur de type "Autorisation refusée" avec un message semblable à permission storage.intelligenceConfigs.update lorsque vous configurez et gérez Storage Intelligence pour une ressource, consultez la section concernant les autorisations associées à l'opération que vous souhaitez effectuer. Pour résoudre ce problème, accordez les autorisations appropriées. Vous pouvez accorder des autorisations de plusieurs façons :

  • Accordez les autorisations IAM requises sur la même ressource de la hiérarchie des ressourcesGoogle Cloud que celle pour laquelle vous activez Storage Intelligence.
  • Assurez-vous qu'une ressource située plus haut dans la hiérarchie des ressources Google Cloud transmet les autorisations à la ressource enfant.

409 : Conflit

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 pas désigner votre bucket par le nom d'un bucket existant. Choisissez un nom qui n'est pas déjà utilisé.

412 : Non-respect des contraintes personnalisées

Problème : Mes requêtes sont rejetées et une erreur 412 orgpolicy m'est renvoyée.

Problème : Mes requêtes sont rejetées et une erreur 412 Multiple constraints were violated m'est renvoyée.

Solution : Vérifiez auprès de votre équipe d'administrateurs de la sécurité si le bucket auquel vous envoyez des requêtes est soumis à une règle d'administration utilisant une contrainte personnalisée. Votre bucket peut également être soumis à 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, tandis qu'une autre règle stipule que les buckets doivent être définis sur la classe de stockage Coldline.

429 : Trop de requêtes

Problème : Mes requêtes sont rejetées et une erreur 429 Too Many Requests m'est renvoyée.

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

  • Si votre charge de travail implique l'envoi de milliers de requêtes par seconde à 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 le fait d'éviter les noms de fichiers séquentiels.

  • Si votre charge de travail est susceptible d'utiliser 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 de la console Google Cloud

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 détails de l'échec de l'opération.

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

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

    Un menu déroulant permet d'afficher les dernières opérations effectuées par la consoleGoogle Cloud .

  2. Cliquez sur l'élément au sujet duquel 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 concernant l'erreur.

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

Solution : Pour afficher une colonne particulière dans la console Google Cloud , cliquez sur l'icône Options d'affichage des colonnes (), 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 contenait 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 Storage (roles/storage.objectAdmin). Pour obtenir des instructions sur l'attribution des rôles, consultez Utiliser des 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 "bucket" (storage.googleapis.com/Bucket) ou le type de ressource "objet" (storage.googleapis.com/Object). Si un bucket d'un projet est soumis à 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 lorsque vous configurez 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 en utilisant un domaine personnalisé via SSL, vous pouvez :

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.

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 Modifier des métadonnées d'objets.

Rendre des données publiques

Problème : J'essaie de rendre mes données publiques, mais un message d'erreur concernant une règle d'administration s'affiche.

Solution : Certaines contraintes de règles d'administration peuvent vous empêcher de rendre vos données publiques. Par exemple, la contrainte de partage restreint au domaine (constraints/iam.allowedPolicyMemberDomains) limite le partage des ressources en fonction du domaine de l'organisation. En cas d'échec des règles d'administration, contactez votre administrateur pour qu'il vous accorde les autorisations (au niveau du projet ou du bucket) permettant le partage de ressources, en modifiant la règle d'administration pour la ressource d'organisation, de dossier ou de projet. Si vous continuez à rencontrer cette erreur après le remplacement de la règle d'administration, il vous faudra peut-être attendre quelques minutes avant que la modification prenne effet.

Problème : Je reçois un message d'erreur d'autorisation 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 Storage (roles/storage.admin). Si vous disposez de l'autorisation storage.buckets.setIamPolicy ou storage.objects.setIamPolicy et que vous constatez toujours une erreur, il est possible que votre bucket soit soumis à la protection contre l'accès public, qui n'autorise pas l'accès à allUsers ni à 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.

Latence

Vous trouverez ci-dessous la description de problèmes de latence courants que vous pouvez rencontrer. Notez que le tableau de bord Service HealthGoogle 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 : Je constate une latence accrue lors des opérations d'importation ou de téléchargement.

Solution : Tenez compte de ces causes courantes pouvant entraîner une latence des importations et des téléchargements :

  • 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 locales, telles que le processeur et la mémoire.

  • Contraintes d'E/S de disque : la dégradation des performances peut être imputable 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 scénarios intercontinentaux. Des tests effectués avec un bucket situé dans la même région que l'environnement concerné permettent de déterminer dans quelle mesure la séparation géographique contribue à l'augmentation de la 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 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 façon importante la latence 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 permet pas 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 une erreur MissingSecurityHeader vous est renvoyée.

Étapes suivantes