אבחון הסביבה (חדשה או משודרגת)

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

נושאי המדריך:

• אימות ההגדרה של ממשק ה-API למדידת ביצועים של הלקוח
• פתרון בעיות בהגדרת מקור הדיווח
• פתרון בעיות בדוחות המצטברים
• בדיקת גרסת הפריסה

אימות ההגדרה של ממשק ה-API למדידת ביצועי לקוחות

אחרי שתבדקו ששרת המקור רשום כראוי, תוכלו לבצע את השלבים הבאים:

1. בודקים איך מפעילים את הדוחות. מוודאים שהדוח מגיע בפורמט הנכון בהתאם ל-API שבו נעשה שימוש:

   • Attribution Reporting API
     • ב-Attribution Reporting API, חשוב לוודא שהמקור נרשם בהצלחה (אירוע וסיכום). כדי לבצע רישום של טריגר (אירוע וסיכום), צריך לוודא שה-JSON שהוענק ל-Attribution-Reporting-Register-Trigger תקין באמצעות הכלי לאימות כותרות. (מידע נוסף זמין במאמר דוחות סיכום של Attribution Reporting API)
   • Private Aggregation API
     • אפשר לדווח ב-Private Aggregation API באמצעות הפונקציה contributeToHistogram. חשוב לוודא שאתם מעבירים את המפתח והערך של הקטגוריה. מפתח הקטגוריה צריך להיות בפורמט BigInt. (מידע נוסף על Private Aggregation API)

2. אם אתם מפעילים את הדוחות כפי שמומלץ, אבל הבעיה נמשכת, כדאי לבדוק אם יש שגיאות ב-Chrome Developer Console בכרטיסייה 'מסוף' ובכרטיסייה 'רשת'.

אם אתם זקוקים לתמיכה נוספת בפתרון בעיות בממשקי ה-API האלה ללקוח, תוכלו להיעזר בהנחיות לניפוי באגים ב-Attribution Reporting API ובהנחיות לניפוי באגים ב-Private Aggregation API + Shared Storage.

פתרון בעיות בהגדרת מקור הדיווח

בשרת המקור של הדיווח ציינתם את נקודות הקצה (endpoints) התואמות של .well-known, שאלהן יישלחו דוחות שאפשר לצבור. מוודאים ששרת המקור לדיווח שנפרס נרשם וסומן כראוי.

האם מקור הדיווח מקבל דוחות?

מוודאים ששרת המקור לדיווח שנפרס נרשם ונכלל בתוכנית כראוי. בשרת הזה הכרזתם על נקודות הקצה (endpoints) התואמות של .well-known, שאלהן יישלחו דוחות שאפשר לצבור.

אחרי שתאמתו ששרת המקור רשום כראוי, תוכלו לבצע את השלבים הבאים:

1. בודקים איך מפעילים את הדוחות. מוודאים שהדוח מגיע בפורמט הנכון בהתאם ל-API שבו נעשה שימוש:

   • דוחות סיכום של Attribution Reporting API
   • Private Aggregation API

2. אם אתם מפעילים את הדוחות כפי שמומלץ אבל הבעיה נמשכת, כדאי לבדוק אם יש שגיאות ב-Chrome Developer Console בכרטיסייה 'מסוף' ובכרטיסייה 'רשת'.

אם אתם זקוקים לתמיכה נוספת בפתרון בעיות בממשקי ה-API האלה ללקוח , תוכלו להמשיך לקרוא את ההנחיות לניפוי באגים ב-Attribution Reporting API וב-Private Aggregation API + Shared Storage.

פתרון בעיות בדוחות הצבירה

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

האם הדוחות שאפשר לצבור אותם ממירים בצורה נכונה?

מוודאים שנקודת הקצה לדיווח (.well-known/…) ממירה בצורה נכונה את דוח ה-JSON הנתון שאפשר לצבור ל-AVRO.

אלה שגיאות ה-API שעשויות להופיע בגלל הבעיה הזו:

                "result_info": {
                    "return_code": "REPORTS_WITH_ERRORS_EXCEEDED_THRESHOLD",
                    "return_message": "Aggregation job failed early because the number of reports excluded from aggregation exceeded threshold.",
                    "error_summary": {
                        "error_counts": [
                            {
                                "category": "DECRYPTION_ERROR",
                                "count": 1,
                                "description": "Unable to decrypt the report. This may be caused by: tampered aggregatable report shared info, corrupt encrypted report, or other such issues."
                            },
                            {
                                "category": "NUM_REPORTS_WITH_ERRORS",
                                "count": 1,
                                "description": "Total number of reports that had an error. These reports were not considered in aggregation. See additional error messages for details on specific reasons."
                            }
                        ],
                        "error_messages": []
                    }
                }
            

                "result_info": {
                    "return_code": "REPORTS_WITH_ERRORS_EXCEEDED_THRESHOLD",
                    "return_message": "Aggregation job failed early because the number of reports excluded from aggregation exceeded threshold.",
                    "error_summary": {
                        "error_counts": [{
                            "category": "DECRYPTION_KEY_NOT_FOUND",
                            "count": 1,
                            "description": "Could not find decryption key on private key endpoint."
                        }, {
                            "category": "NUM_REPORTS_WITH_ERRORS",
                            "count": 1,
                            "description": "Total number of reports that had an error. These reports were not considered in aggregation. See additional error messages for details on specific reasons."
                        }],
                        "error_messages": []
                    }
                }
            

                sharedStorage.run('someOperation', {'privateAggregationConfig':
                {'aggregationCoordinatorOrigin': ' https://publickeyservice.msmt.gcp.privacysandboxservices.com'}});

            

                "result_info": {
                        "return_code": "REPORTS_WITH_ERRORS_EXCEEDED_THRESHOLD",
                        "return_message": "Aggregation job failed early because the number of reports excluded from aggregation exceeded threshold.",
                        "error_summary": {
                            "error_counts": [
                                {
                                    "category": "DECRYPTION_KEY_FETCH_ERROR",
                                    "count": 1,
                                    "description": "Fetching the decryption key for report decryption failed. This can happen using an unapproved aggregation service binary, running the aggregation service binary in debug mode, key corruption or service availability issues."
                                },
                                {
                                    "category": "NUM_REPORTS_WITH_ERRORS",
                                    "count": 1,
                                    "description": "Total number of reports that had an error. These reports were not considered in aggregation. See additional error messages for details on specific reasons."
                                }
                            ]
                        }
                }
            

כדי לאמת את החשבון:

1. אפשר להשתמש בכלי aggregatable_report_converter כדי להמיר את הדוחות שאפשר לצבור שאספתם מנקודת הקצה ‎ .well-known ל-AVRO, וליצור את מפתחות הדומיין של הפלט. (הערה: קובצי הדומיין של הפלט צריכים להיות מחרוזת בייטים ב-big-endian באורך 16 בייטים).

2. פועלים לפי השלבים ב-codelab של ספק הענן הציבורי כדי לאסוף את דוחות ניפוי הבאגים ולהריץ משימה של Aggregation Service באמצעות מפתחות הדומיין של הפלט: א. Google Cloud: פועלים לפי השלבים 3.1.2 עד 3.2.3 במדריך Aggregation Service Google Cloud Codelab. ב. Amazon Web Services: פועלים לפי השלבים 4.2 עד 5.3 במדריך Aggregation Service AWS Codelab.

אם התגובה שתקבלו היא SUCCESS, סימן שההמרה פועלת.

האם הדוחות שאפשר לצבור אותם תקינים?

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

שגיאות ה-API שעשויות להופיע בהתאם לבעיה הזו הן:

כדי לאמת את החשבון:

1. אימות הדוח המצטבר:

   • יוצרים דוחות מצטברים ומשתמשים בכלי aggregatable_report_converter כדי להמיר את דומיין הפלט לפורמט AVRO.
   • מריצים בקשה מסוג createJob עם הדוח הזה שאפשר לצבור, ועם קובץ הפלט של הדומיין.
   • אם הפונקציה מחזירה את הערך SUCCESS, המשמעות היא שהדוח שניתן לצבור תקין. אם מתקבלת שגיאה, יש בעיה בדוח שאפשר לצבור או בדוח ובדומיין.
   • בשלב הבא, ממשיכים לבדוק את קובץ הדומיין.

2. בודקים את קובץ הדומיין של הפלט:

   • יוצרים קובץ של תוצאת הדומיין ומשתמשים בכלי aggregatable_report_converter כדי ליצור את הדוח שאפשר לצבור.
   • מריצים בקשה מסוג createJob עם הדוח הזה שאפשר לצבור, ועם קובץ הפלט של הדומיין.
   • אם הפונקציה מחזירה את הערך SUCCESS, סימן שדומיין הפלט תקין ויש בעיה בקוד ליצירת הדוח שניתן לצבור.
   • ממשיכים לשלב הבא כדי לבדוק את shared_info.

3. בודקים את המידע ששותף:

   • מוודאים שהפעלתם דיווחים על ניפוי באגים. בדוחות שהופעלה בהם ניפוי באגים יופיע השדה debug_cleartext_payload.
   • יוצרים דוח ניפוי באגים לשימוש בכלי הבדיקה המקומי, ומשתמשים ב-debug_cleartext_payload כמטען הייעודי.
   • מריצים את כלי הבדיקה המקומי עם קובץ הדומיין. אם הערך הוא SUCCESS, סימן שקובץ shared_info נפרץ.

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

בדיקת גרסת הפריסה החדשה

מוודאים שעדיין יש תמיכה בגרסת Aggregation Service שלכם. אחרי שתקבעו באיזו גרסה אתם משתמשים, תוכלו לבדוק את רשימת הגרסאות של Aggregation Service ולוודא שבגרסה שלכם לא מופיעה ההתראה על סיום התמיכה: This release has reached its end of support on { date }. ההוראות הבאות לזיהוי הגרסה שפרסמתם מיועדות לעננים הציבוריים הנתמכים.

שלבים ל-Google Cloud

1. עוברים אל Compute Engine‏ > VM instances.
2. לוחצים על המכונה הווירטואלית ששם המכונה שלה מכיל את -worker-.
3. מאתרים את הקטע Custom Metadata ואז את המפתח tee-image-reference.
   • הערה: כל מכונה וירטואלית שמוקצית ב-Google Cloud על ידי Terraform צריכה לכלול את המטא-נתונים האלה (מטא-נתונים של tee-image-reference במודול העבודה).
4. הערך של tee-image-reference יכיל את מספר הגרסה. לדוגמה, מספר הגרסה של הנתיב הבא הוא v2.9.1. אלו תמונות שנוצרו מראש ונמצאות ב-Artifact Registry של פרויקט ב-Google Cloud.
   • הערה: השם רלוונטי אם אתם משתמשים בנכסים שנוצרו מראש. אם לא, השם צריך להתאים לשם ולתג שנתתם אישית לתמונה. (לדוגמה: us.docker.pkg.dev/<gcp_project_name>/artifacts:aggregation-service- container-artifacts-worker_mp_go_prod:2.9.1)

שלבים ל-Amazon Web Services

1. עוברים אל EC2 Instances במסוף Amazon Web Services.
2. לוחצים על המכונה בשם aggregation-service-operator-dev-env.
3. בדף המכונה, מאתרים את Details (פרטים) > AMI (Amazon Machine Image).
4. שם הגרסה צריך להיכלל בנתיב של התמונה. לדוגמה, מספר הגרסה של הנתיב הבא הוא v2.9.1.
   • הערה: השדה הזה רלוונטי אם אתם משתמשים בנכסים שנוצרו מראש. אם לא, השם צריך להתאים לשם ולתג שנתתם אישית לתמונה. (לדוגמה: aggregation-service-enclave_2.9.1--2024-10-03T01-24-25Z)

השלבים הבאים

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