Cloud Trace הוא מערכת מבוזרת למעקב אחרי בקשות ב- Google Cloud. המערכת עוקבת אחרי זמן האחזור של הבקשות ועוזרת לכם לפתור בעיות שגורמות לצווארי בקבוק בביצועים בשירותים ובאפליקציות מבוססות-AI גנרטיבי. Trace אוסף נתונים של זמן אחזור מGoogle Cloud שירותים ומאפליקציות עם מכשור, ועוזר לכם להבין איך בקשות מעובדות בארכיטקטורת מיקרו-שירותים ולזהות יומנים רלוונטיים.
בעזרת Trace תוכלו לענות על שאלות כמו:
- כמה זמן לוקח לאפליקציה שלך לטפל בבקשה מסוימת?
- למה נדרש זמן רב להשלמת הבקשה?
- למה חלק מהבקשות נמשכות יותר זמן מאחרות?
- מהו זמן האחזור הכולל של בקשות לאפליקציה?
- האם זמן האחזור של האפליקציה עלה או ירד לאורך זמן?
- איך אפשר להפחית את זמן האחזור של האפליקציה?
- מהן התלויות של האפליקציה?
מידע על שימוש משולב בנתוני מעקב וביומנים לצורך ניתוח שורש הבעיה מופיע בפוסט בבלוג פתרון בעיות באפליקציות מבוזרות: שימוש משולב בנתוני מעקב וביומנים לצורך ניתוח שורש הבעיה.
למידע על יצירת פרופיל של האפליקציה, ראו Cloud Profiler.
תמיכה בסביבה
כלי המעקב פועל ב-Linux בסביבות הבאות:
- Compute Engine
- Google Kubernetes Engine (GKE)
- Apigee (Public Preview)
- הסביבה הגמישה של App Engine
- הסביבה הסטנדרטית של App Engine
- Cloud Run
- Cloud Service Mesh
- Cloud SQL query insights
- סביבות שאינןGoogle Cloud
רכיבים
Trace מורכב מלקוח מעקב שאוסף עקבות ושולח אותם לפרויקט Google Cloud שלכם. אחרי כן, תוכלו להשתמש במסוףGoogle Cloud כדי להציג ולנתח את הנתונים שנאספו על ידי לקוח המעקב. מידע על מודל הנתונים זמין במאמר בנושא עקבות וטווחים.
מעקב אחר לקוח
לקוח מעקב אוסף נתונים של זמן אחזור וטווח מהאפליקציה שלכם ומייצא אותם לפרויקט Google Cloud . בהתאם לסביבה ולדרישות שלכם, אתם יכולים לאסוף נתוני מעקב באופן אוטומטי או ידני על ידי הוספת קוד אפליקציה למעקב.
ממשק מעקב
כדי להציג ולנתח את נתוני יחידה לוגית למעקב, אפשר להשתמש בדפים Trace Explorer ו-Observability Analytics במסוףGoogle Cloud :
Trace Explorer: מציג מידע מצטבר על נתוני העקבות ומאפשר לבחון עקבות ספציפיים בפירוט. נתוני ההשהיה המצטברים מוצגים במפת חום שאפשר לבחון באמצעות מצביע העכבר. כדי להגביל את הנתונים שמוצגים, אפשר להוסיף מסננים. אפשר גם להציג ולחקור טווחים ועקבות ספציפיים:
- מידע על הצגת נתוני מעקב שמאוחסנים בכמה פרויקטים זמין במאמר יצירה וניהול של היקף מעקב.
- מידע על סינון והצגה של נתוני העקבות זמין במאמר חיפוש עקבות ועיון בהם.
Observability Analytics: מספק ממשק לשאילתות SQL. אפשר להצטרף לשאילתות ולעקוב אחרי נתוני היומן, ולראות את תוצאות השאילתה כטבלה או כתרשים. אם יוצרים מערך נתונים מקושר ב-BigQuery, אפשר להשתמש ב-BigQuery כדי לנתח את נתוני ה-trace. מידע נוסף מופיע במאמר שאילתות וניתוח של עקבות.
הגדרות עם מעקב אוטומטי
ההגדרות הבאות מתעדות באופן אוטומטי נתוני מעקב:
סביבה רגילה של App Engine
סביבות זמן ריצה מהדור הראשון מיירטות באופן אוטומטי את טווחי המעקב ושולחות אותם אל Cloud Trace. מידע נוסף זמין במאמר סקירה כללית של חבילות שירותים מדור קודם.
סביבות זמן ריצה מהדור השני מתעדות באופן אוטומטי את זמן האחזור הכולל של הבקשה ומוסיפות את כותרת ה-HTTP
X-Cloud-Trace-Contextלבקשות. מידע נוסף זמין במאמר בנושא לוח הזמנים של התמיכה בזמן ריצה.
פונקציות Cloud Run ו-Cloud Run
נתוני השהיה של בקשות HTTP נכנסות ויוצאות נשלחים באופן אוטומטי אל Trace.
הוספת כלי מדידה לאפליקציה
בצעו אינסטרומנטציה לאפליקציה שלכם כדי לאסוף מידע ספציפי שיעזור לכם להבין את הביצועים שלה ולפתור בעיות. יש כמה מסגרות עבודה של מכשור בקוד פתוח שאוספות נתונים של יומנים, מדדים ועקבות, ויכולות לשלוח את הנתונים האלה לכל ספק, כולל Google Cloud. במקרה של אפליקציות מבוססות-סוכן, חלק מהמסגרות יכולות לאסוף את ההנחיות והתשובות שלכם או להעביר הקשר שמאפשר מעקב אחרי חלק מהקריאות לשרתי MCP מרוחקים של Google Cloud.
כדי להוסיף לאפליקציה כלי מדידה, מומלץ להשתמש במסגרת מדידה ניטרלית ובעלת קוד פתוח, כמו OpenTelemetry, במקום בממשקי API או בספריות לקוח ספציפיים לספקים ולמוצרים. מידע על המסגרות האלה זמין במאמרים בנושא מדידה ויכולת צפייה ובחירת גישה למדידה.
הדוגמאות של שדרוג המידע שאנחנו מספקים משתמשות ב-OpenTelemetry:
דוגמאות לשימוש בייצוא מבוסס-איסוף:
הדוגמאות האלה שולחות נתוני מדדים ונתוני מעקב בפורמט של OpenTelemetry Protocol (OTLP) לפרויקט שלכם באמצעות Telemetry API. בדוגמאות נעשה שימוש ב Google Cloud כלי לייצוא נתוני יומן.
במאמר מעבר מייצוא נתוני מעקב לנקודת הקצה של OTLP מוסבר איך לייצא נתוני מעקב ישירות ולשלוח אותם ל-Telemetry API.
דוגמאות שמראות איך להגדיר אפליקציה מבוססת-סוכנים כדי לאסוף הנחיות ותגובות זמינות במאמר איך להטמיע כלי מעקב באפליקציות מבוססות-AI גנרטיבי.
- במאמר בדיקת קריאות ל-MCP באמצעות Trace מוסבר על שרתי MCP של Google Cloud שיכולים ליצור טווחים של מעקב.
אפשר להשתמש בספריות הלקוח של Cloud Trace כדי להוסיף לאפליקציה כלי מעקב, אבל אנחנו ממליצים להשתמש ב-OpenTelemetry. עדיף להשתמש בספריות OpenTelemetry במקום בספריות לקוח של Trace, כי הן פשוטות יותר ומייצאות נתוני מעקב בפורמט OTLP, שמוגדר על ידי OpenTelemetry. מידע נוסף זמין במאמרים Instrument for Trace וClient libraries for Cloud Trace.
Cloud Trace ואפליקציות מבוססות-סוכנים
כדי להבין את ה**התנהגות** של האפליקציות ה**סוכני**ות שלכם, הגדירו אותן לאסוף **פרומפטים** ותגובות או ליצור **יחידות לוגיות למעקב** כשהן קוראות ל**שרתי MCP** מרוחקים של Google Cloud. הפרומפטים והתשובות עוזרים לכם להבין את ההיגיון שבו משתמשת האפליקציה מבוססת-הסוכן. טווחים שמתעדים קריאות לכלים עוזרים לכם לאשר הפעלה של כלים, סטטוסים של קריאות וחביון של בקשות.
כמה דוגמאות להטמעה מראות איך להגדיר אפליקציה כדי לאסוף הנחיות ותשובות. הדוגמאות האלה מסתמכות על OpenTelemetry. מידע נוסף זמין במאמר בנושא איך להטמיע כלי מעקב באפליקציות AI גנרטיביות.
שרתי Google Cloud MCP יכולים ליצור טווחים של מעקב. מידע נוסף זמין במאמר בנושא בדיקת שיחות MCP באמצעות Trace.
ממשקי API שמטמיעים נתוני מעקב
אפשר לשלוח נתוני מעקב לפרויקט באמצעות Telemetry API או Cloud Trace API. אנחנו ממליצים להשתמש ב-Telemetry API מהסיבות הבאות:
ממשק ה-API תואם למערכת האקולוגית של OpenTelemetry בקוד פתוח, והמגבלות שלו לרוב נדיבות יותר מהמגבלות של Cloud Trace API, שהוא API קנייני של Google Cloud Google.
נתוני העקבות מאוחסנים בפורמט שתואם בדרך כלל לקובצי ה-proto שמוגדרים על ידי OTLP. יכול להיות שחלק מהשדות יומרו מסוג נתונים ספציפי ל-OpenTelemetry לסוג נתונים של JSON לפני האחסון. מידע על פורמט האחסון זמין במאמר סכימה של נתוני מעקב.
כשמייצאים נתוני מעקב באמצעות כלי איסוף, המכשור לא מסתמך על כלי ייצוא ספציפי ל- Google Cloud.
חלק מהתכונות, כמו מעקב אחר אפליקציות, מתבססות על מידע שזמין רק כששולחים נתוני מעקב אל Telemetry API.
כדי למנוע שמירת נתוני מעקב בפרויקט Google Cloud , צריך להשבית את Cloud Trace API. השבתה של Cloud Trace API גורמת לשינויים הבאים:
- שירותיGoogle Cloud לא שולחים נתוני מעקב לפרויקט.
- Google Cloud מחזירה קוד שגיאה בתגובה לבקשות שנשלחות לנקודת קצה ל-API של Cloud Trace.
- Google Cloud Observability מבטל את הנתונים של המעקב שנשלחים לנקודת קצה ל-API של Telemetry שספציפית למעקב. אל תשביתו את Telemetry API, כי ממשק ה-API הזה יכול לקבל נתוני יומנים, מדדים ועקבות.
אם אתם מנהלים ארגון ורוצים למנוע שימוש ב-Cloud Trace, אתם יכולים ליצור אילוץ של מדיניות הארגון.
תמיכה ב-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 כדי לשלוח טווחים של מעקב.
כדי למנוע שמירת נתוני מעקב בפרויקט Google Cloud , צריך להשבית את Cloud Trace API. אל תשביתו את Telemetry API, כי ה-API הזה יכול לקבל נתוני יומן, מדדים ונתוני מעקב.
שמירת נתוני מעקב
| קטגוריה | תקופת שמירה |
|---|---|
טווחים שמאוחסנים בקטגוריה _Trace |
30 ימים |
תפקידי IAM
ב-Cloud Trace נעשה שימוש בניהול זהויות והרשאות גישה (IAM) כדי לשלוט בגישה למשאבים. רשימת התפקידים ב-Cloud Trace API וב-Telemetry API מופיעה במאמר בקרת גישה באמצעות IAM.
מכיוון ש-Telemetry API הוא API לצרכנים, כדי לשלוח נתונים ל-Telemetry API צריך לציין פרויקט מכסה ולהעניק לחשבון השירות של האפליקציה הרשאה להשתמש במכסה הזו. מידע נוסף זמין במאמר Telemetry API: Authentication.
תמחור
מידע על התמחור של Cloud Trace זמין בדף התמחור של Google Cloud Observability.
המאמרים הבאים
כדאי לנסות את המדריך למתחילים.
מידע על מכסות ומגבלות זמין במאמר מכסות ומגבלות.
אפשר גם לקרוא את המשאבים שלנו בנושא DevOps ולעיין בתוכנית המחקר DevOps Research and Assessment.