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

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

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

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

התראות שווא בגלל חריגות בחישוב היחס

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

  • מסוףGoogle Cloud : מגדירים את משך הזמן בשדה משך כשמגדירים את תנאי ההתראה.
  • ‫Cloud Monitoring API או Terraform: מציינים את משך הזמן בשדה AlertPolicy.Condition.PrometheusQueryLanguageCondition.duration.

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