Cómo se procesan los datos en los centros de FinOps

Los centros de FinOps realizan muchas actividades de procesamiento de datos para limpiar, normalizar y optimizar los datos. En las secciones siguientes se muestra cómo fluyen los datos de Cost Management a una instancia del centro.

Configuración del ámbito

Un ámbito es un nivel dentro de la jerarquía de recursos y cuentas en la nube que proporciona acceso a los datos de costo, uso y carbono. En el caso de los centros de FinOps, normalmente se recomienda usar cuentas de facturación de Contrato Enterprise (EA) o perfiles de facturación de Contrato de cliente de Microsoft (MCA), pero cualquier ámbito de nube es suficiente para el análisis básico. La principal preocupación es si se necesitan datos de precios y reservas, ya que Cost Management solo expone los datos de las cuentas de facturación de EA y los perfiles de facturación de MCA.

Los centros de FinOps admiten la configuración de ámbitos mediante la configuración manual de exportaciones de Cost Management o la concesión de acceso a centros de FinOps para administrar ámbitos en su nombre. Los ámbitos administrados se configuran en el archivo config/settings.json en el almacenamiento del concentrador. La información describe lo que sucede cuando se agrega un ámbito administrado nuevo a este archivo. Los ámbitos no administrados, donde las exportaciones de Cost Management se configuran manualmente, no requieren otra configuración.

1. El desencadenador config_SettingsUpdated se ejecuta cuando se actualiza el archivo settings.json .
2. La canalización de config_ConfigureExports crea nuevas exportaciones para cualquier nuevo ámbito agregado.

Ingesta de datos

En el diagrama siguiente se muestra el proceso de ingesta de datos de un extremo a otro en FinOps Hubs:

1. (Opcional) Si usa exportaciones administradas:
   1. Los desencadenadores config_DailySchedule y config_MonthlySchedule se ejecutan según sus respectivas programaciones para iniciar la ingesta de datos.
   2. La canalización de config_StartExportProcess obtiene las exportaciones aplicables para la programación que está en ejecución.
   3. La canalización config_RunExportJobs ejecuta cada una de las exportaciones seleccionadas.
2. Cost Management exporta los detalles sin procesar de los costos al contenedor msexports. Más información.
3. La canalización msexports_ExecuteETL pone en cola la canalización de extracción-transformación-carga (ETL) cuando se agregan archivos al contenedor msexports.
4. La canalización de msexports_ETL_ingestion transforma los datos a formato parquet y los mueve al contenedor de ingesta mediante una estructura de archivos escalable. Más información.
5. (Opcional) Si usa Azure Data Explorer:
   1. La canalización de ingestion_ExecuteETL pone en cola la canalización de ingesta del Explorador de datos cuando los archivos manifest.json se agregan al contenedor ingesta.
      • Si ingiere conjuntos de datos personalizados fuera de las exportaciones de Cost Management, cree un archivo manifest.json vacío en la carpeta de ingesta de destino después de que todos los demás archivos estén listos (no agregue este archivo cuando los archivos todavía se carguen). El archivo manifest.json no se analiza y puede estar vacío. El único propósito es indicar que se agregaron todos los archivos de este trabajo de ingesta.
   2. La canalización de ingestion_ETL_dataExplorer ingiere datos en la tabla {dataset}_raw del Explorador de datos.
      • El nombre del conjunto de datos es la primera carpeta del contenedor de ingesta.
      • Todas las tablas sin procesar se encuentran en la base de datos de ingesta en el Explorador de datos.
   3. Cuando los datos se ingieren en tablas sin procesar en el Explorador de datos, una directiva de actualización copia los datos en la tabla correspondiente {dataset}_final_v1_0 mediante la {dataset}_transform_v1_0() función para normalizar todos los datos para alinearse con FOCUS 1.0.
   4. Después de la ingesta, la canalización de ingestion_ETL_dataExplorer realiza algunas tareas de limpieza, incluida la purga de datos en la tabla final cuando ha pasado el período de retención de datos.
      • A partir de la versión 0.7, Data Explorer aplica la retención de datos en tablas sin procesar mientras la canalización de ingesta aplica la retención de datos en tablas finales. Si se detiene la ingesta de datos, los datos históricos no se purgan.
      • La retención de datos se puede configurar durante la implementación de la plantilla o manualmente en el archivo config/settings.json en el almacenamiento.
6. Informes y otras herramientas, como Power BI, leen datos del Explorador de datos o del contenedor de ingesta .
   • Los datos en el Explorador de Datos se pueden leer desde la base de datos del Hub.
     • Use la {dataset}() función para usar el esquema más reciente.
       • Esta función es útil para la exploración rápida, pero puede introducir cambios importantes a medida que se actualiza la instancia del centro de FinOps.
     • Use la {dataset}_v1_0() función para usar el esquema FOCUS 1.0.
       • Los esquemas de función con versiones no deben cambiar con el tiempo, pero los valores pueden cambiar si el origen de datos cambia esos valores.
     • Evite usar la base de datos de Ingesta para las consultas. Si bien no está explícitamente prohibido, la base de datos de ingesta debe considerarse un área interna para el almacenamiento provisional y la preparación de datos.
   • Los datos del almacenamiento se pueden leer desde ingestion/<dataset>/<year>/<month>/<scope-path>.
     • Los datos se deben leer de forma recursiva desde la carpeta del conjunto de datos y, opcionalmente, incluir más según sea necesario para la especificidad.
     • Los archivos de cada carpeta del conjunto de datos pueden tener esquemas diferentes en función del origen de datos y el tipo de cuenta. Prepárese para transformar los datos cuando se ingieren en otros sistemas, como Microsoft Fabric.
     • No se recomienda leer desde el almacenamiento debido a motivos de rendimiento. Se recomienda el Explorador de datos al informar sobre más de 1 millón de dólares en costes.

Acerca de la ingestión de datos en el Explorador

Cuando los datos se ingieren en el Explorador de datos, las funciones {dataset}_transform_v1_0() aplican reglas de transformación en la base de datos de ingesta. Cada conjunto de datos tiene un conjunto diferente de reglas de transformación que se tratan en las secciones siguientes.

Para obtener una lista de los cambios solicitados, ideas en consideración y preguntas abiertas sobre los conjuntos de datos subyacentes de Cost Management, consulte el problema n.º 1111. Deje comentarios sobre ese problema si encuentra oportunidades para abordar cualquier preocupación o para expresar su soporte técnico para cualquiera de los problemas específicos.

Transformaciones de datos sobre costes

Conjuntos de datos admitidos:

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

En el diseño se han contabilizado los siguientes conjuntos de datos, pero no se admiten de forma nativa. Para ingerir estos conjuntos de datos, cree una canalización de datos (o un proceso externo) que inserte archivos parquet en la carpeta ingestion/Costs/yyyy/mm/{scope-path} del almacenamiento. {scope-path} puede ser cualquier ruta de acceso única, como aws/123 o gcp/projects/foo. El único requisito es asegurarse de que cada ámbito está en una carpeta independiente. Después de copiar contenido externo, cree también un archivo manifest.json para desencadenar la ingesta del Explorador de datos.

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

Transforma:

• v0.7+:
  • Alinee los nombres de columna FOCUS 1.0-preview con FOCUS 1.0.
    • Incluye la conversión de la versión preliminar de FOCUS 1.0 a 1.0.
  • Agregue x_IngestionTime para indicar cuándo se actualizó por última vez la fila.
  • Agregue x_SourceChanges para identificar cuándo los centros cambian los datos de una fila.
  • Actualice ProviderName y PublisherName cuando no se especifique.
  • Agregue x_SourceName, x_SourceProvider, x_SourceTypey x_SourceVersion para identificar el conjunto de datos ingerido original.
  • Rellene los valores que faltan ListCost, ListUnitPrice, ContractedCosty ContractedUnitPrice en función de la hoja de precios.
    • Este proceso requiere que los precios se exportan antes del costo. Los precios no están disponibles el primer día del mes si los costos se registran antes de que los precios estén disponibles para el mes.
  • Corrige ContractedCost cuando se establezca incorrectamente debido a un error en la gestión de costos.
  • Poner en minúsculas ResourceName y x_ResourceGroupName para solucionar problemas de coherencia de mayúsculas y minúsculas que interrumpen la agrupación y el filtrado.
  • Agregue x_BillingAccountAgreement en función del tipo de cuenta.
• v0.8+:
  • Corrija los ResourceType valores que usen identificadores de tipo de recurso interno (por ejemplo, microsoft.compute/virtualmachines).
• v0.9+:
  • Cambia BillingAccountId a minúsculas para asegurarte de que la unión de precios coincida con todas las filas.
  • Cambie CommitmentDiscountId minúsculas para evitar filas duplicadas al agregar datos.
  • Agregue nuevas x_SourceChanges comprobaciones para ListCostLessThanContractedCost y ContractedCostLessThanEffectiveCost.
• v0.10+:
  • Corrija x_EffectiveUnitPrice cuando se calcula y hay un error de redondeo en comparación con x_BilledUnitPrice o ContractedUnitPrice.
  • Calcula PricingQuantity y ConsumedQuantity cuando haya costos, pero no haya cantidades.
  • Establézcalo ContractedCost en EffectiveCost cuando no esté establecido.
  • Establézcalo ListCost en ContractedCost cuando no esté establecido.
  • Quita "-2" en la columna x_InvoiceSectionId.
  • Quita "Sin asignar" en la columna x_InvoiceSectionName.
  • Corregimos x_EffectiveUnitPrice al calcularlo y encontrar un error de redondeo.
  • Agregue nuevas x_SourceChanges comprobaciones para MissingConsumedQuantity, MissingPricingQuantityy XEffectiveUnitPriceRoundingError.
• v0.11+:
  • Cambie BillingPeriodStart y BillingPeriodEnd para que sea el primero del mes.

Transformaciones de datos de precios

Conjuntos de datos admitidos:

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

Transforma:

• v0.7+
  • Alinee los nombres de columna con FOCUS 1.0.
    • Incluye la aplicación de la coherencia de nombres de columna EA y MCA.
    • No cambia los valores subyacentes, que pueden diferir entre EA y MCA.
  • Convierte la duración ISO x_SkuTerm al número específico de meses para que coincida con los detalles del coste.
    • Esperamos que FOCUS determine cómo definir duraciones antes de cambiar este valor a ISO u otro formato.
  • Reemplace ContractedUnitPrice para uso del plan de ahorro por el equivalente bajo demanda.
  • Establezca ListUnitPrice para uso del plan de ahorro definido como el equivalente a petición.
  • Agregue SkuPriceIdv2 como un valor más preciso SkuPriceId que el que se encuentra actualmente en detalles de costos.
  • Agregue x_IngestionTime para indicar cuándo se actualizó por última vez la fila.
  • Agregue x_CommitmentDiscountSpendEligibility y x_CommitmentDiscountUsageEligibility.
  • Expanda x_PricingUnitDescription en PricingUnit y x_PricingBlockSize.
  • Agregue x_BillingAccountAgreement en función del tipo de cuenta.
  • Cambie x_EffectivePeriodEnd para que sea una fecha de finalización exclusiva.
  • Agregue x_EffectiveUnitPriceDiscount, x_ContractedUnitPriceDiscounty x_TotalUnitPriceDiscount para resumir los descuentos disponibles por SKU.
  • Agregue x_EffectiveUnitPriceDiscountPercent, x_ContractedUnitPriceDiscountPercenty x_TotalUnitPriceDiscountPercent para resumir el porcentaje del descuento por SKU.
  • Agregue x_SourceName, x_SourceProvider, x_SourceTypey x_SourceVersion para identificar el conjunto de datos ingerido original.
• v0.9+:
  • Cambia BillingAccountId a minúsculas para asegurarte de que la unión de costes coincida con todas las filas.

Transformaciones de datos de recomendación

Conjuntos de datos admitidos:

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

Transforma:

1. Alinee los nombres de columna con FOCUS 1.0.
   • Incluye la aplicación de la coherencia de nombres de columna EA y MCA.
   • No cambia los valores subyacentes, que pueden diferir entre EA y MCA.
2. Agregue x_SourceName, x_SourceProvider, x_SourceTypey x_SourceVersion para identificar el conjunto de datos ingerido original.

Transformaciones de datos de transacción

Conjuntos de datos admitidos:

• Transacciones de Reserva de Microsoft: 2023-05-01 (EA y MCA)

Transforma:

1. Alinee los nombres de columna con FOCUS 1.0.
   • Incluye la aplicación de la coherencia de nombres de columna EA y MCA.
   • No cambia los valores subyacentes, que pueden diferir entre EA y MCA.
2. Agregue x_SourceName, x_SourceProvider, x_SourceTypey x_SourceVersion para identificar el conjunto de datos ingerido original.

Transformaciones de datos de uso de descuento de compromiso

Conjuntos de datos admitidos:

• DetallesDeReservas de Microsoft: 2023-03-01 (EA y MCA)

Transforma:

1. Alinee los nombres de columna con FOCUS 1.0.
   • Incluye la aplicación de la coherencia de nombres de columna EA y MCA.
   • No cambia los valores subyacentes, que pueden diferir entre EA y MCA.
2. Agregue ResourceType columna con el nombre del tipo de recurso para mostrar.
3. Agregue las columnas ServiceName, ServiceCategory y x_ServiceModel.
4. Reemplace "NA" con null para x_CommitmentDiscountNormalizedGroup.
5. Agregue x_CommitmentDiscountQuantity basado en FOCUS 1.1.

Acerca del contenedor de ingesta

Los centros de FinOps dependen de una ruta de acceso de carpeta específica y un formato de nombre de archivo en el contenedor de almacenamiento de ingesta.

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

• ingestion es el contenedor donde la canalización de datos guarda los datos.
• {dataset} es el tipo de conjunto de datos exportado. Si se ingiere en Azure Data Explorer, la base de datos de Ingesta debe tener una tabla "_raw" que coincida exactamente y distinga entre mayúsculas y minúsculas (por ejemplo, "Costs_raw"). Los centros de FinOps admiten los siguientes conjuntos de datos en esta versión:
  • CommitmentDiscountUsage: exportación de detalles de reserva de Cost Management.
  • Costos - Datos de costo y uso de FOCUS.
  • Precios - exportación de la hoja de precios de Cost Management.
  • Recomendaciones : exportación de recomendaciones de reserva de Cost Management.
  • Transacciones : exportación de transacciones de reserva de Cost Management.
  • Para ingerir conjuntos de datos personalizados, cree una tabla correspondiente {dataset}_raw y una asignación de ingesta en parquet en la base de datos Ingesta.
• {date-folder-path} puede ser una o varias carpetas que indiquen cuántos conjuntos de datos ingeridos se deben conservar. Ejemplos:
  • all (o cualquier marcador de posición) para no realizar un seguimiento del historial del conjunto de datos. Cada ingesta reemplaza los datos anteriores. No se admite en los informes de Power BI basados en almacenamiento.
  • {yyyy} como un año de cuatro dígitos del conjunto de datos exportado para conservar solo la ingesta más reciente por año. No se admite en los informes de Power BI basados en almacenamiento.
  • {yyyy}/{mm} como un año de cuatro dígitos y un mes de dos dígitos del conjunto de datos exportado para conservar la ingesta más reciente por mes.
  • {yyyy}/{mm}/{dd} como un año de cuatro dígitos, un mes de dos dígitos y un día de dos dígitos del conjunto de datos exportado para conservar la ingesta más reciente por día. No se admite en los informes de Power BI basados en almacenamiento.
• {scope-id-path} es el identificador de recurso completo del ámbito del que proceden los datos. Si ingiere datos que no son de Azure, se recomienda usar una jerarquía lógica basada en el ámbito de los datos (por ejemplo, aws/{account-id}, gcp/{project-name}, oci/{component-id}/{component-id}).
• {ingestion-id} es un identificador único para el conjunto de datos ingerido. Este identificador puede ser un GUID, una marca de tiempo o cualquier valor siempre que sea coherente en todos los archivos del conjunto de datos ingerido. Este valor se usa para quitar datos ingeridos previamente en la misma ubicación de carpeta.
• {original-file-name} está pensado para ser el nombre de archivo original u otro identificador para indicar dónde se originaron los datos del archivo. Este valor es solo con fines de solución de problemas.

La ruta de acceso completa de la carpeta y el identificador de ingesta se usan para asegurarse de que los datos no están duplicados en el almacenamiento o en Azure Data Explorer. El nombre de archivo original se agrega a los segmentos de Azure Data Explorer para fines de solución de problemas, pero no se rastrea ni se utiliza en los centros de FinOps.

Si necesita usar centros de conectividad para supervisar datos que no son de Azure, convierta los datos en FOCUS y colóquelos en el contenedor de ingesta mediante esta guía. Nota La compatibilidad con datos que no son de Azure no se ha probado explícitamente en la versión más reciente. Si experimenta algún problema, cree un problema.

Acerca de las exportaciones

Los centros de FinOps aprovechan las exportaciones de Cost Management para obtener datos de costos. Cost Management controla la estructura de carpetas de los datos exportados en el contenedor de almacenamiento msexports . Una ruta de acceso típica tiene el siguiente aspecto:

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

Los centros de FinOps utilizan el archivo de manifiesto para identificar el ámbito, el conjunto de datos, el mes, etc. La única parte importante de la ruta de acceso de los centros es el contenedor, que debe ser msexports.

No exporte datos al contenedor de ingesta . Los archivos CSV exportados deben publicarse en el contenedor msexports para que sean procesados por el motor de concentradores.

Para ingerir datos personalizados, guarde los archivos parquet en el contenedor de ingesta para que los informes de Power BI del kit de herramientas de FinOps funcionen según lo previsto. Una vez agregados todos los archivos parquet, agregue un archivo manifest.json vacío para desencadenar la ingesta.

Para ingerir el archivo CSV de las exportaciones de Cost Management, guarde los archivos en una carpeta específica del contenedor msexports . Una vez agregados todos los archivos, agregue un archivo manifest.json basado en la plantilla siguiente. Realice los siguientes cambios para garantizar la ingesta correcta:

1. Cambie <export-name> a un valor único dentro del ámbito del conjunto de datos que va a ingerir.
   • Esto solo se usa para las recomendaciones con el fin de diferenciar los muchos tipos diferentes de recomendaciones que se ingieren que no son identificables solo a partir del manifiesto de exportación. En el caso de las recomendaciones de reserva, incluya el servicio, el ámbito (único o compartido) y el período de retroactividad.
2. Cambie <dataset> y <version> al tipo de exportación y la versión de Cost Management. Consulte la lista siguiente para ver los conjuntos de datos admitidos.
3. Cambie <scope> al identificador de recurso de Azure del ámbito del que proceden los datos.
4. Cambie <guid> por un GUID único.
5. Cambie <yyyy-MM> al año y al mes del conjunto de datos.
6. Cambie <path-to-file> por la ruta completa de la carpeta en el contenedor (no incluya "msexports").
7. Cambie <file-name> por el nombre del primer archivo cargado en el almacenamiento.
8. Si tiene más de un archivo CSV, copie el objeto de blob para cada archivo que cargó y actualice el nombre de archivo.

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

Los centros de FinOps admiten los siguientes tipos de conjunto de datos, versiones y versiones de API:

• FocusCost: 1.0r2, , 1.01.0-preview(v1)
• Hoja de Precios: 2023-05-01
• DetallesDeLaReserva: 2023-03-01
• RecomendacionesDeReserva: 2023-05-01
• TransaccionesDeReserva: 2023-05-01
• Versiones de API: 2023-07-01-preview

FinOps Hubs v0.6

En las secciones siguientes se explica el proceso de datos en FinOps Hubs 0.6.

Configuración del alcance en v0.6

Los pasos siguientes se producen cuando se agrega un ámbito administrado nuevo a una instancia de concentrador. Los ámbitos no administrados (donde las exportaciones de Cost Management están configuradas manualmente) no requieren ninguna configuración en los centros.

1. El desencadenador config_SettingsUpdated se ejecuta cuando se actualiza el archivo settings.json .
2. La canalización de config_ConfigureExports crea nuevas exportaciones para cualquier nuevo ámbito agregado.

Ingesta de datos en v0.6

La ingesta de datos se puede dividir en dos partes:

1. Exporta datos de inserción al almacenamiento.
2. Hubs procesa e ingiere datos.

En el caso de los ámbitos administrados, los centros realizan los pasos siguientes:

1. Los desencadenadores config_DailySchedule y config_MonthlySchedule se ejecutan según sus respectivas programaciones para iniciar la ingesta de datos.
2. La canalización de config_StartExportProcess obtiene las exportaciones aplicables para la programación que está en ejecución.
3. La canalización config_RunExportJobs ejecuta cada una de las exportaciones seleccionadas.
4. Cost Management exporta los detalles sin procesar de los costos al contenedor msexports. Más información.
5. La canalización msexports_ExecuteETL pone en cola la canalización de extracción-transformación-carga (ETL) cuando se agregan archivos al contenedor msexports.
6. La canalización de msexports_ETL_ingestion transforma los datos a formato parquet y los mueve al contenedor de ingesta mediante una estructura de archivos escalable. Más información.
7. Power BI u otras herramientas leen datos del contenedor de ingesta .

Una vez ejecutadas las exportaciones, ya sea administradas o no administradas, los centros realizan los pasos siguientes:

1. La pipeline msexports_ExecuteETL inicia el proceso de extracción-transformación-carga (ETL) cuando se agregan archivos al almacenamiento.
2. La canalización de msexports_ETL_ingestion transforma los datos a formato parquet y los mueve al contenedor de ingesta mediante una estructura de archivos escalable. Más información.
3. Power BI u otras herramientas leen datos del contenedor de ingesta .

Acerca de la ingesta en v0.6

Los centros de FinOps dependen de una ruta de acceso de carpeta específica y un formato de nombre de archivo en el contenedor de almacenamiento de ingesta.

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

• ingestion es el contenedor donde la canalización de datos guarda los datos.
• {dataset} es el tipo de conjunto de datos exportado.
• {date-folder-path} puede ser una o varias carpetas que indiquen cuántos conjuntos de datos ingeridos se deben conservar. Ejemplos:
  • all (o cualquier marcador de posición) para no realizar un seguimiento del historial del conjunto de datos. Cada ingesta reemplaza los datos anteriores. No se admite en los informes de Power BI basados en almacenamiento.
  • {yyyy} como un año de cuatro dígitos del conjunto de datos exportado para conservar solo la ingesta más reciente por año. No se admite en los informes de Power BI basados en almacenamiento.
  • {yyyy}/{mm} como un año de cuatro dígitos y un mes de dos dígitos del conjunto de datos exportado para conservar la ingesta más reciente por mes.
  • {yyyy}/{mm}/{dd} como un año de cuatro dígitos, un mes de dos dígitos y un día de dos dígitos del conjunto de datos exportado para conservar la ingesta más reciente por día. No se admite en los informes de Power BI basados en almacenamiento.
• {scope-id-path} es el identificador de recurso completo del ámbito del que proceden los datos. Si ingiere datos que no son de Azure, se recomienda usar una jerarquía lógica basada en el ámbito de los datos (por ejemplo, "aws/{account-id}", "gcp/{project-name}", "oci/{component-id}/{component-id}").
• {ingestion-id} es un identificador único para el conjunto de datos ingerido. Este identificador puede ser un GUID, una marca de tiempo o cualquier valor siempre que sea coherente en todos los archivos del conjunto de datos ingerido. Este valor se usa para quitar datos ingeridos previamente en la misma ubicación de carpeta.
• {original-file-name} está pensado para ser el nombre de archivo original u otro identificador para indicar dónde se originaron los datos del archivo. Este valor es solo con fines de solución de problemas.

La ruta de acceso completa de la carpeta y el identificador de ingesta se usan para asegurarse de que los datos no están duplicados en el almacenamiento o en Azure Data Explorer. El nombre de archivo original se agrega a los segmentos de Azure Data Explorer para fines de solución de problemas, pero no se rastrea ni se utiliza en los centros de FinOps.

Si necesita usar centros de conectividad para supervisar datos que no son de Azure, convierta los datos en FOCUS y colóquelos en el contenedor de ingesta mediante esta guía. Nota La compatibilidad con datos que no son de Azure no se ha probado explícitamente en la versión más reciente. Si experimenta algún problema, cree un problema.

Acerca de las exportaciones en v0.6

Los centros de FinOps usan exportaciones de Cost Management para obtener datos de costos. Cost Management controla la estructura de carpetas de los datos exportados en el contenedor msexports . Una ruta de acceso típica tiene el siguiente aspecto:

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

A partir de la versión 0.4, los hubs de FinOps ya no dependen de rutas de acceso de archivo. Los centros de FinOps utilizan el archivo de manifiesto para identificar el ámbito, el conjunto de datos, el mes, etc. La única parte importante de la ruta de acceso de los centros es el contenedor, que debe ser msexports.

Los manifiestos de exportación pueden cambiar con versiones de API. Este es un ejemplo con la versión 2023-07-01-previewde 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": ###
    }
  ]
}

Los centros de FinOps usan las siguientes propiedades:

• exportConfig.resourceId para identificar el ámbito.
• exportConfig.type para identificar el tipo de conjunto de datos.
• exportConfig.dataVersion para identificar la versión del conjunto de datos.
• runInfo.startDate para identificar el mes exportado.

Los centros de FinOps admiten los siguientes tipos de conjunto de datos, versiones y versiones de API:

• FocusCost: 1.0, 1.0-preview(v1)
• Hoja de Precios: 2023-05-01
• DetallesDeLaReserva: 2023-03-01
• RecomendacionesDeReserva: 2023-05-01
• TransaccionesDeReserva: 2023-05-01
• Versiones de API: 2023-07-01-preview

FinOps Hubs v0.4-0.5

En la siguiente información se describe cómo se procesan los datos en FinOps Hubs v0.4 y v0.5.

Configuración del alcance en v0.4-0.5

1. El desencadenador config_SettingsUpdated se ejecuta cuando se actualiza el archivo settings.json .
2. La canalización de config_ConfigureExports crea nuevas exportaciones para cualquier nuevo ámbito agregado.

Ingesta de datos en v0.4-0.5

Para ámbitos administrados:

1. Los desencadenadores config_DailySchedule y config_MonthlySchedule se ejecutan según sus respectivas programaciones para iniciar la ingesta de datos.
2. La canalización config_ExportData obtiene las exportaciones aplicables para la programación en ejecución.
3. El pipeline config_RunExports ejecuta cada una de las exportaciones seleccionadas.
4. Cost Management exporta los detalles sin procesar de los costos al contenedor msexports. Para obtener más información, consulte Acerca de las exportaciones en v04-05.

Una vez completadas las exportaciones, tanto para ámbitos administrados como no administrados:

1. La pipeline msexports_ExecuteETL inicia el proceso de extracción-transformación-carga (ETL) cuando se agregan archivos al almacenamiento.
2. La canalización de msexports_ETL_ingestion transforma los datos en un esquema estándar y guarda los datos sin procesar en formato parquet en el contenedor de ingesta. Para obtener más información, vea Acerca de la ingesta en v04-05.
3. Power BI lee los datos de costes del contenedor de ingesta.

Acerca de la ingesta en v0.4-0.5

Los centros de FinOps dependen de una ruta de acceso de carpeta específica en el contenedor de almacenamiento de ingesta:

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

• ingestion es el contenedor donde la canalización de datos guarda los datos.
• {dataset} es el tipo de conjunto de datos exportado.
• {month} es el año y mes de los datos exportados formateados como yyyyMM.
• {scope-id} se espera que sea el identificador de recurso completo del ámbito del que proceden los datos.

Si necesita usar centros para supervisar datos que no son de Azure, convierta los datos en FOCUS y colóquelos en el contenedor de ingesta . Este proceso no se probó explícitamente en la versión más reciente. Si experimenta algún problema, cree un problema.

Acerca de las exportaciones en v0.4-0.5

Los centros de FinOps usan exportaciones de Cost Management para obtener datos de costos. Cost Management controla la estructura de carpetas de los datos exportados en el contenedor msexports . Una ruta de acceso típica tiene el siguiente aspecto:

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

A partir de la versión 0.4, los hubs de FinOps ya no dependen de rutas de acceso de archivo. Hubs utiliza el archivo de manifiesto para identificar el ámbito, el conjunto de datos, el mes, etc. La única parte importante de la ruta para los hubs es el contenedor, que debe ser msexports.

Los manifiestos de exportación pueden cambiar con versiones de API. Este es un ejemplo con la versión 2023-07-01-previewde 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": ###
    }
  ]
}

Los centros de FinOps usan las siguientes propiedades:

• exportConfig.resourceId para identificar el ámbito.
• exportConfig.type para identificar el tipo de conjunto de datos.
• exportConfig.dataVersion para identificar la versión del conjunto de datos.
• runInfo.startDate para identificar el mes exportado.

Los centros de FinOps admiten los siguientes tipos de conjunto de datos, versiones y versiones de API:

• FocusCost: 1.0, 1.0-preview(v1)
• Hoja de Precios: 2023-05-01
• DetallesDeLaReserva: 2023-03-01
• RecomendacionesDeReserva: 2023-05-01
• TransaccionesDeReserva: 2023-05-01
• Versiones de API: 2023-07-01-preview

FinOps Hubs v0.2-0.3

En los pasos siguientes se describe el proceso de exportación y procesamiento de datos de costos mediante las versiones 0.2-0.3 de FinOps Hubs:

1. Cost Management exporta los detalles sin procesar de los costos al contenedor msexports.
2. La pipeline msexports_ExecuteETL inicia el proceso de extracción-transformación-carga (ETL) cuando se agregan archivos al almacenamiento.
3. La canalización msexports_ETL_ingestion guarda los datos exportados en formato parquet en el contenedor de ingesta.
4. Power BI lee los datos de costes del contenedor de ingesta.

FinOps Hubs 0.2-0.3 usa la ruta de exportación para determinar el ámbito exportado y el mes. Este punto es importante, ya que las actualizaciones de la ruta de acceso pueden interrumpir las canalizaciones de datos. Para evitar este problema, se recomienda actualizar a FinOps Hubs 0.4. La ruta de acceso esperada debe imitar:

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

• msexports es el contenedor especificado en la exportación.
• {scope-id} es la ruta de la carpeta especificada durante la exportación.

  Hubs 0.3 y versiones anteriores lo usan para identificar el ámbito del que proceden los datos. Se recomienda usar el identificador de ámbito, pero se puede usar cualquier valor. Los identificadores de ámbito de ejemplo incluyen:

  Tipo de ámbito	Ejemplo de valor
  Suscripción	/subscriptions/###
  Grupo de recursos	/subscriptions/###/resourceGroups/###
  Cuenta de facturación	/providers/Microsoft.Billing/billingAccounts/###
  Perfil de facturación	/providers/Microsoft.Billing/billingAccounts/###/billingProfiles/###

• {export-name} es el nombre de la exportación.

  Los hubs ignoran esta carpeta.

• Los datos del intervalo de fechas que se exportan son {date-range}.

  Hubs 0.3 y versiones anteriores lo usan para identificar el mes. El formato de esta carpeta es yyyyMMdd-yyyyMMdd. Hubs 0.4 usa el manifiesto en su lugar.

• {export-time} es una marca de tiempo de cuando se ejecutó la exportación.

  Los centros omiten esto. El formato de esta carpeta es yyyyMMddHHmm.

• {guid} es un GUID único y no siempre está presente.

  Los centros omiten esto. Cost Management no siempre incluye esta carpeta. Si se incluye o no depende de la versión de API que se usa para crear la exportación.

• {file} es un manifiesto o un conjunto de datos exportados.

  La versión 0.3 y anteriores omiten los archivos de manifiesto y solo supervisan los archivos *.csv . En una versión futura, los centros supervisarán el manifiesto.

FinOps Hubs v0.1

En los pasos siguientes se describe el proceso para exportar y procesar datos de costos mediante FinOps Hubs versión 0.1:

1. Cost Management exporta los detalles sin procesar de los costos al contenedor msexports.
2. La canalización de msexports_transform guarda los datos sin procesar en formato parquet en el contenedor de ingesta.
3. Power BI lee los datos de costes del contenedor de ingesta.

Proporcionar comentarios

Déjanos saber cómo lo estamos haciendo con una breve revisión. Usamos estas revisiones para mejorar y expandir herramientas y recursos de FinOps.

Si busca algo específico, vote por una idea existente o cree una idea nueva. Comparta ideas con otros usuarios para obtener más votos. Nos centramos en las ideas con la mayoría de los votos.

Contenido relacionado

• Implementación de centros de FinOps
• Más información