Présentation

Les coûts SaaS et IA 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.

snowflake
databricks
openai
anthropic
cursor
temporal cloud
github
confluent cloud
mongodb
elastic cloud
fastly
twilio

Si votre fournisseur n’est pas pris en charge, utilisez Coûts personnalisés pour importer n’importe quelle source de données de coûts dans 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

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

Ajoutez vos comptes AWS, Azure et 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, GitHub, Cursor et Temporal Cloud
  1. Trouvez votre URL de compte Snowflake.

    Le menu de compte avec l'option de copie de l'URL de compte sélectionnée dans l'interface utilisateur de Snowflake
  2. Accédez à la tuile d’intégration Snowflake dans Datadog et cliquez sur Add Snowflake Account.

  3. Saisissez l’URL de votre compte Snowflake dans le champ Account URL. Par exemple : https://xyz12345.us-east-1.snowflakecomputing.com.

  4. Sous la section Connect your Snowflake account, cliquez sur le bouton bascule pour activer Snowflake dans Cloud Cost Management.

  5. Saisissez votre nom d’utilisateur Snowflake dans le champ User Name.

  6. Suivez l’étape 4 de la page Intégration Snowflake pour créer un rôle et un utilisateur spécifiques à Datadog afin de surveiller Snowflake.

  7. Suivez l’étape 5 de la page Intégration Snowflake pour configurer l’authentification par paire clé-valeur.

  8. Cliquez sur Save.

Les données de coût Snowflake des 6 derniers mois sont disponibles dans Cloud Cost Management sous 24 heures. Pour accéder aux données disponibles collectées par chaque intégration de coût SaaS, consultez la section Données collectées.

Tags de requête Snowflake

Les tags de requête de Snowflake sont des chaînes de métadonnées puissantes qui peuvent être associées aux requêtes. L’intégration de gestion des coûts Snowflake ingère des tags de requête analysables au format JSON présents dans une liste d’autorisation séparée par des virgules trouvée dans la tuile 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"}';
Regroupez les coûts par tags de requête d'application et d'équipe.

Par conséquent, 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 des points suivants :

  • La chaîne query_tag doit être analysable au format JSON. Plus précisément, cela signifie que la chaîne est traitable par la fonction native PARSE_JSON.

  • Une liste d’autorisation de clés doit être fournie dans la tuile 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 ne contiennent que des caractères alphanumériques, des traits de soulignement, des traits d’union et des points. Vous pouvez saisir ces informations dans la tuile Snowflake, sous Resources Collected > Cloud Cost Management > Collected Query Tags.

Remarque : Sélectionnez vos tags de requête en tenant compte de 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 (telle qu’un UUID unique associé à des exécutions de jobs) peut entraîner des problèmes de goulot d’étranglement pour l’ingestion de données et le rendu frontal.

Tags d’objet Snowflake CCM

Les tags d’objet sont des chaînes définies par l’utilisateur que vous pouvez associer aux objets Snowflake pour une meilleure auditabilité et une analyse des coûts. 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’objet s’effectue dans Snowflake.

Remarques :

  • Héritage de tags : les objets Snowflake respectent 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ût.

    Intégrez Snowflake pour collecter des données de coût.
  1. Accédez à la tuile d’intégration Databricks dans Datadog et cliquez sur Configure.
  2. Saisissez le nom de l’espace de travail, l’URL, l’ID client et le secret client correspondant à votre principal de service Databricks.
  3. Sous la section Select products to set up integration, cliquez sur le bouton bascule pour chaque compte afin d’activer Databricks Cloud Cost Management.
  4. 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.
  5. Cliquez sur Save Databricks Workspace.

Votre principal de service nécessite un accès en lecture aux tables système au sein d’Unity Catalog. Dans Databricks, ouvrez le SQL Editor et exécutez les commandes suivantes, en utilisant l’ID client du principal de service (et non son nom d’affichage) :

GRANT USE CATALOG ON CATALOG system TO `<CLIENT-ID>`;
GRANT USE SCHEMA ON CATALOG system TO `<CLIENT-ID>`;
GRANT SELECT ON CATALOG system TO `<CLIENT-ID>`;

Vos données de coût 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 de coût SaaS, consultez la section Données collectées.

Intégrez Databricks pour collecter des données de coût.
Une clé d'API avec périmètre administrateur est requise pour collecter les données de coût OpenAI pour Cloud Cost Management. Les clés d'API avec périmètre projet ne peuvent pas collecter de données de coût.
  1. Créez une clé d’API administrateur dans les paramètres de votre compte OpenAI :
    • Connectez-vous à votre compte OpenAI.
    • Accédez à la page des clés administrateur ou allez dans API keys sous Organization settings et sélectionnez l’onglet Admin keys.
    • Cliquez sur Create a new secret key et copiez la clé d’API administrateur créée.
  2. Accédez à la tuile d’intégration OpenAI dans Datadog et cliquez sur Add Account.
  3. Saisissez le nom de votre compte OpenAI, entrez votre clé d’API administrateur et, éventuellement, spécifiez des tags.
  4. Sous la section Resources, cliquez sur le bouton bascule de chaque compte pour activer OpenAI Billing Usage Data Collection.
  5. Cliquez sur Save.

Vos données de coût 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 de coût SaaS, consultez la section Données collectées.

Intégrez OpenAI pour collecter des données de coût.

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

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

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

2. Configurez l’intégration Datadog

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

Une fois votre configuration enregistrée, Datadog commence à interroger les endpoints d’utilisation et de coûts d’Anthropic à l’aide de cette clé, et renseigne les métriques dans votre environnement.

Remarque : Pour suivre les coûts des comptes Anthropic Enterprise et des comptes de plateforme, répétez les étapes de configuration pour ajouter une entrée de compte distincte pour chaque type de clé d’API. Utilisez la clé d’API administrateur pour l’utilisation standard de la plateforme, et la clé d’API Enterprise Analytics pour l’utilisation d’Anthropic Enterprise.

Un forfait Enterprise et un rôle d'administrateur d'équipe sont requis pour générer une clé d'API administrateur Cursor. Les comptes avec un forfait d'équipe standard renvoient des erreurs d'accès refusé.

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

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

  1. Dans le dashboard Cursor, accédez à Settings > Advanced > Admin API Keys.
  2. Créez une nouvelle clé d’API administrateur et copiez-la dans un emplacement sécurisé.

2. Configurez l’intégration Datadog

  1. Dans Datadog, accédez à Integrations > Cursor.
  2. Sous l’onglet Configure, dans Account details, collez la Admin API Key provenant de Cursor.
  3. Dans la section Resources, cliquez sur le bouton bascule de chaque compte pour activer Cursor in Cloud Cost Management.
  4. Cliquez sur Save.

Une fois votre configuration enregistrée, Datadog commence à interroger les endpoints d’utilisation et de coûts de Cursor à l’aide de cette clé, et renseigne les métriques dans votre environnement. Vos données de coûts Cursor 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 de coût SaaS, consultez la section Données collectées.

Un compte de service doté du rôle Finance Admin ou Account Owner est requis pour générer une clé d'API de facturation Temporal Cloud. Les rôles Metrics Read-Only et Account Admin ne peuvent pas accéder à l'API de facturation.

1. Générez une clé d’API de facturation

  1. Dans Temporal Cloud, accédez à Settings > Service Accounts > Create Service Account.
  2. Attribuez au compte de service le rôle Finance Admin ou Account Owner.
  3. Générez une clé d’API pour le compte de service et copiez-la dans un emplacement sécurisé. Temporal Cloud n’affiche la clé qu’une seule fois.

2. Configurez l’intégration Datadog

  1. Dans Datadog, accédez à Integrations > Temporal Cloud Cost Management.
  2. Cliquez sur Install Integration, puis cliquez sur Configure.
  3. Cliquez sur Add Account et collez la clé d’API de facturation provenant de Temporal Cloud.
  4. Cliquez sur Save.

Une fois votre configuration enregistrée, Datadog commence à interroger l’API de facturation Temporal Cloud à l’aide de cette clé et renseigne les métriques dans votre environnement. Vos données de coût Temporal Cloud sont accessibles dans Cloud Cost Management sous 25 à 30 heures. Pour accéder aux données disponibles collectées par chaque intégration de coût SaaS, consultez la section Données collectées.

  1. Créez un jeton d’autorisation personnel (classique), avec les périmètres manage_billing:enterprise et read:org sur la page Personal Access Tokens dans GitHub.
  2. Accédez à la tuile GitHub Costs de Datadog.
  3. Cliquez sur Add New.
  4. Saisissez un nom de compte, votre jeton d’accès personnel et votre nom d’entreprise (au format enterprise-name), ainsi que tous les tags appropriés.
  5. Cliquez sur le bouton en forme de coche pour enregistrer ce compte.

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

Intégrez-vous à GitHub pour collecter des données de coût.
  1. Créez ou obtenez une clé d’API avec le rôle billing admin dans Confluent Cloud.
  2. Accédez à la tuile d’intégration Confluent Cloud dans Datadog et cliquez sur Add Account.
  3. Saisissez le nom de votre compte Confluent Cloud, votre clé d’API, votre secret API et, éventuellement, spécifiez des tags.
  4. Sous la section Resources, cliquez sur le bouton bascule pour Collect cost data to view in Cloud Cost Management.
  5. Cliquez sur Save.

Vos données de coût 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 de coût SaaS, 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é d’API et un secret Schema Registry. Veuillez consulter Schema Management on Confluent Cloud pour plus d’informations.

Intégrez-vous à Confluent pour collecter des données de coût.
  1. Créez un jeton d’API dans MongoDB avec les autorisations Organizational Billing Viewer, et ajoutez les autorisations Organizational Read Only pour les tags de ressources de cluster.
  2. Accédez à la tuile d’intégration MongoDB Cost Management dans Datadog et cliquez sur Add New.
  3. Saisissez le nom de votre compte MongoDB, votre clé publique, votre clé privée, votre ID d’organisation et, éventuellement, spécifiez des tags.
  4. Cliquez sur Save.

Vos données de coût 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 de coût SaaS, consultez la section Données collectées.

Intégrez-vous à MongoDB pour collecter des données de coût.
  1. Accédez à la section API Key dans les paramètres de votre organisation Elastic Cloud.
  2. Cliquez sur Create New Key.
  3. Choisissez un Name et Expiration Date pour votre clé d’API.
  4. Sélectionnez le rôle Billing Admin.
  5. Cliquez sur Create Key pour générer la clé.
  6. Accédez à la tuile d’intégration Elastic Cloud dans Datadog
  7. Cliquez sur Add Account.
  8. Saisissez votre Elastic Cloud Organization ID et Billing API Key dans le tableau des comptes.

Vos données de coût 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 de coût SaaS, consultez la section Données collectées.

Intégrez-vous à Elastic Cloud pour collecter des données de coût.
  1. Créez un jeton d’API avec au moins le périmètre "global:read" et le rôle "Billing" sur la page Personal API tokens dans Fastly.
  2. Accédez à la tuile d’intégration Fastly Cost Management dans Datadog et cliquez sur Add New.
  3. Saisissez le nom de votre compte Fastly et votre jeton d’API.
  4. Cliquez sur Save.

Vos données de coût 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 de coût SaaS, consultez la section Données collectées.

Intégrez-vous à Fastly pour collecter des données de coût.
  1. Accédez à la tuile d’intégration Twilio dans Datadog et cliquez sur Add Account.
  2. Sous la section Resources, cliquez sur le commutateur de chaque compte pour activer Twilio in Cloud Cost Management.
  3. Saisissez un Account SID pour votre compte Twilio.
  4. Cliquez sur Save.

Vos données de coût 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 de coût SaaS, consultez la section Données collectées.

Intégrez Twilio pour collecter des données de coût.

Données collectées

Vous pouvez consulter les données de coût sur la Cloud Cost Explorer page, sur le Cloud Cost Tag Explorer, et dans les dashboards, notebooks ou monitors. Vous pouvez également combiner ces métriques de coût avec d’autres métriques Cloud Cost 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 tagDescription du tag
account_locatorLocalisateur du compte où l'utilisation a été consommée.
account_nameNom du compte où l'utilisation a été consommée.
balance_sourceSource 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 de report. 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 de report.
- free usage : Utilisation couverte par les crédits gratuits fournis à l'organisation.
- overage : Utilisation payée au tarif à la demande, ce qui se produit lorsqu'une organisation a épuisé ses crédits de capacité, de report et gratuits.
- rebate : Utilisation couverte par les crédits accordés à l'organisation lorsqu'elle a partagé des données avec une autre organisation.
billing_typeIndique 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 accordés à l'organisation lorsqu'elle a partagé des données avec une autre organisation.
- priority support : Frais pour les services de support prioritaire. Cette charge est associée à une stipulation dans un contrat, et non à un compte.
- vps_deployment_fee : Frais pour un déploiement Virtual Private Snowflake.
- support_credit : Snowflake Support a crédité le compte pour annuler des frais attribués à un problème dans Snowflake.
charge_descriptionUne description du type de coût associé à des éléments distincts. Les descriptions diffèrent pour chaque type de coût, représenté par la servicename tag.
contract_numberNuméro de contrat Snowflake pour l'organisation.
database_nameNom de la base de données dans laquelle la requête a été exécutée (le cas échéant). Uniquement trouvé pour les coûts d'attribution de requête.
organization_nameNom de l'organisation.
query_hashHachage unique représentant une version paramétrée de la requête à des fins d'attribution. Uniquement trouvé pour les coûts d'attribution de requête.
query_hash_versionVersion de l'algorithme de hachage de requête Snowflake utilisé pour générer query_hash. Uniquement trouvé pour les coûts de query attribution.
rating_typeIndique comment l'utilisation dans l'enregistrement est évaluée ou tarifée. Les valeurs possibles incluent :
- compute
- data_transfer
- storage
- Other
regionNom de la région où se trouve le compte.
service_levelNiveau de service (édition) du compte Snowflake (Standard, Enterprise ou Business Critical).
servicenameType d'utilisation. Les types de service possibles incluent :
- automatic_clustering : Reportez-vous à Automatic Clustering.
- data_transfer : Reportez-vous à Understanding data transfer cost.
- logging : Reportez-vous à Logging and Tracing Overview.
- materialized_view : Reportez-vous à Working with Materialized Views.
- replication : Reportez-vous à Introduction to replication and failover across multiple accounts.
- query_acceleration : Reportez-vous à Using the Query Acceleration Service.
- search_optimization : Reportez-vous à Search Optimization Service.
- serverless_task : Reportez-vous à Introduction to tasks.
- snowpipe : Reportez-vous à Snowpipe.
- snowpipe_streaming : Reportez-vous à Snowpipe Streaming.
- storage : Reportez-vous à Understanding storage cost.
- warehouse_metering_query_attribution : Reportez-vous à Virtual warehouse credit usage of queries with an execution time of 100ms or greater. N'indique pas l'utilisation du calcul serverless ou des services cloud.
- warehouse_metering_query_attribution : Reportez-vous à Virtual warehouse credit usage of queries with an execution time of 100ms or less, as well as idle warehouse time. N'indique pas l'utilisation du calcul serverless ou des services cloud.
user_nameNom de l'utilisateur ou du compte de service associé à la requête.
warehouse_idIdentifiant de l'entrepôt générant le coût.
warehouse_nameNom de l'entrepôt associé à cette utilisation.
warehouse_sizeTaille de l'entrepôt (par exemple, Large, Medium).

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

Nom du tagDescription du tag
account_idID du compte pour lequel ce rapport a été généré.
billing_origin_productProduit ou fonctionnalité à l'origine de l'événement de facturation (par exemple, JOBS, CLUSTERS).
central_clean_room_idID de la salle blanche centrale associée à la charge de travail (le cas échéant).
charge_descriptionCombinaison du type de cloud et du nom de la SKU associée (par exemple, AWS - PREMIUM_ALL_PURPOSE_COMPUTE).
cloudCloud pour lequel cette utilisation est pertinente. Les valeurs possibles sont AWS, AZURE et GCP.
cluster_idID du cluster associé à cette utilisation.
custom_tagsTags 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_regionRégion où la charge de travail est dirigée (le cas échéant).
dlt_maintenance_idID de maintenance pour Delta Live Tables (le cas échéant).
dlt_pipeline_idID du pipeline Delta Live Tables (le cas échéant).
dlt_tierNiveau du service Delta Live Tables (le cas échéant).
dlt_update_idID de mise à jour Delta Live Table associé à cette utilisation (le cas échéant).
endpoint_idID de l'endpoint pour une utilisation basée sur SQL ou liée au service (le cas échéant).
endpoint_nameNom de l'endpoint SQL ou de service (le cas échéant).
instance_pool_idID du pool d'instances utilisé (le cas échéant).
is_photonIndique si le traitement Photon a été utilisé (true ou false).
is_serverlessIndique si l'utilisation concerne une ressource de calcul serverless (true ou false).
job_idIdentifiant unique du job dans Databricks.
job_nameNom du job dans Databricks (le cas échéant).
job_run_idIdentifiant de l'exécution spécifique du job (le cas échéant).
jobs_tierNiveau du job, tel que CLASSIC ou PREMIUM.
networkingType de mise en réseau utilisé pour ce job, si spécifié.
node_typeType de nœud utilisé dans cet enregistrement de facturation (par exemple, m5d.large).
notebook_idID du notebook utilisé dans cet enregistrement de facturation (le cas échéant).
notebook_pathChemin d'accès au notebook dans Databricks (le cas échéant).
record_idID unique pour cet enregistrement.
run_nameNom du job ou de l'exécution du workflow actuel (le cas échéant).
serving_typeType de modèle de service utilisé, le cas échéant (par exemple, Model Serving).
source_regionRégion d'origine de cet enregistrement de facturation (le cas échéant).
sql_tierNiveau SQL associé à l'utilisation (le cas échéant).
usage_metadataMétadonnées relatives à l'utilisation, pouvant inclure des détails tels que le type d'utilisation, la catégorie de service ou d'autres informations pertinentes.
usage_typeType d'utilisation facturé (par exemple, COMPUTE_TIME).
warehouse_idID de l'entrepôt SQL (le cas échéant).
workspace_idID de l'espace de travail auquel cette utilisation était associée.
Nom du tagDescription du tag
charge_descriptionNom du modèle dont les coûts sont associés à la facturation.
organization_idIdentifiant unique de l’organisation.
organization_nameNom de l’organisation.
project_idIdentifiant unique du projet.
project_nameNom du projet.
Nom du tagDescription du tag
workspace_idIdentifiant unique de l’espace de travail Anthropic.
workspace_nameVersion normalisée par tag du nom de l’espace de travail.
display_workspace_nameNom inchangé de l’espace de travail.
org_idIdentifiant unique de l’organisation Anthropic.
org_nameVersion normalisée par tag du nom de l’organisation Anthropic.
display_org_nameNom inchangé de l’organisation.
org_typeLe type de compte Anthropic (par exemple, enterprise ou platform).
model_idL’identifiant canonique du modèle Anthropic (par exemple, claude-3-opus-20240229).
modelUn alias pour model_id, fourni pour des raisons de compatibilité et de cohérence avec l’utilisation et les métriques.
model_nameLe nom convivial du modèle (par exemple, Claude 3 Opus).
service_tierLe plan ou le niveau de service Anthropic associé à l’utilisation (par exemple, standard, pro, enterprise).
token_typeLa catégorie de jetons consommés.
context_windowLa taille de la fenêtre de contexte pour les jetons (par exemple, tier_0-200k).
Nom du tagDescription du tag
billing_groupLe groupe de facturation au sein de l’organisation Cursor auquel l’utilisation est attribuée.
charge_typeLa catégorie de frais Cursor (par exemple, fast_premium, slow_premium).
hourL’heure à laquelle l’utilisation a été enregistrée, en UTC.
is_headlessIndique si l’utilisation a été générée par une session sans interface, telle qu’un agent en arrière-plan s’exécutant en dehors de l’éditeur Cursor (true ou false).
max_modeIndique si la requête a utilisé Cursor Max, qui achemine les requêtes vers des modèles de pointe à un coût plus élevé (true ou false).
userL’adresse e-mail de l’utilisateur Cursor ayant engendré le coût.

Remarque : Les tags d’espace de noms personnalisés configurés dans Temporal Cloud sont affichés sous forme de tags temporal_tag_<key> dynamiques (par exemple, un espace de noms tagué tmprl_project apparaît sous la forme temporal_tag_tmprl_project).

Nom du tagDescription du tag
namespaceL’espace de noms Temporal Cloud auquel l’utilisation est attribuée (par exemple, replay-2025).
billing_accountLe compte de facturation Temporal Cloud associé aux frais.
billing_account_idL’identifiant unique du compte de facturation Temporal Cloud.
resource_typeLe type de ressource générant l’utilisation (par exemple, Namespace).
service_subcategoryLa catégorie d’utilisation entraînant la facturation (par exemple, Actions, Active Storage, Retained Storage).
sku_idL’identifiant unique de la SKU Temporal Cloud associée à la facturation (par exemple, business-actions, business-active-storage).
sku_meterLe compteur de SKU Temporal Cloud utilisé pour calculer la facturation (par exemple, Actions, Active Storage, Retained Storage).
charge_categoryLa catégorie des frais Temporal Cloud (par exemple, usage).
pricing_unitL’unité utilisée pour tarifer les frais (par exemple, GB/h, 1 Million Actions).
usage_unitL’unité d’utilisation mesurée pour les frais (par exemple, GB/h, 1 Million Actions).
unit_priceLe prix par unité d’utilisation.
invoice_idL’identifiant unique de la facture Temporal Cloud associée à la facturation.

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

Nom du tagDescription du tag
enterprise_nameChaîne alphanumérique identifiant le compte d’entreprise GitHub.
charge_descriptionLa description de la facturation.
productLe produit de l’utilisation, par exemple « actions » ou « stockage ».
organization_nameL’organisation GitHub.
repository_nameLe dépôt GitHub.
billing_currencyLa devise de facturation, par exemple « USD ».
discountSi l’élément de coût est une remise.
Nom du tagDescription du tag
charge_descriptionLe sous-type du coût (par exemple, KAFKA_NETWORK_WRITE).
environment_idL'identifiant unique de l'environnement.
network_access_typeType d'accès réseau pour le cluster. Les valeurs possibles sont INTERNET, TRANSIT_GATEWAY, PRIVATE_LINK, et PEERED_VPC.
productNom 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_idL'identifiant unique de la ressource Confluent.
resource_nameLe nom de la ressource Confluent.
Nom du tagDescription du tag
charge_descriptionL’unité de gestion des stocks (SKU) d’une charge.
kindLe type de ressource.
nameL’identifiant unique de la ressource Elastic Cloud.
price_per_hourLe coût de la ressource Elastic Cloud par heure.
Nom du tagDescription du tag
charge_descriptionLa description d’une charge.
cluster_nameLe nom du cluster ayant engendré la charge.
group_idID du projet auquel le poste de dépense est associé.
invoice_idL’identifiant unique de la facture.
mongo_org_idID de l’organisation MongoDB.
replica_set_nameNom du jeu de réplicas auquel l’élément de ligne est associé.
resource_tagsTags arbitraires sur les clusters définis par les utilisateurs, généralement sous forme de paires clé-valeur.
statusÉtat du paiement.
Nom du tagDescription du tag
charge_descriptionLa description de la charge.
credit_coupon_codeCode de tout coupon ou crédit appliqué à cette entrée de coût (si disponible).
plan_nameNom du plan auquel ce service appartient, correspondant souvent à « product_line ».
product_nameNom du produit spécifique facturé (par exemple, « North America Bandwidth »).
product_groupGroupe ou catégorie du produit, tel que « Full Site Delivery ».
product_lineGamme de produits à laquelle cet élément appartient, par exemple « Network Services ».
regionRégion où l'utilisation du service a eu lieu (par exemple, « North America »).
service_nameNom du service associé à cette entrée de coût, correspondant souvent au product_name.
usage_typeType d'utilisation facturé (par exemple, « Bandwidth »).
usage_type_cdCode ou libellé représentant le type d'utilisation, tel que « North America Bandwidth ».
Nom du tagDescription du tag
account_sidChaîne alphanumérique identifiant le compte Twilio.
categoryLa catégorie d'utilisation. Pour plus d'informations, consultez Usage Categories.
charge_descriptionLa description de la charge.
count_unitUnités dans lesquelles le nombre est mesuré, telles que les appels pour les appels ou les messages pour les SMS.
usage_unitUnités dans lesquelles l'utilisation est mesurée, telles que les minutes pour les appels ou les messages pour les SMS.

Pour aller plus loin