מידע על יחסי מדדים

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

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

שיטות מומלצות

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

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

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

הגבלות עם יחסים

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

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

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

    נניח שיש הגדרה שבה סדרת הזמן של המונה כוללת את התוויות method,‏ quota_metric ו-project_id. לסדרת הזמן של המכנה יש תוויות limit_name, quota_metric ו-project_id. האפשרויות התקפות לקיבוץ המכנה תלויות באפשרויות שנבחרו עבור המונה:

    • מונה מקובץ לפי התווית method: משלבים את סדרת הזמנים של המכנה לסדרת זמן אחת. אין קיבוץ אחר שבו התוויות של סדרת הזמן במכנה הן קבוצת משנה של התוויות של סדרת הזמן במונה.
    • מונה מקובץ לפי התווית quota_metric: מקבצים את המכנה לפי התווית הזו או משלבים את כל סדרות הזמנים במכנה לסדרת זמן אחת.
    • מונה מקובץ לפי התוויות quota_metric ו-project_id: מקבצים את המכנה לפי שתי התוויות, לפי תווית אחת או משלבים את סדרת הזמנים של המכנה לסדרת זמנים אחת.

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

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

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

  • למונה ולמכנה צריך להיות אותו סוג ערך. לדוגמה, אם המונה הוא מסוג DOUBLE, המכנה צריך להיות גם הוא מסוג DOUBLE.

    כדי להשתמש ביחסים, המונה והמכנה של המדד צריכים להיות מסוג DOUBLE או INT64.

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

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

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

    לדוגמה, אם המשאב של מדד המונה הוא מכונות של Compute Engine, אז המשאב של מדד המכנה חייב להיות גם מכונות של Compute Engine.

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

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

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

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

ההבדל במספר הערכים במרווחי ההתאמה המקבילים יכול להוביל לערכי יחס לא הגיוניים של error/total, כמו 1/0 או 2/1.

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

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

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

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