בעזרת Observability Analytics אתם יכולים להריץ שאילתות SQL כדי לנתח את היומנים, ליצור תצוגות ניתוח נתונים, לקשר בין קטגוריות ביומן למערכי נתונים ב-BigQuery ולעקוב אחרי תוצאות השאילתות באמצעות מדיניות התראות. אם נתקלתם בשגיאות כשניסיתם להגדיר את Observability Analytics או לשלוח שאילתות, אתם יכולים להיעזר בהנחיות שבמאמר הזה כדי לזהות ולפתור אותן. נתקלתם בבעיות בשדרוג של קטגוריית יומנים? קראו את המאמר פתרון בעיות בשדרוג של קטגוריה לשימוש ב-Observability Analytics.
הודעות שגיאה
בקטע הזה מתוארות הודעות השגיאה שעשויות להופיע, ואיך לפתור את מצבי השגיאה המתאימים.
הודעת השגיאה No completion signal within allotted timeframe
מזינים שאילתת SQL ולוחצים על Run query. השאילתה לא מסתיימת ומופיעה הודעת השגיאה הבאה:
The query failed to execute and return results due to error: No completion signal within allotted timeframe.
כדי לפתור את השגיאה הזו, מבצעים אחת מהפעולות הבאות:
מקצרים את מרווח הזמן של השאילתה ביומנים ומנסים שוב. לדוגמה, אם מרווח הזמן של השאילתה הוא 14 ימים, מקצרים את המרווח ל-7 ימים ואז מריצים את השאילתה.
יוצרים מערך נתונים מקושר ב-BigQuery ואז מריצים את השאילתה מהממשק של BigQuery. הממשק של BigQuery תומך בשאילתות שדורשות זמן ביצוע ארוך יותר מאשר הממשק של Cloud Logging. מידע נוסף זמין במאמר יצירת מערך נתונים מקושר ב-BigQuery.
הודעת שגיאה בשאילתות בקטגוריות עם מפתחות CMEK נפרדים
מזינים שאילתת SQL ששולחת שאילתות לכמה קטגוריות של יומנים ובוחרים באפשרות Run query. השאילתה לא מסתיימת ומופיעה הודעת השגיאה הבאה:
Queries against buckets with distinct CMEK keys must have a key configured in the LogSettings.
כדי לפתור את הבעיה, אתם יכולים לבצע אחת מהפעולות הבאות:
- מגדירים את קטגוריות היומנים כך שישתמשו באותו מפתח של Cloud Key Management Service (Cloud KMS).
- כשהתיקיות של היומנים נמצאות באותו מיקום, אתם יכולים להגדיר תיקייה או ארגון שהם משאב הורה של התיקיות של היומנים עם מפתח Cloud KMS שמוגדר כברירת מחדל. מפתח ברירת המחדל של ההורה צריך להיות באותו מיקום שבו נמצאים מאגרי היומנים. בהגדרה הזו, מפתח ברירת המחדל של ההורה מצפין את כל הנתונים הזמניים שנוצרים על ידי השאילתה של Observability Analytics. מידע נוסף זמין במאמר הגבלות על Observability Analytics.
הודעת השגיאה FROM clause must contain exactly one log view
אתם מזינים שאילתת SQL בחלונית השאילתות בדף Observability Analytics במסוף Google Cloud , אבל מנתח ה-SQL מציג את השגיאה הבאה:
FROM clause must contain exactly one log view
השגיאה הקודמת מדווחת כשהטבלה שצוינה בהצהרה FROM לא יכולה להסתנכרן עם תצוגת יומן ספציפית.
כדי לפתור את השגיאה הזו, צריך לוודא שהתחביר של שם הטבלה נכון:
חשוב לוודא ששם הטבלה תואם לתחביר שנדרש לפי סכמת מתן השמות של Observability Analytics. ל-BigQuery ול-Observability Analytics יש דרישות שונות לגבי שם הטבלה. כדי למצוא את התחביר הנדרש לשם הטבלה, אפשר להציג את שאילתת ברירת המחדל.
אם מזהה הפרויקט, האזור, מזהה הקטגוריה או מזהה התצוגה של קטגוריית היומנים ב- Google Cloud מכילים נקודות (
(.)), צריך לוודא שכל אחד מהשדות האלה מוקף בגרש הפוך ((`)).לדוגמה, אם מזהה הפרויקט ב- Google Cloud הוא
example.com:bluebird, כדי לשלוח שאילתה לתצוגה_AllLogsשל קטגוריית היומנים_Default, צריך לציין את הטבלה באמצעות התחביר הבא:SELECT * FROM `example.com:bluebird`.`global`.`_Default`.`_AllLogs`השאילתה הקודמת מניחה שהקטגוריה
_Defaultנמצאת באזורglobal.
לא ניתן לשמור שאילתה
אתם רוצים לשמור את השאילתה הנוכחית, אז אתם מריצים אותה ולוחצים על Save, אבל האפשרות Save query מושבתת או שאתם לא מצליחים להשלים את השלבים בתיבת הדו-שיח.
הסיבה לכך היא התנגשות בין מדיניות הארגון לבין הגדרות ברירת המחדל של המשאבים ב-Cloud Logging. בארגון או בתיקייה, אתם יכולים להגדיר הגדרות ברירת מחדל למשאבים ב-Cloud Logging שמציינות מיקום. במיקום הזה מאוחסנות השאילתות השמורות. עם זאת, אם המיקום מתנגש עם מדיניות הארגון, לא תוכלו לשמור את השאילתות.
כדי לפתור את הבעיה, צריך לבקש מהאדמין של הארגון לעדכן את הגדרות ברירת המחדל של המשאבים ב-Cloud Logging, כך שהגדרת המיקום תהיה מותרת לפי מדיניות הארגון. מידע נוסף זמין במאמר הגדרת ברירת המחדל של המשאבים ב-Cloud Logging.
אם האפשרות Save query מופעלת אבל אתם לא מצליחים להשלים את תיבת הדו-שיח ולשמור את השאילתה, בצעו את הפעולות הבאות:
- מוודאים שאין שגיאות תחביר בשאילתה. אפשר לשמור רק שאילתות תקינות.
- אופציונלי: מעתיקים את השאילתה ללוח.
- צריך לטעון מחדש את הדף.
- אם העתקתם את השאילתה ללוח, מדביקים אותה בחלונית Query, מריצים אותה ואז שומרים אותה.
אי אפשר ליצור תצוגת ניתוח נתונים
אתם רוצים ליצור תצוגת ניתוח נתונים, אז אתם מזינים ומריצים שאילתת SQL ואז לוחצים על Save, אבל האפשרות Save as analytic view מושבתת.
כדי לפתור את הבעיה, ודאו שהתפקידים שלכם ב-IAM כוללים את ההרשאות הבאות:
observability.analyticsViews.{get, list, create, update, delete}
ההרשאות האלה לא כלולות באף תפקיד מוגדר מראש של Cloud Logging. למידע על התפקידים הנדרשים, קראו את המאמר יצירה ושאילתות של תצוגות ניתוח נתונים: לפני שמתחילים.
לא ניתן לשלוח שאילתה לתצוגת ניתוח נתונים
אתם רוצים לשלוח שאילתה לתצוגת ניתוח נתונים, אבל בחלונית Views בדף Observability Analytics לא מוצגות תצוגות של ניתוח נתונים.
כדי לפתור את הבעיה, נסו את הפתרונות הבאים:
מוודאים שתפקידי ה-IAM כוללים את ההרשאות הבאות:
observability.analyticsViews.{get, list}
ההרשאות האלה לא כלולות באף תפקיד מוגדר מראש של Cloud Logging. למידע על התפקידים הנדרשים, קראו את המאמר יצירה ושאילתות של תצוגות ניתוח נתונים: לפני שמתחילים.
מוודאים שקיימות תצוגות של ניתוח נתונים בפרויקט ב- Google Cloud .
אין גישה לדף Observability Analytics
אתם פותחים את הדף Observability Analytics במסוף Google Cloud ומוצגת הודעת השגיאה "אין הרשאה".
כדי לקבל את ההרשאות שנדרשות לטעינת הדף Observability Analytics, להרצת שאילתות ולצפייה ביומנים, בקשו מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:
-
צפייה ביומנים:
מציג היומנים (
roles/logging.viewer) -
צפייה ביומנים בקטגוריות של יומנים בהתאמה אישית: גישה לתצוגת יומנים (
roles/logging.viewAccessor)
יכול להיות שתוכלו לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש של רישום ביומן.
ההרשאות שנדרשות כדי לצפות ברשומות ביומן ולהריץ שאילתות בדף Observability Analytics זהות להרשאות שנדרשות כדי לצפות ביומנים בדף Logs Explorer. במאמר תפקידים ב-Cloud Logging מפורטים תפקידים נוספים שנדרשים כדי לשלוח שאילתות לתצוגות בקטגוריות שהוגדרו על ידי המשתמשים, או כדי לשלוח שאילתות לתצוגה _AllLogs של קטגוריית היומנים _Default.
יצירת קטגוריית יומנים נכשלת בגלל אילוץ מיקום
ניסיתם ליצור קטגוריית יומנים, אבל הפעולה נכשלה והופיעה הודעה דומה לזו:
Constraint `constraints/gcp.resourceLocations` violated for `<CONTAINER>` attempting to change `<BUCKET_NAME>` with location `<LOCATION>`. The location must be in the allowed location list configured by the organization policy administrator.
הודעת השגיאה הקודמת מציינת שהמיקום שבחרתם בשביל קטגוריית היומנים החדשה לא נתמך על ידי הארגון שלכם.
כדי לפתור את הבעיה, צריך לבחור מיקום שנתמך על ידי הארגון.
יצירת מערך נתונים מקושר ב-BigQuery נכשלה
אתם עורכים תיקיית יומנים כדי ליצור מערך נתונים מקושר ב-BigQuery, או שאתם יוצרים תיקיית יומנים חדשה ובוחרים באפשרות ליצור מערך נתונים מקושר ב-BigQuery, אבל מערך הנתונים המקושר ב-BigQuery לא נוצר.
כדי לפתור את השגיאה, צריך לבקש מהאדמין של הפרויקט Google Cloud להקצות לכם תפקיד ב-IAM שכולל את ההרשאה הבאה:
logging.links.create
ההרשאה הקודמת כלולה בתפקידים "אדמין של רישום ביומן" (roles/logging.admin) ו"כתיבה של הגדרות יומנים" (roles/logging.configWriter).
במאמר בקרת גישה באמצעות IAM מוסבר על תפקידים והרשאות.
מחיקה של מערך נתונים מקושר ב-BigQuery נכשלה
אתם לא רוצים יותר את מערך הנתונים המקושר ב-BigQuery, אבל האפשרות למחוק אותו מושבתת.
כדי לפתור את השגיאה, צריך לבקש מהאדמין של הפרויקט Google Cloud להקצות לכם תפקיד ב-IAM שכולל את ההרשאה הבאה:
logging.links.delete
ההרשאה הקודמת כלולה בתפקידים "אדמין של רישום ביומן" (roles/logging.admin) ו"כתיבה של הגדרות יומנים" (roles/logging.configWriter).
ההרשאה הזו מאפשרת למחוק את מערך הנתונים המקושר ב-BigQuery מהדף Logs Storage במסוף Google Cloud . במאמר בקרת גישה באמצעות IAM תוכלו לקרוא מידע נוסף על תפקידים והרשאות.
אזהרה ב-Observability Analytics לגבי מטא-נתונים רגישים
בדף Observability Analytics מופיעה הודעה דומה לזו:
This SQL query is configured to run on the BigQuery engine using [PROJECT_ID],
and references resources from [RESOURCE, ...]. Sensitive metadata,
including table contents, may be written to [PROJECT_ID].
הודעת האזהרה מציינת שהשאילתה חוצה את גבולות הבעלות, ומאפשרת לכם לאמת את השאילתה לפני שהיא מופעלת. גבולות הבעלות נקבעים לפי כמה גורמים, אחד מהם הוא ההיררכיה של המשאבים שבהם השאילתה משתמשת.
אי אפשר למנוע את האזהרות האלה.
אם בדף Observability Analytics מופיעה תיבת דו-שיח עם אזהרה, אתם יכולים:
אם אתם יודעים שהשאילתה בטוחה להרצה ואתם רוצים לראות את תוצאות השאילתה, לחצו על Confirm and Run.
מנתחים את השאילתה, ואם צריך, מבטלים אותה. לדוגמה, אתם יכולים:
- בודקים את השאילתה. בבדיקה, כדאי לבדוק אילו נתונים נשלפים בשאילתה, מה הגודל הפוטנציאלי של מערך הנתונים שנשלף בשאילתה ומהו מנוע השאילתות. יכול להיות שתחויבו על שאילתות שמופעלות בשירות BigQuery.
- אם נשלח אליכם קישור לדף Observability Analytics, ודאו שהשולח הוא מקור מהימן.
ב-Google Cloud יש כמה תכונות שיכולות לעזור למנוע זליגת נתונים באמצעות פישינג, התקפות פנימיות או ישויות חיצוניות. מידע נוסף זמין במאמר אבטחת מידע באמצעות Observability Analytics.
השאילתה במערך נתונים מקושר ב-BigQuery נכשלת כי מערך הנתונים לא נמצא
שלחתם שאילתה למערך נתונים מקושר ב-BigQuery, והפקודה נכשלה עם הודעת שגיאה כמו "Dataset not found".
כדי לפתור את הבעיה, נסו את הפתרונות הבאים:
- מוודאים שהנתיב לשם של מערך הנתונים נכון.
מריצים את הפקודה הבאה של
gcloud logging links listומוודאים שבתגובה מופיעה קבוצת הנתונים המקושרת ב-BigQuery.אם קבוצת הנתונים המקושרת ב-BigQuery לא מופיעה ברשימה, סימן שהיא מנותקת. כדי לפתור את הבעיה, צריך למחוק את מערך הנתונים המקושר ב-BigQuery.
יכול להיות שלפרויקט יהיה מערך נתונים מקושר מיותם ב-BigQuery אם תבטלו את ההקצאות של תפקידי IAM מחשבון שירות שמשמש את Google Cloud Observability לניהול נתונים, ואז תמחקו את הקישור בתיקיית היומנים. במקרה כזה, אי אפשר למחוק את מערך הנתונים המקושר ב-BigQuery באמצעות Google Cloud Observability.
לא ניתן להגדיר את מנוע השאילתות ל-BigQuery
האפשרות BigQuery מושבתת בתפריט ההגדרות של settings.
כדי להפעיל את האפשרות הזו, ודאו שיש לכם מערך נתונים מקושר של BigQuery בתיקיית היומנים שאתם שולחים אליה שאילתות.
הכפתור "הפעלה ב-BigQuery" מושבת
אם הלחצן Run on BigQuery מוצג אבל מושבת, סימן שלתצוגת היומן שהשאילתה מפנה אליה אין מערך נתונים מקושר ב-BigQuery. כדי להריץ את השאילתה במנוע של BigQuery, צריך ליצור מערך נתונים מקושר של BigQuery בקטגוריית היומנים.
אין חשבון שירות ב-Monitoring
אתם רוצים ליצור מדיניות התראות כדי לעקוב אחרי התוצאות של שאילתת SQL. בשלבי ההגדרה צריך להקצות תפקידי IAM לחשבון השירות של Monitoring, אבל החשבון הזה לא קיים.
חשבון השירות של Monitoring נקרא סוכן שירות כי הוא נוצר ומנוהל על ידיGoogle Cloud. החשבון נוצר באופן אוטומטי כשמגדירים משאב או שירות שדורשים את החשבון. לדוגמה, אם יוצרים ערוץ התראות ב-Pub/Sub, הפעולה הזו עשויה לגרום ליצירת חשבון השירות של Monitoring.
כדי ליצור את חשבון השירות של Monitoring ולתת לו את ההרשאות שנדרשות למדיניות התראות שמבוססת על SQL:
יוצרים את חשבון השירות למעקב. מידע נוסף זמין במאמר איך יוצרים סוכני שירות ומעניקים להם תפקידים.
מקצים לחשבון השירות של Monitoring את התפקידים הבאים:
- סוכן שירות למעקב (
roles/monitoring.notificationServiceAgent) בפרויקט. - BigQuery Data Viewer (
roles/bigquery.dataViewer) במערך הנתונים המקושר ב-BigQuery.
- סוכן שירות למעקב (
שגיאה: נדחתה הרשאה לחשבון שירות של Monitoring
אתם רוצים ליצור מדיניות התראות כדי לעקוב אחרי התוצאות של שאילתת SQL.
עם זאת, מופיעה השגיאה PermissionDenied עם הודעה שמתחילה ב-Error authenticating service account.
כדי לפתור את הבעיה, צריך להקצות לחשבון השירות של Monitoring את התפקידים הבאים:
- סוכן שירות למעקב (
roles/monitoring.notificationServiceAgent) בפרויקט. - BigQuery Data Viewer (
roles/bigquery.dataViewer) במערך הנתונים המקושר ב-BigQuery.
יש רשומות כפולות ביומן בתוצאות של Observability Analytics
אתם מריצים שאילתה שסופרת או מדווחת על רשומות כפולות. ב-Logs Explorer רשומות כפולות מוסרות על סמך שם היומן, חותמת הזמן ומזהה ההוספה, ולכן אתם מצפים ש-Observability Analytics יבטל כפילויות של רשומות ביומן לפני הרצת השאילתה.
ב-Observability Analytics לא מתבצעת אותה הסרה של כפילויות כמו ב-Logs Explorer.
כדי לפתור את הבעיה של רשומות כפולות ביומן, נסו את הפתרונות הבאים:
בודקים אם לרשומות הכפולות ביומן יש ערכים שונים של חותמות זמן לקבלה. אם חותמות הזמן שונות, סימן שאותם נתונים נכתבו ב-Logging כמה פעמים.
כדי לפתור את הבעיה של כתיבה כפולה, צריך לבדוק אם יש הודעות שגיאה או הגדרות שגויות בשילוב של הרישום ביומן.
אם הקטגוריה מוגדרת לשימוש במפתחות של Cloud Key Management Service, צריך לוודא שלא חרגתם מהמכסה ושהמפתח נגיש באופן עקבי. חריגה מהמכסה או אובדן הגישה למפתח עלולים לגרום לרשומות כפולות ביומן.
כדי לפתור את הבעיות האלה, ודאו שלא חרגתם מהמכסה ושהמפתח נגיש.
משנים את השאילתה כדי להסיר רשומות כפולות ביומן.
לדוגמה, נניח שהמטען הייעודי (payload) של ה-JSON מכיל את
fieldAו-fieldB, כשהראשון הוא מחרוזת והשני הוא מספר. נניח גם שהמטען הייעודי (payload) של ה-JSON מכיל שדה עם התוויתserver, שמכיל מחרוזת. עכשיו נבחן את השאילתה הבאה:SELECT JSON_VALUE(json_payload.fieldA) AS fieldA, SUM(IFNULL(SAFE_CAST(JSON_VALUE(json_payload.fieldB) AS INT64), 0)) AS sum_fieldB FROM `VIEW` WHERE JSON_VALUE(json_payload.server) = "test" GROUP BY fieldA;אפשר לשנות את השאילתה כדי להסיר רשומות כפולות ביומן. שם היומן, חותמת הזמן ומזהה ההוספה נבדקים כדי לקבוע אם רשומת היומן כפולה:
WITH deduplicated AS ( SELECT JSON_VALUE(json_payload.fieldA) AS fieldA, IFNULL(SAFE_CAST(JSON_VALUE(json_payload.fieldB) AS INT64), 0) AS fieldB FROM `VIEW` a WHERE JSON_VALUE(json_payload.server) = "test" QUALIFY ROW_NUMBER() OVER (PARTITION BY a.log_name, a.timestamp, a.insert_id ) = 1 ) SELECT fieldA, SUM(fieldB) AS sum_fieldB FROM deduplicated GROUP BY fieldA;