ניסיון חוזר של אירועים

רגילה

‫Eventarc Standard תומך בהעברת אירועים לפחות פעם אחת. המשמעות היא שאם יעד לא מאשר קבלת אירוע, Eventarc ינסה באופן אוטומטי לשלוח אותו מחדש.

מאפייני הניסיון החוזר של Eventarc Standard זהים לאלה של שכבת התעבורה שלו, Cloud Pub/Sub, שמטפל בכשלים בעיבוד באמצעות מדיניות ניסיון חוזר של מינוי.

איך מתבצעים ניסיונות חוזרים

כשיוצרים טריגר Eventarc, נושא התעבורה והמינוי של Pub/Sub נוצרים אוטומטית. (אירועים ממקורות Pub/Sub יכולים להשתמש בנושא Pub/Sub קיים). כל מזהה מינוי שנוצר אוטומטית על ידי Eventarc יהיה בפורמט שמתחיל ב-eventarc-REGION-.

כברירת מחדל, כאשר יעד לא יכול לאשר קבלה של הודעה, מערכת Pub/Sub תשלח את ההודעה שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff). השהיה מעריכית לפני ניסיון חוזר (exponential backoff) מאפשרת להוסיף השהיות ארוכות יותר ויותר בין ניסיונות חוזרים. העיכוב שמוגדר כברירת מחדל מתחיל ב-10 שניות לפחות וגדל עם כל ניסיון כושל, עד למקסימום של 600 שניות. ב-Eventarc, משך השמירה של ההודעות מוגדר כברירת מחדל ל-24 שעות.

מידע נוסף על האופן שבו Pub/Sub מטפל בניסיונות חוזרים זמין במאמרים טיפול בכשלים בהודעות וניסיון חוזר של בקשות.

שיטות מומלצות לטיפול בניסיונות חוזרים

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

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

הגדרת ניסיונות חוזרים

יכול להיות שתרצו להתאים אישית את התנהגות ברירת המחדל של הניסיון החוזר. כל הגדרות הניסיון החוזר והשמירה מוגדרות באמצעות מדיניות הניסיון החוזר של מינוי Pub/Sub שמשויכת לטריגר Eventarc.

כדי לשנות את מדיניות הניסיון החוזר של המינוי, קודם צריך לזהות את מינוי Pub/Sub שמשויך לטריגר Eventarc. לאחר מכן, מעדכנים את המינוי עצמו.

מידע נוסף על מאפייני מינוי זמין במאמר מאפייני מינוי. מידע על מגבלות המינוי זמין במאמר מגבלות על משאבים ב-Pub/Sub.

זיהוי המינוי

כדי לזהות את המינוי ל-Pub/Sub שמשויך לטריגר Eventarc:

המסוף

1. נכנסים לדף Triggers ב-Eventarc במסוף Google Cloud .

   כניסה לדף Triggers

2. ברשימת הטריגרים, לוחצים על הטריגר שרוצים לראות את הפרטים שלו.

3. לוחצים על שם הנושא.

4. כדי להציג את מזהה המינוי, לוחצים על הכרטיסייה מינויים.

gcloud

אפשר להשתמש בפקודה gcloud eventarc triggers describe כדי לאחזר את מזהה המינוי.

gcloud eventarc triggers describe TRIGGER_NAME \
    --location=LOCATION

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

• ‫TRIGGER_NAME: השם של הטריגר או מזהה מלא.
• ‫LOCATION: המיקום של טריגר Eventarc.

הפקודה הזו מחזירה מידע על הטריגר שדומה למידע הבא וכולל את מזהה המינוי:

  createTime: '2023-03-16T13:40:44.889670204Z'
  destination:
    cloudRun:
      path: /
      region: us-central1
      service: hello
  eventDataContentType: application/protobuf
  eventFilters:
  ...
  transport:
    pubsub:
      subscription: projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID
      topic: projects/PROJECT_ID/topics/TOPIC_ID

Terraform

כדי לתאר משאב של Terraform‏ google_eventarc_trigger, אפשר להשתמש בפקודה state show.

terraform state show google_eventarc_trigger.default

הפקודה state show מחזירה מידע על הטריגר, כולל מזהה המינוי. לדוגמה:

# google_eventarc_trigger.default:
resource "google_eventarc_trigger" "default" {
    conditions              = {}
    create_time             = "2025-07-14T17:29:22.575033822Z"
    effective_labels        = {
        "goog-terraform-provisioned" = "true"
    }
    ...
    transport {
        pubsub {
            subscription = "projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID"
            topic        = "projects/PROJECT_ID/topics/TOPIC_ID"
        }
    }
}

מידע נוסף על שימוש ב-Terraform זמין במאמרי העזרה בנושא Terraform ב- Google Cloud .

REST

כדי לתאר טריגר בפרויקט ובמיקום מסוימים, משתמשים ב-method‏ projects.locations.triggers.get.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

• ‫TRIGGER_NAME: השם של הטריגר שרוצים לתאר.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud.
• ‫LOCATION: האזור שבו נוצר הטריגר, לדוגמה us-central1.

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

מריצים את הפקודה הבאה:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://eventarc.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/triggers/TRIGGER_NAME"

‎PowerShell (Windows)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://eventarc.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/triggers/TRIGGER_NAME" | Select-Object -Expand Content

אם הפעולה בוצעה ללא שגיאות, גוף התגובה יכיל מופע של Trigger, למשל:

{
  "name": "projects/PROJECT_ID/locations/LOCATION/triggers/TRIGGER_NAME",
  "uid": "d700773a-698b-47b2-a712-2ee10b690062",
  "createTime": "2022-12-06T22:44:04.744001514Z",
  "updateTime": "2022-12-06T22:44:09.116459550Z",
  "eventFilters": [
    {
      "attribute": "type",
      "value": "google.cloud.pubsub.topic.v1.messagePublished"
    }
  ],
  "serviceAccount": "SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com",
  "destination": {
    "workflow": "projects/PROJECT_ID/locations/LOCATION/workflows/WORKFLOW_NAME"
  },
  "transport": {
    "pubsub": {
      "topic": "projects/PROJECT_ID/topics/TOPIC_ID",
      "subscription": "projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID"
    }
  }
}

עדכון המינוי

כדי לעדכן את מדיניות הניסיון החוזר של מינוי Pub/Sub שמשויך לטריגר Eventarc:

המסוף

1. נכנסים לדף Triggers ב-Eventarc במסוף Google Cloud .

   כניסה לדף Triggers

2. ברשימת הטריגרים, לוחצים על הטריגר שרוצים לראות את הפרטים שלו.

3. לוחצים על שם הנושא.

4. כדי להציג את מזהה המינוי, לוחצים על הכרטיסייה מינויים.

5. לוחצים על מזהה המינוי ואז על עריכה.

6. בקטע Retry policy, בוחרים באפשרות Retry immediately.

   לחלופין, כדי לנסות שוב אחרי השהיה מעריכית (exponential backoff), מזינים את הערכים הבאים בשניות:

   • השהיה מינימלית לפני ניסיון חוזר (backoff): ההשהיה המינימלית בשניות בין מסירות עוקבות של הודעה נתונה. ברירת המחדל היא 10 שניות, והערך צריך להיות בין 0 ל-600.

   • Maximum backoff: the maximum delay in seconds between consecutive deliveries of a given message. ברירת המחדל היא 600 שניות, והערך צריך להיות בין 0 ל-600.

   מידע נוסף זמין במאמר בנושא מדיניות ניסיון חוזר.

7. לוחצים על עדכון.

gcloud

אפשר להשתמש בפקודה gcloud pubsub subscriptions update כדי לעדכן את מדיניות הניסיון החוזר לחיוב המינוי.

gcloud pubsub subscriptions update SUBSCRIPTION_ID \
    --min-retry-delay=MIN_RETRY_DELAY \
    --max-retry-delay=MAX_RETRY_DELAY

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

• ‫SUBSCRIPTION_ID: המזהה של המינוי או מזהה מלא.

• כדי לנסות שוב אחרי השהיה מעריכית לפני ניסיון חוזר (exponential backoff), צריך לציין את שני הדגלים הבאים. אחרת, כל דגל שלא צוין יחזור לערך ברירת המחדל שלו:

  • ‫MIN_RETRY_DELAY: ההשהיה המינימלית בשניות בין מסירות עוקבות של הודעה נתונה. ברירת המחדל היא 10 שניות, והערך צריך להיות בין 0 ל-600.
  • ‫MAX_RETRY_DELAY: העיכוב המקסימלי בשניות בין מסירות עוקבות של הודעה נתונה. ברירת המחדל היא 600 שניות, והערך צריך להיות בין 0 ל-600.

אפשר גם להשתמש בדגל --clear-retry-policy כדי לנקות את מדיניות הניסיון החוזר ולהגדיר את המינוי לניסיון חוזר מיידי.

Terraform

כדי לעדכן את מדיניות הניסיון החוזר של מינוי Pub/Sub, צריך להגדיר את משאב Terraform‏ google_pubsub_subscription. משתמשים בבלוק import כדי לייבא את המינוי הקיים, כך ש-Terraform תוכל לעקוב אחרי המשאב בקובץ המצב. אחרי הייבוא, אפשר לנהל את המשאב כמו כל משאב אחר, באמצעות ignore_changes כדי לציין מאפיינים ש-Terraform צריך להתעלם מהם כשמעדכנים את המשאב.

לדוגמה:

import {
  to = google_pubsub_subscription.default
  id = "SUBSCRIPTION_ID"
}

resource "google_pubsub_subscription" "default" {
  name  = "SUBSCRIPTION_ID"
  topic = "TOPIC_ID"
  retry_policy {
    minimum_backoff = "MIN_RETRY_DELAYs"
    maximum_backoff = "MAX_RETRY_DELAYs"
  }
  lifecycle {
    # Ignore push delivery configuration which is managed by Eventarc
    ignore_changes = [push_config]
  }
}

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

• ‫SUBSCRIPTION_ID: מזהה המינוי.
• ‫TOPIC_ID: מזהה הנושא.
• ‫MIN_RETRY_DELAY: ההשהיה המינימלית בשניות בין מסירות עוקבות של הודעה נתונה. ברירת המחדל היא 10 שניות, והערך צריך להיות בין 0 ל-600.
• ‫MAX_RETRY_DELAY: העיכוב המקסימלי בשניות בין מסירות עוקבות של הודעה נתונה. ברירת המחדל היא 600 שניות, והערך צריך להיות בין 0 ל-600.

REST

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

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

• ‫MIN_RETRY_DELAY: ההשהיה המינימלית בשניות בין מסירות עוקבות של הודעה נתונה. ברירת המחדל היא 10 שניות, והערך צריך להיות בין 0 ל-600.
• ‫MAX_RETRY_DELAY: העיכוב המקסימלי בשניות בין מסירות עוקבות של הודעה נתונה. ברירת המחדל היא 600 שניות, והערך צריך להיות בין 0 ל-600.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud.
• ‫SUBSCRIPTION_ID: המזהה של מינוי Pub/Sub שאתם מעדכנים.

תוכן בקשת JSON:

{
  "subscription": {
    "retryPolicy": {
      "minimumBackoff": "MIN_RETRY_DELAYs",
      "maximumBackoff": "MAX_RETRY_DELAYs"
    }
  },
  "updateMask": "retry_policy.maximum_backoff,retry_policy.minimum_backoff"
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

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

cat > request.json << 'EOF'
{
  "subscription": {
    "retryPolicy": {
      "minimumBackoff": "MIN_RETRY_DELAYs",
      "maximumBackoff": "MAX_RETRY_DELAYs"
    }
  },
  "updateMask": "retry_policy.maximum_backoff,retry_policy.minimum_backoff"
}
EOF

לאחר מכן מבצעים את הפקודה הבאה כדי לשלוח את בקשת ה-REST:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID"

‎PowerShell (Windows)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

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

@'
{
  "subscription": {
    "retryPolicy": {
      "minimumBackoff": "MIN_RETRY_DELAYs",
      "maximumBackoff": "MAX_RETRY_DELAYs"
    }
  },
  "updateMask": "retry_policy.maximum_backoff,retry_policy.minimum_backoff"
}
'@  | Out-File -FilePath request.json -Encoding utf8

לאחר מכן מבצעים את הפקודה הבאה כדי לשלוח את בקשת ה-REST:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID" | Select-Object -Expand Content

אם הפעולה בוצעה ללא שגיאות, גוף התגובה יכיל מופע של Subscription, למשל:

{
  "name": "projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID",
  "topic": "projects/PROJECT_ID/topics/TOPIC_ID",
  ...
  "retryPolicy": {
    "minimumBackoff": "MIN_RETRY_DELAYs",
    "maximumBackoff": "MAX_RETRY_DELAYs"
  },
  "state": "ACTIVE"
}

שיקולים נוספים לגבי ניסיון חוזר

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

השהיות של שליחת בקשות

אם מנוי ל-push שולח יותר מדי אישורים שליליים, יכול להיות ש-Pub/Sub יתחיל להעביר הודעות באמצעות השהיית push. כש-Pub/Sub משתמש בהשהיה לפני ניסיון חוזר (backoff) של דחיפת הודעות, הוא מפסיק לשלוח הודעות למשך פרק זמן שנקבע מראש. טווח הזמן הזה יכול להיות בין 100 אלפיות שנייה ל-60 שניות. אחרי שהזמן חולף, Pub/Sub מתחיל לספק הודעות שוב. מידע נוסף זמין במאמר בנושא השהיית ניסיון השליחה.

נושאים להודעות ללא מוצא

אם היעד לא מקבל את ההודעה, אפשר להעביר הודעות שלא נמסרו לנושא להודעות ללא מוצא (שנקרא גם תור של הודעות שלא נמסרו). נושא להודעות ללא מוצא יכול לאחסן הודעות שהיעד לא יכול לאשר את קבלתן. חובה להגדיר נושא להודעות ללא מוצא כשיוצרים או מעדכנים מינוי ל-Pub/Sub, ולא כשיוצרים נושא Pub/Sub או כש-Eventarc יוצר נושא Pub/Sub. למידע נוסף, ראו הגדרת נושא להודעות ללא מוצא.

שגיאות שלא מצדיקות ניסיונות חוזרים

כשמשתמשים ב-Pub/Sub כמקור האירועים באפליקציות והאירוע לא מועבר, המערכת מנסה להעביר אותו שוב באופן אוטומטי, למעט שגיאות שלא מצדיקות ניסיונות חוזרים. אם תהליך העבודה לא מופעל, לא יתבצע ניסיון חוזר לשליחת אירועים ליעד Workflows מכל מקור. שימו לב: מערכת Workflows מאשרת אירועים ברגע שהפעלת תהליך העבודה מתחילה. אם הפעלת תהליך העבודה מתחילה אבל נכשלת בהמשך, המערכת לא מנסה להפעיל מחדש את התהליך. כדי לפתור בעיות כאלה בשירות, צריך לטפל בשגיאות ובניסיונות חוזרים בתהליך העבודה.

אירועים כפולים

יכול להיות שאירועים כפולים יועברו ל-event handlers. בהתאם למפרט CloudEvents, השילוב של מאפייני source ו-id נחשב ייחודי, ולכן כל האירועים עם אותו שילוב נחשבים כפילויות. מומלץ להטמיע מטפלי אירועים אידמפוטנטיים כשיטה מומלצת כללית.

גורמים מטפלים באירועים אידמפוטנטיים

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

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