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

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

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

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

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

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

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