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

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

חיפוש יומנים

כדי לעזור לכם לקשר בין בקשות לבין היומנים שלכם, בקשות HTTP ו-HTTPS שנשלחות על ידי Cloud Monitoring כוללות כותרת Check-Id שבה מאוחסן המזהה של הבדיקה הסינתטית או של בדיקת הזמינות המשויכת. כדי למצוא יומנים של בדיקות סינתטיות ושל בדיקות זמני פעילות, מבצעים את הפעולות הבאות::

  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"

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

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

        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:

        מעבר אל מעקב סינתטי

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

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

  2. מידע על איתור נתוני יומן משויכים זמין במאמר בנושא איתור יומנים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Public uptime checks cannot be configured in a VPC Service Controls perimeter.

הודעת השגיאה הזו מציינת שהפרויקט Google Cloud שלכם נמצא בהיקף של VPC Service Controls שמופעל. אי אפשר ליצור בדיקות זמינות ציבוריות להגדרות האלה.

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

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

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

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

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

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

המסוף

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

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

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

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

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

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

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

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

‫gcloud: פרויקט בפיקוח

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

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

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

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

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

אי אפשר לטרגט שירות Cloud Run

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

כדי לטרגט שירות Cloud Run באמצעות בדיקת זמינות פרטית, צריך להגדיר מאזן עומסים פנימי של אפליקציות עם קצה עורפי של NEG ללא שרתים, ולרשום את כתובת ה-IP הפנימית של מאזן העומסים בספריית השירותים. דוגמה להגדרת מאזן עומסים מופיעה במאמר הגדרת מאזן עומסים של אפליקציות (ALB) פנימי אזורי באמצעות Cloud Run.

הגישה נדחתה

בדיקות זמני הפעילות שלך נכשלות עם תוצאות 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 החישוב מבוסס על נתוני זמן הפעולה (uptime) של POST

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

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

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

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

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

    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 דחה את הפקודה. כדי לפתור את הכשל הזה, צריך לשנות את היעד של הבדיקה הסינתטית.

    נקודת הקצה 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:

    מעבר אל מעקב סינתטי

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא 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, לגשת אליהן ולכתוב בהן.