צפייה ביומנים שמועברים ל-BigQuery

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

‫Cloud Logging משתמש בLegacy streaming API כדי להזרים את רשומות היומן ל-BigQuery. בדרך כלל, רשומות ביומן מופיעות ב-BigQuery תוך דקה. עם זאת, כשיוצרים טבלה חדשה, יכול להיות שיחלפו כמה דקות עד שרשומות היומן הראשונות יהיו זמינות.

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

לפני שמתחילים

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

הוראות לגבי ניתוב יומנים מופיעות במאמר ניתוב יומנים ליעדים נתמכים.

במאמר סכימת BigQuery ליומנים מנותבים מוסבר איך נקראים השדות של רשומות היומן המנותבות.

צפייה ביומנים

כדי לראות את היומנים שמועברים ל-BigQuery:

1. במסוף Google Cloud , עוברים לדף BigQuery:

   כניסה ל-BigQuery Studio

   אפשר גם להשתמש בסרגל החיפוש כדי למצוא את הדף הזה.

2. בחלונית Explorer מרחיבים את הפרויקט ובוחרים מערך נתונים.

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

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

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

דוגמה לשאילתת Compute Engine

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

• השאילתה מחפשת ביומנים syslog ו-apache-access מ-3 הימים האחרונים. השאילתה בוצעה ב-23 בפברואר 2020 והיא כוללת את כל הרשומות ביומן שהתקבלו ב-21 וב-22 בפברואר, בנוסף לרשומות ביומן שהתקבלו ב-23 בפברואר עד למועד שליחת השאילתה.

• השאילתה מאחזרת תוצאות עבור מכונה וירטואלית אחת ב-Compute Engine,‏ 1554300700000000000.

SELECT
  timestamp AS Time,
  logName as Log,
  textPayload AS Message
FROM
  (TABLE_DATE_RANGE(my_bq_dataset.syslog_,
    DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP())),
  (TABLE_DATE_RANGE(my_bq_dataset.apache_access_,
    DATE_ADD(CURRENT_TIMESTAMP(), -2, 'DAY'), CURRENT_TIMESTAMP()))
WHERE
  resource.type == 'gce_instance'
  AND resource.labels.instance_id == '1554300700000000000'
ORDER BY time;

כמה דוגמאות לשורות פלט:

Row | Time                    | Log                                         | Message
--- | ----------------------- | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------
 5  | 2020-02-21 03:40:14 UTC | projects/project-id/logs/syslog             | Feb 21 03:40:14 my-gce-instance collectd[24281]: uc_update: Value too old: name = 15543007601548826368/df-tmpfs/df_complex-used; value time = 1424490014.269; last cache update = 1424490014.269;
 6  | 2020-02-21 04:17:01 UTC | projects/project-id/logs/syslog             | Feb 21 04:17:01 my-gce-instance /USR/SBIN/CRON[8082]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
 7  | 2020-02-21 04:49:58 UTC | projects/project-id/logs/apache-access      | 128.61.240.66 - - [21/Feb/2020:04:49:58 +0000] "GET / HTTP/1.0" 200 536 "-" "masscan/1.0 (https://github.com/robertdavidgraham/masscan)"
 8  | 2020-02-21 05:17:01 UTC | projects/project-id/logs/syslog             | Feb 21 05:17:01 my-gce-instance /USR/SBIN/CRON[9104]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
 9  | 2020-02-21 05:30:50 UTC | projects/project-id/log/syslogapache-access | 92.254.50.61 - - [21/Feb/2020:05:30:50 +0000] "GET /tmUnblock.cgi HTTP/1.1" 400 541 "-" "-"

דוגמה לשאילתה ב-App Engine

השאילתה הבאה ב-BigQuery מאחזרת בקשות לא מוצלחות של App Engine מהחודש האחרון:

SELECT
  timestamp AS Time,
  protoPayload.host AS Host,
  protoPayload.status AS Status,
  protoPayload.resource AS Path
FROM
  (TABLE_DATE_RANGE(my_bq_dataset.appengine_googleapis_com_request_log_,
    DATE_ADD(CURRENT_TIMESTAMP(), -1, 'MONTH'), CURRENT_TIMESTAMP()))
WHERE
  protoPayload.status != 200
ORDER BY time

הנה כמה מהתוצאות:

Row | Time                    | Host                                  | Status | Path
--- | ----------------------- | ------------------------------------- | ------ | ------
 6  | 2020-02-12 19:35:02 UTC | default.my-gcp-project-id.appspot.com |    404 | /foo?thud=3
 7  | 2020-02-12 19:35:21 UTC | default.my-gcp-project-id.appspot.com |    404 | /foo
 8  | 2020-02-16 20:17:19 UTC | my-gcp-project-id.appspot.com         |    404 | /favicon.ico
 9  | 2020-02-16 20:17:34 UTC | my-gcp-project-id.appspot.com         |    404 | /foo?thud=%22what???%22

סכימת BigQuery ליומנים שמועברים לניתוב

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

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

מוסכמות למתן שמות לשדות

יש כמה מוסכמות למתן שמות שחלות על השדות של רשומות ביומן כששולחים יומנים ל-BigQuery:

• שמות השדות ברשומות ביומן לא יכולים להיות ארוכים מ-128 תווים.

• שמות השדות של רשומות ביומן יכולים לכלול רק תווים אלפאנומריים. כל התווים שלא נתמכים מוסרים משמות השדות ומוחלפים בקו תחתון. לדוגמה, המחרוזת jsonPayload.foo%% תומר למחרוזת jsonPayload.foo__.

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

• בשדות של רשומות ביומן ששייכים לסוג LogEntry, שמות השדות התואמים ב-BigQuery זהים בדיוק לשמות השדות של רשומות ביומן.

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

• בשדות במטענים ייעודיים (payloads) מובנים, כל עוד לא מופיע המציין @type, שמות השדות התואמים ב-BigQuery עוברים נורמליזציה לאותיות קטנות, אבל השמות עצמם נשמרים.

  מידע על מטענים מובְנים שבהם מופיע המציין @type זמין בקטע שדות של מטענים עם @type בדף הזה.

בדוגמאות הבאות אפשר לראות איך משתמשים במוסכמות האלה למתן שמות:

שדה של רשומה ביומן	LogEntry מיפוי סוגים	שם השדה ב-BigQuery
insertId	insertId	insertId
textPayload	textPayload	textPayload
httpRequest.status	httpRequest.status	httpRequest.status
httpRequest.requestMethod.GET	httpRequest.requestMethod.[ABC]	httpRequest.requestMethod.get
resource.labels.moduleid	resource.labels.[ABC]	resource.labels.moduleid
jsonPayload.MESSAGE	jsonPayload.[ABC]	jsonPayload.message
jsonPayload.myField.mySubfield	jsonPayload.[ABC].[XYZ]	jsonPayload.myfield.mysubfield

שדות המטען הייעודי עם @type

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

מטענים (payloads) ברשומות ביומן יכולים להכיל נתונים מובְנים. כל שדה מובנה יכול לכלול מציין סוג אופציונלי בפורמט הבא:

@type: type.googleapis.com/[TYPE]

כללים למתן שמות ב-@type

לשדות מובנים עם מפרטי סוגים בדרך כלל מוקצים שמות של שדות ב-BigQuery עם התוספת [TYPE] לשם השדה. הערך של [TYPE] יכול להיות כל מחרוזת.

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

כשמטפלים בשדות של מטען ייעודי (payload) מובנה ברמה העליונה, מערכת הרישום מסירה את הקידומת type.googleapis.com.

לדוגמה, בטבלה הבאה מוצג המיפוי של שדות המטען הייעודי (payload) המובנה ברמה העליונה לשמות השדות ב-BigQuery עבור רשומות ביומן שאינן יומני ביקורת:

Payload	‫Payload @type	שדה מטען ייעודי (payload)	שם השדה ב-BigQuery
jsonPayload	(ללא)	statusCode	jsonPayload.statusCode
jsonPayload	type.googleapis.com/abc.Xyz	statusCode	jsonpayload_abc_xyz.statuscode
protoPayload	(ללא)	statusCode	protoPayload.statuscode
protoPayload	type.googleapis.com/abc.Xyz	statusCode	protopayload_abc_xyz.statuscode

יש כמה חריגים לכללים הקודמים לגבי שדות עם מפרטי סוגים:

• ביומני הבקשות של App Engine, שם המטען הייעודי (payload) ביומנים שמועברים ל-BigQuery הוא protoPayload, גם אם המטען הייעודי כולל מפרט סוג.

• הטבלה שלמעלה לא רלוונטית ליומני ביקורת. ב-Cloud Logging מוחלים כמה כללים מיוחדים כדי לקצר את שמות השדות בסכימת BigQuery עבור יומני ביקורת. הנושא הזה מוסבר בקטע שדות ביומני ביקורת בדף הזה.

דוגמה

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

נניח שמטען ייעודי (payload) של רשומה ביומן בנוי באופן הבא:

jsonPayload: {
  @type: "type.googleapis.com/google.cloud.v1.CustomType"
    name_a: {
      sub_a: "A value"
    }
    name_b: {
      sub_b: 22
    }
  }

המיפוי לשדות ב-BigQuery הוא כדלקמן:

• השדה המובנה ברמה העליונה jsonPayload מכיל את המציין @type. השם שלה ב-BigQuery הוא jsonpayload_v1_customtype.

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

לכן, השמות הבאים ב-BigQuery מוגדרים עבור מטען הייעודי (payload) של רשומת היומן:

  jsonpayload_v1_customtype
  jsonpayload_v1_customtype._type
  jsonpayload_v1_customtype.name_b
  jsonpayload_v1_customtype.name_b.sub_b
  jsonpayload_v1_customtype.name_a
  jsonpayload_v1_customtype.name_a.sub_a

שדות ביומני ביקורת

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

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

@type: type.googleapis.com/[TYPE]

שינויים בשם השדה

כשיומן ביקורת מכיל מטען ייעודי (payload) עם מזהה @type, יכול להיות ש-Cloud Logging ישנה את הערך [TYPE] שמצורף למזהה לפני שנוצר שם השדה ב-BigQuery. השינויים האלה גורמים לשמות שדות קצרים יותר ב-BigQuery.

הרישום ביומן תמיד מסיר את הקידומת type.googleapis.com מהערך [TYPE]. בטבלה הבאה מתואר מתי הרישום ביומן מקצר את שמות השדות:

ערך מקורי [TYPE]	ערך [TYPE] שעבר שינוי
google.cloud.audit.AuditLog	AuditLog
google.appengine.legacy.AuditData	legacy.appengine
google.appengine.v1alpha.AuditData	v1alpha.appengine
google.appengine.v1beta.AuditData	v1beta.appengine
google.appengine.v1beta4.AuditData	v1beta4.appengine
google.appengine.v1beta5.AuditData	v1beta5.appengine
google.appengine.v1.AuditData	v1.appengine
google.cloud.bigquery.logging.v1.AuditData	v1.bigquery
google.iam.v1.logging.AuditData	v1.iam
google.iam.admin.v1.AuditData	v1.iam.admin
google.type.Money	money
google.appengine.logging.v1.RequestLog

לדוגמה, נניח שרשומה ביומן הביקורת מכילה את התוכן הבא:

{
  logName: "projects/REDACTED/logs/cloudaudit.googleapis.com%2Factivity"
  protoPayload: {
    @type: "type.googleapis.com/google.cloud.audit.AuditLog"
    serviceData: {
      @type: "type.googleapis.com/google.appengine.legacy.AuditData"
      eventData: {
        timezone: "UTC"
      }
    }
  }
}

שמות השדות ב-BigQuery נגזרים מהרשומה ביומן ששונתה, והם:

{
  logName: "projects/REDACTED/logs/cloudaudit.googleapis.com%2Factivity"
  protoPayload: {
    @type: "AuditLog"
    serviceData: {
      @type: "legacy.appengine"
      eventData: {
        timezone: "UTC"
      }
    }
  }
}

כללים למתן שמות ב-@type

ביומני הביקורת יש כמה שדות שיכולים לכלול @typeמציין:

• protoPayload
• protoPayload.serviceData
• protoPayload.request
• protoPayload.response
• protoPayload.metadata

השדות request, response ו-metadata מטופלים כנתוני JSON. כלומר, שמות הסכימות שלהם ב-BigQuery הם שמות השדות שלהם עם התוספת Json, והם מכילים נתוני מחרוזת בפורמט JSON.

בטבלה הבאה מפורטים שני סוגי השמות של שדות המטען הייעודי (payload) ביומן הביקורת:

שדה של רשומה ביומן	שם השדה ב-BigQuery
protoPayload	protopayload_auditlog
protopayload.metadata	protopayload_auditlog.metadataJson
protoPayload.request	protopayload_auditlog.requestJson
protoPayload.response	protopayload_auditlog.responseJson
protoPayload.serviceData	protopayload_auditlog.servicedata_v1_bigquery לדוגמה: protopayload_auditlog.servicedata_v1_bigquery.tableInsertRequest
protoPayload.status.code	protoPayload_auditlog.statuscode

שימו לב שמוסכמת השמות serviceData ספציפית ליומני ביקורת שנוצרים על ידי BigQuery ומועברים מ-Cloud Logging ל-BigQuery. הרשומות ביומן הביקורת כוללות שדה serviceData עם מציין @type של type.googleapis.com/google.cloud.bigquery.logging.v1.auditdata.

דוגמה

רשומה ביומן ביקורת שנוצרת על ידי BigQuery כוללת שדה עם השם הבא:

protoPayload.serviceData.tableInsertRequest

אם רשומת היומן הזו תנותב ל-BigQuery, איך תהיה ההפניה לשדה tableInsertRequest? לפני קיצור השם, שם השדה התואם ב-BigQuery היה:

protopayload_google_cloud_audit_auditlog.servicedata_google_cloud_bigquery_logging_v1_auditdata.tableInsertRequest

אחרי קיצור השם, השדה הזה יופיע בטבלאות BigQuery כך:

protopayload_auditlog.servicedata_v1_bigquery.tableInsertRequest

ארגון הטבלה

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

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

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

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

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

ארגון הטבלה

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

לשמות הטבלאות מתווספת סיומת של התאריך ביומן בפורמט הבסיסי של ISO 8601 (YYYYMMDD).

בטבלה הבאה מוצגות דוגמאות למיפוי של שמות יומנים וחותמות זמן לדוגמה לשמות של טבלאות ב-BigQuery:

שם יומן הביקורת	רשומה ביומן timestamp^1	שם הטבלה ב-BigQuery‏ (חלוקה לפי תאריך)	שם הטבלה ב-BigQuery‏ (מחולקת למחיצות)
syslog	2017-05-23T18:19:22.135Z	syslog_20170523	syslog
apache-access	2017-01-01T00:00:00.000Z	apache_access_20170101	apache_access
compute.googleapis.com/activity_log	2017-12-31T23:59:59.999Z	compute_googleapis_com_activity_log_20171231	compute_googleapis_com_activity_log

‫¹ חותמות הזמן ברשומות ביומן מופיעות לפי שעון UTC (זמן אוניברסלי מתואם).

יצירת טבלאות מחולקות למחיצות

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

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

• Google Cloud מסוף: ניתוב יומנים ליעדים נתמכים.

• ‫Google Cloud CLI: gcloud logging sinks create.

חוסר התאמה בסכימה

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

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

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

  לדוגמה, אם השדה jsonPayload.user_id של רשומה ראשונית ביומן הוא string, הרשומה הזו ביומן יוצרת טבלה עם סוג מחרוזת בשדה הזה. אם מאוחר יותר תתחילו לרשום ביומן את jsonPayload.user_id כ-array, תהיה אי התאמה בסכימה.

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

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

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

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

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

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

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

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

סכמת טבלת השגיאות

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

• ‫logEntry: מכיל את רשומת היומן המלאה, אבל רשומת היומן מומרת מ-JSON למחרוזת.
• ‫schemaErrorDetail: מכיל את הודעת השגיאה המלאה שהוחזרה על ידי BigQuery.
• ‫sink: מכיל את נתיב המשאב המלא של sink ביומן.
• ‫logName: חולץ מתוך LogEntry.
• ‫timestamp: חולץ מתוך LogEntry.
• ‫receiveTimestamp: חולץ מתוך LogEntry.
• ‫severity: חולץ מתוך LogEntry.
• ‫insertId: חולץ מתוך LogEntry.
• ‫trace: חולץ מתוך LogEntry.
• ‫resourceType: חולץ מתוך LogEntry.

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

• ‫Project Owners מקבלים אימייל. הפרטים כוללים: Google Cloud מזהה הפרויקט, שם היעד והיעד.
• בדף הפעילות במסוף מוצגת שגיאה, Stackdriver Config error. Google Cloud הפרטים כוללים את שם היעד ואת היעד, וקישור לדוגמה של רשומה ביומן שגרמה לשגיאה.

איך למנוע בעיות של חוסר התאמה בין סוגי שדות בעתיד

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

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

פתרון בעיות

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

תמחור

למידע על מחירים, אפשר לעיין בדף תמחור של Google Cloud Observability. אם אתם מעבירים נתוני יומן לשירותים אחרים, כדאי לעיין במסמכים הבאים: Google Cloud

• תמחור של Cloud Storage
• תמחור ב-BigQuery
• תמחור של Pub/Sub