تریسهای توزیعشده رو بخون، حتی اگه کد رو ننوشتی
خلاصهٔ کاملتر
نویسنده (الیزابت از SigNoz) با این واقعیت شروع میکنه که ما مهندسها بیشتر وقتها داریم باگی رو درست میکنیم که خودمون نساختیم و روی کد قدیمیای کار میکنیم که خودمون ننوشتیم. حرف اصلیش اینه که برای خوندن تریس یه کد، لازم نیست خودت اون کد رو نوشته باشی؛ چون تریس مثل مستندیه که خود سیستم نوشته. به نظر نویسنده، فهمیدن مشکل از روی تریس یه مهارته که با تمرین به دست میاد.
اول ساختار یه تریس رو توضیح میده. یه تریس مثل درختی از spanهاست؛ هر span یه واحد کاره، مثل یه فراخوانی HTTP، یه کوئری دیتابیس، یا اجرای یه تابع. span ریشه نقطهٔ ورودیه و بقیه زیرش لانه میکنن. زمان هم از چپ به راست جلو میره. هر span چند چیز رو با خودش حمل میکنه: یه اسم، سرویسی که ازش اومده، یه مدت زمان، یه سری attribute (متادیتای کلید-مقدار مثل http.status_code=500)، یه سری event (لاگهای زماندار، اغلب همراه stack trace) و یه status مثل OK یا ERROR.
بعد انواع spanها رو معرفی میکنه: server span نقطهٔ ورود به یه سرویسه (یعنی این سرویس یه درخواست گرفته)؛ client span فراخوانی بیرونیه (این سرویس داره یکی دیگه رو صدا میزنه) و با server span اونطرف جفت میشه؛ spanهای دیتابیس و کش و صف فراخوانی به لایهٔ داده رو میپیچن و معمولاً خود کوئری SQL تو attributeهاشون هست؛ و internal span کاریه که داخل خود سرویس انجام میشه، که معمولاً یکی دستی instrument کرده چون براش مهم بوده.
قلب مقاله، روش چهار قدمی نویسنده برای خوندن تریسه. قدم اول، ریشه رو پیدا کن: چی این تریس رو راه انداخته؟ یه کاربر، یه جاب زمانبندیشده، یا یه پیام صف؟ قدم دوم، مسیر بحرانی رو دنبال کن، نه طولانیترین span رو: یه span دو ثانیهای که موازی با یه span سه ثانیهای اجرا میشه، اصلاً به تأخیر کلی اضافه نمیکنه؛ سؤال درست اینه که چی جلوی چی رو گرفته.
قدم سوم، شکل تریس رو بخون. نویسنده چند الگوی تکرارشونده رو نشون میده: الگوی پلهای (Staircase) که معمولاً نشونهٔ مشکل N+1 queryه (مثلاً ۵۰ تا پست رو میگیری، بعد تو حلقه برای هر کدوم یه کوئری جدا برای نویسندهش میزنی و به جای ۱-۲ کوئری، ۵۱ تا میزنی)؛ اسپایک (Spike) که وقتی یه span از بقیه پهنتره، نه بار از ده بار همون مقصره؛ گپ (Gap) که زمان مردهٔ بین spanهاست و معمولاً یعنی کار instrumentنشده یا تأخیر شبکه یا مکث GC؛ و پایانهای همزمان که معمولاً یا یه timeout شلیک کرده یا یه قفل آزاد شده.
قدم چهارم، attributeها رو بخون؛ بعد از پیدا کردن span مشکوک، جواب اغلب تو خود attributeهاست: db.statement کوئری کند رو نشون میده و exception.stacktrace خط خراب رو. در آخر نویسنده میگه این مهارت کمکت میکنه از روی رفتار واقعی سیستم تو production معماری رو یاد بگیری؛ چیزی که اغلب از خوندن خود کد بهتره، چون کد میگه چی باید اتفاق بیفته، ولی تریس میگه واقعاً چی داره اتفاق میافته.
نکات کلیدی:
- تریس مثل مستندیه که خود سیستم نوشته؛ برای خوندنش لازم نیست کد رو نوشته باشی
- هر span یه واحد کاره با اسم، سرویس، مدت زمان، attribute، event و status
- روش چهار قدمی: پیدا کردن ریشه، دنبال کردن مسیر بحرانی، خوندن شکل، خوندن attributeها
- مسیر بحرانی مهمه نه طولانیترین span؛ spanهای موازی به تأخیر اضافه نمیکنن
- الگوی پلهای نشونهٔ N+1 query، اسپایک نشونهٔ گلوگاه، و گپ نشونهٔ کار instrumentنشدهست




