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

בדיקות זמני פעילות ציבוריות מאפשרות לבדוק את הזמינות של כתובות URL ושל Google Cloud משאבים שנגישים לכולם, על ידי שליחת בקשות HTTP, ‏ HTTPS או TCP תקופתיות ממספר מיקומים ברחבי העולם. כשיוצרים בדיקת זמינות, אפשר גם להגדיר מדיניות התראות כדי לקבל התראה אם היעד לא מגיב. כדי לבדוק משאבים ברשת פרטית, אפשר לעיין במאמר בנושא יצירת בדיקות זמני פעילות פרטיות.

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

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

• כתובת URL לבדיקת זמינות
• VM instance
• אפליקציית App Engine
• שירות Kubernetes
• מכונה של Amazon Elastic Compute Cloud‏ (EC2)
• גרסת Cloud Run

ב-HTTP וב-HTTPS, המערכת עוקבת אחרי כל ההפניות לכתובות URL, והתגובה הסופית שמתקבלת בבדיקת הזמינות משמשת להערכת קריטריוני ההצלחה. בבדיקות של HTTPS, זמן התפוגה של אישור ה-SSL מחושב על סמך אישור השרת שמתקבל בתגובה הסופית.

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

• סטטוס ה-HTTP צריך להתאים לקריטריונים שציינתם.
• נתוני התשובה לא מכילים את התוכן הנדרש או שהתוכן הנדרש קיים.

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

לפני שמתחילים

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

1. כדי לקבל את ההרשאות שדרושות ליצירת בדיקות זמינות, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

   • Google Cloud משתמשי קונסולה: עורך המעקב (roles/monitoring.editor)
   • משתמשי API:
     • עורך הגדרות בדיקת זמני פעילות (Uptime) של מעקב (roles/monitoring.uptimeCheckConfigEditor)
     • עורך מדיניות ההתראות של Monitoring (roles/monitoring.alertPolicyEditor)
     • עריכת ערוץ ההתראות של המעקב (roles/monitoring.notificationChannelEditor)
   הערה: אם אתם מתכננים ליצור בדיקת זמינות בשירות Cloud Run, אתם צריכים גם את ההרשאה run.routes.invoke בשירות הזה.

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

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

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

4. מגדירים את ערוצי ההתראות שרוצים להשתמש בהם כדי לקבל התראות. מומלץ ליצור כמה סוגים של ערוצי התראות. מידע נוסף מופיע במאמר בנושא יצירה וניהול של ערוצי התראות.

5. מציינים לפחות שלושה בודקים לבדיקת הזמינות. האזור USA לבדיקת זמינות כולל את האזורים USA_OREGON, USA_IOWA ו-USA_VIRGINIA. לכל אחד מהאזורים USA_* יש בודק אחד, והבודק USA כולל את שלושתם. באזורים האחרים לבדיקת זמינות, EUROPE, SOUTH_AMERICA ו-ASIA_PACIFIC, יש בודק אחד בכל אזור.

   אם בוחרים באפשרות Global (גלובלי) כשמשתמשים במסוף Google Cloud , או באפשרות REGION_UNSPECIFIED כשמשתמשים ב-API, הבדיקות לזמינות מתבצעות מכל האזורים שבהם מתבצעות בדיקות לזמינות.

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

   המסוף

   כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים Google Cloud ולממשקי ה-API, לא צריך להגדיר אימות.

   gcloud

   במסוף Google Cloud , מפעילים את Cloud Shell.

   הפעלת Cloud Shell

   בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

   Terraform

   כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של Terraform שבדף הזה, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

   1. התקינו את ה-CLI של Google Cloud.

   2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

      gcloud auth application-default login

      אם אתם משתמשים ב-Cloud Shell, אתם לא צריכים לעשות את זה.

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

   למידע נוסף, ראו הגדרת ADC לסביבת פיתוח מקומית במאמרי העזרה בנושא אימות Google Cloud .

   C#‎

   כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של .NET שבדף הזה, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

   1. התקינו את ה-CLI של Google Cloud.

   2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

      gcloud auth application-default login

      אם אתם משתמשים ב-Cloud Shell, אתם לא צריכים לעשות את זה.

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

   למידע נוסף, ראו הגדרת ADC לסביבת פיתוח מקומית במאמרי העזרה בנושא אימות Google Cloud .

   המשך

   כדי להשתמש בדוגמאות של Go שבדף הזה בסביבת פיתוח מקומית, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

   1. התקינו את ה-CLI של Google Cloud.

   2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

      gcloud auth application-default login

      אם אתם משתמשים ב-Cloud Shell, אתם לא צריכים לעשות את זה.

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

   למידע נוסף, ראו הגדרת ADC לסביבת פיתוח מקומית במאמרי העזרה בנושא אימות Google Cloud .

   Java

   כדי להשתמש בדוגמאות של Java שבדף הזה בסביבת פיתוח מקומית, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

   1. התקינו את ה-CLI של Google Cloud.

   2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

      gcloud auth application-default login

      אם אתם משתמשים ב-Cloud Shell, אתם לא צריכים לעשות את זה.

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

   למידע נוסף, ראו הגדרת ADC לסביבת פיתוח מקומית במאמרי העזרה בנושא אימות Google Cloud .

   Node.js

   כדי להשתמש בדוגמאות של Node.js שבדף הזה בסביבת פיתוח מקומית, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

   1. התקינו את ה-CLI של Google Cloud.

   2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

      gcloud auth application-default login

      אם אתם משתמשים ב-Cloud Shell, אתם לא צריכים לעשות את זה.

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

   למידע נוסף, ראו הגדרת ADC לסביבת פיתוח מקומית במאמרי העזרה בנושא אימות Google Cloud .

   PHP

   כדי להשתמש בדוגמאות של PHP שבדף הזה בסביבת פיתוח מקומית, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

   1. התקינו את ה-CLI של Google Cloud.

   2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

      gcloud auth application-default login

      אם אתם משתמשים ב-Cloud Shell, אתם לא צריכים לעשות את זה.

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

   למידע נוסף, ראו הגדרת ADC לסביבת פיתוח מקומית במאמרי העזרה בנושא אימות Google Cloud .

   Python

   כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של Python שבדף הזה, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

   1. התקינו את ה-CLI של Google Cloud.

   2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

      gcloud auth application-default login

      אם אתם משתמשים ב-Cloud Shell, אתם לא צריכים לעשות את זה.

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

   למידע נוסף, ראו הגדרת ADC לסביבת פיתוח מקומית במאמרי העזרה בנושא אימות Google Cloud .

   Ruby

   כדי להשתמש בדוגמאות של Ruby שבדף הזה בסביבת פיתוח מקומית, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

   1. התקינו את ה-CLI של Google Cloud.

   2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

      gcloud auth application-default login

      אם אתם משתמשים ב-Cloud Shell, אתם לא צריכים לעשות את זה.

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

   למידע נוסף, ראו הגדרת ADC לסביבת פיתוח מקומית במאמרי העזרה בנושא אימות Google Cloud .

   REST

   כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

   התקינו את ה-CLI של Google Cloud.

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

   מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

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

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

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

הערה: כל בדיקות זמני הפעילות משתמשות בבקשות HTTP GET או POST או בבקשות TCP.

המסוף

כדי ליצור בדיקת זמני פעילות באמצעות מסוף Google Cloud :

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

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

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

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

3. לוחצים על Create Uptime Check (יצירת בדיקת זמינות).

   

4. מציינים את היעד של בדיקת זמני הפעילות:

   1. בוחרים את הפרוטוקול. אפשר לבחור באפשרות HTTP,‏ HTTPS או TCP.

   2. בוחרים אחד מסוגי המשאבים הבאים:

      • כתובת URL: כל כתובת IPv4 או שם מארח. הנתיב והיציאה מוזנים בנפרד.
      • Kubernetes LoadBalancer Service: Kubernetes Service of LoadBalancer type.
      • שירות Cloud Run: אם בוחרים שירות Cloud Run כיעד של בדיקת זמינות, צריך לוודא שיש לכם הרשאת run.routes.invoke בשירות הזה.
      • ‫App Engine: אפליקציות (מודולים) של App Engine.
      • מכונה: מכונות Compute Engine או AWS EC2.
      • ‫Elastic Load Balancer: מאזן עומסים של AWS.
      הערה: אל תבחרו באפשרות כתובת IP פנימית, כי סוג המשאב הזה לא יכול להיות יעד של בדיקת זמינות ציבורית.

   3. מזינים את השדות הספציפיים לפרוטוקול:

      • לגבי בדיקות TCP, מזינים את היציאה.

      • בבדיקות של HTTP ו-HTTPS, אפשר להזין נתיב במארח או במשאב. כל בדיקות זמני הפעילות שמשתמשות בפרוטוקולים האלה שולחות בקשה אל http://target/path. בביטוי הזה, כשמדובר במשאב של כתובת URL, ‏target הוא שם מארח או כתובת IP. במשאב App Engine, ‏ target הוא שם מארח שנגזר משם השירות. לדוגמה, במשאבי מכונות וירטואליות ומאזני עומסים, target היא כתובת IP שנגזרת מהשם שציינתם למשאב או לקבוצת המשאבים.

        אם משאירים את השדה path ריק או אם מגדירים את הערך ל-/, הבקשה מונפקת ל-http://target/.

        לדוגמה, כדי להנפיק בדיקת זמני פעילות למשאב כתובת ה-URL example.com/tester, מגדירים את השדה שם המארח לערך example.com ואת השדה נתיב לערך /tester.

        נניח שפרסתם שרת ב-App Engine עם רכיב Dispatcher שתומך ב-/ וב-/hello. כדי להנפיק את בדיקת זמן הפעולה ל-handler‏ /, משאירים את השדה Path ריק. כדי להנפיק את בדיקת זמן הפעולה ל-handler‏ /hello, מגדירים את הערך של השדה Path ל-/hello.

   4. מזינים את השדות הספציפיים למשאב:

      • למשאבי כתובת URL, מזינים את שם המארח בשדה שם המארח. לדוגמה, מזינים example.com.

        הערה: מומלץ ליצור בדיקות מול כתובות URL ישירות כשאפשר.

      • בשביל משאבי App Engine, מזינים את שם השירות בשדה Service.

      • למשאבי Elastic Load Balancer ו-Instance, ממלאים את השדה Applies to באופן הבא:

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

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

   6. אופציונלי: כדי לבחור אזורים לבדיקה, או כדי להגדיר אישורי SSL, אימות, כותרות ויציאות לבדיקות HTTP ו-HTTPS, לוחצים על More target options (אפשרויות נוספות של יעד):

      • אזורים: בוחרים את האזורים שבהם בדיקות זמני פעילות יקבלו בקשות. בבדיקת זמינות צריכים להיות לפחות שלושה בודקים. יש בודק אחד בכל האזורים חוץ מארצות הברית, שבה יש שלושה בודקים. הגדרת ברירת המחדל, Global, כוללת את כל האזורים.
      • ICMP Pings: הגדרת בדיקת הזמינות לשליחה של עד שלוש בדיקות פינג. מידע נוסף זמין במאמר שימוש בפינגים של ICMP.
      • שיטת בקשה: בבדיקות HTTP, בוחרים את שיטת הבקשה.
      • גוף: לבדיקות HTTP POST, מזינים את הגוף שמקודד בכתובת ה-URL. את הקידוד צריך לבצע באופן עצמאי. בכל הבדיקות האחרות, משאירים את השדה הזה ריק.
      • כותרת מארח: ממלאים את השדה הזה כדי לבדוק מארחים וירטואליים. השדה הזה לא זמין לבדיקות TCP.
      • יציאה: מציינים מספר יציאה.
      • כותרות בהתאמה אישית: אפשר לספק כותרות בהתאמה אישית ולהצפין אותן אם רוצים. ההצפנה מסתירה את הערכים של הכותרת בטופס. השתמשו בהצפנה לכותרות שקשורות לאימות שאתם לא רוצים שאחרים יראו.

      • אימות: הערכים האלה נשלחים ככותרת Authorization. השדה הזה לא זמין לבדיקות TCP.

        הערה: אל תגדירו את השדות Authentication כשאתם שולחים כותרת Authorization. אם מגדירים את השדות Authentication ושולחים כותרת Authorization, מתרחשת שגיאה Invalid Argument.

        בוחרים אחת מהאפשרויות הבאות:

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

      • אימות אישור SSL: אם בחרתם ב-HTTPS עבור משאב של כתובת URL, כברירת מחדל השירות ינסה להתחבר דרך HTTPS ולאמת את אישור ה-SSL. בדיקות הזמינות נכשלות אם לכתובת URL יש אישור לא תקף. הסיבות לאישור לא תקין כוללות:

        • אישור שתוקפו פג
        • אישור עם חתימה עצמית
        • אישור עם אי התאמה של שם הדומיין
        • אישור שמשתמש בתוסף Authority Information Access ‏ (AIA).
        הערה: אישור SSL שבוטל לא נחשב לאישור לא חוקי.

        כדי לאלץ בדיקת זמינות של HTTPS כדי לאמת את אישור ה-SSL, בוחרים באפשרות אימות אישורי SSL.

        כדי להשבית את האימות של אישורי SSL, מבטלים את הסימון של אימות אישורי SSL.

        אם יש לכם אישורי SSL עם תוספי AIA, אתם צריכים להשבית את האימות של אישור ה-SSL. סוגי האישורים האלה לא נתמכים, והם לא עוברים את רצף האימות. בדרך כלל, הודעת השגיאה היא 'Responded with SSL handshake Error in 10000 ms'.

        אפשר להשתמש במדד monitoring.googleapis.com/uptime_check/time_until_ssl_cert_expires כדי ליצור מדיניות התראות שתשלח לכם התראה לפני שתוקף האישור יפוג. מידע נוסף זמין במאמר בנושא מדיניות לדוגמה: מדיניות לבדיקת זמינות.

5. לוחצים על המשך ומגדירים את הדרישות לתגובה. לכל ההגדרות בקטע הזה יש ערכי ברירת מחדל:

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

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

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

     • בתפריט האפשרויות, בוחרים באפשרות סוג התאמה של תוכן התגובה. השדה הזה קובע איך תוכן התשובה מושווה לנתונים שמוחזרים. לדוגמה, נניח שתוכן התשובה הוא abcd וסוג התאמת התוכן הוא Contains. בדיקת הזמינות מצליחה רק אם נתוני התגובה מכילים את הערך abcd. מידע נוסף זמין במאמר בנושא אימות נתוני התגובה.
     • מזינים את תוכן התגובה. תוכן התשובה צריך להיות מחרוזת באורך של עד 1,024 בייט. ב-API, השדה הזה הוא האובייקט ContentMatcher.
     הערה: כשבוחרים בפרוטוקול TCP, צריך להפעיל את האפשרות 'התאמה של תוכן התגובה'.

   • כדי למנוע יצירה של רשומות ביומן בגלל בדיקות זמני פעילות, צריך לבטל את הסימון של Log check failures (רישום כשלים בבדיקה).

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

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

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

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

   3. בתיבה Notification channels (ערוצי התראות), לוחצים על Menu (תפריט), בוחרים את הערוצים שרוצים להוסיף ולוחצים על OK (אישור).

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

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

7. לוחצים על המשך ומשלימים את בדיקת הזמינות:

   1. מזינים שם תיאורי לבדיקת הזמינות.

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

      1. לוחצים על הצגת תוויות משתמש.
      2. בשדה Key (מפתח), מזינים שם לתווית. שמות התוויות צריכים להתחיל באות קטנה, והם יכולים לכלול אותיות קטנות, ספרות, קווים תחתונים ומקפים. לדוגמה, מקלידים severity.
      3. בשדה ערך, מזינים ערך לתווית. הערכים של התוויות יכולים להכיל אותיות קטנות, ספרות, קווים תחתונים ומקפים. לדוגמה, מקלידים critical.
      4. לכל תווית נוספת, לוחצים על הוספת תווית משתמש ואז מזינים את המפתח והערך של התווית.

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

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

gcloud

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

gcloud monitoring uptime create DISPLAY_NAME REQUIRED_FLAGS OPTIONAL_FLAGS --project=PROJECT_ID

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

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

• ‫DISPLAY_NAME: השם של בדיקת הזמינות.

• ‫REQUIRED_FLAGS: הגדרה של המשאב שנבדק על ידי בדיקת הזמינות. לדוגמה, הפקודה הבאה יוצרת בדיקת זמינות שבודקת את כתובת ה-URL EXAMPLE.com בפרויקט מסוים:

  gcloud monitoring uptime create DISPLAY_NAME \
  --resource-labels=host=EXAMPLE.com,project_id=PROJECT_ID \
  --resource-type=uptime-url
  

  בפקודה הקודמת מוגדרים ערכים לכל תווית שנדרשת על ידי סוג המשאב uptime-url.

  הערה: בפקודה הקודמת, מגדירים את השדה resource-type לערך uptime-url. אל תשתמשו ב-uptime_url. הפקודות של Google Cloud CLI לא פועלות לפי אותן מוסכמות שמות כמו Cloud Monitoring. רשימה של הערכים התקינים בשדה resource-type זמינה במסמכי התיעוד בנושא gcloud monitoring uptime create.

• ‫OPTIONAL_FLAGS: הגדרת הדגלים האלה כדי לשנות את ערכי ברירת המחדל. לדוגמה, צריך להגדיר את הדגל --protocol אם הפרוטוקול הוא לא http.

Terraform

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

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

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

2. עורכים את קובץ התצורה של Terraform ומוסיפים משאב google_monitoring_uptime_check_config, ואז מחילים את קובץ התצורה.

   בדוגמה הבאה מוצגת הגדרה שבודקת כתובת URL ציבורית:

   resource "google_monitoring_uptime_check_config" "example" {
       display_name = "example"
       timeout      = "60s"
   
       http_check {
           port = "80"
           request_method = "GET"
       }
   
       monitored_resource {
           type = "uptime_url"
           labels = {
               project_id = "PROJECT_ID"
               host="EXAMPLE.com"
           }
       }
   
       checker_type = "STATIC_IP_CHECKERS"
   }
   

   בביטוי הקודם:

   • ‫PROJECT_ID הוא מזהה הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את הפרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
   • ‫EXAMPLE.com היא כתובת ה-URL של המארח.

3. אופציונלי: יוצרים ערוץ התראות ומדיניות התראות:

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

   1. כדי ליצור ערוץ התראות:

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

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

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

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

   2. כדי ליצור מדיניות התראות:

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

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

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

      2. בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את הפרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
      3. מאתרים את בדיקת הזמינות, לוחצים על עוד ואז על הוספת מדיניות התראות.
      4. בתיבת הדו-שיח, עוברים לקטע Notifications and name, מרחיבים את Notification Channels ובוחרים את האפשרויות הרצויות.
      5. נותנים שם למדיניות ההתראות ולוחצים על Create policy.

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

C#

כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.

public static object CreateUptimeCheck(string projectId, string hostName,
    string displayName)
{
    // Define a new config.
    var config = new UptimeCheckConfig()
    {
        DisplayName = displayName,
        MonitoredResource = new MonitoredResource()
        {
            Type = "uptime_url",
            Labels = { { "host", hostName } }
        },
        HttpCheck = new UptimeCheckConfig.Types.HttpCheck()
        {
            Path = "/",
            Port = 80,
        },
        Timeout = TimeSpan.FromSeconds(10).ToDuration(),
        Period = TimeSpan.FromMinutes(5).ToDuration()
    };
    // Create a client.
    var client = UptimeCheckServiceClient.Create();
    ProjectName projectName = new ProjectName(projectId);
    // Create the config.
    var newConfig = client.CreateUptimeCheckConfig(
        projectName,
        config,
        CallSettings.FromExpiration(
            Expiration.FromTimeout(
                TimeSpan.FromMinutes(2))));
    Console.WriteLine(newConfig.Name);
    return 0;
}

Java

כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.

private static void createUptimeCheck(
    String projectId, String displayName, String hostName, String pathName) throws IOException {
  CreateUptimeCheckConfigRequest request =
      CreateUptimeCheckConfigRequest.newBuilder()
          .setParent(ProjectName.format(projectId))
          .setUptimeCheckConfig(
              UptimeCheckConfig.newBuilder()
                  .setDisplayName(displayName)
                  .setMonitoredResource(
                      MonitoredResource.newBuilder()
                          .setType("uptime_url")
                          .putLabels("host", hostName))
                  .setHttpCheck(HttpCheck.newBuilder().setPath(pathName).setPort(80))
                  .setTimeout(Duration.newBuilder().setSeconds(10))
                  .setPeriod(Duration.newBuilder().setSeconds(300)))
          .build();
  try (UptimeCheckServiceClient client = UptimeCheckServiceClient.create()) {
    UptimeCheckConfig config = client.createUptimeCheckConfig(request);
    System.out.println("Uptime check created: " + config.getName());
  } catch (Exception e) {
    usage("Exception creating uptime check: " + e.toString());
    throw e;
  }
}

Go

כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.

// createGet creates an example uptime check on a GET request.
func createGet(w io.Writer, projectID string) (*monitoringpb.UptimeCheckConfig, error) {
	ctx := context.Background()
	client, err := monitoring.NewUptimeCheckClient(ctx)
	if err != nil {
		return nil, fmt.Errorf("NewUptimeCheckClient: %w", err)
	}
	defer client.Close()
	req := &monitoringpb.CreateUptimeCheckConfigRequest{
		Parent: "projects/" + projectID,
		UptimeCheckConfig: &monitoringpb.UptimeCheckConfig{
			DisplayName: "new GET uptime check",
			Resource: &monitoringpb.UptimeCheckConfig_MonitoredResource{
				MonitoredResource: &monitoredres.MonitoredResource{
					Type: "uptime_url",
					Labels: map[string]string{
						"host": "example.com",
					},
				},
			},
			CheckRequestType: &monitoringpb.UptimeCheckConfig_HttpCheck_{
				HttpCheck: &monitoringpb.UptimeCheckConfig_HttpCheck{
					RequestMethod: monitoringpb.UptimeCheckConfig_HttpCheck_GET,
					Path:          "/",
					Port:          80,
				},
			},
			Timeout: &duration.Duration{Seconds: 10},
			Period:  &duration.Duration{Seconds: 300},
		},
	}
	config, err := client.CreateUptimeCheckConfig(ctx, req)
	if err != nil {
		return nil, fmt.Errorf("CreateUptimeCheckConfig GET: %w", err)
	}
	fmt.Fprintf(w, "Successfully created GET uptime check %q\n", config.GetDisplayName())
	return config, nil
}

// createPost creates an example uptime check on a POST request.
func createPost(w io.Writer, projectID string) (*monitoringpb.UptimeCheckConfig, error) {
	ctx := context.Background()
	client, err := monitoring.NewUptimeCheckClient(ctx)
	if err != nil {
		return nil, fmt.Errorf("NewUptimeCheckClient: %w", err)
	}
	defer client.Close()
	req := &monitoringpb.CreateUptimeCheckConfigRequest{
		Parent: "projects/" + projectID,
		UptimeCheckConfig: &monitoringpb.UptimeCheckConfig{
			DisplayName: "new POST uptime check",
			Resource: &monitoringpb.UptimeCheckConfig_MonitoredResource{
				MonitoredResource: &monitoredres.MonitoredResource{
					Type: "uptime_url",
					Labels: map[string]string{
						"host": "example.com",
					},
				},
			},
			CheckRequestType: &monitoringpb.UptimeCheckConfig_HttpCheck_{
				HttpCheck: &monitoringpb.UptimeCheckConfig_HttpCheck{
					RequestMethod: monitoringpb.UptimeCheckConfig_HttpCheck_POST,
					ContentType:   monitoringpb.UptimeCheckConfig_HttpCheck_URL_ENCODED,
					Path:          "/",
					Port:          80,
					Body:          []byte(base64.URLEncoding.EncodeToString([]byte("key: value"))),
				},
			},
			Timeout: &duration.Duration{Seconds: 10},
			Period:  &duration.Duration{Seconds: 300},
		},
	}
	config, err := client.CreateUptimeCheckConfig(ctx, req)
	if err != nil {
		return nil, fmt.Errorf("CreateUptimeCheckConfig POST: %w", err)
	}
	fmt.Fprintf(w, "Successfully created POST uptime check %q\n", config.GetDisplayName())
	return config, nil
}

Node.js

כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.

// Imports the Google Cloud client library
const monitoring = require('@google-cloud/monitoring');

// Creates a client
const client = new monitoring.UptimeCheckServiceClient();

/**
 * TODO(developer): Uncomment and edit the following lines of code.
 */
// const projectId = 'YOUR_PROJECT_ID';
// const hostname = 'mydomain.com';

const request = {
  // i.e. parent: 'projects/my-project-id'
  parent: client.projectPath(projectId),
  uptimeCheckConfig: {
    displayName: 'My Uptime Check',
    monitoredResource: {
      // See the Uptime Check docs for supported MonitoredResource types
      type: 'uptime_url',
      labels: {
        host: hostname,
      },
    },
    httpCheck: {
      path: '/',
      port: 80,
    },
    timeout: {
      seconds: 10,
    },
    period: {
      seconds: 300,
    },
  },
};

// Creates an uptime check config for a GCE instance
const [uptimeCheckConfig] = await client.createUptimeCheckConfig(request);
console.log('Uptime check created:');
console.log(`ID: ${uptimeCheckConfig.name}`);
console.log(`Display Name: ${uptimeCheckConfig.displayName}`);
console.log('Resource: %j', uptimeCheckConfig.monitoredResource);
console.log('Period: %j', uptimeCheckConfig.period);
console.log('Timeout: %j', uptimeCheckConfig.timeout);
console.log(`Check type: ${uptimeCheckConfig.check_request_type}`);
console.log(
  'Check: %j',
  uptimeCheckConfig.httpCheck || uptimeCheckConfig.tcpCheck
);
console.log(
  `Content matchers: ${uptimeCheckConfig.contentMatchers
    .map(matcher => matcher.content)
    .join(', ')}`
);
console.log(`Regions: ${uptimeCheckConfig.selectedRegions.join(', ')}`);

PHP

כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.

use Google\Api\MonitoredResource;
use Google\Cloud\Monitoring\V3\Client\UptimeCheckServiceClient;
use Google\Cloud\Monitoring\V3\CreateUptimeCheckConfigRequest;
use Google\Cloud\Monitoring\V3\UptimeCheckConfig;

/**
 * Example:
 * ```
 * create_uptime_check($projectId, 'myproject.appspot.com', 'Test Uptime Check!');
 * ```
 *
 * @param string $projectId Your project ID
 * @param string $hostName
 * @param string $displayName
 */
function create_uptime_check($projectId, $hostName = 'example.com', $displayName = 'New uptime check')
{
    $projectName = 'projects/' . $projectId;
    $uptimeCheckClient = new UptimeCheckServiceClient([
        'projectId' => $projectId,
    ]);

    $monitoredResource = new MonitoredResource();
    $monitoredResource->setType('uptime_url');
    $monitoredResource->setLabels(['host' => $hostName]);

    $uptimeCheckConfig = new UptimeCheckConfig();
    $uptimeCheckConfig->setDisplayName($displayName);
    $uptimeCheckConfig->setMonitoredResource($monitoredResource);
    $createUptimeCheckConfigRequest = (new CreateUptimeCheckConfigRequest())
        ->setParent($projectName)
        ->setUptimeCheckConfig($uptimeCheckConfig);

    $uptimeCheckConfig = $uptimeCheckClient->createUptimeCheckConfig($createUptimeCheckConfigRequest);

    printf('Created an uptime check: %s' . PHP_EOL, $uptimeCheckConfig->getName());
}

Python

כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.

def create_uptime_check_config_get(
    project_id: str, host_name: str = None, display_name: str = None
) -> uptime.UptimeCheckConfig:
    """Creates a new uptime check configuration

    Args:
        project_id: Google Cloud project id where the uptime check is created
        host_name: An example label's value for the "host" label
        display_name: A human friendly name of the configuration

    Returns:
        A structure that describes a new created uptime check
    """
    config = monitoring_v3.UptimeCheckConfig()
    config.display_name = display_name or "New GET uptime check"
    config.monitored_resource = {
        "type": "uptime_url",
        "labels": {"host": host_name or "example.com"},
    }
    config.http_check = {
        "request_method": monitoring_v3.UptimeCheckConfig.HttpCheck.RequestMethod.GET,
        "path": "/",
        "port": 80,
    }
    config.timeout = {"seconds": 10}
    config.period = {"seconds": 300}

    client = monitoring_v3.UptimeCheckServiceClient()
    new_config = client.create_uptime_check_config(
        request={"parent": project_id, "uptime_check_config": config}
    )
    pprint.pprint(new_config)
    return new_config


def create_uptime_check_config_post(
    project_id: str, host_name: str = None, display_name: str = None
) -> uptime.UptimeCheckConfig:
    """Creates a new uptime check configuration

    Args:
        project_id: Google Cloud project id where the uptime check is created
        host_name: An example label's value for the "host" label
        display_name: A human friendly name of the configuration

    Returns:
        A structure that describes a new created uptime check
    """
    config = monitoring_v3.UptimeCheckConfig()
    config.display_name = display_name or "New POST uptime check"
    config.monitored_resource = {
        "type": "uptime_url",
        "labels": {"host": host_name or "example.com"},
    }
    config.http_check = {
        "request_method": monitoring_v3.UptimeCheckConfig.HttpCheck.RequestMethod.POST,
        "content_type": monitoring_v3.UptimeCheckConfig.HttpCheck.ContentType.URL_ENCODED,
        "body": "foo=bar".encode("utf-8"),
        "path": "/",
        "port": 80,
    }
    config.timeout = {"seconds": 10}
    config.period = {"seconds": 300}

    client = monitoring_v3.UptimeCheckServiceClient()
    new_config = client.create_uptime_check_config(
        request={"parent": project_id, "uptime_check_config": config}
    )
    pprint.pprint(new_config)
    return new_config

Ruby

כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.

gem "google-cloud-monitoring"
require "google/cloud/monitoring"

def create_uptime_check_config project_id: nil, host_name: nil, display_name: nil
  client = Google::Cloud::Monitoring.uptime_check_service
  project_name = client.project_path project: project_id
  config = {
    display_name:       display_name.nil? ? "New uptime check" : display_name,
    monitored_resource: {
      type:   "uptime_url",
      labels: { "host" => host_name.nil? ? "example.com" : host_name }
    },
    http_check:         { path: "/", port: 80 },
    timeout:            { seconds: 10 },
    period:             { seconds: 300 }
  }
  new_config = client.create_uptime_check_config \
    parent:              project_name,
    uptime_check_config: config
  puts new_config.name
  new_config
end

REST

כדי ליצור בדיקת זמני פעילות, צריך לבצע קריאה ל-method‏ projects.uptimeCheckConfigs.create. מגדירים את הפרמטרים של השיטה באופן הבא:

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

  projects/PROJECT_ID
  

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

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

  • אם אתם מגדירים בדיקת HTTP או HTTPS, אתם צריכים למלא את השדה HttpCheck של האובייקט UptimeCheckConfig. באובייקט הזה, מגדירים את השדה requestMethod כ-GET או כ-POST. אם השדה הזה מושמט או מוגדר לערך METHOD_UNSPECIFIED, מתבצעת בקשת GET.

    אם אתם מגדירים POST בקשה, אתם צריכים למלא את השדות contentType, customContentType (אופציונלי) וbody.

השיטה create מחזירה את האובייקט UptimeCheckConfig של ההגדרה החדשה.

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

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

שימוש בפינגים של ICMP

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

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

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

• ‫rtt_usec: זמן הלוך ושוב של כל בקשת פינג לא מוצלחת.
• ‫unreachable_count: מספר בקשות הפינג שהחזירו את קוד הסטטוס ICMP_DEST_UNREACH.
• ‫no_answer_count: מספר בקשות הפינג שחלף הזמן הקצוב לתגובה שלהן ולא הוחזרה תגובה.

התוצאות של פקודות ה-ping לבדיקות זמינות מוצלחות לא נרשמות ביומן.

הגדרת פינגים

כל הגדרה של בדיקת זמינות כוללת אובייקט HttpCheck או אובייקט TcpCheck. שני האובייקטים האלה כוללים את השדה pingConfig. בשדה הזה מציינים את מספר הפינגים של ICMP שרוצים לכלול בכל בדיקה, עד 3. כברירת מחדל, לא נשלחים פינגים.

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

• כשמשתמשים במסוף Google Cloud , מרחיבים את More target options ומזינים ערך בשדה ICMP Pings.

• כשמשתמשים ב-Cloud Monitoring API, צריך להשתמש באובייקט PingConfig, שיש לו את המבנה הבא:

  {
    "pingsCount": integer
  }
  

  מידע נוסף על שימוש ב-Monitoring API להגדרות של בדיקת זמינות מופיע במאמרים יצירת בדיקת זמינות: API או עריכת בדיקת זמינות: API.

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

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

בדיקות שהושלמו בהצלחה

בדיקת זמינות נחשבת למוצלחת אם התנאים הבאים מתקיימים:

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

בדיקות שנכשלו

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

• שגיאת חיבור – נדחה: אם אתם משתמשים בסוג החיבור HTTP שמוגדר כברירת מחדל, צריך לוודא שהתקנתם שרת אינטרנט שמגיב לבקשות HTTP. שגיאת חיבור יכולה לקרות במופע חדש אם לא התקנתם שרת אינטרנט. אפשר לעיין במדריך למתחילים של Compute Engine. אם אתם משתמשים בסוג החיבור HTTPS, יכול להיות שתצטרכו לבצע שלבי הגדרה נוספים. לפתרון בעיות בחומת האש, אפשר לעיין במאמר בנושא רשימת כתובות ה-IP של שרתי בדיקת הזמינות.
• לא נמצא שם או שירות: יכול להיות ששם המארח שגוי.

• 403 Forbidden: השירות מחזיר קוד שגיאה לכלי לבדיקת זמינות. לדוגמה, הגדרת ברירת המחדל של שרת האינטרנט Apache מחזירה את הקוד הזה ב-Amazon Linux, אבל מחזירה את הקוד 200 (הצלחה) בחלק מגרסאות Linux אחרות. אפשר לעיין במדריך LAMP ל-Amazon Linux או במסמכי התיעוד של שרת האינטרנט.

  אם מוצגת הודעת השגיאה הזו והיעד של בדיקת הזמינות הוא שירות Cloud Run, צריך לוודא שיש לכם את ההרשאה run.routes.invoke בשירות הזה.

• 404 לא נמצא: יכול להיות שהנתיב שגוי.

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

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

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

מגבלות

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

המאמרים הבאים

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