הסבר על מכסות ומגבלות על שימוש חורג

נתמך ב:

במסמך הזה מתוארות המכסות והמגבלות על שימוש ב-Google Security Operations.

הגדרה של מגבלות על פרצי תנועה

מגבלות על פרצי תעבורה הן סוג של מגבלות על שירותים ב-Google SecOps שפועלות כמו מגבלות מהירות על הטמעת נתונים. הן נועדו להגן על התשתית המשותפת של הפלטפורמה מפני עליות פתאומיות ומשמעותיות בתעבורה. מגבלת פרץ מגבילה את קצב ההטמעה (שנמדד במגה-בייט לשנייה – MBps, או בגיגה-בייט לשנייה – GBps) בחלון זמן מתגלגל של חמש דקות.

איך מחושבות מגבלות השימוש

מערכת Google SecOps מקצה מכסות שימוש זמניות לדיירים ב-Google SecOps על סמך נפח הנתונים השנתי שרכשתם (הקיבולת שנרכשה) בהתאם לרישיון שלכם ל-Google SecOps.

כדי להתמודד עם שינויים צפויים ועם עליות לא מתוכננות בנפח התנועה של היומנים, מגדירים את מגבלת השימוש היומית כטווח ספציפי, שמאפשר לכם להשתמש בנפח שגדול פי אחד עד פי שלושה (1x עד 3x) מהממוצע היומי הצפוי (שמחושב כקיבולת השנתית שרכשתם חלקי 365 ימים). הקצבה הגמישה הזו נועדה לספוג עליות חדות רגילות בהעלאת נתונים בלי לשבש את הפעולות שלכם. לדוגמה, אם רכשתם נפח אחסון שנתי של 365 TB, הממוצע היומי הצפוי הוא 1 TB. המגבלה הזמנית שהוקצתה לכם תהיה בין 1TB ל-3TB ליום (שמתורגמת לטווח של כ-12MBps עד 36MBps). אם קצב העיבוד של הנתונים שלכם חורג באופן עקבי מהטווח הזה של פי 1 עד פי 3, תצטרכו להגדיל את הקיבולת השנתית שרכשתם.

מגבלות על פרצי תנועה נאכפות לכל דייר של לקוח Google SecOps.

בטבלה הבאה מוצגות מגבלות השימוש בהתאם לכמויות שונות של נפח אחסון שנרכש:

דוגמה לקיבולת שנרכשה טווח מגבלת פרץ מגבלת שימוש של 5 דקות העברה בכמות המקסימלית של נתונים (שעתית) הטמעה בהגבלה המקסימלית של פרץ (יומי) הטמעה בהגבלה המקסימלית של פרץ (שנתית)
‫100 TB ‫3 עד 10 MBps ‫0.9 עד 3 GB ‫~34 GB ‫~822 GB ‫300 TB
‫500 TB ‫16 עד 48 MBps ‫4.8 עד 14.4 GB ‫~171 GB ‫~4 TB ‫1.5 PB
‫1 PB ‫32 עד 97 מגה-בייט לשנייה ‫9.6 – 29 GB ‫~343 GB ‫~8 TB ‫3 PB
‫5 PB ‫158 עד 476 מגה-בייט לשנייה ‫47.4 עד 143 GB ‫~1.7 TB ‫~41 TB ‫15 PB
‫30 PB ‫0.96 עד 2.86 GBps ‫288 עד 858 GB ‫~10.3 TB ‫~247 TB ‫90 PB

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

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

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

החלת מגבלות על פידים מבוססי-משיכה

ב-Google SecOps יש גם מגבלה על הטמעה מבוססת-משיכה, והיא שליש (33%) ממגבלת ההעלאה הכוללת לכל סוג יומן (בכל הפידים). המגבלה הזו נועדה להבטיח שהטמעה מבוססת-משיכה (בדרך כלל ממקורות בענן) לא תמצה את מגבלות ההעברה הכוללות של הדייר, ולא תפגע בהטמעת נתונים באמצעות שיטות מבוססות-דחיפה (כמו שימוש בסוכני Bindplane, במעבירים או בהטמעה ישירה ב-Google SecOps APIs).

שיטות להעברה מבוססת-משיכה

שיטות מבוססות-משיכה כוללות שיטות להטמעת נתונים (שנקראות סוגי מקורות ב-Google SecOps) שבהן Google SecOps פונה באופן פעיל לממשק ה-API של המקור כדי לאחזר נתונים. זה כולל את סוגי המקורות הבאים שנתמכים ב-Google SecOps:

  • ממשקי API של צד שלישי
  • Azure Event Hub
  • הטמעה ישירה מ-Google Workspace ו Google Cloud
  • Cloud Storage
  • פיד Cloud Storage (מבוסס-אירועים)
  • Amazon S3
  • Amazon SQS
  • Azure Blobstore
  • בקשת SFTP
  • בקשת HTTP

לדוגמה, אם מגבלת הנתונים הזמנית לדייר מוגדרת ל-150 MBps, והדייר קולט יומני הקשר של משתמשי Okta באמצעות מחבר API של צד שלישי (כלומר, שיטת קליטה מבוססת-משיכה), המערכת מגבילה את קצב הקליטה של כל פידים של Okta יחד למקסימום של [150/3 =] 50 MBps. המגבלה הנוספת הזו חלה גם אם קצב הכנסת הנתונים הכולל שלכם נמצא בתוך מגבלת ההעברה המהירה שהוקצתה לכם.

חריגים למגבלות ברמת logtype לשיטות הטמעה מבוססות-משיכה

למרות שמגבלות ברמת logtype חלות בדרך כלל על פידים מבוססי-משיכה, יש כמה יוצאים מן הכלל:

  • וווב-הוקים של HTTPS: זו שיטה שמבוססת על דחיפת הודעות עם מגבלות ברמת סוג היומן.
  • ‫Azure Event Hub: זו שיטה מבוססת-משיכה ללא מגבלות ברמת logtype.

איך מיושמות מגבלות על שימוש חריג

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

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

מה קורה לנתונים אם חורגים ממגבלות השימוש

אם חורגים ממגבלת העומס, Google SecOps מפסיק את ההטמעה של נתונים נוספים, והמנגנונים הבאים מופעלים – בהתאם לשאלה אם הנתונים מוטמעים באמצעות שיטות מבוססות-משיכה או מבוססות-דחיפה:

  • שימוש בשיטות מבוססות-משיכה: ההטמעה נשמרת באופן אוטומטי במאגר זמני ולא דורשת הגדרה נוספת מצד הלקוח. הנתונים יישארו מאוחסנים באחסון הזמני עד שהמגבלה תתאפס ו-Google SecOps יחדש את הטמעת הנתונים.
  • שימוש בשיטות מבוססות-push: Google SecOps דוחה באופן זמני את הטמעת הנתונים עם השגיאה HTTP 429 Too Many Requests (יותר מדי בקשות). האות הזה גורם למנגנון ההטמעה להשהות, לשמור בזיכרון ולנסות שוב, כדי שלא יאבדו נתונים.

כשמשתמשים בשיטות להעברה מבוססת-push, האחריות על שמירת הנתונים במאגר זמני ועל ניסיון חוזר להעברה מוטלת על הלקוח (ראו אחריות הלקוח לשמירת נתונים במאגר זמני ולניסיון חוזר להעברה).

דחיות של בקשות בגלל חריגה ממגבלת הבקשות לא נחשבות לאובדן נתונים

חשוב להבין שדחיות בגלל חריגה ממגבלת פרץ (HTTP 429) לא נחשבות לאירועים של אובדן נתונים. דחייה בגלל חריגה ממגבלת נפח (שגיאת HTTP 429) היא השהיה בהעברת הנתונים.

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

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

האחריות של הלקוחות לגבי אחסון זמני של נתונים וניסיון חוזר

למרות ש-Google SecOps מנהל באופן אוטומטי את הנתונים שנשמרים בזיכרון הזמני ואת הניסיונות החוזרים של נתונים שמועברים באמצעות שיטות העברה מבוססות-משיכה, אתם אחראים לנתונים שנשמרים בזיכרון הזמני ולניסיונות החוזרים של העברת נתונים באמצעות שיטות העברה מבוססות-דחיפה (כמו ווּבּהוּקים של HTTPS,‏ Bindplane,‏ forwarders או Cribl).

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

בטבלה הבאה מפורטים ההבדלים העיקריים באופן שבו Google SecOps מטפל בהעברת נתונים כשמגיעים למגבלת ההעברה המהירה בשני סוגי שיטות ההעברה:

תכונה העברה מבוססת-משיכה העברה מבוססת-דחיפה
איך זה עובד ‫Google SecOps פונה באופן פעיל אל ה-API של המקור כדי לאחזר נתונים. המערכות שלכם יוזמות את החיבור ושולחות נתונים ל-Google.
אחריות על אחסון נתונים במאגר זמני וניסיון חוזר ‫Google SecOps מנהל את האגירה באופן אוטומטי. כשמגיעים למגבלת ההעלאה, Google SecOps מפסיק את ההעלאה של נתונים נוספים. הנתונים נשארים מאוחסנים באחסון הזמני עד שהמגבלה מתאפסת ו-Google SecOps מחדש את האחזור.
באחסון הזמני מאוחסנים נתונים למשך עד 90 יום בלבד, ולאחר מכן הנתונים נמחקים.		 הלקוח צריך לנהל את האגירה הזמנית. כש-Google SecOps משיב עם HTTP 429, מערכת השליחה צריכה לזהות את השגיאה הזו, לשמור את הנתונים בתור מקומי (בדיסק או בזיכרון) ולנסות לשלוח אותם שוב מאוחר יותר. אם השולח מוגדר ל'הסרה במקרה של כשל', הנתונים יאבדו.
סוגים של מקורות נתונים ‫API של צד שלישי, Azure Event Hub, הטמעה ישירה מ-Google Workspace ו- Google Cloud, Cloud Storage, פיד של Cloud Storage (מבוסס-אירועים), Amazon S3, ‏ Amazon SQS, ‏ Azure Blobstore, בקשת SFTP, בקשת HTTP. ‫Google SecOps forwarder, ‏ Bindplane agent, ‏ Pub/Sub, ‏ Amazon Kinesis Firehose, ‏ HTTPS webhook, ‏ direct to ingestion API.
פעולת משתמש צריך לבצע פעולות כדי להתאים את נפח הנתונים שמועברים למערכת לקיבולת שרכשתם. בנוסף, צריך לוודא שמקורות ההטמעה מוגדרים לשמירת נתונים, לגיבוי ולניסיון חוזר.
מידע נוסף זמין במאמר הגדרות של גיבוי וניסיון חוזר למערכות מבוססות-דחיפה.

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

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

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

כדי לברר מהי מגבלת ההיטים המקסימלית שמוקצית לדייר Google SecOps שלכם, מבצעים את הפעולות הבאות:

  1. במסוף Google SecOps, עוברים אל לוחות בקרה > הטמעה של נתונים ותקינות.
  2. בודקים את הגרף של מגבלת השימוש המקסימלית – מגבלת מכסת השימוש. בתרשים מוצגת המכסה שהוקצתה לכם (הקו האופקי) ביחס לקצב ההעברה בפועל.

מעקב אחרי התקרבות למגבלת השימוש או חריגה ממנה

אפשר לעקוב אחרי השימוש באמצעות לוחות הבקרה המובנים או באמצעות Cloud Monitoring.

שימוש בלוחות בקרה של Google SecOps כדי לעקוב אחרי התקרבות למגבלת השימוש או חריגה ממנה

  • עוברים אל לוחות בקרה > הזנת נתונים וסטטוס וצופים בנתונים הבאים:

    • תרשים קצב ההטמעה: מוצג בו קצב העברת הנתונים הנוכחי.
    • תרשים של דחיית פרץ: בתרשים הזה מוצג נפח היומנים שנדחו (שגיאות HTTP 429) בגלל חריגה ממגבלת הפרץ.

שימוש ב-Cloud Monitoring כדי לעקוב אחרי התקרבות למגבלת השימוש או חריגה ממנה

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

כמה מהמדדים הרלוונטיים הם:

  • נפח הנתונים שהועברו: chronicle.googleapis.com/ingestion/log/bytes_count
  • נפח שנדחה: `chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count

מדיניות התראות מוכנה לשימוש

‫Google SecOps מספק מדיניות התראות מוכנה לשימוש ב-Cloud Monitoring שאפשר להפעיל כדי לעקוב אחרי מכסת ההעברה.

כדי למצוא ולהפעיל את המדיניות הזו:

  1. במסוף Google Cloud , עוברים אל Monitoring (מעקב) > Integrations (שילובים).
  2. ברשימת השילובים, בוחרים באפשרות Chronicle Security.
  3. לוחצים על הכרטיסייה התראות.
  4. בודקים ומפעילים את מדיניות ההתראות לדוגמה הבאה:
    • מדיניות ההתראות 'מתקרבים למכסת ההטמעה': המדיניות הזו מזהה אם נפח הטמעת הנתונים מתקרב למכסה המקסימלית.
    • מדיניות התראות על דחיית מכסת העברה: המדיניות הזו מזהה אם בקשות להעברת נתונים נדחות בגלל מכסת העברה לא מספיקה (שגיאות HTTP 429).

דוגמאות

בקטעים הבאים יש דוגמאות לשאילתות PromQL לצורך מעקב והתראות.

צפייה בשימוש במגבלת השימוש הזמנית

  • כדי לראות את השימוש במכסת הנתונים הזמנית, משתמשים בשאילתת PromQL הבאה:

    100 * sum(rate(chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"}[10m]))/min(min_over_time(chronicle_googleapis_com:ingestion_quota_limit{monitored_resource="chronicle.googleapis.com/Collector"}[10m]))

הצגת מספר הבייטים שנדחו אחרי חריגה ממגבלת הנתונים

  • כדי לראות את מספר הבייטים שנדחו אחרי חריגה ממגבלת ה-Burst, משתמשים בשאילתת PromQL הבאה:

    topk(5, sum by ("collector_id","log_type")(rate({"__name__"="chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count","monitored_resource"="chronicle.googleapis.com/Collector","quota_type"="SHORT_TERM_DATA_RATE"}[${__interval}])))

הפעלת התראה כשמגיעים ל-70% ממגבלת השימוש המקסימלית

  • כדי להפעיל התראה כשמגיעים ל-70% ממגבלת השימוש המקסימלי, משתמשים בשאילתת PromQL הבאה:

    100 * topk(5, sum by ("collector_id","log_type")(rate({"__name__"="chronicle.googleapis.com/ingestion/log/quota_rejected_bytes_count","monitored_resource"="chronicle.googleapis.com/Collector","quota_type"="SHORT_TERM_DATA_RATE"}[${__interval}]))) > 70

מידע נוסף על הגדרת התראות על הטמעה זמין במאמר שימוש ב-Cloud Monitoring להטמעה לקבלת תובנות לגבי הטמעה.

טיפול בדחיות של מגבלות על פרצי תנועה שנגרמות משיטות מבוססות-דחיפה

אם אתם נתקלים בשגיאות דחייה (HTTP 429) בגלל שהגעתם למגבלת ההעברה המהירה של נתונים נכנסים באמצעות שיטות מבוססות-דחיפה, מומלץ לבצע את הפעולות הבאות:

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

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

תכנון קיבולת בהתאמה אישית לתפוקה גבוהה במיוחד

למרות כל מה שמתואר בסעיפים האחרים של המסמך הזה, קצב העברת נתונים (throughput) של יותר מ-3 GBps נחשב קצב העברת נתונים גבוה במיוחד. אם אתם מתכננים העברות נתונים בהיקף גדול, צופים תפוקה גבוהה במיוחד לאורך זמן או מפעילים ארכיטקטורות שמייצרות באופן עקבי פרצי קליטה גדולים, אתם צריכים לפנות לצוות ניהול החשבון שלכם כדי להקצות קיבולת בהתאמה אישית.

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

שאלות נפוצות

בקטעים הבאים ריכזנו תשובות לשאלות נפוצות.

האם אפשר להגדיל את מגבלת השימוש המקסימלית?

אם אתם צופים שהיקף הנתונים שמועברים יגדל באופן קבוע, אתם יכולים להגדיל את הקיבולת שרכשתם. לשם כך, עליכם לפנות לנציג המכירות של Google SecOps.

האם אפשר להגדיל את המגבלות ברמת סוג היומן עבור פידים מבוססי-משיכה?

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

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

האם אפשר לעקוב אחרי הנתונים שלא נאספו?

לא בשלב הזה.

מהן הדרכים האפשריות לנקות את הנתונים שהצטברו?

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

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

  • כדאי לבקש תמיכה טכנית של Google SecOps כדי לטפל בבעיות שמופיעות ב-backlog.

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

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

האם מגבלות על פרצי תנועה חלות גם על הטמעת נתונים בצינור לעיבוד נתונים?

מגבלות קצב ההטמעה שחלות על פידים של נתונים ששולחים נתוני יומנים גולמיים לצינור לעיבוד נתונים של Google SecOps מוגדרות להיות גבוהות יותר ממגבלת ההעברה המהירה של הדייר.

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

  • שימוש בשיטות מבוססות-משיכה: ההטמעה נשמרת באופן אוטומטי בזיכרון הזמני ולא נדרשת הגדרה נוספת.
  • שימוש בשיטות מבוססות-push: Google SecOps דוחה באופן זמני את הנתונים עם השגיאה HTTP 429 Too Many Requests (יותר מדי בקשות).

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

מה צריך לעשות אם מגבלת השימוש שלי נמוכה מהמגבלה שנקבעה בחוזה?

אם מגבלת השימוש המקסימלית שלכם נמוכה מהמגבלה שנקבעה בחוזה, פנו לתמיכה של Google (ראו תמיכה ב-Google SecOps) וציינו את מגבלת השימוש המקסימלית שאתם מצפים לה.

הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.