تفاوت متریک، لاگ و Tracing چیست؟ راهنمای ساده و کاربردی

فرض کنید کاربران فروشگاه شما می‌گویند صفحه پرداخت کند شده است. برای پیدا کردن علت مشکل چند سؤال مهم دارید:

• این کندی از چه زمانی شروع شده و چند درصد کاربران را درگیر کرده است؟
• هنگام کندی چه خطایی در برنامه رخ داده است؟
• درخواست کاربر بین سرویس‌های مختلف از چه مسیری عبور کرده و دقیقاً در کدام بخش متوقف شده است؟

هرکدام از این سؤال‌ها با نوع متفاوتی از داده پاسخ داده می‌شود:

• متریک (Metric) می‌گوید چه اتفاقی در حال رخ‌دادن است.
• لاگ (Log) جزئیات رخداد و خطا را نشان می‌دهد.
• Trace مسیر کامل یک درخواست را بین بخش‌های مختلف سیستم دنبال می‌کند.

متریک، لاگ و Trace سه ستون اصلی Observability یا مشاهده‌پذیری هستند. در این مقاله تفاوت آن‌ها را ابتدا با زبان ساده و سپس با جزئیات فنی بررسی می‌کنیم.

تفاوت متریک، لاگ و Trace در یک نگاه

یک تشبیه ساده این است: متریک مانند چراغ هشدار خودرو است و وجود مشکل را اعلام می‌کند؛ لاگ مانند گزارش کامپیوتر خودرو جزئیات خطا را می‌دهد؛ و Trace مانند دنبال‌کردن مسیر سوخت از باک تا موتور نشان می‌دهد مشکل دقیقاً در کدام مرحله ایجاد شده است.

متریک یا Metric چیست؟

متریک یک مقدار عددی است که در طول زمان اندازه‌گیری می‌شود. مصرف CPU، میزان RAM، تعداد درخواست‌ها، نرخ خطا، زمان پاسخ API و تعداد کاربران آنلاین همگی نمونه‌هایی از متریک هستند.

برای مثال، داده زیر می‌گوید مصرف CPU یک سرور در یک زمان مشخص ۸۲ درصد بوده است:

server_cpu_usage{host="api-01"} 82

متریک‌ها معمولاً همراه با Timestamp و تعدادی Label یا Tag ذخیره می‌شوند. Label کمک می‌کند داده را براساس سرور، سرویس، Endpoint، منطقه یا نسخه برنامه تفکیک کنیم.

نمونه‌های رایج متریک

• درصد مصرف CPU و RAM
• فضای آزاد دیسک
• تعداد درخواست در ثانیه
• نرخ پاسخ‌های خطای 5xx
• میانگین و صدک ۹۵ زمان پاسخ
• تعداد Jobهای موجود در Queue
• تعداد اتصال‌های فعال دیتابیس
• نرخ خرید موفق یا ناموفق

متریک چه مزیتی دارد؟

متریک فشرده و مناسب تحلیل در بازه‌های زمانی طولانی است. با آن می‌توان نمودار ساخت، وضعیت فعلی را با هفته قبل مقایسه کرد و برای عبور یک مقدار از حد مشخص هشدار تعریف کرد.

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

محدودیت متریک چیست؟

متریک معمولاً می‌گوید مشکلی وجود دارد، اما به‌تنهایی علت دقیق آن را مشخص نمی‌کند. نمودار CPU می‌تواند افزایش مصرف را نشان دهد، اما نمی‌گوید کدام درخواست، Query یا خط کد باعث این افزایش شده است.

Labelهای بسیار متنوع نیز ممکن است باعث High Cardinality شوند. برای مثال، قراردادن شناسه منحصربه‌فرد هر کاربر در Label متریک می‌تواند تعداد Time Seriesها و هزینه ذخیره‌سازی را به‌شدت افزایش دهد. داده‌های منحصربه‌فرد معمولاً برای لاگ یا Trace مناسب‌ترند.

لاگ یا Log چیست؟

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

{
  "timestamp": "2026-07-30T08:42:11Z",
  "level": "error",
  "service": "payment-api",
  "message": "Database connection timeout",
  "requestId": "req_82f19",
  "durationMs": 3000
}

این لاگ مشخص می‌کند خطا در سرویس پرداخت رخ داده، علت ثبت‌شده Timeout اتصال به دیتابیس بوده و درخواست سه ثانیه منتظر مانده است.

سطوح رایج لاگ

• Debug: جزئیات زیاد برای توسعه و عیب‌یابی
• Info: رخدادهای عادی مانند شروع سرویس یا تکمیل سفارش
• Warn: وضعیت غیرعادی که هنوز به خطای کامل تبدیل نشده است
• Error: خطایی که یک عملیات را مختل کرده است
• Fatal: خطای بحرانی که ممکن است باعث توقف سرویس شود

لاگ ساختاریافته بهتر است یا متن ساده؟

برای محیط Production، لاگ ساختاریافته مانند JSON معمولاً انتخاب بهتری است. در این حالت فیلدهایی مثل نام سرویس، وضعیت سفارش، شناسه درخواست و زمان اجرا جداگانه ذخیره می‌شوند و می‌توان آن‌ها را فیلتر، گروه‌بندی و جست‌وجو کرد.

برای مثال، جست‌وجوی تمام خطاهای سرویس پرداخت با مدت بیشتر از دو ثانیه در لاگ ساختاریافته بسیار ساده‌تر از جست‌وجو در هزاران خط متن نامنظم است.

لاگ چه مزیتی دارد؟

• جزئیات فنی و Context رخداد را نگه می‌دارد.
• برای بررسی Exception، Stack Trace و رفتار غیرمنتظره مناسب است.
• به توسعه‌دهنده اجازه می‌دهد براساس Request ID، User ID یا Order ID جست‌وجو کند.
• برای Audit، بررسی امنیتی و تحلیل رخدادهای کسب‌وکار نیز کاربرد دارد.

محدودیت لاگ چیست؟

حجم لاگ می‌تواند بسیار سریع رشد کند. ثبت جزئیات بیش از حد، علاوه‌بر افزایش هزینه Storage و پردازش، پیدا کردن داده مهم را دشوار می‌کند. از طرف دیگر، اگر Context کافی ثبت نشود، لاگ در لحظه عیب‌یابی ارزش چندانی نخواهد داشت.

لاگ‌ها همچنین ممکن است شامل اطلاعات حساس باشند. رمز عبور، Token، اطلاعات کارت بانکی و داده‌های شخصی نباید به‌صورت خام وارد لاگ شوند و بهتر است سیاست‌های Masking و Retention برای آن‌ها تعریف شود.

Tracing یا ردیابی توزیع‌شده چیست؟

Trace مسیر کامل یک درخواست را از لحظه ورود تا پایان آن دنبال می‌کند. این قابلیت به‌خصوص در معماری Microservices اهمیت دارد؛ زیرا یک درخواست ممکن است از API Gateway وارد شود، سپس به سرویس سفارش، پرداخت، موجودی، دیتابیس و یک API خارجی برسد.

هر Trace از چند Span تشکیل می‌شود. Span نماینده یک مرحله از پردازش است و اطلاعاتی مانند زمان شروع، مدت اجرا، وضعیت، سرویس مربوطه و ارتباط آن با Span قبلی را نگه می‌دارد.

Trace: checkout-request (2.1s)
├── API Gateway (45ms)
├── Order Service (180ms)
├── Inventory Service (120ms)
└── Payment Service (1.7s)
    ├── Database Query (1.4s)
    └── Payment Provider (220ms)

در این مثال، بدون بررسی تک‌تک سرویس‌ها می‌توان دید که بخش اصلی کندی داخل Query دیتابیس سرویس پرداخت ایجاد شده است.

Trace، Span و Trace ID به زبان ساده

• Trace: کل سفر یک درخواست در سیستم
• Span: یک مرحله از این سفر، مانند اجرای Query یا فراخوانی API
• Trace ID: شناسه مشترکی که تمام Spanهای یک درخواست را به هم متصل می‌کند
• Parent Span: مرحله‌ای که Span فعلی از آن ایجاد شده است

Tracing چه مزیتی دارد؟

• مسیر درخواست میان سرویس‌ها را به‌صورت End-to-end نشان می‌دهد.
• گلوگاه‌های عملکرد را در سطح سرویس، عملیات و Query مشخص می‌کند.
• وابستگی پنهان بین سرویس‌ها را آشکار می‌کند.
• خطاهای زنجیره‌ای در معماری Microservices را قابل‌ردیابی می‌کند.
• برای تحلیل APM و مقایسه عملکرد نسخه‌های مختلف برنامه مناسب است.

محدودیت Tracing چیست؟

راه‌اندازی Tracing به Instrumentation برنامه و انتقال درست Trace Context بین سرویس‌ها نیاز دارد. در سیستم پرترافیک، ذخیره تمام Traceها نیز ممکن است حجم و هزینه زیادی ایجاد کند؛ به همین دلیل از Sampling استفاده می‌شود.

در Sampling فقط بخشی از درخواست‌ها ذخیره می‌شوند. یک سیاست مناسب می‌تواند درصدی از درخواست‌های عادی و سهم بیشتری از درخواست‌های کند یا خطادار را نگه دارد تا ضمن کنترل هزینه، داده‌های مهم از دست نروند.

یک مثال واقعی: چرا پرداخت فروشگاه کند شده است؟

اکنون ببینیم این سه نوع داده چگونه در کنار هم علت مشکل را پیدا می‌کنند.

مرحله اول: متریک مشکل را کشف می‌کند

داشبورد نشان می‌دهد صدک ۹۵ زمان پاسخ Endpoint پرداخت از ۴۰۰ میلی‌ثانیه به ۲.۴ ثانیه رسیده و نرخ خطا نیز از ۱ به ۸ درصد افزایش پیدا کرده است. Alert فعال می‌شود و تیم متوجه مشکل می‌شود.

در این مرحله می‌دانیم چه چیزی خراب شده، مشکل از چه زمانی شروع شده و چه تعداد درخواست تحت‌تأثیر قرار گرفته‌اند؛ اما هنوز علت را نمی‌دانیم.

مرحله دوم: Trace محل کندی را پیدا می‌کند

یک Trace کند را باز می‌کنیم. درخواست ابتدا از API Gateway و سرویس سفارش عبور کرده، اما در سرویس پرداخت ۱.۸ ثانیه منتظر یک Query دیتابیس مانده است. اکنون محدوده مشکل از کل سیستم به یک عملیات مشخص کاهش یافته است.

مرحله سوم: لاگ علت دقیق را نشان می‌دهد

با استفاده از Trace ID، لاگ‌های همان درخواست را فیلتر می‌کنیم. لاگ‌ها نشان می‌دهند Connection Pool دیتابیس پر شده و چند اتصال به‌دلیل Timeout آزاد نشده‌اند. در نتیجه علت اصلی مشخص می‌شود.

این سناریو نقش هر داده را به‌خوبی نشان می‌دهد:

• Metric: مشکل وجود دارد و گستردگی آن چقدر است؟
• Trace: مشکل در کدام سرویس یا عملیات رخ داده است؟
• Log: جزئیات فنی و علت احتمالی خطا چیست؟

آیا یکی از این سه مورد به‌تنهایی کافی است؟

در سیستم‌های ساده ممکن است فقط با متریک و چند لاگ بتوان بسیاری از مشکلات را بررسی کرد، اما با بزرگ‌ترشدن برنامه، افزایش ترافیک و اضافه‌شدن سرویس‌ها، استفاده جداگانه از این داده‌ها محدودکننده می‌شود.

بیشترین ارزش زمانی ایجاد می‌شود که این سه داده به یکدیگر متصل باشند. برای مثال، از روی یک نقطه غیرعادی در نمودار متریک وارد Traceهای همان بازه شوید و سپس لاگ‌های مرتبط با یک Trace ID را مشاهده کنید. به این ارتباط Correlation گفته می‌شود.

Monitoring و Observability چه تفاوتی دارند؟

Monitoring معمولاً وضعیت‌های از قبل شناخته‌شده را بررسی می‌کند: آیا CPU بالا است؟ آیا API پاسخ می‌دهد؟ آیا نرخ خطا از حد مشخص عبور کرده است؟

Observability مفهوم گسترده‌تری است و کمک می‌کند با بررسی داده‌های خروجی سیستم، علت وضعیت‌هایی را پیدا کنیم که از قبل برای آن‌ها داشبورد یا Alert مشخصی نساخته‌ایم.

به زبان ساده، Monitoring می‌گوید «سیستم مشکلی دارد» و Observability کمک می‌کند بفهمیم «چرا این مشکل ایجاد شده است». متریک، لاگ و Trace داده‌های اصلی برای رسیدن به این دید هستند.

برای هر نوع داده چه ابزاری استفاده می‌شود؟

در استک Self-host، معمولاً چند ابزار مختلف برای جمع‌آوری، ذخیره‌سازی و نمایش این داده‌ها کنار هم قرار می‌گیرند. این روش کنترل زیادی می‌دهد، اما نصب، مقیاس‌پذیری، Retention، Backup و نگهداری آن برعهده تیم شما خواهد بود.

پلتفرم‌های مدیریت‌شده این داده‌ها را در یک محیط جمع می‌کنند تا جابه‌جایی میان داشبورد، Trace و لاگ ساده‌تر شود.

OpenTelemetry چه نقشی دارد؟

OpenTelemetry یک استاندارد و مجموعه ابزار متن‌باز برای تولید، جمع‌آوری و ارسال Telemetry Data است. این پروژه به شما کمک می‌کند متریک، لاگ و Trace را با روش استاندارد از برنامه دریافت کنید و به Backend دلخواه بفرستید.

OpenTelemetry خودش الزاماً محل نهایی ذخیره یا مشاهده داده نیست. می‌توان آن را مانند یک زبان و مسیر استاندارد میان برنامه و پلتفرم Observability در نظر گرفت.

مزیت مهم آن کاهش وابستگی مستقیم به یک Vendor است. اگر Instrumentation برنامه براساس OpenTelemetry انجام شود، تغییر مقصد داده یا استفاده هم‌زمان از چند Backend ساده‌تر خواهد بود.

برای شروع چه داده‌هایی را جمع‌آوری کنیم؟

لازم نیست از روز اول همه‌چیز را ثبت کنید. جمع‌آوری بدون برنامه می‌تواند هزینه و نویز زیادی ایجاد کند. برای شروع، این مسیر عملی است:

1. متریک‌های طلایی را فعال کنید: نرخ درخواست، نرخ خطا، مدت پاسخ و میزان اشباع منابع را برای سرویس‌های اصلی اندازه بگیرید.
2. لاگ ساختاریافته ثبت کنید: حداقل Timestamp، Level، Service Name، Environment، Request ID و پیام قابل‌فهم داشته باشید.
3. Trace را از مسیرهای حیاتی شروع کنید: ثبت‌نام، ورود، پرداخت و ثبت سفارش معمولاً ارزش بیشتری نسبت به عملیات‌های کم‌اهمیت دارند.
4. داده‌ها را به هم مرتبط کنید: Trace ID و Request ID را داخل لاگ قرار دهید و نام سرویس و محیط را در هر سه نوع داده یکسان نگه دارید.
5. Retention و Sampling تعریف کنید: همه داده‌ها لازم نیست برای همیشه یا با جزئیات یکسان نگهداری شوند.
6. اطلاعات حساس را حذف یا Mask کنید: امنیت داده باید از زمان تولید Telemetry در نظر گرفته شود.

اشتباهات رایج در استفاده از متریک، لاگ و Trace

• ساخت ده‌ها داشبورد بدون مشخص‌کردن اینکه چه تصمیمی با آن‌ها گرفته می‌شود
• ارسال Alert برای هر تغییر کوچک و ایجاد Alert Fatigue
• ثبت لاگ‌های زیاد اما بدون Service Name، Request ID یا Context کافی
• استفاده از User ID و مقادیر منحصربه‌فرد به‌عنوان Label متریک
• ذخیره تمام Traceها بدون سیاست Sampling
• یکسان‌نبودن نام سرویس‌ها و Environmentها بین سه منبع داده
• ثبت رمز عبور، Token یا اطلاعات شخصی در لاگ و Span
• تمرکز روی مصرف CPU و RAM و نادیده‌گرفتن متریک‌های تجربه کاربر و کسب‌وکار

متریک، لاگ و Trace در Watchlog

Watchlog این سه نوع داده را در یک پلتفرم Observability در اختیار تیم قرار می‌دهد:

• Infrastructure Monitoring برای مشاهده متریک‌های سرور، سرویس و Integrationها
• Log Monitoring برای جمع‌آوری، جست‌وجو، فیلتر و تحلیل لاگ‌ها
• APM و Distributed Tracing برای بررسی Transaction، Span، خطا و گلوگاه عملکرد
• Alerting برای اطلاع‌رسانی از طریق Email، Telegram، Slack و Webhook
• مانیتورینگ API، Kubernetes، تجربه کاربر و تست‌های Synthetic در همان پنل

مزیت یک پلتفرم یکپارچه فقط داشتن چند نمودار در یک صفحه نیست. ارزش اصلی زمانی ایجاد می‌شود که تیم بتواند از هشدار و متریک غیرعادی به سرویس مشکل‌دار، Trace کند و لاگ مرتبط برسد و زمان تشخیص علت خطا یا MTTR را کاهش دهد.

اگر نمی‌خواهید برای متریک، لاگ، Trace و Alert چند ابزار جداگانه نصب و نگهداری کنید، می‌توانید با پلن رایگان Watchlog شروع کنید یا برای زیرساخت‌های سازمانی درخواست دمو ثبت کنید.

سؤالات متداول

تفاوت اصلی Metric و Log چیست؟

Metric یک مقدار عددی قابل‌اندازه‌گیری در طول زمان است و برای نمودار، روند و Alert کاربرد دارد. Log رکورد جزئی‌تری از یک رخداد است و Context، پیام خطا یا اطلاعات اجرای برنامه را نگه می‌دارد.

تفاوت Log و Trace چیست؟

Log معمولاً یک رخداد مستقل را ثبت می‌کند، اما Trace چند مرحله مرتبط از یک درخواست را در کنار هم قرار می‌دهد. با Trace می‌توان دید درخواست بین سرویس‌ها از چه مسیری عبور کرده و هر مرحله چقدر زمان برده است.

آیا APM همان Tracing است؟

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

آیا برای یک برنامه کوچک به هر سه مورد نیاز داریم؟

برای یک برنامه کوچک، متریک‌های پایه و لاگ ساختاریافته نقطه شروع خوبی هستند. Trace زمانی ارزش بیشتری پیدا می‌کند که چند سرویس، دیتابیس، Queue یا API خارجی در مسیر درخواست وجود داشته باشد یا پیدا کردن گلوگاه عملکرد دشوار شده باشد.

برای Alert از کدام داده استفاده کنیم؟

متریک معمولاً بهترین گزینه برای Alertهای پایدار و قابل‌کنترل است؛ مانند نرخ خطا، Latency یا مصرف منابع. برای بعضی خطاهای مشخص می‌توان از Log Alert نیز استفاده کرد. Trace بیشتر برای تحلیل علت و مسیر درخواست پس از شناسایی مشکل کاربرد دارد.

سه ستون اصلی Observability چیست؟

در مدل رایج، Metrics، Logs و Traces سه ستون اصلی Observability محسوب می‌شوند. البته در سیستم‌های مدرن داده‌های دیگری مانند Profile، Event و تجربه واقعی کاربر نیز می‌توانند این دید را کامل‌تر کنند.

جمع‌بندی

متریک، لاگ و Trace رقیب یکدیگر نیستند و هرکدام بخش متفاوتی از واقعیت سیستم را نشان می‌دهند. متریک برای کشف سریع مشکل و مشاهده روندها مناسب است؛ لاگ جزئیات رخداد را در اختیار شما می‌گذارد؛ و Trace مسیر کامل درخواست و محل کندی یا خطا را مشخص می‌کند.

اگر فقط یک جمله از این مقاله به خاطر بسپارید، این باشد:

• Metric: چه مشکلی و با چه شدتی رخ داده است؟
• Trace: مشکل در کدام بخش از مسیر درخواست است؟
• Log: هنگام وقوع مشکل چه جزئیاتی ثبت شده است؟

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