سیستم توزیعشده بدون رصدپذیری، جعبه سیاهی است که فقط وقتی کاربران توییت زدند میفهمی خراب است. سه ستون: Log ،Metric ،Trace — و رویشان: هشدارِ درست.
Logs
رویدادهای گسسته با جزئیات. ساختیافته (JSON) بنویس تا قابل جستجو باشد؛ سطحبندی (info/warn/error) و بدون داده حساس.
Metrics
اعداد تجمیعی سریزمانی: QPS، خطا، تأخیر p99 ،CPU. ارزان، مناسب داشبورد و هشدار.
Traces
سفر یک درخواست بین سرویسها با trace_id مشترک: کدام قدم 900ms خورد؟ بدون این، دیباگ microservices شکنجه است.
چه چیزی را بپاییم؟ چارچوب RED
- Rate — نرخ درخواست هر سرویس
- Errors — نرخ و نوع خطاها
- Duration — توزیع تأخیر (p50/p95/p99، نه فقط میانگین!)
- + برای منابع: USE (Utilization ،Saturation ،Errors) — CPU، حافظه، دیسک، صفها
هنر هشدار
- روی علائمِ کاربر-محور هشدار بده (نرخ خطا، p99)، نه هر پرش CPU — وگرنه Alert Fatigue: تیمی که هشدارها را silent میکند.
- هر هشدار باید «قابل اقدام» باشد: کی بیدار شود و چه کند (Runbook).
- SLO محور: بودجه خطا (Error Budget) تعریف کن؛ سوختن سریع بودجه = هشدار.
به زبان ساده
Logs میگویند چه رخ داده، metrics میگویند چقدر رخ داده و trace میگوید یک درخواست از کجا کند شده است.
مثال واقعی
وقتی سفارش دیر ثبت میشود، trace نشان میدهد ۹۰۰ms زمان در پرداخت بوده یا در دیتابیس؛ حدس نمیزنیم.