Diagnostiquer vos tâches d'agrégation

Les tableaux suivants détaillent une myriade de problèmes et de codes d'état d'erreur, ainsi que les raisons potentielles de leur origine et les actions que vous pouvez entreprendre pour atténuer votre déploiement. Si vous souhaitez consulter les spécifications d'erreur et les mesures d'atténuation complètes pour le service d'agrégation, consultez nos conseils publics actuels.

Thèmes du guide :

Erreurs d'autorisation et d'autorisation

Problème Problèmes d'autorisation lorsque vous exécutez terraform plan ou terraform apply dans votre projet de cloud public.
Exemple d'erreur Error: UnauthorizedOperation: You are not authorized to perform this operation.
Solution

Vérifiez que vous êtes correctement authentifié dans l'interface de ligne de commande du cloud public que vous utilisez.

Amazon Web Services

AWS exige des autorisations utilisateur pour pouvoir créer des instances et d'autres services requis pour le service d'agrégation. Une fois cette opération effectuée, vous devriez pouvoir exécuter les commandes "terraform plan" et "apply" sans problème.

Google Cloud Platform

Dans Google Cloud, notez que vous devrez emprunter l'identité d'un compte de service pour déployer la seconde moitié de Terraform. Si vous avez ignoré cette étape, il est possible que votre commande "terraform apply" échoue, car le compte de service de déploiement dispose de toutes les autorisations nécessaires pour créer des ressources. Consultez l'étape 4 de la section "Configurer votre environnement de déploiement" dans la documentation GitHub.

Erreurs liées au privacy budget

Erreur PRIVACY_BUDGET_ERROR
Cause Cela indique que le service n'a pas pu traiter les rapports en raison d'une erreur liée au service de budget de confidentialité.
Vérifier Une fois que vous avez relancé le job pour vérifier si l'erreur était ponctuelle, contactez-nous via le formulaire d'assistance technique.
Erreur PRIVACY_BUDGET_AUTHORIZATION_ERROR
Cause Il est possible que vous utilisiez une origine de rapport différente de celle qu'ils ont fournie lors de l'intégration.
Vérifier

Vérifiez que le site que vous envoyez dans le champ attribution_report_to de la demande createJob est le même que celui envoyé lors de l'intégration.

Le site doit correspondre à celui qui a été intégré ou en être un sous-domaine. Notez que l'intégration du service d'agrégation est gérée au niveau du domaine de premier niveau. Tous les sous-domaines peuvent utiliser le service d'agrégation une fois le domaine de premier niveau intégré.

Erreur PRIVACY_BUDGET_AUTHENTICATION_ERROR
Cause Vous utilisez peut-être un ARN obsolète ou incorrect.
Vérifier Google Cloud Platform

Vérifiez que le compte de service utilisé dans votre déploiement du service d'agrégation correspond à celui fourni lors de l'intégration. Il doit correspondre exactement, et pas seulement appartenir au même projet.

Amazon Web Services

Vous devez utiliser les mêmes coordinateurs que ceux qui vous ont été fournis par e-mail. Si vous rencontrez toujours des problèmes, rassemblez votre fichier auto.tfvars et les informations sur l'origine des rapports, puis contactez-nous via le formulaire d'assistance technique.

Erreur PRIVACY_BUDGET_EXHAUSTED
Cause Erreur :
            "result_info": {
              "return_code": "PRIVACY_BUDGET_EXHAUSTED",
              "return_message": "com.google.aggregate.adtech.worker.exceptions.AggregationJobProcessException:
              Insufficient privacy budget for one or more aggregatable reports. No aggregatable report can appear
              in more than one aggregation job. Information related to reports that do not have budget can be
              found in the following file:
              File path: //
              Filename: privacy budget exhausted debugging information  \n
              com.google.aggregate.adtech.worker.aggregation.concurrent.ConcurrentAggregationProcessor.consumePrivacyBudgetUnits(ConcurrentAggregationProcessor.java:525) \n com.google.aggregate.adtech.worker.aggregation.concurrent.ConcurrentAggregationProcessor.process(ConcurrentAggregationProcessor.java:319) \n com.google.aggregate.adtech.worker.WorkerPullWorkService.run(WorkerPullWorkService.java:157)",
              "error_summary": {
                  "error_counts": [],
                  "error_messages": []
              },
              "finished_at": 
            }
          

Le problème d'épuisement du budget de confidentialité se produit lorsque vous essayez de regrouper un rapport dont l'ID partagé a déjà été inclus dans un lot précédent qui a réussi. Cette erreur se produit en raison de la règle "Pas de doublons", selon laquelle les rapports agrégables ne peuvent apparaître que dans un seul lot et ne peuvent contribuer qu'à un seul rapport récapitulatif.

Chaque rapport se verra attribuer un "ID partagé" composé des champs shared_info de l'API, reporting_origin, destination_site, source_registration_time (tronqué par jour), scheduled_report_time (tronqué par heure) et version. Cela signifie que plusieurs rapports peuvent appartenir au même "ID partagé" s'ils partagent les mêmes attributs du champ shared_info.

Vérifier

Nous vous recommandons d'essayer l'assistance pour le budget de confidentialité épuisé fournie dans la réponse du job pour examiner et résoudre votre erreur. Cela fournit un nouveau fichier JSON d'aide qui permet de voir quels rapports ont contribué à l'erreur.

Notez que si vous regroupez correctement vos campagnes, vous pourrez peut-être bénéficier de la récupération du budget (explication). Suggérez-lui de lire l'explication et de remplir le formulaire, mais précisez que sa demande devra être approuvée pour qu'il puisse récupérer le budget et relancer le job.

Erreur DEBUG_SUCCESS_WITH_PRIVACY_BUDGET_EXHAUSTED
Cause Cela indique que vous exécutez le job en mode débogage. Le job_parameters de la requête createJob contient le debug_run: true. Lorsque l'indicateur debug_run est activé, vous pouvez exécuter le rapport plusieurs fois à des fins de débogage. Ce message d'erreur vous informe que le job aurait échoué en raison de l'épuisement du budget de confidentialité du rapport s'il n'avait pas été exécuté en mode débogage. Cette erreur ne sera valable que dans les versions 2.10.0 ou antérieures.
Vérifier Le corps de la requête createJob contiendra debug_run dans job_parameters.
            {
              "job_request_id": "{job_request_id}",
              "input_data_blob_prefix": "{input_prefix}",
              "input_data_bucket_name": "{input_bucket}",
              "output_data_blob_prefix": "{output_prefix}",
              "output_data_bucket_name": "{output_bucket}",
              "job_parameters": {
                "output_domain_blob_prefix": "{output_domain_prefix}",
                "output_domain_bucket_name": "{output_domain_bucket}",
                "attribution_report_to": "{reporting_origin}",
                "debug_run": "true"
              }
            }
          

Erreurs d'exécution des jobs

Erreur INVALID_JOB
Point de terminaison createJob
Cause Cela peut se produire lorsque l'epsilon de confidentialité de débogage fourni ne se trouve pas dans les limites (0,64] ou lorsque les paramètres du job ne sont pas validés.
Vérifier Quelle valeur epsilon a été utilisée ? Quels paramètres de job ont été utilisés dans la requête createJob ? Correspondent-ils à votre environnement ? Sont-ils correctement mis en forme ? Apportez les corrections nécessaires et réessayez.
Erreur INTERNAL_ERROR
Point de terminaison getJob
Cause Il peut s'agir d'un problème de formatage qui empêche le traitement du domaine de sortie ou des rapports. Il peut également s'agir d'un problème lié au déploiement de votre service d'agrégation.
Vérifier Vérifiez que l'emplacement du domaine de sortie est un chemin d'accès valide. Réessayez d'exécuter le job. Si l'erreur persiste, demandez le fichier auto.tfvars et la sortie du plan Terraform pour résoudre les problèmes de déploiement du service d'agrégation.
Erreur RESULT_WRITE_ERROR
Point de terminaison getJob
Cause Cela peut se produire lorsque l'écriture dans le répertoire de sortie échoue, de manière transitoire ou en raison d'un manque d'autorisation d'écriture dans le répertoire. Notez que les erreurs d'écriture consomment du budget de confidentialité et que la tâche ne peut pas être relancée. Cela peut contribuer à un autre résultat d'erreur de type PRIVACY_BUDGET_EXHAUSTED.
Vérifier Cette erreur se produit-elle pour tous les jobs ou seulement de temps en temps ? Si cela se produit dans chaque job, vérifiez que vous avez activé les autorisations d'écriture dans le répertoire de sortie. Si l'échec est intermittent, les autorisations devraient être correctes. Il s'agit d'un problème connu : il est possible que l'écriture de rapports récapitulatifs échoue, mais le budget de confidentialité sera tout de même consommé. Dans ce cas, vous pouvez demander la récupération du budget (explication).
Problème Vous rencontrez des erreurs 403 lors de l'exécution d'un job et de la récupération d'un jeton de service d'attestation, et le job renvoie toujours l'état "RECEIVED".
Erreur
            {
                "job_status": "RECEIVED",
                "request_received_at": "{utc timestamp}",
                "request_updated_at": "{utc timestamp}",
                "job_request_id": "0001",
                "input_data_blob_prefix": "reports/",
                "input_data_bucket_name": "{bucket_name}",
                "output_data_blob_prefix": "summary/",
                "output_data_bucket_name": "{bucket_name}",
                "postback_url": "",
                "job_parameters": {
                    "output_domain_bucket_name": "{bucket_name}",
                    "output_domain_blob_prefix": "output_domain/",
                    "attribution_report_to": 
                }
            }
          
Solution

Les jobs bloqués à l'état RECEIVED et l'erreur 403 se produisent généralement lorsque le compte de service n'a pas encore été intégré. Vérifiez que le compte de service que vous utilisez correspond à celui que vous avez indiqué dans votre demande d'intégration. Si vous n'avez pas encore envoyé de demande d'intégration, veuillez remplir le formulaire d'intégration et les formulaires d'inscription.

Une fois que vous avez vérifié l'état de votre inscription et de votre intégration, vérifiez ce qu'il est advenu de votre tâche en cours d'exécution.

Amazon Web Services

Dans ce cas, il est possible que l'enclave AWS ne soit pas en cours d'exécution ou qu'elle ait planté. Les tâches ne sont donc pas récupérées.

  1. Connectez-vous au gestionnaire de sessions de l'instance EC2.
  2. Suivez cette documentation AWS, qui inclut les étapes suivantes pour vous connecter à Session Manager.
  3. Accédez à AWS Console Manager > EC2 > Instances.
  4. Sélectionnez l'ID d'instance du service d'agrégation en cours d'exécution.
  5. Sélectionnez l'onglet"Session Manager " (Gestionnaire de sessions), puis cliquez sur le bouton "Connect" (Se connecter). Vous serez alors connecté à votre instance.
  6. Une fois l'instance Enclave en cours d'exécution, exécutez la commande suivante dans le terminal :
    sudo nitro-cli describe-enclaves
    Si cette commande n'affiche pas les journaux comme prévu, exécutez la commande suivante avant de réessayer :
    sudo nitro-cli run-enclave --cpu-count=2 --memory=7000 --eif-path=/opt/google/worker/enclave.eif
  7. Pour vérifier si l'enclave AWS a planté, exécutez la commande suivante : sudo journalctl -u aggregate-worker.service
  8. Vous devriez voir des journaux de sortie s'afficher, tels que :
    Starting aggregate-worker.service - Watcher script for nitro enclave.
    Les erreurs devraient être visibles ici en cas d'échec, etc.
Google Cloud Platform

Il est possible que le groupe d'instances géré (MIG) ne soit pas opérationnel. Si vous configurez Terraform adtech_setup pour la première fois, ou si vous l'avez détruit et recréé, vérifiez que votre compte de service est intégré. Si le compte de service n'est pas intégré, les MIG ne seront pas opérationnels.

  1. Dans la console Cloud, accédez à Compute Engine > Groupes d'instances.
  2. Consultez les colonnes d'état (les coches vertes indiquent que tout va bien).
  3. Cliquez sur l'un des groupes d'instances, puis consultez l'onglet "Erreurs" pour en savoir plus sur le problème. Cliquez sur le nom de l'instance pour accéder aux informations au niveau de la VM.
  4. Vous pouvez également utiliser votre terminal pour interagir avec le groupe d'instances et obtenir les mêmes informations. Essayez la commande list-errors :
    gcloud compute instance-groups managed list-errors --region=
    Voici un exemple de résultat.
                      INSTANCE_URL: https://www.googleapis.com/compute/v1/projects/aggservice-sandbox/zones/us-central1-c/instances/collector-operator-demo-env-67hd
                      ACTION: VERIFYING
                      ERROR_CODE: WAITING_FOR_HEALTHY_TIMEOUT_EXCEEDED
                      ERROR_MESSAGE: Waiting for HEALTHY state timed out (autohealingPolicy.initialDelay=200 sec) for instance projects/aggservice-sandbox/zones/us-central1-c/instances/collector-operator-demo-env-67hd and health check projects/aggservice-sandbox/global/healthChecks/operator-demo-env-collector-auto-heal-hc.
                      TIMESTAMP: 
                      INSTANCE_TEMPLATE: https://www.googleapis.com/compute/v1/projects/aggservice-sandbox/global/instanceTemplates/operator-demo-env-collector
                      VERSION_NAME: primary
                    
Si le problème persiste, enregistrez cette page et envoyez-la à notre équipe. Passez aux étapes suivantes.

Votre rapport récapitulatif génère-t-il les conversions attendues ?

Il peut arriver que votre appel getJob réussisse, mais qu'il y ait un problème avec le rapport récapitulatif renvoyé par le service d'agrégation. Le rapport récapitulatif est au format AVRO et devra être converti au format JSON. Une fois converti au format JSON, il ressemblera à ce qui suit.

{
  "bucket": "\u0005Y",
  "metric": 26308
}

Si la conversion AVRO pose problème, essayez d'utiliser les outils AVRO et la commande suivante sur le rapport AVRO. java -jar avro-tools-1.11.1.jar tojson [report_name].avro > [report_name].json Vous pouvez télécharger les versions stables ici. Si vous avez besoin d'aide, passez à l'étape suivante.

Étapes suivantes

Vérifiez si d'autres utilisateurs ont rencontré le même problème sur le tableau de bord de l'état de Privacy Sandbox ou sur le dépôt GitHub public.

Si vous ne trouvez pas de solution à votre problème lié au service d'agrégation, prévenez-nous en signalant un problème GitHub ou en envoyant le formulaire d'assistance technique.