פריסת הסוכן של Bindplane לאיסוף נתונים

נתמך ב:

במאמר הזה מוסבר על Bindplane ל-Google Security Operations.

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

ל-Bindplane יש שתי מהדורות במיוחד ל-Google.

‫Bindplane כולל את הרכיבים העיקריים הבאים:

  • Bindplane collector. סוכן בקוד פתוח, שמבוסס על Collector של OpenTelemetry‏ (OTel). הוא אוסף יומנים ממקורות שונים, כולל יומני אירועים של Microsoft Windows, ושולח אותם ל-Google SecOps. אפשר להתקין את ה-collectors באופן מקומי או בענן.

    הרכיב הזה נקרא גם Bindplane Distribution for OpenTelemetry (BDOT) Collector,‏ bindplane agent,‏ collection agent,‏ collector או agent.

  • שרת Bindplane. פלטפורמה מקיפה ומאוחדת לניהול פריסות של אוספי OTel. הפריסות האלה יכולות להיות ב-Google SecOps וב- Google Cloud. הרבה לקוחות של Google SecOps משתמשים ב-Bindplane Server, אבל השימוש בו הוא אופציונלי. אפשר להריץ את Bindplane Server באופן מקומי או בענן של Bindplane. מידע נוסף על השרת זמין במאמר שרת Bindplane.

    הרכיב הזה נקרא גם מסוף הניהול של Bindplane Observability Pipeline (OP)‎ או מסוף הניהול של Bindplane.

מהדורות Google של Bindplane

ל-Bindplane יש שתי מהדורות במיוחד ל-Google: ‏Bindplane (Google Edition) ו-Bindplane Enterprise (Google Edition).

Bindplane (Google Edition)

‫Bindplane (Google Edition) זמין לכל לקוחות Google SecOps.

אתם יכולים להשתמש ב-Bindplane (Google Edition) בשירות עצמי בענן של Bindplane.

כדי להתחיל להתקין ולארח בעצמכם את Bindplane (Google Edition) או ליצור מפתח לשרת Bindplane מקומי, ראו Bindplane (Google Edition).

‫Bindplane Enterprise (מהדורת Google) – ללקוחות Google SecOps Enterprise Plus ו-Google Unified Security (GUS)

‫Bindplane Enterprise (Google Edition) כלול ללקוחות Google SecOps Enterprise Plus ו-GUS.

מומלץ להשתמש ב-Bindplane Enterprise (Google Edition) בפריסות בקנה מידה גדול.

הורדת מפתח הרישיון של Bindplane Enterprise

לקוחות Google SecOps Enterprise Plus ו-GUS יכולים להוריד את מפתח הרישיון של Bindplane Enterprise (Google Edition) ישירות ממסוף הפלטפורמה:

  1. במסוף Google SecOps, עוברים אל Settings > ניהול נתונים > Collection Agents.
  2. בכרטיס Bindplane License, לוחצים על Download License כדי לשמור את קובץ מפתח הרישיון.
  3. מחילים את מפתח הרישיון שהורדתם על ההתקנה של Bindplane Server. פרטים נוספים זמינים במאמר החלת רישיון Bindplane.

ההבדלים בין מהדורות Bindplane Google

בטבלה הבאה מפורטים ההבדלים בין מהדורות Google של Bindplane:

נושא או תכונה Bindplane (Google Edition) ‫Bindplane Enterprise (מהדורת Google)
עלות כלול ללא תשלום נוסף לכל לקוחות Google SecOps כלול בחינם ללקוחות Google SecOps Enterprise Plus
ניתוב/יעדים Google בלבד, כולל Google SecOps,‏ Cloud Logging,‏ BigQuery ו-Cloud Storage דרך Google SecOps ‫Google, כולל ניתוב למשך 12 חודשים ליעד שאינו של Google לצורך העברות של SIEM
סינון מסנן בסיסי עם ביטוי רגולרי מעבדי סינון מתקדמים (לדוגמה, סינון לפי תנאי, שדה, חומרה וכו'), צמצום נתונים, דגימת יומנים, ביטול כפילויות
צנזור לא רלוונטי אנונימיזציה של פרטים אישיים מזהים (PII)
טרנספורמציה הוספת שדה, העברת שדה, ניתוח נתונים (KV, ‏ JSON, ‏ CSV, ‏ XML, חותמת זמן, ניתוח לפי ביטוי רגולרי), שינוי שם של שדה, מפריד אירועים כולל את כל היכולות שנתמכות ב-Bindplane (מהדורת Google) בנוסף למחיקת שדה, מחיקת ערכים ריקים, coalesce
תכונות כלליות ברמת הפלטפורמה שער (נתונים נצברים מאוספים), אוספי Bindplane, שרת Bindplane (שכבת ניהול של Bindplane) מקומי או בענן, כל המקורות, מעקב אחר מארח שקט באמצעות מעבד Google SecOps, תור מתמשך, העשרת נתוני טלמטריה, זמינות גבוהה, RBAC, תמיכה בשני ממשקי ה-API להטמעת נתונים של Google SecOps, ערפול פרטי כניסה, ניהול צי מתקדם כולל קיבוץ של אוספים, הקצאה דינמית של סוגי יומנים כל היכולות שנתמכות ב-Bindplane (מהדורת Google)

ארכיטקטורת ה-collector של Bindplane

ב-Bindplane משתמשים ב-BDOT Collector (שנקרא באופן כללי collector) כדי ליצור סטנדרטיזציה של ניהול הטלמטריה באמצעות Open Agent Management Protocol‏ (OpAMP). אתם יכולים גם ליצור ולנהל הפצות בהתאמה אישית של OpenTelemetry Collector באמצעות Bindplane.

אפשר להריץ את ה-collector ב-Linux או ב-Docker כשרת אינטרנט קל ללא יחסי תלות חיצוניים.

למידע נוסף על ארכיטקטורת הפריסה של אוספי Bindplane OpenTelemetry, ראו פריסה.

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

אוספי נתונים שולחים יומנים לאוסף נתונים שפועל כשער

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

אוסף שפועל כשער משתמש באותו קובץ בינארי כמו כל האוספים האחרים.

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

אוספי נתונים שולחים יומנים לאוסף נתונים שפועל כשער

המלקטים שולחים יומנים ישירות ל-Google SecOps ingestion API

הדיאגרמה הבאה מציגה רכיבי Collector ששולחים יומנים ישירות ל-Google SecOps Ingestion API:

המלקטים שולחים יומנים ישירות ל-Google SecOps ingestion API

האוספים שולחים יומנים ישירות ל-Cloud Logging

בתרשים הבא מוצגים אוספים ששולחים יומנים ישירות ל-Cloud Logging:

האוספים שולחים יומנים ישירות ל-Cloud Logging

מערכות לאיסוף נתונים שולחות יומנים לכמה יעדים

הדיאגרמה הבאה מציגה Collector-ים ששולחים יומנים לכמה יעדים:

הכלי לאיסוף נתונים שולח יומנים לכמה יעדים

שרת Bindplane

אלה התכונות העיקריות של שרת Bindplane:

  • ניהול מרכזי. השרת מאפשר לנהל את כל הפריסות של אוספי OTel ב- Google Cloud. אתם יכולים לראות את הסטטוס של כל פריסה ולבצע משימות ניהול נפוצות, כמו הפעלה, עצירה והפעלה מחדש של אוספי נתונים.
  • מעקב בזמן אמת. השרת מספק מעקב בזמן אמת אחרי הפריסות של ה-OTel Collector. אתם יכולים לעקוב אחרי מדדים כמו שימוש במעבד (CPU), שימוש בזיכרון וקצב העברת נתונים. אפשר גם להציג יומנים ומעקבים כדי לפתור בעיות.
  • התראות ועדכונים. השרת מאפשר להגדיר התראות לאירועים חשובים, כמו הפסקת פעילות של אוסף או חריגה מסף של מדד.
  • ניהול הגדרות. השרת מאפשר לכם לנהל באופן מרוכז את ההגדרות של אוספי הנתונים של OTel. אתם יכולים לערוך קובצי תצורה, להגדיר משתני סביבה ולהחיל כללי מדיניות אבטחה על כל הפריסות שלכם.
  • שילוב עם Google Cloud. אתם יכולים ליצור ולנהל פריסות של אוספי OTel ב- Google Cloud ולהשתמש בשרת כדי לגשת למשאבים שלכם ב- Google Cloud .

אפשר לפרוס את Bindplane בענן או באופן מקומי. מידע נוסף זמין במאמר שימוש בשרת Bindplane.

דרישות טכניות והמלצות

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

דרישות רוחב הפס

‫Bindplane שומר על חיבורים לרשתות הבאות:

  • ניהול ה-Collector
  • מדידות של קצב העברת הנתונים של Collector
  • ממשקי משתמש באינטרנט ובשורת הפקודה

הדרישות לקישוריות

כברירת מחדל, Bindplane מאזין ליציאה 3001. אפשר להגדיר את היציאה הזו.

היציאה של Bindplane משמשת למטרות הבאות:

  • פקודות ואמצעי בקרה של Collector באמצעות OpAMP‏ (WebSocket)
  • בקשות למדידת קצב העברת הנתונים של האספן (בקשת HTTP POST)
  • משתמשי דפדפן ו-CLI‏ (HTTP ו-WebSocket)

האוספים צריכים להיות מסוגלים ליזום חיבורים ל-Bindplane עבור OpAMP (WebSocket) ומדידות תפוקה (HTTP).

‫Bindplane אף פעם לא יוזם חיבורים לאוספים. אפשר להגדיר חומת אש כדי למנוע מ-Bindplane להגיע לרשתות של ה-collector, אבל הרשתות של ה-collector צריכות להיות מסוגלות להגיע ל-Bindplane ביציאה שהוגדרה.

דרישות טכניות כלליות של Bindplane Collector

למידע על הדרישות הטכניות הכלליות של אוסף Bindplane, ראו:

דרישות המשאבים של Collector

דרישות המשאבים של Bindplane משתנות בהתאם למספר ה-collectors המנוהלים. ככל שמספר ה-collectors המנוהלים גדל, כך גדלה גם הצריכה של המעבד (CPU), הזיכרון, קצב העברת הנתונים בדיסק/IOPS והרשת.

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

מספר האספנים צמתים של Bindplane עמידות בפני תקלות ליבות מעבד (CPU) זיכרון מסד נתונים
1-‎100 1 לא רלוונטי 2 4 GB bbolt
‫100 עד 25,000 1 לא רלוונטי 4 ‫16GB postgres
1-60,000 3 1 2 8 GB postgres
60,001-125,000 5 1 2 8 GB postgres
125,001-250,000 10 2 2 8 GB postgres

תכנון ההתקנה והפריסה

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

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

עדיף להשתמש בהתאמה אופקית לעומס כי היא מספקת עמידות בפני תקלות ויכולה למנוע צווארי בקבוק בייצוא.

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

חישוב מספר הקולטים שצריך

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

קצב העברת נתונים של טלמטריה יומנים לשנייה אספנים
‫5GB לחודש 250,000 2
‫10GB לחודש 500,000 3
‫20GB לחודש 1,000,000 5
‫100GB לחודש 5,000,000 25

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

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

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

העברת תקורה של עיבוד

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

שיטות מומלצות למצב שער

כשמריצים את אוספי Bindplane במצב שער, מומלץ לתכנן את הפריסה לפי השיטות המומלצות הבאות:

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

שימוש במאזן עומסים לפי הצורך

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

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

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

מידע נוסף זמין במאמר הגדרת מאזן עומסים.

יציאות ופרוטוקולים של איזון עומסים

כברירת מחדל, Bindplane מאזין ליציאה 3001.

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

  • פרוטוקולי תעבורה מסוג TCP/UDP
  • פרוטוקולים של אפליקציות HTTP ו-gRPC

גודל איזון העומסים

כדי להשיג עמידות מקסימלית בפני תקלות, צומתי Bindplane צריכים לנהל עד 30,000 אוספים. כל אוסף פותח שני חיבורים ל-Bindplane (אחד לניהול מרחוק של OpAMP ואחד לפרסום מדדי תפוקה). המגבלה הזו עוזרת לוודא שלא תחרוג ממגבלת החיבורים של כ-65,535 לכל שרת עורפי (backend instance), שמוטלת על ידי רוב מאזני העומסים.

אם בארגון יש 100,000 אוספים, אשכול בגודל שלוש לא יספיק. כל צומת יהיה אחראי לכ-33,000 אוספים, כלומר 66,000 חיבורי TCP לכל מכונה של Bindplane. המצב הזה מחמיר אם צומת אחד מושבת לצורך תחזוקה, כי כל מכונה של Bindplane שנותרה תנהל 50,000 אוספים או 100,000 חיבורי TCP.

שיטות מומלצות לקביעת הגודל של איזון העומסים

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

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

    • פרוטוקולי תעבורה מסוג TCP/UDP
    • פרוטוקולים של אפליקציות HTTP ו-gRPC

מידע נוסף זמין במאמר עמידות של Collector.

איזון עומסים לפי סוג המקור

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

  • OTLP
  • Syslog
  • TCP/UDP
  • Splunk HEC
  • Fluent Forward

שימוש במצב זמינות גבוהה בסביבות ייצור

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

אם Bindplane מנהל יותר מ-25,000 אוספים, מומלץ להפעיל את Bindplane במצב זמינות גבוהה (HA).

למידע נוסף על זמינות גבוהה ב-Bindplane, קראו את המאמר High Availability.

חישוב מספר השרתים של Bindplane והאוספים לזמינות גבוהה (HA)

כשמפעילים את Bindplane במצב HA, צריך להביא בחשבון את מספר ה-collectors שכל שרת Bindplane אמור לטפל בהם.

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

‫Postgres לזמינות גבוהה (HA)

כדי להפעיל את Bindplane במצב HA, צריך להתקין את Postgres.

‫Prometheus לזמינות גבוהה (HA)

צריך את Prometheus כשמפעילים את Bindplane במצב HA.

מידע נוסף זמין במאמר Prometheus.

אפיק אירועים לזמינות גבוהה (HA)

ב-Bindplane משתמשים באפיק אירועים כדי לתקשר בין רכיבים בתוך Bindplane. כשמפעילים את Bindplane במצב HA, אפשר להשתמש באפיק האירועים כדי לשלוח אירועים בין שרתי Bindplane.

מידע נוסף זמין במאמר Event Bus.

פריסה של מכונה אחת לסביבת בדיקה או להוכחת היתכנות (PoC)

בסביבת בדיקה או בהוכחת היתכנות, מומלץ להשתמש בפריסה של מכונה אחת.

מידע נוסף זמין במאמר מופע יחיד.

בידוד פרטי הכניסה לקצה העורפי

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

הגדרת חומת אש לאוספי השער

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

חומת האש צריכה לאפשר לתנועת HTTP להגיע ל-Bindplane ביציאה שהוגדרה.

אימות ההגדרות של חומת האש (Ingestion API)

אם יש חומות אש או שרתי proxy מאומתים בין ה-Collector לבין האינטרנט, צריך להגדיר כללים שיפתחו את הגישה למארחים הבאים:

סוג החיבור יעד יציאה
TCP malachiteingestion-pa.googleapis.com 443
TCP asia-northeast1-malachiteingestion-pa.googleapis.com 443
TCP asia-south1-malachiteingestion-pa.googleapis.com 443
TCP asia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP australia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP europe-malachiteingestion-pa.googleapis.com 443
TCP europe-west2-malachiteingestion-pa.googleapis.com 443
TCP europe-west3-malachiteingestion-pa.googleapis.com 443
TCP europe-west6-malachiteingestion-pa.googleapis.com 443
TCP europe-west12-malachiteingestion-pa.googleapis.com 443
TCP me-central1-malachiteingestion-pa.googleapis.com 443
TCP me-central2-malachiteingestion-pa.googleapis.com 443
TCP me-west1-malachiteingestion-pa.googleapis.com 443
TCP northamerica-northeast2-malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP oauth2.googleapis.com 443

דרישות מוקדמות להטמעת נתונים ב-Google SecOps באמצעות Bindplane

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

דרישות הרשת ל-Chronicle API ‏(HTTPS)

כשמשתמשים ב-Bindplane עם Chronicle Ingestion API, שמשתמש ב-HTTPS, צריך לוודא שהגדרות הרשת וחומת האש מאפשרות חיבורים יוצאים לנקודות קצה ל-API של Chronicle.

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

כדי לשמור על הטמעת נתונים רציפה, כדאי:

  • רשימת היתרים מבוססת-דומיין: השיטה המומלצת היא להגדיר את חומת האש כך שתאפשר תנועת HTTPS יוצאת (יציאה 443) לכל הדומיין *.chronicle.googleapis.com.
  • נקודות קצה אזוריות: צריך להגדיר את Bindplane כך שישתמש בנקודת הקצה האזורית המתאימה למכונה של Google SecOps, כמו us-chronicle.googleapis.com,‏ europe-chronicle.googleapis.com וכו'. רשימה מלאה של נקודות קצה אזוריות זמינה במסמכי התיעוד בנושא מעבר מ-SIEM API מדור קודם ל-Chronicle API.
  • עדכונים אוטומטיים של כתובות IP: אם אי אפשר להוסיף לרשימת ההיתרים לפי דומיין, צריך להטמיע מערכת אוטומטית שתאחזר ותעדכן מדי פעם את טווחי כתובות ה-IP שמשויכים ל-*.chronicle.googleapis.com. אפשר לקבל את טווחי ה-IP הנוכחיים של Google APIs מהקבצים goog.json ו-cloud.json, כפי שמתואר במסמכי התיעוד של כתובות ה-IP של Google. הטמיעו מערכת לעדכון דינמי של כללי חומת האש על סמך המקורות האלה.

שימוש ב-PostgreSQL לפריסות בסביבת הייצור

כדי לפרוס את Bindplane בסביבת ייצור, צריך להשתמש ב-Postgres.

כדי להפעיל את Bindplane במצב HA, צריך להתקין את Postgres.

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

מספר האספנים ליבות מעבד (CPU) זיכרון
1-60,000 4 ‫16GB
60,001-125,000 8 32 GB
125,001-250,000 16 64 GB

למידע נוסף, קראו את המאמרים הבאים:

הטמעת אימות תקין

‫Bindplane תומך באימות באמצעות הפרוטוקולים והשירותים הבאים. ודאו שהם מוטמעים כמו שצריך:

שימוש בשרת Bindplane

רוב הלקוחות של Google SecOps משתמשים בשרת Bindplane, אבל השימוש בו הוא אופציונלי. אם אתם מתקינים את שרת Bindplane, אתם צריכים גישה אל storage.googleapis.com. אם אתם מתקינים רק אוסף נתונים, אין צורך בגישה הזו.

בסרטון Bindplane Use Case Demos, בקטע Google SecOps Configuration, מוסבר איך להגדיר את שרת Bindplane כדי לתקנן את היומנים ולייצא אותם ל-Google SecOps.

שימוש בשרת Bindplane Cloud

‫Bindplane Cloud זמין ללקוחות Google.

נכנסים למהדורת Google.

בכל בעיה שקשורה ל-Bindplane Cloud Server, פנו לתמיכה של Bindplane. אם נתקלתם בבעיות שקשורות לשרת Bindplane מקומי, פנו לתמיכה של Google SecOps.

שימוש בשרת Bindplane ב- Google Cloud

למידע על הפעלת שרת Bindplane ב- Google Cloud, קראו את המאמר Bindplane Enterprise Edition.

שימוש בשרת המקומי של Bindplane

השימוש בשרת Bindplane המקומי כפוף Google Cloud לתנאים ולהגבלות הקיימים.

התקנת השרת המקומי ב-Linux

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

כדי להתקין את שרת Bindplane המקומי ב-Linux באמצעות סקריפט:

  1. מריצים את הסקריפט הזה:

    curl -fsSlL https://downloads.bindplane.com/bindplane/latest/install-linux.sh -o install-linux.sh && bash install-linux.sh --init && rm install-linux.sh

  2. פועלים לפי ההוראות עד שמגיעים לשלב של אתחול השרת.

כדי להתקין את שרת Bindplane המקומי ב-Linux באמצעות קובץ בינארי:

  1. מורידים אחד מהקבצים הבאים:

  2. מעדכנים את קובץ התצורה לפי ההוראות שמפורטות במאמר הגדרת שרת Bindplane.

הפצות Linux נתמכות:
  • ‫Red Hat, ‏Centos, ‏Oracle Linux 7, ‏8, ‏9
  • ‫Debian 11 ו-Debian 12
  • ‫Ubuntu LTS 20.04 ו-22.04
  • ‫SUSE Linux 12 ו-15
  • ‫Alma ו-Rocky Linux

למידע נוסף, קראו את המאמרים הבאים:

פריסות מקומיות של Docker

למידע נוסף, קראו את המאמר התקנת שרת Bindplane.

אפשר למצוא קובצי אימג' של קונטיינרים של Bindplane Docker במיקומים הבאים:

  • חבילות GitHub: ghcr.io/observiq/Bindplane-ee
  • מאגר פריטי המידע שנוצרו בתהליך הפיתוח (Artifact) של Google: us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
  • Docker hub:‏ observiq/bindplane-ee

קובצי האימג' של הקונטיינרים מתויגים עם גרסת ההפצה: לדוגמה, גרסה v1.35.0 תתויג בתור observiq/bindplane-ee:1.35.0.

התקנת ה-collector של Bindplane

בקטע הזה מוסבר איך להתקין את Bindplane Collector ל-Google SecOps במערכות שונות.

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

כדי ללמוד איך להתקין את ה-collector (כלומר, סוכן OTel), קראו את המאמר Bindplane OTel Collector.

אפשר גם לעיין במסמכי התיעוד של GitHub בנושא bindplane-otel-collector.

כדי להתקין את ה-collector, צריך:

  • קובץ אימות להטמעת נתונים ב-Google SecOps

    כדי להוריד את קובץ האימות:

    1. פותחים את מסוף Google SecOps.
    2. עוברים אל הגדרות > ניהול נתונים > סוכני איסוף.
    3. מורידים את קובץ האימות להטמעת נתונים של Google SecOps. השלב הבא תלוי בשיטת ההעברה:
      • ‫gRPC: משתמשים בקובץ האימות שהורדתם.
      • ‫HTTPS: יוצרים חשבון שירות בפרויקט ב- Google Cloud שמקושר ל-Google SecOps ומקצים לו את התפקיד עריכה ב-Chronicle.

  • מספר הלקוח ב-Google SecOps

    כדי למצוא את מספר הלקוח:

    1. פותחים את מסוף Google SecOps.
    2. עוברים אל הגדרות > ניהול > פרופיל.
    3. מעתיקים את מזהה הלקוח מהקטע פרטי הארגון.

  • ‫Windows 2012 SP2 ואילך או מארח Linux עם systemd

  • חיבור לאינטרנט

  • גישה ל-GitHub

כלי פריסה

בקטע הזה מתוארים כלי הפריסה של Bindplane.

GitOps

פורסים את המשאבים של Bindplane באמצעות מודל GitOps, שכולל את הפעולות הבאות:

  • אימות Bindplane
  • Bindplane CLI
  • גישה לרשת
  • שילוב עם מאגר GitHub ופעולות GitHub
  • ייצוא של משאבים קיימים
  • ניהול ערכים רגישים
  • הגדרת תהליך עבודה של GitHub Action
  • הוראות מפורטות לשמירה ובדיקה של ההגדרות, להפעלת השקות אוטומטיות ולעדכון משאבים באמצעות עריכות ישירות או שיטת הייצוא של ממשק המשתמש
  • עדכון ערכים רגישים ושימוש ב-RBAC

מידע נוסף זמין במאמר GitOps.

Ansible

במאמר bindplane-agent-ansible מוסבר איך לפרוס את Bindplane באמצעות Ansible.

Bindplane CLI

למידע נוסף על Bindplane CLI, ראו GitOps.

Terraform

במאמר Bindplane Provider מוסבר איך משתמשים ב-Terraform כדי להגדיר את המשאבים של Bindplane.

‏Kubernetes

במאמרים הבאים מוסבר על Kubernetes עם Bindplane:

התקנת Bindplane Collector ב-Windows

כדי להתקין את אוסף הנתונים של Bindplane ב-Windows, מריצים את הפקודה הבאה ב-PowerShell:

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

לחלופין, כדי להתקין באמצעות אשף התקנה, מורידים את תוכנת ההתקנה העדכנית ל-Windows. אחרי שמורידים את קובץ ההתקנה, פותחים את אשף ההתקנה ופועלים לפי ההוראות כדי להגדיר ולהתקין את Bindplane Collector.

למידע נוסף על התקנת ה-collector של Bindplane ב-Windows, ראו התקנה ב-Windows.

התקנת Bindplane collector ב-Linux

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

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

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

התקנה מחבילה מקומית

כדי להתקין את ה-collector מחבילה מקומית, משתמשים ב--f עם הנתיב לחבילה.

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh -f path_to_package

התקנת RPM

מורידים את חבילת ה-RPM לארכיטקטורה שלכם מדף הגרסאות ומתקינים את החבילה באמצעות rpm. בדוגמה הבאה מוסבר איך להתקין את החבילה amd64:

sudo rpm -U ./observiq-otel-collector_v${VERSION}_linux_amd64.rpm
sudo systemctl enable --now observiq-otel-collector

מחליפים את VERSION בגרסה של החבילה שהורדתם.

התקנת DEB

מורידים את חבילת ה-DEB לארכיטקטורה שלכם מדף הגרסאות ומתקינים את החבילה באמצעות dpkg. בדוגמה הבאה מוסבר איך להתקין את החבילה amd64:

sudo dpkg -i --force-overwrite ./observiq-otel-collector_v${VERSION}_linux_amd64.deb
sudo systemctl enable --now observiq-otel-collector

מחליפים את VERSION בגרסת החבילה שהורדתם.

הגדרת ה-collector של Bindplane

אחרי שמתקינים את ה-collector, השירות observiq-otel-collector פועל ומוכן להגדרה.

אפשר להגדיר את ה-collector באופן ידני או באמצעות שרת Bindplane.

אם אתם מגדירים את ה-collector באופן ידני, אתם צריכים לעדכן את הפרמטרים של ה-exporter כדי לוודא שה-collector מאמת את Google SecOps.

קובץ התצורה של אוסף OTel

ב-Linux, קובץ התצורה של ה-collector נמצא ב-/opt/observiq-otel-collector/config.yaml.

שירות ויומנים של OTel Collector

כברירת מחדל, ה-collector מתעד ביומן ב-C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log.

יומן השגיאות הסטנדרטי של תהליך האיסוף נמצא ב-C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err.

ב-Linux, כדי להציג את היומנים מהאוסף, מריצים את הפקודה sudo tail -F /opt/observiq-otel-collector/log/collector.log.

פקודות נפוצות של שירות ה-OTel collector ב-Linux:

  • כדי להפסיק את שירות ה-OTel collector, מריצים את הפקודה sudo systemctl stop observiq-otel-collector.

  • כדי להפעיל את שירות ה-OTel collector, מריצים את הפקודה sudo systemctl start observiq-otel-collector.

  • כדי להפעיל מחדש את שירות ה-OTel collector, מריצים את הפקודה sudo systemctl restart observiq-otel-collector.

  • כדי להפעיל את שירות ה-OTel collector בזמן ההפעלה, מריצים את הפקודה sudo systemctl enable observiq-otel-collector.

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

כשמשנים את ההגדרות, צריך להפעיל מחדש את שירות ה-collector כדי שהשינויים ייכנסו לתוקף (sudo systemctl restart observiq-otel-collector).

שימוש בקובץ תצורה לדוגמה שמוגדר כברירת מחדל

כברירת מחדל, קובץ התצורה של ה-collector נמצא ב-C:\Program Files\observIQ OpenTelemetry Collector\config.yaml.

כדי להוריד קובץ תצורה לדוגמה וטוקן אימות שמשמש את ה-collector:

  • פותחים את מסוף Google SecOps ועוברים אל Settings > ניהול נתונים > Collection Agents.

מתאימים אישית את שני הקטעים הבאים בקובץ התצורה:

  • מקבל: מציין אילו יומנים האוסף צריך לאסוף ולשלוח אל Google SecOps.
  • Exporter: מציין את היעד שאליו ה-collector שולח את היומנים. אפשר להשתמש במייצאים הבאים:
    • מייצא Google SecOps: שולח יומנים ישירות ל-Google SecOps ingestion API.
    • מייצא של Google SecOps forwarder: שולח יומנים אל Google SecOps forwarder.
    • ‫Cloud Logging exporter: שולח יומנים אל Cloud Logging.

בכלי הייצוא, מתאימים אישית את האפשרויות הבאות:

  • ‫customer_id: מספר הלקוח ב-Google SecOps.
  • ‫endpoint: נקודת הקצה האזורית של Google SecOps.

  • creds: טוקן האימות שלכם.

    לחלופין, אתם יכולים להשתמש ב-creds_file_path כדי להפנות ישירות לקובץ פרטי הכניסה. בהגדרות של Windows, צריך להוסיף לוכסנים הפוכים לנתיב.

  • ‫log_type: סוג היומן. מומלץ לבחור באפשרות WINDOWS_DNS בתור Log Type.

  • ingestion_labels: תוויות הטמעה. התוויות האלה מזהות את היומנים ב-Google SecOps.

  • ‫namespace: מרחב שמות אופציונלי.

    צריך להגדיר מייצא לכל סוג של יומן.

דוגמאות להגדרות של איסוף יומנים

בקטעים הבאים יש דוגמאות להגדרות לאיסוף יומנים.

שליחת אירועים של Windows ו-sysmon ישירות אל Google SecOps

מגדירים את הפרמטרים הבאים בדוגמה:

הגדרה לדוגמה:

receivers:
  windowseventlog/sysmon:
    channel: Microsoft-Windows-Sysmon/Operational
    raw: true
  windowseventlog/security:
    channel: security
    raw: true
  windowseventlog/application:
    channel: application
    raw: true
  windowseventlog/system:
    channel: system
    raw: true

processors:
  batch:

exporters:
  chronicle/sysmon:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.",
  "universe_domain": "googleapis.com"
}' 
    log_type: 'WINDOWS_SYSMON'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'
  chronicle/winevtlog:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.",
  "universe_domain": "googleapis.com"
}'
    log_type: 'WINEVTLOG'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'

service:
  pipelines:
    logs/sysmon:
      receivers: [windowseventlog/sysmon]
      processors: [batch]
      exporters: [chronicle/sysmon]
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: [batch]
      exporters: [chronicle/winevtlog]

שליחת אירועים של Windows ו-syslog ישירות אל Google SecOps

מגדירים את הפרמטרים הבאים בדוגמה:

הגדרה לדוגמה:

receivers:
    tcplog:
      listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicle/chronicle_w_labels
        logs/source1__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

שליחת אירועים של Windows ו-syslog אל Google SecOps forwarder

מגדירים את הפרמטרים הבאים בדוגמה:

הגדרה לדוגמה:

receivers:
tcplog:
    listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicleforwarder/forwarder:
        export_type: syslog
        raw_log_field: body
        syslog:
            endpoint: 127.0.0.1:10514
            transport: udp
service:
    pipelines:
        logs/source0__forwarder-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicleforwarder/forwarder
        logs/source1__forwarder-0:
            receivers:
                - tcplog
            exporters:
                - chronicleforwarder/forwarder

שליחת syslog ישירות אל Google SecOps

מגדירים את הפרמטרים הבאים בדוגמה:

הגדרה לדוגמה:

receivers:
  tcplog:
    listen_address: "0.0.0.0:54525"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

איסוף אירועים של Windows מרחוק ושליחה שלהם ישירות אל Google SecOps

מגדירים את הפרמטרים הבאים בדוגמה:

  • windowseventlogreceiver
    • username
    • password
    • server
  • chronicleexporter
    • namespace
    • ingestion_labels
    • log_type
    • customer_id
    • creds

הגדרה לדוגמה:

receivers:
    windowseventlog/system:
        channel: system
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "remote-server"
    windowseventlog/application:
        channel: application
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
    windowseventlog/security:
        channel: security
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: WINEVTLOG
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/system
                - windowseventlog/application
                - windowseventlog/security
            exporters:
                - chronicle/chronicle_w_labels

שליחת נתונים ל-Cloud Logging

מגדירים את הפרמטר credentials_file בדוגמה.

הגדרה לדוגמה:

exporters:
  googlecloud:
    credentials_file: /opt/observiq-otel-collector/credentials.json

שליחת שאילתה למסד נתונים של SQL ושליחת התוצאות אל Google SecOps

מגדירים את הפרמטרים הבאים בדוגמה:

הגדרה לדוגמה:

receivers:
  sqlquery/source0:
    datasource: host=localhost port=5432 user=postgres password=s3cr3t sslmode=disable
    driver: postgres
    queries:
      - logs:
          - body_column: log_body
        sql: select * from my_logs where log_id > $$1
        tracking_column: log_id
        tracking_start_value: "10000"
processors:
  transform/source0_processor0__logs:
    error_mode: ignore
    log_statements:
      - context: log
        statements:
          - set(attributes["chronicle_log_type"], "POSTGRESQL") where true
exporters:
  chronicle/chronicle_sql:
    compression: gzip
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.",
  "universe_domain": "googleapis.com"
}' 
    customer_id: customer_id
    endpoint: malachiteingestion-pa.googleapis.com
    log_type: POSTGRESQL
    namespace: null
    raw_log_field: body
    retry_on_failure:
      enabled: false
    sending_queue:
      enabled: false
service:
  pipelines:
    logs/source0_chronicle_sql-0:
      receivers:
        - sqlquery/source0
      processors:
        - transform/source0_processor0__logs
      exporters:
        - chronicle/chronicle_sql

השלכת יומנים שתואמים לביטוי רגולרי

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

כדי להשמיט יומנים שתואמים לביטוי רגולרי, מוסיפים מעבד מסוג filter/drop-matching-logs-to-Chronicle להגדרות האישיות. המעבד הזה משתמש בפונקציה IsMatch כדי להעריך את גוף היומן ביחס לביטוי הרגולרי. אם הפונקציה מחזירה true, היומן נמחק.

בדוגמה הבאה, ההגדרה משמיטה יומנים שמכילים את המחרוזות <EventID>10</EventID> או <EventID>4799</EventID> בגוף היומן.

אתם יכולים להתאים אישית את הביטוי הרגולרי כך שיתאים לכל תבנית שאתם צריכים. הפונקציה IsMatch משתמשת בתחביר של ביטויים רגולריים מסוג RE2.

הגדרה לדוגמה:

processors:
    filter/drop-matching-logs-to-Chronicle:
        error_mode: ignore
        logs:
            log_record:
                - (IsMatch(body, "<EventID>10</EventID>")) or (IsMatch(body, "<EventID>4799</EventID>"))

בדוגמה הבאה, המעבד נוסף לצינור עיבוד הנתונים באותה הגדרה:

service:
  pipelines:
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: 
      - filter/drop-matching-logs-to-Chronicle # Add this line
      - batch
      exporters: [chronicle/winevtlog]

תפעול ותחזוקה של Bindplane

בקטע הזה מתוארות פעולות תחזוקה ותפעול שגרתיות.

אימות של הגדרת OTel

במאמר OTelBin מוסבר איך לאמת את ההגדרות של Bindplane OTel.

עדכוני גרסה של Collector

‫Bindplane יכול לבצע סקר ב-bindplane-otel-collector/releases כדי לזהות גרסאות חדשות של ה-collector. התכונה הזו היא אופציונלית.

כדי להשבית את הסקרים של GitHub, מגדירים את agentVersions.syncInterval ל-0 בהגדרות של Bindplane:

agentVersions:
syncInterval: 0

גיבוי ותוכנית התאוששות מאסון (DR)

במשאבים של Bindplane מוסבר איך לגבות ולשחזר נתונים אחרי אסון באמצעות Bindplane.

גיבוי ותוכנית התאוששות מאסון (DR) ב-PostgreSQL

במסמכי התיעוד של PostgreSQL מוסבר איך לגבות את PostgreSQL ולהתאושש מאסון באמצעות Bindplane.

גיבוי ותוכנית התאוששות מאסון (DR) ב-BBolt

כדי לקבל מידע על גיבוי והתאוששות מאסון של BBolt (הוצא משימוש) באמצעות Bindplane, קראו את המסמכים של BBolt Store.

עמידות וניסיון חוזר

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

מידע נוסף זמין במאמר עמידות של Collector.

צמצום נפח היומנים באמצעות מסנן החומרה

במאמר צמצום נפח היומנים באמצעות מסנן החומרה מוסבר איך לצמצם את נפח היומנים.

שילובים של Bindplane עם אוספי נתונים של צד שלישי

למרות ש-Bindplane יעיל יותר כשמשתמשים ב-Bindplane לאיסוף בקצה, ברוב המקרים Bindplane יכול להישאר בתשתית הקיימת. לדוגמה, אם אתם כבר משתמשים ב-Fluent Bit או ב-Splunk Universal Forwarders, אתם יכולים להמשיך להשתמש בהם.

שילוב של Bindplane עם Splunk

למידע נוסף על Splunk עם Bindplane, ראו:

שילובים של Bindplane עם אוספי נתונים אחרים של צד שלישי

למידע על שילובי Bindplane עם אוספים של צד שלישי, ראו חיבור אוספי OpenTelemetry אחרים באמצעות תוסף OpAMP.

מעקב שקט אחרי המארח

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

למידע על השימוש ב-Bindplane למעקב אחר מארחים שקטים, ראו:

שדרוג Bindplane ב-Linux

כדי לשדרג את Bindplane, מספיק להריץ את פקודת ההתקנה בלי הדגל --init בסוף. כדי לשדרג את Bindplane, צריך להריץ את הסקריפט הזה בשרת Bindplane. מידע נוסף זמין במאמר שדרוג, שדרוג לאחור או הסרה של Bindplane Server.

מעקב אחרי Bindplane

במאמר מעקב אחרי Bindplane מוסבר איך לעקוב אחרי Bindplane.

מעקב אחרי Kubernetes ב-Bindplane

במאמר מעקב אחרי Kubernetes מוסבר איך לעקוב אחרי Kubernetes ב-Bindplane.

מסמכים נוספים

מידע נוסף על Bindplane (לשעבר observIQ) זמין במקורות הבאים:

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