פתרון בעיות בבדיקות סינתטיות ובבדיקות זמני פעילות

במסמך הזה מוסבר איך למצוא נתוני יומן ואיך לפתור בעיות שקשורות לניטור סינתטי ולבדיקות זמינות:

חיפוש יומנים

בקטע הזה מוסבר איך למצוא יומנים של בדיקות זמינות ושל בדיקות סינתטיות:

  1. במסוף Google Cloud , נכנסים לדף Logs Explorer:

    כניסה אל Logs Explorer

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

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

  3. מבצעים אחת מהפעולות הבאות:

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

      כדי לבצע בדיקת זמני פעילות, בתפריט Resource בוחרים באפשרות Uptime Check URL, או מזינים את השאילתה הבאה בעורך השאילתות ולוחצים על Run query:

      resource.type="uptime_url"

      במקרה של בדיקות סינתטיות, בתפריט Resource בוחרים באפשרות Cloud Run Revision, או מזינים את השאילתה הבאה בעורך השאילתות ולוחצים על Run query:

      resource.type="cloud_run_revision"

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

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

        labels.check_id="my-check-id"

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

        "UptimeCheckResult"

        השאילתה הקודמת תואמת לכל הרשומות ביומן שכוללות את המחרוזת "UptimeCheckResult".

      היומנים האלה כוללים את הפרטים הבאים:

      • המזהה של הבדיקה הסינתטית או של בדיקת הזמינות, שמאוחסן בשדה labels.check_id.

      • בבדיקות סינתטיות, השם של פונקציית Cloud Run, שמאוחסן בשדה resource.labels.service_name.

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

    • כדי לוודא שהשירות שלכם קיבל בקשות משרתים של Google Cloud , מעתיקים את השאילתה הבאה לעורך השאילתות ולוחצים על Run query:

      "GoogleStackdriverMonitoring-UptimeChecks"

      השדה protoPayload.ip מכיל אחת מהכתובות שבהן משתמשים שרתי בדיקת הזמינות. מידע על הצגת רשימה של כל כתובות ה-IP זמין במאמר הצגת רשימת כתובות IP.

פתרון בעיות בנושא התראות

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

אחד מהבודקים נכשל, אבל האחרים לא נכשלו

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

לא צריך לעשות שום דבר כדי לפתור את הבעיה.

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

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

קיבלתם התראה ואתם רוצים לנפות באגים בכשל

  1. כדי לזהות מתי התחילה השגיאה, אפשר לבצע אחת מהפעולות הבאות:

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

      1. במסוף Google Cloud , עוברים לדף  בדיקת זמני פעילות:

        לדף בדיקת זמני פעילות

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

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

      3. מוצאים את בדיקת זמני הפעילות ובוחרים אותה.

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

    • כדי לדעת מתי הכשל התרחש בבדיקות סינתטיות, צריך לעיין בדף פרטי זמינות:

      1. במסוף Google Cloud , עוברים לדף  Synthetic monitoring:

        כניסה אל Synthetic monitoring

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

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

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

לא תקבלו הודעה על כך שבדיקת זמינות נכשלה

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

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

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

כדי להציג או לערוך מדיניות התראות:

  1. נכנסים לדף  Alerting במסוף Google Cloud :

    עוברים אל התראות

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

  2. בסרגל הכלים של מסוף Google Cloud , בוחרים את הפרויקט הרלוונטי ב- Google Cloud . בהגדרות של מרכז האפליקציות, בוחרים את פרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
  3. בחלונית Policies (מדיניות), לוחצים על See all policies (הצגת כל פריטי המדיניות).

  4. מאתרים את המדיניות שרוצים לראות או לערוך ולוחצים על השם שלה.

    אפשר לראות ולערוך את המדיניות בדף פרטי המדיניות.

פתרון בעיות בבדיקות זמני פעילות ציבוריות

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

בדיקות הזמינות הציבוריות שלך נכשלות

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

אלה כמה מהסיבות האפשריות לכשל בבדיקת זמינות:

  • שגיאת חיבור – נדחתה: אם אתם משתמשים בסוג החיבור HTTP שמוגדר כברירת מחדל, צריך לוודא שהתקנתם שרת אינטרנט שמגיב לבקשות HTTP. שגיאת חיבור יכולה להתרחש במופע חדש אם לא התקנתם שרת אינטרנט. אפשר לעיין במדריך למתחילים של Compute Engine. אם אתם משתמשים בסוג החיבור HTTPS, יכול להיות שתצטרכו לבצע שלבי הגדרה נוספים. לפתרון בעיות בחומת האש, אפשר לעיין במאמר בנושא רשימת כתובות ה-IP של שרתי בדיקת הזמינות.
  • לא נמצא שם או שירות: יכול להיות ששם המארח שגוי.
  • 403 Forbidden: השירות מחזיר קוד שגיאה לכלי לבדיקת זמינות. לדוגמה, הגדרת ברירת המחדל של שרת האינטרנט Apache מחזירה את הקוד הזה ב-Amazon Linux, אבל היא מחזירה את הקוד 200 (Success) בחלק מגרסאות Linux אחרות. אפשר לעיין במדריך LAMP ל-Amazon Linux או בתיעוד של שרת האינטרנט.
  • 404 לא נמצא: יכול להיות שהנתיב שגוי.
  • 408 בקשה שחורגת מהזמן הקצוב לתפוגה, או ללא תגובה: יכול להיות שמספר היציאה שגוי, שהשירות לא פועל, שהשירות לא נגיש או שהזמן הקצוב לתפוגה קצר מדי. בודקים שחומת האש מאפשרת תעבורה משרתי זמני הפעילות. אפשר לעיין ברשימת כתובות ה-IP של שרתי בדיקת זמני הפעילות. מגדירים את מגבלת הזמן הקצוב לתפוגה באפשרויות של אימות התגובה.

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

פתרון בעיות בבדיקות זמני פעילות פרטיות

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

יצירת בדיקה של זמני פעילות נכשלת

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

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

מסוף Google Cloud

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

במאמר איך מאשרים את חשבון השירות מוסבר איך נותנים תפקידים לחשבון שירות.

‫API: הגדרת היקף הפרויקט

בפעם הראשונה שבה יוצרים בדיקת זמינות פרטית לשירות Service Directory ולמשאבים פרטיים בפרויקט Google Cloud יחיד, יכול להיות שהבקשה תצליח או תיכשל. התוצאה תלויה בשאלה אם השבתתם את הקצאת התפקידים האוטומטית לחשבונות שירות בפרויקט:

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

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

אם יצירת בדיקת זמני הפעילות נכשלת, צריך לבצע את הפעולות הבאות:

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

‫API: פרויקט במעקב

בפעם הראשונה שיוצרים בדיקת זמינות פרטית שמכוונת לשירות Service Directory בפרויקט שנמצא במעקב או למשאבים פרטיים בפרויקט אחר Google Cloud , הבקשה נכשלת ונוצר חשבון שירות של Monitoring.

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

  • הפרויקט שבו הגדרתם את בדיקת הפרטיות בזמן פעולה תקינה.
  • הפרויקט שבמעקב שבו הגדרתם את שירות Service Directory.
  • הפרויקט שבו הגדרתם את רשת ה-VPC.
  • הפרויקט שבו מוגדרים משאבי רשת כמו מכונות וירטואליות או מאזני עומסים. לפרויקט הזה אין תפקיד בהרשאה של חשבון השירות שמתוארת כאן.

אם יצירת הבדיקה הראשונה של זמני הפעילות נכשלת, צריך לבצע את הפעולות הבאות:

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

הגישה נדחתה

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

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

מידע נוסף על גישה לרשתות פרטיות זמין במאמר הגדרת פרויקט הרשת.

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

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

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

כותרות ברירת מחדל

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

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

כותרת ערך
HTTP_USER_AGENT GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)
HTTP_CONNECTION keep-alive
HTTP_HOST כתובת ה-IP של נקודת הקצה של Service Directory
HTTP_ACCEPT_ENCODING gzip, deflate, br
CONTENT_LENGTH החישוב בוצע על סמך נתוני זמינות שפורסמו

אם תנסו לשנות את הערכים האלה, יכול להיות שיקרו הדברים הבאים:

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

לא מוצגים נתונים

לא מוצגים נתונים בלוח הבקרה של בדיקת הזמינות אם בדיקת הזמינות נמצאת בפרויקט אחר Google Cloud משירות Service Directory.

מוודאים ש Google Cloud הפרויקט שמכיל את בדיקת זמני הפעילות עוקב אחרי Google Cloud הפרויקט שמכיל את שירות Service Directory.

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

פתרון בעיות בבדיקות סינתטיות

בקטע הזה מוסבר איך אפשר לפתור בעיות שקשורות לבדיקות סינתטיות.

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

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

An error occurred during fetching available regions: Cloud Functions API has
not been used in project PROJECT_ID before or it is disabled.

בהודעת השגיאה מומלץ לוודא שה-API מופעל, ואז להמתין ולנסות לבצע את הפעולה שוב.

כדי לוודא שממשק ה-API מופעל, עוברים לדף APIs & Services של הפרויקט:

כניסה אל APIs & Services

אחרי שמוודאים שה-API מופעל, אפשר להמשיך בתהליך היצירה. המצב הזה נפתר באופן אוטומטי אחרי שהפעלת ה-API מועברת דרך ה-backend.

לא מתבצע מעקב אחרי בקשות HTTP יוצאות

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

ב-Cloud Trace מוצג רק מעקב אחד.

כדי לפתור את הבעיה, צריך לוודא שחשבון השירות קיבל את התפקיד Cloud Trace Agent (סוכן Cloud Trace) ‏(roles/cloudtrace.agent). גם התפקיד Editor (עריכה) ‏(roles/editor) מספיק.

כדי לראות את התפקידים שניתנו לחשבון השירות:

  1. נכנסים לדף IAM במסוף Google Cloud :

    כניסה לדף IAM

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא IAM & Admin.

  2. בסרגל הכלים של מסוף Google Cloud , בוחרים את הפרויקט הרלוונטי ב- Google Cloud . בהגדרות של מרכז האפליקציות, בוחרים את פרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
  3. מסמנים את התיבה Include Google-provided role grants.

  4. אם חשבון השירות שבו נעשה שימוש בבדיקה הסינתטית לא מופיע, או אם לא הוקצה לו תפקיד שכולל את ההרשאות בתפקיד של Cloud Trace Agent ‏ (roles/cloudtrace.agent), צריך להקצות את התפקיד הזה לחשבון השירות.

    אם אתם לא יודעים את השם של חשבון השירות, בתפריט הניווט בוחרים באפשרות חשבונות שירות.

הסטטוס 'בתהליך'

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

כדי לבדוק אם הפריסה של הפונקציה נכשלה, אפשר לנסות את הפעולות הבאות:

  • מוודאים ששם פונקציית Cloud Run לא מכיל קו תחתון. אם יש קו תחתון, צריך להסיר אותו ולפרוס מחדש את פונקציית Cloud Run.

  • פותחים את הדף פרטים של בדיקת זמינות סינתטית של בדיקת הזמינות הסינתטית.

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

    Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.

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

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

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

    This function has failed to deploy and will not work correctly. Please edit and redeploy

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

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

סטטוס אזהרה

בקטע Synthetic monitors (בדיקות סינתטיות) מופיעה בדיקה סינתטית עם הסטטוס Warning. הסטטוס Warning מציין שהתוצאות של ההרצה לא עקביות. יכול להיות שהדבר מצביע על בעיה בתכנון הבדיקה, או על כך שההתנהגות של מה שנבדק לא עקבית.

סטטוס: נכשל

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

  • אם מוצגת הודעת השגיאה Request failed with status code 429, הפקודה נדחתה על ידי היעד של בקשת ה-HTTP. כדי לפתור את הכשל הזה, צריך לשנות את היעד של הבדיקה הסינתטית.

    נקודת הקצה (endpoint) https://www.google.com דוחה בקשות שנשלחות על ידי כלי מעקב סינתטיים.

  • אם השגיאה מחזירה זמן ביצוע של 0ms, יכול להיות שפונקציית Cloud Run לא מקבלת מספיק זיכרון. כדי לפתור את הבעיה, עורכים את פונקציית Cloud Run, מגדילים את הזיכרון ל-2 GiB לפחות ומגדירים את השדה CPU ל-1.

המחיקה נכשלת עבור מעקב סינתטי

אתם משתמשים ב-Cloud Monitoring API כדי למחוק בדיקה סינתטית, אבל קריאת ה-API נכשלת עם תגובה שדומה לתגובה הבאה:

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.DebugInfo",
        "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
      }
    ]
  }
}

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

אי אפשר לערוך את ההגדרה של כלי לבדיקת קישורים שבורים

יצרתם כלי לבדיקת קישורים שבורים באמצעות Google Cloud המסוף, ואתם רוצים לשנות את רכיבי ה-HTML שנבדקים, או לשנות את הזמן הקצוב לתפוגה של ה-URI, את מספר הניסיונות החוזרים, את ההמתנה לבחירת הרכיב ואת האפשרויות לכל קישור. אבל כשעורכים את הכלי לבדיקת קישורים שבורים, שדות ההגדרה לא מוצגים במסוף Google Cloud .

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

  1. במסוף Google Cloud , עוברים לדף  Synthetic monitoring:

    כניסה אל Synthetic monitoring

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

  2. בסרגל הכלים של מסוף Google Cloud , בוחרים את הפרויקט הרלוונטי ב- Google Cloud . בהגדרות של מרכז האפליקציות, בוחרים את פרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
  3. מחפשים את הבדיקה הסינתטית שרוצים לערוך, לוחצים על אפשרויות נוספות ובוחרים באפשרות עריכה.
  4. לוחצים על עריכת הפונקציה.

  5. עורכים את האובייקט options בקובץ index.js ולוחצים על החלת הפונקציה.

    מידע על השדות והתחביר של האובייקט הזה זמין במאמר broken-links-ok/index.js.

  6. לוחצים על Save.

Google Cloud המסוף מציג שהשמירה של צילומי המסך נכשלה

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

  • InvalidStorageLocation
  • StorageValidationError
  • BucketCreationError
  • ScreenshotFileUploadError

כדי לפתור את הבעיות האלה, נסו את הפתרונות הבאים:

  • אם מופיעה ההודעה InvalidStorageLocation, צריך לוודא שהקטגוריה של Cloud Storage שצוינה בשדה options.screenshot_options.storage_location קיימת.

  • צפייה ביומנים שקשורים לפונקציית Cloud Run. מידע נוסף מופיע במאמר בנושא איתור יומנים.

  • מוודאים שלחשבון השירות שבו נעשה שימוש בפונקציית Cloud Run המתאימה יש תפקיד בניהול הזהויות והרשאות הגישה (IAM) שמאפשר לו ליצור קטגוריות של Cloud Storage, לגשת אליהן ולכתוב בהן.