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

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

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

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

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

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

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

ב-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 כדי לגשת לשירותים ולממשקי ה-API, לא צריך להגדיר אימות. Google Cloud

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

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

המסוף

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

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

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

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

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

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

   

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

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

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

      • כתובת URL: כל כתובת IPv4 או שם מארח. הנתיב והיציאה מוזנים בנפרד.
      • Kubernetes LoadBalancer Service: שירות Kubernetes מסוג LoadBalancer.
      • שירות 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 ואז משתמשים בתפריט כדי לבחור את המופע או מאזן העומסים הספציפיים.
        • כדי להפעיל בדיקת זמינות לקבוצת מעקב, בוחרים באפשרות קבוצה ומשתמשים בתפריט כדי לבחור את שם הקבוצה.

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

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

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

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

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

        מסמנים את תיבת הסימון אימות אישורי SSL.

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

שימוש בפינגים של 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 (Success) בחלק מגרסאות Linux אחרות. אפשר לעיין במדריך LAMP ל-Amazon Linux או בתיעוד של שרת האינטרנט.

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

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

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

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

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

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

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