Partage via


Inventaire des objets blob du Stockage Azure

L’inventaire des objets blob Stockage Azure fournit une liste des conteneurs, des objets blob, des versions d’objets blob et des captures instantanées de votre compte de stockage, ainsi que ses propriétés associées. Il génère un rapport de sortie au format CSV (Valeurs séparées par des virgules) ou au format Apache Parquet sur une base quotidienne ou hebdomadaire. Vous pouvez utiliser le rapport pour auditer une rétention, une conservation légale ou un état de chiffrement du contenu de votre compte de stockage, ou vous pouvez l’utiliser pour comprendre la taille totale des données, l’âge, la distribution de niveaux ou d’autres attributs de vos données. Vous pouvez également utiliser un inventaire d’objets blob pour simplifier vos flux de travail d’entreprise ou accélérer des travaux de traitement des données, en utilisant l’inventaire d’objets blob comme automatisation planifiée des API Répertorier les conteneurs et Répertorier les objets blob. Les règles d’inventaire d’objets blob vous permettent de filtrer le contenu du rapport par type d’objet blob, préfixe ou en sélectionnant les propriétés d’objet blob à inclure dans le rapport.

L’inventaire des objets blob stockage Azure est disponible pour les types de comptes de stockage suivants :

  • Usage général v2 Standard
  • Stockage d’objets blob de blocs Premium
  • Stockage d'objets blob

Fonctionnalités de l’inventaire

La liste suivante décrit les fonctionnalités et capacités disponibles dans la version actuelle de l’inventaire de blobs de Stockage Azure.

  • Rapports d’inventaire pour les blobs et les conteneurs

    Vous pouvez générer des rapports d’inventaire pour les blobs et les conteneurs. Un rapport sur les blobs peut contenir les blobs de base, la durée du contenu, les instantanés, les versions de blobs et leurs propriétés associées telles que l’heure de création ou l’heure de dernière modification. Les conteneurs vides ne sont pas répertoriés dans le rapport d’inventaire de blobs. Un rapport sur les conteneurs décrit les conteneurs et leurs propriétés associées telles que l’état de la stratégie d’immuabilité ou l’état de conservation légale.

  • Schéma personnalisé

    Vous pouvez choisir les champs à afficher dans les rapports. Faites votre choix parmi une liste de champs pris en charge. Cette liste apparaît plus loin dans cet article.

  • Format de sortie CSV et Apache Parquet

    Vous pouvez générer un rapport d’inventaire au format de sortie CSV ou Apache Parquet.

  • Fichier manifeste et événement Azure Event Grid par rapport d’inventaire

    Un fichier manifeste et un événement Azure Event Grid sont générés par rapport d’inventaire. Ils sont décrits plus loin dans cet article.

Activation des rapports d’inventaire

Activez les rapports d’inventaire des blobs en ajoutant une stratégie comprenant une ou plusieurs règles à votre compte de stockage. Pour obtenir une aide, consultez Activer les rapports d’inventaire des blobs de Stockage Azure.

Mise à niveau d’une stratégie d’inventaire

Si vous êtes un utilisateur actuel de l’inventaire des objets blob du Stockage Azure, et que vous avez configuré votre inventaire avant juin 2021, vous pouvez commencer à utiliser les nouvelles fonctionnalités en chargeant la stratégie, puis en réenregistrant la stratégie après avoir apporté des modifications. Lorsque vous rechargez la stratégie, les nouveaux champs de la stratégie sont renseignés avec les valeurs par défaut. Vous pouvez modifier ces valeurs si vous le souhaitez. En outre, les deux fonctionnalités suivantes seront disponibles.

  • Un conteneur de destination est désormais pris en charge pour chaque règle au lieu d’être simplement pris en charge pour la stratégie.

  • Un fichier manifeste et un événement Azure Event Grid sont désormais générés par règle et non plus par stratégie.

Stratégie d’inventaire

La configuration d’un rapport d’inventaire s’effectue en ajoutant une stratégie d’inventaire avec une ou plusieurs règles. Une stratégie d’inventaire est un ensemble de règles dans un document JSON.

{
  "enabled": true,
  "rules": [
  {
    "enabled": true,
    "name": "inventoryrule1",
    "destination": "inventory-destination-container",
    "definition": {. . .}
  },
  {
    "enabled": true,
    "name": "inventoryrule2",
    "destination": "inventory-destination-container",
    "definition": {. . .}
  }]
}

Pour afficher le code JSON d’une stratégie d’inventaire, sélectionnez l’onglet Mode Code dans la section Inventaire des objets blob du Portail Azure.

Nom du paramètre Type de paramètre Notes Requis ?
enabled boolean Paramètre permettant de désactiver l’intégralité de la stratégie. Lorsqu’il a la valeur true, le champ de niveau règle activé remplace ce paramètre. Quand il est désactivé, l’inventaire est désactivé pour toutes les règles. Yes
rules Tableau d’objets de règle Une stratégie requiert au moins une règle. Jusqu’à 100 règles sont prises en charge par stratégie. Yes

Règles d’inventaire

Une règle capture les conditions de filtrage et les paramètres de sortie associés à la génération d’un rapport d’inventaire. Chaque règle crée un rapport d’inventaire. Les règles peuvent comporter des préfixes qui se chevauchent. Il peut arriver qu’un objet blob apparaisse dans plusieurs inventaires en fonction des définitions de règles.

Chaque règle au sein de la stratégie a plusieurs paramètres :

Nom du paramètre Type de paramètre Notes Requis ?
name string Un nom de règle peut comporter jusqu’à 256 caractères alphanumériques sensibles à la casse. Il doit être unique dans une stratégie. Yes
enabled boolean Indicateur permettant l’activation et la désactivation d’une règle. La valeur par défaut est true. Yes
Définition Définition de règle d’inventaire JSON Chaque définition se compose d’un ensemble de filtres de règle. Yes
destination string Le conteneur de destination dans lequel tous les fichiers d’inventaire sont générés. Il doit déjà exister.

L’indicateur global Inventaire des objets blob activé est prioritaire sur le paramètre activé dans une règle.

Définition de la règle

Nom du paramètre Type de paramètre Notes Obligatoire
filtres json Les filtres déterminent si un blob ou un conteneur fait partie de l’inventaire ou non. Yes
format string Détermine la sortie du fichier d’inventaire. Les valeurs valides sont csv (pour le format CSV) et parquet (pour le format Apache Parquet). Yes
objectType string Indique s’il s’agit d’une règle d’inventaire pour les blobs ou les conteneurs. Les valeurs valides sont blob et container. Yes
schedule string Calendrier d’exécution de cette règle. Les valeurs valides sont daily et weekly. Yes
schemaFields Tableau JSON Liste des champs de schéma devant faire partie de l’inventaire. Yes

Filtres de règle

Plusieurs filtres sont disponibles pour personnaliser un rapport d’inventaire d’objets blob :

Nom du filtre Type de filtre Notes Requis ?
blobTypes Tableau de valeurs enum prédéfinies Les valeurs valides sont blockBlob et appendBlob pour les comptes avec espace de noms hiérarchique, et blockBlob, appendBlob et pageBlob pour les autres. Ce champ n’est pas applicable à l’inventaire d’un conteneur (objectType : container). Oui
creationTime Numéro Spécifie le nombre de jours depuis la création du blob. Par exemple, la valeur 3 inclut uniquement dans le rapport les blobs créés au cours des trois derniers jours. Non
prefixMatch Tableau pouvant comporter jusqu’à 10 chaînes pour les préfixes à mettre en correspondance Si vous ne définissez pas prefixMatch ou que vous indiquez un préfixe vide, la règle s’applique à tous les objets blob du compte de stockage. Un préfixe doit être un préfixe de nom de conteneur ou un nom de conteneur. Par exemple, container, container1/foo. Non
excludePrefix Tableau pouvant comporter jusqu’à 10 chaînes pour les préfixes à exclure. Spécifie les chemins des objets blob à exclure du rapport d’inventaire.

Un excludePrefix doit être un préfixe de nom de conteneur ou un nom de conteneur. Un excludePrefix vide signifierait que tous les objets blob avec des noms correspondant à n’importe quelle chaîne prefixMatch seront listés.

Si vous souhaitez inclure un certain préfixe mais exclure un sous-ensemble spécifique de celui-ci, vous pouvez utiliser le filtre excludePrefix. Par exemple, si vous souhaitez inclure tous les objets blob sous container-a excepté ceux qui sont sous le dossier container-a/folder, prefixMatch doit être défini sur container-a et excludePrefix doit être défini sur container-a/folder.
No
includeSnapshots boolean Spécifie si l’inventaire doit inclure les instantanés. La valeur par défaut est false. Ce champ n’est pas applicable à l’inventaire d’un conteneur (objectType : container). No
includeBlobVersions boolean Spécifie si l’inventaire doit inclure les versions d’objets blob. La valeur par défaut est false. Ce champ n’est pas applicable à l’inventaire d’un conteneur (objectType : container). No
includeDeleted boolean Spécifie si l’inventaire doit inclure les objets blob supprimés. La valeur par défaut est false. Dans les comptes qui ont un espace de noms hiérarchique, ce filtre inclut les dossiers et englobe également les objets blob qui sont dans un état supprimé de manière réversible.

Seuls les dossiers et fichiers (objets blob) explicitement supprimés apparaissent dans les rapports. Les dossiers et fichiers enfants qui sont supprimés à la suite de la suppression d’un dossier parent ne sont pas inclus dans le rapport.
No

Pour afficher le code JSON de règles d’inventaire, sélectionnez l’onglet Mode Code dans la section Inventaire des objets blob du Portail Azure. Les filtres sont spécifiés au sein d’une définition de règle.

{
  "destination": "inventory-destination-container",
  "enabled": true,
  "rules": [
  {
    "definition": {
      "filters": {
        "blobTypes": ["blockBlob", "appendBlob", "pageBlob"],
        "prefixMatch": ["inventorytestcontainer1", "inventorytestcontainer2/abcd", "etc"],
        "excludePrefix": ["inventorytestcontainer10", "etc/logs"],
        "includeSnapshots": false,
        "includeBlobVersions": true,
      },
      "format": "csv",
      "objectType": "blob",
      "schedule": "daily",
      "schemaFields": ["Name", "Creation-Time"]
    },
    "enabled": true,
    "name": "blobinventorytest",
    "destination": "inventorydestinationContainer"
  },
  {
    "definition": {
      "filters": {
        "prefixMatch": ["inventorytestcontainer1", "inventorytestcontainer2/abcd", "etc"]
      },
      "format": "csv",
      "objectType": "container",
      "schedule": "weekly",
      "schemaFields": ["Name", "HasImmutabilityPolicy", "HasLegalHold"]
    },
    "enabled": true,
    "name": "containerinventorytest",
    "destination": "inventorydestinationContainer"
    }
  ]
}

Champs de schéma personnalisés pris en charge pour l’inventaire des blobs

Remarque

La colonne Data Lake Storage montre la prise en charge dans les comptes où la fonctionnalité d’espace de noms hiérarchique est activée.

Champ Stockage Blob (prise en charge par défaut) Data Lake Storage
Name (obligatoire) Oui Yes
Creation-Time Oui Oui
Last-Modified Oui Oui
LastAccessTime1 Oui Yes
ETag Oui Oui
Content-Length Yes Yes
Content-Type Oui Oui
Content-Encoding Yes Yes
Content-Language Oui Yes
Content-CRC64 Oui Yes
Content-MD5 Yes Yes
Cache-Control Yes Yes
Cache-Disposition Oui Oui
BlobType Oui Yes
AccessTier Oui Yes
AccessTierChangeTime Yes Oui
LeaseStatus Oui Oui
LeaseState Yes Yes
ServerEncrypted Yes Yes
CustomerProvidedKeySHA256 Oui Oui
Métadonnées Yes Oui
Expiry-Time Non Yes
hdi_isfolder Non Yes
Propriétaire Non Yes
Groupe Non Yes
Autorisations Non Yes
Acl Non Yes
Snapshot (disponible et obligatoire lorsque vous choisissez d’inclure des instantanés dans votre rapport) Oui Oui
Deleted Oui Oui
DeletedId Non Yes
DeletedTime Non Oui
RemainingRetentionDays Oui Oui
VersionId (disponible et obligatoire lorsque vous choisissez d’inclure des versions de blobs dans votre rapport) Oui Non
IsCurrentVersion (disponible et obligatoire lorsque vous choisissez d’inclure des versions de blobs dans votre rapport) Yes Non
TagCount Yes Non
Étiquettes Yes Non
CopyId Oui Yes
CopySource Yes Yes
CopyStatus Yes Yes
CopyProgress Yes Yes
CopyCompletionTime Yes Yes
CopyStatusDescription Yes Oui
ImmutabilityPolicyUntilDate Yes Yes
ImmutabilityPolicyMode Yes Oui
LegalHold Oui Oui
RehydratePriority Yes Yes
ArchiveStatus Oui Oui
EncryptionScope Oui Oui
IncrementalCopy Oui Oui
x-ms-blob-sequence-number Oui Non

1 Désactivé par défaut. Activer éventuellement le suivi du temps d'accès.

Champs de schéma personnalisés pris en charge pour l’inventaire des conteneurs

Remarque

La colonne Data Lake Storage montre la prise en charge dans les comptes où la fonctionnalité d’espace de noms hiérarchique est activée.

Champ Stockage Blob (prise en charge par défaut) Data Lake Storage
Name (obligatoire) Oui Oui
Last-Modified Oui Yes
ETag Oui Oui
LeaseStatus Oui Oui
LeaseState Yes Yes
LeaseDuration Yes Oui
Métadonnées Yes Yes
PublicAccess Yes Yes
DefaultEncryptionScope Yes Yes
DenyEncryptionScopeOverride Oui Yes
HasImmutabilityPolicy Yes Oui
HasLegalHold Yes Yes
ImmutableStorageWithVersioningEnabled Yes Oui
Deleted (apparaît seulement si l’inclusion des conteneurs supprimés est sélectionnée) Oui Oui
Version (apparaît seulement si l’inclusion des conteneurs supprimés est sélectionnée) Oui Yes
DeletedTime (apparaît seulement si l’inclusion des conteneurs supprimés est sélectionnée) Oui Yes
RemainingRetentionDays (apparaît seulement si l’inclusion des conteneurs supprimés est sélectionnée) Yes Yes

Exécution d’un inventaire

Si vous configurez une règle pour qu’elle s’exécute quotidiennement, son exécution est planifiée tous les jours. Si vous configurez une règle pour qu’elle s’exécute toutes les semaines, elle est planifiée pour s’exécuter chaque semaine à l’heure UTC du dimanche.

La plupart des exécutions d’inventaire se terminent dans les 24 heures. Pour les comptes dotés d’un espace de noms hiérarchique, une exécution peut durer jusqu’à deux jours et, selon le nombre de fichiers traités, l’exécution peut ne pas se terminer à la fin de ces deux jours. La durée maximale pendant laquelle une exécution peut se terminer avant d’échouer est de six jours.

Les exécutions ne se chevauchent pas, de sorte qu’une exécution doit se terminer avant qu’une autre exécution de la même règle puisse commencer. Par exemple, si une règle est planifiée pour s’exécuter quotidiennement, mais que l’exécution du jour précédent de cette même règle est toujours en cours, une nouvelle exécution n’est pas lancée ce jour-là. Les règles qui sont planifiées pour s’exécuter chaque semaine s’exécutent chaque dimanche, que l’exécution précédente réussisse ou échoue. Si une exécution ne se termine pas correctement, vérifiez les exécutions suivantes pour voir si elles se terminent avant de contacter le support. Les performances d’une exécution peuvent varier. Par conséquent, si une exécution ne se termine pas, il est possible que les exécutions suivantes, elles, se terminent.

Les stratégies d’inventaire sont lues ou écrites en entier. Les mises à jour partielles ne sont pas prises en charge. Les règles d’inventaire sont évaluées quotidiennement. Par conséquent, si vous modifiez la définition d’une règle, mais que les règles d’une stratégie ont déjà été évaluées pour ce jour-là, vos mises à jour ne seront évaluées que le jour suivant.

Événement d’inventaire terminé

L’événement BlobInventoryPolicyCompleted est généré lorsque l’exécution de l’inventaire est terminée pour une règle. Cet événement se produit également si l’exécution de l’inventaire rencontre une erreur utilisateur avant de commencer. Par exemple, une stratégie non valide ou une erreur qui se produit lorsqu’un conteneur de destination n’est pas présent déclenchera l’événement. Le json suivant montre un exemple d’événement BlobInventoryPolicyCompleted.

{
  "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/BlobInventory/providers/Microsoft.EventGrid/topics/BlobInventoryTopic",
  "subject": "BlobDataManagement/BlobInventory",
  "eventType": "Microsoft.Storage.BlobInventoryPolicyCompleted",
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "data": {
    "scheduleDateTime": "2021-05-28T03:50:27Z",
    "accountName": "testaccount",
    "ruleName": "Rule_1",
    "policyRunStatus": "Succeeded",
    "policyRunStatusMessage": "Inventory run succeeded, refer manifest file for inventory details.",
    "policyRunId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "manifestBlobUrl": "https://testaccount.blob.core.windows.net/inventory-destination-container/2021/05/26/13-25-36/Rule_1/Rule_1-manifest.json"
  },
  "dataVersion": "1.0",
  "metadataVersion": "1",
  "eventTime": "2021-05-28T15:03:18Z"
}

Le tableau suivant décrit le schéma de l’événement BlobInventoryPolicyCompleted.

Champ Type Description
scheduleDateTime string Heure à laquelle la règle d’inventaire a été planifiée.
accountName string nom du compte de stockage.
ruleName string Nom de la règle.
policyRunStatus string État de l’exécution de l’inventaire. Les valeurs possibles sont Succeeded, PartiallySucceeded et Failed.
policyRunStatusMessage string Message d’état pour l’exécution de l’inventaire.
policyRunId string ID d’exécution de la stratégie pour l’exécution de l’inventaire.
manifestBlobUrl string URL du blob pour le fichier manifeste pour l’exécution de l’inventaire.

Sortie de l’inventaire

Chaque règle d’inventaire génère un ensemble de fichiers dans le conteneur de destination des inventaires spécifié pour cette règle. La sortie d’inventaire est générée dans le chemin https://<accountName>.blob.core.windows.net/<inventory-destination-container>/YYYY/MM/DD/HH-MM-SS/<ruleName, où :

  • accountName est le nom du compte Stockage Blob Azure ;
  • inventory-destination-container est le conteneur de destination que vous avez spécifié dans la règle d’inventaire ;
  • YYYY/MM/DD/HH-MM-SS est l’heure à laquelle l’inventaire a commencé à s’exécuter ;
  • ruleName est le nom de la règle d’inventaire.

Fichiers d’inventaire

Chaque exécution d’inventaire pour une règle génère les fichiers suivants :

  • Fichier d’inventaire : L’exécution d’un inventaire pour une règle génère un fichier au format CSV ou Apache Parquet. Chacun de ces fichiers contient les objets mis en correspondance et leurs métadonnées.

    Important

    À compter d’octobre 2023, les exécutions d’inventaire produisent plusieurs fichiers, si le nombre d’objets est volumineux. Pour plus d’informations, consultez FAQ sur les sorties de plusieurs fichiers d’inventaire.

    Les rapports au format Apache Parquet présentent les dates au format suivant : timestamp_millis [number of milliseconds since 1970-01-01 00:00:00 UTC]. Pour un fichier au format CSV, la première ligne est toujours celle du schéma. Voici un fichier CSV d’inventaire ouvert dans Microsoft Excel.

    Capture d’écran d’un fichier CSV d’inventaire ouvert dans Microsoft Excel

    Important

    Les chemins d’accès des blobs qui apparaissent dans un fichier d’inventaire peuvent ne pas apparaître dans un ordre particulier.

  • Fichier de somme de contrôle : Un fichier de somme de contrôle contient la somme de contrôle MD5 du contenu du fichier manifest.json. Le nom du fichier de somme de contrôle est <ruleName>-manifest.checksum. La génération du fichier de somme de contrôle marque la fin de l’exécution d’une règle d’inventaire.

  • Fichier manifeste : Un fichier manifest.json contient les détails du ou des fichiers d’inventaire générés pour cette règle. Le nom du fichier est <ruleName>-manifest.json. Ce fichier capture également la définition de règle fournie par l’utilisateur et le chemin vers l’inventaire pour cette règle. Le code JSON suivant montre le contenu d’un exemple de fichier manifest.json.

    {
    "destinationContainer" : "inventory-destination-container",
    "endpoint" : "https://testaccount.blob.core.windows.net",
    "files" : [
      {
        "blob" : "2021/05/26/13-25-36/Rule_1/Rule_1.csv",
        "size" : 12710092
      }
    ],
    "inventoryCompletionTime" : "2021-05-26T13:35:56Z",
    "inventoryStartTime" : "2021-05-26T13:25:36Z",
    "ruleDefinition" : {
      "filters" : {
        "blobTypes" : [ "blockBlob" ],
        "includeBlobVersions" : false,
        "includeSnapshots" : false,
        "prefixMatch" : [ "penner-test-container-100003" ]
      },
      "format" : "csv",
      "objectType" : "blob",
      "schedule" : "daily",
      "schemaFields" : [
        "Name",
        "Creation-Time",
        "BlobType",
        "Content-Length",
        "LastAccessTime",
        "Last-Modified",
        "Metadata",
        "AccessTier"
      ]
    },
    "ruleName" : "Rule_1",
    "status" : "Succeeded",
    "summary" : {
      "objectCount" : 110000,
      "totalObjectSize" : 23789775
    },
    "version" : "1.0"
    }
    

    Ce fichier est créé au démarrage de l’exécution. Le champ status de ce fichier est défini sur Pending jusqu’à la fin de l’exécution. Une fois l’exécution terminée, ce champ est défini sur un état d’achèvement (par exemple : Succeeded ou Failed).

Tarification et facturation

La tarification de l’inventaire est basée sur le nombre de blobs et de conteneurs analysés au cours de la période de facturation. La page de tarification du stockage Blob Azure affiche le prix par million d’objets analysés. Par exemple, si le prix de l’analyse d’un million d’objets est de $0.003, que votre compte contient trois millions d’objets et que vous produisez quatre rapports mensuels, votre facture serait de 4 * 3 * $0.003 = $0.036.

Après la création des fichiers d’inventaire, des frais standard supplémentaires de stockage de données et d’exploitation seront encourus pour le stockage, la lecture et l’écriture des fichiers générés par l’inventaire dans le compte.

Si une règle contient un préfixe qui chevauche le préfixe d’une autre règle, le même blob peut apparaître dans plusieurs rapports d’inventaire. Dans ce cas, les deux instances vous sont facturées. Par exemple, supposons que l’élément prefixMatch d’une règle est défini sur ["inventory-blob-1", "inventory-blob-2"] et que l’élément prefixMatch d’une autre règle est défini sur ["inventory-blob-10", "inventory-blob-20"]. Un objet nommé inventory-blob-200 apparaît dans les deux rapports d’inventaire.

Les instantanés et les versions d’un blob sont également pris en compte dans la facturation, même si vous avez défini les filtres includeSnapshots et includeVersions sur false. Ces valeurs de filtre sont sans effet sur la facturation. Vous pouvez les utiliser uniquement pour filtrer ce qui apparaît dans le rapport.

Pour plus d’informations sur la tarification de l’inventaire de blobs Stockage Azure, consultez Tarification Stockage Blob Azure.

Prise en charge des fonctionnalités

La prise en charge de cette fonctionnalité peut être impactée par l’activation de Data Lake Storage Gen2, du protocole NFS (Network File System) 3.0 ou du protocole SFTP (SSH File Transfer Protocol). Si vous avez activé l’une de ces fonctionnalités, consultez Prise en charge des fonctionnalités Stockage Blob dans les comptes Stockage Azure pour évaluer la prise en charge de cette fonctionnalité.

Problèmes connus et limitations

Cette section décrit les limitations et les problèmes connus de la fonctionnalité d’inventaire des objets blob du service Stockage Azure.

Les travaux d’inventaire prennent plus de temps dans certains cas

Un travail d’inventaire peut prendre plus de temps dans les cas suivants :

  • Une grande quantité de nouvelles données est ajoutée

  • Une règle ou un ensemble de règles est en cours d’exécution pour la première fois

    L’exécution d’inventaire peut prendre plus de temps que les exécutions d’inventaire suivantes.

  • L’exécution d’un inventaire consiste à traiter une grande quantité de données dans des comptes activés par l’espace de noms hiérarchique

    Un travail d’inventaire peut prendre plus d’un jour pour les comptes avec espace de noms hiérarchique qui ont des centaines de millions d’objets blob. Parfois, le travail d’inventaire échoue et ne crée pas de fichier d’inventaire. Si un travail ne se termine pas correctement, vérifiez les travaux suivants pour voir s’ils se terminent avant de contacter le support.

  • Il n’existe aucune option permettant de générer un rapport de manière rétrospective à une date donnée.

Les travaux d’inventaire ne peuvent pas écrire de rapports dans des conteneurs qui ont une stratégie de réplication d’objet

Une stratégie de réplication d’objet peut empêcher un travail d’inventaire d’écrire des rapports d’inventaire dans le conteneur de destination. D’autres scénarios peuvent archiver les rapports ou rendre les rapports immuables lorsqu’ils sont partiellement terminés, ce qui peut entraîner l’échec des travaux d’inventaire.

Inventaire et stockage immuable

Vous ne pouvez pas configurer une stratégie d’inventaire dans le compte si la prise en charge de l’immuabilité au niveau de la version est activée sur ce compte, ou si la prise en charge de l’immuabilité au niveau de la version est activée sur le conteneur de destination défini dans la stratégie d’inventaire.

Les rapports peuvent exclure des objets BLOB supprimés de manière réversible dans les comptes qui ont un espace de noms hiérarchique

Si un conteneur ou un répertoire est supprimé avec la suppression réversible activée, le conteneur ou le répertoire et tout son contenu sont marqués comme supprimés de manière réversible. Toutefois, seul le conteneur ou le répertoire (signalé en tant qu’objet BLOB de longueur nulle) apparaît dans un rapport d’inventaire et non dans les objets BLOB supprimés de manière réversible dans ce conteneur ou répertoire, même si vous définissez le champ includeDeleted de la stratégie sur true. Cela peut entraîner une différence entre ce qui apparaît dans les métriques de capacité que vous obtenez dans le Portail Azure et ce qui est signalé par un rapport d’inventaire.

Seuls les objets BLOB qui sont supprimés explicitement apparaissent dans les rapports. Par conséquent, pour obtenir une liste complète de tous les objets BLOB supprimés de manière réversible (répertoire et tous les objets BLOB enfants), les charges de travail doivent supprimer chaque objet BLOB d’un répertoire avant de supprimer le répertoire lui-même.

Étapes suivantes