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

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

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

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

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

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

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

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

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

  • סביבת זמן הריצה מוגבלת ל-Node.js. מידע נוסף זמין במאמר בנושא צומת. יש תמיכה בגרסאות הבאות של Node.js: 12,‏ 14,‏ 16,‏ 18 ו-20.

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

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

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

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

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

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

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

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

  2. Enable the Cloud Monitoring API, Artifact Registry API, Cloud Build API, Cloud Functions API, Cloud Logging API, Pub/Sub API, and Cloud Run Admin API APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  3. מוודאים ש Google Cloud הפרויקט מכיל את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. חשבון השירות הזה נוצר כשמפעילים את Compute Engine API, והשם שלו דומה ל-12345-compute@developer.gserviceaccount.com.

    נכנסים לדף 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. Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

    Terraform

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

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

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

      If you're using a local shell, then create local authentication credentials for your user account: 

      gcloud auth application-default login

      You don't need to do this if you're using Cloud Shell.

      If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

    למידע נוסף, ראו הגדרת 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 קיימת.

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

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

      כניסה אל מעקב סינתטי

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

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

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

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

      • Mocha synthetic monitor: משתמשים בתבנית הזו כשכותבים חבילות של בדיקות Mocha.

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

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

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

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

    9. בתיבת הדו-שיח של פונקציית Cloud Run:

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

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

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

        • בשדה Runtime service account בוחרים חשבון שירות.

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

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

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

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

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

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

          • ‫Mocha: ‏ 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, ואז מחילים את השינויים.

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

          כניסה אל מעקב סינתטי

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

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

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

          • ‫Mocha: ‏ 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 עבור ה-method.
      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 מוצג רק מעקב אחד.

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

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

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

      נקודת הקצה (endpoint) 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."
      }
    ]
  }
}

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

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