سه مفهوم اصلی
تریس (Trace)
تریس مسیر کامل اجرای یک درخواست است؛ از زمانی که درخواست کاربر آغاز میشود تا زمانی که پاسخ نهایی را دریافت میکند.
یک تریس میتواند از چند سرویس عبور کند. برای مثال، درخواست پرداخت ممکن است از مرورگر به API اصلی، سرویس پرداخت و دیتابیس منتقل شود. همه این بخشها با یک شناسه تریس (Trace ID) به هم مرتبط میشوند تا مشخص باشد به یک درخواست تعلق دارند.
تراکنش (Transaction)
تراکنش بخشی از تریس است که اجرای درخواست در یک سرویس یا قسمت مشخصی از اپلیکیشن را ثبت میکند.
برای نمونه، بارگذاری صفحه پرداخت در مرورگر میتواند یک تراکنش باشد. پردازش درخواست پرداخت در Backend نیز تراکنش دیگری است. اگر هر دو به یک درخواست کاربر مربوط باشند و ردیابی بهدرستی پیکربندی شده باشد، زیر یک Trace ID قرار میگیرند.
هر تراکنش مدتزمان مشخصی دارد و نشان میدهد یک عملیات اصلی چقدر طول کشیده است.
اسپن (Span)
اسپن کوچکترین بخش قابلاندازهگیری در یک تراکنش است. هر Span یک عملیات مشخص، مانند اجرای کوئری دیتابیس، فراخوانی یک API یا پردازش بخشی از درخواست را نمایش میدهد.
هر اسپن معمولاً نام، زمان شروع و مدت اجرا دارد. بررسی Spanها کمک میکند مشخص شود کدام مرحله بیشترین زمان را مصرف کرده یا باعث کندی تراکنش شده است.
تریس کل مسیر درخواست است، تراکنش اجرای بخشی از این مسیر در یک سرویس را نشان میدهد و اسپن یکی از عملیاتهای داخل تراکنش است.
چرا Trace و Transaction شبیه به نظر میرسند؟
اگر فقط یک سرویس ردیابی شود، ممکن است یک تریس فقط شامل یک تراکنش باشد. در چنین شرایطی، Trace و Transaction تقریباً یک محدوده زمانی و اطلاعات مشابهی دارند و تفاوت آنها بهوضوح دیده نمیشود.
این تفاوت زمانی مشخصتر میشود که درخواست میان چند سرویس جابهجا شود. فرض کنید Frontend یک درخواست برای API اصلی میفرستد و API نیز سرویس پرداخت را فراخوانی میکند. در این حالت ممکن است سه تراکنش ثبت شوند:
- تراکنش مربوط به Frontend؛
- تراکنش مربوط به API اصلی؛
- تراکنش مربوط به سرویس پرداخت.
هر تراکنش اجرای درخواست را در یک بخش نشان میدهد، اما همه آنها با یک Trace ID به یکدیگر متصل میشوند و بخشی از یک تریس هستند.
این ارتباط زمانی برقرار میشود که Tracing در سرویسهای مرتبط فعال باشد و اطلاعات ردیابی همراه درخواستها منتقل شوند. در غیر این صورت، ممکن است هر سرویس اطلاعات خود را جداگانه ثبت کند و سنتری نتواند آنها را در یک مسیر نمایش دهد.
Spanها چگونه به شناسایی کندی کمک میکنند؟
دانستن اینکه یک صفحه در شش ثانیه بارگذاری شده است، بهتنهایی علت کندی را مشخص نمیکند. مشکل ممکن است از دیتابیس، یک API خارجی یا پردازش داخلی برنامه باشد.
Spanها مدت اجرای هر مرحله را روی یک خط زمانی نمایش میدهند. برای مثال، یک تراکنش مربوط به صفحه پرداخت ممکن است چنین ساختاری داشته باشد:
checkout page 6.2s
├── db: get cart 0.1s
├── http: call payment-api 5.8s
└── render 0.3s
در این مثال، فراخوانی سرویس پرداخت بیشتر زمان تراکنش را مصرف کرده است. اگر سرویس پرداخت نیز به سنتری متصل باشد و انتقال Trace ID بهدرستی انجام شود، میتوانید تراکنش همان سرویس و Spanهای داخلی آن را هم بررسی کنید. شاید منشأ اصلی کندی، یک کوئری دیتابیس در سرویس پرداخت باشد.
در نتیجه، یک تریس میتواند چند تراکنش داشته باشد و هر تراکنش نیز میتواند شامل چند Span باشد.
Spanها چگونه ایجاد میشوند؟
SDKهای سنتری، بسته به زبان، فریمورک و تنظیمات فعال، میتوانند بعضی عملیاتهای رایج مانند درخواستهای HTTP یا کوئریهای دیتابیس را بهصورت خودکار ثبت کنند.
برای عملیاتهای اختصاصی برنامه نیز میتوانید Spanهای سفارشی تعریف کنید. برای مثال، اگر محاسبه قیمت سفارش یا پردازش یک فایل برای شما اهمیت دارد، میتوانید زمان اجرای آن را در قالب یک Span اندازهگیری کنید.
فعالسازی Tracing میتواند تعداد Transactionهای ارسالی به سنتری را افزایش دهد. برای کنترل این مقدار میتوانید از نمونهبرداری (Sampling) استفاده کنید و فقط درصد مشخصی از تراکنشها را بفرستید.
خلاصه
- Trace: مسیر کامل یک درخواست در یک یا چند سرویس؛
- Transaction: اجرای بخشی از درخواست در یک سرویس یا قسمت مشخص؛
- Span: یک عملیات قابلاندازهگیری داخل Transaction؛
- Trace ID: شناسهای که Transactionهای مربوط به یک درخواست را به هم متصل میکند.
درک این سه مفهوم کمک میکند دادههای Performance Monitoring را بهتر بخوانید و منشأ کندی را در بخشهای مختلف اپلیکیشن پیدا کنید.