פתרון בעיות בהגדרת Observability Analytics

במסמך הזה מוסבר איך לפתור שגיאות שעשויות להתרחש כשמשתמשים בדף Observability Analytics במסוף Google Cloud .

הודעות שגיאה

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

הודעת השגיאה 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 ששולפת נתונים מכמה מאגרי יומנים ולוחצים על הפעלת שאילתה. השאילתה לא מסתיימת ומופיעה הודעת השגיאה הבאה:

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. מידע נוסף זמין במאמר בנושא הגבלות על ניתוח נתונים של יכולת התבוננות.

המשפט FROM חייב להכיל בדיוק הודעת שגיאה אחת של תצוגה

מזינים שאילתת SQL בחלונית השאילתות בדף Observability Analytics במסוף Google Cloud , אבל מנתח ה-SQL מציג את השגיאה הבאה:

FROM clause must contain exactly one log view

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

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

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

  • אם מזהה הפרויקט, האזור, מזהה הקטגוריה או מזהה התצוגה של קטגוריית יומנים מכילים נקודות, (.), צריך לוודא שכל אחד מהשדות האלה מוקף במירכאות הפוכות בודדות, (`). Google Cloud

    לדוגמה, אם מזהה הפרויקט הוא example.com:bluebird, כדי לשלוח שאילתה לתצוגה _AllLogs של קטגוריית היומן _Default, צריך להשתמש בתחביר הבא כדי לציין את הטבלה: Google Cloud 

    
SELECT *
FROM `example.com:bluebird`.`global`.`_Default`.`_AllLogs`

    השאילתה הקודמת מניחה שקטגוריית _Default נמצאת באזור global.

לא ניתן לשמור שאילתה

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

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

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

אם האפשרות שמירת שאילתה מופעלת אבל אי אפשר להשלים את תיבת הדו-שיח ולשמור את השאילתה, צריך לבצע את הפעולות הבאות:

  1. מוודאים שהשאילתה לא מכילה שגיאות תחביר. אפשר לשמור רק שאילתות תקינות.
  2. אופציונלי: מעתיקים את השאילתה ללוח.
  3. צריך לטעון מחדש את הדף.
  4. אם העתקתם את השאילתה ללוח, מדביקים אותה בחלונית Query, מריצים את השאילתה ומבצעים את פעולת השמירה.

אי אפשר ליצור תצוגת ניתוח נתונים

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

כדי לפתור את הבעיה, צריך לוודא שתפקידי ה-IAM שלכם כוללים את ההרשאות הבאות:

  • observability.analyticsViews.{get, list, create, update, delete}

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

אי אפשר להריץ שאילתה בתצוגת ניתוח נתונים

אתם רוצים לשלוח שאילתה לתצוגת ניתוח נתונים, אבל בחלונית Views בדף Observability Analytics לא מוצגות תצוגות ניתוח נתונים.

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:

הגישה לדף Observability Analytics נדחתה

כשפותחים את הדף Observability Analytics במסוף Google Cloud , מוצגת הודעת שגיאה על דחיית הרשאה.

כדי לקבל את ההרשאות שדרושות לטעינת הדף Observability Analytics, להפעלת שאילתות ולצפייה ביומנים, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

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

ההרשאות שנדרשות כדי לצפות ברשומות ביומן ולהריץ שאילתות בדף Observability Analytics זהות לאלה שנדרשות כדי לצפות ביומנים בדף Logs Explorer. מידע על תפקידים נוספים שצריך כדי להריץ שאילתות בתצוגות של קטגוריות שהוגדרו על ידי המשתמש או כדי להריץ שאילתות בתצוגה _AllLogs של קטגוריה ביומן _Default זמין במאמר בנושא תפקידים ב-Cloud Logging.

השדרוג של קטגוריית יומנים לשימוש ב-Observability Analytics נכשל

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

Failed precondition (HTTP 400): Constraint "my-constraint" violated for PROJECT_ID  with location global.

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

היצירה של מערך נתונים מקושר ב-BigQuery נכשלת

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

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

  • logging.links.create

ההרשאה הקודמת כלולה בתפקידים Logging Admin (אדמין של Logging,‏ roles/logging.admin) ו-Logs Configuration Writer (כותב הגדרות של יומנים,‏ roles/logging.configWriter).

מידע על תפקידים והרשאות זמין במאמר בקרת גישה באמצעות IAM.

מחיקה של מערך נתונים מקושר ב-BigQuery נכשלת

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

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

  • logging.links.delete

ההרשאה הקודמת כלולה בתפקידים Logging Admin (אדמין של Logging,‏ roles/logging.admin) ו-Logs Configuration Writer (כותב הגדרות של יומנים,‏ 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, אפשר לבצע אחת מהפעולות הבאות:

  • אם אתם יודעים שהשאילתה בטוחה להרצה ורוצים לראות את התוצאות שלה, לוחצים על אישור והרצה.

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

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

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

אי אפשר להגדיר את מנוע השאילתות ל-BigQuery

האפשרות BigQuery בתפריט Settings מושבתת.

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

הכפתור 'הפעלה ב-BigQuery' מושבת

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

אין חשבון שירות לניטור

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

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

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

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

  2. מקצים לחשבון השירות של Monitoring את התפקידים הבאים:

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

רוצים ליצור מדיניות התראות כדי לעקוב אחרי התוצאות של שאילתת SQL. עם זאת, מוצגת שגיאת PermissionDenied עם הודעה שמתחילה ב-Error authenticating service account.

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

יש כפילויות ברשומות ביומן בתוצאות של Observability Analytics

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

ניתוח נתונים של יכולת התבוננות לא מבצע את אותו סוג של ביטול כפילויות שמבוצע על ידי הכלי 'Logs Explorer'.

כדי לפתור בעיה של רשומות כפולות ביומן, אפשר לנסות את הפעולות הבאות:

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

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

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

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

  3. משנים את השאילתה כדי להסיר רשומות כפולות ביומן.

    לדוגמה, נניח שמטען ה-JSON מכיל את הערכים fieldA ו-fieldB, כאשר הראשון הוא מחרוזת והשני הוא ערך מספרי. בנוסף, נניח שמטען ה-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;