רשומות ביומן הניתוב

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

כברירת מחדל, Cloud Logging מעביר את כל הרשומות ביומן למאגרי יומנים בפרויקט, בתיקייה או בארגון שבהם הן נוצרו. עם זאת, אפשר להגדיר יעד ליומנים כדי לנתב את נתוני היומנים לקטגוריות מותאמות אישית, ל-Cloud Storage, ל-BigQuery או ל-Pub/Sub. שירותים כמו Cloud Storage ו-Pub/Sub תומכים בייצוא של נתוני היומן לכלים של צד שלישי.

ברמה גבוהה, כך Cloud Logging מנתב ומאחסן רשומות ביומן:

איור שממחיש איך Cloud Logging מעביר רשומות ביומן.

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

ניתוב לעומת ייצוא של רשומות ביומן

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

ייצוא הוא תהליך של העברת רשומות ביומן מ- Google Cloud למיקום חיצוני. לדוגמה, אפשר לנתב רשומות ביומן ל-Pub/Sub ואז לייצא אותן לכלים של צד שלישי.

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

בעזרת Logs Explorer אפשר להוריד רשומות ביומן שמאוחסנות בקטגוריות של יומנים לאחסון מקומי. עם זאת, אפשרות ההורדה מוגבלת ל-10,000 רשומות ביומן. כדי לייצא את הרשומות ביומן מ-Google Cloud, אפשר להשתמש באפשרויות הבאות:

  • מגדירים sink ביומן כדי להעביר רשומות ביומן נכנסות ל-Pub/Sub, ואז מייצאים את הנתונים האלה מ- Google Cloud.

  • העתקת רשומות ביומן מקטגוריית יומנים ל-Cloud Storage, ואז ייצוא הנתונים מ- Google Cloud. מידע על העתקת יומנים מופיע במאמר העתקה וניתוב של יומנים באופן רטרואקטיבי.

מידע על נתבי יומנים

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

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

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

המערכת מתעלמת מרשומות ביומן עם חותמות זמן שחלפו יותר מתקופת השמירה של היומנים או שחלפו יותר מ-24 שעות.

מידע על פריטי Sink ביומן

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

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

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

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

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

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

תמיכה בארגונים ובתיקיות

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

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

    • מאגרי מידע מצטברים שלא מיירטים נתונים
    • יירוט של כיורים מצטברים

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

  • אתם יכולים להגדיר הגדרות ברירת מחדל למשאבים ב-Cloud Logging כדי לציין את ההגדרה של יעד _Default שנוצר על ידי המערכת למשאבים חדשים בארגון או בתיקייה. לדוגמה, אתם יכולים להשתמש בהגדרות האלה כדי להשבית את יעד _Default או לציין את המסננים ביעד הזה.

דוגמאות לתכנון מסלול

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

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

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

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

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

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

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

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

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

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

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

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

    1. הרשומה ביומן לא מנותבת על ידי מאגר היעד המצטבר שחוצץ בין המקור ליעד.
    2. הכלי Log Router שולח את רשומת היומן אל יעד היומן בפרויקט שבו נוצרה רשומת היומן.

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

מסננים של פריטי Sink ביומן

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

רשומה ביומן מנותבת על ידי sink ביומן על סמך הכללים הבאים:

  • אם רשומת היומן לא תואמת למסנן ההכללה, היא לא מנותבת. אם לא מציינים מסנן הכללה באובייקט sink, כל רשומה ביומן תואמת למסנן הזה.

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

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

המסננים ב-sink ביומן מוגדרים באמצעות שפת השאילתות של Logging.

אי אפשר להשתמש במסנני החרגה כדי לצמצם את השימוש בentries.write מכסת ה-API או את מספר הקריאות ל-entries.writeAPI. מסנני החרגה מופעלים אחרי שרשומות היומן מתקבלות על ידי Logging API.

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

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

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

_Required sink ביומן

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

LOG_ID("cloudaudit.googleapis.com/activity") OR
LOG_ID("externalaudit.googleapis.com/activity") OR
LOG_ID("cloudaudit.googleapis.com/system_event") OR
LOG_ID("externalaudit.googleapis.com/system_event") OR
LOG_ID("cloudaudit.googleapis.com/access_transparency") OR
LOG_ID("externalaudit.googleapis.com/access_transparency")

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

אי אפשר לשנות או למחוק את _Required sink ביומן.

_Default sink ביומן

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

NOT LOG_ID("cloudaudit.googleapis.com/activity") AND
NOT LOG_ID("externalaudit.googleapis.com/activity") AND
NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND
NOT LOG_ID("externalaudit.googleapis.com/system_event") AND
NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND
NOT LOG_ID("externalaudit.googleapis.com/access_transparency")

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

יעדי Sink

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

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

פרויקטGoogle Cloud

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

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

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

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

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

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

מגבלות על יעדים

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

  • כשמגדירים יעד ל-sink, צריך לספק את הנתיב המוגדר במלואו ולהשתמש בנקודת הקצה הגלובלית של השירות. אין תמיכה בנקודות קצה אזוריות של שירותים (REP), כמו pubsub.LOCATION.rep.googleapis.com.
  • אם אתם מעבירים רשומות ביומן לקטגוריית יומנים בפרויקט אחר Google Cloud , Error Reporting לא מנתח את הרשומות האלה ביומן. מידע נוסף מופיע במאמר סקירה כללית על Error Reporting.
  • המגבלות הבאות חלות כשמגדירים מערך נתונים ב-BigQuery כיעד של sink ליומן:

    • צריך להפעיל הרשאת כתיבה למערך הנתונים ב-BigQuery. לא מגדירים את היעד כמערך נתונים מקושר ב-BigQuery. מערכי נתונים מקושרים הם לקריאה בלבד.
    • הרישום יוצר טבלה בתוך מערך הנתונים לכל שם יומן. אי אפשר לשנות את השם של טבלה בזמן שמקור נתונים מעביר אליה נתונים.
  • יכול להיות שיחלפו כמה שעות עד ש-sinks חדשים שמנתבים רשומות ביומן לקטגוריות של Cloud Storage יתחילו לנתב את הרשומות. הנתונים בלוחות האלה מתעדכנים מדי שעה.
  • אין תמיכה בהעברת יומנים לנושא ב-Pub/Sub שמוגדרות בו הגבלות על נתונים במעבר. הרישום ביומן לא יכול להבטיח שבקשות פרסום מגיעות מאזור מותר, ולכן נגרמותtopic_region_not_allowed שגיאות בהגדרות ויומנים מושמטים.

  • ההגבלות הבאות חלות כש Google Cloud פרויקט הוא היעד של sink ביומן:

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

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

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

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

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

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

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

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

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

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

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

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

לשיטות מומלצות לשימוש בהעברה למשילות מידע (data governance) או לתרחישי שימוש נפוצים, אפשר לעיין במסמכים הבאים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אפשר לאחסן באופן מרכזי רשומות ביומן שתואמות ל_Required sink ביומן. כדי לאחסן את רשומות היומן האלה באופן מרכזי, אפשר לבצע אחת מהפעולות הבאות:

  • יוצרים מאגרי יומנים שמנתבים רשומות ביומן שתואמות למאגר היומנים _Required למאגר יומנים מרכזי.

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

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

תמחור

למידע על התמחור של Cloud Logging, אפשר לעיין בדף התמחור של Google Cloud Observability.

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

כדי לעזור לכם להעביר ולאחסן נתונים של Cloud Logging, תוכלו לעיין במסמכים הבאים: