Hur data bearbetas i FinOps-hubbar

FinOps-hubbar utför många databearbetningsaktiviteter för att rensa, normalisera och optimera data. Följande avsnitt visar hur data flödar från Cost Management till en hubbinstans.

Omfångskonfiguration

Ett omfång är en nivå inom molnresurs- och kontohierarkin som ger åtkomst till kostnader, användning och koldioxiddata. För FinOps-hubbar rekommenderar vi vanligtvis att du använder faktureringskonton för företagsavtal (EA) eller faktureringsprofiler för Microsoft-kundavtal (MCA), men alla molnomfattningar räcker för grundläggande analys. Det viktigaste är om pris- och reservationsdata behövs, eftersom Cost Management endast exponerar data för EA-faktureringskonton och MCA-faktureringsprofiler.

FinOps Hubs har stöd för att konfigurera omfång genom att manuellt konfigurera Cost Management-exporter eller genom att ge FinOps Hubs åtkomst för att hantera omfång åt dig. Hanterade omfång konfigureras i filen config/settings.json i hubblagringen. Informationen beskriver vad som händer när ett nytt hanterat omfång läggs till i den här filen. Ohanterade omfång, där Cost Management-exporter konfigureras manuellt, kräver inte någon annan konfiguration.

1. Utlösaren config_SettingsUpdated körs när settings.json-filen uppdateras.
2. Den config_ConfigureExports pipelinen skapar nya exporter för alla nya omfång som har lagts till.

Datainsamling

Följande diagram visar datainmatningsprocessen från slutpunkt till slutpunkt i FinOps-hubbar:

1. (Valfritt) Om du använder hanterade exporter:
   1. Config_DailySchedule och config_MonthlySchedule körs enligt sina respektive scheman för att starta datainmatning.
   2. Den config_StartExportProcess pipelinen hämtar tillämpliga exporter för det schema som körs.
   3. Den config_RunExportJobs pipelinen kör var och en av de valda exporterna.
2. Cost Management exporterar information om råa kostnader till containern msexports . Läs mer.
3. Den msexports_ExecuteETL pipeline köar extract-transform-load (ETL)-pipeline när filer läggs till i msexports behållare.
4. Den msexports_ETL_ingestion-pipelin omvandlar data till parquet-format och flyttar dem till inmatningscontainern med hjälp av en skalbar filstruktur. Läs mer.
5. (Valfritt) Om du använder Azure Data Explorer:
   1. Den ingestion_ExecuteETL pipeline köar upp Datautforskarens inmatningspipeline när manifest.json-filer läggs till i inmatnings container.
      • Om du matar in anpassade datauppsättningar utanför Cost Management-exporter skapar du en tom manifest.json fil i målinmatningsmappen när alla andra filer är klara (lägg inte till den här filen när filerna fortfarande laddas upp). Den manifest.json filen parsas inte och kan vara tom. Det enda syftet är att ange att alla filer för det här inmatningsjobbet läggs till.
   2. Den ingestion_ETL_dataExplorer-pipelinen läser in data till tabellen {dataset}_raw i Datautforskaren.
      • Datauppsättningens namn är den första mappen i inmatningsbehållare.
      • Alla rådatatabeller finns i databasen Inmatning i Datautforskaren.
   3. När data matas in i rådatatabeller i Datautforskaren kopierar en uppdateringsprincip data till motsvarande {dataset}_final_v1_0 tabell med hjälp av funktionen {dataset}_transform_v1_0() för att normalisera alla data så att de justeras till FOCUS 1.0.
   4. Efter inmatning utför ingestion_ETL_dataExplorer-pipeline en viss rensning, inklusive att ta bort data i den sista tabellen som har passerat datalagringsperioden.
      • Från och med 0.7 tillämpar Data Explorer datakvarhållning i rådatatabeller medan datakvarhållning i sluttabeller tillämpas av datainmatningspipelinen. Om datainmatningen stoppas rensas inte historiska data.
      • Datakvarhållning kan konfigureras under malldistributionen eller manuellt i config/settings.json-fil i lagringen.
6. Rapporter och andra verktyg som Power BI läser data från Data Explorer eller inmatningsbehållare.
   • Data i Datautforskaren kan läsas från databasen Hub.
     • Använd funktionen {dataset}() för att använda det senaste schemat.
       • Den här funktionen är användbar för snabb utforskning, men kan innebära störande ändringar när FinOps-hubb-instansen uppdateras.
     • Använd funktionen {dataset}_v1_0() för att använda schemat FOCUS 1.0.
       • Versionsscheman för funktioner bör inte ändras över tid, men värden kan ändras om datakällan ändrar dessa värden.
     • Undvik att använda databasinmatning för sökfrågor. Även om det inte uttryckligen är förbjudet bör inmatning databas betraktas som ett internt område för mellanlagring och dataförberedelse.
   • Data i lagring kan läsas från ingestion/<dataset>/<year>/<month>/<scope-path>.
     • Data ska läsas rekursivt från datamängdsmappen och eventuellt inkludera mer efter behov för specificitet.
     • Filer i varje datauppsättningsmapp kan ha olika scheman baserat på datakällan och kontotypen. Var beredd på att transformera data vid inmatning i andra system, till exempel Microsoft Fabric.
     • Läsning från lagring rekommenderas inte på grund av prestandaskäl. Datautforskaren rekommenderas när du rapporterar om mer än en miljon dollar i kostnader.

Om datautforskarens dataimport

När data matas in i Datautforskaren tillämpar {dataset}_transform_v1_0()-funktionerna transformeringsregler i inmatning databas. Varje datauppsättning har en annan uppsättning transformeringsregler som beskrivs i följande avsnitt.

En lista över begärda ändringar, idéer som övervägs och öppna frågor om underliggande Cost Management-datamängder finns i problem #1111. Lämna kommentarer om problemet om du hittar möjligheter att ta itu med eventuella problem eller att uttrycka ditt stöd för något av de specifika problemen.

Transformering av kostnadsdata

Datauppsättningar som stöds:

• Microsoft FocusCost: 1.0r2, 1.0, 1.0-preview(v1)

Följande datauppsättningar har redovisats i designen, men stöds inte internt. Om du vill mata in dessa datauppsättningar skapar du en datapipeline (eller extern process) som skickar parquet-filer till ingestion/Costs/yyyy/mm/{scope-path}-mappen i lagringsutrymmet. {scope-path} kan vara valfri unik sökväg, till exempel aws/123 eller gcp/projects/foo. Det enda kravet är att se till att varje omfång finns i en separat mapp. När du har kopierat externt innehåll skapar du även en manifest.json fil för att utlösa inmatning i Data Explorer.

• Amazon Web Services (AWS) FOCUS 1.0
• Google Cloud Platform (GCP) FOCUS 1.0
• Oracle Cloud Infrastructure (OCI) FOCUS 1.0

Förvandlar:

• v0.7+:
  • Justera kolumnnamnen för FOCUS 1.0-preview till FOCUS 1.0.
    • Inkluderar konvertering av FÖRHANDSVERSION AV FOCUS 1.0 till 1.0.
  • Lägg till x_IngestionTime för att ange när raden senast uppdaterades.
  • Lägg till x_SourceChanges för att identifiera när data i en rad ändras av hubbar.
  • Uppdatera ProviderName och PublisherName när de inte har angetts.
  • Lägg till x_SourceName, x_SourceProvider, x_SourceTypeoch x_SourceVersion för att identifiera den ursprungliga inmatade datamängden.
  • Fyll i saknade värden för ListCost, ListUnitPrice, ContractedCostoch ContractedUnitPrice baserat på prisdokumentet.
    • Den här processen kräver att priserna exporteras före kostnaden. Priserna saknas för den första dagen i månaden om kostnaderna matas in innan priserna är tillgängliga för månaden.
  • Åtgärda ContractedCost när det har angetts felaktigt på grund av ett problem i Cost Management.
  • Skriv ResourceName och x_ResourceGroupName med gemener för att åtgärda konsekvensproblem med versalisering som bryter gruppering och filtrering.
  • Lägg till x_BillingAccountAgreement baserat på kontotypen.
• v0.8+:
  • Åtgärda alla ResourceType värden som använder interna resurstyps-ID:er (till exempel microsoft.compute/virtualmachines).
• v0.9+:
  • Använd gemener för BillingAccountId för att säkerställa att prisjämförelsen matchar alla rader.
  • Skriv med små bokstäver CommitmentDiscountId för att undvika dubbletter av rader när data aggregeras.
  • Lägg till nya x_SourceChanges kontroller för ListCostLessThanContractedCost och ContractedCostLessThanEffectiveCost.
• v0.10+:
  • Åtgärda x_EffectiveUnitPrice när den beräknas och det finns ett avrundningsfel jämfört med x_BilledUnitPrice eller ContractedUnitPrice.
  • Beräkna PricingQuantity och ConsumedQuantity när det finns kostnad men ingen kvantitet.
  • Ange ContractedCost till EffectiveCost när det inte har angetts.
  • Ange ListCost till ContractedCost när det inte har angetts.
  • Ta bort "-2" i x_InvoiceSectionId kolumnen.
  • Ta bort "Ej tilldelad" i x_InvoiceSectionName kolumnen.
  • Korrigeras x_EffectiveUnitPrice när den beräknas och har ett avrundningsfel.
  • Lägg till nya x_SourceChanges kontroller för MissingConsumedQuantity, MissingPricingQuantityoch XEffectiveUnitPriceRoundingError.
• v0.11+:
  • Ändra BillingPeriodStart och BillingPeriodEnd till att vara den första dagen i månaden.

Transformering av prisdata

Datauppsättningar som stöds:

• Microsoft PriceSheet: 2023-05-01 (EA och MCA)

Förvandlar:

• v0.7+
  • Justera kolumnnamnen till FOCUS 1.0.
    • Inkluderar att säkerställa konsekvens för EA- och MCA-kolumnnamn.
    • Ändrar inte de underliggande värdena, vilket kan skilja sig mellan EA och MCA.
  • Konvertera x_SkuTerm ISO-varaktighet till det specifika antalet månader för att matcha kostnadsinformationen.
    • Vi väntar på att FOCUS ska bestämma hur varaktigheter ska definieras innan det här värdet ändras till ISO eller något annat format.
  • Ersätt ContractedUnitPrice för användning av sparplan med motsvarigheten på begäran.
  • Ange ListUnitPrice för användning av sparplan inställd på motsvarande på begäran.
  • Lägg till SkuPriceIdv2 som ett mer exakt SkuPriceId värde än vad som för närvarande finns i kostnadsinformationen.
  • Lägg till x_IngestionTime för att ange när raden senast uppdaterades.
  • Lägg till x_CommitmentDiscountSpendEligibility och x_CommitmentDiscountUsageEligibility.
  • Expandera x_PricingUnitDescription till PricingUnit och x_PricingBlockSize.
  • Lägg till x_BillingAccountAgreement baserat på kontotypen.
  • Ändra x_EffectivePeriodEnd till ett exklusivt slutdatum.
  • Lägg till x_EffectiveUnitPriceDiscount, x_ContractedUnitPriceDiscountoch x_TotalUnitPriceDiscount för att sammanfatta tillgängliga rabatter per SKU.
  • Lägg till x_EffectiveUnitPriceDiscountPercent, x_ContractedUnitPriceDiscountPercentoch x_TotalUnitPriceDiscountPercent för att sammanfatta procentandelen av rabatten per SKU.
  • Lägg till x_SourceName, x_SourceProvider, x_SourceTypeoch x_SourceVersion för att identifiera den ursprungliga inmatade datamängden.
• v0.9+:
  • Använd gemener BillingAccountId för att säkerställa att kostnadssambandet matchar alla rader.

Transformering av rekommendationsdata

Datauppsättningar som stöds:

• Microsoft ReservationRecommendations: 2023-05-01 (EA och MCA)

Förvandlar:

1. Justera kolumnnamnen till FOCUS 1.0.
   • Inkluderar att säkerställa konsekvens för EA- och MCA-kolumnnamn.
   • Ändrar inte de underliggande värdena, vilket kan skilja sig mellan EA och MCA.
2. Lägg till x_SourceName, x_SourceProvider, x_SourceTypeoch x_SourceVersion för att identifiera den ursprungliga inmatade datamängden.

Transformering av transaktionsdata

Datauppsättningar som stöds:

• Microsoft ReservationTransactions : 2023-05-01 (EA och MCA)

Förvandlar:

1. Justera kolumnnamnen till FOCUS 1.0.
   • Inkluderar att säkerställa konsekvens för EA- och MCA-kolumnnamn.
   • Ändrar inte de underliggande värdena, vilket kan skilja sig mellan EA och MCA.
2. Lägg till x_SourceName, x_SourceProvider, x_SourceTypeoch x_SourceVersion för att identifiera den ursprungliga inmatade datamängden.

Transformation av användningsdata för åtaganderabatt

Datauppsättningar som stöds:

• ** Microsoft Bokningsdetaljer: 2023-03-01 (EA och MCA)

Förvandlar:

1. Justera kolumnnamnen till FOCUS 1.0.
   • Inkluderar att säkerställa konsekvens för EA- och MCA-kolumnnamn.
   • Ändrar inte de underliggande värdena, vilket kan skilja sig mellan EA och MCA.
2. Lägg till ResourceType kolumn med resurstypens visningsnamn.
3. Lägg till kolumnerna ServiceName, ServiceCategoryoch x_ServiceModel.
4. Ersätt "NA" med null i x_CommitmentDiscountNormalizedGroup.
5. Lägg till x_CommitmentDiscountQuantity baserat på FOCUS 1.1.

Om inmatningscontainern

FinOps-hubbar förlitar sig på en specifik mappsökväg och filnamnsformat i inmatning lagringscontainer:

ingestion/{dataset}/{date-folder-path}/{scope-id-path}/{ingestion-id}__{original-file-name}.parquet

• ingestion är containern där datapipelinen sparar data.
• {dataset} är den exporterade datamängdstypen. Om du importerar data till Azure Data Explorer måste -ingestering-databasen ha en matchande, skiftlägeskänslig "_raw"-tabell (som exempel "Costs_raw"). FinOps-hubbar stöder följande datauppsättningar i den här versionen:
  • CommitmentDiscountUsage – Export av kostnadshanteringsreservationsinformation.
  • Kostnader – FOCUS-kostnads- och användningsdata.
  • Priser – Export av Kostnadshanteringsprisdokument.
  • Rekommendationer – Export av rekommendationer för kostnadshanteringsreservationer.
  • Transaktioner – Export av Cost Management-reservationstransaktioner.
  • Om du vill mata in anpassade datauppsättningar skapar du en matchande {dataset}_raw-tabell och parquet-inmatningskarta i Ingestion-databasen.
• {date-folder-path} kan vara en eller flera mappar som anger hur många inmatade datauppsättningar som ska behållas. Exempel:
  • all (eller någon platshållare) för att inte spåra historik för datasetet. Varje inmatning ersätter tidigare data. Stöds inte i lagringsbaserade Power BI-rapporter.
  • {yyyy} som ett fyrsiffrigt år för den exporterade datamängden för att endast behålla den senaste inmatningen per år. Stöds inte i lagringsbaserade Power BI-rapporter.
  • {yyyy}/{mm} som ett fyrsiffrigt år och en tvåsiffrig månad för den exporterade datamängden för att behålla den senaste inmatningen per månad.
  • {yyyy}/{mm}/{dd} som ett fyrsiffrigt år, en tvåsiffrig månad och en tvåsiffrig dag för den exporterade datamängden för att behålla den senaste inmatningen per dag. Stöds inte i lagringsbaserade Power BI-rapporter.
• {scope-id-path} är det fullständigt kvalificerade resurs-ID:t för det omfång som data kommer från. Om du matar in icke-Azure-data rekommenderar vi att du använder en logisk hierarki baserat på dataomfånget (till exempel aws/{account-id}, gcp/{project-name}, oci/{component-id}/{component-id}).
• {ingestion-id} är ett unikt ID för den inmatade datamängden. Det här ID:t kan vara ett GUID, en tidsstämpel eller valfritt värde så länge det är konsekvent i alla filer för den inmatade datamängden. Det här värdet används för att ta bort tidigare inmatade data i samma mappsökväg.
• {original-file-name} är avsett att vara det ursprungliga filnamnet eller annan identifierare som anger var data i filen har sitt ursprung. Det här värdet är endast i felsökningssyfte.

Den fullständiga mappsökvägen och inmatnings-ID:t används båda för att säkerställa att data inte dupliceras i lagring eller i Azure Data Explorer. Det ursprungliga filnamnet läggs till i Azure Data Explorer-omfattningar i felsökningssyfte, men spåras eller används inte på annat sätt av FinOps-hubbar.

Om du behöver använda hubbar för att övervaka icke-Azure-data konverterar du data till FOCUS- och släpper dem i inmatning container med hjälp av den här vägledningen. Observera att stöd för icke-Azure-data inte uttryckligen har testats i den senaste versionen. Om du får problem, rapporterar du ett problem.

Om exporten

FinOps-hubbar använder Cost Management-exporter för att hämta kostnadsdata. Cost Management styr mappstrukturen för exporterade data i msexports lagringscontainer. En typisk sökväg ser ut så här:

{container}/{path}/{date-range}/{export-name}/{export-time}/{guid}/{file}

FinOps-hubbar använder manifestfilen för att identifiera omfång, datauppsättning, månad osv. Den enda viktiga delen av sökvägen för hubbar är containern, som måste vara msexports.

Exportera inte data till inmatningscontainern . Exporterade CSV:er måste publiceras till containern msexports som ska bearbetas av hubbarmotorn.

Om du vill mata in anpassade data sparar du parquet-filer i inmatningscontainern så att FinOps toolkit Power BI-rapporterna fungerar som förväntat. När alla parquet-filer har lagts till lägger du till en tom manifest.json fil för att utlösa inmatning.

Om du vill mata in CSV-filen från Cost Management-exporter sparar du filer i en specifik mapp i containern msexports . När alla filer har lagts till lägger du till en manifest.json fil baserat på mallen nedan. Gör följande ändringar för att säkerställa lyckad inmatning:

1. Ändra <export-name> till ett unikt värde inom omfånget för den datauppsättning som du matar in.
   • Detta används endast för rekommendationer för att särskilja de många olika typer av rekommendationer som matas in som inte kan identifieras enbart från exportmanifestet. För reservationsrekommendationer bör du helst inkludera tjänsten, omfånget (enkel/delad) och återställningsperioden.
2. Ändra <dataset> och <version> till exporttypen och versionen för Cost Management. Se listan nedan för datauppsättningar som stöds.
3. Ändra <scope> till Azure-resurs-ID för det omfång som data kom från.
4. Ändra <guid> till ett unikt GUID.
5. Ändra <yyyy-MM> till datamängdens år och månad.
6. Ändra <path-to-file> till den fullständiga mappsökvägen under containern (inkludera inte "msexports").
7. Ändra <file-name> till namnet på den första filen som laddats upp till lagring.
8. Om du har fler än en CSV-fil kopierar du blobobjektet för varje fil som du laddade upp och uppdaterar filnamnet.

{
  "blobCount": 1,
  "dataRowCount": 1,
  "exportConfig": {
    "exportName": "<export-name>",
    "type": "<dataset>",
    "dataVersion": "<version>",
    "resourceId": "<scope>/providers/Microsoft.CostManagement/exports/export-name"
  },
  "runInfo": {
    "runId": "<guid>",
    "startDate": "<yyyy-MM>-01T00:00:00"
  },
  "blobs": [
    {
      "blobName": "<path-to-file>/<file-name>.csv"
    }
  ]
}

FinOps-hubbar stöder följande datauppsättningstyper, versioner och API-versioner:

• FocusCost: 1.0r2, 1.0, 1.0-preview(v1)
• Prisdokument: 2023-05-01
• Reserveringsdetaljer: 2023-03-01
• Bokningsrekommendationer: 2023-05-01
• Reservationstransaktioner: 2023-05-01
• API-versioner: 2023-07-01-preview

FinOps Hubs v0.6

I följande avsnitt förklaras dataprocessen i FinOps Hubs 0.6.

Omfångskonfiguration i v0.6

Följande steg inträffar när ett nytt hanterat omfång läggs till i en hubbinstans. Ohanterade omfång (där Cost Management-exporter konfigureras manuellt) kräver ingen konfiguration i hubbar.

1. Utlösaren config_SettingsUpdated körs när settings.json-filen uppdateras.
2. Den config_ConfigureExports pipelinen skapar nya exporter för alla nya omfång som har lagts till.

Datainmatning för v0.6

Datainmatning kan delas upp i två delar:

1. Exporter överför data till lagring.
2. Hubbar bearbetar och matar in data.

För hanterade omfång utför hubbar följande steg:

1. Config_DailySchedule och config_MonthlySchedule körs enligt sina respektive scheman för att starta datainmatning.
2. Den config_StartExportProcess pipelinen hämtar tillämpliga exporter för det schema som körs.
3. Den config_RunExportJobs pipelinen kör var och en av de valda exporterna.
4. Cost Management exporterar information om råa kostnader till containern msexports . Läs mer.
5. Den msexports_ExecuteETL pipeline köar extract-transform-load (ETL)-pipeline när filer läggs till i msexports behållare.
6. Den msexports_ETL_ingestion-pipelin omvandlar data till parquet-format och flyttar dem till inmatningscontainern med hjälp av en skalbar filstruktur. Läs mer.
7. Power BI eller andra verktyg läser data från inmatningscontainern .

När exporter körs, oavsett om de är hanterade eller ohanterade, genomför hubbar följande steg:

1. Den msexports_ExecuteETL pipelinen startar ETL-processen (extract-transform-load) när filer läggs till i lagringen.
2. Den msexports_ETL_ingestion-pipelin omvandlar data till parquet-format och flyttar dem till inmatningscontainern med hjälp av en skalbar filstruktur. Läs mer.
3. Power BI eller andra verktyg läser data från inmatningscontainern .

Om inmatning i v0.6

FinOps-hubbar förlitar sig på en specifik mappsökväg och filnamnsformat i inmatning container:

ingestion/{dataset}/{date-folder-path}/{scope-id-path}/{ingestion-id}__{original-file-name}.parquet

• ingestion är containern där datapipelinen sparar data.
• {dataset} är den exporterade datamängdstypen.
• {date-folder-path} kan vara en eller flera mappar som anger hur många inmatade datauppsättningar som ska behållas. Exempel:
  • all (eller någon platshållare) för att inte spåra historik för datasetet. Varje inmatning ersätter tidigare data. Stöds inte i lagringsbaserade Power BI-rapporter.
  • {yyyy} som ett fyrsiffrigt år för den exporterade datamängden för att endast behålla den senaste inmatningen per år. Stöds inte i lagringsbaserade Power BI-rapporter.
  • {yyyy}/{mm} som ett fyrsiffrigt år och en tvåsiffrig månad för den exporterade datamängden för att behålla den senaste inmatningen per månad.
  • {yyyy}/{mm}/{dd} som ett fyrsiffrigt år, en tvåsiffrig månad och en tvåsiffrig dag för den exporterade datamängden för att behålla den senaste inmatningen per dag. Stöds inte i lagringsbaserade Power BI-rapporter.
• {scope-id-path} är det fullständigt kvalificerade resurs-ID:t för det omfång som data kommer från. Om du matar in icke-Azure-data rekommenderar vi att du använder en logisk hierarki baserat på dataomfånget (till exempel "aws/{account-id}", "gcp/{project-name}", "oci/{component-id}/{component-id}").
• {ingestion-id} är ett unikt ID för den inmatade datamängden. Det här ID:t kan vara ett GUID, en tidsstämpel eller valfritt värde så länge det är konsekvent i alla filer för den inmatade datamängden. Det här värdet används för att ta bort tidigare inmatade data i samma mappsökväg.
• {original-file-name} är avsett att vara det ursprungliga filnamnet eller annan identifierare som anger var data i filen har sitt ursprung. Det här värdet är endast i felsökningssyfte.

Den fullständiga mappsökvägen och inmatnings-ID:t används båda för att säkerställa att data inte dupliceras i lagring eller i Azure Data Explorer. Det ursprungliga filnamnet läggs till i Azure Data Explorer-omfattningar i felsökningssyfte, men spåras eller används inte på annat sätt av FinOps-hubbar.

Om du behöver använda hubbar för att övervaka icke-Azure-data konverterar du data till FOCUS- och släpper dem i inmatning container med hjälp av den här vägledningen. Observera att stöd för icke-Azure-data inte uttryckligen har testats i den senaste versionen. Om du får problem, rapporterar du ett problem.

Om export i version 0.6

FinOps-hubbar använder Cost Management-exporter för att hämta kostnadsdata. Cost Management styr mappstrukturen för exporterade data i containern msexports . En typisk sökväg ser ut så här:

{container}/{path}/{date-range}/{export-name}/{export-time}/{guid}/{file}

Från och med 0.4 förlitar sig FinOps-hubbar inte på filsökvägar. Hubbar använder manifestfilen för att identifiera omfång, datauppsättning, månad osv. Den enda viktiga delen av sökvägen för hubbar är containern, som måste vara msexports.

Exportmanifest kan ändras med API-versioner. Här är ett exempel med API-version 2023-07-01-preview:

{
  "exportConfig": {
    "exportName": "<export-name>",
    "resourceId": "/<scope>/providers/Microsoft.CostManagement/exports/<export-name>",
    "dataVersion": "<dataset-version>",
    "apiVersion": "<api-version>",
    "type": "<dataset-type>",
    "timeFrame": "OneTime|TheLastMonth|MonthToDate",
    "granularity": "Daily"
  },
  "deliveryConfig": {
    "partitionData": true,
    "dataOverwriteBehavior": "CreateNewReport|OverwritePreviousReport",
    "fileFormat": "Csv",
    "containerUri": "<storage-resource-id>",
    "rootFolderPath": "<path>"
  },
  "runInfo": {
    "executionType": "Scheduled",
    "submittedTime": "2024-02-03T18:33:03.1032074Z",
    "runId": "af754a8e-30fc-4ef3-bfc6-71bd1efb8598",
    "startDate": "2024-01-01T00:00:00",
    "endDate": "2024-01-31T00:00:00"
  },
  "blobs": [
    {
      "blobName": "<path>/<export-name>/<date-range>/<export-time>/<guid>/<file-name>.<file-type>",
      "byteCount": ###
    }
  ]
}

FinOps-hubbar använder följande egenskaper:

• exportConfig.resourceId för att identifiera omfånget.
• exportConfig.type för att identifiera datamängdstypen.
• exportConfig.dataVersion för att identifiera datamängdsversionen.
• runInfo.startDate för att identifiera den exporterade månaden.

FinOps-hubbar stöder följande datauppsättningstyper, versioner och API-versioner:

• FocusCost: 1.0, 1.0-preview(v1)
• Prisdokument: 2023-05-01
• Reserveringsdetaljer: 2023-03-01
• Bokningsrekommendationer: 2023-05-01
• Reservationstransaktioner: 2023-05-01
• API-versioner: 2023-07-01-preview

FinOps Hubs v0.4-0.5

Följande information beskriver hur data bearbetas i FinOps Hubs v0.4 och v0.5.

Omfångskonfiguration i v0.4-0.5

1. Utlösaren config_SettingsUpdated körs när settings.json-filen uppdateras.
2. Den config_ConfigureExports pipelinen skapar nya exporter för alla nya omfång som har lagts till.

Datainmatning för v0.4-0.5

För hanterade omfång:

1. Config_DailySchedule och config_MonthlySchedule körs enligt sina respektive scheman för att starta datainmatning.
2. Den config_ExportData pipelinen hämtar tillämpliga exporter för det schema som körs.
3. Den config_RunExports pipelinen kör var och en av de valda exporterna.
4. Cost Management exporterar information om råa kostnader till containern msexports . Mer information finns i Om exporter i v04-05.

När exporten har slutförts för både hanterade och ohanterade omfång:

1. Den msexports_ExecuteETL pipelinen startar ETL-processen (extract-transform-load) när filer läggs till i lagringen.
2. Den msexports_ETL_ingestion pipeline omvandlar data till ett standardschema och sparar rådata i parquet-formatet till ingestioncontainern. För mer information, se Om inmatning i v04-05.
3. Power BI läser kostnadsdata från inmatningscontainern .

Om inmatning i v0.4-0.5

FinOps-hubbar förlitar sig på en specifik mappsökväg i inmatningscontainern :

ingestion/{dataset}/{yyyy}/{mm}/{scope-id}

• ingestion är containern där datapipelinen sparar data.
• {dataset} är den exporterade datamängdstypen.
• {month} är året och månaden för exporterade data formaterade som yyyyMM.
• {scope-id} förväntas vara det fullständigt kvalificerade resurs-ID:t för det omfång som data kommer från.

Om du behöver använda hubbar för att övervaka data som inte är Azure konverterar du data till FOCUS och släpper dem i inmatningscontainern . Den här processen testades inte uttryckligen i den senaste versionen. Om du får problem, rapporterar du ett problem.

Om exporterna i v0.4-0.5

FinOps-hubbar använder Cost Management-exporter för att hämta kostnadsdata. Cost Management styr mappstrukturen för exporterade data i containern msexports . En typisk sökväg ser ut så här:

{container}/{path}/{date-range}/{export-name}/{export-time}/{guid}/{file}

Från och med 0.4 förlitar sig FinOps-hubbar inte på filsökvägar. Hubbar använder manifestfilen för att identifiera omfång, datauppsättning, månad och så vidare. Den enda viktiga delen av sökvägen för hubbar är containern, som måste vara msexports.

Exportmanifest kan ändras med API-versioner. Här är ett exempel med API-version 2023-07-01-preview:

{
  "exportConfig": {
    "exportName": "<export-name>",
    "resourceId": "/<scope>/providers/Microsoft.CostManagement/exports/<export-name>",
    "dataVersion": "<dataset-version>",
    "apiVersion": "<api-version>",
    "type": "<dataset-type>",
    "timeFrame": "OneTime|TheLastMonth|MonthToDate",
    "granularity": "Daily"
  },
  "deliveryConfig": {
    "partitionData": true,
    "dataOverwriteBehavior": "CreateNewReport|OverwritePreviousReport",
    "fileFormat": "Csv",
    "containerUri": "<storage-resource-id>",
    "rootFolderPath": "<path>"
  },
  "runInfo": {
    "executionType": "Scheduled",
    "submittedTime": "2024-02-03T18:33:03.1032074Z",
    "runId": "af754a8e-30fc-4ef3-bfc6-71bd1efb8598",
    "startDate": "2024-01-01T00:00:00",
    "endDate": "2024-01-31T00:00:00"
  },
  "blobs": [
    {
      "blobName": "<path>/<export-name>/<date-range>/<export-time>/<guid>/<file-name>.csv",
      "byteCount": ###
    }
  ]
}

FinOps-hubbar använder följande egenskaper:

• exportConfig.resourceId för att identifiera omfånget.
• exportConfig.type för att identifiera datamängdstypen.
• exportConfig.dataVersion för att identifiera datamängdsversionen.
• runInfo.startDate för att identifiera den exporterade månaden.

FinOps-hubbar stöder följande datauppsättningstyper, versioner och API-versioner:

• FocusCost: 1.0, 1.0-preview(v1)
• Prisdokument: 2023-05-01
• Reserveringsdetaljer: 2023-03-01
• Bokningsrekommendationer: 2023-05-01
• Reservationstransaktioner: 2023-05-01
• API-versioner: 2023-07-01-preview

FinOps Hubs v0.2-0.3

Följande steg beskriver processen för att exportera och bearbeta kostnadsdata med hjälp av FinOps Hubs-versionerna 0.2-0.3:

1. Cost Management exporterar information om råa kostnader till containern msexports .
2. Den msexports_ExecuteETL pipelinen startar ETL-processen (extract-transform-load) när filer läggs till i lagringen.
3. Den msexports_ETL_ingestion pipelinen sparar exporterade data i parquet-format i inmatningscontainern .
4. Power BI läser kostnadsdata från inmatningscontainern .

FinOps Hubs 0.2-0.3 använder exportsökvägen för att fastställa det exporterade omfånget och månaden. Den här punkten är viktig eftersom uppdateringar av sökvägen kan bryta datapipelinesystemet. För att undvika det här problemet rekommenderar vi att du uppdaterar till FinOps Hubs 0.4. Den förväntade sökvägen bör efterlikna:

msexports/{scope-id}/{export-name}/{date-range}/{export-time}/{guid}/{file}

• msexports är containern som anges vid exporten.
• {scope-id} är mappsökvägen som anges vid exporten.

  Hubbar version 0.3 och tidigare använder detta för att identifiera vilket omfång som datan kommer ifrån. Vi rekommenderar att du använder omfångs-ID:t, men alla värden kan användas. Exempel på omfattnings-ID:n är:

  Omfattningstyp	Exempelvärde
  Prenumeration	/subscriptions/###
  Resursgrupp	/subscriptions/###/resourceGroups/###
  Faktureringskonto	/providers/Microsoft.Billing/billingAccounts/###
  Faktureringsprofil	/providers/Microsoft.Billing/billingAccounts/###/billingProfiles/###

• {export-name} är namnet på exporten.

  Hubbar ignorerar den här mappen.

• {date-range} är datumintervalldata som exporteras.

  Hubbar 0.3 och tidigare använder detta för att identifiera månaden. Formatet för den här mappen är yyyyMMdd-yyyyMMdd. Hubs 0.4 använder manifestet i stället.

• {export-time} är en tidsstämpel för när exporten kördes.

  Hubbar ignorerar detta. Formatet för den här mappen är yyyyMMddHHmm.

• {guid} är ett unikt GUID och finns inte alltid.

  Hubbar ignorerar detta. Cost Management inkluderar inte alltid den här mappen. Om den ingår eller inte beror på vilken API-version som används för att skapa exporten.

• {file} är antingen ett manifest eller exporterade data.

  Version 0.3 och tidigare ignorerar manifestfiler och övervakar endast *.csv filer. I en framtida version övervakar hubbar manifestet.

FinOps Hubs v0.1

Följande steg beskriver processen för att exportera och bearbeta kostnadsdata med FinOps Hubs version 0.1:

1. Cost Management exporterar information om råa kostnader till containern msexports .
2. Den msexports_transform pipelinen sparar rådata i parquet-format till inmatningscontainern .
3. Power BI läser kostnadsdata från inmatningscontainern .

Lämna feedback

Låt oss veta hur det går med en snabb granskning. Vi använder dessa granskningar för att förbättra och utöka FinOps-verktyg och -resurser.

Om du letar efter något specifikt kan du rösta på en befintlig eller skapa en ny idé. Dela idéer med andra för att få fler röster. Vi fokuserar på idéer med flest röster.

Relaterat innehåll

• Distribuera FinOps-hubbar
• Läs mer