אבחון משימות הצבירה

בטבלאות הבאות מפורטות מגוון בעיות וקודי סטטוס של שגיאות, עם סיבות אפשריות לבעיה ופעולות שאפשר לבצע כדי לצמצם את הסיכון לפריסה. אם אתם רוצים לעיין במפרטים מלאים של שגיאות ודרכים לצמצום הסיכון בשירות האגרגציה, תוכלו לעיין בהנחיות הציבוריות העדכניות שלנו.

נושאים במדריך:

שגיאות הרשאות והרשאות גישה

בעיה בעיות בהרשאות כשמריצים את הפקודות terraform plan או terraform apply בפרויקט בענן הציבורי.
דוגמה לשגיאה Error: UnauthorizedOperation: You are not authorized to perform this operation.
רזולוציה

בודקים שהאימות שלכם לממשק שורת הפקודה (CLI) של הענן הציבורי שבו אתם משתמשים מתבצע בצורה תקינה.

‫Amazon Web Services

ב-AWS נדרשות הרשאות משתמש כדי ליצור מופעים ושירותים אחרים שנדרשים לשירות הצבירה. אחרי שתחיל את השינוי הזה, תוכל לבצע את הפעולות terraform plan ו-apply ללא בעיות.

‫Google Cloud Platform

ב-Google Cloud, שימו לב שתצטרכו להתחזות לחשבון שירות כדי לפרוס את החלק השני של Terraform. יכול להיות שהפקודה terraform apply תיכשל אם דילגתם על השלב הזה, כי לחשבון השירות של הפריסה יש את כל ההרשאות הנדרשות ליצירת משאבים. במאמרי העזרה של GitHub, אפשר לעיין בשלב 4 בקטע 'הגדרת סביבת הפריסה'.

שגיאות במכסת הפרטיות

שגיאה PRIVACY_BUDGET_ERROR
סיבה המשמעות היא שהשירות לא הצליח לעבד את הדוחות בגלל שגיאה בשירות של תקציב הפרטיות.
המחאה אחרי שתנסו להריץ את העבודה שוב כדי לבדוק אם השגיאה הייתה זמנית, תוכלו לפנות אלינו באמצעות טופס התמיכה הטכנית.
שגיאה PRIVACY_BUDGET_AUTHORIZATION_ERROR
סיבה יכול להיות שאתם משתמשים במקור דיווח שונה מזה שהם סיפקו במהלך ההצטרפות.
המחאה

מוודאים שהאתר שציינתם בשדה attribution_report_to של בקשת createJob הוא אותו אתר שציינתם במהלך ההצטרפות.

האתר צריך להיות זהה לדומיין שצורף ל-AdSense או להיות תת-דומיין שלו. שימו לב שההצטרפות ל-Aggregation Service מתבצעת ברמת הדומיין העליון, וכל תת-הדומיינים יכולים להשתמש ב-Aggregation Service אחרי שהדומיין העליון מצטרף.
שגיאה PRIVACY_BUDGET_AUTHENTICATION_ERROR
סיבה יכול להיות שאתם משתמשים ב-ARN לא עדכני או שגוי.
המחאה Google Cloud Platform

מוודאים שחשבון השירות שבו נעשה שימוש בפריסת שירות הצבירה זהה לחשבון השירות שסופק במהלך ההצטרפות. היא צריכה להיות זהה בדיוק, ולא רק להשתייך לאותו פרויקט.

Amazon Web Services

ההנחה היא שאתם משתמשים באותם רכזי תרגום שקיבלתם באימייל. אם הבעיות נמשכות, צריך לאסוף את קובץ auto.tfvars ואת פרטי מקור הדיווח ולפנות אלינו באמצעות טופס התמיכה הטכנית.
שגיאה PRIVACY_BUDGET_EXHAUSTED
סיבה שגיאה: 
            "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": 
            }

בעיה של מיצוי תקציב הפרטיות מתרחשת כשמנסים להוסיף לחבילה דוח שהמזהה המשותף שלו כבר נכלל בחבילה קודמת שהצליחה. השגיאה הזו מתרחשת בגלל הכלל 'ללא כפילויות', שבו דוחות שאפשר לצבור מותרים להופיע רק באצווה אחת ויכולים לתרום רק לדוח סיכום אחד.

לכל דוח יוקצה 'מזהה משותף' שיכלול את שדות ה-API‏ shared_info, ‏ reporting_origin, ‏ destination_site, ‏ source_registration_time (חיתוך לפי יום), ‏ scheduled_report_time (חיתוך לפי שעה) ו-version. המשמעות היא שכמה דוחות יכולים להשתייך לאותו 'מזהה משותף' אם הם חולקים את אותם מאפיינים של השדה shared_info.
המחאה

מומלץ לנסות את התמיכה בנושא מיצוי תקציב הפרטיות שמופיעה בתגובה למשימה, כדי לבדוק את השגיאה ולפתור אותה. הפעולה הזו יוצרת קובץ JSON חדש שיעזור לכם להבין אילו דוחות תרמו לשגיאה.

שימו לב: אם אתם משתמשים באסטרטגיית בידינג של המרות בכמות גדולה בצורה נכונה, יכול להיות שתהיו זכאים לשחזור תקציב (הסבר). מציעים לו לקרוא את ההסבר ולמלא את הטופס, אבל מציינים שהבקשה שלו תצטרך אישור כדי לשחזר את התקציב ולהפעיל מחדש את העבודה.
שגיאה DEBUG_SUCCESS_WITH_PRIVACY_BUDGET_EXHAUSTED
סיבה המשמעות היא שהפעלתם את העבודה במצב ניפוי באגים. השדה job_parameters בבקשת createJob מכיל את debug_run: true. כשהדגל debug_run מופעל, אפשר להריץ את הדוח כמה פעמים למטרות ניפוי באגים. הודעת השגיאה הזו מודיעה לכם שהעבודה הייתה נכשלת בגלל שמיציתם את תקציב הפרטיות של הדוח, אם היא לא הייתה מופעלת במצב ניפוי באגים. השגיאה הזו תקפה רק בגרסאות v2.10.0 או גרסאות קודמות.
המחאה גוף הבקשה createJob יכיל את הערך debug_run בשדה 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"
              }
            }

שגיאות זמן ריצה של משימות

שגיאה INVALID_JOB
נקודת קצה createJob
סיבה זה יכול לקרות אם ערך האפסילון של הפרטיות לניפוי הבאגים שסופק לא נמצא בטווח (0.64], או אם פרמטרי העבודה לא עוברים אימות.
המחאה באיזה ערך אפסילון השתמשת? אילו פרמטרים של עבודה שימשו בבקשה createJob, והאם הם תואמים לסביבה שלכם? האם הפורמט שלהם נכון? מבצעים את התיקונים הנדרשים ומנסים שוב להריץ את העבודה.
שגיאה INTERNAL_ERROR
נקודת קצה getJob
סיבה יכול להיות שזו בעיה בפורמט שגורמת לעיבוד להיכשל בדומיין הפלט או בדוחות. יכול להיות שזו גם בעיה בפריסה של Aggregation Service.
המחאה מוודאים שהמיקום של דומיין הפלט הוא נתיב תקין. מנסים להפעיל מחדש את העבודה. אם השגיאה נמשכת, צריך לבקש את הקובץ auto.tfvars ואת הפלט של תוכנית Terraform כדי לפתור את הבעיה בפריסת שירות הצבירה.
שגיאה RESULT_WRITE_ERROR
נקודת קצה getJob
סיבה זה יכול לקרות אם הכתיבה לספריית הפלט נכשלת, באופן זמני או בגלל חוסר הרשאת כתיבה בספרייה. חשוב לדעת: שגיאות כתיבה צורכות את תקציב הפרטיות, ואי אפשר לנסות שוב את העבודה. הדבר הזה יכול לתרום לשגיאה נוספת, PRIVACY_BUDGET_EXHAUSTED.
המחאה האם השגיאה הזו מתרחשת בכל משימה, או רק מדי פעם? אם הבעיה מתרחשת בכל עבודה, צריך לוודא שהפעלתם הרשאות כתיבה בספריית הפלט. אם מדובר בכשל לסירוגין, ההרשאות אמורות להיות נכונות. זו בעיה מוכרת: יכול להיות שכתיבת דוחות סיכום תיכשל, אבל תקציב הפרטיות עדיין ינוצל. במקרה כזה, אפשר לבקש שחזור של התקציב (הסבר).
בעיה נתקלים בשגיאות 403 במהלך הפעלת משימה ואחזור אסימון של שירות אימות, והמשימה תמיד חוזרת עם הסטטוס RECEIVED.
שגיאה 
            {
                "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": 
                }
            }
רזולוציה

משימות נתקעות במצב RECEIVED והשגיאה 403 מתרחשת בדרך כלל כשחשבון השירות עדיין לא הועבר. מוודאים שחשבון השירות שבו אתם משתמשים זהה למה שסיפקתם בבקשת ההצטרפות. אם לא השלמתם בקשה להצטרפות, עליכם למלא את טופס ההצטרפות ואת טופסי ההרשמה.

אחרי שבודקים את סטטוס ההרשמה וההצטרפות, בודקים מה קרה לעבודה הפעילה.

Amazon Web Services

במצב כזה, יכול להיות שה-AWS enclave לא פועל או שהוא קרס, ולכן המשימות לא נאספות.

  1. מתחברים ל-Session Manager של מכונת EC2.
  2. פועלים לפי ההוראות בתיעוד של AWS, שכולל את השלבים הבאים לחיבור אל Session Manager.
  3. עוברים אל AWS Console Manager‏ > EC2‏ > Instances (מופעים).
  4. בוחרים את מזהה המופע של Aggregation Service שפועל.
  5. בוחרים בכרטיסייה 'Session Manager' (ניהול סשנים) > הלחצן 'Connect' (התחברות). הפעולה הזו תחבר אתכם למופע.
  6. אחרי שמריצים את מופע Enclave, מריצים את הפקודה הבאה במסוף:
    sudo nitro-cli describe-enclaves
    אם הפקודה הזו לא מציגה את היומנים כמו שציפיתם, מריצים את הפקודה הבאה לפני שמנסים שוב:
    sudo nitro-cli run-enclave --cpu-count=2 --memory=7000 --eif-path=/opt/google/worker/enclave.eif
  7. כדי לבדוק אם האנקלייב של AWS קרס, מריצים את הפקודה: sudo journalctl -u aggregate-worker.service
  8. יוצגו יומני פלט כמו:
    Starting aggregate-worker.service - Watcher script for nitro enclave.
    אם יש כשלים וכו', השגיאות יופיעו כאן.
Google Cloud Platform

יכול להיות שקבוצת המופעים המנוהלת (MIG) לא תקינה. אם זו הפעם הראשונה שאתם מבצעים את ההגדרה, או אם השבתתם את adtech_setup Terraform ויצרתם אותו מחדש, אתם צריכים לוודא שחשבון השירות שלכם נוסף. אם חשבון השירות לא יצורף, קבוצות ה-MIG לא יהיו תקינות.

  1. ב-Cloud Console, מנווטים אל Compute Engine > Instance groups
  2. בודקים את עמודות הסטטוס (סימני וי ירוקים מציינים שהסטטוס תקין)
  3. לוחצים על אחת מקבוצות המופעים ועוברים לכרטיסייה 'שגיאות' כדי לקבל מידע נוסף על הבעיה. לוחצים על שם המכונה כדי לגשת למידע ברמת המכונה הווירטואלית.
  4. אפשר גם להשתמש במסוף כדי ליצור אינטראקציה עם קבוצת המופעים ולקבל את אותו מידע. מנסים להריץ את הפקודה list-errors:
    gcloud compute instance-groups managed list-errors --region=
    בהמשך מופיע פלט לדוגמה. 
                      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
אם הבעיות נמשכות, כדאי לשמור את הנתונים האלה ולשלוח אותם לצוות שלנו. ממשיכים לשלבים הבאים.

האם דוח הסיכום ממיר כמצופה?

יכול להיות שהקריאה getJob תצליח, אבל תהיה בעיה בדוח הסיכום שמוחזר על ידי Aggregation Service. דוח הסיכום הוא בפורמט AVRO וצריך להמיר אותו לפורמט JSON. אחרי ההמרה לפורמט JSON, הוא ייראה בערך כך.

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

אם יש בעיה בהמרת AVRO, נסו להשתמש בכלי AVRO ובפקודה הבאה בדוח AVRO. java -jar avro-tools-1.11.1.jar tojson [report_name].avro > [report_name].json אפשר להוריד גרסאות יציבות מכאן. אם דרושה לך עזרה נוספת, אפשר לעבור לשלבים הבאים.

השלבים הבאים

בודקים אם מישהו אחר נתקל באותה בעיה במרכז השליטה של ארגז החול לפרטיות או במאגר הציבורי ב-GitHub.

אם לא מצאתם פתרון לבעיה בשירות הצבירה, אתם יכולים לדווח לנו על כך באמצעות פתיחת בעיה ב-GitHub או שליחת טופס תמיכה טכנית.