Nota: Cualquier mención de v1 y v2 en este documento no se refiere a la versión en la ruta URL. Todas las APIs de esta documentación son las primeras versiones con sus respectivas rutas, por lo que utilizan v1 en la ruta URL.
La API v2 de atribución de uso mensual Obtener atribución de uso mensual también muestra la atribución de uso mensual y ofrece la posibilidad de hacer consultas según combinaciones de etiquetas.
Consulte las secciones a continuación para ver las diferencias entre la API v1 y v2 y recomendaciones para migrar a la API v2.
En la API v1 API puedes configurar la paginación mediante los parámetros de consulta offset y limit. El valor en
metadata.pagination.total_number_of_records muestra el número total de registros en todas las páginas.
En la API v2 puedes configurar la paginación mediante el parámetro de consulta next_record_id. El valor inicial de la página siguiente se muestra
en metadata.pagination.next_record_id. La respuesta no incluye el número total de registros.
Para migrar a la API v2, usa next_record_id para cambiar de página como se explica en la página de documentación de la API.
En la API v1, los datos de uso se desglosan por separado para cada etiqueta en la misma respuesta. Esto da lugar a datos aparentemente duplicados, en los que se cuenta el mismo recurso en varias etiquetas, como por ejemplo a, b y c por separado.
En la API v2 puedes seleccionar el desglose por etiquetas introduciendo una configuración de etiquetas en el parámetro tag_breakdown_keys. Puedes introducir las etiquetas una por una o varias etiquetas en una lista separada por comas. Si introduces varias etiquetas, se mostrará el uso filtrado por la combinación de dichas etiquetas.
Para migrar a la API v2, especifica las etiquetas a usar en el parámetro tag_breakdown_keys. Para obtener
los mismos desgloses que en la API v1, haz consultas distintas para cada etiqueta.
En la API v1, la sección aggregates contiene las sumas de todos los registros posibles, lo que da un resultado tres veces mayor al número real, ya que los datos se triplican en tres etiquetas distintas. Por ejemplo:
Esta API proporciona un enlace para descargar un archivo .zip con los datos de atribución de uso para todos los productos en un día concreto. El archivo .zip
contiene un archivo TSV (tab separated value, valores separados por tabuladores) para cada producto.
En la API v1, la respuesta contiene un enlace a un archivo ZIP que contiene un archivo TSV para cada producto.
En la API v2, la respuesta contiene los datos de atribución de uso en formato JSON.
Para migrar a la API v2, tus procesos tienen que gestionar los datos en formato JSON. Puedes aplicar las conversiones necesarias a los datos JSON para crear el formato que mejor se adapte a tus necesidades.
En la API v1, los datos de uso se desglosan según las etiquetas elegidas.
En la API v2, puedes seleccionar el desglose de etiquetas introduciendo una configuración de etiquetas en tag_breakdown_keys, en formato de lista separada por comas.
Para migrar a la API v2, especifica todas las etiquetas seleccionadas en el parámetro de consulta tag_breakdown_keys .
En la API v1, si un recurso tiene varios casos de la misma etiqueta, aparece como una cadena separada por barras verticales (|) en la columna de la etiqueta.
En la API v2, el valor correspondiente a cada clave de etiqueta en el objeto tags es una matriz. Si hay varias instancias de la misma etiqueta en un recurso,
esto indica que la lista contiene varios elementos.
Para migrar a la API v2, tus procesos deben gestionar recursos con la misma etiqueta aplicada varias veces.
Los valores de etiquetas en la matriz de respuesta v2 aparecen en el mismo orden que en la cadena separada por barras verticales en la respuesta v1,
así que puedes unir la matriz con barras verticales para generar los mismos valores de etiquetas que en la respuesta v1.
En la API v1, el formato de fecha y hora es YYYY-MM-DD hh:mm:ss.
En la API v2, el formato de fecha y hora es YYYY-MM-DDThh.
Los datos en el formato v1 siempre usan el valor 0 para minutos y segundos (los datos son horarios). Los datos en el formato v2 pueden ser parseados y tratados como equivalentes a la hora parseada del formato v1.
En la API v1, el archivo solo contiene datos para la configuración de etiquetas definida en la organización principal. Esto incluye todas las organizaciones secundarias de la principal, porque las configuraciones de etiquetas también se aplican a las organizaciones secundarias.
En la API v1, si se provee el parámetro include_descendants=true (esto es el valor por defecto), la respuesta contiene datos para la organización principal y todas sus organizaciones secundarias. Esto incluye todos los datos de las configuraciones de etiquetas heredadas de la organización principal por las secundarias y también incluye configuraciones de etiquetas definidas directamente para dichas organizaciones secundarias. Se puede ver el origen de una configuración de etiquetas específica en el campo tag_config_source.
Para migrar a la API v2, pasa el parámetro include_descendants=true. Para obtener los mismos valores que en la respuesta v1, filtra todos los registros en la respuesta que no coincidan con tag_config_source en la configuración de etiquetas
de la organización principal.
En la API v1, se devuelven los datos para un solo día. La fecha se especifica en el parámetro record_id de la
solicitud.
En la API v2, puedes recuperar los datos para periodos de tiempo arbitrarios, hasta 24 horas en una solicitud, usando los parámetros start_hr
y end_hr.
Para migrar a la API v2, solicita datos con start_hr como media noche (00 horas) del día deseado
y end_hr como media noche del día siguiente.
En la API v1, los datos no están paginados. Esto puede dar lugar a archivos muy grandes.
En la API v2, los datos están paginados. Si una respuesta ocupa más de una página, la ID para obtener la página siguiente se
muestra en el campo metadata.pagination.next_record_id. Puedes introducir este valor en el parámetro de consulta next_record_id
para obtener la página siguiente.
Para migrar a la API v2, recupera todas las páginas para el día concreto.
Esta API devuelve un enlace para descargar un archivo ZIP con los datos de atribución de uso para todos los productos durante un mes concreto. El archivo ZIP
contiene un archivo TSV para cada producto y un archivo resumen para cada etiqueta. Los métodos para replicar ambos tipos de archivos se explican a continuación.
Los archivos de datos horarios usan el formato de nombre monthly_<product>_<date>.tsv. Cada archivo de producto es una versión concatenada
de los archivos ZIP diarios disponibles
en Obtener los informes personalizados diarios especificados
.
Dado que los archivos de datos horarios son muy similares a los archivos disponibles
en Obtener los informes personalizados diarios especificados
, la misma guía es aplicable excepto la recomendación para rangos de tiempo. Para migrar desde los archivos mensuales v1,
solicita todas las páginas para cada día del mes. Las solicitudes tienen un límite de 24 horas por solicitud en la API v2.
Los archivos de resumen mensuales usan el formato de nombresummary_<tag>_<date>.tsv. Proporcionan rollup para todo el uso durante
el mes para cada etiqueta. La API Obtener atribución de uso mensual
proporciona los mismos datos.
Consulta las secciones siguientes para ver las diferencias entre la API v1 y la API v2 junto con recomendaciones para migrar a la API v2.
La respuesta de la API v1 contiene un enlace a un archivo ZIP, que contiene un archivo TSV para cada etiqueta seleccionada.
La respuesta de la API v2 devuelve los datos de atribución de uso en formato JSON.
Para migrar a la API v2, tus procesos tienen que gestionar los datos en formato JSON. Puedes aplicar las conversiones necesarias a los datos JSON para crear el formato que mejor se adapte a tus necesidades.
En la API v1, hay un archivo TSV distinto para cada etiqueta elegida.
En la API v2, puedes seleccionar el desglose por etiquetas introduciendo una configuración de etiquetas en tag_breakdown_keys como una lista separada por comas.
Para migrar a la API v2, haz solicitudes con cada etiqueta especificada de forma individual en tag_breakdown_keys.
En la API v1, si un recurso está etiquetado con la misma etiqueta varias veces, se muestra como una cadena separada por barras verticales (|)
en la columna de la etiqueta.
Ejemplo:
month public_id team infra_host_usage ....
2022-01 abc123 billing|sre 100
...
En la API v2, el valor correspondiente a cada clave de etiqueta en el objeto tags es una matriz. Si un recurso está etiquetado varias veces con la misma etiqueta, la lista contiene varios elementos.
Ejemplo:
...
"tags": {
"team": [
"billing",
"sre"
]
},
...
Para migrar a la API v2, tus procesos deben gestionar recursos con la misma etiqueta aplicada varias veces.
Los valores de etiquetas en la matriz de respuesta v2 aparecen en el mismo orden que en la cadena separada por barras verticales en la respuesta v1,
así que puedes unir la matriz con barras verticales para generar los mismos valores de etiquetas que en la respuesta v1.
En la API v1, el archivo solo contiene datos para la configuración de etiquetas definida en la organización principal. Esto incluye todas las organizaciones secundarias
de la principal, porque las configuraciones de etiquetas también se aplican a las organizaciones secundarias.
En la API v1, si se provee el parámetro include_descendants=true (esto es el valor por defecto), la respuesta contiene datos para la organización principal y todas sus organizaciones secundarias.
Esto incluye todos los datos de las configuraciones de etiquetas heredadas de la organización principal por las secundarias y también incluye configuraciones de etiquetas definidas directamente para dichas organizaciones secundarias. Se puede ver el origen de una configuración de etiquetas específica en el campo tag_config_source.
En la API v1, el uso de la monitorización serverless usa los siguientes nombres:
lambda_functions_usage
lambda_functions_percentage
lambda_invocations_usage
lambda_invocations_percentage
En la API v2, el uso de la monitorización serverless usa los siguientes nombres:
functions_usage
functions_percentage
invocations_usage
invocations_percentage
Para migrar a la API v2, consulta el uso de monitorización serverless bajo los nombres actualizados de los campos. Estos tipos de uso son equivalentes funcionalmente. La única diferencia es el nuevo nombre del campo.
