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

במאמר הזה מוסבר איך מגדירים בדיקה פרטית של זמן פעולה תקינה. בדיקות זמינות פרטיות מאפשרות לשלוח בקשות 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 הבאים:
- Cloud Monitoring API: monitoring.googleapis.com
- ‫Service Directory API: ‏ servicedirectory.googleapis.com
- ‫Service Networking API: ‏ servicenetworking.googleapis.com
- ‫Compute Engine API: ‏ compute.googleapis.com
אפשר להפעיל את ממשקי ה-API באמצעות ה-CLI של gcloud אוGoogle Cloud Console. בכרטיסיות הבאות מוסבר איך להתקין את ה-CLI של gcloud ולהפעיל את Cloud Monitoring API:
מסוף Google Cloud
1. במסוף Google Cloud , בוחרים את הפרויקט Google Cloud שעבורו רוצים להפעיל את ה-API, ואז עוברים לדף APIs & Services:
  
  עוברים אל APIs & Services
2. לוחצים על הכפתור הפעלת ממשקי API ושירותים.
3. מחפשים את 'מעקב'.
4. בתוצאות החיפוש, לוחצים על Stackdriver Monitoring API.
5. אם מופיע הכיתוב 'API enabled', סימן שה-API כבר מופעל. אם לא, לוחצים על הפעלה.
‫CLI של gcloud
1. אם עדיין לא התקנתם את ה-CLI של gcloud בתחנת העבודה, תוכלו לעיין במאמר בנושא התקנת Google Cloud CLI.
2. כדי לבדוק אם Monitoring API מופעל, מריצים את הפקודה הבאה בתחנת העבודה, אחרי שמחליפים את PROJECT_ID במזהה הפרויקט שעבורו רוצים להפעיל את ה-API:
  gcloud services list --project=PROJECT_ID
  אם monitoring.googleapis.com מופיע בפלט, ה-API מופעל.
3. אם ה-API לא מופעל, מריצים את הפקודה הבאה כדי להפעיל אותו:
  gcloud services enable monitoring --project=PROJECT_ID
  מידע נוסף זמין במאמר gcloud services.
אפשר להשתמש באותם שלבים כדי להפעיל את ממשקי ה-API האחרים:
- כדי להשתמש במסוף Google Cloud , מחפשים את השם לתצוגה, לדוגמה, Service Directory API.
- כדי להשתמש ב-CLI של gcloud, מציינים את הרכיב הראשון של השם googleapis.com, לדוגמה, servicedirectory.
מגדירים את ערוצי ההתראות שרוצים להשתמש בהם כדי לקבל התראות. מומלץ ליצור כמה סוגים של ערוצי התראות. מידע נוסף זמין במאמר בנושא יצירה וניהול של ערוצי התראות.
הגדרת רשת פרטית והגדרת מכונה וירטואלית או איזון עומסים פנימי כך שתהיה להם גישה לרשת הפרטית הזו. מידע נוסף זמין במאמר גישה לשירותים פרטיים.

בדיקות פרטיות שמטרגטות ILB מוגבלות לאזורים עם בודקי זמן פעולה תקינה. אזור הבדיקה של זמן הפעולה 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 , בוחרים בכרטיסייה Google Cloud מסוף.
כדי להשתמש ב-Cloud Monitoring API ולהגדיר את שירות Service Directory כך שיהיה באותו פרויקט של בדיקת הזמינות, בוחרים בכרטיסייה API: פרויקט להגדרת היקף. Google Cloud
כדי להשתמש ב-Cloud Monitoring API ולהגדיר את שירות Service Directory כך שיהיה בפרויקט שנמצא במעקב של היקף המדדים של הפרויקט של בדיקת הזמינות, בוחרים בכרטיסייה API: פרויקט במעקב.

מסוף Google Cloud

כדי ליצור בדיקת זמינות באמצעות מסוף 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 ואז בוחרים את האזור של המכונה הווירטואלית שמשרתת את הבקשות.
  2. מרחיבים את Namespace ואז בוחרים מרחב שמות קיים של Service Directory או לוחצים על Create namespace ויוצרים מרחב שמות.
  3. לוחצים על שם השירות ומזינים שם לשירות. השירותים הם היעדים של בדיקות הפרטיות בזמן פעולה תקינה.
  4. לוחצים על Endpoint name ומזינים שם לנקודת הקצה. נקודת קצה היא צמד של כתובת IP וערכי יציאה ששירות יכול להשתמש בהם כדי לטפל בבקשות. אם השירות מכיל כמה נקודות קצה, אחת מהן נבחרת באופן אקראי.
  5. מרחיבים את Network ובוחרים את הרשת הפרטית.
  6. מרחיבים את Instance ואז בוחרים את מכונת ה-VM ברשת הפרטית שמשרתת בקשות. אחרי שבוחרים את המופע, מוצגת כתובת ה-IP הפנימית שלו.
  7. לוחצים על סיום.
4. מרחיבים את Firewall rules:
  1. מרחיבים את Network (רשת) ובוחרים את הרשת שאליה מצורף כלל הרשת.
  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.
  
  אם משאירים את השדה Path ריק או אם מגדירים את הערך ל-/, הבקשה מונפקת ל-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. לוחצים על יצירה.

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

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

{
  "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 ולפרסם אובייקט הגדרה:

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"
}'

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

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

{
  "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 הפרויקט של בדיקת זמני הפעילות, פועלים לפי השלבים הבאים:

מגדירים את ה-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 ולפרסם אובייקט הגדרה:

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

מסוף Google Cloud

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

ה-CLI של 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

‫ה-CLI של 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

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

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

כדי להעניק תפקידים ב-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

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

כדי להעניק תפקידים ב-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

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

‫CLI של 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 כדי ליצור בדיקת זמינות פרטית, המסוף Google Cloud מנפיק את הפקודות להענקת התפקידים של Service Directory לחשבון השירות.

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

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

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

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

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

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

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

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

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

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

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

מסוף Google Cloud

‫CLI של gcloud

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

מסוף Google Cloud

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

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

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

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

מסוף Google Cloud

ה-CLI של gcloud – מכונה וירטואלית

‫ה-CLI של gcloud – איזון עומסים ברמה 4

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

מסוף Google Cloud

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

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

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

מסוף Google Cloud

‫CLI של gcloud

מגבלות

פתרון בעיות

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

מסוף Google Cloud

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

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

הגישה נדחתה

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

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

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

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

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