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, aux enrichissements d'objets (preview) 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 que la requête 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.s3nsapis.fr/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, la requête 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 champs FieldMask 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 de 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. Spécifiez uniquement les champs modifiables 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 acceptés 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 liste 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 envoyés 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 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 console Cloud de Confiance , 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 Attribuer les rôles requis à l'agent de service.

Retards dans les rapports d'inventaire

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

Solution : Les délais de génération des rapports varient. Un délai de 24 heures est normal.

Les ensembles de données ne sont pas renseignés

Problème : les tables de l'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 Résoudre les erreurs liées aux ensembles 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 colonne ref 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'objets à l'aide de BigQuery.

Erreurs d'enrichissement d'objets

Cette section explique comment résoudre les problèmes courants lors de la configuration, de la génération ou de l'interrogation d'enrichissements d'objets.

Enrichissements manquants pour les objets

Problème : les enrichissements d'objets n'apparaissent pas sur les objets après leur configuration.

Solution : vérifiez les points suivants :

  • Autorisations de l'agent de service : assurez-vous d'accorder à l'agent de service d'enrichissement d'objets le rôle roles/storage.annotationGeneratorService sur le bucket (ou projet) cible et le rôle roles/storage.bucketViewer sur le projet. Pour obtenir des instructions, consultez Accorder des autorisations à l'agent de service.
  • Configuration du filtre et du champ d'application : assurez-vous que votre ressource FeatureConfig inclut explicitement le nom du bucket cible. Cloud Storage n'inclut pas automatiquement les buckets créés après la création de la ressource FeatureConfig. De plus, si vous supprimez et recréez ou déplacez un bucket, vous devez mettre à jour la ressource FeatureConfig pour l'inclure à nouveau.
  • Prérequis du modèle et métadonnées Content-Type : vérifiez que les objets respectent les limites de type de contenu et de taille pour vos modèles activés. Cloud Storage utilise le champ de métadonnées Content-Type de l'objet pour déterminer l'éligibilité (BMP, GIF, ICO, JPEG, PNG, TIFF ou WEBP pour les images ; application/pdf pour la classification des PDF). Si les métadonnées Content-Type sont manquantes ou incorrectes, Cloud Storage ne traite pas l'objet tant que vous n'avez pas mis à jour ses métadonnées. De plus, le service d'enrichissement d'objets ignore les objets de plus de 20 Mio. Pour en savoir plus, consultez Modèles et schémas compatibles.
  • Latence de traitement : prévoyez un délai suffisant pour le traitement asynchrone. Le service d'enrichissement d'objets traite les objets de manière asynchrone. Les enrichissements des objets récemment importés apparaissent généralement en quelques heures. En revanche, le remplissage des objets existants dans les grands buckets peut prendre des heures ou des jours.

Les enrichissements d'objets ne sont pas visibles dans BigQuery

Problème : Les enrichissements d'objets apparaissent dans l'API, mais pas dans BigQuery.

Solution : vérifiez les points suivants :

  • Configuration des ensembles de données Storage Insights : vérifiez que vous avez configuré les ensembles de données Storage Insights pour le bucket.
  • Planification quotidienne des rapports : attendez la mise à jour quotidienne de l'ensemble de données. Les ensembles de données Storage Insights sont mis à jour toutes les 24 heures. Par conséquent, les enrichissements nouvellement générés peuvent mettre jusqu'à 24 heures pour apparaître dans la vue object_contexts_catalog_view de BigQuery.
  • Autorisations IAM : assurez-vous de disposer des autorisations nécessaires pour exécuter des jobs et lire des données dans BigQuery (par exemple, roles/bigquery.jobUser et roles/bigquery.dataViewer). Pour obtenir des conseils sur les requêtes, consultez Analyser les enrichissements d'objets dans BigQuery.

Autorisation refusée lors de la récupération des données d'enrichissement d'objets étendues

Problème : une erreur d'autorisation se produit lors de la récupération des données d'enrichissement d'objets étendus.

Solution : vous devez disposer de l'autorisation storage.objects.viewFullContext sur l'objet ou le bucket pour récupérer des données étendues, telles que les coordonnées du cadre de délimitation ou les scores de confiance de la catégorie. Les rôles tels que Utilisateur d'objets Storage (roles/storage.objectUser) et Administrateur Storage (roles/storage.admin) incluent cette autorisation. Pour en savoir plus, consultez Gérer les enrichissements d'objets.

Autorisation refusée lors de la gestion des configurations de fonctionnalités

Problème : Une erreur d'autorisation se produit lors de la création, de la mise à jour ou de la suppression d'un FeatureConfig.

Solution : Vérifiez que votre compte dispose du rôle d'administrateur de l'espace de stockage (roles/storage.admin) ou d'un rôle personnalisé avec les autorisations nécessaires sur le projet cible. Ces autorisations requises incluent storage.featureConfigs.create, storage.featureConfigs.update ou storage.featureConfigs.delete. Pour connaître les autorisations spécifiques à une méthode, consultez Configurer les enrichissements d'objets et la ressource d'API featureConfigs.

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 à la ressource de job (projects/PROJECT_ID/locations/LOCATION/jobs/JOB_ID) ne dépasse pas 200 octets. Si le chemin d'accès dépasse 200 octets, raccourcissez l'ID du job. Pour en savoir plus, consultez Nom du job.

400 : La description du job dépasse la limite

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

Solution : assurez-vous que la description du job ne dépasse pas 1 024 octets. Si elle dépasse cette limite, raccourcissez le texte. Pour en savoir plus, consultez Description du job.

400 : Configurations de source de job manquantes ou non valides

Problème : La requête de création de job renvoie une réponse 400 Bad Request (INVALID_ARGUMENT) pour l'une des raisons suivantes :

  • SOURCE_NOT_SPECIFIED
  • BUCKET_LIST_EMPTY
  • TOO_MANY_BUCKETS
  • MULTI_BUCKET_NOT_SUPPORTED
  • BUCKET_NAME_REQUIRED
  • OBJECT_CONFIGURATION_REQUIRED

Solution : assurez-vous que votre job spécifie une configuration source valide (bucket_list ou project_source) et que chaque bucket définit une méthode de sélection d'objets. Pour en savoir plus, consultez Créer et gérer des jobs d'opérations par lot.

400 : Nom de bucket ou d'objet non valide

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

Solution : Assurez-vous que tous les noms de buckets et d'objets respectent les exigences de dénomination de Cloud Storage. Pour en savoir plus, consultez les consignes de dénomination des buckets et les consignes de dénomination des objets.

400 : Erreurs de configuration de la source du projet

Problème : La requête de création de job renvoie une réponse 400 Bad Request (INVALID_ARGUMENT) pour l'une des raisons suivantes :

  • PROJECT_SOURCE_PROJECT_INVALID
  • PROJECT_SOURCE_DRY_RUN_FIELDS_EXCLUSIVE
  • PROJECT_SOURCE_DRY_RUN_ID_INVALID

Solution : Vérifiez que la configuration de la source de votre projet respecte les exigences de mise en forme et d'exclusivité des champs. Si vous spécifiez un ID de job de simulation, omettez tous les autres paramètres project_source. Pour en savoir plus, consultez Créer un job à l'aide de filtres avancés.

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) pour l'une des raisons suivantes :

  • TRANSFORMATION_NOT_SPECIFIED
  • REWRITE_OBJECT_MISSING_PARAMETERS
  • PUT_OBJECT_HOLD_MISSING_PARAMETERS
  • 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 le verrouillage d'objet est activé sur le bucket et que les codes temporels utilisent le format RFC 3339 UTC. Pour en savoir plus sur les exigences de paramètres par transformation, consultez Type de job.

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

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

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

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 fichier manifeste.

Solution : vérifiez que l'URI du fichier 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 fichier manifeste. Pour en savoir plus sur les exigences de mise en forme et de schéma CSV, consultez Manifeste.

400 : Erreurs de découverte de l'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) pour l'une des raisons suivantes :

  • BUCKET_DISCOVERY_SNAPSHOT_TOO_OLD
  • TARGET_LOCATIONS_REQUIRED_FOR_SNAPSHOT_TIME
  • BUCKET_DISCOVERY_TOO_MANY_BUCKETS

Solution : Vérifiez que snapshot_time se situe dans les dernières 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 Créer un fichier 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 des buckets pour lesquels la classe automatique est activée. Ciblez un bucket sans Autoclass ou supprimez la transformation de classe de stockage. Pour en savoir plus, consultez Restrictions liées à la classe automatique.

400 : Échec des mises à jour des LCA d'objets sur les buckets avec accès uniforme au niveau du bucket

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'objets sur les buckets pour lesquels l'accès uniforme au niveau du bucket est activé. Gérez plutôt les accès à l'aide de rôles IAM au niveau du bucket ou du projet. Pour en savoir plus, consultez Accès uniforme au niveau du bucket.

Problèmes 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 pendant 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.s3ns-system.iam.gserviceaccount.com) les rôles IAM requis pour votre type de transformation. Pour en savoir plus, consultez 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 l'erreur 400 Bad Request ou 403 Forbidden en raison d'erreurs d'état ou d'autorisation de la clé Cloud KMS.

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 rôle roles/cloudkms.cryptoKeyEncrypterDecrypter. Pour en savoir plus, consultez Type de mission : réécriture d'objet.

Nombre élevé d'échecs dans error_summaries

Problème : Un job par lot se termine avec un counters.failed_object_count non nul 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'option --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 Obtenir les détails d'un job.

Échec d'un 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é remonte à plus de deux jours.

Solution : Pour éviter les actions sur des états d'objets obsolètes, les opérations de stockage par lot échouent automatiquement lors de la création de jobs. 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 fichier manifeste pour éviter la limite de deux jours.
  • Vérifiez les configurations de l'ensemble de données : assurez-vous que vos configurations de l'ensemble de données sont actives et non suspendues. Vérifiez que les instantanés de l'ensemble de données s'exécutent correctement. Pour savoir comment vérifier vos configurations, consultez Afficher la configuration d'un ensemble de données.
  • Utiliser les remplacements de la zone géographique ciblée 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 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 : Après avoir activé l'abonnement Storage Intelligence, vous devez attendre 24 heures avant d'exécuter des jobs d'opérations de stockage par lot basés sur des filtres CEL. Ce délai permet au système d'effectuer l'instantané initial des métadonnées et d'établir l'heure de l'instantané de départ.

Le job d'opérations de stockage par lot basé sur un filtre CEL échoue avec des erreurs d'autorisation ou génère 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 IAM de lecture ou d'écriture nécessaires sur les buckets et 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 de rôles équivalents pour tous les buckets et objets concernés par le job. Pour obtenir des instructions sur l'attribution des rôles, consultez 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 Afficher les journaux des opérations de stockage par lot.

Problèmes liés au conseiller Storage Intelligence

Cette section vous explique comment résoudre les problèmes courants liés à l'utilisation de l'outil de recommandation Storage Intelligence.

Erreurs d'autorisation refusée pour le conseiller Storage Intelligence

Problème : Vous recevez une erreur Permission denied lorsque vous accédez au conseiller Storage Intelligence, et les graphiques et les métriques sont vides ou affichent des erreurs d'autorisation.

Solution : Ce problème se produit si vous ne disposez pas d'un rôle IAM avec les autorisations requises pour afficher Storage Intelligence Advisor. Demandez à votre administrateur de vous accorder le rôle Administrateur de l'espace de stockage (roles/storage.admin) sur le projet, le dossier ou l'organisation que vous souhaitez afficher. Pour obtenir la liste des autorisations requises, consultez Rôles requis.

Autorisations insuffisantes pour afficher un projet concerné

Problème : Lorsque vous affichez les résultats au niveau de l'organisation ou du dossier, le panneau Projets avec des résultats détectés affiche un indicateur d'avertissement avec le message You've insufficient permission to access this project à côté d'un projet.

Solution : ce problème se produit si vous disposez des autorisations nécessaires pour afficher Storage Intelligence Advisor au niveau de l'organisation ou du dossier, mais que vous ne disposez pas des autorisations IAM requises sur ce projet spécifique. Demandez à l'administrateur du projet de vous accorder le rôle Administrateur de l'espace de stockage (roles/storage.admin) sur le projet concerné.

Le conseiller Storage Intelligence est vide ou des données sont manquantes

Problème : la page du conseiller Storage Intelligence se charge, et les graphiques, les métriques de la section En un coup d'œil (intitulée Projet en un coup d'œil, Dossier en un coup d'œil ou Organisation en un coup d'œil selon la ressource sélectionnée) ou la section Principaux résultats sont vides ou les données sont obsolètes.

Solution : ce problème peut survenir pour les raisons suivantes :

  • Latence du traitement des données : les métriques et les résultats de Storage Intelligence s'appuient sur des instantanés quotidiens et sur l'analyse de l'utilisation de l'espace de stockage. L'affichage des données dans le conseiller Storage Intelligence peut prendre de 24 à 48 heures. Ces retards se produisent généralement après la création de buckets ou lorsque vous consultez Storage Intelligence Advisor pour la première fois. Si vous vous attendez à voir des données d'activité récentes, patientez 48 heures, puis vérifiez à nouveau.
  • Aucune ressource de stockage : si le projet, le dossier ou l'organisation sélectionnés ne contiennent aucun bucket ni objet pour la période sélectionnée, le conseiller Storage Intelligence est vide. Choisissez un autre projet, dossier ou organisation contenant des ressources de stockage.
  • Filtre temporel incorrect : le filtre temporel est défini sur une période pendant laquelle aucune activité de stockage n'a eu lieu. Ajustez le filtre temporel sur une période incluant l'activité de stockage.

Les résultats n'apparaissent pas dans le conseiller Storage Intelligence

Problème : vous vous attendez à voir des résultats dans la section Principaux résultats en fonction de l'activité de stockage récente, mais la section est vide.

Solution : Ce problème se produit si Storage Intelligence Advisor ne génère aucun résultat pour la période sélectionnée. L'absence de résultats peut s'expliquer par les raisons suivantes :

  • Aucun schéma correspondant : le cycle d'analyse le plus récent n'a détecté aucun comportement de stockage correspondant à un schéma de résultat.
  • Délais de traitement des données : les résultats s'appuient sur des métriques de stockage, dont le traitement prend 24 à 48 heures. Les résultats des événements qui se sont produits au cours des dernières 24 heures s'affichent une fois le cycle de traitement suivant terminé.

Problèmes lors de l'utilisation de VPC Service Controls

Problème : Vous recevez des erreurs d'accès refusé ou d'autorisation lorsque vous essayez d'accéder au conseiller Storage Intelligence à partir d'un projet situé dans un périmètre de service VPC Service Controls.

Solution : Ce problème se produit si VPC Service Controls n'est pas configuré correctement pour autoriser la communication entre votre projet, la console Cloud de Confiance et les ressources Storage Intelligence. Pour résoudre ce problème, vérifiez les exigences suivantes :

  • Services restreints : vérifiez si le périmètre de service restreint l'API Cloud Storage (storage.googleapis.com) et l'API Storage Insights (storageinsights.googleapis.com). Pour en savoir plus, consultez Répertorier et décrire les paramètres de service.
  • Configuration du périmètre : vérifiez que le projet que vous utilisez pour afficher le conseiller Storage Intelligence se trouve dans le même périmètre de service que les projets que vous surveillez. S'ils se trouvent dans des périmètres différents, vous devez configurer des règles d'entrée et de sortie ou utiliser des liaisons de périmètre.
  • Accès depuis l'extérieur du périmètre : si vous accédez à la console Cloud de Confiance depuis un réseau situé en dehors du périmètre, vous devez créer une règle d'entrée ou un niveau d'accès incluant votre compte utilisateur et la plage d'adresses IP publiques que vous utilisez.
  • VPC partagé : si vous utilisez un VPC partagé, vérifiez que le projet se trouve dans le même périmètre de service que vos projets de service. Pour en savoir plus, consultez VPC partagé.
  • Journaux d'audit : utilisez l'analyseur de cas de non-conformité pour rechercher les cas de non-conformité à VPC Service Controls dans vos journaux d'audit. L'analyseur de cas de non-respect permet de diagnostiquer le cas de non-respect et d'en identifier les causes, comme une erreur RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Étapes suivantes