دیدن کل سفر یک درخواست
Correlation ID به ما کمک می‌کند لاگ‌های مربوط به یک درخواست را پیدا کنیم، اما نمی‌گوید هر مرحله چقدر زمان برده است. ردیابی توزیع‌شده (Distributed Tracing) این خلأ را پر می‌کند: هر درخواست به یک Trace تبدیل می‌شود که از چندین Span (هر Span معادل زمان اجرای یک عملیات در یک سرویس) تشکیل شده است.
Trace: درخواست ثبت سفارش (کل: 340ms)
├── Span: API Gateway (10ms)
├── Span: Order Service (280ms)
│ ├── Span: Inventory Service call (150ms)
│ └── Span: Payment Service call (110ms)
└── Span: پاسخ به کلاینت (5ms)این نمای درختی به‌سرعت نشان می‌دهد کدام سرویس گلوگاه (bottleneck) کارایی است؛ در مثال بالا، فراخوانی سرویس موجودی بیشترین زمان را مصرف کرده است.
ابزارهای رایج
OpenTelemetry استاندارد باز و رایج امروزی برای تولید داده‌ی tracing است که با اکثر زبان‌های برنامه‌نویسی سازگار است، و ابزارهایی مثل Jaeger یا Zipkin این داده‌ها را جمع‌آوری و به‌صورت گرافیکی نمایش می‌دهند. برای فعال کردن tracing، معمولاً یک کتابخانه‌ی client به کد سرویس اضافه می‌شود که به‌طور خودکار Spanها را برای فراخوانی‌های HTTP، پایگاه‌داده و صف پیام می‌سازد. ترکیب لاگ، متریک و trace را «سه ستون مشاهده‌پذیری» (Three Pillars of Observability) می‌نامند که هرکدام دید متفاوتی به سلامت سیستم می‌دهند.