פתרון בעיות

במסמך הזה מוסבר איך לפתור בעיות נפוצות שקשורות ל-Cloud Trace, כמו נתוני span חסרים, כשלים בשאילתות ב-Observability Analytics ושגיאות אימות כשיוצרים מדיניות התראות.

בעיות מוכרות

בקטע הזה מפורטות בעיות מוכרות:

• לא ניתן לגשת לטווחים שנכתבו ל Google Cloud פרויקט באמצעות Telemetry API דרך Cloud Trace API. לדוגמה, אם תנסו לרשום את העקבות האלה, הפקודה תיכשל עם שגיאה 404 Not Found.

פתרון בעיות ב-Observability Analytics

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

אי אפשר לשמור את מדיניות ההתראות בגלל שגיאת אימות

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

The following error occurred when validating your SQL Alert: Error authenticating service account `[e-mail]`. BigQuery returned an error.

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

כדי לפתור את הבעיה, מבצעים את הפעולות הבאות:

1. במסוף Google Cloud , נכנסים לדף APIs & Services ומפעילים את Cloud Monitoring API:

   עוברים אל APIs & Services

2. נכנסים לדף IAM במסוף Google Cloud :

   כניסה לדף IAM

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

3. בדף IAM, מבצעים את הפעולות הבאות:

   1. בוחרים באפשרות Include Google-provided role grants.

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

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

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

      • ‫Monitoring Service Agent (roles/monitoring.notificationServiceAgent) בפרויקט.
      • BigQuery Data Viewer (roles/bigquery.dataViewer) במערך הנתונים המקושר של BigQuery.
      הערה: מומלץ להגביל את ההרשאה לתפקיד BigQuery Data Viewer למערך הנתונים המקושר ב-BigQuery של נתוני העקבות. אל תקצו את התפקיד הזה ברמת הפרויקט.

הודעת שגיאה שמודיעה שתצוגה לא קיימת

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

projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID/datasets/DATASET_ID/views/OBS_VIEW_ID does not exist

השגיאה הקודמת מדווחת אם לא ניתן למצוא את התצוגה שצוינה בהצהרה FROM.

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

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

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

  לדוגמה, אם מזהה הפרויקט שלכם Google Cloud הוא example.com:bluebird, אז ההצהרה FROM תהיה:

  FROM `example.com:bluebird`.`us`.`_Trace`.`Spans`.`_AllSpans`
  

מוצגת ההודעה 'תחילת העבודה עם Observability Analytics'

פותחים את הדף Observability Analytics ומוצג חלון עם הודעה דומה לזו:

Get started with Observability Analytics

כדי להשתמש ב-Observability Analytics, לוחצים על סגירה בחלון.

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

הצטרפות של כמה תצוגות נכשלת

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

לא ניתן להצטרף לכל הצפיות.

ההגבלות הבאות חלות על הצטרפות לתצוגות:

1. המיקומים של התצוגות עומדים באחד מהתנאים הבאים:

   • לכל התצוגות יש את אותו המיקום.
   • כל התצוגות נמצאות במיקום global או us.

2. כשמשאבי אחסון משתמשים במפתחות הצפנה בניהול הלקוח (CMEK), אחד מהתנאים הבאים מתקיים:

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

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

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

• משאבי האחסון לא משתמשים ב-CMEK.
• משאב אחסון אחד משתמש ב-CMEK והשני לא.
• שני משאבי האחסון משתמשים ב-CMEK ובאותו מפתח Cloud KMS.

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

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

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

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

ERROR: (gcloud.beta.observability.buckets.datasets.links.create) {
  "code": 7,
  "message": "The caller does not have permission"
}

כדי לפתור את הבעיה:

• מוודאים שקיבלתם את התפקידים הנדרשים ב-IAM. לרשימת התפקידים האלה, ראו יצירת קישור למערך נתונים.

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

אין נתונים בדף Trace Explorer

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

יכולות להיות כמה סיבות לכך שלא ניתן להציג את נתוני המעקב:

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

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

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

כדי לראות את נתוני העקבות, צריך לוודא שהוקצה לכם התפקיד Cloud Trace User ‏ (roles/cloudtrace.user).

אימות של שליחת טווחים של מעקב לפרויקט

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

1. מפעילים את Cloud Trace API ואת Telemetry API.

   תפקידים שנדרשים להפעלת ממשקי API

   כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin). כך מקצים תפקידים.

   הפעלת ממשקי ה-API

   שני ממשקי ה-API יכולים לקבל נתונים של טווחים של מעקב. עם זאת, מומלץ להשתמש ב-Telemetry API כי הוא תואם לאקוסיסטם של OpenTelemetry, ויש לו מגבלות נדיבות יותר מאלה של Cloud Trace API.

   הערה: יכול להיות שקיימים כללי מדיניות של הארגון שהשביתו את Cloud Trace API. כללי המדיניות האלה מונעים הפעלה של ה-API.

2. עוברים לדף Enabled APIs and Services, ומחפשים את השורות של Cloud Trace API ו-Telemetry API.

   אם הערך של Requests (בקשות) בשני ממשקי ה-API האלה הוא אפס, סימן שלא נשלחים לפרויקט נתוני מעקב.

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

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

1. עוברים לדף Enabled APIs and Services, מאתרים את השורות של Cloud Trace API ו-Telemetry API ובודקים את העמודה Errors.

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

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

   • ‫Cloud Trace API: ‏ Cloud Trace Agent Role (roles/cloudtrace.agent).
   • ‫Telemetry API: Cloud Telemetry Trace Writer (roles/telemetry.tracesWriter).

איך מוודאים שנתוני העקבות מאוחסנים

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

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

• Google Cloud הוראות למסוף:

  1. נכנסים לדף Trace explorer במסוף Google Cloud :

     כניסה אל Trace explorer

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

1. אם מופיע באנר דומה לזה שמוצג בהמשך, המשמעות היא שלא הוקצה אחסון לנתוני העקבות. none {: .devsite-disable-click-to-copy} Trace storage is not initialized for this project. Enable trace storage to begin collecting trace data. כדי להקצות קטגוריה של נתונים שניתנים לצפייה לנתוני המעקב, עוברים לבאנר ולוחצים על הפעלה. כשלוחצים על הפעלה, יחידה לוגית למעקב נשלחת לפרויקט. אחרי שהמערכת מקבלת את יחידה לוגית למעקב, היא מנפיקה את הפקודה ליצירת קטגוריה של ניראות (observability) בשם _Trace. התהליך הזה יכול להימשך כמה דקות. אחרי שההקצאה תושלם, יופיע באנר התראה, ו-Cloud Trace יקלוט את כל נתוני המעקב שנשלחו בשעה האחרונה. יכול להיות שיחלפו כמה דקות עד שהנתונים יופיעו בכלי לבדיקת נתיב התעבורה. אם לא מופיעים נתונים, צריך לרענן את הדף.

   1. אם הפקודה להפעלה נכשלת, מוצגת ההודעה הבאה:

      Initializing trace storage has failed for an unexpected reason. Please file a support ticket for assistance.
      

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

• הוראות ל-API:

  1. הצגת רשימה של קטגוריות של נתוני Observability

  2. אם בפרויקט שלכם אין קטגוריית _Trace, צריך ליצור אחת.

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

חיפוש של עקבות ספציפי נכשל

מזינים מזהה מעקב בדף Trace Explorer. המעקב לא נמצא ומוצגת הודעה דומה לזו:

The selected trace with ID abcde does not exist or is older than 30 days and has been deleted per our retention policy.

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

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

2. מזהים את Google Cloud הפרויקט שבו מאוחסן ה-trace, ומוודאים שבכלי לבחירת משאבים במסוף Google Cloud הפרויקט הזה נבחר. כברירת מחדל, בדף Trace Explorer יש גישה רק לנתוני מעקב שמאוחסנים בפרויקט שנבחר.

חסרים נתונים ישנים יותר בדף Trace Explorer

אתם משתמשים בדף Trace Explorer ויכולים לראות נתונים מהזמן האחרון, אבל כשאתם מגדירים את בורר טווח הזמן ל-30 ימים או לערך גדול יותר, הנתונים הישנים יותר לא מוצגים.

בדף Trace Explorer לא מוצגים נתונים לתקופות זמן ארוכות יותר מתקופת שמירת הנתונים של Cloud Trace, שהיא 30 יום.

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

מוצג מעקב לא מלא

פותחים את הדף Trace Explorer ובוחרים יחידה לוגית למעקב להצגה. בחלונית הנפתחת פרטים מוצג המעקב, אבל הוא לא מלא. חלק מהטווחים לא מוצגים.

יכולות להיות כמה סיבות לכך שטווחים מסוימים לא מופיעים:

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

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

• יש בעיה במדידה. לדוגמה, רק חלק מהטווחים במעקב נשלחו לפרויקט Google Cloud .

כדי לפתור את הבעיות האלה:

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

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

2. מוודאים שיש לכם את התפקיד 'משתמש ב-Cloud Trace' (roles/cloudtrace.user) בפרויקטים שבהם מאוחסנים נתוני הטווח.

אין לך את ההרשאות הנדרשות כדי לראות את נתוני המעקב

אתם צופים בדף Trace Explorer ורואים את ההודעה הבאה:

You don't have the required permissions to view trace data for one or more projects listed in the trace scope.

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

1. מרחיבים את הרכיב Scope (היקף) ומזהים את היקף המעקב שנבחר.
2. בתפריט הנפתח Refine scope (צמצום ההיקף), בוחרים באפשרות Manage scopes (ניהול היקפים).
3. מאתרים את היקף העקבות שזיהיתם בשלב הראשון, ואז מרחיבים את הפרטים כדי לראות את רשימת הפרויקטים. Google Cloud
4. לכל Google Cloud פרויקט בהיקף של Trace, מוודאים שיש לכם את התפקיד Cloud Trace User ‏ (roles/cloudtrace.user). אם אין לכם את התפקיד הזה בפרויקט, צריך לבקש מאדמין או מבעלי הפרויקט להקצות לכם את התפקיד הזה.

אין תמיכה בשאילתות חוצות-אזורים

פותחים את הדף Trace Explorer ומוצגת הודעה דומה לזו:

Error loading chart data. Cross-regional queries are not supported. The selected scope comprises buckets residing in multiple locations: list of locations.

הודעת השגיאה מציינת שבדף Trace Explorer צריך לשלוח שאילתה לנתונים שמאוחסנים במיקומים שונים.

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

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

  • עוברים לסרגל הכלים בדף Trace Explorer ומרחיבים את התפריט Scope.
  • בתפריט הנפתח Refine scope, בוחרים באפשרות Current project.

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

• מסירים מהיקף העקבות שנבחר את הפרויקטים שהנתונים שלהם מאוחסנים במיקום שונה מהמיקום של הפרויקט שנבחר:

  • עוברים לסרגל הכלים בדף Trace Explorer ומרחיבים את התפריט Scope.
  • בתפריט הנפתח Refine scope (צמצום ההיקף), בוחרים באפשרות Manage scopes (ניהול היקפים).
  • בדף Trace scopes אפשר לערוך כל trace scope.

  כדי למצוא את מיקום האחסון של נתוני העקבות, מריצים את הפקודה List observability buckets. בפרמטר הנתיב מציינים את הפרויקט, ובשדה LOCATION מגדירים מקף, (-), שמשמש כתו כללי.

הודעה על חוסר מזהה של יחידה לוגית למעקב ביומן מעקב

המעקב מכיל את ההודעה Missing span ID (חסר מזהה span).

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

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

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

אם ההודעה "חסר מזהה טווח" מופיעה באופן עקבי, נסו את הפעולות הבאות:

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

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

• אם אתם משתמשים ב-Cloud Service Mesh, אתם צריכים לוודא שאתם פועלים לפי ההנחיות להפצת הקשר של המעקב עבור ההגדרות האלה. הנחיות לגבי Cloud Service Mesh זמינות במאמר בנושא העברת הקשר של מעקב.

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

אתם מבצעים אחת מהפעולות הבאות:

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

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

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

אין נתוני מעקב אחרי עדכון אפליקציית Go לשימוש ב-OpenTelemetry

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

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

מידע על העדכון של ספריות הלקוח של Cloud ל-Go זמין בבעיה מספר 4237.