ניהול עלויות של התראות

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

איחוד של מדיניות התראות כדי להפעיל אותה על יותר משאבים

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

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

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

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

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

צבירה רק לרמה שרוצים לקבל עליה התראה

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

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

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

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

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

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

לא להציג התראות על נתונים גולמיים ולא מצטברים

המעקב מתבצע באמצעות מערכת של מדדים רב-ממדיים, שבה לכל מדד יש עוצמה כוללת ששווה למספר המשאבים שבמעקב כפול מספר שילובי התוויות במדד הזה. לדוגמה, אם יש לכם 100 מכונות וירטואליות שפולטות מדד, ולמדד הזה יש 10 תוויות עם 10 ערכים כל אחת, הקרדינליות הכוללת היא 100 * 10 * 10 = 10,000.

כתוצאה מהאופן שבו העוצמה (cardinality) גדלה, שליחת התראות על נתונים גולמיים עלולה להיות יקרה מאוד. בדוגמה הקודמת, קיבלתם 10,000 סדרות זמן לכל תקופת ביצוע. עם זאת, אם מצברים את הנתונים ב-VM, יוחזרו רק 100 סדרות זמן לכל תקופת הרצה, ללא קשר לקרדינליות של התוויות בנתוני הבסיס.

התראות על נתונים גולמיים גם חושפות אתכם לסיכון של עלייה בסדרת הזמנים כשמדדים מקבלים תוויות חדשות. בדוגמה הקודמת, אם משתמש מוסיף תווית חדשה למדד, העוצמה הכוללת (cardinality) תגדל ל-100 * 11 * 10 = 11,000 סדרות זמן. במקרה כזה, מספר סדרות הזמן שמוחזרות יגדל ב-1,000 בכל תקופת ביצוע, גם אם מדיניות ההתראות לא השתנתה. אם במקום זאת מצברים את הנתונים במכונה הווירטואלית, עדיין מוחזרות רק 100 סדרות זמן, למרות הקרדינליות הבסיסית הגבוהה יותר.

סינון תשובות מיותרות

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

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

שימוש באופרטורים של הזרם העליון כדי לצמצם את מספר סדרות הזמן שמוחזרות

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

  • ‫PromQL: ‏ topk

לדוגמה, סעיף topk(metric, 5) בשאילתת PromQL מגביל את מספר סדרות הזמן שמוחזרות לחמש בכל תקופת ביצוע.

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

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

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

הארכת משך תקופת ההפעלה (PromQL בלבד)

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

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