סקירה כללית של מדדים מוגדרים על ידי משתמש

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

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

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

אפשר ליצור מדדים מוגדרים על ידי משתמש, למעט מדדים שמבוססים על יומנים, באמצעות Cloud Monitoring API ישירות. עם זאת, מומלץ להשתמש ב-OpenTelemetry. מידע על יצירת מדדים בהגדרת המשתמש מופיע במאמרים הבאים:

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

  • במאמר List metric and resource types מוסבר איך להציג ולבדוק את סוגי המדדים המוגדרים על ידי המשתמש ואת סוגי המדדים המובנים. לדוגמה, אפשר להשתמש במידע שמופיע במסמך הזה כדי להציג רשימה של כל תיאורי המדדים שהוגדרו על ידי המשתמש בפרויקט.
  • במאמר אחזור נתונים של סדרות זמנים מוסבר איך לאחזר נתונים של סדרות זמנים ממדדים באמצעות Monitoring API. לדוגמה, במסמך הזה מוסבר איך אפשר להשתמש ב-API כדי לקבל את נתוני השימוש במעבד של מופעים של מכונות וירטואליות (VM) בפרויקט Google Cloud .

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

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

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

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

דוגמה לעיצוב

נניח שיש לכם תוכנית שפועלת במחשב יחיד, ושתוכנית זו קוראת לתוכניות עזר A ו-B. רוצים לספור את מספר הפעמים שבהן התוכניות A ו-B נקראות. אתם גם רוצים לדעת מתי מתבצעת קריאה לתוכנית A יותר מ-10 פעמים בדקה, ומתי מתבצעת קריאה לתוכנית B יותר מ-5 פעמים בדקה. לבסוף, נניח שיש לכם פרויקט אחד Google Cloud ואתם מתכננים לכתוב את הנתונים למשאב במעקב global.

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

  • אתם משתמשים בשני מדדים: Metric-type-A סופר שיחות לתוכנית A וMetric-type-B סופר שיחות לתוכנית B. במקרה הזה, Metric-type-A מכיל סדרת זמן אחת, ו-Metric-type-B מכיל סדרת זמן אחת.

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

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

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

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

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

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

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

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

שמות של מדדים שהוגדרו על ידי המשתמש

כשיוצרים מדד מוגדר על ידי המשתמש, מגדירים מזהה מחרוזת שמייצג את סוג המדד. המחרוזת הזו צריכה להיות ייחודית בין המדדים שהוגדרו על ידי המשתמש בGoogle Cloud פרויקט, והיא צריכה לכלול תחילית שמציינת שהמדד הוגדר על ידי המשתמש. למעקב, הקידומות המותרות הן custom.googleapis.com/, workload.googleapis.com/, external.googleapis.com/user ו-external.googleapis.com/prometheus. אחרי הקידומת מופיע שם שמתאר את מה שאוספים. פרטים על הדרך המומלצת למתן שם למדד מופיעים במאמר בנושא מוסכמות למתן שמות למדדים. דוגמאות לשני סוגי המזהים של סוגי מדדים:

    custom.googleapis.com/cpu_utilization
    custom.googleapis.com/instance/cpu/utilization

בדוגמה הקודמת, הקידומת custom.googleapis.com מציינת ששני המדדים הם מדדים שהוגדרו על ידי המשתמש. שתי הדוגמאות הן למדדים שמודדים את ניצול המעבד, אבל הן משתמשות במודלים ארגוניים שונים. אם אתם צופים שתהיה לכם כמות גדולה של מדדים שהוגדרו על ידי המשתמש, מומלץ להשתמש במבנה היררכי למתן שמות כמו בדוגמה השנייה.

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

projects/PROJECT_ID/metricDescriptors/METRIC_TYPE

כאשר METRIC_TYPE הוא מזהה המחרוזת של סוג המדד. אם יוצרים את הדוגמאות הקודמות של המדדים בפרויקט my-project-id, שמות המשאבים של המדדים האלה יהיו:

    projects/my-project-id/metricDescriptors/custom.googleapis.com/cpu_utilization
    projects/my-project-id/metricDescriptors/custom.googleapis.com/instance/cpu/utilization

שם או סוג? בשדה name של מתאר המדד נשמר שם המשאב של סוג המדד, ובשדה type נשמר המחרוזת METRIC_TYPE.

סוגי משאבים שבמעקב למדדים שהוגדרו על ידי המשתמש

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

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

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

חובה להשתמש באחד מסוגי המשאבים הבאים שבמעקב עם מדדים מוגדרים על ידי המשתמש:

  • ‫aws_ec2_instance: מופע Amazon EC2.
  • ‫dataflow_job: משימת Dataflow.
  • ‫gae_instance: מופע App Engine.
  • ‫gce_instance: מכונה של Compute Engine.
  • ‫generic_node: צומת מחשוב שצוין על ידי המשתמש.
  • ‫generic_task: משימה בהגדרת המשתמש.
  • ‫gke_container: מופע של קונטיינר GKE.
  • ‫global: משתמשים במשאב הזה כשאין סוג משאב אחר שמתאים. ברוב תרחישי השימוש, עדיף להשתמש ב-generic_node או ב-generic_task במקום ב-global.
  • ‫k8s_cluster: אשכול Kubernetes.
  • ‫k8s_container: קונטיינר Kubernetes.
  • ‫k8s_node: צומת Kubernetes.
  • ‫k8s_pod: פוד של Kubernetes.

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

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

‫global ומשאבים גנריים

סוגי המשאבים generic_task ו-generic_node שימושיים במצבים שבהם אף אחד מסוגי המשאבים הספציפיים יותר לא מתאים. הסוג generic_task שימושי להגדרת משאבים דמויי משימות, כמו אפליקציות. הסוג generic_node שימושי להגדרת משאבים דמויי צומת, כמו מכונות וירטואליות. לשני הסוגים generic_* יש כמה תוויות משותפות שאפשר להשתמש בהן כדי להגדיר אובייקטים ייחודיים של משאבים, וכך קל להשתמש בהן במסנני מדדים לצורך צבירה וצמצום.

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

שיטות API שתומכות במדדים מוגדרים על ידי המשתמש

בטבלה הבאה מפורטות השיטות ב-Monitoring API שתומכות במדדים מוגדרים על ידי המשתמש והשיטות שתומכות במדדים מובנים:

שיטת Monitoring API שימוש עם
מדדים שהוגדרו על ידי המשתמש		 שימוש במדדים מובנים
monitoredResourceDescriptors.get כן כן
monitoredResourceDescriptors.list כן כן
metricDescriptors.get כן כן
metricDescriptors.list כן כן
timeSeries.list כן כן
timeSeries.create כן
metricDescriptors.create כן
metricDescriptors.delete כן

מגבלות וזמני אחזור

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

כדי לשמור את נתוני המדדים מעבר לתקופת השמירה, צריך להעתיק את הנתונים באופן ידני למיקום אחר, כמו Cloud Storage או BigQuery.

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

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