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

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

שימוש במחשבון התמחור בממשק המשתמש כדי לראות את החשבון המשוער

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

שימוש ב-Metrics Explorer כדי לאמת את מספר הנקודות שמוחזרות

מספר הנקודות שמוחזרות על ידי השאילתה של מדיניות ההתראות תלוי בעיקר בעוצמה (cardinality) של הפלט של השאילתה של מדיניות ההתראות. כדי לראות את הקרדינליות המשוערת של מדיניות ההתראות:

  • כדי ליצור תנאי התראה של סף מדד, משתמשים ב-Metrics Explorer כדי ליצור שאילתה זהה. מוסיפים טרנספורמציה משנית של ספירת סדרות זמן לפי ללא.
  • כדי להגדיר תנאי התראה ב-PromQL, מעתיקים את השאילתה אל Metrics Explorer ואז מבצעים את הפעולות הבאות:
    • כדי לפצל את השאילתה לסעיפים נפרדים, צריך לפצל אותה לפי כל אחד מהאופרטורים >, <, >=, <=, ==, !=, AND, OR ו-UNLESS.
    • מוחקים כל סעיף שלא מכיל מדד, כמו ערך סף מספרי.
    • עוטפים כל סעיף בפונקציה count().
    • מסכמים את התוצאות.

  • בשביל תנאי התראה של MQL, מעתיקים את השאילתה אל Metrics Explorer. מסירים את השורה | condition. מוסיפים שורה של | group_by [], .count בסוף.

    התמיכה ב-MQL הוצאה משימוש, ויכול להיות שבקשות תמיכה לקבלת עזרה בניפוי באגים בבעיות שקשורות לחיוב יידחו על ידי Cloud Customer Care.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כתוצאה מהאופן שבו העוצמה (cardinality) גדלה, התראות על נתונים גולמיים עלולות להיות יקרות מאוד. בדוגמה הקודמת, מוחזרות 10,000 נקודות לכל תקופת ביצוע. עם זאת, אם מצברים את הנתונים במכונה הווירטואלית, יוחזרו רק 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 שניות.

אל תשתמשו בערך Unspecified Resource (מקור לא מוגדר) (רק במדדים מבוססי-יומן)

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

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