מכסות ומגבלות ב-Cloud Monitoring

במאמר הזה מוסבר על מכסות ומגבלות המערכת של Cloud Monitoring.

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

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

מערכת המכסות ב-Cloud:

• עוקבת אחרי השימוש במוצרים ובשירותים של Google Cloud
• מגבילה את השימוש במשאבים האלה
• כוללת כלי שבאמצעותו אפשר לשלוח בקשות לשינוי המכסות ולשנות אותן אוטומטית

ברוב המקרים, כשאתם מנסים להשתמש ביותר משאבים מהמכסה, הגישה למשאב נחסמת ומה שאתם מנסים לעשות נכשל.

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

לסקירה כללית על מכסות ב-Cloud

כדי לשנות את רוב המכסות, משתמשים במסוף Google Cloud . איך שולחים בקשה לשינוי המכסות

למשאבי Monitoring יש גם מגבלות מערכת. שאי אפשר לשנות.

מדדים בהגדרת המשתמש

בדף Metrics Management ב-Cloud Monitoring מופיע מידע שיכול לעזור לכם לשלוט בסכום שאתם מוציאים על מדדים לחיוב, בלי להשפיע על יכולת התצפית. בדף Metrics Management מוצג המידע הבא:

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

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

קטגוריה	ערך מקסימלי
תיאורי מדדים בהתאמה אישית לכל פרויקט^1	10,000
תוויות לכל תיאור מדד מותאם אישית, חיצוני ולעומס עבודה	30
תוויות לכל תיאור מדד של Prometheus	200
אורך המחרוזת של מפתח התווית	100
אורך המחרוזת של ערך התווית	1024
סדרות זמן שנכללות בבקשת כתיבה^2	200
הקצב שבו אפשר לכתוב נתונים לסדרת זמן אחת^3	נקודה אחת כל 5 שניות
קטגוריות של היסטוגרמה לכל מדד התפלגות בהתאמה אישית	200
תיאורי מדדים של עומס עבודה, Prometheus וחיצוניים^4 לכל פרויקט	25,000
סדרות זמנים פעילות ממדדים מותאמים אישית לכל משאב במעקב^5	200,000
סדרות זמנים פעילות ממדדי עומס עבודה לכל משאב במעקב^5	200,000
סדרות של נתונים פעילות מ-Prometheus לכל משאב במעקב^5	1,000,000
סדרות פעולות פעילות על ציר הזמן ממדדים חיצוניים לכל משאב במעקב^5	200,000
הקצב שבו אפשר ליצור תיאורי מדדים	‫6,000 לדקה לכל פרויקט

¹ המגבלה הזו נקבעת על ידי Cloud Monitoring. בשירותים אחרים יכול להיות שערכי המקסימום יהיו נמוכים יותר. מדדים מותאמים אישית הם מדדים שנכתבים ב-custom.googleapis.com.
² אפשר לכתוב רק נקודת נתונים אחת לכל סדרה עתית בבקשה, כך שהמגבלה הזו פועלת גם כמספר המקסימלי של נקודות שאפשר לכתוב לכל בקשה.
³ ב-Cloud Monitoring API, זמני הסיום של הנקודות שנכתבות בסדרה עתית צריכים להיות בהפרש של 5 שניות לפחות. אפשר לכתוב נקודות על הגרף בסדרות זמן באצווה, בתנאי שהנקודות על הגרף נכתבות לפי הסדר.
^‫4 מדדים חיצוניים הם מדדים שנכתבים ב-external.googleapis.com.
⁵ סדרת זמנים נחשבת פעילה אם כתבתם בה נקודות על הגרף ב-24 השעות האחרונות. המגבלה שמצוינת בשורה היא המספר הכולל של סדרות הזמן הפעילות למשאב יחיד במעקב (לדוגמה, מכונה וירטואלית אחת של gce_instance או קונטיינר אחד של k8s_container) בכל המדדים שמוגדרים על ידי המשתמש באותה שורה (מדדים בהתאמה אישית, מדדי עומס עבודה, מדדי Prometheus או מדדים חיצוניים). החריג היחיד הוא המשאב במעקב global, שבו המגבלה חלה על כל מדד שמוגדר על ידי המשתמש בנפרד. זוהי מגבלת בטיחות שחלה על כל המערכת ואי אפשר להתאים אותה אישית.

מעקב אחרי המכסות והמגבלות של ה-API

קטגוריה	ערך מקסימלי
מגבלות על השימוש ב-API	כדי למצוא את המכסות והמגבלות של ה-API, אתם יכולים לבצע אחת מהפעולות הבאות: נכנסים לדף Quotas dashboard במסוף Google Cloud . ב-Cloud Shell, מריצים את הפקודה gcloud alpha services quota list.
משך החיים של אסימוני דפים ב-API	24 שעות
גודל התשובה המקסימלי	200 MB ההגבלה חלה על הגודל של המטען הייעודי (payload) של התגובה שעברה סריאליזציה, שכולל גם את הנתונים הגולמיים וגם את המפתחות והערכים של התוויות לכל סדרת נתונים שמוחזרת. אם התגובה לשאילתה גדולה מ-200MB, הבקשה נכשלת ומוצגת השגיאה RESOURCE_EXHAUSTED (HTTP 429 Too Many Requests). כדי למנוע או לפתור שגיאות מסוג RESOURCE_EXHAUSTED, צריך לבצע את הפעולות הבאות: צריך להקטין את עוצמת המדדים או להחיל מסננים כדי להקטין את מספר הסדרות של הזמן. להגדיל את תקופת ההתאמה. מקצרים את טווח התאריכים של השאילתה. אם אתם משתמשים ב-PromQL, כדאי להטמיע כללי שמירה.

מידע על מכסות ב-Monitoring API

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

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

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

המגבלות האחרות קבועות ומתוארות במסמך הזה.

מידע נוסף זמין במאמרי העזרה בנושא מכסות ב-Cloud.

מכסות ומגבלות של Telemetry API להטמעת מדדים

בקטע הזה מתוארות המכסות והמגבלות שחלות על Telemetry (OTLP) API כשמשתמשים בו להטמעת מדדים. ‫Telemetry API מטמיע את מפרט OpenTelemetry OTLP.

תיאור	ערך	נתונים
מספר נקודות הנתונים המקסימלי לכל בקשה	200	הגבלה
המספר המקסימלי של ResourceMetrics לכל בקשה	200	הגבלה
המספר המקסימלי של קוונטילים לכל מדד סיכום	10	הגבלה
מספר הבקשות להטמעת מדדים לדקה לכל אזור (מכסה)	60,000	מכסה

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

שמירת נתונים

נקודות על הגרף של מדדים שחורגות מתקופת השמירה נמחקות מסדרת הזמן.

קטגוריה	ערך
שמירת נקודות על הגרף מסוגי מדדים מותאמים אישית, חיצוניים ושל סוכנים, כולל: מדדים מותאמים אישית, קידומת custom.googleapis.com מדדים מהשירות המנוהל של Google Cloud ל-Prometheus וממייצא ה-OTLP של OpenTelemetry, קידומת prometheus.googleapis.com^2 ‫Agent metrics, הקידומת agent.googleapis.com, כולל כל המדדים של processes. מדדים חיצוניים, קידומת external.googleapis.com מדדים אחרים של עומסי עבודה שנשלחים על ידי מייצאים של OpenTelemetry שאינם OTLP, קידומת workload.googleapis.com	‫24 חודשים^1
שמירה של נקודות על הגרף בשירותי Google Cloud מסוימים, כולל רוב המדדים בקטגוריות הבאות: מדדי Compute Engine, קידומת compute.googleapis.com מדדי GKE ו-GKE Enterprise, קידומת kubernetes.io מדדי Cloud Storage, קידומת storage.googleapis.com מדדי BigQuery, קידומת bigquery.googleapis.com מדדי Cloud SQL, קידומת cloudsql.googleapis.com מדדים של מאזני עומסים פנימיים, מסוג HTTPS ומסוג L7, קידומת loadbalancing.googleapis.com	‫24 חודשים^1
שמירת נקודות על הגרף מכל סוגי המדדים האחרים, כולל: כל Google Cloud המדדים האחרים מדדי Istio מדדי AWS מדדים מבוססי-יומנים	6 שבועות
משך החיים של אסימוני דפים ב-API	24 שעות

‫¹ נתוני המדדים נשמרים למשך 6 שבועות בתדירות הדגימה המקורית שלהם, ואז הם נדגמים בתדירות נמוכה יותר למרווחים של 10 דקות לאחסון מורחב.
^‫2 נתוני המדדים של השירות המנוהל של Google Cloud ל-Prometheus ול-OTLP נשמרים למשך שבוע בתדירות הדגימה המקורית שלהם, ואז הם נדגמים בתדירות נמוכה יותר למרווחים של דקה אחת למשך 5 השבועות הבאים, ואז הם נדגמים בתדירות נמוכה יותר למרווחים של 10 דקות לאחסון מורחב.

קבוצות משאבים

קטגוריה	ערך
מספר קבוצות המשאבים בכל היקף מדדים בפרויקט	500
מספר הקבוצות המקסימלי שאפשר לכלול בדוח שנשלח באימייל^1	10

¹ כשמגדירים דוחות באימייל ב-Cloud Monitoring, אפשר לבקש מידע על השימוש בקבוצות המשאבים. בגלל מגבלה בכלי לדיווח באימייל, הדוחות שנוצרים כוללים מידע על 10 קבוצות בלבד.

מגבלות הפרויקטים במעקב

ב-Cloud Monitoring יש תמיכה רשמית בעד 375 פרויקטים ב- Google Cloud לכל היקף מדדים .

אפשר להוסיף עד 3,500 Google Cloud פרויקטים לכל היקף מדדים בפרויקט, אבל יכול להיות שתיתקלו בבעיות בביצועים, במיוחד כששולחים שאילתות לגבי מדדים בהתאמה אישית או נתונים היסטוריים. ב-Cloud Monitoring, אפשר להריץ שאילתות ותרשימים עם ביצועים טובים רק ל-375 Google Cloud פרויקטים לכל היקף מדדים בפרויקט .

כדי להגדיל את המכסה של Google Cloud פרויקטים לכל היקף מדדים, אתם יכולים לבקש להגדיל את המכסה של "פרויקטים במעקב / היקף המדדים בפרויקט". לפרטים נוספים, קראו את המאמר ניהול המכסה.

מגבלות על יצירה ועדכון של תיאורי מדדים

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

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

מגבלות על התראות

בשתי העמודות הראשונות בטבלה הבאה מפורטים קטגוריה וערך מגבלה. בעמודה השלישית מפורטים סוגי המדיניות שהמגבלה חלה עליהם:

• מדד: חל על כללי מדיניות התראה שעוקבים אחרי נתוני מדדים, כולל מדדים מבוססי-יומנים.
• LBA: חלה על כללי מדיניות התראה שעוקבים אחרי רשומות ביומן. כללי המדיניות האלה נקראים כללי מדיניות להתראות מבוססות-יומנים.
• ‫SQL: חל על מדיניות התראות שעוקבות אחרי תוצאה של שאילתת SQL.
• ‫All: חל על כל מדיניות ההתראות.

קטגוריה	ערך	סוג המדיניות
כללי מדיניות התראות (סכום של מדדים ויומנים) לכל היקף מדדים בפרויקט ^1	2,000	מדד, LBA
תנאים לכל מדיניות התראות שמבוססת על מדדים	6	מדד
תנאים לכל מדיניות התראה מבוססת-SQL (Public Preview)	1	SQL
זמן הביצוע המקסימלי של שאילתה ב מדיניות התראות שמבוססת על SQL (גרסת טרום-השקה ציבורית)	5 דקות	SQL
התקופה המקסימלית שבה מוערך תנאי של היעדר מדד^2	יום אחד	מדד
התקופה המקסימלית שבה תנאי סף של מדד נבדק^2	‫25 שעות	מדד
תקופת הזמן המקסימלית שבה מתבצעת הערכה של תנאי PromQL	שנתיים	מדד
האורך המקסימלי של המסנן שמשמש בתנאי של סף מדד	‫2,048 תווי Unicode	מדד
מספר מקסימלי של סדרות זמן שמנוטרות על ידי תנאי חיזוי	64	מדד
חלון התחזית המינימלי	שעה אחת (3,600 שניות)	מדד
חלון התחזית המקסימלי	‫2.5 ימים (216,000 שניות)	מדד
ערוצי התראות לכל מדיניות התראה	16	הכול
מספר מקסימלי של התראות חדשות לכל מדיניות התראות מבוססת-יומן	‫20 התראות ביום	LBA
מספר ההתראות המקסימלי^3 לכל מדיניות התראות מבוססת-יומנים	‫20 התראות ביום	LBA
הקצב המקסימלי של התראות חדשות לכל מדיניות התראות מבוססת-יומנים	2 התראות חדשות בדקה	LBA
מרווח הזמן המינימלי בין התראות על התראה פתוחה^4 לכל מדיניות התראות מבוססת-יומן	5 דקות	LBA
המספר המקסימלי של כללי מדיניות התראה שמופעלים בו-זמנית בכל פרויקט	80,000	הכול
המספר המקסימלי של התראות פתוחות בו-זמנית לכל מדיניות התראות	1,000	הכול
התקופה שאחריה התראה ללא נתונים חדשים נסגרת באופן אוטומטי	7 ימים	מדד, SQL
משך הזמן המקסימלי של התראה אם היא לא נסגרת באופן ידני	7 ימים	LBA
שמירת התראות שנסגרו	‫13 חודשים	לא רלוונטי
שמירת התראות פתוחות	ללא הגבלת זמן	לא רלוונטי
ערוצי התראות לכל היקף מדדים בפרויקט	4,000	לא רלוונטי
המספר המקסימלי של כללי מדיניות התראות לכל הפעלה של "התראה חוזרת"	16	הכול
שמירה של התראה במצב נודניק	‫13 חודשים	לא רלוונטי

‫¹ אפשר לבקש להגדיל את המגבלה הזו מברירת המחדל של 2,000 כללי מדיניות לכל היקף מדדים בפרויקט, עד ל-10,000 כללי מדיניות לכל היקף מדדים בפרויקט.
^‫2 פרק הזמן המקסימלי שבו התנאי נבדק הוא הסכום של ערכי תקופת ההתאמה וחלון משך הזמן. לדוגמה, אם תקופת ההתאמה מוגדרת ל-15 שעות וחלון משך הזמן מוגדר ל-15 שעות, נדרשים נתונים של 30 שעות כדי להעריך את התנאי.
³מערכת Monitoring יוצרת התראות להתראה פתוחה כשחולף הזמן המינימלי בין ההתראות, ורשומה ביומן תואמת לתוויות ההתראה. אם מדיניות התראה מבוססת-יומנים נמצאת במצב "התראה" כש-Monitoring יוצר התראה, ההתראה נמחקת ולא נשלחת לערוצי ההתראות של המדיניות. אחרת, ההתראה תישלח לערוצי ההתראות של מדיניות ההתראות. כל ההתראות שנוצרות ב-Monitoring נספרות במגבלה של מדיניות ההתראות, שהיא 20 התראות ביום.
^‫4 אם השאילתה של מדיניות ההתראות שמבוססת על יומנים מחלצת תוויות, כל שילוב של ערכי תוויות שחולצו מייצג ציר זמן משלו להתראות. לכן, יכול להיות שתקבלו כמה התראות תוך 5 דקות.

מגבלות על הודעות SMS

המגבלות על הודעות SMS חלות על חלון זמן דינמי של 24 שעות.

קטגוריה	ערך
מספר קודי האימות ב-SMS	40
מספר קודי האימות ב-SMS לכל מספר טלפון	5
מספר הודעות ההתראה ב-SMS	2,500
מספר הודעות ההתראה ב-SMS לכל מספר טלפון	200

מגבלות על צגים סינתטיים

קטגוריה	ערך
בדיקות זמני פעילות לכל היקף מדדים בפרויקט ^*	100
מספר מקסימלי של פינגים של ICMP לכל בדיקת זמינות ציבורית	3
מסכים סינתטיים לכל היקף מדדים בפרויקט	100^†

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

מגבלות על תרשימים

קטגוריה	ערך
מרכזי בקרה לכל היקף מדדים בפרויקט	1000
תרשימים במרכז בקרה	100
שמירת היסטוריית הגרסאות של מרכז הבקרה	90 ימים
קווים בתרשים	50^*
שורות בטבלה	300
מספר מקסימלי של כללי מדיניות התראות לכל ווידג'ט Alerts	20
מספר המשאבים המקסימלי לכל ווידג'ט התראות	20
מספר התווים המקסימלי בשאילתה של ווידג'ט בחלונית היומנים	2,000

^*המגבלה הזו חלה מסיבות שקשורות לביצועים. אם יש יותר מ-50 סדרות זמנים להצגה בתרשים, סמל עם נקודה אדומה נוסף לסרגל הכלים. בהסבר הקצר של הסמל מוצגת ההודעה To improve performance, we've limited the time series displayed in this chart. כדי להציג את כל סדרות הזמנים, מרחיבים את ההסבר הקצר ולוחצים על הכפתור Show All Time Series.

יעדים למדידת רמת השירות (SLO)

קטגוריה	ערך
מספר יעדי ה-SLO לכל שירות	500

מגבלות על תגים

קטגוריה	ערך
המספר המקסימלי של צוותים בכל פרויקט כשמשתמשים בתגים לבקרת גישה	250