Tracing توزیع‌شده: چطور کار می‌کنه و کی لازمش دارید.

وقتی یه صفحه چهار ثانیه طول می‌کشه تا باز بشه و درخواست از یه gateway، سه سرویس، یه کش و دو دیتابیس رد شده، لاگ هر جزء یه چیز کوچیکی می‌گه و هیچ‌کدوم نمی‌گه اون چهار ثانیه کجا رفت. Tracing توزیع‌شده کل سفر یه درخواست رو ثبت می‌کنه، تا مرحله‌ی کند یا خراب به چشم بیاد.

نکته‌های کلیدی

• یه trace سفر یه درخواسته که از spanها ساخته شده؛ یکی برای هر عملیات.
• زمینه (trace ID و شناسه‌ی span والد) در هدرهای درخواست بین سرویس‌ها جابه‌جا می‌شه.
• نمونه‌برداری هزینه رو کنترل می‌کنه؛ همه‌ی خطاها و درخواست‌های کند رو نگه دارید و از بقیه نمونه بگیرید.
• OpenTelemetry برای بیشتر زبان‌ها ابزارگذاری مستقل از فروشنده ارائه می‌ده.
• Tracing کندی داخل سیستم شما رو توضیح می‌ده؛ چک‌های آپتایم تأیید می‌کنن کاربرها اصلاً بهش می‌رسن.

Trace و span

یه span یه واحد کار رو ثبت می‌کنه: یه تماس HTTP، یه کوئری دیتابیس، یه جستجوی کش. هر کدوم زمان شروع، مدت، اسم، ویژگی‌ها (مثل http.status_code یا db.statement) و وضعیت داره. spanها تودرتو هستن: span «رسیدگی به پرداخت» شامل spanهای فرزند «رزرو موجودی»، «شارژ کارت» و «ارسال رسید» هست.

GET /checkout                          1,840 ms
├── auth.verify_token                     12 ms
├── inventory.reserve                    210 ms
│   └── SELECT ... FROM stock             190 ms
├── payments.charge                    1,520 ms   <- the slow part
│   └── POST gateway /charge            1,505 ms
└── email.queue_receipt                    9 ms

با خوندن چنین traceی، گفت‌وگو با یه نگاه از «سایت کنده» به «تماس با درگاه پرداخت ۱٫۵ ثانیه طول می‌کشه» می‌رسه.

انتقال زمینه

برای اینکه spanهای سرویس‌های مختلف به یه trace بپیوندن، هر درخواست خروجی زمینه‌ی trace رو با خودش می‌بره. هدر استاندارد W3C این‌شکلیه:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

شامل trace ID، شناسه‌ی span والد و یه پرچم نمونه‌برداریه. کتابخانه‌های ابزارگذاری برای کلاینت‌ها، سرورها و صف‌های پیام رایج، اون رو خودکار اضافه می‌کنن و می‌خونن. جزئی که این هدر رو جا بندازه، trace رو تیکه‌تیکه می‌کنه؛ یه علت رایج spanهای «گم‌شده».

نمونه‌برداری

trace گرفتن از همه‌ی درخواست‌ها در یه سیستم شلوغ گرونه. راهبردهای رایج:

• نمونه‌برداری اول کار (head)؛ تصمیم در شروع (مثلاً نگه داشتن ۱۰٪). ساده است، ولی ممکنه همون یه درخواست جالب رو دور بریزه.
• نمونه‌برداری آخر کار (tail)؛ تصمیم بعد از کامل شدن trace، با نگه داشتن همه‌ی خطاها و traceهای کند به‌علاوه‌ی سهم کوچیکی از عادی‌ها. مفیدتره، ولی یه collector لازم داره که traceها رو بافر کنه.

ابزارگذاری با OpenTelemetry

OpenTelemetry (OTel) برای بیشتر زبان‌ها و فریم‌ورک‌ها SDK و ابزارگذاری خودکار ارائه می‌ده. یه تنظیم معمولی:

1. SDK و ابزارگذاری خودکار OTel رو برای فریم‌ورکتون اضافه کنید.
2. اسم سرویس و محیط رو به‌عنوان ویژگی‌های منبع تنظیم کنید.
3. خروجی رو به یه OpenTelemetry Collector بفرستید که به backend tracing انتخابی شما منتقل کنه.
4. دور عملیات‌های مهم کسب‌وکار span دستی اضافه کنید.

export OTEL_SERVICE_NAME=checkout
export OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317

مفید کردن traceها

• trace ID رو در هر خط لاگ بنویسید تا بتونید از یه trace به لاگ‌هاش برید.
• spanها رو بر اساس عملیات نام‌گذاری کنید، نه مقدار: GET /orders/{id}، نه GET /orders/58114.
• خطاها رو روی spanها ثبت کنید با نوع و پیام خطا.
• رمزها رو در ویژگی‌ها نذارید؛ query stringها و هدرها معمولاً توکن دارن.

Tracing کجا متوقف می‌شه؟

traceها وقتی شروع می‌شن که درخواست به کد ابزارگذاری‌شده‌ی شما برسه. نمی‌تونن خرابی DNS، گواهی منقضی یا مشکل شبکه‌ای رو نشون بدن که جلوی رسیدن درخواست‌ها رو می‌گیره. برای اون نگاه بیرونی، مانیتورینگ آپتایم و API بیرونی رو سر جاش نگه دارید و از زمان‌های پاسخی که از چند شهر ثبت می‌کنه استفاده کنید تا ببینید کندی داخل سیستم شماست یا در مسیر رسیدن بهش.

پرسش‌های پرتکرار

• برای یه برنامه‌ی یکپارچه (monolith) هم tracing لازمه؟

  +

  کمتر فوری. یه برنامه‌ی تکی معمولاً با لاگ خوب و یه profiler عیب‌یابی می‌شه. tracing وقتی می‌ارزه که درخواست‌ها از مرز پروسس‌ها رد بشن: صف‌ها، سرویس‌های جدا، APIهای بیرونی.

• Tracing برنامه رو کند می‌کنه؟

  +

  سربار ابزارگذاری مدرن معمولاً کمه و نمونه‌برداری هزینه‌ی ارسال رو پایین نگه می‌داره. قبل از اجرای گسترده، توی محیط خودتون اندازه‌اش بگیرید.

• فرق trace ID و request ID چیه؟

  +

  نقش یکسانی دارن: هر چیزی که یه درخواست انجام داده رو به هم وصل می‌کنن. trace ID یه قالب استاندارد داره و ابزارهای tracing اون رو می‌فهمن؛ خیلی از تیم‌ها همون رو به‌عنوان request ID استفاده می‌کنن.