סקירה כללית של מדדי הטמעה

נתמך ב:

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

למה חשוב להשתמש במדדי הטמעה

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

איפה אפשר לגשת למדדי ההטמעה

  • Google Cloud Monitoring:

    • שילוב של מדדי Google SecOps ב-Cloud Monitoring, שמאפשר ליצור לוחות בקרה ולהגדיר מדיניות התראות על סמך ערכי סף של מדדים כמו מספר היומנים שנוספו, הגדלים שלהם ואירועי נרמול.
    • המדדים זמינים עם קידומות כמו Chronicle Collector ו-Chronicle Log Type.
    • מקור מידע: שימוש ב-Cloud Monitoring כדי לקבל תובנות לגבי הטמעת נתונים

  • ‫Google SecOps Health Hub:

    • ב-Health Hub יש תצוגה מרוכזת בפלטפורמת Google SecOps שמאפשרת לעקוב אחרי הסטטוס של מקור הנתונים, נפחי הטמעת הנתונים ותקינות הניתוח. הוא מדגיש שגיאות ומספק קישורים למידע נוסף.
    • מקור: שימוש במרכז הבריאות

  • BigQuery Export:

קטגוריות ושדות של מדדים מרכזיים

המדדים של ההטמעה מחולקים לרכיבים שונים של צינור ההטמעה (לדוגמה, Forwarder, ‏ Ingestion API, ‏ Normalizer, ‏ Feeds). הנה כמה שדות חשובים שתיתקלו בהם:

  • מדדי נפח:

    • ‫log_count: מספר הרשומות ביומן הגולמי שהתקבלו או עובדו.
    • ‫log_volume: הגודל הכולל של היומנים שהתקבלו או עובדו (בבייטים).
    • ‫event_count: מספר אירועי ה-UDM שנוצרו אחרי הניתוח.

  • מדדי נרמול:

    • ‫state: התוצאה של תהליך הנרמול של היומנים (לדוגמה, parsed, ‏ failed_parsing, ‏ failed_validation).
    • ‫total_events: מספר אירועי ה-UDM שאומתו בהצלחה.
    • ‫total_error_events: מספר האירועים שהניתוח או האימות שלהם נכשלו.
    • ‫drop_reason_code: הסיבה לכך שיומן או אירוע הושמטו.

  • בריאות וביצועים:

    • ‫last_heartbeat_time: מציין את הפעם האחרונה שבה המאגר או הפיד היו פעילים.
    • ‫drop_count: מספר היומנים שהושמטו על ידי רכיב.
    • ‫cpu_used, ‏ memory_used, ‏ disk_used: ניצול המשאבים של רכיבים מקומיים כמו Bindplane Agent או Forwarder מדור קודם.
    • ‫latency_count: מדדים שקשורים לזמן שחלף בין הטמעת הנתונים לבין הנורמליזציה.

  • מדדי מכסה (Ingestion API):

    • ‫quota_rejected_long_term_log_volume: נפח היומנים שנדחו בגלל חריגה ממגבלות המכסה.

הסבר על מאפיינים

בדרך כלל המדדים מפורטים לפי מאפיינים, כך שאפשר לסנן ולקבץ את הנתונים:

  • ‫component: החלק בצינור ההזנה שאליו מתייחס המדד (לדוגמה, Forwarder, ‏ Ingestion API, ‏ Normalizer,‏ Out-of-Band Processor).
  • ‫log_type: סוג מקור היומן (לדוגמה, WINDOWS_DNS, CS_EDR).
  • ‫collector_id / feed_id: מזהה ייחודי של המכונה הספציפית של ה-collector או של פיד הנתונים.
  • ‫namespace: משמש לארגון יומנים, לרוב בייבוא נתונים מ-API.

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

הבדלים בין נפח היומן הגולמי לבין נפח היומן בלוח הבקרה

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

ההבדלים האלה נובעים מהסיבות הבאות:

  • טווחי תאריכים שונים ומגבלות שונות על תקופת המבט לאחור:

    • אחסון יומנים גולמיים: הנתונים נשמרים בהתאם למדיניות שמירת הנתונים שהגדרתם במכונה. יכול להיות שהמכונה שלכם הטמיעה יומנים במשך כמה שנים מאז שהוקצתה.
    • מרכזי הבקרה של Google SecOps: מחשבים את ingestion.log_volume רק בטווח התאריכים שנבחר, עד למגבלת מבט לאחור של 365 ימים (או עד 24 חודשים ב-Cloud Monitoring למכונות של Bring Your Own Project (BYOP)). אם המכונה שלכם הטמיעה נתונים במשך יותר מ-365 ימים, שאילתות בלוח הבקרה מדווחות על סכום נמוך יותר מנפח ההטמעה ההיסטורי המצטבר.

  • מקורות נתונים שונים וצינורות עיבוד נתונים שונים לאיסוף נתונים:

    • אחסון יומנים גולמיים: מתעד את הגודל הישיר בבייטים של קבוצות יומנים גולמיים שנטמעו ומאוחסנים ב-Google SecOps.
    • מרכזי הבקרה של Google SecOps: שאילתה על ingestion.log_volume מהטבלה ingestion_metrics, שאוספת נתוני טלמטריה באופן אסינכרוני במרווחים של כ-5 דקות. בצינור עיבוד הנתונים הזה של הטלמטריה יכולים להיות עיכובים באיסוף, דגימה או ירידות זמניות במדדים, ולכן השאילתות בלוח הבקרה מספקות נפח משוער ולא ספירת בייטים מדויקת.

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

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

  • לוחות בקרה של Google SecOps (עד 365 ימים):

    • איפה מחשבים: פותחים את Dashboards & Reports (מרכזי בקרה ודוחות) > Dashboards (מרכזי בקרה), ואז מעיינים בווידג'ט Throughput (תפוקה) במרכז הבקרה Main (ראשי) או Data Ingestion and Health (הטמעת נתונים ותקינות) (כולל התרשים Ingestion - Throughput (All-Time) (הטמעה – תפוקה (כל הזמנים)). אפשר גם להריץ שאילתה מותאמת אישית בלוח הבקרה של sum($event.ingestion.log_volume), עם סינון לפי $event.ingestion.component = "Ingestion API".
    • טווח תאריכים מקסימלי: השאילתות מוגבלות ל-365 ימים לכל היותר, גם בתרשים הטמעת נתונים – תפוקה (מאז ומעולם) שנבחר.
    • ההבדלים בין הערכים: מרכזי הבקרה שולחים שאילתות לטבלה האסינכרונית ingestion_metrics, שאוספת נתוני טלמטריה במרווחים של כ-5 דקות. יכול להיות שיהיה עיכוב באיסוף הנתונים או ירידה זמנית במדדים. הערכים הם משוערים ומשקפים רק את היומנים שנקלטו דרך Ingestion API במהלך טווח התאריכים שנבחר, ולא את כל הבייטים של היומנים הגולמיים או את הנפח הסופי לחיוב.

  • כלי Metrics Explorer של Cloud Monitoring (עד 24 חודשים למופעי BYOP):

    • איפה מחשבים: פותחים את Monitoring > Metrics explorer במסוף Google Cloud , ואז מריצים שאילתה עבור chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"} (הוראות מפורטות זמינות במאמר איך רואים את נפח ההטמעה שחויב).
    • טווח תאריכים מקסימלי: השאילתות מוגבלות ל-24 חודשים לכל היותר, בהתאם לשמירת המדדים ב-Cloud Monitoring.
    • ההבדלים בין הערכים: המערכת של Cloud Monitoring אוספת את מספר הבייטים של נתוני ההטמעה ברמת האוסף בחלון הזמן שבחרתם. הערכים מתייחסים לחלון מבט לאחור ארוך יותר בהשוואה ללוחות הבקרה של Google SecOps (עד 24 חודשים במקום 365 ימים), אבל הם לא משקפים את הסכום הכולל אם המופע שלכם ישן יותר מ-24 חודשים.

  • ייצוא ל-BigQuery (מעבר ל-365 ימים, בהתאם לשמירת מערך הנתונים):

    • איפה מבצעים את החישוב: פותחים את פרויקט BigQuery אחרי ייצוא הטבלה ingestion_metrics, ואז מריצים שאילתה לחישוב SUM(log_volume) (או total_size_bytes ב-Looker וב-BigQuery) עם סינון לפי component = "Ingestion API".
    • טווח תאריכים מקסימלי: השאילתות מוגבלות לתקופת השמירה שהוגדרה לטבלה ב-BigQuery מהרגע שהפעלתם את הייצוא, ולא למגבלה של 365 ימים במרכז הבקרה.
    • ההבדלים בין הערכים: BigQuery שולח שאילתות לאותה טבלה אסינכרונית של ingestion_metrics כמו מרכזי הבקרה של Google SecOps. הערכים תואמים לשאילתות בלוח הבקרה עבור אותו טווח תאריכים, אבל הם נשארים אינדיקטורים משוערים של טלמטריה ולא בייטים של יומנים גולמיים או נפח סופי לחיוב.

שימוש במדדי הטמעה

  • פתרון בעיות: כדי למצוא בעיות בניתוח, אפשר לסנן לפי log_type ו-state (לדוגמה, failed_parsing) במדדי הנורמליזציה. בודקים את drop_count ואת drop_reason_code כדי לראות אם יש אובדן נתונים.

  • התראות: הגדירו התראות ב-Cloud Monitoring כדי לעקוב אחרי ירידות פתאומיות ב-log_count במקורות יומנים קריטיים, או אחרי שיעורים גבוהים של total_error_events. כדי לעקוב אחרי נפח ההטמעה היומי בהשוואה למגבלות החוזיות, השתמשו במדד Total ingested log size ‏(chronicle.googleapis.com/ingestion/log/bytes_count). אל תשתמשו במדד chronicle.googleapis.com/ingestion/quota_limit להתראות על נפח יומי, מהסיבות הבאות:

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

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

  • תכנון קיבולת: ניתוח מגמות של log_volume ב-BigQuery כדי לחזות צרכים עתידיים.

  • אימות ההגדרות: אחרי שמגדירים מקור נתונים חדש, בודקים את המדדים כדי לוודא שהנתונים זורמים ומנותחים כמו שצריך.

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

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