במסמך הזה מתואר הפורמט שבו מאוחסנים טווחים של מעקב. הפורמט של הנתונים בדרך כלל עקבי עם קובצי הפרוטו שמוגדרים על ידי OpenTelemetry Line Protocol. עם זאת, יכול להיות ששדות יומרו מסוג נתונים ספציפי ל-OpenTelemetry לסוג נתונים של JSON לפני האחסון.
Telemetry API משתמש ב-OpenTelemetry Line Protocol.
הפרוטוקול הזה מסתמך על הקבצים trace_service.proto ו-trace.proto. מידע על מגבלות השדות זמין במאמר מגבלות של Telemetry API.
Cloud Trace API לא משתמש בפרוטוקול OpenTelemetry OTLP, ומגדיר פורמט נתונים קנייני. נתוני מעקב שנשלחים אל Google Cloud הפרויקט שלכם דרך ה-API הזה מומרים לפורמט שמתואר במסמך הזה. עם זאת, חלות המגבלות של Cloud Trace API.
פורמט אחסון של טווח
| שדה | תיאור | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trace_id |
מזהה ייחודי גלובלי של המעקב.
המזהה הזה הוא ערך מספרי של 128 ביטים בפורמט של מחרוזת הקסדצימלית בגודל 16 בתים. לדוגמה:
ערך מספרי של אפס לא תקין. ה- |
||||||||||||||||
span_id |
חובה. מזהה של התג span.
המזהה חייב להיות ייחודי בתוך מעקב.
המזהה הזה הוא ערך מספרי בן 64 ביט
בפורמט של מחרוזת הקסדצימלית באורך 8 בתים.
לדוגמה, ערך מספרי של אפס לא תקין. |
||||||||||||||||
trace_state |
השדה הזה תואם לכותרת הספריות של OpenTelemetry מתעדות באופן אוטומטי את הערך של הכותרת |
||||||||||||||||
parent_span_id |
זה שינוי אופציונלי. מזהה את הפעולה שהפעילה את הטווח הזה. בטווח 'root' מזהה טווח האב מוגדר כ-null. הקשר הראשי-משני בין טווחי זמן משמש כלי ויזואליזציה לבניית מבנה העץ. |
||||||||||||||||
name |
חובה. שם הפעולה שבוצעה. השם יכול להיות שם של שיטה או שם אחר של אתר לכל שיחה. אם משתמשים באותו שם לאותו קובץ הפעלה ולאותה נקודת קצה, קל יותר לקשר בין טווחי זמן שונים בנתוני המעקב. שיטות מומלצות מפורטות במאמר איך לתת שמות לטווחים. שם הטווח עובר ניקוי ומוצג במסוף Google Cloud . |
||||||||||||||||
kind |
מציין את המיקום במערכת שבו התרחשה הפעולה. הערך תואם לספירה OpenTelemetry: Span Kind:
|
||||||||||||||||
start_time |
חובה. שעת ההתחלה של הטווח, מעוגלת לננו-שנייה הקרובה ביותר. |
||||||||||||||||
start_time_unix_nano |
זמן ההתחלה בננו-שניות, לפי ראשית זמן יוניקס (Unix epoch). |
||||||||||||||||
end_time |
חובה. שעת הסיום של טווח הזמן, מעוגלת לננו-שנייה הקרובה ביותר. |
||||||||||||||||
end_time_unix_nano |
זמן הסיום בננו-שניות, לפי ראשית זמן יוניקס (Unix epoch). |
||||||||||||||||
receive_time |
חובה. שעת הקבלה של היחידה הלוגית למעקב, מעוגלת לננו-השנייה הקרובה ביותר. |
||||||||||||||||
receive_time_unix_nano |
זמן הסיום בננו-שניות, לפי ראשית זמן יוניקס (Unix epoch). |
||||||||||||||||
duration_unix_nano |
משך הזמן בננו-שניות. |
||||||||||||||||
attributes |
כל מאפיין הוא צמד מפתח/ערך. המאפיינים שזמינים לכם תלויים בנתוני העקבות. מבנה המאפיינים תואם לתקן OpenTelemetry. מידע נוסף זמין במאמר OpenTelemetry: Attributes. ב-OpenTelemetry מוגדרות מוסכמות סמנטיות למאפיינים. מידע נוסף על המוסכמות האלה זמין במאמר בנושא מוסכמות סמנטיות של מעקב. דוגמאות למאפיינים: "yourcompany.your.own.key": "your own value" "network.protocol.name": "http" "network.protocol.version": "1.1" "http.response.status_code": "200" "network.peer.address": "REDACTED" |
||||||||||||||||
dropped_attributes_count |
מספר המאפיינים שהמערכת פסלה. יכול להיות שמאפיינים ייפסלו כי המפתחות שלהם ארוכים מדי או כי יש יותר מדי מאפיינים. אם הערך הוא אפס, לא נמחקו מאפיינים. יכול להיות שהערך הזה מוגדר על ידי מכשור בצד הלקוח או על ידי אפליקציה. השרת יכול להגדיל את הערך. |
||||||||||||||||
events |
אירוע שמתרחש בנקודת זמן מסוימת. כל אירוע מכיל את השדות הבאים.
|
||||||||||||||||
dropped_events_count |
מספר האירועים שהושלכו. יכול להיות שהאירועים יימחקו כי יש יותר מדי אירועים. אם הערך הוא אפס, לא נמחקו אירועים. |
||||||||||||||||
links |
קישורים שמשויכים לטווח. קישורים הם הפניות מהיחידה הלוגית למעקב הזו ליחידה לוגית למעקב אחרת באותו יומן מעקב או ביומן מעקב אחר. קישורים מספקים מנגנון לקורלציה בין טווחי זמן ממעקב אחד לבין טווחי זמן במעקב אחר. לדוגמה, נניח שפעולה אחת גורמת להתרחשות של פעולה אסינכרונית. בתרחיש הזה יש שני מעקבים, אחד לפעולה המקורית ואחד לפעולה האסינכרונית. אפשר להשתמש בקישורים כדי ליצור קורלציה בין הטווחים בנתוני המעקב האלה. כל קישור מכיל את השדות הבאים.
|
||||||||||||||||
dropped_links_count |
מספר הקישורים שהושלכו. יכול להיות שקישורים יימחקו כי יש יותר מדי קישורים. אם הערך הוא אפס, לא נמחקו קישורים. |
||||||||||||||||
status |
בשדה הזה מתועד סטטוס ההשלמה של יחידה לוגית למעקב.
הערך בשדה המשנה
שדה המשנה |
||||||||||||||||
resource |
בשדה הזה מצוינת התשתית או מערכת האירוח שממנה נאספו נתוני הטלמטריה או שהנתונים מתייחסים אליה. לדוגמה, נניח שיש לכם אפליקציה שפועלת ב-Google Kubernetes Engine. המאפיינים של המשאב הזה יכולים לכלול את שם התהליך ואת מרחב השמות. השדה הזה מכיל את שדות המשנה הבאים:
מידע נוסף זמין במאמר OpenTelemetry: Resources. |
||||||||||||||||
instrumentation_scope |
בשדה הזה מצוין הרכיב בספרייה או ברכיב באפליקציה של לדוגמה, נניח שהאפליקציה checkout-service נפרסה ב-Cloud Run, כלומר טווח של לקוח, כמו WritePaymentInfoToStripe, יכול להיות טווח שמדווח על ידי payment-processor-library, שנמצא בתוך שירות Cloud Run שנקרא checkout-service. השדה הזה מכיל את שדות המשנה הבאים:
מידע נוסף זמין במאמר בנושא OpenTelemetry: Instrumentation scope. |
||||||||||||||||
resource_schema_link |
השדות האלה חייבים להיות כתובת URL בפורמט של מחרוזת. השדות האלה מכילים כתובת URL שמחזירה קובץ סכימה של משאב. הפורמט של קובץ הסכימה והנתונים מוגדר על ידי OpenTelemetry. מידע נוסף זמין במאמר בנושא OpenTelemetry: Schemas. אפשר להגדיר את השדות האלה רק כשמשתמשים ב-Telemetry API. ממשק ה-API הזה לא מאמת שהנתונים תואמים לסכימה שהוגדרה. |
||||||||||||||||
scope_schema_link |
השדות האלה חייבים להיות כתובת URL בפורמט של מחרוזת. השדות האלה מכילים כתובת URL שמחזירה קובץ סכימה להיקף. הפורמט של קובץ הסכימה והנתונים מוגדר על ידי OpenTelemetry. מידע נוסף זמין במאמר בנושא OpenTelemetry: Schemas. אפשר להגדיר את השדות האלה רק כשמשתמשים ב-Telemetry API. ממשק ה-API הזה לא מאמת שהנתונים תואמים לסכימה שהוגדרה. |
||||||||||||||||
apphub |
תוויות ספציפיות לאפליקציה זמינות כשמרווחי זמן של מעקב נוצרים על ידי אפליקציות של מרכז האפליקציות, כשהאפליקציות האלה פועלות בתשתית נתמכת או כשבוצע אינסטרומנטציה. מידע נוסף על Application Monitoring ועל המועד שבו התוויות האלה זמינות מופיע במאמר סקירה כללית על Application Monitoring. השדה הזה מכיל את שדות המשנה
|