סקירה כללית על Cloud Trace

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

‫Trace מקבל נתוני חביון משירותים כמו App Engine ומאפליקציות שאתם מפעילים, ולכן הוא יכול לעזור לכם לענות על השאלות הבאות: Google Cloud

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

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

למידע על יצירת פרופיל של האפליקציה, ראו Cloud Profiler.

תמיכה בסביבה

כלי המעקב פועל ב-Linux בסביבות הבאות:

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

הגדרות עם מעקב אוטומטי

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

  • סביבה רגילה של App Engine

    באפליקציות Java 8,‏ Python 2 ו-PHP 5 לא צריך להשתמש בספריות הלקוח של Trace. סביבות זמן הריצה האלה שולחות באופן אוטומטי נתוני השהיה ל-Trace עבור בקשות לכתובות URI של אפליקציות. הבקשות כוללות נתוני זמן אחזור לקריאות לשירות מרוחק (RPC) הלוך ושוב לשירותי App Engine. ‫Trace פועל עם כל ממשקי ה-API של App Engine Admin, למעט Cloud SQL.

  • פונקציות Cloud Run ו-Cloud Run

    נתוני השהיה של בקשות HTTP נכנסות ויוצאות נשלחים באופן אוטומטי אל Trace.

ממשקי API שמטמיעים נתוני מעקב

אפשר לשלוח נתוני Trace לפרויקט באמצעות Telemetry API או Cloud Trace API. מומלץ להשתמש ב-Telemetry API מהסיבה הבאה:

  • ה-API תואם למערכת האקולוגית של OpenTelemetry בקוד פתוח, והמגבלות שלו לרוב נדיבות יותר מהמגבלות של Cloud Trace API, שהוא API קנייני Google Cloud

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

  • בייצוא נתוני מעקב שמבוסס על איסוף, המכשור לא מסתמך על כלי ייצוא ספציפי ל- Google Cloud.

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

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

  • Google Cloud לא שולחים נתוני מעקב לפרויקט.
  • ‫Google Cloud Cloud Trace API מחזיר קוד שגיאה בתשובה לבקשות שנשלחות לנקודת קצה ל-API של Cloud Trace.
  • Google Cloud Observability מבטל את הנתונים של המעקב שנשלחים לנקודת קצה ל-API של Telemetry שספציפית למעקב. אל תשביתו את Telemetry API, כי ממשק ה-API הזה יכול לקבל נתוני יומנים, מדדים ועקבות.

אם אתם מנהלים ארגון ורוצים למנוע שימוש ב-Cloud Trace, אתם יכולים ליצור אילוץ של מדיניות הארגון.

‫Cloud Trace ואפליקציות מבוססות-סוכנים

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

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

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

איך מטמיעים את האפליקציה

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

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

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

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

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

רכיבים

‫Trace מורכב מלקוח מעקב שאוסף עקבות ושולח אותם לפרויקט Google Cloud . אחרי זה אפשר להשתמש במסוףGoogle Cloud כדי לראות ולנתח את הנתונים שנאספו על ידי הסוכן. מידע על מודל הנתונים זמין במאמר בנושא עקבות וטווחים.

מעקב אחר לקוח

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

אם אין ספריית OpenTelemetry, צריך להוסיף אינסטרומנטציה לקוד על ידי ייבוא של ספריית Trace SDK ושימוש ב-Cloud Trace API. ה-API של Cloud Trace שולח נתוני מעקב אל הפרויקט שלכם ב- Google Cloud .

ממשק מעקב

בממשק Trace אפשר לראות ולנתח את נתוני העקבות כמעט בזמן אמת.

כדי להציג ולנתח את נתוני יחידה לוגית למעקב, אפשר להשתמש בדפים Trace Explorer ו-Observability Analytics במסוףGoogle Cloud :

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

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

תמיכה ב-VPC Service Controls

‫Trace הוא שירות שנתמך על ידי VPC Service Controls. שם השירות של Trace הוא cloudtrace.googleapis.com. הגבלות של VPC Service Controls שיוצרים עבור שירות Trace חלות רק על השירות הזה. ההגבלות האלה לא חלות על שירותים אחרים, כולל שירותים כמו telemetry.googleapis.com, שיכולים גם לקלוט נתוני מעקב.

למידע נוסף, קראו את המאמרים הבאים:

‫Cloud Trace ומיקום הנתונים

אם אתם משתמשים ב-Assured Workloads כי יש לכם דרישות לגבי מיקום הנתונים או רמת ההשפעה 4 (IL4), אל תשתמשו ב-Cloud Trace API כדי לשלוח טווחים של מעקב.

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

  • Google Cloud לא שולחים נתוני מעקב לפרויקט.
  • ‫Google Cloud Cloud Trace API מחזיר קוד שגיאה בתשובה לבקשות שנשלחות לנקודת קצה ל-API של Cloud Trace.
  • Google Cloud Observability מבטל את הנתונים של המעקב שנשלחים לנקודת קצה ל-API של Telemetry שספציפית למעקב. אל תשביתו את Telemetry API, כי ממשק ה-API הזה יכול לקבל נתוני יומנים, מדדים ועקבות.

אם אתם מנהלים ארגון ורוצים למנוע שימוש ב-Cloud Trace, אתם יכולים ליצור אילוץ של מדיניות הארגון.

תמחור

מידע על התמחור של Cloud Trace זמין בדף התמחור של Google Cloud Observability.

המאמרים הבאים