Como os dados são processados nos hubs FinOps

Os hubs FinOps executam muitas atividades de processamento de dados para limpar, normalizar e otimizar dados. As seções a seguir mostram como os dados fluem do Gerenciamento de Custos para uma instância de hub.

Configuração do escopo

Um escopo é um nível dentro da hierarquia de recursos e contas da nuvem que fornece acesso a dados de custo, uso e carbono. Para hubs FinOps, normalmente recomendamos o uso de contas de faturamento do Enterprise Agreement (EA) ou perfis de faturamento do Microsoft Customer Agreement (MCA), no entanto, qualquer escopo de nuvem é suficiente para uma análise básica. A principal preocupação é saber se os dados de preços e reservas são necessários, uma vez que a Gestão de Custos apenas expõe os dados das contas de faturação da EA e dos perfis de faturação MCA.

Os hubs FinOps suportam a configuração de escopos configurando manualmente as exportações do Gerenciamento de Custos ou concedendo aos hubs FinOps acesso para gerenciar escopos em seu nome. Os escopos gerenciados são configurados no arquivo config/settings.json no armazenamento do hub. As informações descrevem o que acontece quando um novo escopo gerenciado é adicionado a esse arquivo. Os escopos não gerenciados, nos quais as exportações do Gerenciamento de Custos são configuradas manualmente, não exigem outra configuração.

1. O gatilho config_SettingsUpdated é executado quando o arquivo settings.json é atualizado.
2. O pipeline config_ConfigureExports cria novas exportações para quaisquer novos âmbitos que tenham sido adicionados.

Ingestão de dados

O diagrama a seguir mostra o processo de ingestão de dados de ponta a ponta nos hubs FinOps:

1. (Opcional) Se estiver usando exportações gerenciadas:
   1. Os gatilhos config_DailySchedule e config_MonthlySchedule são executados em seus respetivos horários para iniciar a ingestão de dados.
   2. O pipeline de config_StartExportProcess obtém as exportações aplicáveis para o cronograma que está sendo executado.
   3. O pipeline config_RunExportJobs executa cada uma das exportações selecionadas.
2. O Gerenciamento de Custos exporta detalhes de custo bruto para o contêiner msexports . Mais informações.
3. O pipeline msexports_ExecuteETL enfileira o pipeline ETL (extract-transform-load) quando os arquivos são adicionados ao contêiner msexports.
4. O pipeline de msexports_ETL_ingestion transforma os dados para o formato parquet e move-os para o contentor de ingestão usando uma estrutura de ficheiro escalável. Mais informações.
5. (Opcional) Se estiver usando o Azure Data Explorer:
   1. O pipeline ingestion_ExecuteETL coloca em fila o pipeline de ingestão do Data Explorer quando manifest.json ficheiros são adicionados ao contêiner de ingestão .
      • Se ingerir conjuntos de dados personalizados fora das exportações do Gerenciamento de Custos, crie um arquivo demanifest.json vazio na pasta de ingestão de destino depois que todos os outros arquivos estiverem prontos (não adicione esse arquivo quando os arquivos ainda estiverem sendo carregados). O arquivo manifest.json não é analisado e pode estar vazio. O único objetivo é indicar que todos os arquivos para este trabalho de ingestão são adicionados.
   2. O pipeline de ingestion_ETL_dataExplorer ingere dados na tabela {dataset}_raw no Data Explorer.
      • O nome do conjunto de dados é a primeira pasta no contêiner de ingestão .
      • Todas as tabelas brutas estão na base de dados Ingestão no Data Explorer.
   3. Quando os dados são ingeridos em tabelas brutas no Data Explorer, uma política de atualização copia os dados para a tabela {dataset}_final_v1_0 correspondente usando a função {dataset}_transform_v1_0() para normalizar todos os dados para alinhar ao FOCUS 1.0.
   4. Após a ingestão, o pipeline de ingestion_ETL_dataExplorer executa uma limpeza, incluindo a purga de dados na tabela final que ultrapassou o período de retenção de dados.
      • A partir de 0,7, o Data Explorer aplica a retenção de dados em tabelas brutas, enquanto a retenção de dados em tabelas finais é aplicada pelo pipeline de ingestão. Se a ingestão de dados parar, os dados históricos não serão limpos.
      • A retenção de dados pode ser configurada durante a implantação do modelo ou manualmente no arquivo config/settings.json no armazenamento.
6. Relatórios e outras ferramentas como o Power BI leem dados do Data Explorer ou do contentor de ingestão de.
   • Os dados no Data Explorer podem ser lidos do banco de dados do Hub.
     • Use a {dataset}() função para usar o esquema mais recente.
       • Essa função é útil para exploração rápida, mas pode introduzir alterações significativas à medida que a instância do hub FinOps é atualizada.
     • Use a {dataset}_v1_0() função para usar o esquema FOCUS 1.0.
       • Os esquemas de função com controle de versão não devem mudar ao longo do tempo, mas os valores podem mudar se a fonte de dados alterar esses valores.
     • Evite usar o banco de dados do Ingestion para consultas. Embora não seja explicitamente proibida, a base de dados Ingestão deve ser considerada uma área interna para encenação e preparação de dados.
   • Os dados armazenados podem ser lidos a partir de ingestion/<dataset>/<year>/<month>/<scope-path>.
     • Os dados devem ser lidos recursivamente a partir da pasta do conjunto de dados e, opcionalmente, incluir mais, conforme necessário para a especificidade.
     • Os arquivos em cada pasta do conjunto de dados podem ter esquemas diferentes com base na fonte de dados e no tipo de conta. Esteja preparado para transformar dados se ingerir em outros sistemas, como o Microsoft Fabric.
     • A leitura a partir do armazenamento é desencorajada por questões de desempenho. O Data Explorer é recomendado ao gerar relatórios sobre mais de US$ 1 milhão em custo.

Sobre a ingestão de dados no Data Explorer

Quando os dados são ingeridos no Data Explorer, as {dataset}_transform_v1_0() funções aplicam regras de transformação no banco de dados Ingestion . Cada conjunto de dados tem um conjunto diferente de regras de transformação abordadas nas seções a seguir.

Para obter uma lista de alterações solicitadas, ideias em consideração e perguntas abertas sobre os conjuntos de dados subjacentes do Gerenciamento de Custos, consulte edição #1111. Deixe comentários sobre essa questão se encontrar oportunidades para abordar quaisquer preocupações ou expressar o seu apoio para qualquer uma das questões específicas.

Transformações de dados de custo

Conjuntos de dados suportados:

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

Os seguintes conjuntos de dados foram contabilizados no design, mas não são suportados nativamente. Para ingerir esses conjuntos de dados, crie um pipeline de dados (ou processo externo) que envie ficheiros Parquet para a pasta ingestion/Costs/yyyy/mm/{scope-path} no armazenamento. O {scope-path} pode ser qualquer caminho único, como aws/123 ou gcp/projects/foo. O único requisito é garantir que cada escopo esteja em uma pasta separada. Depois de copiar conteúdo externo, crie também um arquivo manifest.json para disparar a ingestão do Data Explorer.

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

Transformações

• v0.7+:
  • Alinhe os nomes das colunas do FOCUS 1.0-preview com o FOCUS 1.0.
    • Inclui a conversão da pré-visualização do FOCUS 1.0 para 1.0.
  • Adicione x_IngestionTime para indicar quando a linha foi atualizada pela última vez.
  • Adicionar x_SourceChanges para identificar quando numa linha os dados são alterados por hubs.
  • Atualize ProviderName e PublisherName quando não estiverem especificados.
  • Adicione x_SourceName, x_SourceProvider, x_SourceTypee x_SourceVersion para identificar o conjunto de dados original ingerido.
  • Preencha os valores ausentes de ListCost, ListUnitPrice, ContractedCoste ContractedUnitPrice de acordo com a planilha de preços.
    • Este processo exige que os preços sejam exportados antes do custo. Faltam preços para o primeiro dia do mês, se os custos forem ingeridos antes de os preços estarem disponíveis para o mês.
  • Corrigir ContractedCost quando configurado incorretamente devido a um bug na Gestão de Custos.
  • Coloque ResourceName e x_ResourceGroupName em minúsculas para resolver problemas de consistência de maiúsculas e minúsculas que interrompem o agrupamento e a filtragem.
  • Adicione x_BillingAccountAgreement com base no tipo de conta.
• v0.8+:
  • Corrija quaisquer ResourceType valores que usem IDs de tipo de recurso interno (por exemplo, microsoft.compute/virtualmachines).
• v0.9+:
  • Tornar BillingAccountId minúsculo para garantir que a união de preços correspondam a todas as linhas.
  • Letras minúsculas CommitmentDiscountId para evitar linhas duplicadas ao agregar dados.
  • Adicione novas x_SourceChanges verificações para ListCostLessThanContractedCost e ContractedCostLessThanEffectiveCost.
• v0.10+:
  • Corrija x_EffectiveUnitPrice quando é calculado e existe um erro de arredondamento em comparação com x_BilledUnitPrice ou ContractedUnitPrice.
  • Calcule PricingQuantity e ConsumedQuantity quando houver custo, mas não quantidade.
  • Defina ContractedCost como EffectiveCost quando não está definido.
  • Defina ListCost como ContractedCost quando não está definido.
  • Remova "-2" na coluna x_InvoiceSectionId.
  • Remova "Não atribuído" na x_InvoiceSectionName coluna.
  • Corrigido x_EffectiveUnitPrice quando é calculado e apresenta um erro de arredondamento.
  • Adicione novas x_SourceChanges verificações para MissingConsumedQuantity, MissingPricingQuantitye XEffectiveUnitPriceRoundingError.
• v0.11+:
  • Altere BillingPeriodStart e BillingPeriodEnd para sejam o primeiro dia do mês.

Transformações de dados de preços

Conjuntos de dados suportados:

• Folha de preços da Microsoft: 2023-05-01 (EA e MCA)

Transformações

• v0,7+
  • Alinhe os nomes das colunas ao FOCUS 1.0.
    • Inclui assegurar a consistência dos nomes das colunas EA e MCA.
    • Não altera os valores subjacentes, que podem diferir entre EA e MCA.
  • Converta x_SkuTerm a duração do ISO para o número específico de meses para corresponder aos detalhes do custo.
    • Estamos esperando que o FOCUS faça uma determinação de como definir durações antes de alterar esse valor para ISO ou outro formato.
  • Substitua ContractedUnitPrice para uso do plano de economia pelo equivalente sob demanda.
  • Defina ListUnitPrice para uso do plano de poupança definido como o equivalente ao sob demanda.
  • Adicione SkuPriceIdv2 como um valor de SkuPriceId mais preciso do que aquele que está atualmente nos detalhes de custos.
  • Adicione x_IngestionTime para indicar quando a linha foi atualizada pela última vez.
  • Adicione x_CommitmentDiscountSpendEligibility e x_CommitmentDiscountUsageEligibility.
  • Expanda x_PricingUnitDescription para PricingUnit e x_PricingBlockSize.
  • Adicione x_BillingAccountAgreement com base no tipo de conta.
  • Altere x_EffectivePeriodEnd para ser uma data de término exclusiva.
  • Adicione x_EffectiveUnitPriceDiscount, x_ContractedUnitPriceDiscounte x_TotalUnitPriceDiscount para resumir os descontos disponíveis por SKU.
  • Adicione x_EffectiveUnitPriceDiscountPercent, x_ContractedUnitPriceDiscountPercente x_TotalUnitPriceDiscountPercent para resumir a porcentagem do desconto por SKU.
  • Adicione x_SourceName, x_SourceProvider, x_SourceTypee x_SourceVersion para identificar o conjunto de dados original ingerido.
• v0.9+:
  • Tornar minúscula BillingAccountId para garantir que a união de custos corresponda a todas as linhas.

Transformações de dados de recomendação

Conjuntos de dados suportados:

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

Transformações

1. Alinhe os nomes das colunas ao FOCUS 1.0.
   • Inclui assegurar a consistência dos nomes das colunas EA e MCA.
   • Não altera os valores subjacentes, que podem diferir entre EA e MCA.
2. Adicione x_SourceName, x_SourceProvider, x_SourceTypee x_SourceVersion para identificar o conjunto de dados original ingerido.

Transformações de dados de transação

Conjuntos de dados suportados:

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

Transformações

1. Alinhe os nomes das colunas ao FOCUS 1.0.
   • Inclui assegurar a consistência dos nomes das colunas EA e MCA.
   • Não altera os valores subjacentes, que podem diferir entre EA e MCA.
2. Adicione x_SourceName, x_SourceProvider, x_SourceTypee x_SourceVersion para identificar o conjunto de dados original ingerido.

Os dados de utilização do desconto de compromisso transformam-se

Conjuntos de dados suportados:

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

Transformações

1. Alinhe os nomes das colunas ao FOCUS 1.0.
   • Inclui assegurar a consistência dos nomes das colunas EA e MCA.
   • Não altera os valores subjacentes, que podem diferir entre EA e MCA.
2. Adicione a coluna ResourceType com o nome de exibição do tipo de recurso.
3. Adicione ServiceName, ServiceCategorye x_ServiceModel colunas.
4. Substitua "NA" por null para x_CommitmentDiscountNormalizedGroup.
5. Adicione x_CommitmentDiscountQuantity com base em FOCUS 1.1.

Sobre o recipiente de ingestão

Os hubs FinOps dependem de um caminho de pasta específico e de um formato de nome de arquivo no contêiner de armazenamento de ingestão.

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

• ingestion é o contêiner onde o pipeline de dados salva dados.
• {dataset} é o tipo de conjunto de dados exportado. Se for ingerido no Azure Data Explorer, o banco de dados Ingestão deverá ter uma tabela "_raw" correspondente e que diferencie maiúsculas de minúsculas (por exemplo, "Costs_raw"). Os hubs FinOps suportam os seguintes conjuntos de dados nesta versão:
  • CommitmentDiscountUsage - exportação de detalhes da reserva da Gestão de Custos.
  • Custos - Dados de custo e utilização FOCUS.
  • Preços - exportação de folha de preços do Cost Management.
  • Recomendações - Exportação de recomendações de Gestão de Custos para reservas.
  • Transações - Exportação de transações de reserva de Gestão de Custos.
  • Para carregar conjuntos de dados personalizados, crie uma tabela correspondente de {dataset}_raw e um mapeamento de ingestão de parquet no banco de dados Ingestion.
• {date-folder-path} pode ser uma ou mais pastas que indicam quantos conjuntos de dados ingeridos devem ser mantidos. Exemplos:
  • all (ou qualquer espaço reservado) para não rastrear o histórico do conjunto de dados. Cada ingestão substitui os dados anteriores. Não há suporte em relatórios do Power BI baseados em armazenamento.
  • {yyyy} como um ano de quatro dígitos do conjunto de dados exportado para reter apenas a última ingestão por ano. Não há suporte em relatórios do Power BI baseados em armazenamento.
  • {yyyy}/{mm} como um ano de quatro dígitos e um mês de dois dígitos do conjunto de dados exportado para manter a ingestão mais recente de cada mês.
  • {yyyy}/{mm}/{dd} como um ano de quatro dígitos, um mês de dois dígitos e um dia de dois dígitos do conjunto de dados exportado para garantir a retenção da ingestão mais recente de cada dia. Não há suporte em relatórios do Power BI baseados em armazenamento.
• {scope-id-path} é o ID de recurso totalmente qualificado do escopo de onde são os dados. Se ingerir dados que não sejam do Azure, recomendamos usar uma hierarquia lógica com base no escopo dos dados (por exemplo, aws/{account-id}, , gcp/{project-name}oci/{component-id}/{component-id}).
• {ingestion-id} é um ID exclusivo para o conjunto de dados ingerido. Esse ID pode ser um GUID, um carimbo de data/hora ou qualquer valor, desde que seja consistente em todos os arquivos do conjunto de dados ingerido. Esse valor é usado para remover dados ingeridos anteriormente no mesmo caminho de pasta.
• {original-file-name} destina-se a ser o nome do ficheiro original ou outro identificador para indicar a origem dos dados no ficheiro. Esse valor é apenas para fins de solução de problemas.

O caminho completo da pasta e a ID de ingestão são usados para garantir que os dados não sejam duplicados no armazenamento ou no Azure Data Explorer. O nome do arquivo original é adicionado às extensões do Azure Data Explorer para fins de solução de problemas, mas não é rastreado ou usado por hubs FinOps.

Se você precisar usar hubs para monitorar dados que não sejam do Azure, converta os dados em FOCUS e solte-os no contêiner de ingestão usando esta orientação. Observação O suporte para dados que não são do Azure não foi explicitamente testado na versão mais recente. Se tiver algum problema, crie um problema.

Sobre as exportações

Os hubs FinOps aproveitam as exportações do Cost Management para obter dados de custos. O Gerenciamento de Custos controla a estrutura de pastas para os dados exportados no contêiner de armazenamento msexports . Um caminho típico se parece com:

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

Os hubs FinOps utilizam o arquivo de manifesto para identificar o escopo, o conjunto de dados, o mês, etc. A única parte importante do caminho para hubs é o contêiner, que deve ser msexports.

Não exporte dados para o container de ingestão. Os CSVs exportados devem ser publicados no contêiner msexports para serem processados pelo mecanismo de hubs.

Para ingerir dados personalizados, salve arquivos de parquet no contêiner de ingestão para que os relatórios do Power BI do kit de ferramentas FinOps funcionem conforme o esperado. Depois de todos os arquivos de parquet serem adicionados, adicione um arquivo manifest.json vazio para acionar a ingestão.

Para ingerir o arquivo CSV das exportações do Cost Management, salve os arquivos em uma pasta específica no contêiner msexports . Depois que todos os arquivos forem adicionados, adicione um arquivo manifest.json com base no modelo abaixo. Faça as seguintes alterações para garantir uma ingestão bem-sucedida:

1. Mude <export-name> para um valor exclusivo dentro do escopo do conjunto de dados que você está ingerindo.
   • Isso é usado apenas para recomendações para diferenciar os muitos tipos diferentes de recomendações que estão sendo ingeridas e que não são identificáveis apenas do manifesto de exportação. Para recomendações de reserva, o ideal é incluir o serviço, o escopo (único/compartilhado) e o período de retrospetiva.
2. Altere <dataset> e <version> para o tipo e versão de exportação do Cost Management. Consulte a lista abaixo para obter os conjuntos de dados suportados.
3. Altere <scope> para a ID de recurso do Azure para o escopo do qual os dados vieram.
4. Mude <guid> para um GUID exclusivo.
5. Altere <yyyy-MM> para o ano e mês do conjunto de dados.
6. Mude <path-to-file> para o caminho completo da pasta dentro do contentor (não inclua "msexports").
7. Mude <file-name> para o nome do primeiro arquivo carregado no armazenamento.
8. Se você tiver mais de um arquivo CSV, copie o objeto blob para cada arquivo carregado e atualize o nome do arquivo.

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

Os hubs FinOps suportam os seguintes tipos de conjuntos de dados, versões e versões de API:

• FocusCost: 1.0r2, 1.0, 1.0-preview(v1)
• Folha de Preços: 2023-05-01
• Detalhes da Reserva: 2023-03-01
• ReservasRecomendações: 2023-05-01
• Transações de Reserva: 2023-05-01
• Versões da API: 2023-07-01-preview

FinOps Hubs v0.6

As seções a seguir explicam o processo de dados nos hubs FinOps 0.6.

Configuração do escopo na v0.6

As etapas a seguir acontecem quando um novo escopo gerenciado é adicionado a uma instância de hub. Os escopos não gerenciados (onde as exportações do Gerenciamento de Custos são configuradas manualmente) não exigem nenhuma configuração em hubs.

1. O gatilho config_SettingsUpdated é executado quando o arquivo settings.json é atualizado.
2. O pipeline config_ConfigureExports cria novas exportações para quaisquer novos âmbitos que tenham sido adicionados.

Ingestão de dados na v0.6

A ingestão de dados pode ser dividida em duas partes:

1. Exporta dados por push para armazenamento.
2. Hubs processa e ingere dados.

Para escopos gerenciados, os hubs executam as seguintes etapas:

1. Os gatilhos config_DailySchedule e config_MonthlySchedule são executados em seus respetivos horários para iniciar a ingestão de dados.
2. O pipeline de config_StartExportProcess obtém as exportações aplicáveis para o cronograma que está sendo executado.
3. O pipeline config_RunExportJobs executa cada uma das exportações selecionadas.
4. O Gerenciamento de Custos exporta detalhes de custo bruto para o contêiner msexports . Mais informações.
5. O pipeline msexports_ExecuteETL enfileira o pipeline ETL (extract-transform-load) quando os arquivos são adicionados ao contêiner msexports.
6. O pipeline de msexports_ETL_ingestion transforma os dados para o formato parquet e move-os para o contentor de ingestão usando uma estrutura de ficheiro escalável. Mais informações.
7. O Power BI ou outras ferramentas leem dados do contentor de ingestão.

Depois que as exportações são executadas, gerenciadas ou não, os hubs executam as seguintes etapas:

1. O pipeline de msexports_ExecuteETL inicia o processo ETL (extract-transform-load) quando os ficheiros são adicionados ao armazenamento.
2. O pipeline de msexports_ETL_ingestion transforma os dados para o formato parquet e move-os para o contentor de ingestão usando uma estrutura de ficheiro escalável. Mais informações.
3. O Power BI ou outras ferramentas leem dados do contentor de ingestão.

Sobre a ingestão na v0.6

Os hubs de FinOps dependem de um caminho de pasta específico e formato de nome de ficheiro no contêiner de ingestão:

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

• ingestion é o contêiner onde o pipeline de dados salva dados.
• {dataset} é o tipo de conjunto de dados exportado.
• {date-folder-path} pode ser uma ou mais pastas que indicam quantos conjuntos de dados ingeridos devem ser mantidos. Exemplos:
  • all (ou qualquer espaço reservado) para não rastrear o histórico do conjunto de dados. Cada ingestão substitui os dados anteriores. Não há suporte em relatórios do Power BI baseados em armazenamento.
  • {yyyy} como um ano de quatro dígitos do conjunto de dados exportado para reter apenas a última ingestão por ano. Não há suporte em relatórios do Power BI baseados em armazenamento.
  • {yyyy}/{mm} como um ano de quatro dígitos e um mês de dois dígitos do conjunto de dados exportado para manter a ingestão mais recente de cada mês.
  • {yyyy}/{mm}/{dd} como um ano de quatro dígitos, um mês de dois dígitos e um dia de dois dígitos do conjunto de dados exportado para garantir a retenção da ingestão mais recente de cada dia. Não há suporte em relatórios do Power BI baseados em armazenamento.
• {scope-id-path} é o ID de recurso totalmente qualificado do escopo de onde são os dados. Se ingerir dados que não sejam do Azure, recomendamos usar uma hierarquia lógica baseada no escopo dos dados (por exemplo, "aws/{account-id}", "gcp/{project-name}", "oci/{component-id}/{component-id}").
• {ingestion-id} é um ID exclusivo para o conjunto de dados ingerido. Esse ID pode ser um GUID, um carimbo de data/hora ou qualquer valor, desde que seja consistente em todos os arquivos do conjunto de dados ingerido. Esse valor é usado para remover dados ingeridos anteriormente no mesmo caminho de pasta.
• {original-file-name} destina-se a ser o nome do ficheiro original ou outro identificador para indicar a origem dos dados no ficheiro. Esse valor é apenas para fins de solução de problemas.

O caminho completo da pasta e a ID de ingestão são usados para garantir que os dados não sejam duplicados no armazenamento ou no Azure Data Explorer. O nome do arquivo original é adicionado às extensões do Azure Data Explorer para fins de solução de problemas, mas não é rastreado ou usado por hubs FinOps.

Se você precisar usar hubs para monitorar dados que não sejam do Azure, converta os dados em FOCUS e solte-os no contêiner de ingestão usando esta orientação. Observação O suporte para dados que não são do Azure não foi explicitamente testado na versão mais recente. Se tiver algum problema, crie um problema.

Sobre as exportações na v0.6

Os hubs FinOps usam exportações do Cost Management para obter dados de custo. O Gerenciamento de Custos controla a estrutura de pastas para os dados exportados no contêiner msexports . Um caminho típico se parece com:

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

A partir de 0.4, os hubs FinOps não dependem de caminhos de arquivo. Os hubs utilizam o arquivo de manifesto para identificar o escopo, o conjunto de dados, o mês, etc. A única parte importante do caminho para hubs é o contêiner, que deve ser msexports.

Os manifestos de exportação podem ser alterados com as versões da API. Aqui está um exemplo com a versão 2023-07-01-previewda API:

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

Os hubs FinOps usam as seguintes propriedades:

• exportConfig.resourceId para identificar o âmbito.
• exportConfig.type para identificar o tipo de conjunto de dados.
• exportConfig.dataVersion para identificar a versão do conjunto de dados.
• runInfo.startDate para identificar o mês exportado.

Os hubs FinOps suportam os seguintes tipos de conjuntos de dados, versões e versões de API:

• FocusCost: 1.0, 1.0-preview(v1)
• Folha de Preços: 2023-05-01
• Detalhes da Reserva: 2023-03-01
• ReservasRecomendações: 2023-05-01
• Transações de Reserva: 2023-05-01
• Versões da API: 2023-07-01-preview

Hubs de FinOps v0.4-0.5

As informações a seguir descrevem como os dados são processados nos hubs FinOps v0.4 e v0.5.

Configuração do Escopo na v0.4-0.5

1. O gatilho config_SettingsUpdated é executado quando o arquivo settings.json é atualizado.
2. O pipeline config_ConfigureExports cria novas exportações para quaisquer novos âmbitos que tenham sido adicionados.

Ingestão de dados em v0.4-0.5

Para escopos gerenciados:

1. Os gatilhos config_DailySchedule e config_MonthlySchedule são executados em seus respetivos horários para iniciar a ingestão de dados.
2. O pipeline config_ExportData obtém as exportações aplicáveis para o cronograma em execução.
3. O pipeline de config_RunExports executa cada uma das exportações selecionadas.
4. O Gerenciamento de Custos exporta detalhes de custo bruto para o contêiner msexports . Para obter mais informações, consulte Sobre exportações na v04-05.

Após a conclusão das exportações, para escopos gerenciados e não gerenciados:

1. O pipeline de msexports_ExecuteETL inicia o processo ETL (extract-transform-load) quando os ficheiros são adicionados ao armazenamento.
2. O pipeline de msexports_ETL_ingestion transforma os dados num esquema padrão e salva os dados brutos em formato parquet no contentor de ingestão. Para obter mais informações, consulte Sobre a ingestão na v04-05.
3. Power BI lê dados de custo do contentor de ingestão.

Sobre a ingestão na v0.4-0.5

Os hubs FinOps dependem de um caminho específico de pasta no contentor de ingestão.

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

• ingestion é o contêiner onde o pipeline de dados salva dados.
• {dataset} é o tipo de conjunto de dados exportado.
• {month} é o ano e o mês dos dados exportados formatados como yyyyMM.
• Espera-se que {scope-id} seja o ID de recurso totalmente qualificado do escopo de onde os dados provêm.

Se você precisar usar hubs para monitorar dados que não sejam do Azure, converta os dados em FOCUS e solte-os no contêiner de ingestão . Este processo não foi explicitamente testado na versão mais recente. Se tiver algum problema, crie um problema.

Sobre as exportações em v0.4-0.5

Os hubs FinOps usam exportações do Cost Management para obter dados de custo. O Gerenciamento de Custos controla a estrutura de pastas para os dados exportados no contêiner msexports . Um caminho típico se parece com:

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

A partir de 0.4, os hubs FinOps não dependem de caminhos de arquivo. Os hubs utilizam o arquivo de manifesto para identificar o escopo, o conjunto de dados, o mês e assim por diante. A única parte importante do caminho para hubs é o contêiner, que deve ser msexports.

Os manifestos de exportação podem ser alterados com as versões da API. Aqui está um exemplo com a versão 2023-07-01-previewda API:

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

Os hubs FinOps usam as seguintes propriedades:

• exportConfig.resourceId para identificar o âmbito.
• exportConfig.type para identificar o tipo de conjunto de dados.
• exportConfig.dataVersion para identificar a versão do conjunto de dados.
• runInfo.startDate para identificar o mês exportado.

Os hubs FinOps suportam os seguintes tipos de conjuntos de dados, versões e versões de API:

• FocusCost: 1.0, 1.0-preview(v1)
• Folha de Preços: 2023-05-01
• Detalhes da Reserva: 2023-03-01
• ReservasRecomendações: 2023-05-01
• Transações de Reserva: 2023-05-01
• Versões da API: 2023-07-01-preview

Centros FinOps v0.2-0.3

As etapas a seguir descrevem o processo de exportação e processamento de dados de custo usando hubs FinOps versões 0.2-0.3:

1. O Gerenciamento de Custos exporta detalhes de custo bruto para o contêiner msexports .
2. O pipeline de msexports_ExecuteETL inicia o processo ETL (extract-transform-load) quando os ficheiros são adicionados ao armazenamento.
3. O pipeline de msexports_ETL_ingestion salva os dados exportados em formato parquet no contentor de ingestão.
4. Power BI lê dados de custo do contentor de ingestão.

Os hubs FinOps 0.2-0.3 usam o caminho de exportação para determinar o escopo e o mês exportados. Este ponto é importante, pois as atualizações do caminho podem quebrar os pipelines de dados. Para evitar esse problema, recomendamos atualizar para hubs FinOps 0.4. O caminho esperado deve imitar:

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

• msexports é o recipiente especificado na exportação.
• {scope-id} é o caminho da pasta especificado na exportação.

  Os Hubs 0.3 e anteriores usam isso para identificar de qual escopo os dados estão vindo. Recomendamos o uso do ID do escopo, mas qualquer valor pode ser usado. Exemplos de IDs de escopo incluem:

  Tipo de âmbito	Valor de exemplo
  Subscrição	/subscriptions/###
  Grupo de recursos	/subscriptions/###/resourceGroups/###
  Conta de faturação	/providers/Microsoft.Billing/billingAccounts/###
  Perfil de faturação	/providers/Microsoft.Billing/billingAccounts/###/billingProfiles/###

• {export-name} é o nome da exportação.

  Os Hubs ignoram esta pasta.

• {date-range} é os dados do intervalo de datas que estão sendo exportados.

  Hubs 0.3 e anteriores usam isso para identificar o mês. O formato desta pasta é yyyyMMdd-yyyyMMdd. Hubs 0.4 usa o manifesto em vez disso.

• {export-time} é um carimbo de data e hora que indica quando a exportação foi realizada.

  Os Hubs ignoram isso. O formato desta pasta é yyyyMMddHHmm.

• {guid} é um GUID exclusivo e nem sempre está presente.

  Os Hubs ignoram isso. O Gerenciamento de Custos nem sempre inclui essa pasta. A inclusão ou não depende da versão da API usada para criar a exportação.

• {file} é um manifesto ou dados exportados.

  A versão 0.3 e anteriores ignoram os ficheiros de manifesto e monitorizam apenas os ficheiros *.csv . Em uma versão futura, os hubs monitorarão o manifesto.

Hub FinOps v0.1

As etapas a seguir descrevem o processo de exportação e processamento de dados de custo usando hubs FinOps versão 0.1:

1. O Gerenciamento de Custos exporta detalhes de custo bruto para o contêiner msexports .
2. O pipeline msexports_transform salva os dados brutos em formato parquet no container de ingestão.
3. Power BI lê dados de custo do contentor de ingestão.

Enviar comentários

Dê-nos a sua opinião com uma breve avaliação. Usamos essas análises para melhorar e expandir as ferramentas e os recursos do FinOps.

Se você está procurando algo específico, vote em uma ideia existente ou crie uma nova. Partilhe ideias com outras pessoas para obter mais votos. Focamo-nos nas ideias mais votadas.

Conteúdos relacionados

• Desenvolver centros FinOps
• Mais informações