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

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

מידע על מאגרי נתונים נצברים

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

  • כל רשומות היומן שמקורן בתיקייה או בארגון.
  • כל רשומות היומן שמקורן במשאבי הצאצא של התיקייה או הארגון.

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

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

יירוט של מקור מצטבר להוצאת המטבע

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

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

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

מאגר נתונים משולב שלא מבצע חסימה לא משפיע על האופן שבו רשומות ביומן מנותבות למאגרים אחרים. כלומר, גם כש<term ref="log entry">רשומה ביומן</term> תואמת למסנן של אובייקט sink מצטבר שלא חוסם, <term ref="log entry">רשומה ביומן</term> זו מועברת לאובייקטים אחרים בהיררכיית המשאבים של <term ref="log entry">רשומה ביומן</term> זו. מאגר נתונים משולב שלא חוסם מאפשר לכם לשמור על נראות של רשומות ביומן במשאבים שבהם הן נוצרו.

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

דוגמאות לניתוב

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

דוגמה: לא קיימים מאגרי נתונים מצטברים

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

דוגמה: קיים יעד מצטבר שלא מבצע יירוט

נניח שקיים יעד מצטבר שלא מיירט ביררכיית המשאבים עבור רשומה ביומן. אחרי ש-Log Router שולח את הרשומה ביומן אל יעד מצטבר שלא מבצע יירוט, קורה הדבר הבא:

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

  2. הכלי Log Router שולח את רשומת היומן אל log sinks בפרויקט שבו נוצרה רשומת היומן.

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

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

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

  • הרשומה ביומן תואמת למסנן ההכללה אבל לא תואמת לאף מסנן החרגה:

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

  • רשומת היומן לא תואמת למסנן ההכללה או שהיא תואמת לפחות למסנן החרגה אחד:

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

    2. הכלי Log Router שולח את רשומת היומן אל log sinks בפרויקט שבו נוצרה רשומת היומן.

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

יעדים נתמכים ל-aggregated sinks

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

כיורים עם סיפון

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

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

כיורים שלא חוסמים את המים

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

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

היעדים הבאים נתמכים:

פרויקטGoogle Cloud

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

קטגוריה ביומן

בוחרים ביעד הזה כשרוצים לאחסן את נתוני היומן במשאבים שמנוהלים על ידי Cloud Logging. אפשר להציג ולנתח נתוני יומן שאוחסנו בדלי יומנים באמצעות שירותים כמו Logs Explorer ו-Log Analytics.

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

מערך נתונים של BigQuery
בוחרים ביעד הזה כשרוצים לצרף את נתוני היומן לנתונים עסקיים אחרים. צריך להפעיל הרשאות כתיבה למערך הנתונים שאתם מציינים. לא מגדירים את היעד של Sink להיות מערך נתונים מקושר ב-BigQuery. מערכי נתונים מקושרים הם לקריאה בלבד.
קטגוריה של Cloud Storage
בוחרים ביעד הזה כשרוצים לאחסן את נתוני היומן לטווח ארוך. הקטגוריה של Cloud Storage יכולה להיות באותו פרויקט שממנו מגיעים רשומות היומן, או בפרויקט אחר. רשומות ביומן מאוחסנות כקובצי JSON.
נושא Pub/Sub
בוחרים ביעד הזה כשרוצים לייצא את נתוני היומן מ-Google Cloud ואז להשתמש בשילובים עם צד שלישי כמו Splunk או Datadog. ערכי היומן מעוצבים בפורמט JSON ואז מנותבים לנושא ב-Pub/Sub.

שיטות מומלצות

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

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

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

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

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

יירו של יעד מצטבר ומדדים מבוססי-יומנים

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

מידע נוסף מופיע במאמר איך רשומות ביומן הניתוב משפיעות על מדדים מבוססי-יומן.

מאגרי נתונים מצטברים ו-VPC Service Controls

המגבלות הבאות חלות כשמשתמשים ביעדים מצטברים וב-VPC Service Controls:

  • מאגרי נתונים מצטברים יכולים לגשת לנתונים מפרויקטים בתוך היקף שירות. כדי להגביל את הגישה של sinks מצטברים לנתונים בתוך גבולות גזרה, מומלץ להשתמש ב-IAM כדי לנהל את הרשאות הגישה לרישום ביומן.

  • שירות VPC Service Controls לא תומך בהוספת משאבים של תיקיות או ארגונים לאזורים של שירותים. לכן, אי אפשר להשתמש ב-VPC Service Controls כדי להגן על יומנים ברמת התיקייה והארגון, כולל יומנים מצטברים. כדי לנהל הרשאות ל-Logging ברמת התיקייה או הארגון, מומלץ להשתמש ב-IAM.

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

  • כשמציינים מדיניות Ingress או Egress עבור גבולות גזרה לשירות, אי אפשר להשתמש ב-ANY_SERVICE_ACCOUNT וב-ANY_USER_ACCOUNT כסוג זהות כשמשתמשים ב-sink ביומן כדי לנתב יומנים למשאבי Cloud Storage. אבל אפשר להשתמש ב-ANY_IDENTITY כסוג הזהות.

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