en inventering av Azure Storage-blobs

Azure Storage blob-inventarium listar containrar, blobs, blobversioner, snapshots och tillhörande egenskaper i ditt lagringskonto. Tjänsten genererar rapporter dagligen eller veckovis i kommaseparerade värden (CSV) eller Apache Parquet-format.

Använd lagerrapporter för att granska bevarande, laglig lagring eller krypteringsstatus för innehållet i ditt lagringskonto. Du kan också analysera total storlek, ålder, nivåfördelning och andra attribut i dina data.

Blob inventory kan förenkla affärsarbetsflöden och snabba upp databehandlingsjobb. Den tillhandahåller schemalagd automatisering av List Containers och List Blobs API:erna. Inventarieregler filtrerar innehållet efter blobtyp, prefix eller valda blob-egenskaper.

Azure Storage Blob Inventory är tillgängligt för följande typer av lagringskonton:

• Standard generell användning v2
• Premium-blockbloblagring
• Blobb-lagring

Inventeringsfunktioner

Azure Storage-blobinventering har stöd för följande funktioner och möjligheter.

• Inventeringsrapporter för blobar och containrar

  Du kan generera inventeringsrapporter för blobar och containrar. En rapport för blobs kan innehålla basblobs, snapshots, innehållsstorlek, blobversioner och deras tillhörande egenskaper såsom skapandetid och senast modifierad tid. Rapporten listar inte tomma behållare. En rapport för behållare beskriver behållare och deras tillhörande egenskaper såsom status för oföränderlighetspolicy och laglig hållning.

• Anpassat schema

  Du kan välja vilka fält som ska visas i rapporter. Välj från en lista över fält som stöds. Listan visas senare i den här artikeln.

• CSV- och Apache Parquet-utdataformat

  Du kan generera en inventeringsrapport i antingen CSV- eller Apache Parquet-utdataformat.

• Manifestfil och Azure Event Grid-händelse per inventeringsrapport

  Tjänsten genererar en manifestfil och en Azure Event Grid-händelse för varje inventarierapport. Artikeln beskriver dessa saker senare.

Aktivering av inventeringsrapporter

Aktivera blobinventeringsrapporter genom att lägga till en princip med en eller flera regler i ditt lagringskonto. Vägledning finns i Aktivera Azure Storage-blobinventeringsrapporter.

Uppgradera en inventeringspolicy

Om du konfigurerade Azure Storage blob-inventarie före juni 2021, ladda policyn, gör nödvändiga ändringar och spara den sedan. När du laddar om policyn fyller tjänsten i destinationsinställningarna per regel, manifestfilen och Azure Event Grid-händelseinställningarna med standardvärden. Du kan ändra dessa värden.

• Varje regel stödjer en destinationscontainer istället för att dela en destination på policynivå.

• Tjänsten genererar en manifestfil och en Azure Event Grid-händelse för varje regel istället för för policyn.

Inventeringsprincip

För att konfigurera inventarierapporter, lägg till en inventeringspolicy med en eller flera regler i ett JSON-dokument.

{
  "enabled": true,
  "rules": [
  {
    "enabled": true,
    "name": "inventoryrule1",
    "destination": "inventory-destination-container",
    "definition": {
      "filters": {
        "blobTypes": ["blockBlob"]
      },
      "format": "csv",
      "objectType": "blob",
      "schedule": "daily",
      "schemaFields": ["Name"]
    }
  },
  {
    "enabled": true,
    "name": "inventoryrule2",
    "destination": "inventory-destination-container",
    "definition": {
      "filters": {},
      "format": "csv",
      "objectType": "container",
      "schedule": "weekly",
      "schemaFields": ["Name"]
    }
  }]
}

Visa JSON för en inventeringsprincip genom att välja fliken Kodvy i avsnittet Blobinventering i Azure Portal.

Inventeringsregler

En regel samlar in filtreringsvillkor och utdataparametrar för att generera en inventeringsrapport. Varje regel skapar en inventeringsrapport. Regler kan ha överlappande prefix. En blob kan visas i mer än en inventering beroende på regeldefinitioner.

Varje regel i principen har flera parametrar:

Den globala flaggan för aktivering av blob-inventering har företräde framför parametern aktiverad i en regel.

Regeldefinition

Regelfilter

Använd följande filter för att anpassa en blob-inventarierapport:

Visa JSON för inventeringsregler genom att välja fliken Kodvy i avsnittet Blobinventering i Azure Portal. Du specificerar filter inom en regeldefinition.

{
  "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"
    }
  ]
}

Anpassade schemafält som stöds för blobinventering

Fält	Blob Storage (standardstöd)	Datalagring i Data Lake
Namn (krävs)
Skapandetid
Senast ändrad
LastAccessTime1
ETag
Innehållslängd
Innehållstyp
Innehållskodning
Innehållsspråk
Innehåll-CRC64
Content-MD5
Cache-Control
Cache-disposition
Blobtyp
AccessTier (på engelska)
AccessTierChangeTime
LeaseStatus
LeaseState
Serverkrypterad
KundeTillhandahållenNyckelSHA256
Metainformation
Förfallotid
hdi_isfolder
Ägare
Grupp
Behörigheter
Åtkomstkontrollista
Ögonblicksbild (tillgänglig och obligatorisk när du väljer att inkludera ögonblicksbilder i rapporten)
Borttagen
Borttagnings-ID
Borttagen tid
Återstående Lagringsdagar
VersionId (Tillgängligt och obligatoriskt när du väljer att inkludera blobversioner i rapporten)
IsCurrentVersion (tillgängligt och obligatoriskt när du väljer att inkludera blobversioner i rapporten)
TagCount
Taggar
KopieringsId
KopiaKälla
Kopieringsstatus
CopyProgress
Kopieringsavslutningstid
Beskrivning av kopieringsstatus
OföränderlighetspolicyTillsDatum
OföränderlighetPolicyMode
LegalHold (på engelska)
RehydrateraPrioritet
ArchiveStatus (ArkivStatus)
Krypteringsomfattning
Inkrementell Kopiering
x-ms-blob-sekvensnummer

¹ Inaktiverad som standard. Du kan också aktivera spårning av åtkomsttid.

Anpassade schemafält som stöds för containerinventering

Fält	Blob Storage (standardstöd)	Datalagring i Data Lake
Namn (krävs)
Senast ändrad
ETag
LeaseStatus
LeaseState
Hyreslängd
Metainformation
PublicAccess
Standardkrypteringsomfång
Neka överskridande av krypteringsomfattning
HarOföränderlighetspolicy
HarJuridiskHållning
OföränderligLagringMedVersionshanteringAktiverad
Borttagen (visas endast om ta med borttagna containrar har valts)
Version (visas endast om ta med borttagna containrar har valts)
DeletedTime (Visas endast om inkludera raderade behållare är valt)
Återstående kvarhållningsdagar (Visas endast om alternativet att inkludera raderade behållare har valts)

Inventeringskörning

Om du konfigurerar en regel att köras dagligen, körs den varje dag. Om du konfigurerar en regel att köras veckovis, körs den varje söndag i UTC.

En inventeringsgenomgång kan ta upp till sex dagar innan den misslyckas. För att lära dig om faktorer som påverkar körtiden, se Blob inventory performance characteristics.

Körningar överlappar inte, så en körning måste slutföras innan en annan körning av samma regel kan börja. Till exempel, om föregående dags körning av en daglig regel fortfarande pågår, startar tjänsten inte en ny körning samma dag. Veckovisa regler körs varje söndag oavsett om en tidigare körning lyckas eller misslyckas. Om en genomspelning inte slutförs, kontrollera efterföljande genomspelningar innan du kontaktar supporten. Prestandan för en körning kan variera, så en efterföljande körning kan slutföras utan problem.

Inventeringsprinciper läses eller skrivs fullständigt. Partiella uppdateringar stöds inte. Inventeringsregler utvärderas dagligen. Om du ändrar en regeldefinition efter att tjänsten utvärderat policyn för den dagen, utvärderar tjänsten dina uppdateringar nästa dag.

Inventeringen har slutförts

Händelsen BlobInventoryPolicyCompleted genereras när inventeringskörningen slutförs för en regel. Den här händelsen inträffar också om inventeringskörningen misslyckas med ett användarfel innan den börjar köras. Till exempel utlöser en ogiltig policy eller en saknad destinationscontainer händelsen. Följande JSON visar ett exempelevent 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"
}

I följande tabell beskrivs schemat för BlobInventoryPolicyCompleted händelsen.

Inventeringsutdata

Varje inventarieregel skapar en uppsättning filer i den angivna inventariedestinationsbehållaren för den regeln. Lagerutmatningen finns tillgänglig på följande väg: https://<accountName>.blob.core.windows.net/<inventory-destination-container>/YYYY/MM/DD/HH-MM-SS/<ruleName> där:

• accountName är ditt Azure Blob Storage-kontonamn.
• inventory-destination-container är den målcontainer som du angav i inventeringsregeln.
• YYYY/MM/DD/HH-MM-SS är tiden då inventeringen började.
• ruleName är namnet på inventeringsregeln.

Inventeringsfiler

Varje inventeringskörning för en regel genererar följande filer:

• Inventeringsfil: En inventeringskörning för en regel genererar en CSV- eller Apache Parquet-formaterad fil. Varje sådan fil innehåller matchade objekt och deras metadata.

  Viktigt!

  Inventariekörningar ger flera filer om objektantalet är stort. Mer information finns i Vanliga frågor och svar om utdata för flera inventeringsfiler.

  Rapporter i Apache Parquet-format presenterar datum i följande format: timestamp_millis [number of milliseconds since 1970-01-01 00:00:00 UTC]. För en CSV-formaterad fil är den första raden alltid schemaraden. Följande bild visar en CSV-inventeringsfil som öppnats i Microsoft Excel.

  

  Viktigt!

  Blobbbanor som visas i en lagerfil visas kanske inte i någon viss ordning.

• Kontrollsummefil: En kontrollsummefil innehåller MD5-kontrollsumman för filens innehåll manifest.json . Namnet på checksum-filen är <ruleName>-manifest.checksum. Genereringen av kontrollsummafilen markerar slutförandet av en inventeringsregelkörning.

• Manifestfil: En fil innehåller detaljerna för inventariefilerna som genererats manifest.json för den regeln. Namnet på filen är <ruleName>-manifest.json. Denna fil fångar också regeldefinitionen och vägen till inventariet för den regeln. Följande JSON visar innehållet i en exempelfil 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"
  }
  

  Den här filen skapas när körningen börjar. Fältet status i den här filen är inställt på Pending tills körningen har slutförts. När körningen har slutförts anges det här fältet med en slutförandestatus (till exempel: Succeeded eller Failed).

Prissättning och fakturering

Prissättningen för lager baseras på antalet blobs och behållare som du skannar under faktureringsperioden. Prissidan för Azure Blob Storage visar priset per en miljon objekt som genomsöks. Om priset för att skanna en miljon objekt till exempel är $0.003innehåller ditt konto tre miljoner objekt och du skapar fyra rapporter under en månad, då blir 4 * 3 * $0.003 = $0.036din faktura .

När du har skapat inventeringsfiler debiteras du ytterligare standardavgifter för datalagring och åtgärder för att lagra, läsa och skriva de filer som genereras av inventeringen i kontot.

Om en regel innehåller ett prefix som överlappar med ett prefix från någon annan regel kan samma blob förekomma i mer än en inventarierapport. I det här fallet betalar du för båda fallen. Anta till exempel att elementet i prefixMatch en regel är inställt på och att ["inventory-blob-1", "inventory-blob-2"]elementet i prefixMatch en annan regel är inställt på ["inventory-blob-10", "inventory-blob-20"]. Ett objekt med namnet inventory-blob-200 visas i båda inventeringsrapporterna.

Ögonblicksbilder och versioner av en blob räknas också med i faktureringen även om du ställer in filtren includeSnapshots och includeBlobVersions på false. Dessa filtervärden påverkar inte faktureringen. Du kan bara använda dem för att filtrera det som visas i rapporten.

Mer information om priser för Azure Storage-blobinventering finns i Prissättning för Azure Blob Storage.

Funktionsstöd

Stöd för den här funktionen kan påverkas genom att aktivera Data Lake Storage Gen2, NFS 3.0-protokoll (Network File System) eller SSH File Transfer Protocol (SFTP). Om du har aktiverat någon av dessa funktioner kan du läsa Stöd för Blob Storage-funktioner i Azure Storage-konton för att utvärdera stödet för den här funktionen.

Kända problem och begränsningar

I det här avsnittet beskrivs begränsningar och kända problem med blobininventeringsfunktionen i Azure Storage.

Inventarierapport, objektantal och datastorlek bör inte jämföras med fakturering

En inventarierapport inkluderar inte metadata, systemloggar och egenskaper, så jämför den inte med antalet fakturerade objekt och datastorleken för lagringskontot.

Inventeringsjobb tar längre tid att slutföra i vissa fall

Ett lagerjobb kan ta längre tid i dessa fall:

• Du lägger till en stor mängd ny data.

• Du kör en regel eller ett regelverk för första gången.

  Inventariegenomgången kan ta längre tid än efterföljande körningar.

• En inventariekörning bearbetar stora mängder data i hierarkiska namnrymdsaktiverade konton.

  Ett inventariejobb kan ta mer än en dag att slutföra för hierarkiska namnrymdsaktiverade konton som har hundratals miljoner blobs. Ibland misslyckas inventeringsjobbet och skapar ingen inventeringsfil. Om ett jobb inte har slutförts kontrollerar du efterföljande jobb för att se om de är slutförda innan du kontaktar supporten.

• Det finns inget alternativ för att generera en rapport i efterhand för ett visst datum.

Inventeringsjobb kan inte skriva rapporter till containrar som har en princip för objektreplikering

En princip för objektreplikering kan förhindra att ett inventeringsjobb skriver inventeringsrapporter till målcontainern. Vissa andra scenarier kan arkivera rapporterna eller göra dem oföränderliga när de delvis är klara, vilket kan orsaka att inventeringsjobb misslyckas.

Inventarium och oföränderlig lagring

Du kan inte konfigurera en inventariepolicy i kontot om stöd för versionsnivå-oföränderlighet är aktiverat på det kontot, eller om stöd för versionsnivå-oföränderlighet är aktiverat i destinationscontainern som du definierar i inventariepolicyn.

Rapporter kan undanta mjukt raderade blobbar i konton som har ett hierarkiskt namnområde

Om du raderar en container eller katalog när mjuk borttagning är aktiverad, markerar tjänsten den och allt dess innehåll som mjukt raderat. Dock förekommer endast behållaren eller katalogen, rapporterad som en nolllängdsblob, i en inventarierapport. Rapporten inkluderar inte mjukt raderade barnblobs även om du sätter policyns includeDeleted fält på true. Detta beteende kan skapa en skillnad mellan kapacitetsmått i Azure-portalen och inventarierapporten.

Endast blobs som du uttryckligen tar bort syns i rapporterna. För att få en fullständig lista över alla mjukt raderade blobs (katalog och alla underblobar) bör arbetsbelastningar ta bort varje blob i en katalog innan själva katalogen raderas.

Hantera dubbletter i blob-inventariet

Blob Inventory körs i ett distribuerat system, vilket innebär att dubbla blob-poster i sällsynta fall kan förekomma i dina rapporter.

Om ditt användningsfall kräver unika blobposter när du efterbehandlar en inventarierapport, använd Name fältet för att bara returnera unika blobs.

Om din rapport innehåller blobversioner använder du fälten Name och Version ID tillsammans för att identifiera och returnera endast de unika blobbarna och versionerna.

Nästa steg

• Aktivera Azure Storage-blobinventeringsrapporter
• Beräkna antalet och den totala storleken på blobar per container
• Handledning: Analysera blob-inventeringsrapporter
• Hantera livscykeln för Azure Blob Storage
• Vanliga frågor om blobinventering