‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

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

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

הגדרת הפרויקט והתפקידים

כדי לקבל את ההרשאות שדרושות להצגה ולשינוי של בדיקות סינתטיות באמצעות Google Cloud המסוף, צריך לבקש מהאדמין להקצות לכם בפרויקט את תפקידי ה-IAM הבאים:
- עריכה של מעקב (roles/monitoring.editor)
- Cloud Functions Developer (roles/cloudfunctions.developer)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
מפעילים את Cloud Monitoring API,‏ Artifact Registry API,‏ Cloud Build API,‏ Cloud Functions API,‏ Cloud Logging API,‏ Pub/Sub API ו-Cloud Run Admin API, אם אחד מהם לא מופעל כבר.
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים
הפעלת ממשקי ה-API
מוודאים ש Google Cloud הפרויקט מכיל את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. חשבון השירות הזה נוצר כשמפעילים את Compute Engine API, והשם שלו דומה ל-12345-compute@developer.gserviceaccount.com.

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

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

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

כדי לראות את התפקידים שניתנו לחשבון השירות:
1. נכנסים לדף IAM במסוף Google Cloud :
  כניסה לדף IAM
  
  אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שמופיע בה הכותרת המשנית IAM & Admin.
2. בוחרים באפשרות Include Google-provided role grants.
3. אם חשבון השירות שבו נעשה שימוש בבדיקה הסינתטית לא מופיע, או אם לא הוקצה לו תפקיד שכולל את ההרשאות בתפקיד Cloud Trace Agent ‏ (roles/cloudtrace.agent), צריך להקצות את התפקיד הזה לחשבון השירות.
מגדירים את ערוצי ההתראות שרוצים להשתמש בהם כדי לקבל התראות. מומלץ ליצור כמה סוגים של ערוצי התראות. מידע נוסף זמין במאמרים בנושא יצירה וניהול של ערוצי התראות ויצירה וניהול של ערוצי התראות באמצעות API.

בחירת הממשק שבו רוצים להשתמש

המסוף

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

gcloud

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

הפעלת Cloud Shell

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

Terraform

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

התקינו את ה-CLI של Google Cloud.
אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.
אם אתם משתמשים במעטפת מקומית, אתם צריכים ליצור פרטי כניסה לאימות מקומי עבור חשבון המשתמש:
```
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 .

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

המסוף

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

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

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.
בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את הפרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
בוחרים באפשרות יצירת בדיקה סינתטית.
בוחרים את התבנית לפונקציית Cloud Run:
- ניטור סינתטי בהתאמה אישית: משתמשים בתבנית הזו כשרוצים לאסוף נתוני יומן או נתוני מעקב לבקשות HTTP יוצאות.
- ‫Mocha synthetic monitor: משתמשים בתבנית הזו כשכותבים חבילות בדיקה של Mocha.
- בודק קישורים שבורים: אפשר להשתמש בתבנית הזו כדי לבדוק URI ומספר קישורים שניתן להגדרה שנמצאים ב-URI הזה. מידע על השדות של הכלי הזה זמין במאמר בנושא יצירת כלי לבדיקת קישורים שבורים.
מזינים שם לניטור.
אופציונלי: מעדכנים את זמן קצוב לתפוגה של התגובה ואת תדירות הבדיקה, ומוסיפים תוויות שהוגדרו על ידי המשתמש.
מבצעים אחת מהפעולות הבאות:
- אם יש לכם גישה ל-Gemini Code Assist בפרויקט הזה ואתם רוצים עזרה בכתיבת הקוד, אתם יכולים ללחוץ על עזרה בכתיבת קוד. התכונה הזו זמינה בתוכנית Public Preview. הנחיות לכתיבת הנחיות מופיעות במאמר הנחיות לכתיבת הנחיות לשימוש בבדיקות סינתטיות.
  
  אחרי שאתם מרוצים מהקוד, לוחצים על Insert into Cloud Function (הוספה לפונקציה של Cloud Functions).
- לוחצים על יצירת פונקציה.
בתיבת הדו-שיח של פונקציית 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 ומוצגות האפשרויות 'בחירה' או 'ביטול'. לוחצים על ביטול כדי לחזור לתיבת הדו-שיח יצירת פונקציה. לאחר מכן, בשדה של קטגוריית היעד, לוחצים על Browse ובוחרים את קטגוריית Cloud Storage.
  - כדי לטעון קובץ ZIP מ-Cloud Storage, בוחרים באפשרות ZIP from Cloud Storage (קובץ ZIP מ-Cloud Storage), בוחרים את קטגוריית האחסון ואז בוחרים את קובץ ה-ZIP לטעינה.
  אפשר גם ליצור פונקציית Cloud Run באמצעות הדפים של Cloud Run functions במסוף Google Cloud . כדי ליצור בדיקה סינתטית שעוקבת אחרי עותק של פונקציית Cloud Run, עוברים לכרטיסייה מקור ולוחצים על הורדת קובץ zip. אחר כך אפשר להעלות את קובץ ה-ZIP.
4. לוחצים על החלת הפונקציה.
מגדירים את מדיניות ההתראות:
1. אופציונלי: מעדכנים את השם של מדיניות ההתראות ואת משך הכישלון לפני שליחת ההתראות.
2. מוסיפים את ערוצי ההתראות.
לוחצים על יצירה.

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

gcloud

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

צריך לוודא שהפעלתם את ממשקי ה-API הנדרשים, שהפרויקט מכיל חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine, ושהחשבון הזה קיבל את התפקיד 'עריכה' (roles/editor). מידע נוסף זמין במאמר לפני שמתחילים.
מגדירים את Google Cloud CLI כך שיגדיר פרויקט ברירת מחדל באמצעות הפקודה gcloud config set:
```
gcloud config set project PROJECT_ID
```
לפני שמריצים את הפקודה הקודמת, מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את הפרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
כותבים ופורסים את פונקציית 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.
כדי ליצור את המוניטור הסינתטי, מריצים את הפקודה gcloud monitoring uptime create:
```
gcloud monitoring uptime create DISPLAY_NAME --synthetic-target=TARGET
```
לפני שמריצים את הפקודה הקודמת, מחליפים את מה שכתוב בשדות הבאים:
- ‫DISPLAY_NAME: השם של הבדיקה הסינתטית.
- ‫TARGET: השם המלא של פונקציית Cloud Run.
יוצרים מדיניות התראות.

בגלל המורכבות של הגדרת מדיניות ההתראות, מומלץ לעבור לדף 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.

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

מתקינים ומגדירים את Terraform לפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את הפרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
צריך לוודא שהפעלתם את ממשקי ה-API הנדרשים, שהפרויקט מכיל חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine, ושהחשבון הזה קיבל את התפקיד 'עריכה' (roles/editor). מידע נוסף זמין במאמר לפני שמתחילים.
עורכים את קובץ התצורה של 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
}
```
עורכים את קובץ התצורה של 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"
}
```

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

חשוב לוודא שבמשאב 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
   }
}

כדי ליצור בדיקה סינתטית, עורכים את קובץ ההגדרות של 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
      }
   }
}

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

בשלבים הבאים מוסבר איך ליצור את ערוץ ההתראות ואת מדיניות ההתראות באמצעות מסוף 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

צריך לוודא שהפעלתם את ממשקי ה-API הנדרשים, שהפרויקט מכיל חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine, ושהחשבון הזה קיבל את התפקיד 'עריכה' (roles/editor). מידע נוסף זמין במאמר לפני שמתחילים.
מגדירים את Google Cloud CLI כך שיגדיר פרויקט ברירת מחדל באמצעות הפקודה gcloud config set:
```
gcloud config set project PROJECT_ID
```
לפני שמריצים את הפקודה הקודמת, מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את הפרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
כותבים ופורסים את פונקציית 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.
כדי ליצור בדיקה סינתטית:
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"
   }
   }
}
}
}
```
יוצרים מדיניות התראות.

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

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

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

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

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שמופיע בה הכותרת המשנית IAM & Admin.
בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את הפרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
בוחרים באפשרות Include Google-provided role grants.
אם חשבון השירות שבו נעשה שימוש בבדיקה הסינתטית לא מופיע, או אם לא הוקצה לו תפקיד שכולל את ההרשאות בתפקיד של 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."
      }
    ]
  }
}

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת הפרויקט והתפקידים

בחירת הממשק שבו רוצים להשתמש

המסוף

gcloud

Terraform

REST

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

המסוף

gcloud

Terraform

REST

תמחור

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

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

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

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

סטטוס האזהרה

סטטוס: נכשל

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

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

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