Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Résoudre les problèmes liés à Storage Intelligence

Ce document explique comment résoudre les problèmes courants liés à Storage Intelligence, aux rapports d'inventaire Storage Insights, aux ensembles de données Storage Insights, et aux opérations de stockage par lot.

Erreurs de configuration de Storage Intelligence

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

400 : Nom de bucket non valide

Problème : La requête renvoie 400 Bad Request avec le message The specified bucket is not valid.

Solution : La requête n'est pas valide. Assurez-vous qu'elle répond aux exigences suivantes :

Utilisez locations/global. Storage Intelligence n'est pas compatible avec d'autres emplacements.
Assurez-vous que les noms de buckets ou les expressions régulières dans bucket_id_regexes sont valides.

Voici un exemple de requête valide :

curl -X PATCH \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -d '{
      "edition_config": "STANDARD",
      "filter": {
        "included_cloud_storage_buckets": {
          "bucket_id_regexes": [
            "my-bucket-name",
            "prod-data-.*"
          ]
        }
      }
    }' \
    "https://storage.googleapis.com/v2/projects/PROJECT_ID/locations/global/intelligenceConfig?updateMask=edition_config,filter"

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

Problème : Lorsque vous envoyez une requête de configuration ou de mise à jour, elle renvoie 400 Bad Request avec le message Empty UPDATE_MASK in the request.

Solution : Fournissez un UPDATE_MASK non vide dans votre requête. UPDATE_MASK spécifie une liste de FieldMask champs séparés par une virgule dans la ressource IntelligenceConfig à mettre à jour (par exemple, updateMask=edition_config ou updateMask=edition_config,filter).

400 : Chemin du masque de mise à jour non valide

Problème : Lors de la mise à jour d'une configuration, la requête renvoie 400 Bad Request avec le message Invalid UPDATE_MASK paths.

Solution : Vérifiez que chaque nom de champ dans UPDATE_MASK correspond à un champ valide dans la ressource IntelligenceConfig.

400 : Le champ n'est pas modifiable

Problème : Lors de la mise à jour d'une configuration, la requête renvoie 400 Bad Request avec le message Invalid UPDATE_MASK: UPDATE_TIME field is not editable.

Solution : Supprimez les champs système non modifiables (tels que UPDATE_TIME) de UPDATE_MASK. Ne spécifiez que les champs mutables définis dans IntelligenceConfig.

400 : Valeur non valide

Problème : La requête renvoie 400 Bad Request avec le message Invalid value at storage_intelligence.edition_config.

Solution : Définissez edition_config sur une valeur acceptée : INHERIT, STANDARD ou DISABLED.

400 : Filtre non vide

Problème : La requête renvoie 400 Bad Request avec le message Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration.

Solution : Supprimez les filtres de bucket de la requête. Les filtres de bucket ne sont pas compatibles lorsque edition_config est défini sur INHERIT ou DISABLED.

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

Problème : La requête renvoie 400 Bad Request avec le message Empty location or bucket values in filter.

Solution : Assurez-vous que ni location ni bucket ne sont des chaînes vides dans votre filtre de bucket.

Problèmes courants liés à Storage Insights

Cette section explique comment résoudre les problèmes courants liés aux rapports d'inventaire et aux ensembles de données.

Plusieurs rapports d'inventaire générés quotidiennement

Problème : Une configuration de rapport d'inventaire génère plusieurs fichiers de rapport chaque jour.

Solution : Cloud Storage segmente les rapports d'inventaire pour les buckets contenant plus de 1 000 000 d'objets, en générant un segment par million d'objets. Par exemple, un bucket contenant 3 500 000 objets génère quatre segments de rapport et un fichier manifeste qui répertorie chaque segment.

Les rapports d'inventaire n'apparaissent pas dans le bucket de destination

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

Solution : Si les rapports ne sont pas fournis au bucket de destination, vérifiez les points suivants :

Assurez-vous que la date de début configurée est passée. Pour en savoir plus, consultez la section Créer une configuration de rapport d'inventaire.
Consultez votre historique de rapports d'inventaire pour rechercher des échecs et leur cause. Procédez comme suit pour consulter votre historique de rapports d'inventaire :
1. Dans la Google Cloud console, accédez à la page Buckets de 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 d'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 des échecs dans la section Historique de rapports d'inventaire. Vous pouvez placer le pointeur sur Aide () 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 en savoir plus, consultez la section Attribuer les rôles requis à l'agent de service.

Retards dans les rapports d'inventaire

Problème : La génération de rapports d'inventaire est retardée.

Solution : Les délais de génération de rapports varient. Les retards allant jusqu'à 24 heures sont normaux.

Les ensembles de données ne sont pas remplis

Problème : Les tables d'ensemble de données Storage Insights restent vides.

Solution : Dans votre ensemble de données BigQuery associé, recherchez les codes d'erreur dans error_attributes_view. Pour en savoir plus, consultez la section Résoudre les erreurs d'ensemble de données.

Valeurs nulles dans la colonne "ref" lors de l'interrogation d'ensembles de données

Problème : Lorsque vous interrogez des ensembles de données Storage Insights dans BigQuery, la ref colonne renvoie null.

Solution : Pour les objets se terminant par /, la colonne ref des ensembles de données est nulle.

Si la colonne ref renvoie des valeurs nulles lorsque vous interrogez des ensembles de données Storage Insights dans BigQuery, vérifiez que vous avez accordé les autorisations et les rôles de connexion requis, y compris l'accès aux ressources Cloud Storage, comme décrit dans Analyser les données et les métadonnées d'objet à l'aide de BigQuery.

Erreurs de validation des jobs d'opérations de stockage par lot

Cette section décrit les erreurs de validation qui se produisent lors de l'envoi d'une requête de job d'opérations par lot à storagebatchoperations.googleapis.com.

400 : ID de job ou nom de ressource non valide

Problème : La requête de création de job renvoie une réponse 400 Bad Request (INVALID_ARGUMENT) avec le motif JOB_ID_INVALID ou RESOURCE_NAME_TOO_LONG.

Solution : Vérifiez que l'ID de job est composé de 1 à 63 caractères alphanumériques minuscules ou de traits d'union ([a-z0-9]([-a-z0-9]*[a-z0-9])?) et que le chemin d'accès complet de la ressource ne dépasse pas 1 024 octets. Pour en savoir plus, consultez la section Nom du job.

400 : Paramètres de transformation manquants ou en conflit

Problème : La requête de création de job renvoie une réponse 400 Bad Request (INVALID_ARGUMENT) avec le motif TRANSFORMATION_NOT_SPECIFIED, REWRITE_OBJECT_MISSING_PARAMETERS, PUT_OBJECT_HOLD_MISSING_PARAMETERS, ou PUT_METADATA_MISSING_PARAMETERS.

Solution : Spécifiez exactement un type de transformation avec tous les paramètres requis. Si vous configurez la conservation des objets, vérifiez que Verrouillage d'objet est activé sur le bucket et que les codes temporels utilisent le format UTC RFC 3339. Pour en savoir plus sur les exigences des paramètres par transformation, consultez la section Type de job.

400 : Préfixes d'objet qui se chevauchent ou en double

Problème : La requête de création de job renvoie une 400 Bad Request (INVALID_ARGUMENT) réponse avec le motif OBJECT_PREFIX_OVERLAP ou DUPLICATE_OBJECT_PREFIX.

Solution : Supprimez les préfixes en double et assurez-vous qu'aucun préfixe dans included_object_prefixes n'est un préfixe d'une autre entrée de la liste. Pour en savoir plus, consultez la section Préfixes d'objet.

400 : Problèmes de mise en forme et d'accès au fichier manifeste

Problème : La requête de création de job renvoie une réponse 400 Bad Request (INVALID_ARGUMENT) avec le motif MANIFEST_LOCATION_REQUIRED ou MANIFEST_LOCATION_INVALID, ou le job ne peut pas lire le manifeste.

Solution : Vérifiez que l'URI du manifeste est un chemin d'accès CSV valide (gs://<bucket_name>/<path>/<object_name>.csv) et que l' agent de service des opérations de stockage par lot dispose du rôle roles/storage.objectViewer sur le bucket du manifeste. Pour en savoir plus sur la mise en forme CSV et les exigences de schéma, consultez la section Manifeste.

400 : Erreurs de découverte d'ensemble de données Storage Insights

Problème : L'utilisation d'un ensemble de données Storage Insights pour la découverte d'objets renvoie une réponse 400 Bad Request (INVALID_ARGUMENT ou FAILED_PRECONDITION) avec le motif BUCKET_DISCOVERY_SNAPSHOT_TOO_OLD, TARGET_LOCATIONS_REQUIRED_FOR_SNAPSHOT_TIME ou BUCKET_DISCOVERY_TOO_MANY_BUCKETS.

Solution : Vérifiez que snapshot_time date de moins de 48 heures, spécifiez target_locations pour les buckets et assurez-vous que la requête de découverte ne correspond pas à plus de 1 000 buckets. Pour en savoir plus, consultez la section Créer un manifeste à l'aide d'ensembles de données Storage Insights.

400 : Échec de la transformation de la classe de stockage sur les buckets pour lesquels la classe automatique est activée

Problème : La requête de création de job renvoie une réponse 400 Bad Request (FAILED_PRECONDITION) avec le motif AUTOCLASS_STORAGE_CLASS_TRANSFORMATION_UNSUPPORTED.

Solution : Vous ne pouvez pas exécuter de transformations de classe de stockage sur les buckets pour lesquels la classe automatique est activée. Ciblez un bucket sans classe automatique ou supprimez la transformation de classe de stockage. Pour en savoir plus, consultez la section Restrictions liées à la classe automatique.

400 : Échec des mises à jour de la LCA d'objet sur les buckets pour lesquels l'accès uniforme au niveau du bucket est activé

Problème : La requête de création de job renvoie une réponse 400 Bad Request (FAILED_PRECONDITION) avec le motif UBLA_OBJECT_ACL_UPDATE_UNSUPPORTED.

Solution : Vous ne pouvez pas mettre à jour les LCA d'objet sur les buckets pour lesquels l' accès uniforme au niveau du bucket est activé. Gérez plutôt l'accès à l'aide de rôles IAM au niveau du bucket ou du projet. Pour en savoir plus, consultez la section Accès uniforme au niveau du bucket.

Problèmes d'exécution et d'exécution des opérations de stockage par lot

Cette section décrit les problèmes qui se produisent lors de l'exécution asynchrone d'un job d'opérations par lot.

403 : Erreurs d'autorisation lors de l'exécution

Problème : Un job par lot échoue lors de l'exécution avec 403 Forbidden (PERMISSION_DENIED).

Solution : Accordez à l'agent de service des opérations de stockage par lot (service-PROJECT_NUMBER@gcp-sa-storagebatchoperations.iam.gserviceaccount.com) les rôles IAM requis pour votre type de transformation. Pour en savoir plus, consultez la section Accorder des autorisations à l'agent de service.

Erreurs de chiffrement CMEK lors de la réécriture d'objets

Problème : Les réécritures d'objets échouent avec 400 Bad Request ou 403 Forbidden en raison de l'état de la clé Cloud KMS ou d'erreurs d'autorisation.

Solution : Vérifiez que la clé Cloud KMS est Enabled et qu'elle se trouve dans la même région que le bucket cible, et que l'agent de service dispose du roles/cloudkms.cryptoKeyEncrypterDecrypter rôle. Pour en savoir plus, consultez la section Type de mission : Réécrire un objet.

Nombre élevé d'échecs dans error_summaries

Problème : Un job par lot se termine avec un counters.failed_object_count différent de zéro et des codes d'erreur dans error_summaries (tels que 404 NOT_FOUND, 412 FAILED_PRECONDITION, ou 403 PERMISSION_DENIED).

Solution : Exécutez gcloud storage batch-operations jobs describe avec l' --location (par exemple, gcloud storage batch-operations jobs describe JOB_ID --location=LOCATION) pour afficher la répartition agrégée des erreurs, puis consultez Cloud Logging pour obtenir les journaux d'erreurs par objet. Pour en savoir plus, consultez la section Obtenir les détails du job.

Échec du job d'opérations de stockage par lot en raison d'un instantané datant de plus de deux jours

Problème : Lorsque vous créez un job d'opérations de stockage par lot basé sur un filtre CEL, la création du job échoue. Le message d'erreur indique que l'heure de l'instantané date de plus de deux jours.

Solution : Pour éviter les actions sur les états d'objet obsolètes, les opérations de stockage par lot échouent automatiquement lors de la création du job. Cet échec se produit si l'instantané sélectionné date de plus de deux jours. Sélectionnez l'une des méthodes suivantes pour résoudre ce problème :

Utiliser un fichier manifeste : interrogez manuellement votre ensemble de données dans BigQuery. Exportez les résultats dans un fichier manifeste CSV, puis importez-le dans un bucket Cloud Storage. Vous pouvez ensuite créer le job d'opérations par lot à l'aide de la méthode du manifeste pour éviter la limite de deux jours.
Vérifier les configurations d'ensemble de données : vérifiez que vos configurations d'ensemble de données sont actives et non mises en pause. Assurez-vous que les instantanés d'ensemble de données s'exécutent correctement. Pour savoir comment vérifier vos configurations, consultez la section Afficher une configuration d'ensemble de données.
Utiliser les remplacements de l'emplacement cible et de l'heure de l'instantané : spécifiez l'option --target-snapshot-time pour contourner l'échec d'obsolescence de deux jours en sélectionnant explicitement un instantané au format RFC 3339. Spécifiez l'option --target-locations pour limiter l'opération aux emplacements où l'instantané existe. Vous pouvez utiliser ces remplacements pour résoudre les retards de synchronisation qui empêchent la mise à jour de l'instantané global automatisé. Par conséquent, vous pouvez cibler manuellement un instantané régional plus récent. Pour connaître la syntaxe de la commande, consultez la section Créer un job à l'aide de filtres avancés.

Échec du job d'opérations de stockage par lot basé sur un filtre CEL sur les projets nouvellement abonnés

Problème : L'exécution d'un job d'opérations de stockage par lot basé sur un filtre CEL sur un projet nouvellement abonné échoue, car le système ne trouve pas d'instantané valide.

Solution : Une fois l'abonnement Storage Intelligence activé, vous devez attendre 24 heures avant d'exécuter des jobs d'opérations de stockage par lot basés sur un filtre CEL. Ce délai permet au système d'effectuer l'instantané initial des métadonnées et d'établir l'heure de début de l'instantané.

Échec du job d'opérations de stockage par lot basé sur un filtre CEL avec des erreurs d'autorisation ou des erreurs d'exécution

Problème : Un job d'opérations de stockage par lot basé sur un filtre CEL échoue lors de l'exécution ou renvoie des erreurs d'autorisation d'exécution.

Solution : Les opérations de stockage par lot utilisent vos identifiants utilisateur pour traiter les objets. Le job échoue si vous ne disposez pas des autorisations de lecteur ou d'écriture IAM nécessaires sur les buckets et les objets ciblés. Ce problème se produit lorsque vos filtres CEL sélectionnent des ressources auxquelles vous n'avez pas accès. Vérifiez que votre compte dispose des rôles Administrateur de l'espace de stockage (roles/storage.admin), Administrateur des objets de l'espace de stockage (roles/storage.objectAdmin) ou des rôles équivalents pour tous les buckets et objets inclus dans le champ d'application du job. Pour obtenir des instructions sur l'attribution des rôles, consultez la section Utiliser des autorisations IAM.

Surveillance et analyse des journaux

Pour en savoir plus sur l'inspection des échecs d'exécution par objet et des charges utiles d'erreur dans Cloud Logging, consultez la section Afficher les journaux des opérations de stockage par lot logs.

Résoudre les problèmes liés à Storage Intelligence Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.