הזרמת יומנים מ-Google Cloud אל Splunk

Last reviewed 2024-10-24 UTC

במאמר הזה מתואר ארכיטקטורת הפניה שעוזרת ליצור מנגנון לייצוא יומנים שמוכן לייצור, ניתן להרחבה, עמיד בפני תקלות ומזרים יומנים ואירועים מהמשאבים שלכם ב- Google Cloud אל Splunk. ‫Splunk הוא כלי פופולרי לניתוח נתונים שמציע פלטפורמה מאוחדת לאבטחה ולניטור. למעשה, אתם יכולים לבחור לייצא את נתוני הרישום ל-Splunk Enterprise או ל-Splunk Cloud Platform. אדמינים יכולים להשתמש בארכיטקטורה הזו גם לתרחישי שימוש של פעולות IT או אבטחה.

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

sink ביומן מצטבר ברמת הארגון לייצוא ל-Splunk.

ארכיטקטורה

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

זרימת יומנים מ-Google Cloud אל Splunk.

הארכיטקטורה הזו כוללת את הרכיבים הבאים:

  • ‫Cloud Logging: כדי להתחיל את התהליך, Cloud Logging אוסף את היומנים ל-Log Sink מצטבר ברמת הארגון ושולח את היומנים ל-Pub/Sub.
  • ‫Pub/Sub: שירות Pub/Sub יוצר נושא ומינוי יחידים ליומנים, ומעביר את היומנים לצינור הראשי של Dataflow.
  • ‫Dataflow: יש שני צינורות עיבוד נתונים של Dataflow בארכיטקטורה לדוגמה הזו:
    • פייפליין ראשי של Dataflow: במרכז התהליך נמצא פייפליין ראשי של Dataflow, שהוא פייפליין סטרימינג מ-Pub/Sub ל-Splunk. הפייפליין הזה שולף יומנים מהמינוי ל-Pub/Sub ומעביר אותם ל-Splunk.
    • צינור עיבוד נתונים משני של Dataflow: צינור עיבוד הנתונים המשני של Dataflow פועל במקביל לצינור עיבוד הנתונים הראשי של Dataflow, והוא צינור עיבוד נתונים בסטרימינג של Pub/Sub ל-Pub/Sub שנועד להפעיל מחדש הודעות אם המסירה נכשלת.
  • ‫Splunk: בסוף התהליך, Splunk Enterprise או Splunk Cloud Platform פועלים כ-HTTP Event Collector‏ (HEC) ומקבלים את היומנים לצורך ניתוח נוסף. אפשר לפרוס את Splunk באופן מקומי, ב-Google Cloud כ-SaaS או בגישה היברידית.

תרחיש לדוגמה

ארכיטקטורת ההפניה הזו מבוססת על ענן ועל גישה מבוססת-דחיפה. בשיטה הזו, שמבוססת על שליחת נתונים, משתמשים בתבנית Pub/Sub to Splunk Dataflow כדי להזרים יומנים אל Splunk HTTP Event Collector (HEC). בארכיטקטורת ההפניה מוסבר גם על תכנון הקיבולת של צינור Dataflow ועל אופן הטיפול בכשלים פוטנציאליים בהעברה כשקיימות בעיות זמניות בשרת או ברשת.

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

לשיטה שמבוססת על דחיפת נתונים ל-Splunk יש את היתרונות הבאים: Google Cloud

  • שירות מנוהל. בתור שירות מנוהל, Dataflow שומר על המשאבים הנדרשים ב- Google Cloud למשימות של עיבוד נתונים, כמו ייצוא יומנים.
  • עומס עבודה מבוזר. השיטה הזו מאפשרת לכם לפזר את עומסי העבודה בין כמה עובדים לעיבוד מקביל, כך שלא יהיה נקודת כשל אחת.
  • אבטחה. ‫ Google Cloud מעביר את הנתונים שלכם ל-Splunk HEC, כך שאין צורך לבצע תחזוקה או לדאוג לאבטחה שקשורים ליצירה ולניהול של מפתחות של חשבון שירות.
  • התאמה אוטומטית של נפח האחסון (autoscaling). שירות Dataflow משנה את מספר העובדים באופן אוטומטי בתגובה לשינויים בנפח היומנים הנכנסים ובפיגור.
  • סובלנות לתקלות. ​​אם יש בעיות זמניות בשרת או ברשת, השיטה מבוססת-הדחיפה מנסה לשלוח מחדש את הנתונים ל-Splunk HEC באופן אוטומטי. הוא גם תומך בנושאים לא מעובדים (שנקראים גם נושאים של הודעות שלא נמסרו) לכל הודעות היומן שלא ניתן למסור, כדי למנוע אובדן נתונים.
  • פשטות. אתם נמנעים מהוצאות ניהול ומהעלות של הפעלת heavy forwarders אחד או יותר ב-Splunk.

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

  • ניתוח נתונים עסקיים
  • תפעול IT
  • מעקב אחרי ביצועי אפליקציות
  • תפעול אבטחה (SecOps)
  • תאימות

חלופות עיצוב

שיטה חלופית לייצוא יומנים ל-Splunk היא שיטה שבה שולפים יומנים מ-Google Cloud. בשיטה הזו, שמבוססת על שליפת נתונים, משתמשים ב-Google Cloud APIs כדי לאחזר את הנתונים באמצעות Splunk Add-on for Google Cloud. אפשר להשתמש בשיטה מבוססת-משיכה במצבים הבאים:

  • פריסת Splunk שלכם לא מציעה נקודת קצה של Splunk HEC.
  • עוצמת הקול של היומן נמוכה.
  • רוצים לייצא ולנתח מדדים של Cloud Monitoring, אובייקטים של Cloud Storage, מטא-נתונים של Cloud Resource Manager API, נתוני חיוב ב-Cloud או יומנים עם נפח נמוך.
  • אתם כבר מנהלים לפחות משגר כבד אחד ב-Splunk.
  • אתם משתמשים ב-Inputs Data Manager for Splunk Cloud.

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

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

לפני שמשתמשים בתוסף Splunk, צריך להפנות את רשומות היומן ל-Pub/Sub באמצעות sink ביומן. כדי ליצור sink ביומן עם נושא Pub/Sub כיעד, ראו יצירת sink. חשוב להקצות את התפקיד 'פרסום הודעות ב-Pub/Sub' (roles/pubsub.publisher) לזהות הכתיבה של ה-sink בנושא ב-Pub/Sub. מידע נוסף על הגדרת הרשאות ליעד של נתוני Sink זמין במאמר הגדרת הרשאות ליעד.

כדי להפעיל את התוסף Splunk, מבצעים את השלבים הבאים:

  1. ב-Splunk, פועלים לפי ההוראות של Splunk כדי להתקין את Splunk Add-on for Google Cloud.
  2. יוצרים מינוי שליפה של Pub/Sub לנושא Pub/Sub שאליו מנותבים היומנים, אם עדיין אין לכם מינוי כזה.
  3. יצירה של חשבון שירות.
  4. יוצרים מפתח לחשבון השירות עבור חשבון השירות שיצרתם.
  5. מקצים לחשבון השירות את התפקידים 'צפייה ב-Pub/Sub' (roles/pubsub.viewer) ו'הרשמה לנושא ב-Pub/Sub' (roles/pubsub.subscriber) כדי לאפשר לחשבון לקבל הודעות מהמינוי ל-Pub/Sub.

  6. ב-Splunk, פועלים לפי ההוראות של Splunk כדי להגדיר קלט חדש של Pub/Sub בתוסף Splunk ל- Google Cloud.

    ההודעות של Pub/Sub מייצוא היומן מופיעות ב-Splunk.

כדי לוודא שהתוסף פועל, פועלים לפי השלבים הבאים:

  1. ב-Cloud Monitoring, פותחים את הכלי Metrics Explorer.
  2. בתפריט Resources בוחרים באפשרות pubsub_subscription.
  3. בקטגוריות מדדים, בוחרים באפשרות pubsub/subscription/pull_message_operation_count.
  4. עוקבים אחרי מספר הפעולות של שליפת הודעות למשך דקה עד שתי דקות.

שיקולים לגבי העיצוב

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

אבטחה, פרטיות ותאימות

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

שימוש בכתובות IP פרטיות כדי לאבטח את המכונות הווירטואליות שתומכות בצינור עיבוד הנתונים ב-Dataflow

מומלץ להגביל את הגישה למכונות הווירטואליות של העובדים שמשמשות בצינור Dataflow. כדי להגביל את הגישה, צריך לפרוס את המכונות הווירטואליות האלה עם כתובות IP פרטיות. עם זאת, המכונות הווירטואליות האלה צריכות גם להיות מסוגלות להשתמש ב-HTTPS כדי להזרים את היומנים המיוצאים ל-Splunk ולגשת לאינטרנט. כדי לספק גישת HTTPS, צריך שער Cloud NAT שמקצה באופן אוטומטי כתובות IP של Cloud NAT למכונות הווירטואליות שזקוקות להן. חשוב למפות את רשת המשנה שמכילה את המכונות הווירטואליות לשער Cloud NAT.

הפעלת גישה פרטית ל-Google

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

הגבלת תעבורת נתונים נכנסת (ingress) של Splunk HEC לכתובות IP מוכרות שמשמשות את Cloud NAT

אם רוצים להגביל את התנועה אל Splunk HEC לקבוצת משנה של כתובות IP ידועות, אפשר לשריין כתובות IP סטטיות ולהקצות אותן באופן ידני לשער Cloud NAT. בהתאם לפריסת Splunk, תוכלו להגדיר את כללי חומת האש של Splunk HEC ingress באמצעות כתובות ה-IP הסטטיות האלה. מידע נוסף על Cloud NAT זמין במאמר הגדרה וניהול של תרגום כתובות רשת באמצעות Cloud NAT.

אחסון הטוקן של Splunk HEC ב-Secret Manager

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

  • Plaintext
  • טקסט מוצפן באמצעות מפתח של Cloud Key Management Service
  • גרסת סוד מוצפנת ומנוהלת על ידי Secret Manager

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

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

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

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

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

תפקידים שנדרשים להקצאה לחשבון שירות של עובד Dataflow.

כפי שמוצג בדיאגרמה, צריך להקצות את התפקידים הבאים לחשבון השירות של העובד (worker) ב-Dataflow:

  • אדמין של Dataflow
  • Dataflow Worker
  • אדמין של אובייקט אחסון
  • מנוי ל-Pub/Sub
  • כלי הצפייה ב-Pub/Sub
  • פרסום הודעות ב-Pub/Sub
  • Secret Accessor

הגדרת אימות SSL באמצעות אישור CA בסיסי פנימי אם משתמשים ב-CA פרטי

כברירת מחדל, צינור עיבוד הנתונים של Dataflow משתמש במאגר האישורים של עובד Dataflow כדי לאמת את אישור ה-SSL של נקודת הקצה של Splunk HEC. אם אתם משתמשים ברשות אישורים (CA) פרטית כדי לחתום על אישור SSL שמשמש את נקודת הקצה של Splunk HEC, אתם יכולים לייבא את אישור ה-CA הבסיסי הפנימי שלכם למאגר האישורים המהימנים. לאחר מכן, תהיה לעובדים של Dataflow אפשרות להשתמש באישור המיובא לצורך אימות אישור SSL.

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

מידע נוסף זמין במאמר פרמטרים של תבנית Pub/Sub ל-Splunk Dataflow rootCaCertificatePath ו-disableCertificateValidation.

יעילות תפעולית

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

שימוש ב-UDF כדי לשנות יומנים או אירועים בזמן ההעברה

תבנית Pub/Sub to Splunk Dataflow תומכת בפונקציות בהגדרת המשתמש (UDF) לצורך שינוי אירועים בהתאמה אישית. דוגמאות למקרים שבהם כדאי להשתמש ב-Dataflow: הוספת שדות נוספים לרשומות, הסתרת שדות רגישים או סינון רשומות לא רצויות. הפונקציה UDF מאפשרת לשנות את פורמט הפלט של צינור Dataflow בלי צורך לבצע קומפילציה מחדש או לתחזק את קוד התבנית עצמו. באדריכלות ההפניה הזו נעשה שימוש בפונקציה להגדרת משתמש (UDF) כדי לטפל בהודעות שצינור הנתונים לא מצליח להעביר ל-Splunk.

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

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

טיפול בשגיאות במהלך ייצוא יומנים ל-Splunk.

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

  1. צינור עיבוד המסירה הראשי מ-Pub/Sub ל-Splunk מעביר אוטומטית הודעות שלא ניתן למסור לנושא שלא עבר עיבוד, כדי שהמשתמש יוכל לבדוק אותן.

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

  3. המפעיל מפעיל את צינור ההודעות של ההודעות שלא נשלחו. צינור הנתונים הזה מ-Pub/Sub ל-Pub/Sub (שמסומן בקטע המקווקו בתרשים הקודם) הוא צינור נתונים זמני שמעביר את ההודעות שנכשלו מהמינוי שלא עבר עיבוד בחזרה לנושא המקורי של sink ביומן.

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

    // If the message has already been converted to a Splunk HEC object
// with a stringified obj.event JSON payload, then it's a replay of
// a previously failed delivery.
// Unnest and parse the obj.event. Drop the previously injected
// obj.attributes such as errorMessage and timestamp
if (obj.event) {
 try {
   event = JSON.parse(obj.event);
   redelivery = true;
 } catch(e) {
   event = obj;
 }
} else {
 event = obj;
}

// Keep a tally of delivery attempts
event.delivery_attempt = event.delivery_attempt || 1;
if (redelivery) {
 event.delivery_attempt += 1;
}

אמינות ועמידות בפני תקלות

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

טבלה 1: סוגי שגיאות מסירה ב-Splunk

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

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

כן

Read timed out

או

Connection reset

שגיאת 5xx בשרת Splunk

כן

Splunk write status code: 503

שגיאת 4xx בשרת Splunk

לא

Splunk write status code: 403

השרת של Splunk לא פועל

לא

The target server failed to respond

אישור SSL לא חוקי של Splunk

לא

Host name X does not match the certificate

שגיאת תחביר JavaScript בפונקציה בהגדרת המשתמש (UDF)

לא

ReferenceError: X is not defined

במקרים מסוימים, הצינור משתמש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) ומנסה באופן אוטומטי למסור את ההודעה שוב. לדוגמה, אם שרת Splunk יוצר קוד שגיאה, צינור הנתונים צריך לשלוח מחדש את ההודעה.5xx קודי השגיאה האלה מופיעים כשהעומס על נקודת הקצה של Splunk HEC גבוה מדי.

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

  • שגיאת תחביר בפונקציית UDF.
  • טוקן HEC לא תקין שגורם לשרת Splunk ליצור תגובת שרת 4xx Forbidden.

אופטימיזציה של הביצועים והעלויות

לגבי אופטימיזציה של הביצועים והעלויות, צריך לקבוע את הגודל המקסימלי ואת קצב העברת הנתונים של צינור עיבוד הנתונים של Dataflow. צריך לחשב את הערכים הנכונים של הגודל וקצב העברת הנתונים כדי שהצינור יוכל להתמודד עם נפח השיא היומי של היומנים (GB/day) ועם קצב ההודעות ביומן (אירועים לשנייה, או EPS) מהמינוי של Pub/Sub במעלה הזרם.

צריך לבחור את הגודל ואת ערכי התפוקה כך שלא יתרחשו במערכת אף אחת מהבעיות הבאות:

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

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

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

  • יוצר 1TB של יומנים מדי יום.
  • גודל ההודעה הממוצע הוא 1KB.
  • שיעור ההודעות המקסימלי שנשלח ברציפות גבוה פי שניים מהשיעור הממוצע.

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

סוג המכונה

שיטה מומלצת: מגדירים את הדגל --worker-machine-type לערך n2-standard-4 כדי לבחור גודל מכונה שמספק את יחס הביצועים לעלות הטוב ביותר.

מכיוון שסוג המכונה n2-standard-4 יכול לטפל ב-12,000 EPS, מומלץ להשתמש בסוג המכונה הזה כבסיס לכל העובדים של Dataflow.

בארכיטקטורת ההפניה הזו, מגדירים את הדגל --worker-machine-type לערך n2-standard-4.

מספר המכונות

שיטה מומלצת: כדאי להגדיר את הדגל --max-workers כדי לשלוט במספר המקסימלי של תהליכי worker שנדרשים לטיפול בשיא הצפוי של EPS.

התכונה 'התאמה אוטומטית לעומס' ב-Dataflow מאפשרת לשירות לשנות באופן דינמי את מספר העובדים שמשמשים להרצת צינור עיבוד הנתונים של הסטרימינג, כשמתבצעים שינויים בשימוש במשאבים ובטעינה. כדי להימנע מהקצאת יתר של משאבים כשמשתמשים בהתאמת קנה מידה אוטומטית, מומלץ להגדיר תמיד את המספר המקסימלי של מכונות וירטואליות שמשמשות כעובדי Dataflow. מגדירים את המספר המקסימלי של מכונות וירטואליות באמצעות הדגל --max-workers כשפורסים את צינור הנתונים של Dataflow.

‫Dataflow מקצה באופן סטטי את רכיב האחסון באופן הבא:

  • צינור לעיבוד נתונים עם התאמה אוטומטית לעומס פורס דיסק אחסון מתמיד אחד לכל עובד פוטנציאלי של סטרימינג. גודל ברירת המחדל של דיסק אחסון מתמיד (persistent disk) הוא 400GB, ואתם מגדירים את המספר המקסימלי של העובדים באמצעות הדגל --max-workers. הדיסקים מחוברים לעובדים הפעילים בכל נקודת זמן, כולל בזמן ההפעלה.

  • מכיוון שכל worker instance מוגבל ל-15 דיסקים קבועים, מספר ה-Workers המינימלי שצריך להפעיל הוא ⌈--max-workers/15⌉. לכן, אם ערך ברירת המחדל הוא --max-workers=20, השימוש בצינור (והעלות) יהיה כדלקמן:

    • אחסון: סטטי עם 20 דיסקים לאחסון מתמיד.
    • ‫Compute: דינמי עם מינימום של 2 מופעי worker ‏ (⌈20/15⌉ = 2) ומקסימום של 20.

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

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

  1. כדי לחשב את המספר הממוצע של אירועים לשנייה (EPS), משתמשים בנוסחה הבאה:

    \( {AverageEventsPerSecond}\simeq\frac{TotalDailyLogsInTB}{AverageMessageSizeInKB}\times\frac{10^9}{24\times3600} \)

    דוגמה לחישוב: בהינתן ערכי הדוגמה של 1TB של יומנים ליום עם גודל הודעה ממוצע של 1KB, הנוסחה הזו יוצרת ערך EPS ממוצע של 11.5k EPS.

  2. כדי לקבוע את שיעור האירועים לשנייה (EPS) המקסימלי המתמשך, משתמשים בנוסחה הבאה, שבה המכפיל N מייצג את האופי של רישום ביומן שמתבצע במנות:

    \( {PeakEventsPerSecond = N \times\ AverageEventsPerSecond} \)

    חישוב לדוגמה: בהינתן ערך לדוגמה של N=2 והערך הממוצע של EPS‏ 11.5k שחישבתם בשלב הקודם, הנוסחה הזו יוצרת ערך שיא קבוע של EPS‏ 23k.

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

    \( {maxCPUs = ⌈PeakEventsPerSecond / 3k ⌉} \)

    דוגמה לחישוב: באמצעות ערך ה-EPS המקסימלי המתמשך של 23,000 שחישבתם בשלב הקודם, הנוסחה הזו יוצרת מקסימום של ⌈23 / 3⌉ = 8 ליבות vCPU.

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

    \( maxNumWorkers = ⌈maxCPUs / 4 ⌉ \)

    דוגמה לחישוב: אם משתמשים בערך המקסימלי של vCPU בדוגמה, שהוא 8, שחושב בשלב הקודם, הנוסחה [8/4] יוצרת מספר מקסימלי של 2 עבור סוג מכונה n2-standard-4.

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

מקביליות

שיטה מומלצת: מגדירים את הפרמטר parallelism בתבנית Pub/Sub to Splunk Dataflow כך שיהיה כפול ממספר ה-vCPU שמשמש את המספר המקסימלי של עובדי Dataflow.

הפרמטר parallelism עוזר למקסם את מספר החיבורים המקבילים של Splunk HEC, וכך למקסם את קצב ה-EPS של הצינור.

ערך ברירת המחדל parallelism של 1 משבית את ההפעלה המקבילית ומגביל את קצב הפלט. צריך לשנות את הגדרת ברירת המחדל הזו כדי להביא בחשבון 2 עד 4 חיבורים מקבילים לכל vCPU, עם המספר המקסימלי של תהליכי worker שנפרסו. ככלל, כדי לחשב את ערך ברירת המחדל של ההגדרה הזו, מכפילים את המספר המקסימלי של עובדי Dataflow במספר המעבדים הווירטואליים לכל עובד, ואז מכפילים את התוצאה ב-2.

כדי לקבוע את המספר הכולל של חיבורים מקבילים ל-Splunk HEC בכל העובדים של Dataflow, משתמשים בנוסחה הבאה:

\( {parallelism = maxCPUs * 2} \)

דוגמה לחישוב: אם מספר המעבדים הווירטואליים המקסימלי הוא 8, כמו בדוגמה שחישבנו קודם לגבי מספר המכונות, הנוסחה הזו תיתן את מספר החיבורים המקבילים: 8 x 2 = 16.

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

מספר הבקשות באצווה

שיטה מומלצת: כדי לאפשר ל-Splunk HEC לעבד אירועים בקבוצות ולא אחד בכל פעם, צריך להגדיר את הפרמטר batchCount לערך שבין 10 ל-50 אירועים/בקשה ליומנים.

הגדרת מספר האצוות עוזרת להגדיל את מספר האירועים לשנייה ולהפחית את העומס בנקודת הקצה של Splunk HEC. ההגדרה משלבת כמה אירועים לחבילה אחת כדי לעבד אותם בצורה יעילה יותר. מומלץ להגדיר את הפרמטר batchCount לערך בין 10 ל-50 אירועים/בקשה ליומנים, בתנאי שעיכוב החיץ המקסימלי של שתי שניות מקובל.

\( {batchCount >= 10} \)

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

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

המאמרים הבאים

  • רשימה מלאה של פרמטרים של תבנית Pub/Sub ל-Splunk Dataflow זמינה במסמכי התיעוד של Pub/Sub ל-Splunk Dataflow.
  • תבניות Terraform תואמות שיעזרו לכם לפרוס את ארכיטקטורת העזר הזו זמינות במאגר GitHub‏ terraform-splunk-log-export. הוא כולל לוח בקרה מוכן מראש של Cloud Monitoring למעקב אחרי צינור עיבוד הנתונים של Splunk Dataflow.
  • פרטים נוספים על מדדים מותאמים אישית של Splunk Dataflow ועל רישום ביומן שיעזרו לכם לעקוב אחרי צינורות הנתונים של Splunk Dataflow ולפתור בעיות בהם זמינים בבלוג New observability features for your Splunk Dataflow streaming pipelines.
  • לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.