نمونه‌برداری و کاهش چشمگیر هزینه‌ها در Tracing بدون از دست دادن Visibility

قبل اینکه بریم سراغ sampling توضیح کوتاهی درباره trace و span بخونیم:
یک trace رو می‌تونیم به‌عنوان نماینده‌ ی یک کار کامل تو سیستم در نظر بگیریم. مثلا وقتی کاربر درخواست ثبت سبد خرید میده، این عملیات به‌صورت کامل یک Trace حساب می‌شه.

هر Span یک بخش کوچک از اون Trace هست. مثلاً برای ثبت سبد خرید، ممکنه چند سرویس درگیر بشن (مثل بررسی موجودی، محاسبه‌ی تخفیف، ثبت در پایگاه داده و ...) که هر کدوم از این مراحل می‌تونه یک Span جدا باشه. در نهایت، این Spanها کنار هم قرار می‌گیرن و یک کار کامل یعنی trace رو تشکیل می‌دن.

پس با استفاده از traces (یا همون ردپاها)، می‌تونید با دقت بررسی کنید یک درخواست از کجا شروع شده، به کدوم سرویس‌ها رفته، و حتی در هر فانکشن یا لایه چقدر زمان برده تا پردازش بشه.
می‌تونید اطلاعات اضافی (Attributes) یا رویدادهایی که اتفاق افتاده رو هم به هر Span اضافه کنید. در کل، Trace ابزار فوق‌العاده‌ای برای تحلیل دقیق و عمیق رفتار سیستمتونه.

اما یه مشکلی هست:
تریس کردن همه‌ی درخواست‌ها هزینه‌ی زیادی داره، هم از نظر حافظه و پهنای باند و هم هزینه‌ی پردازش و ذخیره‌سازی.
در واقع، بیشتر درخواست‌هایی که وارد سیستم شما می‌شن بدون خطا و با latency مناسب انجام می‌شن. پس واقعا نیازی به نگه‌داری صد درصد تریس ها ندارید.
شما فقط به نمونه هایی از کل تریس ها نیاز دارید. اینجاست که مفهوم Sampling و یا همون نمونه برداری وارد می‌شه.

نمونه برداری یعنی چی؟

نمونه برداری یعنی تصمیم بگیریم کدوم Traceها نگه‌داری (Sampled) بشه و کدوم رو حذف کنیم (Not Sampled).
هدف اینه که با یه درصد کوچیک و حساب‌شده از داده‌ها، تصویری واضح از وضعیت سیستم داشته باشیم.

مثلا اگه شما هزار تا Trace در ثانیه تولید می‌کنید، نگه داشتن ۱۰۰٪ اونا هم پرهزینه‌ست و هم اغلب غیرضروری. توی این شرایط، یه نرخ Sampling حتی در حد ۱٪ هم می‌تونه نماینده خوبی از رفتار کلی سیستم باشه.

چه زمانی باید از Sampling استفاده کنیم؟

* وقتی تعداد زیادی Trace در ثانیه تولید می‌کنید (مثلا بیشتر از ۱۰۰۰ تا)
* وقتی بیشتر ترافیک شما سالم و بدون خطاست
* وقتی بتونید با قواعد خاصی (مثل خطا داشتن یا latency زیاد) تصمیم بگیرید که چه Traceهایی مهم‌ترن
* وقتی بودجه محدودی برای observability دارید

همچنین ما دو نوع نمونه برداری داریم:

1. Head Sampling

اینجوریه که تو لحظه ای که یک تریس ایجاد میشه، براساس ID و بدون درنظر گرفتن محتوا تصمیم‌گیری میکنه که این تریس سمپل هستش یا نه.
مزیتش اینه ساده و سریعه، ولی نمی‌تونه مثلا تشخیص بده که آیا داخل اون Trace خطا بوده یا نه.
مثال استفادش مثلا میگیم پنجاه درصد کل درخواست هارو نگه دار.

2. Tail Sampling

نمونه برداری بعد از اینکه کل Trace جمع‌آوری شد. می‌تونه براساس شرایطی مثل داشتن خطا، زیاد بودن latency، یا حتی اطلاعات مربوط به یک سرویس خاص تصمیم بگیره. خیلی قدرتمنده ولی نسب به head sampling منابع و هزینه بیشتری میخواد.

مثال tail sampling:
– هر Trace که error داشته باشه رو حتما نگه دار
– اگه latency بالای ۳ ثانیه بود، نگه دار
– تریس هایی که از سرویس جدیدمون شروع می‌شن رو بیشتر نگه دار

گاهی ترکیب Head و Tail Sampling بهترین راهه

مثلا ممکنه یه سیستم خیلی پرحجم اول با Head Sampling فقط ۱۰٪ داده‌ها رو رد کنه، بعد اون ۱۰٪ رو بیاره داخل یه سیستم Tail Sampling تا براساس هوشمندی بیشتر تصمیم بگیره چی رو نگه داره.

پیاده سازی عملی:
ما تو پروژه اپن سورس و مدرن Quick-Connect از opentelemetry برای جمع آوری تریس ها استفاده کردیم و از head sampling هم برای نمونه برداری استفاده کردیم که توی کانفیگ میتونید مشخص کنید به چه صورت باشه.
اگه 0 تنظیم کنید هیچی تریس نمیکنه و اگه 1 تنظیم کنیم صد درصد تریس میکنه.
برای اینکه مشخص کنید ده درصد باشه میتونید روی 0.1 تنظیمش کنید.

https://github.com/syntaxfa/quick-connect/tree/main/adapter/observability/traceotela


#trace #sampling #opentelemetry #observability

@Syntax_fa