Delen via

Hoe gegevens worden verwerkt in FinOps-hubs

FinOps-hubs voeren veel gegevensverwerkingsactiviteiten uit om gegevens op te schonen, te normaliseren en te optimaliseren. In de volgende secties ziet u hoe gegevens van Cost Management naar een hub-exemplaar stromen.


Bereik instellen

Een bereik is een niveau binnen de cloudresource- en accounthiërarchie die toegang biedt tot kosten, gebruik en koolstofgegevens. Voor FinOps-hubs raden we doorgaans aan om factureringsaccounts van Enterprise Overeenkomst (EA) of Microsoft-klantovereenkomst (MCA) te gebruiken, maar elk cloudbereik is voldoende voor basisanalyse. De belangrijkste zorg is of prijs- en reserveringsgegevens nodig zijn, omdat Cost Management alleen de gegevens voor EA-factureringsaccounts en MCA-factureringsprofielen beschikbaar maakt.

FinOps-hubs ondersteunen het configureren van bereiken door cost management-exports handmatig te configureren of door FinOps-hubs namens u toegang te verlenen tot het beheren van bereiken. Beheerde scopes worden geconfigureerd in het config/settings.json-bestand in de opslag van de hub. In de informatie wordt beschreven wat er gebeurt wanneer een nieuw, beheerd bereik wordt toegevoegd aan dit bestand. Niet-beheerde bereiken, waarbij Cost Management-exports handmatig zijn geconfigureerd, vereisen geen andere installatie.

Het diagram toont het proces voor het instellen van de scope.

  1. De config_SettingsUpdated-trigger wordt uitgevoerd wanneer het settings.json-bestand wordt bijgewerkt.
  2. Met de config_ConfigureExports-pijplijn worden nieuwe exports gemaakt voor nieuwe bereiken die zijn toegevoegd.

Gegevensopname

In het volgende diagram ziet u het end-to-end gegevensopnameproces in FinOps-hubs:

Diagram met het gegevensopnameproces.

  1. (Optioneel) Als u beheerde exports gebruikt:
    1. De config_DailySchedule - en config_MonthlySchedule-triggers worden volgens hun respectieve planningen uitgevoerd om gegevensopname te starten.
    2. De config_StartExportProcess-pijplijn haalt de toepasselijke exports op voor het schema dat wordt uitgevoerd.
    3. De config_RunExportJobs-pijplijn voert elk van de geselecteerde exports uit.
  2. Cost Management exporteert onbewerkte kostendetails naar de msexports-container . Meer informatie.
  3. De msexports_ExecuteETL pijplijn plaatst de extract-transform-load (ETL) pijplijn in de wachtrij wanneer bestanden worden toegevoegd aan de msexports container.
  4. De msexports_ETL_ingestion pijplijn transformeert de gegevens naar parquet-indeling en verplaatst deze naar de ingestion container met behulp van een schaalbare bestandsstructuur. Meer informatie.
  5. (Optioneel) Als u Azure Data Explorer gebruikt:
    1. De ingestion_ExecuteETL-pijplijn plaatst de Data Explorer-ingestiepijplijn in de wachtrij wanneer er manifest.json bestanden worden toegevoegd aan de ingestiecontainer.
      • Als u aangepaste gegevenssets buiten Cost Management-exports opneemt, maakt u een leeg manifest.json-bestand in de doelopnamemap nadat alle andere bestanden gereed zijn (voeg dit bestand niet toe wanneer bestanden nog steeds worden geüpload). Het manifest.json bestand is niet geparseerd en kan leeg zijn. Het enige doel is om aan te geven dat alle bestanden voor deze opnametaak worden toegevoegd.
    2. De ingestion_ETL_dataExplorer pijplijn neemt gegevens op in de {dataset}_raw tabel in Data Explorer.
      • De naam van de gegevensset is de eerste map in de opnamecontainer .
      • Alle onbewerkte tabellen bevinden zich in de opnamedatabase in Data Explorer.
    3. Wanneer gegevens worden opgenomen in onbewerkte tabellen in Data Explorer, kopieert een updatebeleid de gegevens naar de bijbehorende {dataset}_final_v1_0 tabel met behulp van de {dataset}_transform_v1_0() functie om alle gegevens te normaliseren om uit te lijnen op FOCUS 1.0.
    4. Na opname voert de ingestion_ETL_dataExplorer pijplijn een aantal opschoning uit, waaronder het opschonen van gegevens in de laatste tabel die voorbij de gegevensretentieperiode valt.
      • Vanaf 0.7 past Data Explorer gegevensretentie toe in onbewerkte tabellen terwijl gegevensretentie in uiteindelijke tabellen wordt toegepast door de opnamepijplijn. Als gegevensopname stopt, worden historische gegevens niet opgeschoond.
      • Gegevensretentie kan worden geconfigureerd tijdens de sjabloonimplementatie of handmatig in het configuratie-/settings.json-bestand in de opslag.
  6. Rapporten en andere hulpprogramma's, zoals Power BI, lezen gegevens uit Data Explorer of de opnamecontainer .
    • Gegevens in Data Explorer kunnen worden gelezen uit de Hub-database .
      • Gebruik de {dataset}() functie om het meest recente schema te gebruiken.
        • Deze functie is handig voor snelle verkenning, maar kan belangrijke wijzigingen veroorzaken wanneer het FinOps-hubexemplaren worden bijgewerkt.
      • Gebruik de {dataset}_v1_0() functie om het FOCUS 1.0-schema te gebruiken.
        • Versiegeschiedenisschema's mogen na verloop van tijd niet worden gewijzigd, maar waarden kunnen veranderen als de gegevensbron de waarden wijzigt.
      • Vermijd het gebruik van de opnamedatabase voor query's. Hoewel dit niet expliciet is verboden, moet de opnamedatabase worden beschouwd als een intern gebied voor fasering en gegevensvoorbereiding.
    • Gegevens in opslag kunnen worden gelezen uit ingestion/<dataset>/<year>/<month>/<scope-path>.
      • Gegevens moeten recursief worden gelezen uit de map van de gegevensset en eventueel meer gegevens opnemen als dat nodig is voor specificiteit.
      • Bestanden in elke gegevenssetmap kunnen verschillende schema's hebben op basis van het gegevensbron- en accounttype. Wees voorbereid om gegevens te transformeren als ze worden opgenomen in andere systemen, zoals Microsoft Fabric.
      • Lezen vanuit opslag wordt afgeraden wegens prestatieoverwegingen. Data Explorer wordt aanbevolen bij het rapporteren van meer dan $ 1 miljoen aan kosten.

Gegevensinvoer in Data Explorer

Wanneer gegevens worden opgenomen in Data Explorer, passen de {dataset}_transform_v1_0() functies transformatieregels toe in de opnamedatabase . Elke gegevensset heeft een andere set transformatieregels die in de volgende secties worden behandeld.

Zie het probleem #1111 voor een lijst met aangevraagde wijzigingen, ideeën die worden overwogen en open vragen over de onderliggende Cost Management-gegevenssets. Laat opmerkingen over dit probleem achter als u mogelijkheden vindt om problemen op te lossen of om uw ondersteuning voor een van de specifieke problemen te laten horen.

Transformaties van kostengegevens

Ondersteunde gegevenssets:

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

De volgende gegevenssets zijn in het ontwerp opgenomen, maar worden niet systeemeigen ondersteund. Als u deze gegevenssets wilt opnemen, maakt u een gegevenspijplijn (of extern proces) waarmee parquet-bestanden naar de ingestion/Costs/yyyy/mm/{scope-path} map in de opslag worden gepusht. Het {scope-path} kan elk uniek pad zijn, zoals aws/123 of gcp/projects/foo. De enige vereiste is ervoor te zorgen dat elke scope zich in een aparte map bevindt. Nadat u externe inhoud hebt gekopieerd, maakt u ook een manifest.json-bestand om data explorer-opname te activeren.

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

Transformeert:

  • v0.7+:
    • Focus 1.0-preview kolomnamen afstemmen met FOCUS 1.0.
      • Omvat het converteren van FOCUS 1.0 preview naar 1.0.
    • Voeg x_IngestionTime toe om aan te geven wanneer de rij voor het laatst is bijgewerkt.
    • Voeg x_SourceChanges toe om te bepalen wanneer gegevens in een rij worden gewijzigd door hubs.
    • Bijwerken ProviderName en PublisherName wanneer dit niet is opgegeven.
    • Voeg x_SourceName, x_SourceProvider, x_SourceTypeen x_SourceVersion om de oorspronkelijke opgenomen gegevensset te identificeren.
    • Vul ontbrekende ListCost, ListUnitPrice, ContractedCost, en ContractedUnitPrice waarden in op basis van het prijzenoverzicht.
      • Voor dit proces moeten prijzen vóór de kosten worden geëxporteerd. Prijzen ontbreken voor de eerste dag van de maand als de kosten worden verwerkt voordat de prijzen beschikbaar zijn voor de maand.
    • Herstel ContractedCost wanneer het onjuist is ingesteld door een bug in Cost Management.
    • Verander ResourceName en x_ResourceGroupName in kleine letters om problemen met hoofdlettergebruikconsistentie op te lossen die het groeperen en filteren beïnvloeden.
    • Toevoegen x_BillingAccountAgreement op basis van het accounttype.
  • v0.8+:
    • Corrigeer waarden ResourceType die gebruikmaken van interne resourcetype-id's (bijvoorbeeld microsoft.compute/virtualmachines).
  • v0.9+:
    • Verklein BillingAccountId om ervoor te zorgen dat de prijskoppeling overeenkomt met alle rijen.
    • Kleine letters CommitmentDiscountId om dubbele rijen te voorkomen bij het samenvoegen van gegevens.
    • Voeg nieuwe x_SourceChanges controles toe voor ListCostLessThanContractedCost en ContractedCostLessThanEffectiveCost.
  • v0.10+:
    • Herstel x_EffectiveUnitPrice wanneer het berekend wordt en er een afrondingsfout is ten opzichte van x_BilledUnitPrice of ContractedUnitPrice.
    • Bereken de prijshoeveelheid en verbruikte hoeveelheid wanneer er kosten zijn maar geen hoeveelheid.
    • Ingesteld ContractedCost op EffectiveCost wanneer deze niet is ingesteld.
    • Ingesteld ListCost op ContractedCost wanneer deze niet is ingesteld.
    • Verwijder '-2' in de x_InvoiceSectionId kolom.
    • Verwijder 'Niet toegewezen' in de x_InvoiceSectionName kolom.
    • x_EffectiveUnitPrice Gecorrigeerd wanneer deze wordt berekend en een afrondingsfout heeft.
    • Voeg nieuwe x_SourceChanges controles toe voor MissingConsumedQuantity, MissingPricingQuantityen XEffectiveUnitPriceRoundingError.
  • v0.11+:
    • Wijzig BillingPeriodStart en BillingPeriodEnd naar de eerste van de maand.

Prijsgegevenstransformaties

Ondersteunde gegevenssets:

  • Microsoft Prijslijst: 2023-05-01 (EA en MCA)

Transformeert:

  • v0.7+
    • Kolomnamen uitlijnen op FOCUS 1.0.
      • Omvat het afdwingen van de consistentie van EA- en MCA-kolomnamen.
      • Wijzigt de onderliggende waarden niet, wat kan verschillen tussen EA en MCA.
    • Converteer x_SkuTerm ISO-duur naar het specifieke aantal maanden om aan de kostendetails te voldoen.
      • We wachten op FOCUS om te bepalen hoe u de duur definieert voordat u deze waarde wijzigt in ISO of een andere indeling.
    • Vervang ContractedUnitPrice voor besparingsplangebruik door het equivalent op aanvraag.
    • Ingesteld ListUnitPrice op besparingsplangebruik ingesteld op het equivalent op aanvraag.
    • Voeg SkuPriceIdv2 als een nauwkeurigere SkuPriceId waarde toe dan wat momenteel in kostendetails staat.
    • Voeg x_IngestionTime toe om aan te geven wanneer de rij voor het laatst is bijgewerkt.
    • Toevoegen x_CommitmentDiscountSpendEligibility en x_CommitmentDiscountUsageEligibility.
    • Uitvouwen x_PricingUnitDescription in PricingUnit en x_PricingBlockSize.
    • Toevoegen x_BillingAccountAgreement op basis van het accounttype.
    • Verander x_EffectivePeriodEnd naar een exclusieve einddatum.
    • Voeg x_EffectiveUnitPriceDiscount, x_ContractedUnitPriceDiscounten x_TotalUnitPriceDiscount samen om beschikbare kortingen per SKU samen te vatten.
    • Voeg x_EffectiveUnitPriceDiscountPercent, x_ContractedUnitPriceDiscountPercenten x_TotalUnitPriceDiscountPercent samen om het percentage van de korting per SKU samen te vatten.
    • Voeg x_SourceName, x_SourceProvider, x_SourceTypeen x_SourceVersion om de oorspronkelijke opgenomen gegevensset te identificeren.
  • v0.9+:
    • Zet BillingAccountId in kleine letters om ervoor te zorgen dat de cost join overeenkomt met alle rijen.

Transformaties van aanbevelingsgegevens

Ondersteunde gegevenssets:

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

Transformeert:

  1. Kolomnamen uitlijnen op FOCUS 1.0.
    • Omvat het afdwingen van de consistentie van EA- en MCA-kolomnamen.
    • Wijzigt de onderliggende waarden niet, wat kan verschillen tussen EA en MCA.
  2. Voeg x_SourceName, x_SourceProvider, x_SourceTypeen x_SourceVersion om de oorspronkelijke opgenomen gegevensset te identificeren.

Transformaties van transactiegegevens

Ondersteunde gegevenssets:

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

Transformeert:

  1. Kolomnamen uitlijnen op FOCUS 1.0.
    • Omvat het afdwingen van de consistentie van EA- en MCA-kolomnamen.
    • Wijzigt de onderliggende waarden niet, wat kan verschillen tussen EA en MCA.
  2. Voeg x_SourceName, x_SourceProvider, x_SourceTypeen x_SourceVersion om de oorspronkelijke opgenomen gegevensset te identificeren.

Transformaties van toezeggingskortingsgebruiksgegevens

Ondersteunde gegevenssets:

  • Microsoft ReservationDetails: 2023-03-01 (EA en MCA)

Transformeert:

  1. Kolomnamen uitlijnen op FOCUS 1.0.
    • Omvat het afdwingen van de consistentie van EA- en MCA-kolomnamen.
    • Wijzigt de onderliggende waarden niet, wat kan verschillen tussen EA en MCA.
  2. Voeg een kolom toe ResourceType met de weergavenaam van het resourcetype.
  3. Kolommen toevoegen ServiceName, ServiceCategorytoevoegen en x_ServiceModel kolommen.
  4. Vervang 'NA' door null voor x_CommitmentDiscountNormalizedGroup.
  5. Toevoegen x_CommitmentDiscountQuantity op basis van FOCUS 1.1.

Over de opnamecontainer

FinOps-hubs zijn afhankelijk van een specifiek mappad en een bestandsindeling in de opslagcontainer voor opname :

ingestion/{dataset}/{date-folder-path}/{scope-id-path}/{ingestion-id}__{original-file-name}.parquet
  • ingestion is de container waarin de gegevenspijplijn gegevens opslaat.
  • {dataset} is het geëxporteerde gegevenssettype. Als u gegevens opneemt in Azure Data Explorer, moet de opnamedatabase een overeenkomende, hoofdlettergevoelige tabel '_raw' hebben (bijvoorbeeld 'Costs_raw'). FinOps-hubs ondersteunen de volgende gegevenssets in deze release:
    • CommitmentDiscountUsage - Export van reserveringsgegevens van Cost Management.
    • Kosten - FOCUS kosten en gebruiksgegevens.
    • Prijzen - Prijzenoverzichten van Cost Management exporteren.
    • Aanbevelingen : export van aanbevelingen voor Cost Management-reserveringen.
    • Transacties - Kostenbeheer reserveringstransacties exporteren.
    • Als u aangepaste gegevenssets wilt opnemen, maakt u een overeenkomende {dataset}_raw tabel en parquet-opnametoewijzing in de opnamedatabase .
  • {date-folder-path} kan een of meer mappen zijn die aangeven hoeveel opgenomen gegevenssets moeten worden bewaard. Voorbeelden:
    • all (of een tijdelijke aanduiding) om de geschiedenis voor de gegevensset niet bij te houden. Elke gegevensinvoer vervangt de vorige gegevens. Niet ondersteund in Power BI-rapporten op basis van opslag.
    • {yyyy} als een viercijferig jaartal van de geëxporteerde gegevensset om alleen de meest recente ingestie per jaar te behouden. Niet ondersteund in Power BI-rapporten op basis van opslag.
    • {yyyy}/{mm} als een viercijferig jaar en een tweecijferige maand van de geëxporteerde gegevensset om de recentste opname per maand te behouden.
    • {yyyy}/{mm}/{dd} als viercijferige jaar, tweecijferige maand en tweecijferige dag van de geëxporteerde gegevensset om de meest recente opname per dag te behouden. Niet ondersteund in Power BI-rapporten op basis van opslag.
  • {scope-id-path} is de volledig gekwalificeerde resource-id van het bereik waaruit de gegevens afkomstig zijn. Als u niet-Azure-gegevens opneemt, wordt u aangeraden een logische hiërarchie te gebruiken op basis van het bereik van gegevens (bijvoorbeeld aws/{account-id}, gcp/{project-name}). oci/{component-id}/{component-id}
  • {ingestion-id} is een unieke id voor de opgenomen gegevensset. Deze id kan een GUID, een tijdstempel of een waarde zijn zolang deze consistent is in alle bestanden voor de opgenomen gegevensset. Deze waarde wordt gebruikt om eerder opgenomen gegevens in hetzelfde mappad te verwijderen.
  • {original-file-name} is bedoeld als de oorspronkelijke bestandsnaam of een andere id om aan te geven waar de gegevens in het bestand vandaan komen. Deze waarde is alleen voor uw probleemoplossingsdoeleinden.

Het volledige mappad en de ingestie-ID worden beide gebruikt om ervoor te zorgen dat gegevens niet worden gedupliceerd in de opslag of in Azure Data Explorer. De oorspronkelijke bestandsnaam wordt toegevoegd aan Azure Data Explorer-gebieden voor probleemoplossing, maar wordt anders niet bijgehouden of gebruikt door FinOps-hubs.

Als u hubs wilt gebruiken om niet-Azure-gegevens te bewaken, converteert u de gegevens naar FOCUS en zet u deze neer in de opnamecontainer met behulp van deze richtlijnen. Ondersteuning voor niet-Azure-gegevens is niet expliciet getest in de nieuwste versie. Als u problemen ondervindt, meld een probleem.


Over exporten

FinOps-hubs maken gebruik van Cost Management-exports om kostengegevens te verkrijgen. Cost Management bepaalt de mapstructuur voor de geëxporteerde gegevens in de opslagcontainer msexports . Een typisch pad ziet er als volgt uit:

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

FinOps-hubs maken gebruik van het manifestbestand om het bereik, de gegevensset, de maand, enzovoort te identificeren. Het enige belangrijke deel van het pad voor hubs is de container, die msexports moet zijn.

Exporteer geen gegevens naar de opnamecontainer . Geëxporteerde CSV's moeten worden gepubliceerd naar de msexports-container die moet worden verwerkt door de hubs-engine.

Als u aangepaste gegevens wilt opnemen, slaat u parquet-bestanden op in de opnamecontainer voor de Power BI-rapporten van de FinOps-toolkit zodat deze naar verwachting werken. Nadat alle Parquet-bestanden zijn toegevoegd, voegt u een leeg manifest.json-bestand toe om de opname te starten.

Als u CSV-bestand wilt opnemen uit Cost Management-exports, slaat u bestanden op in een specifieke map in de container msexports . Nadat alle bestanden zijn toegevoegd, voegt u een manifest.json-bestand toe op basis van de onderstaande sjabloon. Breng de volgende wijzigingen aan om ervoor te zorgen dat de opname is geslaagd:

  1. Ga naar <export-name> een unieke waarde binnen het bereik van de gegevensset die u opneemt.
    • Dit wordt alleen gebruikt voor aanbevelingen om onderscheid te maken tussen de vele verschillende typen aanbevelingen die worden opgenomen, die alleen niet kunnen worden geïdentificeerd vanuit het exportmanifest. Voor reserveringsaanbevelingen is het ideaal om de service, het bereik (enkel/gedeeld) en de lookbackperiode op te nemen.
  2. Verander <dataset> en <version> naar het exporttype en de versie van Cost Management. Zie de onderstaande lijst voor ondersteunde gegevenssets.
  3. Wijzig <scope> in de Azure-resource-id voor het bereik waar de gegevens vandaan kwamen.
  4. Verander <guid> naar een unieke GUID.
  5. Ga naar <yyyy-MM> het jaar en de maand van de gegevensset.
  6. Verander <path-to-file> naar het volledige mappad onder de container, zonder 'msexports'.
  7. Wijzig <file-name> naar de naam van het eerste bestand dat naar de opslag is geüpload.
  8. Als u meer dan één CSV-bestand hebt, kopieert u het blobobject voor elk bestand dat u hebt geüpload en werkt u de bestandsnaam bij.
{
  "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-hubs ondersteunen de volgende typen gegevenssets, versies en API-versies:

  • FocusCost: 1.0r2, 1.01.0-preview(v1)
  • Prijzenoverzicht: 2023-05-01
  • Reserveringsdetails: 2023-03-01
  • Reserveringsaanbevelingen: 2023-05-01
  • ReservatieTransacties: 2023-05-01
  • API-versies: 2023-07-01-preview

FinOps-hubs v0.6

In de volgende secties wordt uitgelegd hoe gegevens worden verwerkt in FinOps-hubs 0.6.

Scope instellen in v0.6

De volgende stappen worden uitgevoerd wanneer een nieuw, beheerd bereik wordt toegevoegd aan een hub-exemplaar. Niet-beheerde bereiken (waarbij Cost Management-exports handmatig zijn geconfigureerd) vereisen geen installatie in hubs.

  1. De config_SettingsUpdated-trigger wordt uitgevoerd wanneer het settings.json-bestand wordt bijgewerkt.
  2. Met de config_ConfigureExports-pijplijn worden nieuwe exports gemaakt voor nieuwe bereiken die zijn toegevoegd.

Gegevensopname in v0.6

Gegevensopname kan in twee delen worden onderverdeeld:

  1. Hiermee exporteert u pushgegevens naar de opslag.
  2. Hubs verwerkt en neemt gegevens op.

Voor beheerde reikwijdten voeren hubs de volgende stappen uit:

  1. De config_DailySchedule - en config_MonthlySchedule-triggers worden volgens hun respectieve planningen uitgevoerd om gegevensopname te starten.
  2. De config_StartExportProcess-pijplijn haalt de toepasselijke exports op voor het schema dat wordt uitgevoerd.
  3. De config_RunExportJobs-pijplijn voert elk van de geselecteerde exports uit.
  4. Cost Management exporteert onbewerkte kostendetails naar de msexports-container . Meer informatie.
  5. De msexports_ExecuteETL pijplijn plaatst de extract-transform-load (ETL) pijplijn in de wachtrij wanneer bestanden worden toegevoegd aan de msexports container.
  6. De msexports_ETL_ingestion pijplijn transformeert de gegevens naar parquet-indeling en verplaatst deze naar de ingestion container met behulp van een schaalbare bestandsstructuur. Meer informatie.
  7. Power BI of andere hulpprogramma's lezen gegevens uit de opnamecontainer .

Nadat exports zijn uitgevoerd, of het nu beheerde of onbeheerde is, voeren hubs de volgende stappen uit:

  1. De msexports_ExecuteETL-pijplijn start het ETL-proces (extract-transform-load) wanneer bestanden worden toegevoegd aan de opslag.
  2. De msexports_ETL_ingestion pijplijn transformeert de gegevens naar parquet-indeling en verplaatst deze naar de ingestion container met behulp van een schaalbare bestandsstructuur. Meer informatie.
  3. Power BI of andere hulpprogramma's lezen gegevens uit de opnamecontainer .

Over opname in v0.6

FinOps-hubs zijn afhankelijk van een specifiek mappad en een bestandsindeling in de opnamecontainer :

ingestion/{dataset}/{date-folder-path}/{scope-id-path}/{ingestion-id}__{original-file-name}.parquet
  • ingestion is de container waarin de gegevenspijplijn gegevens opslaat.
  • {dataset} is het geëxporteerde gegevenssettype.
  • {date-folder-path} kan een of meer mappen zijn die aangeven hoeveel opgenomen gegevenssets moeten worden bewaard. Voorbeelden:
    • all (of een tijdelijke aanduiding) om de geschiedenis voor de gegevensset niet bij te houden. Elke gegevensinvoer vervangt de vorige gegevens. Niet ondersteund in Power BI-rapporten op basis van opslag.
    • {yyyy} als een viercijferig jaartal van de geëxporteerde gegevensset om alleen de meest recente ingestie per jaar te behouden. Niet ondersteund in Power BI-rapporten op basis van opslag.
    • {yyyy}/{mm} als een viercijferig jaar en een tweecijferige maand van de geëxporteerde gegevensset om de recentste opname per maand te behouden.
    • {yyyy}/{mm}/{dd} als viercijferige jaar, tweecijferige maand en tweecijferige dag van de geëxporteerde gegevensset om de meest recente opname per dag te behouden. Niet ondersteund in Power BI-rapporten op basis van opslag.
  • {scope-id-path} is de volledig gekwalificeerde resource-id van het bereik waaruit de gegevens afkomstig zijn. Als u niet-Azure-gegevens opneemt, wordt u aangeraden een logische hiërarchie te gebruiken op basis van het bereik van gegevens (bijvoorbeeld 'aws/{account-id}', 'gcp/{project-name}', 'oci/{component-id}/{component-id}').
  • {ingestion-id} is een unieke id voor de opgenomen gegevensset. Deze id kan een GUID, een tijdstempel of een waarde zijn zolang deze consistent is in alle bestanden voor de opgenomen gegevensset. Deze waarde wordt gebruikt om eerder opgenomen gegevens in hetzelfde mappad te verwijderen.
  • {original-file-name} is bedoeld als de oorspronkelijke bestandsnaam of een andere id om aan te geven waar de gegevens in het bestand vandaan komen. Deze waarde is alleen voor uw probleemoplossingsdoeleinden.

Het volledige mappad en de ingestie-ID worden beide gebruikt om ervoor te zorgen dat gegevens niet worden gedupliceerd in de opslag of in Azure Data Explorer. De oorspronkelijke bestandsnaam wordt toegevoegd aan Azure Data Explorer-gebieden voor probleemoplossing, maar wordt anders niet bijgehouden of gebruikt door FinOps-hubs.

Als u hubs wilt gebruiken om niet-Azure-gegevens te bewaken, converteert u de gegevens naar FOCUS en zet u deze neer in de opnamecontainer met behulp van deze richtlijnen. Ondersteuning voor niet-Azure-gegevens is niet expliciet getest in de nieuwste versie. Als u problemen ondervindt, meld een probleem.


Over de exports in versie 0.6

FinOps-hubs maken gebruik van Cost Management-exports om kostengegevens te verkrijgen. Cost Management bepaalt de mapstructuur voor de geëxporteerde gegevens in de container msexports . Een typisch pad ziet er als volgt uit:

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

Vanaf 0.4 zijn FinOps-hubs niet afhankelijk van bestandspaden. Hubs maken gebruik van het manifestbestand om het bereik, de gegevensset, de maand, enzovoort te identificeren. Het enige belangrijke deel van het pad voor hubs is de container, die msexports moet zijn.

Waarschuwing

  • Exporteer geen gegevens naar de opnamecontainer . Geëxporteerde CSV's moeten worden gepubliceerd naar de msexports-container die moet worden verwerkt door de hubs-engine.
  • Als u aangepaste gegevens wilt opnemen, sla dan FOCUS-uitgelijnde Parquet-bestanden op in de opnamecontainer zodat de Power BI-rapporten van de FinOps-toolkit naar verwachting werken.

Exportmanifesten kunnen worden gewijzigd met API-versies. Hier volgt een voorbeeld met API-versie 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-hubs gebruiken de volgende eigenschappen:

  • exportConfig.resourceId om het bereik te identificeren.
  • exportConfig.type om het gegevenssettype te identificeren.
  • exportConfig.dataVersion om de versie van de gegevensset te identificeren.
  • runInfo.startDate om de geëxporteerde maand te identificeren.

FinOps-hubs ondersteunen de volgende typen gegevenssets, versies en API-versies:

  • FocusCost: 1.0, 1.0-preview(v1)
  • Prijzenoverzicht: 2023-05-01
  • Reserveringsdetails: 2023-03-01
  • Reserveringsaanbevelingen: 2023-05-01
  • ReservatieTransacties: 2023-05-01
  • API-versies: 2023-07-01-preview

FinOps-hubs v0.4-0.5

In de volgende informatie wordt beschreven hoe gegevens worden verwerkt in FinOps-hubs v0.4 en v0.5.

Instellen van bereik in v0.4-0.5

  1. De config_SettingsUpdated-trigger wordt uitgevoerd wanneer het settings.json-bestand wordt bijgewerkt.
  2. Met de config_ConfigureExports-pijplijn worden nieuwe exports gemaakt voor nieuwe bereiken die zijn toegevoegd.

Gegevensopname in v0.4-0.5

Voor beheerde toepassingsgebieden:

  1. De config_DailySchedule - en config_MonthlySchedule-triggers worden volgens hun respectieve planningen uitgevoerd om gegevensopname te starten.
  2. De config_ExportData-pijplijn haalt de toepasselijke exports op voor het schema dat wordt uitgevoerd.
  3. De config_RunExports-pijplijn voert elk van de geselecteerde exports uit.
  4. Cost Management exporteert onbewerkte kostendetails naar de msexports-container . Zie Exporteren in v04-05 voor meer informatie.

Nadat de exports zijn voltooid, voor zowel beheerde als onbeheerde bereiken:

  1. De msexports_ExecuteETL-pijplijn start het ETL-proces (extract-transform-load) wanneer bestanden worden toegevoegd aan de opslag.
  2. De msexports_ETL_ingestion pijplijn transformeert de gegevens naar een standaardschema en slaat de onbewerkte gegevens in parquet-indeling op in de opnamecontainer . Voor meer informatie, zie Over opname in v04-05.
  3. Power BI leest kostengegevens uit de opnamecontainer .

Informatie over inslikken in v0.4-0.5

FinOps-hubs zijn afhankelijk van een specifiek mappad in de opnamecontainer :

ingestion/{dataset}/{yyyy}/{mm}/{scope-id}
  • ingestion is de container waarin de gegevenspijplijn gegevens opslaat.
  • {dataset} is het geëxporteerde gegevenssettype.
  • {month} is het jaar en de maand van de geëxporteerde gegevens die zijn opgemaakt als yyyyMM.
  • {scope-id} is naar verwachting de volledig gekwalificeerde resource-id van het bereik waaruit de gegevens afkomstig zijn.

Als u hubs wilt gebruiken om niet-Azure-gegevens te bewaken, converteert u de gegevens naar FOCUS en zet u deze neer in de opnamecontainer . Dit proces is niet expliciet getest in de nieuwste release. Als u problemen ondervindt, meld een probleem.

Over gegevensexports in v0.4-0.5

FinOps-hubs maken gebruik van Cost Management-exports om kostengegevens te verkrijgen. Cost Management bepaalt de mapstructuur voor de geëxporteerde gegevens in de container msexports . Een typisch pad ziet er als volgt uit:

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

Vanaf 0.4 zijn FinOps-hubs niet afhankelijk van bestandspaden. Hubs maken gebruik van het manifestbestand om het bereik, de gegevensset, de maand, enzovoort te identificeren. Het enige belangrijke deel van het pad voor hubs is de container, die msexports moet zijn.

Notitie

Exporteer geen gegevens naar de opnamecontainer . Geëxporteerde CSV's moeten worden gepubliceerd naar de msexports-container die moet worden verwerkt door de hubs-engine.

Als u aangepaste gegevens wilt opnemen, sla dan FOCUS-uitgelijnde Parquet-bestanden op in de opnamecontainer zodat de Power BI-rapporten van de FinOps-toolkit naar verwachting werken.

Exportmanifesten kunnen worden gewijzigd met API-versies. Hier volgt een voorbeeld met API-versie 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-hubs gebruiken de volgende eigenschappen:

  • exportConfig.resourceId om het bereik te identificeren.
  • exportConfig.type om het gegevenssettype te identificeren.
  • exportConfig.dataVersion om de versie van de gegevensset te identificeren.
  • runInfo.startDate om de geëxporteerde maand te identificeren.

FinOps-hubs ondersteunen de volgende typen gegevenssets, versies en API-versies:

  • FocusCost: 1.0, 1.0-preview(v1)
  • Prijzenoverzicht: 2023-05-01
  • Reserveringsdetails: 2023-03-01
  • Reserveringsaanbevelingen: 2023-05-01
  • ReservatieTransacties: 2023-05-01
  • API-versies: 2023-07-01-preview

FinOps-hubs v0.2-0.3

De volgende stappen geven een overzicht van het proces voor het exporteren en verwerken van kostengegevens met behulp van FinOps Hubs-versies 0.2-0.3:

  1. Cost Management exporteert onbewerkte kostendetails naar de msexports-container .
  2. De msexports_ExecuteETL-pijplijn start het ETL-proces (extract-transform-load) wanneer bestanden worden toegevoegd aan de opslag.
  3. Met de pijplijn msexports_ETL_ingestion worden geëxporteerde gegevens opgeslagen in parquetformaat in de opname container.
  4. Power BI leest kostengegevens uit de opnamecontainer .

FinOps-hubs 0.2-0.3 gebruiken het exportpad om het geëxporteerde bereik en de maand te bepalen. Dit punt is belangrijk omdat wijzigingen in het pad de gegevenspijplijnen kunnen verstoren. Om dit probleem te voorkomen, raden we u aan om bij te werken naar FinOps-hubs 0.4. Het verwachte pad moet nabootsen:

msexports/{scope-id}/{export-name}/{date-range}/{export-time}/{guid}/{file}
  • msexports is de container die is opgegeven voor de export.
  • {scope-id} is het pad naar de map dat is opgegeven bij de export.

    Hubs 0.3 en eerder gebruiken dit om te bepalen van welk bereik de gegevens afkomstig zijn. U wordt aangeraden de scope-ID te gebruiken, maar elke waarde kan worden gebruikt. Voorbeelden van scope-ID's zijn:

    Bereiktype Voorbeeldwaarde
    Abonnement /subscriptions/###
    Resourcegroep /subscriptions/###/resourceGroups/###
    Factureringsrekening /providers/Microsoft.Billing/billingAccounts/###
    Factureringsprofiel /providers/Microsoft.Billing/billingAccounts/###/billingProfiles/###
  • {export-name} is de naam van de export.

    Hubs negeren deze map.

  • {date-range} is de gegevens van het datumbereik die worden geëxporteerd.

    Hubs 0.3 en eerder gebruiken dit om de maand te identificeren. Indeling voor deze map is yyyyMMdd-yyyyMMdd. Hubs 0.4 gebruikt in plaats daarvan het manifest.

  • {export-time} is een tijdstempel van wanneer de export is uitgevoerd.

    Hubs negeren dit. Indeling voor deze map is yyyyMMddHHmm.

  • {guid} is een unieke GUID en is niet altijd aanwezig.

    Hubs negeren dit. Cost Management bevat deze map niet altijd. Of deze al dan niet is opgenomen, is afhankelijk van de API-versie die wordt gebruikt om de export te maken.

  • {file} is een manifest of geëxporteerde gegevens.

    Versie 0.3 en eerdere negeren manifestbestanden en monitoren de *.csv bestanden. In een toekomstige release bewaken hubs het manifest.


FinOps-hubs v0.1

De volgende stappen beschrijven het proces voor het exporteren en verwerken van kostengegevens met behulp van FinOps-hubs versie 0.1:

  1. Cost Management exporteert onbewerkte kostendetails naar de msexports-container .
  2. De msexports_transform pipeline slaat de onbewerkte gegevens in parquet-indeling op in de ingestiecontainer.
  3. Power BI leest kostengegevens uit de opnamecontainer .

Feedback geven

Laat ons weten hoe we het doen met een korte recensie. We gebruiken deze beoordelingen om FinOps-hulpprogramma's en -resources te verbeteren en uit te breiden.

Feedback geven

Als u op zoek bent naar iets specifieks, stem dan op een bestaande of maak een nieuw idee. Deel ideeën met anderen om meer stemmen te krijgen. We richten ons op ideeën met de meeste stemmen.

stemmen of ideeën voorstellen


Gerelateerde inhoud