Aggregationsjobs diagnostizieren

Prüfen Sie, ob Sie in der Befehlszeilenschnittstelle (Command-Line Interface, CLI) der von Ihnen verwendeten öffentlichen Cloud richtig authentifiziert sind.

AWS erfordert Nutzerberechtigungen, um Instanzen und andere für den Aggregationsdienst erforderliche Dienste erstellen zu können. Danach sollten Sie „terraform plan“ und „apply“ problemlos ausführen können.

In Google Cloud müssen Sie die Identität eines Dienstkontos übernehmen, um die zweite Hälfte des Terraform-Codes bereitzustellen. Ihr „terraform apply“-Befehl schlägt möglicherweise fehl, wenn Sie diesen Schritt übersprungen haben, da das Dienstkonto für die Bereitstellung alle erforderlichen Berechtigungen zum Erstellen von Ressourcen hat. Weitere Informationen finden Sie in der GitHub-Dokumentation unter Schritt 4: Bereitstellungsumgebung einrichten.

Prüfen Sie, ob die Website, die Sie im Feld attribution_report_to der createJob-Anfrage einreichen, mit der Website übereinstimmt, die beim Onboarding eingereicht wurde.

Die Website sollte mit der Website übereinstimmen, die für das Onboarding verwendet wurde, oder eine Subdomain davon sein. Das Onboarding für den Aggregation Service erfolgt auf der Ebene der Top-Level-Domain. Alle Subdomains können den Aggregation Service verwenden, sobald die Top-Level-Domain eingebunden ist.

Prüfen Sie, ob das Dienstkonto, das in Ihrer Aggregationsdienstbereitstellung verwendet wird, mit dem Dienstkonto übereinstimmt, das beim Onboarding angegeben wurde. Er muss genau übereinstimmen und nicht nur zum selben Projekt gehören.

Sie sollten dieselben Koordinatoren verwenden, die Ihnen per E-Mail zur Verfügung gestellt wurden. Wenn weiterhin Probleme auftreten, sammeln Sie die Datei „auto.tfvars“ und Informationen zum Ursprung des Berichts und wenden Sie sich über das Formular für technischen Support an uns.

            "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": 
            }
          

Das Problem mit dem Aufbrauchen des Privacy-Budgets tritt auf, wenn Sie versuchen, einen Bericht in einem Batch zu verarbeiten, dessen freigegebene ID bereits in einem zuvor erfolgreichen Batch enthalten war. Dieser Fehler tritt aufgrund der Regel „Keine Duplikate“ auf. Aggregierbare Berichte dürfen nur in einem einzelnen Batch enthalten sein und können nur zu einem zusammenfassenden Bericht beitragen.

Jedem Bericht wird eine „gemeinsame ID“ zugewiesen, die aus den Feldern shared_info API, reporting_origin, destination_site, source_registration_time (nach Tag gekürzt), scheduled_report_time (nach Stunde gekürzt) und version besteht. Das bedeutet, dass mehrere Berichte zur selben „gemeinsamen ID“ gehören können, wenn sie dieselben Attribute des Felds shared_info haben.

Wir empfehlen Ihnen, die Unterstützung bei ausgeschöpftem Datenschutzbudget zu nutzen, die in der Jobantwort bereitgestellt wird, um den Fehler zu untersuchen und zu beheben. Dadurch wird eine neue JSON-Hilfsdatei bereitgestellt, die Aufschluss darüber gibt, welche Berichte zum Fehler beigetragen haben.

Wenn Sie die Batch-Verarbeitung richtig anwenden, haben Sie möglicherweise Anspruch auf eine Budgetwiederherstellung (weitere Informationen). Schlage vor, dass sie sich die Erläuterung durchlesen und das Formular ausfüllen. Weise sie aber darauf hin, dass ihr Antrag genehmigt werden muss, damit das Budget wiederhergestellt und der Job noch einmal ausgeführt werden kann.

Wenn Jobs im Status RECEIVED hängen bleiben und der Fehler 403 auftritt, wurde das Dienstkonto in der Regel noch nicht eingerichtet. Prüfen Sie, ob das von Ihnen verwendete Dienstkonto mit dem übereinstimmt, das Sie in Ihrem Onboarding-Antrag angegeben haben. Wenn Sie noch keinen Antrag für die Einrichtung gestellt haben, füllen Sie bitte das Einrichtungsformular und die Anmeldeformulare aus.

Nachdem Sie den Status Ihrer Registrierung und Ihres Onboardings geprüft haben, sehen Sie nach, was mit Ihrem laufenden Job passiert ist.

In diesem Fall wird die AWS-Enklave möglicherweise nicht ausgeführt oder ist abgestürzt. Daher werden die Jobs nicht übernommen.

1. Stellen Sie eine Verbindung zur EC2-Instanz über Session Manager her.
2. Folgen Sie dieser AWS-Dokumentation, die die folgenden Schritte zum Herstellen einer Verbindung zu Session Manager enthält.
3. Rufen Sie die AWS Console Manager > EC2 > Instances auf.
4. Wählen Sie die Instanz-ID des ausgeführten Aggregationsdienstes aus.
5. Wählen Sie den Tab „Session Manager“ (Sitzungsmanager) > Schaltfläche „Connect“ (Verbinden) aus. Dadurch wird eine Verbindung zur Instanz hergestellt.
6. Sobald die Enclave-Instanz ausgeführt wird, führen Sie im Terminal Folgendes aus:
   sudo nitro-cli describe-enclaves
   Wenn mit diesem Befehl nicht wie erwartet Protokolle angezeigt werden, führen Sie Folgendes aus, bevor Sie es noch einmal versuchen:
   sudo nitro-cli run-enclave --cpu-count=2 --memory=7000 --eif-path=/opt/google/worker/enclave.eif
   
7. Führen Sie den folgenden Befehl aus, um zu prüfen, ob die AWS-Enklave abgestürzt ist: sudo journalctl -u aggregate-worker.service
8. Sie sollten sehen, dass Ausgabelogs wie die folgenden angezeigt werden:
   Starting aggregate-worker.service - Watcher script for nitro enclave.
   Hier sollten Fehler angezeigt werden, falls es welche gibt.

Die verwaltete Instanzgruppe (Managed Instance Group, MIG) ist möglicherweise nicht fehlerfrei. Wenn Sie die Einrichtung zum ersten Mal vornehmen oder die adtech_setup-Terraform zerstört und neu erstellt haben, prüfen Sie, ob Ihr Dienstkonto eingerichtet ist. Wenn das Dienstkonto nicht eingerichtet ist, sind die MIGs nicht fehlerfrei.

1. Rufen Sie in der Cloud Console „Compute Engine“ > „Instanzgruppen“ auf.
2. Statusspalten prüfen (grüne Häkchen bedeuten, dass alles in Ordnung ist)
3. Klicken Sie auf eine der Instanzgruppen und sehen Sie sich den Tab „Fehler“ an, um mehr über das Problem zu erfahren. Klicken Sie auf den Instanznamen, um Informationen auf VM-Ebene aufzurufen.
4. Sie können auch über das Terminal mit der Instanzgruppe interagieren und dieselben Informationen abrufen. Versuchen Sie es mit dem Befehl „list-errors“:
   gcloud compute instance-groups managed list-errors --region=
   Hier sehen Sie ein Beispiel für die Ausgabe.

                     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