דגימת נתונים של מעקב קובעת אילו בקשות וטווחים נקלטים ב-Cloud Trace, ועוזרת לכם לשלוט בעלויות האחסון ולעמוד במכסות, תוך איסוף מספיק נתונים לפתרון בעיות בביצועים. כדי לנהל נפחים גדולים של בקשות, רכיבים במערכת מבוזרת למעקב אחר בקשות בדרך כלל דוגמים רק קבוצת משנה של עקבות או פועלים לפי החלטות הדגימה של טווחי האב.
דגימה שונה מהעברת הקשר: דגימה קובעת אם רכיב מתעד נתוני span, בעוד שהעברת הקשר מעבירה מזהי מעקב בין רכיבים כדי שאפשר יהיה לקשר בין spans שנדגמו.
אסטרטגיות דגימה
ההחלטות לגבי הדגימה יכולות להתבסס על תחילת הנתונים או על סוף הנתונים. בדגימה מבוססת-כותרת, החלטת הדגימה מתקבלת כשהבקשה מתקבלת על ידי הרכיב שמבצע את העיבוד של הטווח. בדגימה מבוססת-זנב, ההחלטה לגבי הדגימה מתעכבת עד שכל העקבות זמינים.
יכול להיות שתיתקלו בביטוי '100% דגימה' במסמכים של מערכות מעקב מבוזרות. יכול להיות שהביטוי הזה מתייחס למעקב או לרכיב. כשמחילים את התג הזה על מעקב, המשמעות היא שכל הטווחים נדגמו, או באופן שווה ערך, שהמעקב הושלם. כשמחילים את ההגדרה על רכיב, המשמעות היא שהרכיב דוגם כל טווח שהוא מעבד.
דגימה מבוססת-ראש
בדרך כלל, דוגמים שמבוססים על ראש מוגדרים לדגום תמיד טווחים או להשתמש באסטרטגיית דגימה הסתברותית:
בהגדרות always sample, רכיבים שמעבדים וכותבים נתוני מעקב דוגמים כל span. מומלץ שכל העקבות יהיו מלאים, ולכן יהיה לכם את המידע שדרוש לפתרון בעיות של כשלים. עם זאת, הגדרה של דגימה תמידית עלולה לגרום לחריגה ממכסות או ממגבלות על עלויות אחסון.
בשיטת הדגימה ההסתברותית, לא כל טווחי הזמן נדגמים. ההתנהגות בפועל של הגישה הזו תלויה בהטמעה של הרכיב. ביישומים מסוימים, לכל הטווחים יש הסתברות זהה להידגם. במקרים אחרים, ההחלטה לגבי הדגימה של ה-parent משפיעה על ההחלטה אם לבצע דגימה של ה-span.
יכול להיות שמעקב לא יכיל כל span. אם אתם משתמשים בדגימה הסתברותית, חורגים מהמכסה או משתמשים ברכיבים שמבצעים עיבוד אבל לא דגימה של טווחים, צפויים להיות עקבות לא מלאים.
דגימה מבוססת-זנב
Cloud Trace לא תומך בדגימה מבוססת-זנב. החלטות לגבי דגימה צריכות להתקבל ברכיבים ששולחים נתונים ל-Cloud Trace.
אם משתמשים בדגימה מבוססת-זנב, אפשר גם להשתמש בשרת ביניים כדי לקבל נתוני מעקב, להעריך החלטות דגימה ולהעביר טווחי זמן שנדגמו אל Trace. לדוגמה, אפשר להשתמש ב-OpenTelemetry Collector עם Tail Sampling Processor כדי לקבל החלטה לגבי דגימה באיחור.
אם אתם מתכננים להשתמש בדגימה של הזנב, כדאי לשקול את הנקודות הבאות:
- צריך לאחסן את כל הטווחים במעקב לפני שמקבלים החלטה לגבי דגימה. לכן, יכול להיות שתצטרכו נפח אחסון זמני גדול או שתחויבו בעלויות נוספות.
- באופן כללי, כל הרכיבים שיכולים ליצור טווחים למעקב צריכים לתאם ביניהם. בדרך כלל, מפתחים שמשתמשים ב-OpenTelemetry מעבירים את כל ה-spans לאותו trace ID לאותו collector.
הרכיבים מקבלים החלטות לגבי דגימה
כל רכיב מקבל החלטה משלו לגבי הדגימה של הטווח שהוא מעבד. עם זאת, החלטת הדגימה של הרכיב ההורה, שעשויה להיות זמינה לרכיב דרך הקשר של מעקב הפעילות, יכולה להשפיע על ההחלטה של הרכיב. אפליקציות שמשתמשות בכותרת traceparent יכולות להעביר את החלטת הדגימה של ההורה באמצעות הסימון sampled.
לדוגמה, נניח שלכל רכיב יש כלל שאומר: "אם טווח האב נדגם, אז צריך לדגום את הטווח הנוכחי; אחרת, צריך לדגום 50% מהטווחים". בתרחיש הזה, הדברים הבאים נכונים:
- הטווח הבסיסי קובע אם כל הטווחים במעקב נדגמים.
- כשמבצעים דגימה של הטווח הבסיסי, מתבצעת דגימה של כל הטווחים במעקב. לכן, המעקב הושלם.
דגימה Google Cloud ושירותים
כל Google Cloud שירות מקבל החלטות משלו לגבי דגימה, ולא כל Google Cloud השירותים מבצעים דגימה. כלומר, יכול להיות ששירות מסוים אף פעם לא ישלח נתונים ל-Cloud Trace.
כששירות Google Cloud תומך בדגימה, בדרך כלל הוא מטמיע את הפעולות הבאות:
- תדירות דגימה שמוגדרת כברירת מחדל.
- מנגנון לשימוש בהחלטת הדגימה של ההורה כרמז לשאלה אם לדגום את היחידה הלוגית למעקב.
- תדירות הדגימה המקסימלית.
כדי לבקש להוסיף תמיכה בדגימה בשירות Google Cloud , צריך להשתמש בכלי למעקב אחר בעיות של Google.
המאמרים הבאים
במאמר דגימה מרחוק ב-Jaeger מוסבר איך בוחרים אסטרטגיית דגימה לפי שם טווח.
מומלץ לעיין במסמכי המקור הפתוח הבאים כדי להחליט איזו גישת דגימה הכי מתאימה לאפליקציות שנמצאות בפיתוח ולאפליקציות שכבר הושקו:
Google Cloud מסמכי השירות: