Cette section décrit les étapes à suivre pour intégrer le backend de votre application à Cloud Marketplace. Grâce à cette intégration, vous pouvez gérer les comptes et les droits d'accès des utilisateurs, qui indiquent qu'ils ont acheté votre produit sur Cloud Marketplace. Si vous avez choisi un modèle de tarification basé sur l'utilisation, l'intégration du backend permet également de signaler l'utilisation à Google.
Pour obtenir un exemple d'intégration d'une application de base avec Cloud Marketplace et un tutoriel sur l'exemple de code, consultez l'atelier de programmation pour intégrer un service géré.
Pour obtenir l'exemple de code utilisé dans l'atelier de programmation, consultez le dépôt GitHub.
Avant de commencer
- Configurez l'accès à l'API Partner Procurement de Cloud Commerce comme décrit à la page Intégrer votre application : configuration.
- Si vous avez choisi un modèle de tarification basé sur l'utilisation, vérifiez si votre ingénieur partenaire a créé un service sur lequel vous pouvez rendre compte de l'utilisation. Ce service s'affiche dans le champ Domaine de service de la section Intégration de la facturation de Producer Portal.
Créer un compte de service
Pour intégrer votre produit à Google Cloud, vous devez créer un compte de service dans le projet que vous utilisez pour votre produit. Votre application utilise ce compte de service pour interagir avec les API Cloud Marketplace Partner et obtenir des informations sur les achats des utilisateurs.
Utilisez Producer Portal pour créer et associer vos comptes de service. Pour connaître la procédure détaillée permettant de créer un compte de service, consultez la page Créer et gérer des comptes de service.
Utiliser Producer Portal pour intégrer le backend de votre application
Pour accéder à toutes les informations dont vous avez besoin pour intégrer le backend de votre application à Cloud Marketplace à partir d'un seul emplacement, comme vos comptes de service et vos identifiants au niveau du forfait, vous pouvez utiliser la section Intégration de la facturation du portail Producer.
Le lien direct vers Producer Portal est le suivant :
https://console.cloud.google.com/producer-portal?project=YOUR_PROJECT_ID
Pour accéder à la section Intégration de la facturation:
Dans la liste des produits, cliquez sur le nom de votre produit.
Sur la page Vue d'ensemble de votre produit, accédez à la section Intégration technique, puis cliquez sur Intégration de la facturation.
Créer et associer des comptes de service dans Producer Portal
Vous pouvez utiliser la section Intégration de la facturation de Producer Portal pour créer et associer les comptes de service que vous utilisez pour interagir avec les API partenaires, et pour obtenir des informations sur les achats des utilisateurs.
Le lien direct vers Producer Portal est le suivant :
https://console.cloud.google.com/producer-portal?project=YOUR_PROJECT_ID
Dans les étapes suivantes, vous pouvez utiliser des comptes de service existants ou en créer de nouveaux. Si vous créez un compte de service, spécifiez son nom dans le champ Nom du compte de service et son ID dans le champ ID du compte de service, puis cliquez sur Créer et associer.
Pour associer vos comptes de service, procédez comme suit :
Dans la liste des produits, cliquez sur le nom de votre produit.
Sur la page Vue d'ensemble de votre produit, accédez à la section Intégration technique, puis cliquez sur Intégration de la facturation.
Pour intégrer l'API Partner Procurement, sous Associer un compte de service pour appeler l'API Procurement, cliquez sur Ajouter un compte de service. Vous pouvez saisir un compte de service existant dans le champ ou créer un nouveau compte de service.
Pour intégrer Pub/Sub, sous Associer un compte de service pour s'abonner au sujet Pub/Sub, cliquez sur Ajouter un compte de service. Vous pouvez saisir un compte de service existant dans le champ ou créer un nouveau compte de service.
Pour intégrer l'API Service Control, cliquez sur Ajouter un compte de service sous Ajouter
roles/servicemanagement.serviceControllerà un compte de service. Vous pouvez saisir un compte de service existant dans le champ ou créer un nouveau compte de service.
Tâches de compte utilisateur
En règle générale, votre application doit gérer le scénario suivant :
Un utilisateur effectue une requête ou une modification dans Cloud Marketplace, par exemple en s'inscrivant à votre produit.
Cloud Marketplace envoie à votre application une notification via Pub/Sub, contenant des informations sur la requête dans le champ
eventType. Par exemple, si un utilisateur change son droit, le champeventTypeest défini surENTITLEMENT_PLAN_CHANGED.Consultez la liste complète des
eventTypes possibles.Pour approuver la requête, votre application envoie une requête
HTTP POSTà l'API Partner Procurement.
Les sections suivantes décrivent les types de requêtes que les utilisateurs peuvent effectuer et ce que votre application doit faire pour gérer ces requêtes.
Pour les appels d'API décrits dans cette section, utilisez ce point de terminaison :
https://cloudcommerceprocurement.googleapis.com/
Créer un compte pour un nouvel utilisateur
Lorsqu'un utilisateur achète votre produit pour la première fois, Cloud Marketplace crée une ressource de compte qui suit la relation qu'il entretient avec vous. Lorsque la ressource de compte est créée, vous recevez une notification via le sujet Pub/Sub qui a été créé pour vous. Le message Pub/Sub est au format suivant :
{
"eventId": "...",
"providerId": "YOUR_PARTNER_ID",
"account": {
"id": "USER_ACCOUNT_ID",
"updateTime": "..."
}
}
où USER_ACCOUNT_ID est l'ID de compte créé par Cloud Marketplace et YOUR_PARTNER_ID est un ID qui vous est attribué lorsque votre ingénieur partenaire autorise l'accès à l'API Partner Procurement.
Simultanément, l'utilisateur est dirigé vers votre page d'inscription, où il crée un compte dans votre système. Pour en savoir plus sur la création de la page d'inscription, consultez la page Intégrer l'interface de votre application.
Approuver le compte d'un utilisateur
Une fois l'utilisateur inscrit, votre application doit appeler l'API Partner Procurement et indiquer que le compte a été approuvé.
Les comptes sont créés dans l'état ACCOUNT_ACTIVE, mais une entrée PENDING est présente dans le champ approvals nommé signup, ce qui indique que l'utilisateur ne s'est pas encore inscrit. Pour approuver le compte après l'inscription de l'utilisateur, utilisez la requête HTTP POST suivante :
POST v1/providers/YOUR_PARTNER_ID/accounts/USER_ACCOUNT_ID:approve {'approvalName': 'signup'}
Vérifier l'état du compte d'un utilisateur
Pour vérifier l'état d'un compte associé, utilisez la demande HTTP GET suivante :
GET v1/providers/YOUR_PARTNER_ID/accounts/USER_ACCOUNT_ID
La réponse est au format suivant :
{
"name": "providers/YOUR_PARTNER_ID/accounts/USER_ACCOUNT_ID",
"provider": "acme-services",
"state": "ACCOUNT_ACTIVE",
"approvals": [{
"name": "signup",
"state": "APPROVED",
"updateTime": "...",
}],
"updateTime": "...",
"createTime": "..."
}
Pour obtenir la liste des états de compte possibles, consultez la référence API providers.accounts.
Gérer les droits d'accès
Lorsque les clients choisissent un forfait pour votre logiciel, Google crée un droit, indiquant qu'ils ont acheté votre produit sur Cloud Marketplace. Cette section explique comment créer et gérer les droits de vos clients à l'aide de l'API Partner Procurement.
Pour en savoir plus sur la gestion des droits d'accès, consultez la documentation de référence.
Approuver ou refuser un droit d'accès
Lorsqu'un client choisit un forfait, Cloud Marketplace crée un droit d'accès et envoie le message Pub/Sub suivant à votre application:
{
"eventId": "...",
"eventType": "ENTITLEMENT_CREATION_REQUESTED",
"providerId": "YOUR_PARTNER_ID",
"entitlement": {
"id": "ENTITLEMENT_ID",
"updateTime": "...",
"newOfferDuration": "P2Y3M", // Contract duration for offer-based entitlements
},
}
où ENTITLEMENT_ID est un ID créé par Cloud Marketplace. Si l'offre comporte une durée spécifiée, celle-ci est indiquée en années et en mois. Si l'offre est associée à une date de fin spécifique et non à une durée, le champ indiquant la durée est vide.
Dans votre système, mettez à jour le compte de l'utilisateur pour indiquer qu'il a souscrit un forfait. Pour approuver le droit, envoyez une requête HTTP POST à l'API Partner Procurement et envoyez l'ID ENTITLEMENT_ID que vous approuvez :
POST v1/providers/YOUR_PARTNER_ID/entitlements/ENTITLEMENT_ID:approve
Pour refuser un droit, utilisez plutôt la méthode reject dans votre requête HTTP POST :
POST v1/providers/YOUR_PARTNER_ID/entitlements/ENTITLEMENT_ID:reject
Pour indiquer un motif de refus dans le corps de la requête, utilisez le format suivant:
{
"reason": "..."
}
Modifier un forfait
En fonction de la configuration de vos forfaits, vos clients pourront peut-être modifier le leur. Si un client sélectionne un nouveau forfait, vous recevez un message Pub/Sub, au format suivant :
{
"eventId": "...",
"eventType": "ENTITLEMENT_PLAN_CHANGE_REQUESTED",
"providerId": "YOUR_PARTNER_ID",
"entitlement": {
"id": "ENTITLEMENT_ID",
"newPlan": "ultimate", // New plan
"updateTime": "...",
"newOfferDuration": "P2Y3M", // Contract duration for the new offer, for offer-based entitlements
},
}
Si l'offre comporte une durée spécifiée, celle-ci est indiquée en années et en mois. Si l'offre est associée à une date de fin spécifique et non à une durée, le champ indiquant la durée est vide.
Pour approuver la modification du forfait, adressez la requête HTTP POST suivante à l'API Partner Procurement :
POST v1/providers/YOUR_PARTNER_ID/entitlements/ENTITLEMENT_ID:approvePlanChange
L'organisme demandeur doit avoir le plan en cours d'approbation :
{
"pendingPlanName": PLAN_NAME
}
Une fois la modification approuvée, vous recevez un autre message Pub/Sub lorsque la modification prend effet. Dans le message, le champ eventType devient ENTITLEMENT_PLAN_CHANGED. Pour vérifier l'état d'un plan, envoyez la requête HTTP GET suivante à l'API Partner Procurement.
GET v1/providers/YOUR_PARTNER_ID/entitlements/ENTITLEMENT_ID
La réponse est semblable à la suivante, le champ state indiquant si le nouveau forfait est actif ou si la modification du forfait est toujours en attente :
{
"name": "providers/YOUR_PARTNER_ID/entitlements/ENTITLEMENT_ID",
"provider": "YOUR_PARTNER_ID",
"account": "USER_ACCOUNT_ID",
"product": "example-server",
"plan": "pro",
"state": "ENTITLEMENT_PENDING_PLAN_CHANGE",
"newPendingPlan": "ultimate",
...
}
Envoyer un message d'état aux utilisateurs
Si le délai entre le choix d'un forfait par l'utilisateur et l'approbation d'un droit d'accès par votre backend est de plusieurs heures, il est recommandé d'envoyer un message d'état aux utilisateurs. Dans ce message, indiquez l'état d'avancement de l'approbation et, le cas échéant, à quel moment vous prévoyez l'approbation définitive.
Pour fournir un message d'état, faites la demande HTTP POST suivante à l'API Procurement :
POST v1/providers/your-partner-id/entitlements/entitlement_id:updateUserMessage
Dans le corps de la requête, indiquez le texte du message, de la même manière que dans l'exemple suivant :
{
"message": "Approval expected in 2 days"
}
Annuler un droit d'accès
Si un utilisateur décide d'annuler son droit d'accès, vous recevez une notification Pub/Sub. Tout comme la modification d'un forfait, l'annulation peut prendre effet à la fin du cycle de facturation en cours.
La notification est au format suivant :
{
"eventId": "...",
// If the entitlement is canceled at the end of the month,
// eventType is ENTITLEMENT_PENDING_CANCELLATION
"eventType": "ENTITLEMENT_CANCELLED",
"providerId": "YOUR_PARTNER_ID",
"entitlement": {
"id": "ENTITLEMENT_ID",
"cancellationDate": "...",
"updateTime": "..."
},
}
Supprimer un droit
Si un utilisateur adresse directement une demande à l'assistance Google ou s'il quitte la plate-forme Google, ses droits d'accès sont immédiatement résiliés, et ses droits d'accès ainsi que ses comptes sont supprimés après un délai de grâce de 60 jours. Pour protéger la vie privée de l'utilisateur, vous devez supprimer ses données de vos serveurs dès que vous en êtes informé.
Une fois les droits d'accès et le compte supprimés, vous recevez des notifications semblables à celles-ci :
{
"eventId": "...",
"eventType": "ENTITLEMENT_DELETED",
"providerId": "YOUR_PARTNER_ID",
"entitlement": {
"id": "ENTITLEMENT_ID",
"updateTime": "...",
},
}
{
"eventId": "...",
"eventType": "ACCOUNT_DELETED",
"providerId": "YOUR_PARTNER_ID",
"account": {
"id": "USER_ACCOUNT_ID",
"updateTime": "...",
},
}
Liste des types d'événements pour les tâches de compte
Voici une liste des eventType que votre application peut recevoir dans les messages Pub/Sub :
| eventType | Description |
|---|---|
| ACCOUNT_CREATION_REQUESTED | Obsolète |
| ACCOUNT_ACTIVE | Indique que le compte du client a été créé. |
| ACCOUNT_DELETED | Indique que le compte du client a été supprimé des systèmes Google Cloud. |
| ENTITLEMENT_CREATION_REQUESTED | Indique qu'un client a sélectionné l'un de vos forfaits. |
| ENTITLEMENT_OFFER_ACCEPTED | Indique qu'une offre a été acceptée par un client. Inclut l'heure de début prévue de l'offre, le cas échéant. |
| ENTITLEMENT_ACTIVE | Indique que le forfait choisi par un client est maintenant actif. |
| ENTITLEMENT_PLAN_CHANGE_REQUESTED | Indique qu'un client a choisi un nouveau forfait. |
| ENTITLEMENT_PLAN_CHANGED | Indique que la modification du forfait d'un client est approuvée et que les modifications sont entrées en vigueur. |
| ENTITLEMENT_PLAN_CHANGE_CANCELLED | Indique que le changement de forfait d'un client a été annulé, soit parce qu'il n'a pas été approuvé, soit parce le client est revenu à son ancien forfait. |
| ENTITLEMENT_PENDING_CANCELLATION | Indique qu'un client a annulé son forfait et que l'annulation est en attente jusqu'à la fin du cycle de facturation. |
| ENTITLEMENT_CANCELLATION_REVERTED | Indique que l'annulation en attente d'un client a été annulée. Notez que les annulations ne peuvent pas être annulées une fois qu'elles sont définitives. |
| ENTITLEMENT_CANCELLED | Indique que le forfait d'un client a été annulé. |
| ENTITLEMENT_CANCELLING | Indique que le forfait d'un client est en cours d'annulation. |
| ENTITLEMENT_RENEWED | Indique que le droit d'accès d'un client a été renouvelé pour une autre période. Aucune action de votre part n'est requise de votre part.. |
| ENTITLEMENT_OFFER_ENDED | Indique que l'offre privée d'un client est arrivée à expiration. Si le droit d'accès du client a été annulé, un événement ENTITLEMENT_CANCELLED distinct est déclenché. Si le droit d'accès du client est toujours actif, son forfait inclut un prix sans remise. |
| ENTITLEMENT_DELETED | Indique que des informations sur le forfait d'un client ont été supprimées de Cloud Marketplace. |
Signaler l'utilisation à Google (pour la tarification basée sur l'utilisation)
Si vous choisissez une tarification basée sur l'utilisation pour votre produit, vous devez signaler l'utilisation de votre application à l'API Service Control.
Pour obtenir une présentation de Service Control, consultez le Guide de démarrage.
Nous vous recommandons d'utiliser Producer Portal pour créer un compte de service dans Producer Portal à utiliser avec Service Control.
Lorsqu'un droit est créé, vous devez appeler l'API Partner Procurement pour récupérer un usageReportingId, à l'aide de la demande HTTP GET suivante :
GET v1/providers/YOUR_PARTNER_ID/entitlements/ENTITLEMENT_ID
La réponse qui contient des informations sur le droit est au format suivant :
{
"name": "providers/YOUR_PARTNER_ID/entitlements/ENTITLEMENT_ID",
"provider": "YOUR_PARTNER_ID",
"account": "USER_ACCOUNT_ID",
"product": "example-messaging-service",
"plan": "pro",
"usageReportingId": "USAGE_REPORTING_ID",
"state": "ENTITLEMENT_ACTIVATION_REQUESTED",
"updateTime": "...",
"createTime": "..."
}
Pour signaler l'utilisation, vous devez d'abord effectuer un appel d'API services.check afin de vérifier la configuration du service. Dans la réponse, si l'objet checkErrors[] est vide, effectuez un appel d'API services.report pour envoyer le rapport d'utilisation.
Le rapport d'utilisation est une API Service Control Operation.
Voici un exemple de rapport d'utilisation pour example-messaging-service qui envoie des informations sur le stockage utilisé par le client :
POST https://servicecontrol.googleapis.com/v1/services/example-messaging-service.gcpmarketplace.example.com:report
{
"operations": [{
"operationId": "1234-example-operation-id-4567",
"operationName": "Hourly Usage Report",
"consumerId": "USAGE_REPORTING_ID",
"startTime": "2019-02-06T12:00:00Z",
"endTime": "2019-02-06T13:00:00Z",
"metricValueSets": [{
"metricName": "example-messaging-service/UsageInGiB",
"metricValues": [{ "int64Value": "150" }]
}],
"userLabels": {
"cloudmarketplace.googleapis.com/resource_name": "order_history_cache",
"cloudmarketplace.googleapis.com/container_name": "storefront_prod",
"environment": "prod",
"region": "us-west2"
}
}]
}
où :
operationIdest une chaîne unique générée par votre instance de service. Vous devez utiliser le même identifiantoperationIdpour vos opérationschecketreport.consumerIdest identique au champusageReportingIddu droit d'accès.startTimeetendTimereprésentent les heures de début et de fin de l'intervalle total pour l'opérationreport. Dans la plupart des cas, l'élémentstartTimed'une opérationreportdoit avoir la même valeur que le champendTimede l'opérationreportprécédente.Si le service d'un client est désactivé avant le
startTimed'une opérationreport, l'appel d'APIservices.checkenvoie une erreur dans l'objetcheckErrors[]et le client n'est pas facturé pour l'intervalle correspondant.MetricValueSetcontient un ou plusieurs intervalles de temps et les valeurs de métriques mises à jour correspondantes. Vous définissez les métriques de votre service lorsque vous choisissez et envoyez votre modèle de tarification.Vous pouvez afficher et référencer les identifiants de vos métriques dans la section Technical Integration (Intégration technique) de Producer Portal.
userLabelssont des libellés créés par l'utilisateur, définis comme des chaînes clé-valeur qui respectent des exigences de syntaxe spécifiques. Ces libellés sont transférés aux outils de gestion des coûts de Cloud Billing pour l'attribution. Pour connaître les conventions d'étiquetage recommandées, consultez la section Bonnes pratiques pour l'étiquetage de l'utilisation.
Si l'API services.check renvoie une ou plusieurs des erreurs suivantes, nous vous recommandons de cesser de fournir votre service au client jusqu'à ce que l'erreur soit résolue :
SERVICE_NOT_ACTIVATEDBILLING_DISABLEDPROJECT_DELETED
Bonnes pratiques pour les rapports d'utilisation
Lorsque vous créez un rapport d'utilisation, par exemple concernant les opérations ou l'utilisation des ressources, tenez compte des informations suivantes pour vous assurer que vos clients sont facturés correctement.
Signaler l'utilisation au moment de l'occurrence
Les retards dans la création des rapports d'utilisation nuisent à l'expérience de gestion des coûts de vos clients et peuvent ne pas être reflétés dans les rapports des partenaires. Les fournisseurs de services doivent signaler l'utilisation dans un délai d'une heure après l'utilisation générée.
Si vous avez besoin de plus de temps pour signaler l'utilisation, contactez votre ingénieur partenaire.
Signaler l'utilisation après une annulation de droit d'accès
Si vous avez annulé l'utilisation après signalement d'un droit, vous pouvez toujours le signaler avec un horodatage qui reflète l'heure à laquelle l'utilisation a été générée. L'horodatage doit être antérieur à l'annulation du droit. Signalez cette utilisation dans un délai d'une heure. Vous ne devez pas signaler d'utilisation en tant que nouvelle utilisation après la fin du droit.
Signaler l'utilisation à la fin du mois
La période de référence d'une heure s'applique à la date limite de fin de mois. Pour vous assurer que l'utilisation est indiquée sur la facture du mois en cours, indiquez l'utilisation au plus tard à 1:00, heure du Pacifique des États-Unis et du Canada (UTC-7 ou UTC-8), le lendemain.
Par exemple, pour une facture de septembre, indiquez l'utilisation avant le 1er octobre, 1:00, heure du Pacifique des États-Unis et du Canada (UTC-7 ou UTC-8).
Si l'utilisation est signalée plus tard dans la journée, elle risque de ne pas être incluse dans la facture du mois en cours.
Correction des actions client qui empêchent de signaler l'utilisation au moment de l'occurrence
Si vous ne pouvez pas signaler l'utilisation, ou si le service ou la facturation est désactivé pendant une période prolongée, nous vous recommandons d'accorder au client un délai de grâce pour restaurer le service. Nous vous recommandons de ne pas dépasser 30 jours. Au cours de ce délai de grâce, envisagez d'effectuer les opérations suivantes :
Dégrader le service fourni. Par exemple, passez le client à une version gratuite ou commencez à rejeter les appels.
Continuez à collecter le journal d'utilisation lorsque le service est désactivé. Nous vous recommandons de collecter l'utilisation avec la répartition des frais au plus tard par une fenêtre d'une heure, afin de pouvoir la relire après l'activation du service.
Lorsque le service est activé, vous devez signaler l'utilisation collectée lors de la désactivation du service en tant qu'utilisation réelle avec l'heure à laquelle les données ont été collectées. Vous devez également reprendre vos rapports d'utilisation habituels.
Pour les applications Kubernetes, si les rapports d'utilisation échouent au démarrage de l'application, nous recommandons que votre application s'arrête d'elle-même, afin que vos clients obtiennent des commentaires immédiats et puissent résoudre le problème.
Bonnes pratiques pour l'étiquetage de l'utilisation
Pour les produits SaaS basés sur l'utilisation, l'utilisation est attribuée à un seul projet spécifié par le champ usageReportingId.
Dans certains scénarios, un produit SaaS peut être partagé largement au sein de l'organisation d'un client et utilisé dans de nombreux projets client. Pour permettre une attribution des coûts plus spécifique, nous vous recommandons d'inclure le champ facultatif userLabels pour les produits SaaS basés sur l'utilisation dans l'opération du rapport d'utilisation.
Si votre service est nativement compatible avec un concept d'étiquettes de ressource, nous vous recommandons de transférer ces étiquettes dans vos rapports d'utilisation. Les étiquettes doivent respecter les exigences de syntaxe.
Cloud Marketplace réserve les libellés suivants. Vous pouvez utiliser ces libellés pour identifier du contexte supplémentaire à utiliser sur votre plate-forme de service natif. Nous vous recommandons d'inclure par défaut ces libellés dans vos rapports d'utilisation.
| Clé du libellé | Valeur du libellé | Description > |
|---|---|---|
| cloudmarketplace.googleapis.com/resource_name | USER_SUPPLIED | Nom de la ressource associée à une métrique d'utilisation. |
| cloudmarketplace.googleapis.com/container_name | USER_SUPPLIED | Nom d'un conteneur de ressources. |
Les libellés sont transmis aux outils de gestion des coûts de Cloud Billing, y compris aux rapports sur les coûts et aux exportations de la facturation.
Exemple d'étiquetage d'utilisation
Pour cet exemple, imaginez que votre organisation propose un produit de stockage appelé Solutions de stockage SaaS.
Un client, Carl, a acheté votre offre de stockage pour son projet Google Cloud e-commerce-website afin d'héberger les bases de données user_profiles_db et products_db de son site Web d'e-commerce:
user_profiles_dbcontient des informations sur les utilisateurs qui visitent le site de Carl.products_dbcontient des informations sur les produits que Carl vend sur son site.
Si vous souhaitez fournir à Carl une répartition détaillée des coûts de leur utilisation, vous pouvez utiliser la paire clé-valeur userLabels pour indiquer le coût d'utilisation de chaque base de données séparément.
Par exemple, pour indiquer le coût attribué à l'utilisation du stockage products_db de Carl, vous pouvez envoyer le rapport suivant, qui indique que l'espace de stockage products_db de Carl lui coûte 100 unités:
operation = {
'operationId': '<UUID>',
'operationName': 'db-total-storage',
'consumerId': 'project:carl_website',
'startTime': '<Timestamp>',
'endTime': '<Timestamp>',
'metricValues': [{
'int64Value': 100,
}],
'userLabels': {
'cloudmarketplace.googleapis.com/container_name': 'e-commerce-website',
'cloudmarketplace.googleapis.com/resource_name': 'products_db'
}
}
service.services().report(
serviceName=service_name, body={
'operations': [operation]
}).execute()
Dans cet exemple, service_name est l'ID du projet Google Cloud de Carl.
Pour obtenir un exemple plus détaillé d'utilisation de userLabels, vous pouvez consulter l'atelier de programmation SaaS.
(Facultatif) Intégrer vos rapports au cloud privé virtuel (VPC)
Si vous souhaitez utiliser un cloud privé virtuel (VPC) dans l'environnement dans lequel le service de votre produit s'exécute, procédez comme suit pour intégrer la création de rapports Google Cloud Marketplace à VPC. Par défaut, les VM Compute Engine de votre VPC ne peuvent communiquer qu'en interne. Vous devez configurer l'une des VM pour qu'elle communique en externe, afin que le reste des VM de votre VPC puisse l'utiliser pour la création de rapports.
Avant de commencer
Configurez l'implémentation de VPC de votre choix dans votre environnement de service. Pour connaître les étapes de configuration du VPC, consultez la page Créer et modifier des réseaux cloud privés virtuels (VPC).
Assurez-vous de disposer du rôle IAM (Identity and Access Management) Administrateur réseau Compute (
roles/compute.NetworkAdmin) pour votre projet Google Cloud.
Configurer l'accès privé à Google
Pour permettre aux machines virtuelles (VM) Compute Engine de votre produit de communiquer en externe à des fins de création de rapports, vous devez configurer l'accès privé à Google. Pour plus d'informations sur la configuration de l'accès privé à Google, consultez la page Configurer l'accès privé à Google.
Activez l'accès privé à Google pour votre environnement de service.
Configurez le DNS pour résoudre les requêtes vers
private.googleapis.com.Créez une route personnalisée pour les API Google:
Dans le champ Nom, indiquez
route-google-apis-services.Dans le champ Réseau, sélectionnez votre VPC.
Pour la plage d'adresses IP de destination, spécifiez
199.36.153.8/30.Pour Priorité, spécifiez
0.Dans le champ Tags des instances, spécifiez
google-apis-services.Pour Saut suivant, sélectionnez Passerelle Internet par défaut.
Créez une règle de pare-feu VPC pour permettre à votre produit de communiquer avec les API Google:
Dans le champ Nom, indiquez
google-apis-services.Dans le champ Description, indiquez
Allow egress traffic to Google APIs and services.Activez la journalisation des règles de pare-feu.
Dans le champ Réseau, sélectionnez votre VPC.
Pour le champ Sens du trafic, sélectionnez Sortie.
Dans Action en cas de correspondance, sélectionnez Autoriser.
Dans le champ Nom, indiquez
google-apis-services.Dans le champ Cibles, sélectionnez
Specified target tags, puis dans le champ Tags cibles, spécifiezgoogle-apis-services.Pour le filtre de destination, sélectionnez
IPv4 ranges, et pour les plages d'adresses IPv4 de destination, spécifiez199.36.153.8/30.Dans Protocoles et ports, sélectionnez
Allow all.
Dans la console Google Cloud, sélectionnez la VM que vous souhaitez utiliser pour générer des rapports sur l'utilisation de votre produit. Sous Tags réseau, ajoutez
google-apis-services, puis cliquez sur ENREGISTRER.Sous Interfaces réseau, localisez l'interface réseau de votre VPC.
Dans la colonne Sous-réseau, cliquez sur le lien du sous-réseau. Sur la page Détails du sous-réseau, cliquez sur MODIFIER et définissez l'Accès privé à Google sur Activé.
Cliquez sur ENREGISTRER.
(Facultatif) Intégrer vos rapports à VPC Service Controls
Si vous souhaitez utiliser VPC Service Controls dans l'environnement dans lequel le service de votre produit s'exécute, vous devez intégrer les rapports Google Cloud Marketplace à VPC Service Controls comme suit:
Configurez l'implémentation de VPC Service Controls de votre choix dans votre environnement de service. Pour en savoir plus sur la configuration de VPC Service Controls, consultez la page Configurer un périmètre de service à l'aide de VPC Service Controls.
Assurez-vous que le service
servicecontrol.googleapis.comdans votre implémentation de VPC Service Controls n'est pas limité.