פתרון בעיות

במסמך הזה מוסבר איך לפתור בעיות נפוצות שקשורות ל-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 במערך נתונים של יכולת התבוננות שנמצא במיקום הספציפי הזה.

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

אתם מריצים שאילתה על מערך נתונים מקושר ב-BigQuery והפקודה נכשלת עם הודעת שגיאה שדומה ל-Dataset not found (מערך הנתונים לא נמצא).

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

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

• מריצים את הפקודה הבאה gcloud observability buckets datasets links list ומוודאים שהתגובה כוללת את מערך הנתונים המקושר שלכם ב-BigQuery.

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

  פרויקט יכול להכיל מערך נתונים מקושר ב-BigQuery שאין לו הורה אם מבטלים את ההרשאות של תפקידי IAM מחשבון שירות שמשמש את Google Cloud Observability לניהול נתונים, ואז מוחקים קישור במערך נתונים של Observability. במקרה כזה, Google Cloud Observability לא יכול למחוק את מערך הנתונים המקושר ב-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. המאגר הזה מוקצה אוטומטית כשפרויקט 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 מגדירים את השדה למקף, (-), שמשמש כתו כללי לחיפוש.

הודעה על מזהה 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.