Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

במאמר הזה מוסבר איך מגדירים בדיקה פרטית של זמן פעולה תקינה. בדיקות זמינות פרטיות מאפשרות לשלוח בקשות HTTP או TCP לרשת ענן וירטואלי פרטי (VPC) של לקוח, תוך אכיפה של הגבלות ניהול זהויות והרשאות גישה (IAM) והיקפים של VPC Service Controls. בדיקות זמני פעילות פרטיות יכולות לשלוח בקשות ברשת הפרטית למשאבים כמו מכונה וירטואלית (VM) או מאזן עומסים פנימי (ILB) ברמה 4.

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

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

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

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

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

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

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

הפעלת ממשקי API:
המסוף

מפעילים את ממשקי ה-API של Cloud Monitoring,‏ Service Directory,‏ Service Networking ו-Compute Engine.
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים
הפעלת ממשקי ה-API
gcloud

מפעילים את ממשקי Cloud Monitoring,‏ Service Directory,‏ Service Networking ו-Compute Engine API:
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים
gcloud services enable monitoring.googleapis.com servicedirectory.googleapis.com servicenetworking.googleapis.com compute.googleapis.com
מגדירים את ערוצי ההתראות שרוצים להשתמש בהם כדי לקבל התראות. מומלץ ליצור כמה סוגים של ערוצי התראות. מידע נוסף מופיע במאמר בנושא יצירה וניהול של ערוצי התראות.
מגדירים רשת פרטית ומגדירים מכונה וירטואלית או איזון עומסים פנימי כך שתהיה להם גישה לרשת הפרטית הזו. מידע נוסף זמין במאמר גישה לשירותים פרטיים.

בדיקות פרטיות שמטרגטות מאזני עומסים פנימיים מוגבלות לאזורים עם בודקי זמינות. אזור הבדיקה של זמן הפעולה USA כולל את האזורים USA_OREGON,‏ USA_IOWA ו-USA_VIRGINIA. כל אחד מהאזורים USA_* כולל בודק אחד, והאזור USA כולל את שלושת הבודקים. בכל אחד מהאזורים האחרים לבדיקת זמינות – EUROPE, SOUTH_AMERICA ו-ASIA_PACIFIC – יש בודק אחד. כדי להסיר את המגבלה הזו, צריך להגדיר גישה גלובלית למאזן העומסים. מידע נוסף על הגדרת גישה גלובלית זמין בכרטיסייה ILB בקטע הגדרת משאבים של Service Directory במסמך הזה.

אם אתם מתכננים לבדוק ILB שלא מאפשר גישה גלובלית, תצטרכו לבחור אחד מהאזורים הבאים עבור ה-ILB:
- us-east4
- us-central1
- us-west1
- europe-west1
- southamerica-east1
- asia-southeast1
קובעים באיזה ממשק להשתמש:
- ‫Google Cloud console: מאפשר ליצור בדיקת זמני פעילות כשמכונה וירטואלית מטפלת בבקשות. הממשק הזה עוזר לכם להגדיר משאבים של Service Directory, לתת הרשאה לחשבון השירות ולהגדיר את כללי חומת האש ברשת.
- ממשקי שורת פקודה: אתם יכולים להשתמש ב-Google Cloud CLI וב-Cloud Monitoring API כדי ליצור בדיקות זמינות פרטיות כשמאזני עומסים פנימיים ומכונות וירטואליות מטפלים בבקשות.
אם אתם מתכננים להשתמש בשורת הפקודה כדי להגדיר בדיקות זמינות פרטיות, עליכם להשלים את השלבים הנדרשים.

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

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

כדי להשתמש במסוף Google Cloud , בוחרים בכרטיסייה Console.
כדי להשתמש ב-Cloud Monitoring API ולהגדיר את שירות Service Directory כך שיהיה באותו פרויקט של בדיקת הזמינות, בוחרים בכרטיסייה gcloud: Scoping project. Google Cloud
כדי להשתמש ב-Cloud Monitoring API ולהגדיר את שירות Service Directory כך שיהיה בפרויקט במעקב של היקף המדדים בפרויקט של בדיקת הזמינות, בוחרים בכרטיסייה gcloud: פרויקט במעקב.

המסוף

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

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

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.
בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את פרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
לוחצים על יצירת בדיקת זמינות.
מציינים בדיקה פרטית של זמני פעילות:
1. בוחרים את הפרוטוקול, שיכול להיות HTTP,‏ HTTPS או TCP.
2. בוחרים את סוג המשאב כתובת IP פנימית.
אם לא הגדרתם שירות Service Directory לפרויקט או אם אתם רוצים ליצור שירות Service Directory, לוחצים על View (הצגה) וממלאים את הפרטים בחלונית Private Uptime Check Prerequisites (דרישות מוקדמות לבדיקת זמינות פרטית):
1. אם מופיעה בקשה, מפעילים את Compute Engine API או את Service Directory API. יכולה לעבור עד דקה לפני שה-API יופעל.
2. מרחיבים את Service Account (אם הוא מוצג) ואז לוחצים על Create Service Account.
  
  אם חשבון השירות של Monitoring לא קיים, הוא נוצר. לאחר מכן, שירות Monitoring מעניק לחשבון השירות שני תפקידים ב-Service Directory.
3. מרחיבים את התפריט Service Directory ומבצעים את הפעולות הבאות:
  1. מרחיבים את Region ובוחרים את האזור של מכונת ה-VM שמשרתת את הבקשות.
  2. מרחיבים את Namespace ואז בוחרים מרחב שמות קיים של Service Directory או לוחצים על Create namespace ויוצרים מרחב שמות.
  3. לוחצים על שם השירות ומזינים שם שירות. השירותים הם היעדים של בדיקות הפרטיות בזמן פעולה תקינה.
  4. לוחצים על Endpoint name ומזינים שם לנקודת הקצה. נקודת קצה היא צמד של כתובת IP וערכי יציאה ששירות יכול להשתמש בהם כדי לטפל בבקשות. אם השירות מכיל כמה נקודות קצה, אחת מהן נבחרת באופן אקראי.
  5. מרחיבים את Network ואז בוחרים את הרשת הפרטית.
  6. מרחיבים את Instance ואז בוחרים את מכונת ה-VM ברשת הפרטית שמשרתת בקשות. אחרי שבוחרים את המופע, מוצגת כתובת ה-IP הפנימית שלו.
  7. לוחצים על סיום.
4. מרחיבים את Firewall rules:
  1. מרחיבים את רשת ובוחרים את הרשת שאליה מצורף כלל הרשת.
  2. לוחצים על יצירת כללים לחומת האש.
    
    כלל חומת האש מאפשר תעבורת TCP נכנסת מהמסלולים ‎35.199.192.0/19. מסלול מ-35.199.192.0/19 תומך בקישוריות ליעדי העברה שמשתמשים בניתוב פרטי. מידע נוסף זמין במאמר בנושא מסלולי VPC.
בחלונית Private Uptime Check, כדי לציין את השירות של Service Directory שבו רוצים להשתמש, מבצעים אחת מהפעולות הבאות:
- בוחרים באפשרות Use fully qualified service name (שימוש בשם שירות שמוגדר במלואו) ומזינים את השם שמוגדר במלואו של השירות:
```
projects/SERVICE_DIRECTORY_PROJECT_ID/locations/REGION/namespaces/PRIVATE_NAMESPACE/services/PRIVATE_SERVICE
```
- בוחרים את האזור, מרחב השמות והשירות באמצעות התפריטים. אם יצרתם שירות, השדות האלה כבר מסומנים בשבילכם.
בחלונית Private Uptime Check (בדיקת זמינות פרטית), משלימים את התיאור של יעד בדיקת הזמינות:
1. אופציונלי: מזינים רכיב נתיב לבקשה.
  
  בדיקות זמינות פרטיות שמשתמשות בפרוטוקול HTTP או HTTPS שולחות בקשה אל http://target/path. בביטוי הזה, target היא כתובת ה-IP הפנימית שהוגדרה בנקודת הקצה של Service Directory.
  
  אם משאירים את השדה נתיב ריק או אם מגדירים את הערך ל-/, הבקשה מונפקת אל http://target/.
2. אופציונלי: כדי להגדיר באיזו תדירות יתבצע אימות הזמינות, משתמשים בשדה תדירות הבדיקה.
3. אופציונלי: כדי לבחור אזורים לבדיקה, או כדי להגדיר אימות, כותרות לבדיקות HTTP ו-HTTPS וערכים אחרים, לוחצים על אפשרויות נוספות של יעד:
  - אזורים: בוחרים את האזורים שבהם בדיקות זמני פעילות יקבלו בקשות. בבדיקת זמינות צריכים להיות לפחות שלושה בודקים. יש בודק אחד בכל האזורים, חוץ מארצות הברית, שבה יש שלושה בודקים. הגדרת ברירת המחדל, Global, כוללת את כל האזורים.
  - שיטת בקשה: בוחרים באפשרות GET או POST.
  - גוף: בבדיקות HTTP POST, מזינים את הגוף עם קידוד כתובת URL. את הקידוד צריך לבצע בעצמכם. בכל הבדיקות האחרות, משאירים את השדה הזה ריק.
  - כותרת המארח: אל תגדירו את השדה הזה כשמגדירים בדיקות זמינות פרטיות.
  - יציאה: כל ערך שתגדירו כאן יבטל את היציאה בהגדרת נקודת הקצה (endpoint) של Service Directory. אם רוצים להשתמש בהגדרות של נקודת הקצה, לא מגדירים כאן ערך.
  - כותרות מותאמות אישית: אפשר לספק כותרות מותאמות אישית, ואם רוצים, להצפין אותן. ההצפנה מסתירה את הערכים בכותרת העליונה בטופס. כדאי להשתמש בהצפנה לכותרות שקשורות לאימות, שלא רוצים שאחרים יראו.
  - אימות: מציינים שם משתמש וסיסמה. הערכים האלה נשלחים ככותרת Authorization. אם מגדירים כאן ערכים, לא צריך להגדיר כותרת Authorization נפרדת. אם מגדירים כותרת Authorization, לא צריך להגדיר כאן ערכים. הסיסמאות תמיד מוסתרות בטופס.
לוחצים על המשך ומגדירים את דרישות התגובה. לכל ההגדרות בקטע הזה יש ערכי ברירת מחדל:
- כדי להגדיר תקופת זמן קצובה לבדיקת זמינות, משתמשים בשדה Response Timeout (זמן קצוב לתגובה). בדיקת זמינות נכשלת אם לא מתקבלת תגובה מיותר ממיקום אחד במהלך התקופה הזו.
- כדי להגדיר את בדיקת זמני הפעילות כך שתבצע התאמת תוכן, מוודאים שהתווית של המתג היא התאמת תוכן מופעלת:
  - בתפריט האפשרויות, בוחרים באפשרות סוג התאמה של תוכן התגובה. השדה הזה קובע איך תוכן התשובה מושווה לנתונים שמוחזרים. לדוגמה, נניח שתוכן התגובה הוא abcd וסוג ההתאמה של התוכן הוא Contains. בדיקת הזמינות מצליחה רק אם נתוני התגובה מכילים את הערך abcd. מידע נוסף זמין במאמר בנושא אימות נתוני התגובה.
  - מזינים את תוכן התגובה. תוכן התשובה חייב להיות מחרוזת באורך של עד 1,024 בייט. ב-API, השדה הזה הוא האובייקט ContentMatcher.
- כדי למנוע יצירה של רשומות ביומן בגלל בדיקות זמני פעילות, צריך לבטל את הסימון של האפשרות Log check failures (רישום של כשלים בבדיקה).
- בבדיקות זמני הפעילות של HTTP, צריך להגדיר את קודי התגובה המקובלים. כברירת מחדל, בדיקות זמני פעילות של HTTP מסמנות כל תגובה של 2xx כתגובה מוצלחת.
לוחצים על המשך ומגדירים את מדיניות ההתראות וההודעות.

כדי לקבל התראה כשבדיקת זמני פעילות נכשלת, צריך ליצור מדיניות התראות ולהגדיר ערוצי התראות למדיניות הזו:
1. אופציונלי: מעדכנים את השם של מדיניות ההתראות.
2. אופציונלי: בשדה משך הזמן, בוחרים כמה זמן בדיקות הזמינות צריכות להיכשל לפני שליחת ההתראות. כברירת מחדל, ההתראות נשלחות כשמתקבלים דיווחים לפחות משני אזורים על כשלים בבדיקת הזמינות למשך דקה אחת לפחות.
3. בתיבה Notification channels (ערוצי התראות), מרחיבים את Menu (תפריט), בוחרים את הערוצים שרוצים להוסיף ולוחצים על OK (אישור).
  
  בתפריט, ערוצי ההתראות מקובצים בסדר אלפביתי לפי כל סוג ערוץ.
אם אתם לא רוצים ליצור מדיניות התראות, ודאו שהטקסט של לחצן המתג הוא אל תיצור התראה.
לוחצים על המשך ומשלימים את בדיקת הזמינות:
1. מזינים שם תיאורי לבדיקת הזמינות.
2. אופציונלי: כדי להוסיף תוויות שמוגדרות על ידי המשתמש לבדיקת הזמינות, מבצעים את הפעולות הבאות:
  1. לוחצים על הצגת תוויות משתמשים.
  2. בשדה Key (מפתח), מזינים שם לתווית. שמות התוויות צריכים להתחיל באות קטנה, והם יכולים להכיל אותיות קטנות, ספרות, קווים תחתונים ומקפים. לדוגמה, מזינים severity.
  3. בשדה ערך, מזינים ערך לתווית. הערכים של התוויות יכולים להכיל אותיות קטנות, ספרות, קווים תחתונים ומקפים. לדוגמה, מזינים critical.
  4. לכל תווית נוספת, לוחצים על הוספת תווית משתמש ואז מזינים את המפתח והערך של התווית.
3. כדי לאמת את ההגדרה של בדיקת זמני הפעילות, לוחצים על Test (בדיקה). אם התוצאה לא תואמת לציפיות שלכם, כדאי לעיין בפתרון בעיות, לתקן את ההגדרות ולחזור על שלב האימות.
4. לוחצים על יצירה.

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

כדי ליצור את ההגדרה של בדיקת זמני פעילות פרטית, יוצרים אובייקט UptimeCheckConfig ומעבירים אותו אל ה-method‏ uptimeCheckConfigs.create ב-Cloud Monitoring API.

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

המשאב במעקב שצוין בהגדרות של בדיקת זמני הפעילות צריך להיות מסוג servicedirectory_service. לסוג המשאב הזה יש את התוויות הבאות:
- ‫project_id: מזהה הפרויקט שמשויך לשירות Service Directory.
- ‫location: האזור בענן שמשויך לשירות.
- ‫namespace_name: מרחב השמות של Service Directory.
- ‫service_name: השם של שירות Service Directory.
הערה: הערכים של התוויות האלה נקבעים כשמגדירים משאבים ב-Service Directory.

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

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

קוד ה-JSON הבא ממחיש אובייקט UptimeCheckConfig לבדיקת זמינות פרטית באמצעות משאבי Service Directory שהוגדרו למכונת VM ברשת פרטית:

{
  "displayName": "private-check-demo",
  "monitoredResource": {
    "type": "servicedirectory_service",
    "labels": {
      "project_id": "SERVICE_DIRECTORY_PROJECT_ID",
      "service_name": "PRIVATE_SERVICE",
      "namespace_name": "PRIVATE_NAMESPACE",
      "location": "REGION"
    }
  },
  "httpCheck": {
    "requestMethod": "GET"
  },
  "period": "60s",
  "timeout": "10s",
  "checker_type": "VPC_CHECKERS"
}'

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

מגדירים את פרויקט ברירת המחדל ל-CLI של gcloud: Google Cloud
```
gcloud config set project PROJECT_ID
```
יוצרים משתנה סביבה לאחסון מזהה הפרויקט:
```
export PROJECT_ID=$(gcloud config get-value core/project)
```
יוצרים משתנה סביבה שמכיל אסימון גישה:
```
export TOKEN=`gcloud auth print-access-token`
```

משתמשים בכלי curl כדי להפעיל את uptimeCheckConfigs.create method ולפרסם אובייקט הגדרה:

curl https://monitoring.googleapis.com/v3/projects/${PROJECT_ID}/uptimeCheckConfigs \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
--request POST --data '{
"displayName": "private-check-demo",
"monitoredResource": {
  "type": "servicedirectory_service",
  "labels": {
    "project_id": "'"$PROJECT_ID"'",
    "service_name": "PRIVATE_SERVICE",
    "namespace_name": "PRIVATE_NAMESPACE",
    "location": "REGION"
  }
},
"httpCheck": {
  "requestMethod": "GET"
},
"period": "60s",
"timeout": "10s",
"checker_type": "VPC_CHECKERS"
}'

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

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

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

המשאב במעקב שצוין בהגדרות של בדיקת זמני הפעילות צריך להיות מסוג servicedirectory_service. לסוג המשאב הזה יש את התוויות הבאות:
- ‫project_id: מזהה הפרויקט שמשויך לשירות Service Directory.
- ‫location: האזור בענן שמשויך לשירות.
- ‫namespace_name: מרחב השמות של Service Directory.
- ‫service_name: השם של שירות Service Directory.
הערה: הערכים של התוויות האלה נקבעים כשמגדירים משאבים ב-Service Directory.

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

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

קוד ה-JSON הבא ממחיש אובייקט UptimeCheckConfig לבדיקת זמינות פרטית באמצעות משאבי Service Directory שהוגדרו למכונת VM ברשת פרטית:

{
  "displayName": "private-check-demo",
  "monitoredResource": {
    "type": "servicedirectory_service",
    "labels": {
      "project_id": "SERVICE_DIRECTORY_PROJECT_ID",
      "service_name": "PRIVATE_SERVICE",
      "namespace_name": "PRIVATE_NAMESPACE",
      "location": "REGION"
    }
  },
  "httpCheck": {
    "requestMethod": "GET"
  },
  "period": "60s",
  "timeout": "10s",
  "checker_type": "VPC_CHECKERS"
}'

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

מגדירים את ה-CLI של gcloud כך שברירת המחדל תהיה Google Cloud הפרויקט שבו רוצים ליצור את בדיקת זמני הפעילות:
```
gcloud config set project PROJECT_ID
```
יוצרים משתנה סביבה לאחסון מזהה הפרויקט:
```
export PROJECT_ID=$(gcloud config get-value core/project)
```
יוצרים משתנה סביבה לאחסון מזהה הפרויקט שלGoogle Cloud הפרויקט שבו מוגדר שירות Service Directory:
```
export MONITORED_PROJECT_ID=MONITORED_PROJECT_ID
```
הפרויקט הזה צריך להיות בהיקף המדדים בפרויקט של בדיקת הזמינות.
יוצרים משתנה סביבה שמכיל אסימון גישה:
```
export TOKEN=`gcloud auth print-access-token`
```

משתמשים בכלי curl כדי להפעיל את uptimeCheckConfigs.create method ולפרסם אובייקט הגדרה:

curl https://monitoring.googleapis.com/v3/projects/${PROJECT_ID}/uptimeCheckConfigs \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
--request POST --data '{
"displayName": "private-check-demo",
"monitoredResource": {
  "type": "servicedirectory_service",
  "labels": {
    "project_id": "'"$MONITORED_PROJECT_ID"'",
    "service_name": "PRIVATE_SERVICE",
    "namespace_name": "PRIVATE_NAMESPACE",
    "location": "REGION"
  }
},
"httpCheck": {
  "requestMethod": "GET"
},
"period": "60s",
"timeout": "10s",
"checker_type": "VPC_CHECKERS"
}'

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

שלבים מקדימים

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

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

הגדרת משאבים ב-Service Directory
מתן הרשאה לחשבון השירות
הגדרת כללים לחומת אש

הגדרת משאבים ב-Service Directory

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

מכונות וירטואליות ברשת פרטית
מאזני עומסים פנימיים (ILB) ברמה 4

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

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

אפשר להגדיר את המשאבים האלה באמצעות ה-CLI של gcloud אוGoogle Cloud המסוף. כשמשתמשים במסוף, שלבי ההגדרה מופיעים בתיבת הדו-שיח Create Uptime Check.

המסוף

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

‫gcloud: מכונה וירטואלית

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

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

מגדירים את Google Cloud CLI כך שברירת המחדל תהיה הפרויקט שבו רוצים ליצור את משאבי Service Directory: Google Cloud
```
gcloud config set project PROJECT_ID
```

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

export PROJECT_ID=$(gcloud config get-value core/project)

export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')

יוצרים מרחב שמות של Service Directory:

gcloud service-directory namespaces create PRIVATE_NAMESPACE --location=REGION

יוצרים שירות Service Directory במרחב השמות:

gcloud service-directory services create PRIVATE_SERVICE \
--namespace PRIVATE_NAMESPACE --location=REGION

יוצרים משתנה סביבה שיכיל את כתובת ה-IP של המכונה הווירטואלית ברשת הפרטית:

export INTERNAL_IP=$(gcloud compute instances describe --zone=ZONE \
PRIVATE_SERVICE_INSTANCE --format='get(networkInterfaces[0].networkIP)')

יוצרים נקודת קצה של Service Directory שמכילה את כתובת ה-IP הפנימית ואת היציאה:

gcloud service-directory endpoints create PRIVATE_ENDPOINT \
--location=REGION --namespace=PRIVATE_NAMESPACE \
--service=PRIVATE_SERVICE \
--network=projects/$PROJECT_NUMBER/locations/global/networks/PRIVATE_CHECK_NETWORK \
--address=$INTERNAL_IP --port=80

‫gcloud: איזון עומסים ברמה 4

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

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

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

מגדירים את Google Cloud CLI כך שברירת המחדל תהיה הפרויקט שבו רוצים ליצור את משאבי Service Directory: Google Cloud
```
gcloud config set project PROJECT_ID
```

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

export PROJECT_ID=$(gcloud config get-value core/project)

export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')

כדי לאפשר לכל בודקי הזמינות להעביר נתונים אל איזון העומסים L4 ILB, צריך להפעיל גישה גלובלית אל איזון העומסים:
```
gcloud compute forwarding-rules update ILB_FORWARDING_RULE_NAME \
--region=ILB_REGION --allow-global-access
```
אם מאזן העומסים L4 ILB לא מאפשר גישה גלובלית, מדדי זמן הפעולה זמינים רק אם ILB_REGION הוא אחד מהבאים:
- us-east4
- us-central1
- us-west1
- europe-west1
- southamerica-east1
- asia-southeast1

יוצרים מרחב שמות של Service Directory:

gcloud service-directory namespaces create PRIVATE_NAMESPACE_FOR_ILB\
--location=REGION

יוצרים שירות Service Directory במרחב השמות:

gcloud service-directory services create PRIVATE_SERVICE_FOR_ILB \
--namespace PRIVATE_NAMESPACE_FOR_ILB --location=REGION

יוצרים משתנה סביבה שיכיל את כתובת ה-IP של מאזן העומסים ברשת הפרטית:

export INTERNAL_IP=$( gcloud compute forwarding-rules describe ILB_FORWARDING_RULE_NAME\
--region=ILB_REGION --format='get(IPAddress)')

יוצרים נקודת קצה של Service Directory שמכילה את כתובת ה-IP הפנימית ואת היציאה:

gcloud service-directory endpoints create PRIVATE_ENDPOINT_FOR_ILB \
--location=ILB_REGION --namespace=PRIVATE_NAMESPACE_FOR_ILB \
--service=PRIVATE_SERVICE_FOR_ILB \
--network=projects/$PROJECT_NUMBER/locations/global/networks/PRIVATE_CHECK_NETWORK \
--address=$INTERNAL_IP --port=80

אישור חשבון השירות

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

service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com

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

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

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

המסוף

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

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

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

מגדירים את ה-CLI של gcloud כך שברירת המחדל תהיה Google Cloud הפרויקט שבו רוצים ליצור את בדיקת זמני הפעילות:
```
gcloud config set project PROJECT_ID
```

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

export PROJECT_ID=$(gcloud config get-value core/project)

export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')

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

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
--role='roles/servicedirectory.viewer'

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
--role='roles/servicedirectory.pscAuthorizedService'

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

roles/servicedirectory.viewer
roles/servicedirectory.pscAuthorizedService

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

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

מגדירים את ה-CLI של gcloud כך שברירת המחדל תהיה Google Cloud הפרויקט שבו רוצים ליצור את בדיקת זמני הפעילות:
```
gcloud config set project PROJECT_ID
```

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

export PROJECT_ID=$(gcloud config get-value core/project)

export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='get(projectNumber)')

יוצרים משתנה סביבה שמכיל את מזהה הפרויקט שבו מוגדר שירות Service Directory:
```
export MONITORED_PROJECT_ID=MONITORED_PROJECT_ID
```
הפרויקט הזה צריך להיות בהיקף המדדים בפרויקט של בדיקת הזמינות.
יוצרים משתנה סביבה שמכיל את מזהה הפרויקט שבו מוגדרת הרשת:
```
export NETWORK_PROJECT_ID=NETWORK_PROJECT_ID
```
הפרויקט הזה לא צריך להיות בהיקף המדדים בפרויקט של בדיקת זמינות.

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

gcloud projects add-iam-policy-binding $MONITORED_PROJECT_ID \
--member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
--role='roles/servicedirectory.viewer'

gcloud projects add-iam-policy-binding $NETWORK_PROJECT_ID \
--member='serviceAccount:service-'$PROJECT_NUMBER'@gcp-sa-monitoring-notification.iam.gserviceaccount.com' \
--role='roles/servicedirectory.pscAuthorizedService'

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

‫roles/servicedirectory.viewer עבור הפרויקט במעקב שבו מוגדר שירות Service Directory,‏ $SERVICE_MONITORED_PROJECT_ID.
‫roles/servicedirectory.pscAuthorizedService לפרויקט שבו מוגדרת הרשת הפרטית, $NETWORK_PROJECT_ID.

הגדרת כללים לחומת אש

עליך ליצור כלל חומת אש שמאפשר תעבורת נתוני TCP נכנסת מהמסלולים ‎35.199.192.0/19. נתיב מ-35.199.192.0/19 תומך בקישוריות ליעדי העברה שמשתמשים בניתוב פרטי. מידע נוסף זמין במאמר בנושא מסלולי VPC.

המסוף

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

gcloud

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

מגדירים את ה-CLI של gcloud כך שברירת המחדל תהיה Google Cloud הפרויקט שבו רוצים ליצור את בדיקת זמני הפעילות:
```
gcloud config set project PROJECT_ID
```
יוצרים משתני סביבה לאחסון מזהה הפרויקט ומספר הפרויקט:
```
export PROJECT_ID=$(gcloud config get-value core/project)
```

יוצרים את כלל הרשת:

gcloud compute firewall-rules create PRIVATE_CHECK_NETWORK_HOPE_RULE \
--network="PRIVATE_CHECK_NETWORK"  \
--action=allow   --direction=ingress   --source-ranges="35.199.192.0/19" \
--rules=tcp   --project="$PROJECT_ID"

בפקודה הקודמת, PRIVATE_CHECK_NETWORK היא הרשת שהכלל הזה מצורף אליה, ואילו PRIVATE_CHECK_NETWORK_HOPE_RULE הוא השם של כלל חומת האש.

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

מגבלות

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

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

פתרון בעיות

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

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

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

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

המסוף

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

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

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

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

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

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

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

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

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

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

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

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

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

הגישה נדחתה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

gcloud

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

המסוף

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

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

שלבים מקדימים

הגדרת משאבים ב-Service Directory

המסוף

‫gcloud: מכונה וירטואלית

‫gcloud: איזון עומסים ברמה 4

אישור חשבון השירות

המסוף

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

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

הגדרת כללים לחומת אש

המסוף

gcloud

מגבלות

פתרון בעיות

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

המסוף

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

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

הגישה נדחתה

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

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

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

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

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