בדף הזה מוסבר איך לבצע אופטימיזציה של העלויות ב-Google Cloud Observability ולעקוב אחריהן. למידע על מחירים, אפשר לעיין במחירון של Google Cloud Observability.
אולי יעניין אותך גם לעיין במסמכים הבאים:
- הערכת החשבונות.
- דוגמאות לתמחור.
- אופטימיזציה של העלויות באמצעות Cost Explorer. ב-Cost Explorer מוצגים נתונים עדכניים והיסטוריים של עלויות ומדדי שימוש. לכן, הנתונים עוזרים לכם לזהות הזדמנויות לאופטימיזציה.
אופטימיזציה
בקטע הזה מוסבר איך להפחית את העלויות שקשורות ל-Cloud Logging, ל-Cloud Trace ולשירות המנוהל של Google Cloud ל-Prometheus, או לבצע אופטימיזציה שלהן.
איך מפחיתים את העלויות של Cloud Logging
כדי להפחית את עלויות האחסון ב-Cloud Logging, צריך להגדיר מסנני החרגה ב-log sinks כדי למנוע הזרמה של רשומות ביומן שלא יתרמו רבות לקמפיין אל log buckets. אפשר להגדיר sink ביומן כך שיחריג את כל רשומות היומן שתואמות למסנן החרגה, או שיחריג רק אחוז מסוים מרשומות היומן התואמות. רשומות ביומן שמוחרגות לא מועברות בסטרימינג לדלי היומנים, והן לא נכללות במכסת האחסון. מידע נוסף זמין במאמר בנושא מסנני sink ביומן.
עלויות האחסון ב-Cloud Logging חלות רק על נתוני יומנים שמאוחסנים בקטגוריות של יומנים. אפשר להגדיר את יעד העברת היומנים כך שנתוני היומנים לא יישמרו במאגרי יומנים, אלא יועברו לאחד מהיעדים הבאים:
אין תשלום על ניתוב רשומות יומן ליעדים שמופיעים ברשימה ב-Cloud Logging. עם זאת, יכול להיות שתחויבו כשערכי יומן יתקבלו ביעד.
מידע על ניתוב נתוני יומנים מופיע במאמר ניתוב יומנים ליעדים נתמכים.
אופטימיזציה של העלויות של השירות המנוהל ל-Prometheus
התמחור של השירות המנוהל ל-Prometheus נועד להיות ניתן לשליטה. החיוב מתבצע על בסיס כל דגימה, ולכן אפשר להשתמש באמצעים הבאים כדי לשלוט בעלויות:
תקופת הדגימה: שינוי התקופה של איסוף המדדים מ-15 שניות ל-60 שניות יכול להוביל לחיסכון של 75% בעלויות, בלי לפגוע בקרדינליות. אפשר להגדיר תקופות דגימה לכל משימה, לכל יעד או באופן גלובלי.
סינון: אפשר להשתמש בסינון כדי לצמצם את מספר הדגימות שנשלחות למאגר הנתונים הגלובלי של השירות. מידע נוסף זמין במאמר בנושא סינון מדדים מיוצאים. משתמשים בהגדרות של שינוי שם המדד בהגדרות של Prometheus scrape כדי להשמיט מדדים בזמן ההטמעה, על סמך התאמה של תוויות.
שמירה מקומית של נתונים בעלי עוצמה גבוהה וערך נמוך. אתם יכולים להריץ את Prometheus הרגיל לצד השירות המנוהל, להשתמש באותן הגדרות של Scape ולשמור נתונים באופן מקומי אם אין טעם לשלוח אותם למאגר הנתונים הגלובלי של השירות.
התמחור של השירות המנוהל ל-Prometheus נועד להיות צפוי.
לא נטיל עליכם עונש אם ההיסטוגרמות שלכם דלילות. הדגימות נספרות רק עבור הערך הראשון שאינו אפס, ואחר כך כשהערך של bucketn גדול מהערך ב-bucketn-1. לדוגמה, היסטוגרמה עם הערכים
10 10 13 14 14 14נחשבת לשלוש דגימות, עבור הדלי הראשון, השלישי והרביעי.בהתאם למספר ההיסטוגרמות שבהן אתם משתמשים ולמטרות השימוש בהן, יכול להיות שההחרגה של קטגוריות שלא השתנו מהתמחור תוביל לכך שמספר הדגימות שייכללו בחיוב יהיה נמוך ב-20% עד 40% ממספר הקטגוריות בהיסטוגרמה.
כשמחייבים על בסיס כל דגימה, לא מוטלים עונשים על קונטיינרים שניתנים להפסקת פעולה, זמניים או שניתנים להרחבה מהירה או שאינם ניתנים להרחבה, כמו אלה שנוצרו על ידי HPA או GKE Autopilot.
אם שירות מנוהל ל-Prometheus מחויב על בסיס מדד, תשלמו על העוצמה (cardinality) של חודש מלא, הכול בבת אחת, בכל פעם שקונטיינר חדש מופעל. בתמחור לפי דגימה, אתם משלמים רק בזמן שהקונטיינר פועל.
שאילתות, כולל שאילתות של התראות
כל השאילתות שהמשתמש מריץ, כולל שאילתות שמופעלות כשמריצים כללי הקלטה של Prometheus, מחויבות דרך קריאות ל-Cloud Monitoring API.
צמצום השימוש ב-Trace
כדי לשלוט בנפח ההטמעה של נתוני הטווח של Trace, אתם יכולים לנהל את קצב הדגימה של הנתונים כדי ליצור איזון בין מספר הנתונים שאתם צריכים לניתוח הביצועים לבין סף העלויות שאתם מוכנים לשלם.
במערכות עם נפח תנועה גבוה, רוב הלקוחות יכולים לדגום בשיעור של 1 מתוך 1,000 עסקאות, או אפילו 1 מתוך 10,000 עסקאות, ועדיין לקבל מספיק מידע לניתוח הביצועים.
קצב הדגימה מוגדר באמצעות ספריות הלקוח של Cloud Trace.
הפחתת החיוב על התראות
בקטע הזה מתוארות אסטרטגיות שבהן אפשר להשתמש כדי לצמצם את העלויות של התראות. למידע על מודל התמחור, ראו תמחור של 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 נקודות לכל הפעלה, יקרה יותר מהאפשרות הראשונה, שמחזירה רק חמש נקודות לכל הפעלה.
כשמגדירים את מדיניות ההתראות, צריך לבחור רמות צבירה שמתאימות לתרחיש השימוש. לדוגמה, אם חשוב לכם לקבל התראה על ניצול המעבד, כדאי לצבור נתונים ברמת המכונה הווירטואלית והמעבד. אם חשוב לכם לקבל התראות על זמן האחזור לפי שירות, כדאי לכם לצבור נתונים ברמת השירות.
לא להציג התראות על נתונים גולמיים ולא מצטברים
ב-Monitoring נעשה שימוש במערכת של מדדים רב-ממדיים, שבה לכל מדד יש עוצמה כוללת ששווה למספר המשאבים שבמעקב כפול מספר השילובים של תוויות במדד הזה. לדוגמה, אם יש לכם 100 מכונות וירטואליות שפולטות מדד, ולמדד הזה יש 10 תוויות עם 10 ערכים כל אחת, הקרדינליות הכוללת היא 100 * 10 * 10 = 10,000.
כתוצאה מהאופן שבו העוצמה (cardinality) גדלה, התראות על נתונים גולמיים עלולות להיות יקרות מאוד. בדוגמה הקודמת, מוחזרות 10,000 נקודות לכל תקופת ביצוע. עם זאת, אם מצברים את הנתונים במכונה הווירטואלית, יוחזרו רק 100 נקודות לכל תקופת ביצוע, ללא קשר לקרדינליות של התווית בנתוני הבסיס.
התראות על נתונים גולמיים גם חושפות אתכם לסיכון של עלייה בנקודות שמוחזרות כשמדדים מקבלים תוויות חדשות. בדוגמה הקודמת, אם משתמש מוסיף תווית חדשה למדד, העוצמה הכוללת (cardinality) גדלה ל-100 * 11 * 10 = 11,000 סדרות זמן. במקרה כזה, מספר הנקודות שמוחזרות גדל ב-1,000 בכל תקופת ביצוע, גם אם מדיניות ההתראות לא משתנה. אם במקום זאת תבצעו צבירה למכונה הווירטואלית, עדיין יוחזרו רק 100 סדרות זמן, למרות הקרדינליות הבסיסית המוגדלת.
סינון תשובות מיותרות
כדאי להגדיר את התנאים כך שיוערכו רק נתונים שנדרשים לצורך ההתראות. אם לא תרצו לבצע פעולה כדי לתקן משהו, תוכלו להחריג אותו ממדיניות ההתראות. לדוגמה, כנראה שלא תצטרכו לקבל התראה על מכונה וירטואלית לפיתוח של מתמחה.
כדי לצמצם את מספר ההתראות והעלויות שלא נחוצות, אפשר לסנן סדרות זמן שלא חשובות. אתם יכולים להשתמש ב 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 (משאב לא מוגדר). השיטה הזו עובדת כי רוב המדדים שמבוססים על יומנים מופיעים רק בסוג אחד של משאב. אם מדד שמבוסס על יומן מופיע בכמה סוגי משאבים, אפשר ליצור כמה מדיניות התראות או להשתמש בכמה תנאים במדיניות התראה אחת.
מעקב
בקטע הזה מוסבר איך לעקוב אחרי העלויות באמצעות יצירה של מדיניות התראות. מדיניות התראות יכולה לעקוב אחרי נתוני מדדים ולשלוח לכם התראה כשהנתונים חוצים סף מסוים.
מעקב אחרי מספר הבייטים של יומנים שנבלעו מדי חודש
כדי ליצור מדיניות התראה שמופעלת כשמספר הבייטים ביומן שנכתבו לקטגוריות היומן חורג מהמגבלה שהוגדרה על ידי המשתמש ב-Cloud Logging, משתמשים בהגדרות הבאות.
| תנאי חדש שדה |
ערך |
|---|---|
| מקור מידע ומדד | בתפריט Resources בוחרים באפשרות Global. בתפריט Metric categories בוחרים באפשרות מדד מבוסס-יומנים. בתפריט Metrics, בוחרים באפשרות Monthly log bytes ingested. |
| פילטר | אין. |
| בסדרות עיתיות צבירה של סדרות עיתיות |
sum |
| חלון נע | 60 m |
| פונקציה אנליטית (window function) | max |
| הגדרת טריגר להתראה שדה |
ערך |
|---|---|
| סוג התנאי | Threshold |
| טריגר להתראה | Any time series violates |
| Threshold position | Above threshold |
| סכום הסף | אתם קובעים את הערך הקביל. |
| חלון הבדיקה מחדש | הערך המינימלי הקביל הוא 30 דקות. |
מעקב אחרי סך כל המדדים שהמערכת קולטת
אי אפשר ליצור התראה על סמך המדדים החודשיים שמוזנים למערכת. עם זאת, אתם יכולים ליצור התראה לגבי העלויות שלכם ב-Cloud Monitoring. מידע נוסף זמין במאמר בנושא הגדרת התראות על חיוב.
מעקב אחר טווחים של נתוני מעקב שהוטמעו מדי חודש
כדי ליצור מדיניות התראות שמופעלת כשהטווח של Cloud Trace שנבלע בחודש חורג ממגבלה שהוגדרה על ידי המשתמש, צריך להשתמש בהגדרות הבאות.
| תנאי חדש שדה |
ערך |
|---|---|
| מקור מידע ומדד | בתפריט Resources בוחרים באפשרות Global. בתפריט Metric categories בוחרים באפשרות Billing. בתפריט Metrics, בוחרים באפשרות Monthly trace spans ingested. |
| פילטר | |
| בסדרות עיתיות צבירה של סדרות עיתיות |
sum |
| חלון נע | 60 m |
| פונקציה אנליטית (window function) | max |
| הגדרת טריגר להתראה שדה |
ערך |
|---|---|
| סוג התנאי | Threshold |
| טריגר להתראה | Any time series violates |
| Threshold position | Above threshold |
Threshold value |
אתם קובעים את הערך הקביל. |
| חלון הבדיקה מחדש | הערך המינימלי הקביל הוא 30 דקות. |
הגדרת התראה לגבי חיוב
כדי לקבל התראה אם החיובים או התחזית שלכם חורגים מהתקציב, אתם יכולים ליצור התראה בדף Budgets and alerts במסוף Google Cloud :
-
נכנסים לדף Billing במסוף Google Cloud :
אפשר גם להשתמש בסרגל החיפוש כדי למצוא את הדף הזה.
אם יש לכם יותר מחשבון אחד לחיוב ב-Cloud:
- כדי לנהל את החיוב ב-Cloud לפרויקט הנוכחי, לוחצים על Go to linked billing account.
- כדי למצוא חשבון אחר לחיוב ב-Cloud, לוחצים על Manage billing accounts ובוחרים את החשבון שבו רוצים להגדיר תקציב.
- בתפריט הניווט Billing בוחרים באפשרות Budgets & alerts.
- לוחצים על Create budget (יצירת תקציב).
- משלימים את תיבת הדו-שיח של התקציב. בתיבת הדו-שיח הזו בוחרים Google Cloud פרויקטים ומוצרים, ואז יוצרים תקציב לשילוב הזה. כברירת מחדל, תקבלו התראה כשתגיעו ל-50%, ל-90% ול-100% מהתקציב. לתיעוד מלא, אפשר לעיין במאמר בנושא הגדרת תקציבים והתראות תקציב.