יצירת מעקב סינתטי

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

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

מידע על בדיקות סינתטיות

במסגרת בדיקה סינתטית, מופעלת באופן תקופתי פונקציית Cloud Run מדור שני למטרה יחידה, שנפרסת ב-Cloud Run. כשיוצרים את המוניטור הסינתטי, מגדירים את פונקציית Cloud Run, שצריכה להיכתב ב-Node.js, ואת תדירות ההפעלה. לדוגמה, אתם יכולים להגדיר את פונקציית Cloud Run כך שתבצע אינטראקציה עם דף אינטרנט באמצעות Puppeteer. אפשר גם להגדיר את פונקציית Cloud Run כך שתקיים אינטראקציה עם API באמצעות מודול Axios. אולי תרצו גם לבדוק משאבים שנמצאים ברשת VPC.

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

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

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

• כשיוצרים בדיקה סינתטית באמצעות Cloud Monitoring API, צריך ליצור את מדיניות ההתראות כדי לעקוב אחרי סוג המדד uptime_check/check_passed של משאב Cloud Run שהפונקציה של Cloud Run פועלת בו.

שיקולים לגבי תדירות הביצוע

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

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

קוד לדוגמה של פונקציית Cloud Run

תבניות ודוגמאות זמינות במאמר דוגמאות למוניטורים סינתטיים. אפשר להשתמש בדוגמאות האלה כנקודת התחלה לפונקציית Cloud Run. אם אתם מפתחים מנוסים, כדאי לכם להשתמש ב-Gemini כדי ליצור קוד לניטור סינתטי וכך לקצר את זמן הפיתוח. השימוש ב-Gemini ליצירת קוד הוא בגרסת טרום-השקה פתוחה.

התבנית הגנרית, שאפשר לבחור בה כשיוצרים כלי מעקב סינתטי באמצעות מסוף Google Cloud , מוגדרת לאיסוף נתוני מעקב ויומן עבור בקשות HTTP יוצאות. הפתרון מבוסס על מודול auto-instrumentation-node של OpenTelemetry ועל winston logger. בגלל התלות במוצרים עם קוד פתוח, צפויים שינויים במבנה של נתוני מעקב ויומנים. לכן, צריך להשתמש בנתוני העקבות והיומן שנאספו רק למטרות ניפוי באגים.

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

הגדרת פונקציית Cloud Run

כשמגדירים את פונקציית Cloud Run, צריך לציין את ההגדרות של זמן הריצה, ה-build, החיבורים והאבטחה, או לאשר את הגדרות ברירת המחדל:

• יכול להיות שערך ברירת המחדל של הזיכרון שהוקצה לא מספיק. מומלץ להגדיר בשדה הזה נפח של ‎2 GiB לפחות.

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

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

הגבלות על פונקציות Cloud Run

• השם של פונקציית Cloud Run לא יכול להכיל קו תחתון.

• אפשר לאסוף נתוני מעקב ויומן רישום רק לבקשות HTTP יוצאות כשמשתמשים בתבנית הגנרית.

• יש תמיכה רק בפונקציות HTTP. אם משתמשים במסוףGoogle Cloud כדי ליצור את המעקב הסינתטי, מוצגת פונקציית ברירת מחדל שמבצעת שאילתה של כתובת URL. המקור של פונקציית ברירת המחדל, שאפשר לשנות אותה, זמין במאגר generic-synthetic-nodejs Git.

  מידע על פונקציות HTTP זמין במאמר כתיבת פונקציות HTTP.

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

• סביבת זמן הריצה מוגבלת ל-Node.js. רשימת הגרסאות הנתמכות מופיעה במאמר בנושא תמיכה בזמן ריצה.

נתונים שנאספים על ידי כלי מעקב סינתטיים

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

היסטוריית הביצוע

לכל בדיקה סינתטית נאספת היסטוריה של תוצאות ההרצה. הנתונים האלה כוללים את הפרטים הבאים:

• סדרת זמן שמתעדת את ההצלחה או הכישלון של ההרצות לאורך זמן.

• סדרת זמנים שמתעדת את משך ההרצה של הקוד. זמן הביצוע של הפונקציה לא מתועד. נתוני ההשהיה נכתבים כסדרת זמן של uptime_check/request_latency עבור משאב Cloud Run שפונקציית Cloud Run פועלת בו. תרשים של הנתונים האלה מוצג בדף Synthetic monitor details.

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

• אופציונלי: עקבות ויומנים של בקשות HTTP יוצאות. מידע על אופן איסוף הנתונים האלה זמין במאמר בנושא זמן האחזור של בקשות.

מדדים ויומנים של פונקציות Cloud Run

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

זמן האחזור של הבקשה

נתוני השהיה של בקשת ה-HTTP שבוצעה על ידי המוניטור הסינתטי נאספים ונשמרים באופן אוטומטי על ידי Cloud Trace.

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

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

מבצעים את השלבים הבאים ב Google Cloud פרויקט שבו יישמר המוניטור הסינתטי:

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

   • עריכה של מעקב (roles/monitoring.editor)
   • Cloud Functions Developer (roles/cloudfunctions.developer)

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

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

2. מפעילים את Cloud Monitoring API,‏ Artifact Registry API,‏ Cloud Build API,‏ Cloud Functions API,‏ Cloud Logging API,‏ Pub/Sub API ו-Cloud Run Admin API.

   תפקידים שנדרשים להפעלת ממשקי API

   כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

   הפעלת ממשקי ה-API

3. מוודאים ש Google Cloud הפרויקט מכיל את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. חשבון השירות הזה נוצר כשמפעילים את Compute Engine API, והשם שלו דומה ל[e-mail].

   נכנסים לדף Service Accounts במסוף Google Cloud .

   לדף Service Accounts

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

   אם חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לא קיים, לוחצים על יצירת חשבון שירות וממלאים את תיבת הדו-שיח.

4. מוודאים שחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine או חשבון השירות שיצרתם קיבל את התפקיד 'עריכה' (roles/editor).

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

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

      כניסה לדף IAM

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

   2. בוחרים באפשרות Include Google-provided role grants.
   3. אם חשבון השירות שבו נעשה שימוש בבדיקה הסינתטית לא מופיע, או אם לא הוקצה לו תפקיד שכולל את ההרשאות בתפקיד Cloud Trace Agent ‏ (roles/cloudtrace.agent), צריך להקצות את התפקיד הזה לחשבון השירות.
5. מגדירים את ערוצי ההתראות שבהם רוצים להשתמש כדי לקבל התראות. מומלץ ליצור כמה סוגים של ערוצי התראות. מידע נוסף זמין במאמרים בנושא יצירה וניהול של ערוצי התראות ויצירה וניהול של ערוצי התראות באמצעות 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 .

   REST

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

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

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

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

יצירת בדיקה סינתטית

אזהרה: אל תגדירו בדיקה סינתטית כדי לבדוק את https://www.google.com. אם משתמשים בקוד לדוגמה, צריך לוודא שמשנים את השדה url לפני שמטמיעים את קוד הדוגמה.

המסוף

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

1. מוודאים שהפעלתם את ממשקי ה-API הנדרשים, שהפרויקט מכיל חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine ושהחשבון הזה קיבל את התפקיד 'עריכה' (roles/editor). מידע נוסף זמין במאמר לפני שמתחילים.

2. במסוף Google Cloud , עוברים לדף  Synthetic monitoring:

   מעבר אל Synthetic monitoring

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

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

5. בוחרים את התבנית לפונקציית Cloud Run:

   • ניטור סינתטי בהתאמה אישית: משתמשים בתבנית הזו כשרוצים לאסוף נתוני יומן או נתוני מעקב לבקשות HTTP יוצאות.

   • מעקב סינתטי של Mocha: משתמשים בתבנית הזו כשכותבים חבילות בדיקה של Mocha.

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

6. מזינים שם לניטור.

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

8. מבצעים אחת מהפעולות הבאות:

   • אם יש לכם גישה ל-Gemini Code Assist בפרויקט הזה ואתם רוצים עזרה בכתיבת הקוד, לוחצים על עזרה בכתיבת קוד. התכונה הזו זמינה בתוכנית Public Preview. הנחיות לכתיבת הנחיות מופיעות במאמר הנחיות לכתיבת הנחיות לשימוש בבדיקות סינתטיות.

     אחרי שבודקים את הקוד, לוחצים על Insert into Cloud Function (הוספה לפונקציה של Cloud Functions).

   • לוחצים על יצירת פונקציה.

9. בתיבת הדו-שיח של פונקציית Cloud Run, מבצעים את הפעולות הבאות:

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

      הערה: אל תכללו קו תחתון בשם של פונקציית Cloud Run.

   2. בקטע Runtime, build, connections and security settings (הגדרות של זמן ריצה, build, חיבורים ואבטחה):

      • בודקים את הגדרות ברירת המחדל ומעדכנים אותן לפי הצורך.
      הערה: יכול להיות שהגדרות ברירת המחדל של הזיכרון, המעבד והאבטחה שהוקצו לא יספיקו. מומלץ להגדיר את הזיכרון ל-2 GiB לפחות.
      • בשדה Runtime service account בוחרים חשבון שירות.

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

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

      • כדי לטעון קובץ ZIP מהמערכת המקומית, בוחרים באפשרות העלאת ZIP.

      אם מעלים קובץ ZIP מהמערכת המקומית, צריך לציין גם קטגוריה של Cloud Storage לקובץ ה-ZIP. אם אין לכם קטגוריה מתאימה ב-Cloud Storage, צריך ליצור אחת.

      הערה: כשיוצרים מאגר אחסון חדש, המאגר נפתח באופן מיידי, מוצגת ההודעה No objects found והאפשרויות הן בחירה או ביטול. לוחצים על ביטול כדי לחזור לתיבת הדו-שיח יצירת פונקציה. לאחר מכן, בקטע 'קטגוריית יעד', לוחצים על עיון ובוחרים את קטגוריית Cloud Storage.
      • כדי לטעון קובץ ZIP מ-Cloud Storage, בוחרים באפשרות ZIP from Cloud Storage, בוחרים את קטגוריית האחסון ואז בוחרים את קובץ ה-ZIP לטעינה.

      אפשר גם ליצור פונקציה של Cloud Run באמצעות הדפים של Cloud Run functions במסוף Google Cloud . כדי ליצור בדיקה סינתטית שעוקבת אחרי עותק של פונקציית Cloud Run, עוברים לכרטיסייה מקור ולוחצים על הורדת קובץ zip. אחר כך אפשר להעלות את קובץ ה-ZIP.

   4. לוחצים על החלת הפונקציה.

10. מגדירים את מדיניות ההתראות:

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

    2. מוסיפים את ערוצי ההתראות.

11. לוחצים על יצירה.

    פונקציית Cloud Run שהגדרתם נבנית ונפרסת כדור שני, והמוניטור הסינתטי נוצר.

gcloud

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

1. מוודאים שהפעלתם את ממשקי ה-API הנדרשים, שהפרויקט מכיל חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine ושהחשבון הזה קיבל את התפקיד 'עריכה' (roles/editor). מידע נוסף זמין במאמר לפני שמתחילים.

2. מגדירים את Google Cloud CLI כך שיגדיר פרויקט ברירת מחדל באמצעות הפקודה gcloud config set:

   gcloud config set project PROJECT_ID
   

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

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

   לדוגמה, כדי לפרוס את הדוגמה synthetics-sdk-nodejs במאגר Google Cloud/synthetics-sdk-nodejs:

   1. משכפלים את המאגר ועוברים למיקום של קוד המקור:

      git clone https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs.git
      cd synthetics-sdk-nodejs/samples/generic-synthetic-nodejs
      

   2. פורסים את הפונקציה של Cloud Run באמצעות הפקודה gcloud functions deploy:

      gcloud functions deploy FUNCTION_NAME \
      --gen2 --region="us-west2" --source="." \
      --entry-point=SyntheticFunction --trigger-http --runtime=nodejs18
      

      בפקודה gcloud functions deploy, מבצעים את הפעולות הבאות:

      • מוודאים שהערך בשדה FUNCTION_NAME הוא ייחודי באזור הפריסה.

        הערה: אל תכללו קו תחתון בשם של פונקציית Cloud Run.

      • כוללים את הדגל --gen2 ומגדירים את אזור הפריסה.

      • מגדירים את השדה --entry-point באופן הבא:

        • מוקה: SyntheticMochaSuite
        • לא מוקה: SyntheticFunction.

      • מגדירים את השדה --runtime לערך nodejs18.

      • כוללים את הדגל --trigger-http.

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

      פונקציות Cloud Run יוצרות את פונקציית Cloud Run ואז פורסות אותה. התוצאות של פקודת Google Cloud CLI כוללות מידע על הפונקציה, כולל השם המלא שלה:

      name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME
      

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

   כדי להציג את רשימת הפונקציות ב-Cloud Run בפרויקט Google Cloud , משתמשים בפקודה gcloud functions list:

   gcloud functions list
   

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

   NAME: function-1
   STATE: ACTIVE
   TRIGGER: HTTP Trigger
   REGION: us-west2
   ENVIRONMENT: 2nd gen
   

   כדי למצוא את השם המלא של פונקציית Cloud Run ספציפית, מריצים את הפקודה gcloud monitoring uptime describe.

4. כדי ליצור את המוניטור הסינתטי, מריצים את הפקודה gcloud monitoring uptime create:

   gcloud monitoring uptime create DISPLAY_NAME --synthetic-target=TARGET
   

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

   • ‫DISPLAY_NAME: השם של הבדיקה הסינתטית.
   • ‫TARGET: השם המלא של פונקציית Cloud Run.

5. יוצרים מדיניות התראות.

   בגלל המורכבות של הגדרת מדיניות ההתראות, מומלץ לעבור לדף Synthetic monitors במסוף Google Cloud ולהשתמש באפשרויות שמופיעות בו כדי ליצור מדיניות התראות. בגישה הזו, רוב השדות במדיניות ההתראות מאוכלסים בשבילכם. כדי ליצור את מדיניות ההתראות באמצעותGoogle Cloud המסוף, לוחצים על Create policy (יצירת מדיניות) בדף Synthetic monitors (צגים סינתטיים).

   אם אתם מתכננים להשתמש ב-Google Cloud CLI או ב-Cloud Monitoring API, אתם צריכים להגדיר את המסנן של התנאי באופן הבא:

   "filter": "resource.type = \"cloud_run_revision\" AND
               metric.type = \"monitoring.googleapis.com/uptime_check/check_passed\" AND
               metric.labels.check_id = \"CHECK_ID\"",
   

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

   מידע על יצירת מדיניות התראות זמין במאמר בנושא יצירת מדיניות התראות באמצעות ה-API.

Terraform

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

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

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

2. מוודאים שהפעלתם את ממשקי ה-API הנדרשים, שהפרויקט מכיל חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine ושהחשבון הזה קיבל את התפקיד 'עריכה' (roles/editor). מידע נוסף זמין במאמר לפני שמתחילים.

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

   הקוד הבא מגדיר קטגוריה של Cloud Storage במיקום US:

   resource "google_storage_bucket" "gcf_source" {
      name = "gcf-v2-source-9948673986912-us"
      location = "US"
      uniform_bucket_level_access = true
   }
   

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

   המשאב מציין את שם האובייקט בקטגוריה ואת המיקום של קובץ ה-ZIP במערכת המקומית. לדוגמה, כשמחילים את הקוד הבא, קובץ בשם example-function.zip מתווסף לקטגוריית האחסון:

   resource "google_storage_bucket_object" "object" {
      name = "example-function.zip"
      bucket = google_storage_bucket.gcf_source.name
      source = "generic-synthetic-node.js.zip"
   }
   

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

   הערה: אל תכללו קו תחתון בשם של פונקציית Cloud Run.

   חשוב לוודא שבמשאב google_cloudfunctions2_function מוגדר זמן ריצה של Node.js ונקודת הכניסה שמשמשת את המוניטורים הסינתטיים. לדוגמה, כשמחילים את הקוד הבא, מתבצע פריסה של פונקציה בשם sm-central1:

   resource "google_cloudfunctions2_function" "central1" {
      name = "sm-central1"
      location = "us-central1"
   
      build_config {
         runtime = "nodejs20"
         entry_point = "SyntheticFunction"
         source {
               storage_source {
                  bucket = google_storage_bucket.gcf_source.name
                  object = google_storage_bucket_object.object.name
               }
         }
      }
   
      service_config {
         max_instance_count = 1
         available_memory = "256Mi"
         timeout_seconds  = 60
      }
   }
   

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

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

   resource "google_monitoring_uptime_check_config" "synthetic" {
      display_name = "sm-central1"
      timeout = "30s"
   
      synthetic_monitor {
         cloud_function_v2 {
               name = google_cloudfunctions2_function.central1.id
         }
      }
   }
   

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

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

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

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

         כניסה אל התראות

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

      2. בוחרים באפשרות ניהול ערוצי התראות.
      3. עוברים לסוג הערוץ שרוצים להוסיף, לוחצים על הוספה ומשלימים את הדיאלוג.

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

      1. במסוף Google Cloud , עוברים לדף  Synthetic monitoring:

         מעבר אל Synthetic monitoring

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

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

REST

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

1. מוודאים שהפעלתם את ממשקי ה-API הנדרשים, שהפרויקט מכיל חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine ושהחשבון הזה קיבל את התפקיד 'עריכה' (roles/editor). מידע נוסף זמין במאמר לפני שמתחילים.

2. מגדירים את Google Cloud CLI כך שיגדיר פרויקט ברירת מחדל באמצעות הפקודה gcloud config set:

   gcloud config set project PROJECT_ID
   

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

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

   לדוגמה, כדי לפרוס את הדוגמה synthetics-sdk-nodejs במאגר Google Cloud/synthetics-sdk-nodejs:

   1. משכפלים את המאגר ועוברים למיקום של קוד המקור:

      git clone https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs.git
      cd synthetics-sdk-nodejs/samples/generic-synthetic-nodejs
      

   2. פורסים את הפונקציה של Cloud Run באמצעות הפקודה gcloud functions deploy:

      gcloud functions deploy FUNCTION_NAME \
      --gen2 --region="us-west2" --source="." \
      --entry-point=SyntheticFunction --trigger-http --runtime=nodejs18
      

      בפקודה gcloud functions deploy, מבצעים את הפעולות הבאות:

      • מוודאים שהערך בשדה FUNCTION_NAME הוא ייחודי באזור הפריסה.

        הערה: אל תכללו קו תחתון בשם של פונקציית Cloud Run.

      • כוללים את הדגל --gen2 ומגדירים את אזור הפריסה.

      • מגדירים את השדה --entry-point באופן הבא:

        • מוקה: SyntheticMochaSuite
        • לא מוקה: SyntheticFunction.

      • מגדירים את השדה --runtime לערך nodejs18.

      • כוללים את הדגל --trigger-http.

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

      פונקציות Cloud Run יוצרות את פונקציית Cloud Run ואז פורסות אותה. התוצאות של פקודת Google Cloud CLI כוללות מידע על הפונקציה, כולל השם המלא שלה:

      name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME
      

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

   כדי להציג את רשימת הפונקציות ב-Cloud Run בפרויקט Google Cloud , משתמשים בפקודה gcloud functions list:

   gcloud functions list
   

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

   NAME: function-1
   STATE: ACTIVE
   TRIGGER: HTTP Trigger
   REGION: us-west2
   ENVIRONMENT: 2nd gen
   

   כדי למצוא את השם המלא של פונקציית Cloud Run ספציפית, מריצים את הפקודה gcloud monitoring uptime describe.

4. כדי ליצור בדיקה סינתטית:

   1. לוחצים על projects.uptimeCheckConfigs.create כדי לפתוח את דף הפניית ה-API לשיטה.
   2. לוחצים על Try it כדי לפתוח את API Explorer.

   3. מגדירים את השדות הבאים ואז מריצים את הפקודה.

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

      projects/PROJECT_ID
      

      • בגוף הבקשה, מציינים את הפרטים הבאים:

      • ‫displayName: השם המוצג של הבדיקה הסינתטית.

      • ‫syntheticMonitor: מוגדר לשם המלא של פונקציית Cloud Run.

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

      {
      "name": "projects/myproject/uptimeCheckConfigs/17272586127463315332",
      "displayName": "MyMonitor",
      ...
      "syntheticMonitor": {
      "cloudFunctionV2": {
         "name": "projects/myproject/locations/us-west2/functions/function-1",
         "cloudRunRevision": {
         "type": "cloud_run_revision",
         "labels": {
            "project_id": "myproject",
            "configuration_name": "",
            "location": "us-west2",
            "revision_name": "",
            "service_name": "function-1"
         }
         }
      }
      }
      }
      

5. יוצרים מדיניות התראות.

   בגלל המורכבות של הגדרת מדיניות ההתראות, מומלץ לעבור לדף Synthetic monitors במסוף Google Cloud ולהשתמש באפשרויות שמופיעות בו כדי ליצור מדיניות התראות. בגישה הזו, רוב השדות במדיניות ההתראות מאוכלסים בשבילכם. כדי ליצור את מדיניות ההתראות באמצעותGoogle Cloud המסוף, לוחצים על Create policy (יצירת מדיניות) בדף Synthetic monitors (צגים סינתטיים).

   אם אתם מתכננים להשתמש ב-Google Cloud CLI או ב-Cloud Monitoring API, אתם צריכים להגדיר את המסנן של התנאי באופן הבא:

   "filter": "resource.type = \"cloud_run_revision\" AND
               metric.type = \"monitoring.googleapis.com/uptime_check/check_passed\" AND
               metric.labels.check_id = \"CHECK_ID\"",
   

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

   מידע על יצירת מדיניות התראות זמין במאמר בנושא יצירת מדיניות התראות באמצעות ה-API.

תמחור

למידע על התמחור של Cloud Monitoring, אפשר לעיין בדף התמחור של Google Cloud Observability.

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

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

הודעת שגיאה אחרי הפעלת ממשקי ה-API

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

An error occurred during fetching available regions: Cloud Functions API has
not been used in project PROJECT_ID before or it is disabled.

בהודעת השגיאה מומלץ לוודא שה-API מופעל, ואז להמתין ולנסות שוב לבצע את הפעולה.

כדי לוודא שממשק ה-API מופעל, עוברים לדף APIs & Services של הפרויקט:

כניסה אל APIs & Services

אחרי שמוודאים שה-API מופעל, אפשר להמשיך בתהליך היצירה. המצב הזה נפתר באופן אוטומטי אחרי שהפעלת ה-API מתפשטת דרך ה-Backend.

לא מתבצע מעקב אחרי בקשות HTTP יוצאות

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

כדי לפתור את הבעיה, צריך לוודא שחשבון השירות קיבל את התפקיד Cloud Trace Agent (סוכן Cloud Trace) ‏(roles/cloudtrace.agent). אפשר גם להשתמש בתפקיד Editor (עריכה) ‏(roles/editor).

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

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

   כניסה לדף IAM

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

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

4. אם חשבון השירות שבו נעשה שימוש בבדיקה הסינתטית לא מופיע, או אם לא הוקצה לו תפקיד שכולל את ההרשאות בתפקיד של Cloud Trace Agent ‏ (roles/cloudtrace.agent), צריך להקצות את התפקיד הזה לחשבון השירות.

   אם אתם לא יודעים את השם של חשבון השירות, בתפריט הניווט בוחרים באפשרות חשבונות שירות.

הסטטוס 'בתהליך'

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

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

• מוודאים ששם פונקציית Cloud Run לא מכיל קו תחתון. אם יש קו תחתון, צריך להסיר אותו ולפרוס מחדש את פונקציית Cloud Run.

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

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

  Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
  

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

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

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

  This function has failed to deploy and will not work correctly. Please edit and redeploy
  

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

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

סטטוס אזהרה

בקטע Synthetic monitors (בדיקות סינתטיות) מופיעה בדיקה סינתטית עם הסטטוס Warning. הסטטוס Warning מציין שהתוצאות של ההפעלה לא עקביות. יכול להיות שהדבר מצביע על בעיה בעיצוב הבדיקה, או על כך שההתנהגות של מה שנבדק לא עקבית.

סטטוס: נכשל

בקטע Synthetic monitors (בדיקות סינתטיות) מופיעה בדיקה סינתטית עם הסטטוס Failing. כדי לקבל מידע נוסף על סיבת הכשל, אפשר לעיין בהיסטוריית הביצועים האחרונה.

• אם מוצגת הודעת השגיאה Request failed with status code 429, סימן שהיעד של בקשת ה-HTTP דחה את הפקודה. כדי לפתור את הכשל הזה, צריך לשנות את היעד של הבדיקה הסינתטית.

  נקודת הקצה https://www.google.com דוחה בקשות שנשלחות על ידי כלי מעקב סינתטיים.

• אם הכשל מחזיר זמן ביצוע של 0ms, יכול להיות שפונקציית Cloud Run חורגת ממגבלת הזיכרון. כדי לפתור את הבעיה, עורכים את פונקציית Cloud Run, מגדילים את הזיכרון ל-2 GiB לפחות ומגדירים את השדה CPU ל-1.

המחיקה נכשלת עבור מעקב סינתטי

אתם משתמשים ב-Cloud Monitoring API כדי למחוק בדיקה סינתטית, אבל קריאת ה-API נכשלת עם תגובה שדומה לתגובה הבאה:

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.DebugInfo",
        "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
      }
    ]
  }
}

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

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

• דוגמאות לניטור סינתטי
• ניהול של בדיקות סינתטיות
• עיון בתוצאות של מעקב סינתטי