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

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

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

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

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

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

  • במאמר הצגת רשימה של מדדים וסוגי משאבים מוסבר איך להציג ולבדוק את סוגי המדדים המוגדרים על ידי המשתמש ואת סוגי המדדים המובנים. לדוגמה, אפשר להשתמש במידע שמופיע במסמך הזה כדי להציג רשימה של כל תיאורי המדדים שהוגדרו על ידי המשתמש בפרויקט.
  • במאמר אחזור נתונים של סדרות זמנים מוסבר איך לאחזר נתונים של סדרות זמנים ממדדים באמצעות Monitoring API. לדוגמה, במאמר הזה מוסבר איך אפשר להשתמש ב-API כדי לקבל את נתוני השימוש במעבד (CPU) של מופעים של מכונות וירטואליות (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 pod.

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

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

‫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.

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

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