Logs در مقابل Metrics
Log رویدادهای گسسته و متنی هستند که جزئیات دقیق چهاتفاقی در یک لحظهی خاص رخ داده را ثبت میکنند (مثلاً یک خطا یا یک درخواست خاص)؛ Metric مقادیر عددی جمعشده در طول زمان هستند (مثل نرخ درخواست یا میانگین تأخیر) که برای رصد روند و سلامت کلی سیستم بهینه شدهاند.
| ویژگی | Logs | Metrics |
|---|---|---|
| نوع داده | متن غیرساختیافته/نیمهساختیافته | عدد ساختیافته (counter/gauge/histogram) |
| حجم ذخیرهسازی | زیاد (به ازای هر رویداد) | کم (نمونهبرداری/تجمیعشده) |
| کاربرد اصلی | دیباگ دقیق یک رویداد | رصد روند و هشدار (alerting) |
| هزینه query در بازه طولانی | بالا | پایین |
کِی از Logs استفاده کنیم؟
وقتی نیاز به بررسی دقیق یک رویداد یا خطای مشخص دارید (مثلاً "چرا این درخواست با شناسه X شکست خورد؟")، به سراغ Log بروید؛ جزئیات کامل context را در خود دارد.
کِی از Metrics استفاده کنیم؟
وقتی میخواهید روند کلی سلامت سیستم را در طول زمان رصد کنید، آستانه هشدار (alert threshold) تنظیم کنید یا داشبورد بسازید (مثل CPU، نرخ خطا، تأخیر p99)، از Metric استفاده کنید؛ چون فشرده و کمحجم است و برای query سریع در بازههای زمانی طولانی بهینه شده.
مثال Logs
2026-08-14T10:22:31Z ERROR OrderService: Payment failed for orderId=8841
reason=InsufficientFunds userId=203 amount=459000
مثال Metrics
# Prometheus query: p99 request latency over 5m
histogram_quantile(0.99,
rate(http_request_duration_seconds_bucket[5m]))
اشتباه رایج
تیمها گاهی سعی میکنند از طریق grep و شمارش خطوط Log، معیارهای عملکردی مثل نرخ خطا در طول زمان استخراج کنند که هم کند است و هم مقیاسپذیر نیست؛ برای این کار باید از ابتدا Metric مجزا (counter/histogram) کنار Log ثبت کرد، نه اینکه Log را جایگزین Metric کرد.
جمعبندی
برای "چرا خراب شد؟" سراغ Log بروید؛ برای "چقدر سالم است؟" سراغ Metric بروید — بهترین observability هر دو را کنار هم دارد.