בדף הזה מוסבר איך לבצע אופטימיזציה של העלויות ב-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 כדי להשמיט מדדים בזמן ההטמעה, על סמך התאמות של תוויות.
שמירה של נתונים בעלי עוצמה גבוהה וערך נמוך באופן מקומי. אתם יכולים להריץ את Prometheus הרגיל לצד השירות המנוהל, להשתמש באותן הגדרות של Scape ולשמור נתונים באופן מקומי אם לא כדאי לשלוח אותם למאגר הנתונים הגלובלי של השירות.
התמחור של השירות המנוהל ל-Prometheus נועד להיות צפוי.
לא נבצע פעולה נגדית אם ההיסטוגרמות שלכם דלילות. הדגימות נספרות רק עבור הערך הראשון ששונה מאפס, ואחר כך כשהערך של bucketn גדול מהערך ב-bucketn-1. לדוגמה, היסטוגרמה עם הערכים
10 10 13 14 14 14נחשבת לשלוש דגימות, עבור הדלי הראשון, השלישי והרביעי.בהתאם למספר ההיסטוגרמות שבהן אתם משתמשים ולמטרות השימוש בהן, החרגה של קטגוריות ללא שינוי מהתמחור עשויה להוביל לכך שמספר הדגימות שייכללו בחיוב יהיה נמוך ב-20% עד 40% ממספר הקטגוריות בהיסטוגרמה.
אם אתם משלמים לפי דגימה, לא נחייב אתכם על קונטיינרים שניתנים להפסקת פעולה, זמניים או שניתנים להרחבה מהירה או שאינם ניתנים להרחבה, כמו אלה שנוצרו על ידי HPA או GKE Autopilot.
אם שירות מנוהל ל-Prometheus מחויב על בסיס כל מדד, תחויבו על קרדינליות של חודש שלם, הכול בבת אחת, בכל פעם שקונטיינר חדש מופעל. בתמחור לפי דגימה, אתם משלמים רק בזמן שהקונטיינר פועל.
שאילתות, כולל שאילתות של התראות
כל השאילתות שהמשתמש מריץ, כולל שאילתות שמופעלות כשמריצים כללי הקלטה של Prometheus, מחויבות באמצעות קריאות ל-Cloud Monitoring API.
צמצום השימוש ב-Trace
כדי לשלוט בנפח ההעברה של נתוני טווח ב-Trace, אתם יכולים לנהל את קצב הדגימה של הנתונים כדי לאזן בין מספר הנתונים שאתם צריכים לניתוח הביצועים לבין סף העלויות שלכם.
במערכות עם נפח תנועה גבוה, רוב הלקוחות יכולים לבצע דגימה של 1 מתוך 1,000 עסקאות, או אפילו 1 מתוך 10,000 עסקאות, ועדיין לקבל מספיק מידע לניתוח הביצועים.
קצב הדגימה מוגדר באמצעות ספריות הלקוח של Cloud Trace.
הפחתת החיוב על התראות
בקטע הזה מתוארות אסטרטגיות שבהן אפשר להשתמש כדי לצמצם את העלויות של התראות.
איחוד של מדיניות התראות כדי להפעיל אותה על יותר משאבים
התראות כרוכות בעלות לכל תנאי. לכן, כשזה אפשרי, מומלץ להשתמש במדיניות התראות אחת כדי לעקוב אחרי כמה משאבים, במקום ליצור מדיניות התראות לכל משאב.
לדוגמה, נניח שיש לכם 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 שניות.
מעקב
בקטע הזה מוסבר איך לעקוב אחרי העלויות באמצעות יצירה של מדיניות התראות. מדיניות התראות יכולה לעקוב אחרי נתוני מדדים ולשלוח לכם התראה כשהנתונים חוצים סף מסוים.
מעקב אחרי נפח הנתונים ביומן שנבלעו מדי חודש
כדי ליצור מדיניות התראה שמופעלת כשמספר הבייטים ביומן שנכתבו לקטגוריות היומן חורג מהמגבלה שהוגדרה על ידי המשתמש עבור Cloud Logging, משתמשים בהגדרות הבאות.
| תנאי חדש שדה |
ערך |
|---|---|
| משאב ומדד | בתפריט Resources (משאבים), בוחרים באפשרות Global (גלובלי). בתפריט Metric categories, בוחרים באפשרות מדד מבוסס-יומנים. בתפריט Metrics, בוחרים באפשרות Monthly log bytes ingested. |
| מסנן | אין. |
| בסדרות של נתונים על ציר הזמן צבירה של נתונים על ציר הזמן |
sum |
| חלון מתגלגל | 60 m |
| פונקציה אנליטית (חלון נע) | max |
| הגדרת טריגר להתראה שדה |
ערך |
|---|---|
| סוג התנאי | Threshold |
| טריגר להתראה | Any time series violates |
| מיקום הסף | Above threshold |
| ערך הסף | אתם קובעים את הערך הקביל. |
| חלון הבדיקה מחדש | הערך המינימלי הקביל הוא 30 דקות. |
מעקב אחרי סך כל המדדים שהועברו
אי אפשר ליצור התראה על סמך המדדים החודשיים שנקלטים. עם זאת, אתם יכולים ליצור התראה לגבי העלויות שלכם ב-Cloud Monitoring. מידע נוסף זמין במאמר בנושא הגדרת התראות על חיוב.
מעקב אחר טווחים של נתוני מעקב שהוטמעו מדי חודש
כדי ליצור מדיניות התראות שמופעלת כשטווח הזמן של Cloud Trace החודשי שלכם חורג ממגבלה שהוגדרה על ידי המשתמש, צריך להשתמש בהגדרות הבאות.
| תנאי חדש שדה |
ערך |
|---|---|
| משאב ומדד | בתפריט Resources (משאבים), בוחרים באפשרות Global (גלובלי). בתפריט Metric categories בוחרים באפשרות Billing. בתפריט Metrics, בוחרים באפשרות Monthly trace spans ingested. |
| מסנן | |
| בסדרות של נתונים על ציר הזמן צבירה של נתונים על ציר הזמן |
sum |
| חלון מתגלגל | 60 m |
| פונקציה אנליטית (חלון נע) | max |
| הגדרת טריגר להתראה שדה |
ערך |
|---|---|
| סוג התנאי | Threshold |
| טריגר להתראה | Any time series violates |
| מיקום הסף | 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% מהתקציב. לתיעוד מלא, אפשר לעיין במאמר בנושא הגדרת תקציבים והתראות תקציב.