خطاها نشان میدهند چه چیزی از کار افتاده است؛ مسیرهای ردیابی نشان میدهند زمان اجرای اپلیکیشن در کدام بخش مصرف شده است. در سنتری، مسیر ردیابی (Trace) بهشکل نمودار آبشاری (Waterfall) نمایش داده میشود و به شما کمک میکند منشأ کندی را در یک درخواست، بارگذاری صفحه یا وظیفه پسزمینه پیدا کنید.
برای خواندن این نمودار باید دو چیز را بررسی کنید: مدت اجرای هر عملیات و شکل قرارگرفتن عملیاتها در کنار یکدیگر.
ساختار Trace در سنتری
هر Trace مسیر کامل یک عملیات را نشان میدهد و میتواند شامل یک یا چند تراکنش (Transaction) باشد. هر Transaction نیز از چند بازه (Span) تشکیل میشود.
در نمودار Waterfall، هر Span با یک نوار افقی نمایش داده میشود:
- طول نوار مدت اجرای Span را نشان میدهد.
- موقعیت نوار مشخص میکند عملیات چه زمانی آغاز و تمام شده است.
- تورفتگی نوارها ارتباط والد و فرزند را نشان میدهد.
- همپوشانی نوارها میتواند نشاندهنده اجرای همزمان عملیاتها باشد.
- فاصلههای خالی ممکن است به اجرای کدی مربوط باشند که برای آن Span ثبت نشده است.
برای مثال، یک Transaction مربوط به صفحه پرداخت میتواند شامل Spanهایی برای دریافت سبد خرید، فراخوانی درگاه پرداخت و پردازش پاسخ باشد. مقایسه مدت این Spanها نشان میدهد کدام مرحله بیشترین سهم را در زمان اجرای درخواست داشته است.
الگوهای مهم در نمودار Waterfall
بیشتر مشکلات عملکردی در یکی از الگوهای زیر دیده میشوند.
یک Span طولانی
اگر یک Span بخش بزرگی از زمان Transaction را مصرف کرده باشد، همان عملیات اولین سرنخ شما برای بررسی است. این Span ممکن است یک کوئری دیتابیس، درخواست HTTP یا پردازش داخلی باشد.
طولانیترین Span همیشه علت نهایی مشکل نیست، اما نقطه مناسبی برای شروع بررسی است. برای مثال، کندبودن فراخوانی یک API خارجی ممکن است به شبکه، Timeout، حجم پاسخ یا رفتار خود سرویس مقصد مربوط باشد.
Spanهای تکراری
اگر چند Span مشابه پشتسرهم تکرار شده باشند، ممکن است یک عملیات داخل حلقه اجرا شده باشد. تکرار تعداد زیادی کوئری مشابه میتواند نشانه مشکل N+1 Query باشد.
در این شرایط، فقط بهینهکردن یک کوئری کافی نیست. ممکن است لازم باشد نحوه دریافت دادهها را تغییر دهید، چند درخواست را در یک عملیات گروهبندی کنید یا از Eager Loading استفاده کنید.
تکرار Spanها همیشه بهمعنای N+1 نیست. نام عملیات، تعداد تکرار و دادههای هر Span را بررسی کنید تا مطمئن شوید این الگو واقعاً غیرضروری است.
فاصله خالی طولانی
گاهی Transaction مدت زیادی طول کشیده است، اما Spanهای ثبتشده فقط بخش کوچکی از آن را پوشش میدهند. این فاصله میتواند مربوط به کدی باشد که SDK آن را بهصورت خودکار ردیابی نکرده است.
عملیات مسدودکننده، انتظار برای Lock، اجرای یک حلقه سنگین یا بخشی از کد اختصاصی برنامه میتوانند چنین فاصلهای ایجاد کنند. برای بررسی دقیقتر، میتوانید برای آن بخش یک Span سفارشی بسازید و Traceهای بعدی را دوباره بررسی کنید.
اجرای ترتیبی یا همزمان غیرمنتظره
نمودار Waterfall نشان میدهد عملیاتها بهصورت ترتیبی اجرا شدهاند یا همزمان. اگر چند درخواست مستقل پشتسرهم اجرا شده باشند، شاید بتوان آنها را بهصورت موازی اجرا کرد.
از طرف دیگر، همپوشانی غیرمنتظره Spanها ممکن است نشان دهد چند عملیات همزمان روی یک منبع مشترک اجرا میشوند. این وضعیت میتواند به رقابت بر سر منابع، Lock یا افزایش بار سرویس منجر شود.
ترتیب بررسی یک Trace
برای بررسی سریعتر، این مسیر را دنبال کنید:
-
مدت کل Transaction را ببینید. ابتدا مشخص کنید عملیات اصلی چقدر طول کشیده و آیا واقعاً از محدوده موردانتظار کندتر بوده است.
-
طولانیترین Span را پیدا کنید. اگر یک Span بیشتر زمان Transaction را مصرف کرده است، بررسی را از همانجا شروع کنید.
-
شکل نمودار را بررسی کنید. به Spanهای تکراری، فاصلههای خالی و عملیاتهای ترتیبی یا همزمان توجه کنید.
-
جزئیات Span را باز کنید. بسته به نوع Span و تنظیمات SDK، ممکن است اطلاعاتی مانند نام عملیات، آدرس درخواست، مدت اجرا، توضیح کوئری و Tags نمایش داده شوند.
-
چند Trace مشابه را مقایسه کنید. یک Trace کند ممکن است یک رخداد استثنایی باشد. اگر همان Span در چند نمونه مشابه کند باشد، احتمال وجود یک مشکل پایدار بیشتر است.
-
بخشهای بدون Span را مشخص کنید. اگر بخش مهمی از زمان قابلتوضیح نیست، ردیابی سفارشی را به همان قسمت اضافه کنید.
بررسی p50، p95 و p99
هر Trace فقط یک نمونه از اجرای عملیات است. برای ارزیابی عملکرد کلی باید توزیع زمان پاسخ را نیز بررسی کنید.
- p50 میانه زمان پاسخ را نشان میدهد؛ یعنی نیمی از درخواستها سریعتر از این مقدار بودهاند.
- p95 مقداری است که ۹۵ درصد درخواستها سریعتر از آن اجرا شدهاند.
- p99 وضعیت درخواستهای بسیار کند را نشان میدهد.
برای مثال، اگر p50 برابر ۸۰ میلیثانیه و p95 برابر ۱٫۲ ثانیه باشد، بیشتر درخواستها سریعاند، اما بخشی از کاربران کندی قابلتوجهی را تجربه میکنند.
بهتر است فقط به میانگین متکی نباشید. میانگین ممکن است تحتتأثیر چند درخواست بسیار سریع یا بسیار کند قرار بگیرد و پراکندگی واقعی دادهها را نشان ندهد. فاصله زیاد میان p50 و p95 نیز میتواند نشانه وجود مسیرهای اجرایی متفاوت، Cache Miss، اتصال سرد یا ورودیهای بزرگتر باشد.
برای بررسی چنین وضعیتی، یک Trace نزدیک به p50 را با نمونهای نزدیک به p95 مقایسه کنید و تفاوت Spanهای آنها را ببینید.
Trace در چند سرویس
در معماریهای توزیعشده، یک درخواست ممکن است از Frontend به Backend و سپس به سرویسهای دیگر منتقل شود. اگر Tracing در این سرویسها فعال باشد و اطلاعات ردیابی همراه درخواستها منتقل شوند، Transactionهای مرتبط زیر یک Trace ID قرار میگیرند.
در این حالت میتوانید ببینید زمان درخواست در کدام سرویس مصرف شده است. ممکن است Transaction مربوط به Frontend سریع باشد، اما فراخوانی سرویس پرداخت یا دیتابیس در Backend زمان زیادی گرفته باشد.
برای کاملبودن Trace، سرویسها باید اطلاعات ردیابی را بهدرستی منتقل کنند و تصمیم نمونهبرداری والد را ادامه دهند. یکسانبودن tracesSampleRate در همه سرویسها الزامی نیست؛ اما تنظیم نادرست انتشار Trace یا نمونهبرداری میتواند باعث ناقصبودن مسیر شود.
خلاصه
- Trace مسیر کامل یک عملیات را نشان میدهد.
- Transaction اجرای بخشی از این مسیر در یک سرویس است.
- Span یکی از عملیاتهای داخل Transaction است.
- بررسی را از طولانیترین Span شروع کنید.
- Spanهای تکراری میتوانند نشانه N+1 Query باشند.
- فاصلههای خالی ممکن است به بخشهای ردیابینشده مرب وط باشند.
- برای تصمیمگیری، چند Trace را مقایسه کنید و فقط به میانگین متکی نباشید.
- در معماری توزیعشده، انتقال Trace ID برای اتصال سرویسها ضروری است.