Intégrations des coûts du SaaS

Docs > Cloud Cost Management > Configuration > Intégrations des coûts du SaaS

Profitez de l'aperçu !

Les intégrations de coûts SaaS sont en aperçu.

Présentation

Les intégrations des coûts Saas vous permettent d’envoyer des données de coûts directement depuis vos fournisseurs en configurant les comptes associés à vos données de coûts cloud dans Datadog.

Si votre fournisseur n’est pas pris en charge, utilisez Custom Costs pour charger n’importe quelle source de données de coûts vers Datadog et comprendre le coût total de vos services. Seuls les coûts SaaS en USD sont pris en charge pour le moment.

Configuration

Pour utiliser les intégrations de coûts SaaS, vous devez configurer Cloud Cost Management pour AWS, Azure, Google Cloud ou Oracle Cloud.

Consultez la documentation respective pour votre fournisseur de cloud :

Configurer vos comptes SaaS

Accédez à Cloud Cost > Settings, sélectionnez Accounts, puis cliquez sur Configure sur un fournisseur pour collecter les données de coûts.

Ajoutez vos comptes avec AWS, Azure, Google Cloud pour collecter les données de coûts. Vous pouvez également ajouter vos comptes pour Fastly, Snowflake, Confluent Cloud, MongoDB, Databricks, OpenAI, Twilio et GitHub

Trouvez votre URL de compte Snowflake.
Accédez au carreau d’intégration Snowflake dans Datadog et cliquez sur Add Snowflake Account.
Saisissez votre URL de compte Snowflake dans le champ Account URL. Par exemple : https://xyz12345.us-east-1.snowflakecomputing.com.
Sous la section Connect your Snowflake account, cliquez sur le bouton bascule pour activer Snowflake dans Cloud Cost Management.
Saisissez votre nom d’utilisateur Snowflake dans le champ User Name.
Suivez l’étape 4 de la page d’intégration Snowflake pour créer un rôle et un utilisateur spécifiques à Datadog pour surveiller Snowflake.
Suivez l’étape 5 de la page d’intégration Snowflake pour configurer l’authentification par paire clé-valeur.
Cliquez sur Save.

Vos données de coûts Snowflake des 15 derniers mois sont accessibles dans Cloud Cost Management après 24 heures. Pour accéder aux données disponibles collectées par chaque intégration SaaS Cost Integration, consultez la section Données collectées.

Tags de requête Snowflake

Les tags de requête de Snowflake sont de puissantes chaînes de métadonnées qui peuvent être associées à des requêtes. L’intégration Snowflake Cost Management ingère les tags de requête analysables en JSON présents dans une liste d’autorisation séparée par des virgules trouvée dans le carreau d’intégration Snowflake.

Par exemple, si une organisation souhaite regrouper ses coûts de calcul Snowflake par les dimensions team et application, elle peut choisir de taguer ses requêtes Snowflake pour l’application d’une équipe spécifique de la manière suivante :

ALTER SESSION SET QUERY_TAG = '{"team": "devops", "application": "CI_job_executor"}';

Regrouper les coûts par tags de requête team et application.

En conséquence, les coûts de toutes les requêtes exécutées avec les tags de requête team et application sont attribuables à ces concepts.

Pour utiliser les tags de requête dans la gestion des coûts, assurez-vous que les conditions suivantes sont remplies :

La chaîne query_tag doit être analysable en JSON. Plus précisément, cela signifie que la chaîne peut être traitée par la fonction native PARSE_JSON.
Une liste d’autorisation de clés doit être fournie dans le carreau d’intégration Snowflake. Ces clés correspondent à la première couche du champ query_tag au format JSON. Cette liste d’autorisation apparaît sous la forme d’une liste de chaînes séparées par des virgules, par exemple : tag_1,tag_2,tag_3. Assurez-vous que les chaînes contiennent uniquement des caractères alphanumériques, des traits de soulignement, des traits d’union et des points. Vous pouvez saisir ces informations dans le carreau Snowflake, sous Resources Collected -> Cloud Cost Management -> Collected Query Tags.

Remarque : sélectionnez vos tags de requête en gardant à l’esprit l’ampleur des données. Les tags de requête appropriés sont ceux qui ont une cardinalité de groupe faible à moyenne (par exemple : équipe, utilisateur, service). La sélection d’un tag de requête avec une cardinalité de groupe élevée (comme un UUID unique associé aux exécutions de tâches) peut entraîner des problèmes de goulot d’étranglement pour l’ingestion de données et le rendu frontal.

Tags d’objets CCM Snowflake

Les tags d’objets sont des chaînes définies par l’utilisateur que vous pouvez attacher aux objets Snowflake pour une auditabilité et une analyse des coûts améliorées. Par exemple, pour suivre les coûts par équipe, taguez vos entrepôts avec les équipes respectives qui les utilisent.

Toute la configuration des tags d’objets se fait dans Snowflake.

Remarques :

Héritage de tags : les objets Snowflake adhèrent à une structure hiérarchique, et l’intégration CCM prend en compte les tags hérités lors de la soumission des données de coûts.

Accédez au carreau d’intégration Databricks dans Datadog et cliquez sur Configure.
Saisissez le nom de l’espace de travail, l’URL, l’ID client et le secret client correspondant à votre principal de service Databricks.
Sous la section Select products to set up integration, cliquez sur le bouton bascule pour chaque compte afin d’activer Databricks Cloud Cost Management.
Saisissez un System Tables SQL Warehouse ID correspondant à l’entrepôt de votre instance Databricks pour interroger les données de facturation des tables système.
Cliquez sur Save Databricks Workspace.

Votre principal de service nécessite un accès en lecture aux tables système dans Unity Catalog.

GRANT USE CATALOG ON CATALOG system TO <service_principal>;
GRANT USE SCHEMA ON CATALOG system TO <service_principal>;
GRANT SELECT ON CATALOG system TO <service_principal>;

Vos données de coûts Databricks des 15 derniers mois sont accessibles dans Cloud Cost Management après 24 heures. Pour accéder aux données disponibles collectées par chaque intégration SaaS Cost Integration, consultez la section Données collectées.

Intégrer avec Databricks pour collecter les données de coûts.

Créez une clé API de projet ou une clé API d’administrateur dans les paramètres de votre compte dans OpenAI. Assurez-vous que la clé dispose d’un accès en lecture aux portées d’API Usage et Management.
Accédez au carreau d’intégration OpenAI dans Datadog et cliquez sur Add Account.
Saisissez le nom de votre compte OpenAI, saisissez votre clé API et, éventuellement, spécifiez des tags.
Sous la section Resources, cliquez sur le bouton bascule pour chaque compte afin d’activer OpenAI Billing Usage Data Collection.
Cliquez sur Save.

Vos données de coûts OpenAI des 15 derniers mois sont accessibles dans Cloud Cost Management après 24 heures. Pour accéder aux données disponibles collectées par chaque intégration SaaS Cost Integration, consultez la section Données collectées.

Intégrer avec OpenAI pour collecter les données de coûts.

1. Générer une clé API d’administrateur

Commencez par obtenir une clé API d’administrateur auprès d’Anthropic. Cette clé permet d’accéder aux rapports d’utilisation et de coûts dans toute votre organisation.

Accédez aux paramètres de votre organisation ou contactez l’administrateur de votre compte Anthropic pour créer une nouvelle clé API d’administrateur.
Copiez la clé API dans un emplacement sécurisé.

2. Configurer l’intégration Datadog

Dans Datadog, accédez à Integrations > Anthropic Usage and Costs.
Dans l’onglet Configure, sous Account details, collez la Admin API Key d’Anthropic.
Cliquez sur Save.

Après avoir enregistré votre configuration, Datadog commence à interroger les endpoints d’utilisation et de coûts d’Anthropic à l’aide de cette clé et remplit les métriques dans votre environnement.

Créez un token d’autorisation personnel (classic), avec les portées manage_billing:enterprise et read:org sur la page Personal Access Tokens dans GitHub.
Accédez au carreau GitHub Costs de Datadog.
Cliquez sur Add New.
Saisissez un nom de compte, votre token d’accès personnel et le nom de votre entreprise (au format enterprise-name), ainsi que tous les tags appropriés.
Cliquez sur le bouton de coche pour enregistrer ce compte.

Vos données de coûts GitHub des 15 derniers mois sont accessibles dans Cloud Cost Management dans les 24 heures. Pour accéder aux données disponibles collectées par chaque intégration SaaS Cost Integration, consultez la section Données collectées.

Intégrer avec GitHub pour collecter les données de coûts.

Créez ou acquérez une clé API avec le rôle billing admin dans Confluent Cloud.
Accédez au carreau d’intégration Confluent Cloud dans Datadog et cliquez sur Add Account.
Saisissez le nom de votre compte Confluent Cloud, la clé API, le secret API et, éventuellement, spécifiez des tags.
Sous la section Resources, cliquez sur le bouton bascule pour Collect cost data to view in Cloud Cost Management.
Cliquez sur Save.

Vos données de coûts Confluent Cloud deviennent disponibles dans Cloud Cost Management 24 heures après la configuration. Ces données incluent automatiquement 12 mois d’historique, le maximum fourni par l’API de facturation Confluent. Au cours des trois prochains mois, les données s’étendront progressivement pour couvrir 15 mois d’historique. Pour accéder aux données disponibles collectées par chaque intégration SaaS Cost Integration, consultez la section Données collectées.

Si vous souhaitez collecter des tags au niveau du cluster ou des tags de métadonnées métier pour vos coûts, vous pouvez ajouter une clé API et un secret Schema Registry. Veuillez consulter Schema Management on Confluent Cloud pour plus d’informations.

Intégrer avec Confluent pour collecter les données de coûts.

Créez un token API dans MongoDB avec les autorisations Organizational Billing Viewer et ajoutez les autorisations Organizational Read Only pour les tags de ressources de cluster.
Accédez au carreau d’intégration MongoDB Cost Management dans Datadog et cliquez sur Add New.
Saisissez le nom de votre compte MongoDB, la clé publique, la clé privée, l’ID organisationnel et, éventuellement, spécifiez des tags.
Cliquez sur Save.

Vos données de coûts MongoDB des 15 derniers mois sont accessibles dans Cloud Cost Management après 24 heures. Pour accéder aux données disponibles collectées par chaque intégration SaaS Cost Integration, consultez la section Données collectées.

Intégrer avec MongoDB pour collecter les données de coûts.

Accédez à la section API Key dans les paramètres de votre organisation Elastic Cloud.
Cliquez sur Create New Key.
Choisissez un Name et une Expiration Date pour votre clé API.
Sélectionnez le rôle Billing Admin.
Cliquez sur Create Key pour générer la clé.
Accédez au carreau d’intégration Elastic Cloud dans Datadog
Cliquez sur Add Account.
Saisissez votre Elastic Cloud Organization ID et votre Billing API Key dans le tableau de comptes.

Vos données de coûts Elastic Cloud des 15 derniers mois sont accessibles dans Cloud Cost Management après 24 heures. Pour accéder aux données disponibles collectées par chaque intégration SaaS Cost Integration, consultez la section Données collectées.

Intégrer avec Elastic Cloud pour collecter les données de coûts.

Créez un token API avec au moins la portée "global:read" et le rôle "Billing" sur la page Personal API tokens dans Fastly.
Accédez au carreau d’intégration de gestion des coûts Fastly dans Datadog et cliquez sur Add New.
Saisissez le nom de votre compte Fastly et le token API.
Cliquez sur Save.

Vos données de coûts Fastly des 15 derniers mois sont accessibles dans Cloud Cost Management après 24 heures. Pour accéder aux données disponibles collectées par chaque intégration SaaS Cost Integration, consultez la section Données collectées.

Intégrer avec Fastly pour collecter les données de coûts.

Accédez au carreau d’intégration Twilio dans Datadog et cliquez sur Add Account.
Sous la section Resources, cliquez sur le bouton bascule pour chaque compte afin d’activer Twilio in Cloud Cost Management.
Saisissez un Account SID pour votre compte Twilio.
Cliquez sur Save.

Vos données de coûts Twilio des 15 derniers mois sont accessibles dans Cloud Cost Management après 24 heures. Pour accéder aux données disponibles collectées par chaque intégration SaaS Cost Integration, consultez la section Données collectées.

Intégrer avec Twilio pour collecter les données de coûts.

Données collectées

Vous pouvez consulter les données de coûts sur la page Cloud Cost Explorer, le Cloud Cost Tag Explorer, et dans les dashboards, notebooks ou monitors. Vous pouvez également combiner ces métriques de coûts avec d’autres métriques de coûts cloud ou métriques d’observabilité.

Le tableau suivant contient une liste non exhaustive de tags prêts à l’emploi associés à chaque intégration SaaS Cost.

Nom du tag	Description du tag
`account_locator`	Localisateur du compte où l'utilisation a été consommée.
`account_name`	Nom du compte où l'utilisation a été consommée.
`balance_source`	Source des fonds utilisés pour payer l'utilisation quotidienne. La source peut être l'une des suivantes : - capacity : utilisation payée avec les crédits restants sur l'engagement de capacité d'une organisation. - rollover : utilisation payée avec des crédits reportés. Lorsqu'une organisation renouvelle un engagement de capacité, les crédits inutilisés sont ajoutés au solde du nouveau contrat en tant que crédits reportés. - free usage : utilisation couverte par les crédits gratuits fournis à l'organisation. - overage : utilisation payée au tarif à la demande, qui se produit lorsqu'une organisation a épuisé ses crédits de capacité, de report et gratuits. - rebate : utilisation couverte par les crédits attribués à l'organisation lorsqu'elle a partagé des données avec une autre organisation.
`billing_type`	Indique ce qui est facturé ou crédité. Les types de facturation possibles incluent : - consumption : utilisation associée aux crédits de calcul, aux coûts de stockage et aux coûts de transfert de données. - rebate : utilisation couverte par les crédits attribués à l'organisation lorsqu'elle a partagé des données avec une autre organisation. - priority support : frais pour les services d'assistance prioritaire. Ces frais sont associés à une stipulation dans un contrat, et non à un compte. - vps_deployment_fee : frais pour un déploiement Virtual Private Snowflake. - support_credit : l'assistance Snowflake a crédité le compte pour annuler les frais attribués à un problème dans Snowflake.
`charge_description`	Une description du type de coût associé à des lignes distinctes. Les descriptions diffèrent pour chaque type de coût, représenté par le tag `servicename`.
`contract_number`	Numéro de contrat Snowflake pour l'organisation.
`database_name`	Nom de la base de données dans laquelle la requête a été exécutée (le cas échéant). Trouvé uniquement pour les coûts d'attribution de requête.
`organization_name`	Nom de l'organisation.
`query_hash`	Hachage unique représentant une version paramétrée de la requête à des fins d'attribution. Trouvé uniquement pour les coûts d'attribution de requête.
`query_hash_version`	Version de l'algorithme de hachage de requête Snowflake utilisé pour générer `query_hash`. Trouvé uniquement pour les coûts d'attribution de requête.
`rating_type`	Indique comment l'utilisation dans l'enregistrement est évaluée ou tarifée. Les valeurs possibles incluent : - compute - data_transfer - storage - Other
`region`	Nom de la région où se trouve le compte.
`service_level`	Niveau de service (édition) du compte Snowflake (Standard, Enterprise ou Business Critical).
`servicename`	Type d'utilisation. Les types de service possibles incluent : - automatic_clustering : consultez Automatic Clustering. - data_transfer : consultez Understanding data transfer cost. - logging : consultez Logging and Tracing Overview. - materialized_view : consultez Working with Materialized Views. - replication : consultez Introduction to replication and failover across multiple accounts. - query_acceleration : consultez Using the Query Acceleration Service. - search_optimization : consultez Search Optimization Service. - serverless_task : consultez Introduction to tasks. - snowpipe : consultez Snowpipe. - snowpipe_streaming : consultez Snowpipe Streaming. - storage : consultez Understanding storage cost. - warehouse_metering_query_attribution : consultez Virtual warehouse credit usage of queries avec un temps d'exécution de 100 ms ou plus. N'indique pas l'utilisation de calcul serverless ou de services cloud. - warehouse_metering_query_attribution : consultez Virtual warehouse credit usage of queries avec un temps d'exécution de 100 ms ou moins, ainsi que le temps d'inactivité de l'entrepôt. N'indique pas l'utilisation de calcul serverless ou de services cloud.
`user_name`	Nom de l'utilisateur ou du compte de service associé à la requête.
`warehouse_id`	Identifiant de l'entrepôt générant le coût.
`warehouse_name`	Nom de l'entrepôt associé à cette utilisation.
`warehouse_size`	Taille de l'entrepôt (par exemple, Large, Medium).

Remarque : l’intégration de coûts Databricks calcule les coûts à l’aide des prix catalogue et des données d’utilisation. Elle ne reflète aucun tarif négocié ou réduit.

Nom du tag	Description du tag
`account_id`	ID du compte pour lequel ce rapport a été généré.
`billing_origin_product`	Produit ou fonctionnalité à l'origine de l'événement de facturation (par exemple, JOBS, CLUSTERS).
`central_clean_room_id`	ID de la salle propre centrale associée à la charge de travail (le cas échéant).
`charge_description`	Une combinaison du type de cloud et du nom du SKU associé (par exemple, AWS - PREMIUM_ALL_PURPOSE_COMPUTE).
`cloud`	Cloud pour lequel cette utilisation est pertinente. Les valeurs possibles sont AWS, AZURE et GCP.
`cluster_id`	ID du cluster associé à cette utilisation.
`custom_tags`	Tags personnalisés appliqués à l'utilisation, généralement sous forme de paires clé-valeur pour des métadonnées ou une catégorisation supplémentaires.
`destination_region`	Région vers laquelle la charge de travail est dirigée (le cas échéant).
`dlt_maintenance_id`	ID de maintenance pour Delta Live Tables (le cas échéant).
`dlt_pipeline_id`	ID du pipeline Delta Live Tables (le cas échéant).
`dlt_tier`	Niveau du service Delta Live Tables (le cas échéant).
`dlt_update_id`	ID de mise à jour Delta Live Table associé à cette utilisation (le cas échéant).
`endpoint_id`	ID de l'endpoint pour une utilisation basée sur SQL ou liée à la diffusion (le cas échéant).
`endpoint_name`	Nom de l'endpoint SQL ou de diffusion (le cas échéant).
`instance_pool_id`	ID du pool d'instances utilisé (le cas échéant).
`is_photon`	Indique si le traitement Photon a été utilisé (`true` ou `false`).
`is_serverless`	Indique si l'utilisation concerne une ressource de calcul serverless (`true` ou `false`).
`job_id`	Identifiant unique de la tâche dans Databricks.
`job_name`	Nom de la tâche dans Databricks (le cas échéant).
`job_run_id`	Identifiant de l'exécution spécifique de la tâche (le cas échéant).
`jobs_tier`	Niveau de la tâche, tel que `CLASSIC` ou `PREMIUM`.
`networking`	Type de réseau utilisé pour cette tâche, s'il est spécifié.
`node_type`	Type de nœud utilisé dans cet enregistrement de facturation (par exemple, m5d.large).
`notebook_id`	ID du notebook utilisé dans cet enregistrement de facturation (le cas échéant).
`notebook_path`	Chemin vers le notebook dans Databricks (le cas échéant).
`record_id`	ID unique pour cet enregistrement.
`run_name`	Nom de l'exécution actuelle de la tâche ou du workflow (le cas échéant).
`serving_type`	Type de modèle de diffusion utilisé, le cas échéant (par exemple, Model Serving).
`source_region`	Région d'origine pour cet enregistrement de facturation (le cas échéant).
`sql_tier`	Niveau SQL associé à l'utilisation (le cas échéant).
`usage_metadata`	Métadonnées relatives à l'utilisation, qui peuvent inclure des détails tels que le type d'utilisation, la catégorie de service ou d'autres informations pertinentes.
`usage_type`	Type d'utilisation facturée (par exemple, COMPUTE_TIME).
`warehouse_id`	ID de l'entrepôt SQL (le cas échéant).
`workspace_id`	ID de l'espace de travail auquel cette utilisation a été associée.

Nom du tag	Description du tag
`charge_description`	Le nom du modèle dont les coûts sont associés aux frais.
`organization_id`	L’identifiant unique de l’organisation.
`organization_name`	Le nom de l’organisation.
`project_id`	L’identifiant unique du projet.
`project_name`	Le nom du projet.

Nom du tag	Description du tag
`workspace_id`	L’identifiant unique de l’espace de travail Anthropic.
`workspace_name`	Une version normalisée en tag du nom de l’espace de travail.
`display_workspace_name`	Le nom non modifié de l’espace de travail.
`org_id`	L’identifiant unique de l’organisation Anthropic.
`org_name`	Une version normalisée en tag du nom de l’organisation Anthropic.
`display_org_name`	Le nom non modifié de l’organisation.
`model_id`	L’identifiant de modèle Anthropic canonique (par exemple, `claude-3-opus-20240229`).
`model`	Un alias pour `model_id`, fourni pour la compatibilité et la cohérence avec l’utilisation et les métriques.
`model_name`	Le nom convivial du modèle (par exemple, `Claude 3 Opus`).
`service_tier`	Le plan ou niveau de service Anthropic associé à l’utilisation (par exemple, `standard`, `pro`, `enterprise`).
`token_type`	La catégorie de tokens consommés.
`context_window`	La taille de la fenêtre de contexte pour les tokens (par exemple, `tier_0-200k`).

Remarque : l’intégration de coûts GitHub estime les coûts en fonction des prix catalogue et des données d’utilisation, et inclut les valeurs de remise lorsqu’elles sont disponibles. Elle ne tient pas compte des tarifs négociés.

Nom du tag	Description du tag
`enterprise_name`	Chaîne alphanumérique identifiant le compte d’entreprise GitHub.
`charge_description`	La description des frais.
`product`	Le produit d’utilisation, par exemple « actions » ou « storage ».
`organization_name`	L’organisation GitHub.
`repository_name`	Le référentiel GitHub.
`billing_currency`	La devise de facturation, par exemple « USD ».
`discount`	Si l’élément de coût est une remise.

Nom du tag	Description du tag
`charge_description`	Le sous-type du coût (par exemple, KAFKA_NETWORK_WRITE).
`environment_id`	L'identifiant unique de l'environnement.
`network_access_type`	Type d'accès réseau pour le cluster. Les valeurs possibles sont `INTERNET`, `TRANSIT_GATEWAY`, `PRIVATE_LINK` et `PEERED_VPC`.
`product`	Nom du produit. Les valeurs possibles incluent `KAFKA`, `CONNECT`, `KSQL`, `AUDIT_LOG`, `STREAM_GOVERNANCE`, `CLUSTER_LINK`, `CUSTOM_CONNECT`, `FLINK`, `SUPPORT_CLOUD_BASIC`, `SUPPORT_CLOUD_DEVELOPER`, `SUPPORT_CLOUD_BUSINESS` et `SUPPORT_CLOUD_PREMIER`.
`resource_id`	L'identifiant unique de la ressource Confluent.
`resource_name`	Le nom de la ressource Confluent.

Nom du tag	Description du tag
`charge_description`	Le SKU d’un coût.
`kind`	Le type de ressource.
`name`	L’identifiant unique de la ressource Elastic Cloud.
`price_per_hour`	Le coût de la ressource Elastic Cloud par heure.

Nom du tag	Description du tag
`charge_description`	La description d’un coût.
`cluster_name`	Le nom du cluster qui a engendré les frais.
`group_id`	ID du projet auquel la ligne est associée.
`invoice_id`	L’identifiant unique de la facture.
`mongo_org_id`	ID de l’organisation MongoDB.
`replica_set_name`	Nom de l’ensemble de répliques auquel la ligne est associée.
`resource_tags`	Tags arbitraires sur les clusters définis par les utilisateurs, généralement sous forme de paires clé-valeur.
`status`	État du paiement.

Nom du tag	Description du tag
`charge_description`	La description des frais.
`credit_coupon_code`	Code de tout coupon ou crédit appliqué à cette entrée de coût (si disponible).
`plan_name`	Nom du plan sous lequel ce service s'inscrit, correspondant souvent à « product_line ».
`product_name`	Nom du produit spécifique facturé (par exemple, « North America Bandwidth »).
`product_group`	Groupe ou catégorie du produit, tel que « Full Site Delivery ».
`product_line`	Ligne de produits à laquelle cet élément appartient, par exemple, « Network Services ».
`region`	Région où l'utilisation du service s'est produite (par exemple, « North America »).
`service_name`	Nom du service associé à cette entrée de coût, correspondant souvent au `product_name`.
`usage_type`	Type d'utilisation facturée (par exemple, « Bandwidth »).
`usage_type_cd`	Code ou étiquette représentant le type d'utilisation, tel que « North America Bandwidth ».

Nom du tag	Description du tag
`account_sid`	Chaîne alphanumérique identifiant le compte Twilio.
`category`	La catégorie d'utilisation. Pour plus d'informations, consultez la section Usage Categories.
`charge_description`	La description des frais.
`count_unit`	Les unités dans lesquelles le nombre est mesuré, telles que les appels pour les appels ou les messages pour les SMS.
`usage_unit`	Les unités dans lesquelles l'utilisation est mesurée, telles que les minutes pour les appels ou les messages pour les SMS.