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

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

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

כדי להוסיף אינסטרומנטציה לקוד ולאסוף מדדים בהגדרת המשתמש, מומלץ להשתמש ב-OpenTelemetry, אבל אפשר גם להשתמש ב-Prometheus או ב-Cloud Monitoring API ישירות. כדי להפיק מדדים מרשומות ביומן, צריך ליצור מדדים מבוססי-יומנים ב-Cloud Logging. אפשר לעקוב אחרי הטמעת המדדים בדף Metrics Management במסוף Google Cloud .

במסמכים הבאים מוסבר איך ליצור מדדים בהגדרת המשתמש:

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

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

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

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.

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

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

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

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

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

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

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

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

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