Como os dados são processados em 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 de escopo

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

Os hubs FinOps dão suporte à 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 de hub. As informações descrevem o que acontece quando um novo escopo gerenciado é adicionado a esse arquivo. Escopos não gerenciados, em que 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 escopos que tenham sido adicionados.

Ingestão de dados

O diagrama a seguir ilustra 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 respectivos agendamentos para iniciar a ingestão de dados.
   2. O pipeline config_StartExportProcess obtém as exportações aplicáveis para o cronograma que está em execução.
   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 . Saiba mais.
3. O pipeline msexports_ExecuteETL enfileira o pipeline de extração, transformação e carregamento (ETL) quando os arquivos são adicionados ao contêiner msexports.
4. O pipeline msexports_ETL_ingestion transforma os dados para o formato Parquet e os move para o contêiner de ingestão usando uma estrutura de arquivos escalonável. Saiba mais.
5. (Opcional) Se estiver usando o Azure Data Explorer:
   1. O pipeline ingestion_ExecuteETL enfileira o pipeline de ingestão do Data Explorer quando arquivos manifest.json são adicionados ao contêiner de ingestão.
      • Se você ingerir conjuntos de dados personalizados fora das exportações de Gerenciamento de Custos, crie um arquivo de manifest.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 carregando). O arquivo manifest.json não é analisado e pode estar vazio. A única finalidade é indicar que todos os arquivos para esse trabalho de ingestão foram adicionados.
   2. O pipeline 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 no banco de dados de 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 de {dataset}_final_v1_0 correspondente usando a função {dataset}_transform_v1_0() para normalizar todos os dados para se alinhar ao FOCUS 1.0.
   4. Após a ingestão, o pipeline ingestion_ETL_dataExplorer executa algumas tarefas de limpeza, incluindo a limpeza de dados na tabela final que já passou do período de retenção de dados.
      • A partir da versão 0.7, o Data Explorer aplica a retenção de dados em tabelas brutas enquanto a retenção de dados nas tabelas finais é aplicada pelo pipeline de ingestão. Se a ingestão de dados for interrompida, 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 contêiner de ingestão.
   • Os dados no Data Explorer podem ser lidos no banco de dados Hub.
     • Use a função {dataset}() 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 função {dataset}_v1_0() para usar o esquema FOCUS 1.0.
       • Os esquemas de função com controle de versão não devem ser alterados ao longo do tempo, mas os valores poderão ser alterados se a fonte de dados alterar esses valores.
     • Evite usar o banco de dados de ingestão para consultas. Embora não seja explicitamente proibido, o banco de dados de ingestão deve ser considerado uma área interna para preparo e preparação de dados.
   • Os dados no armazenamento podem ser lidos de ingestion/<dataset>/<year>/<month>/<scope-path>.
     • Os dados devem ser lidos recursivamente da pasta do conjunto de dados e, opcionalmente, incluindo mais conforme necessário para especificidade.
     • Os arquivos em cada pasta de conjunto de dados podem ter esquemas diferentes com base na fonte de dados e no tipo de conta. Esteja preparado para transformar dados se estiver fazendo ingestão em outros sistemas, como Microsoft Fabric.
     • A leitura do armazenamento é desencorajada por questões de desempenho. O Data Explorer é recomendado ao relatar 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 funções {dataset}_transform_v1_0() aplicam regras de transformação no banco de dados de ingestão. 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 de Gerenciamento de Custos subjacentes, confira o problema nº 1111. Deixe comentários sobre esse problema se você encontrar oportunidades para resolver quaisquer preocupações ou expressar seu suporte para qualquer um dos problemas específicos.

Transformações dos dados de custo

Conjuntos de dados com suporte:

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

Os conjuntos de dados a seguir foram contabilizados no design, mas não têm suporte nativo. Para ingerir esses conjuntos de dados, crie um pipeline de dados (ou processo externo) que envia arquivos Parquet por push para a pasta ingestion/Costs/yyyy/mm/{scope-path} no armazenamento. O {scope-path} pode ser qualquer caminho exclusivo, 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.

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

Transformações:

• v0.7+:
  • Alinhe os nomes de coluna do FOCUS 1.0-preview com o FOCUS 1.0.
    • Inclui a conversão da versão prévia do FOCUS 1.0 para 1.0.
  • Adicione x_IngestionTime para indicar quando a linha foi atualizada pela última vez.
  • Adicione x_SourceChanges para identificar quando os dados em uma linha são alterados pelos hubs.
  • Atualize ProviderName e PublisherName quando não for especificado.
  • Adicione x_SourceName, x_SourceProvider, x_SourceTypee x_SourceVersion para identificar o conjunto de dados ingerido original.
  • Preencha os valores ListCost, ListUnitPrice, ContractedCoste ContractedUnitPrice ausentes com base na tabela de preços.
    • Esse processo exige que os preços sejam exportados antes do custo. Os preços estarão ausentes no primeiro dia do mês se os custos forem ingeridos antes que os preços do mês estejam disponíveis.
  • Corrija ContractedCost quando definido incorretamente devido a um bug no Gerenciamento de Custos.
  • Minúsculas ResourceName e x_ResourceGroupName para resolver problemas de inconsistê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 valores de ResourceType que usem IDs de tipo de recurso interno (por exemplo, microsoft.compute/virtualmachines).
• v0.9+:
  • Converta BillingAccountId para letras minúsculas para garantir que a junção de preços corresponda a todas as linhas.
  • Torne CommitmentDiscountId minúscula para evitar linhas duplicadas ao agregar dados.
  • Adicionar novas x_SourceChanges verificações para ListCostLessThanContractedCost e ContractedCostLessThanEffectiveCost.
• v0.10+:
  • Corrija x_EffectiveUnitPrice quando ele é calculado e há um erro de arredondamento em comparação com x_BilledUnitPrice ou ContractedUnitPrice.
  • Calcule PricingQuantity e ConsumedQuantity quando houver custo, mas nenhuma quantidade.
  • Defina ContractedCost como EffectiveCost quando não estiver definido.
  • Defina ListCost como ContractedCost quando não estiver definido.
  • Remova "-2" na coluna x_InvoiceSectionId.
  • Remova "Não atribuído" na x_InvoiceSectionName coluna.
  • x_EffectiveUnitPrice Corrigido quando é calculado e tem um erro de arredondamento.
  • Adicionar novas x_SourceChanges verificações para MissingConsumedQuantity, MissingPricingQuantitye XEffectiveUnitPriceRoundingError.
• v0.11+:
  • Altere BillingPeriodStart e BillingPeriodEnd para serem o primeiro do mês.

Transformações de dados sobre preços

Conjuntos de dados com suporte:

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

Transformações:

• v0.7+
  • Alinhe os nomes das colunas ao FOCUS 1.0.
    • Inclui a imposição de consistência de nome de coluna EA e MCA.
    • Não altera os valores subjacentes, que podem ser diferentes entre EA e MCA.
  • Converta a duração x_SkuTerm do ISO para o número específico de meses para corresponder aos detalhes de custo.
    • Estamos aguardando que FOCUS faça uma determinação de como definir durações antes de alterar esse valor para ISO ou outro formato.
  • Substitua o ContractedUnitPrice para uso do plano de economia pelo equivalente sob demanda.
  • Defina o ListUnitPrice para uso do plano de economia definido como o equivalente sob demanda.
  • Adicione SkuPriceIdv2 como um valor mais preciso de SkuPriceId do que o que está atualmente nos detalhes de custo.
  • Adicione x_IngestionTime para indicar quando a linha foi atualizada pela última vez.
  • Adicionar 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 o percentual do desconto por SKU.
  • Adicione x_SourceName, x_SourceProvider, x_SourceTypee x_SourceVersion para identificar o conjunto de dados ingerido original.
• v0.9+:
  • Converta BillingAccountId para minúsculas para garantir que a junção de custo corresponda a todas as linhas.

Transformações de dados de recomendação

Conjuntos de dados com suporte:

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

Transformações:

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

Transformações de dados de transação

Conjuntos de dados com suporte:

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

Transformações:

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

Transformações de dados de uso de desconto de compromisso

Conjuntos de dados com suporte:

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

Transformações:

1. Alinhe os nomes das colunas ao FOCUS 1.0.
   • Inclui a imposição de consistência de nome de coluna EA e MCA.
   • Não altera os valores subjacentes, que podem ser diferentes entre EA e MCA.
2. Adicione a coluna ResourceType com o nome de exibição do tipo de recurso.
3. Adicione colunas ServiceName, ServiceCategorye x_ServiceModel.
4. Substituir "NA" será nulo para x_CommitmentDiscountNormalizedGroup.
5. Adicione x_CommitmentDiscountQuantity com base no FOCUS 1.1.

Sobre o contêiner de ingestão

Os hubs de FinOps dependem de um caminho de pasta específico e 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 em que o pipeline de dados salva dados.
• {dataset} é o tipo de conjunto de dados exportado. Se estiver ingerindo no Azure Data Explorer, o banco de dados de ingestão deverá ter uma tabela "_raw" correspondente e sensível a maiúsculas de minúsculas (por exemplo, "Costs_raw"). Os hubs FinOps dão suporte aos seguintes conjuntos de dados nesta versão:
  • CommitmentDiscountUsage – Exportação de detalhes da reserva de Gerenciamento de Custos.
  • Custos – Dados de custo e uso do FOCUS.
  • Preços – Exportação da tabela de preços do Gerenciamento de Custos.
  • Recomendações – Exportação de recomendações de reserva do Gerenciamento de Custos.
  • Transações – Exportação de transações de reserva do Gerenciamento de Custos.
  • Para ingerir conjuntos de dados personalizados, crie uma tabela correspondente {dataset}_raw e um mapeamento de ingestão Parquet no banco de dados de ingestão.
• {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 acompanhar o histórico do conjunto de dados. Cada inserçã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 manter apenas a ingestão mais recente 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 por 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 manter a ingestão mais recente por dia. Não há suporte em relatórios do Power BI baseados em armazenamento.
• {scope-id-path} é o identificador de recurso completamente qualificado do escopo do qual os dados são originários. Se ingerir dados não 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} é uma ID exclusiva para o conjunto de dados ingerido. Essa ID pode ser um GUID, um carimbo de data/hora ou qualquer valor, desde que seja consistente em todos os arquivos para o 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 arquivo original ou outro identificador para indicar onde os dados no arquivo se originaram. 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 são do Azure, converta os dados em FOCUS e solte-os no contêiner de ingestão usando essas diretrizes. Observe que o suporte para dados não Azure não foi explicitamente testado na versão mais recente. Se você tiver algum problema, crie um problema.

Sobre as exportações

Os hubs FinOps aproveitam as exportações de Gerenciamento de Custos para obter dados de custo. O Gerenciamento de Custos controla a estrutura de pastas dos dados exportados no msexports contêiner de armazenamento. 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 contêiner 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 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 que todos os arquivos parquet forem adicionados, adicione um arquivo demanifest.json vazio para disparar a ingestão.

Para ingerir o arquivo CSV das exportações de Gerenciamento de Custos, salve 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 a ingestão bem-sucedida:

1. Altere <export-name> para um valor exclusivo dentro do escopo do conjunto de dados que você está ingerindo.
   • Isso só é usado para recomendações para diferenciar os vários tipos diferentes de recomendações ingeridas 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 retrocesso.
2. Alterar <dataset> e <version> para o tipo de exportação e a versão do Gerenciamento de Custos. Confira a lista abaixo para conjuntos de dados com suporte.
3. Altere <scope> para a ID do recurso do Azure para o escopo de onde os dados vieram.
4. Altere <guid> para um GUID exclusivo.
5. Altere <yyyy-MM> para o ano e o mês do conjunto de dados.
6. Altere <path-to-file> para o caminho completo da pasta no contêiner (não inclua "msexports").
7. Altere <file-name> para o nome do primeiro arquivo carregado no armazenamento.
8. Se você tiver mais de um arquivo CSV, copie o objeto de 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 dão suporte aos seguintes tipos de conjunto de dados, versões e versões de API:

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

Hubs FinOps v0.6

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

Configuração de escopo na v0.6

As etapas a seguir ocorrem quando um novo escopo gerenciado é adicionado a uma instância do hub. Escopos não gerenciados (em que as exportações de Gerenciamento de Custos são configuradas manualmente) não exigem nenhuma configuração nos 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 escopos 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 o armazenamento.
2. O 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 respectivos agendamentos para iniciar a ingestão de dados.
2. O pipeline config_StartExportProcess obtém as exportações aplicáveis para o cronograma que está em execução.
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 . Saiba mais.
5. O pipeline msexports_ExecuteETL enfileira o pipeline de extração, transformação e carregamento (ETL) quando os arquivos são adicionados ao contêiner msexports.
6. O pipeline msexports_ETL_ingestion transforma os dados para o formato Parquet e os move para o contêiner de ingestão usando uma estrutura de arquivos escalonável. Saiba mais.
7. O Power BI ou outras ferramentas leem os dados do contêiner de ingestão.

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

1. O pipeline msexports_ExecuteETL inicia o processo de extração, transformação e carregamento (ETL) quando os arquivos são adicionados ao armazenamento.
2. O pipeline msexports_ETL_ingestion transforma os dados para o formato Parquet e os move para o contêiner de ingestão usando uma estrutura de arquivos escalonável. Saiba mais.
3. O Power BI ou outras ferramentas leem os dados do contêiner de ingestão.

Sobre a ingestão na v0.6

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

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

• ingestion é o contêiner em que 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 acompanhar o histórico do conjunto de dados. Cada inserçã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 manter apenas a ingestão mais recente 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 por 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 manter a ingestão mais recente por dia. Não há suporte em relatórios do Power BI baseados em armazenamento.
• {scope-id-path} é o identificador de recurso completamente qualificado do escopo do qual os dados são originários. Se ingerir dados não 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} é uma ID exclusiva para o conjunto de dados ingerido. Essa ID pode ser um GUID, um carimbo de data/hora ou qualquer valor, desde que seja consistente em todos os arquivos para o 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 arquivo original ou outro identificador para indicar onde os dados no arquivo se originaram. 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 são do Azure, converta os dados em FOCUS e solte-os no contêiner de ingestão usando essas diretrizes. Observe que o suporte para dados não Azure não foi explicitamente testado na versão mais recente. Se você tiver algum problema, crie um problema.

Sobre as exportações na v0.6

Os hubs FinOps usam exportações do Gerenciamento de Custos para obter dados de custo. O Gerenciamento de Custos controla a estrutura de pastas dos 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 da versão 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 escopo.
• 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 dão suporte aos seguintes tipos de conjunto 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
• Recomendações de reserva: 2023-05-01
• Transações de Reserva: 2023-05-01
• Versões da API: 2023-07-01-preview

Hubs 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 de 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 escopos que tenham sido adicionados.

Ingestão de dados na v0.4-0.5

Para escopos gerenciados:

1. Os gatilhos config_DailySchedule e config_MonthlySchedule são executados em seus respectivos agendamentos para iniciar a ingestão de dados.
2. O pipeline config_ExportData obtém as exportações aplicáveis para o agendamento em execução.
3. O pipeline 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 msexports_ExecuteETL inicia o processo de extração, transformação e carregamento (ETL) quando os arquivos são adicionados ao armazenamento.
2. O pipeline msexports_ETL_ingestion transforma os dados em um esquema padrão e salva os dados brutos no formato Parquet no contêiner de ingestão. Para obter mais informações, confira Sobre a ingestão na v04-05.
3. O Power BI lê os dados de custo do contêiner de ingestão.

Sobre a ingestão na v0.4-0.5

Os hubs FinOps dependem de um caminho de pasta específico no contêiner 'ingestion'.

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

• ingestion é o contêiner em que 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 a ID de recurso totalmente qualificado do escopo do qual os dados provêm.

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

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

Os hubs FinOps usam exportações do Gerenciamento de Custos para obter dados de custo. O Gerenciamento de Custos controla a estrutura de pastas dos 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 da versão 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 escopo.
• 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 dão suporte aos seguintes tipos de conjunto 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
• Recomendações de reserva: 2023-05-01
• Transações de Reserva: 2023-05-01
• Versões da API: 2023-07-01-preview

Hubs FinOps v0.2-0.3

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

1. O Gerenciamento de Custos exporta detalhes de custo bruto para o contêiner msexports .
2. O pipeline msexports_ExecuteETL inicia o processo de extração, transformação e carregamento (ETL) quando os arquivos são adicionados ao armazenamento.
3. O pipeline msexports_ETL_ingestion salva os dados exportados no formato Parquet no contêiner de ingestão.
4. O Power BI lê os dados de custo do contêiner 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. Esse ponto é importante, pois as atualizações no caminho podem interromper os pipelines de dados. Para evitar esse problema, recomendamos atualizar para os hubs FinOps 0.4. O caminho esperado deve imitar:

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

• msexports é o contêiner 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 usar a ID do escopo, mas qualquer valor pode ser usado. As IDs de escopo de exemplo incluem:

  Tipo de escopo	Valor de exemplo
  Assinatura	/subscriptions/###
  Grupo de recursos	/subscriptions/###/resourceGroups/###
  Conta de cobrança	/providers/Microsoft.Billing/billingAccounts/###
  Perfil de faturamento	/providers/Microsoft.Billing/billingAccounts/###/billingProfiles/###

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

  Os hubs ignoram essa pasta.

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

  Os hubs 0.3 e anteriores usam isso para identificar o mês. O formato para esta pasta é yyyyMMdd-yyyyMMdd. Em vez disso, o Hubs 0.4 usa o manifesto.

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

  Os hubs ignoram isso. O formato para esta pasta é yyyyMMddHHmm.

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

  Os hubs ignoram isso. O Gerenciamento de Custos nem sempre inclui essa pasta. Se ela está incluída 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 arquivos de manifesto e monitoram apenas os arquivos *.csv . Em uma versão futura, os hubs monitorarão o manifesto.

Hubs 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 no formato parquet no contêiner de ingestão.
3. O Power BI lê os dados de custo do contêiner de ingestão.

Envie comentários

Deixe-nos saber como estamos indo com uma avaliação rápida. Usamos essas revisões para melhorar e expandir ferramentas e recursos do FinOps.

Se você estiver procurando algo específico, vote em um existente ou crie uma ideia. Compartilhe ideias com outras pessoas para obter mais votos. Nos concentramos em ideias com a maioria dos votos.

Conteúdo relacionado

• Implantar hubs FinOps
• Saiba mais