اصطلاحات مهم مانیتورینگ که هر برنامه‌نویس و DevOps باید بداند

در یک جلسه فنی ممکن است جمله‌هایی مثل این را بشنوید:

میانگین Latency خوب است، اما p99 بالا رفته؛ نرخ خطا هنوز داخل SLO است، ولی اگر این روند ادامه پیدا کند Error Budget این ماه تمام می‌شود.

اگر با اصطلاحات مانیتورینگ آشنا نباشید، این جمله پیچیده به نظر می‌رسد. اما هر بخش آن درباره یک سؤال ساده است: کاربران چقدر منتظر می‌مانند؟ چند درخواست خراب می‌شود؟ چه مقدار اختلال قابل‌قبول است و تیم با چه سرعتی مشکل را برطرف می‌کند؟

این اصطلاحات فقط مخصوص مهندسان SRE یا شرکت‌های بسیار بزرگ نیستند. یک برنامه‌نویس Backend برای بهینه‌کردن API، یک مهندس DevOps برای تعریف Alert، یک مدیر فنی برای تعیین سطح پایداری سرویس و حتی یک تیم کوچک برای فهمیدن تجربه واقعی کاربران به آن‌ها نیاز دارد.

در این مقاله مهم‌ترین اصطلاحات مانیتورینگ را از سطح مقدماتی تا حرفه‌ای با یک سناریوی واقعی توضیح می‌دهیم. هدف حفظ‌کردن تعریف‌ها نیست؛ هدف این است که بدانید هر عدد چه چیزی درباره سیستم می‌گوید و براساس آن چه تصمیمی باید بگیرید.

سناریوی اصلی: API سریع است، اما کاربران ناراضی‌اند

فرض کنید یک API پرداخت در روز ۱۰۰ هزار درخواست دریافت می‌کند. داشبورد میانگین زمان پاسخ را ۲۰۰ میلی‌ثانیه نشان می‌دهد، اما بعضی کاربران می‌گویند پرداخت چند ثانیه طول می‌کشد.

در نگاه اول همه‌چیز خوب به نظر می‌رسد، ولی جزئیات تصویر متفاوتی نشان می‌دهند:

• میانه زمان پاسخ یا p50 برابر ۱۲۰ میلی‌ثانیه است.
• p95 برابر ۸۰۰ میلی‌ثانیه است.
• p99 برابر ۴ ثانیه است.
• یک درصد درخواست‌ها با خطای 5xx شکست می‌خورند.
• هنگام افزایش ترافیک، Connection Pool دیتابیس پر می‌شود.

میانگین ۲۰۰ میلی‌ثانیه دروغ نیست، اما تمام واقعیت را هم نشان نمی‌دهد. تعداد زیادی درخواست سریع می‌توانند اثر تعداد کمتری درخواست بسیار کند را در میانگین پنهان کنند. به همین دلیل تیم‌های حرفه‌ای فقط به Average نگاه نمی‌کنند.

خلاصه مهم‌ترین اصطلاحات مانیتورینگ

۱. Latency؛ کاربر چقدر منتظر پاسخ می‌ماند؟

Latency مدت‌زمان بین شروع یک عملیات و دریافت نتیجه آن است. زمان پاسخ API، مدت اجرای Query دیتابیس، زمان ارسال پیام به Queue و زمان بارگذاری صفحه همگی نمونه‌هایی از Latency هستند.

Latency را با Response Time یکسان در نظر می‌گیرند، هرچند در بعضی بحث‌های فنی Response Time می‌تواند علاوه‌بر زمان انتظار، زمان پردازش و انتقال کامل پاسخ را نیز شامل شود. مهم‌تر از نام، این است که دقیقاً مشخص کنید چه بازه‌ای را اندازه می‌گیرید.

برای یک Endpoint بهتر است Latency را براساس مسیر، متد، Status Code و گاهی منطقه کاربر بررسی کنید. یک عدد کلی برای کل Backend می‌تواند کندی فقط یک Endpoint حساس مثل پرداخت را پنهان کند.

چرا Average کافی نیست؟

فرض کنید ۹ درخواست در ۱۰۰ میلی‌ثانیه و یک درخواست در ۵ ثانیه پاسخ داده شود. میانگین حدود ۵۹۰ میلی‌ثانیه خواهد بود؛ عددی که نه تجربه کاربران سریع را درست نشان می‌دهد و نه تجربه کاربر کند را.

میانگین برای مشاهده روند کلی مفید است، اما برای سنجش تجربه کاربر باید در کنار Percentileها دیده شود.

۲. Percentile، p50، p95 و p99 به زبان ساده

Percentile یا صدک نشان می‌دهد چه درصدی از داده‌ها مساوی یا کمتر از یک مقدار مشخص هستند.

• p50: پنجاه درصد درخواست‌ها در این زمان یا سریع‌تر پاسخ گرفته‌اند. این عدد همان Median یا میانه است.
• p95: نودوپنج درصد درخواست‌ها در این زمان یا سریع‌تر تمام شده‌اند و پنج درصد کندتر بوده‌اند.
• p99: نودونه درصد درخواست‌ها در این زمان یا سریع‌تر تمام شده‌اند و یک درصد کندتر بوده‌اند.

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

چرا یک درصد در p99 مهم است؟

در یک سرویس با روزانه ۱۰۰ هزار درخواست، یک درصد برابر با هزار درخواست است. پس p99 نماینده یک مورد عجیب و نادر نیست؛ ممکن است هر روز هزار تجربه کند داشته باشید.

p95 معمولاً برای مشاهده تجربه بخش بزرگی از کاربران و تعریف هدف عملکرد مناسب است. p99 مشکلات Tail Latency مانند Pauseهای Runtime، Queryهای خاص، Lock، Retry یا کندی سرویس خارجی را بهتر نمایان می‌کند. انتخاب صدک باید متناسب با حجم ترافیک و حساسیت عملیات باشد؛ p99.9 برای یک سرویس کم‌ترافیک ممکن است بیشتر از آنکه مفید باشد، پرنوسان باشد.

اشتباه رایج در Percentile

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

۳. Throughput، RPS و TPS؛ سیستم چقدر کار انجام می‌دهد؟

Throughput حجم عملیات پردازش‌شده در یک بازه زمانی است. در APIها معمولاً از RPS یا Request Per Second استفاده می‌شود. در سیستم‌های مالی ممکن است TPS به معنای Transaction Per Second باشد.

Latency بدون Throughput تصویر کاملی نمی‌دهد. p95 برابر ۵۰۰ms در ۱۰ درخواست بر ثانیه با همین مقدار در ۵ هزار درخواست بر ثانیه شرایط یکسانی نیست. افزایش Latency هم‌زمان با افزایش RPS می‌تواند نشانه نزدیک‌شدن سیستم به ظرفیت باشد.

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

۴. Error Rate؛ چند درصد عملیات واقعاً ناموفق است؟

Error Rate نسبت عملیات ناموفق به کل عملیات است:

Error Rate = Failed Requests / Total Requests × 100

اگر از ۱۰ هزار درخواست، ۲۰۰ درخواست شکست بخورد، نرخ خطا ۲ درصد است. اما تعریف «ناموفق» باید دقیق باشد. فقط پاسخ‌های 5xx خطا نیستند؛ Timeout، پاسخ نامعتبر سرویس خارجی یا حتی پاسخ 200 که عملیات تجاری در آن شکست خورده نیز ممکن است از دید کاربر خطا باشد.

Technical Error در برابر Business Error

• Technical Error: خطای 500، قطع دیتابیس، Timeout یا Exception.
• Business Error: پرداخت ناموفق، ثبت‌نشدن سفارش یا ارسال‌نشدن کد ورود؛ حتی اگر API پاسخ 200 داده باشد.

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

۵. Availability و Uptime؛ آیا سرویس قابل‌استفاده است؟

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

ممکن است سرور روشن باشد و Health Check پاسخ 200 بدهد، اما همه درخواست‌های پرداخت Timeout شوند. در این حالت Uptime زیرساخت خوب است، ولی سرویس عملاً Available نیست.

هر 9 اضافه هزینه فنی و عملیاتی زیادی دارد. همه سرویس‌ها به 99.99% نیاز ندارند؛ هدف باید براساس اهمیت سرویس، انتظار کاربر و هزینه رسیدن به آن تعیین شود.

۶. چهار سیگنال طلایی: Latency، Traffic، Errors و Saturation

یکی از چارچوب‌های رایج برای مانیتورینگ سرویس‌ها، Four Golden Signals است:

• Latency: درخواست‌ها چقدر زمان می‌برند؟
• Traffic: چه مقدار تقاضا وارد سیستم می‌شود؟
• Errors: چه تعداد عملیات شکست می‌خورد؟
• Saturation: سیستم چقدر به ظرفیت خود نزدیک شده است؟

سه مورد اول را بررسی کردیم. Saturation فقط مصرف CPU نیست. پرشدن Worker Pool، Connection Pool، Queue، تعداد File Descriptorها، IOPS دیسک یا پهنای باند هم می‌تواند محدودیت ظرفیت ایجاد کند.

مثلاً CPU روی ۴۰ درصد است، اما همه Connectionهای دیتابیس اشغال شده‌اند؛ درخواست جدید باید منتظر بماند و p99 افزایش پیدا می‌کند. اگر فقط CPU را ببینید، علت اصلی را از دست می‌دهید.

۷. Utilization در برابر Saturation

Utilization نشان می‌دهد چه سهمی از یک منبع مشغول استفاده است. Saturation نشان می‌دهد کاری وجود دارد که به‌دلیل نبود ظرفیت باید منتظر بماند.

CPU Usage برابر ۹۰ درصد یک Utilization بالاست. اگر Taskها در Run Queue منتظر CPU باشند، سیستم Saturated شده است. این تفاوت کمک می‌کند بین «منبع زیاد استفاده می‌شود» و «منبع دیگر جواب‌گوی تقاضا نیست» تمایز بگذارید.

۸. Apdex؛ رضایت کاربر از سرعت سرویس در یک عدد

Apdex درخواست‌ها را براساس یک آستانه هدف با نام T به سه گروه تقسیم می‌کند:

• Satisfied: زمان پاسخ کمتر یا مساوی T
• Tolerating: زمان پاسخ بیشتر از T و حداکثر 4T
• Frustrated: زمان پاسخ بیشتر از 4T یا درخواست ناموفق

Apdex = (Satisfied + Tolerating / 2) / Total

امتیاز Apdex بین صفر و یک است؛ هرچه به یک نزدیک‌تر باشد، تجربه بهتر است. مزیت Apdex این است که وضعیت عملکرد را در یک عدد قابل‌مقایسه خلاصه می‌کند، اما انتخاب T باید متناسب با انتظار واقعی کاربر باشد. یک آستانه مشترک برای جست‌وجو، گزارش‌گیری سنگین و پرداخت منطقی نیست.

۹. SLI، SLO و SLA؛ سه اصطلاح شبیه با کاربرد متفاوت

SLI؛ چیزی که اندازه می‌گیریم

Service Level Indicator شاخص واقعی کیفیت سرویس است. درصد درخواست‌های موفق، درصد درخواست‌های سریع‌تر از ۵۰۰ms یا درصد پیام‌های پردازش‌شده در کمتر از یک دقیقه می‌توانند SLI باشند.

SLO؛ هدفی که داخل تیم تعیین می‌کنیم

Service Level Objective هدف مشخص برای SLI است. برای مثال:

در یک بازه ۳۰ روزه، ۹۹.۹ درصد درخواست‌های پرداخت باید موفق باشند و در کمتر از یک ثانیه پاسخ بگیرند.

SLO خوب باید از دید کاربر، قابل‌اندازه‌گیری و دارای بازه زمانی مشخص باشد. جمله «API باید سریع باشد» SLO نیست.

SLA؛ تعهد رسمی به مشتری

Service Level Agreement توافق رسمی با مشتری است و ممکن است در صورت نقض آن، اعتبار مالی یا پیامد قراردادی وجود داشته باشد. معمولاً SLA کمی ضعیف‌تر از SLO داخلی تعیین می‌شود تا تیم قبل از نقض تعهد مشتری فرصت واکنش داشته باشد.

۱۰. Error Budget؛ چه مقدار اختلال قابل‌قبول است؟

اگر SLO سرویس 99.9% باشد، 0.1% باقی‌مانده Error Budget است؛ یعنی میزان خطا یا اختلالی که در بازه تعیین‌شده بدون نقض SLO قابل‌تحمل است.

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

این مفهوم به معنی مجازبودن بی‌تفاوتی نسبت به خطا نیست. هدف آن تبدیل بحث مبهم «پایداری در برابر توسعه» به تصمیمی مبتنی بر داده است.

Burn Rate چیست؟

Error Budget Burn Rate سرعت مصرف بودجه خطا را نشان می‌دهد. Burn Rate برابر 1 یعنی بودجه دقیقاً با سرعتی مصرف می‌شود که تا پایان بازه دوام می‌آورد. Burn Rate برابر 10 یعنی در صورت ادامه شرایط، بودجه ده برابر سریع‌تر از حد مجاز تمام می‌شود.

Alert روی Burn Rate معمولاً بهتر از هشدار ثابت روی Error Rate است؛ چون هم شدت خطا و هم مدت اثر آن را در ارتباط با SLO می‌سنجد.

۱۱. MTTD، MTTA، MTTR و MTBF؛ سرعت واکنش به Incident

• MTTD – Mean Time to Detect: میانگین زمان بین شروع مشکل و تشخیص آن
• MTTA – Mean Time to Acknowledge: میانگین زمان تا زمانی که فرد مسئول هشدار را می‌بیند و مسئولیت آن را می‌پذیرد
• MTTR – Mean Time to Restore/Resolve: میانگین زمان لازم برای بازیابی سرویس یا رفع Incident
• MTBF – Mean Time Between Failures: میانگین زمان کارکرد بین دو خرابی

ممکن است تیم نتواند همه خطاها را حذف کند، اما می‌تواند زمان اثر آن‌ها را کاهش دهد. Alert دقیق MTTD را کم می‌کند؛ Runbook، مالکیت روشن سرویس، Rollback سریع و اطلاعات مرتبط در یک داشبورد MTTR را کاهش می‌دهند.

واژه «Mean» گاهی می‌تواند رخدادهای بسیار طولانی را پنهان کند. در گزارش‌های عملیاتی بهتر است علاوه‌بر میانگین، میانه، p90 و بزرگ‌ترین Incidentها نیز بررسی شوند.

۱۲. Threshold، Baseline و Anomaly؛ چه زمانی باید هشدار بدهیم؟

Threshold یک حد ثابت است؛ مثلاً اگر CPU بیشتر از ۹۰ درصد شد هشدار بده. ساده است، اما همیشه هوشمند نیست. CPU ممکن است چند ثانیه به‌طور طبیعی بالا برود یا یک سرویس با CPU پایین کاملاً از دسترس خارج شود.

Baseline رفتار عادی سیستم را براساس تاریخچه مشخص می‌کند. Anomaly انحراف معنادار از این رفتار عادی است. مثلاً افت ۷۰ درصدی سفارش‌ها ساعت ۳ صبح شاید طبیعی باشد، اما همان افت ساعت ۹ شب می‌تواند غیرعادی باشد.

بهترین Alertها معمولاً روی نشانه‌های اثرگذار بر کاربر تعریف می‌شوند: افزایش Error Rate، عبور p95 از هدف، کاهش خرید موفق یا مصرف سریع Error Budget. هشدار منابع زیرساخت نیز لازم است، اما باید به مشکلی قابل‌اقدام اشاره کند.

۱۳. Alert Fatigue؛ وقتی تعداد زیاد هشدار، تیم را بی‌حس می‌کند

اگر هر نوسان کوچک Notification ایجاد کند، تیم بعد از مدتی هشدارها را نادیده می‌گیرد. این وضعیت Alert Fatigue نام دارد و می‌تواند باعث شود Incident مهم میان ده‌ها هشدار بی‌ارزش گم شود.

یک Alert خوب باید:

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

همه رخدادها نباید تیم را از خواب بیدار کنند. هشدارهای بحرانی برای اقدام فوری، Warningها برای بررسی در ساعات کاری و گزارش‌ها برای روندهای غیرفوری مناسب‌اند.

۱۴. Cardinality؛ اصطلاحی که می‌تواند هزینه مانیتورینگ را چند برابر کند

Cardinality تعداد مقادیر منحصربه‌فرد یک فیلد یا Label است. Label با نام محیط و مقادیر production، staging و development دارای Cardinality پایین است. اما user_id با میلیون‌ها مقدار Cardinality بسیار بالا دارد.

در سیستم‌های Time Series، هر ترکیب منحصربه‌فرد Labelها می‌تواند یک Series جدید ایجاد کند:

http_requests_total{
  service="payment",
  method="POST",
  status="200",
  user_id="847291"
}

اضافه‌کردن user_id، request_id یا یک URL دارای شناسه پویا به Label متریک می‌تواند مصرف حافظه، Storage و هزینه را به‌شدت افزایش دهد. این داده‌ها معمولاً جای بهتری در Log یا Trace دارند.

Labelهای مناسب برای متریک معمولاً مجموعه‌ای محدود و قابل‌کنترل دارند: نام سرویس، محیط، Region، متد HTTP، گروه Status Code و Route نرمال‌شده.

۱۵. Sampling و Retention؛ چقدر داده جمع کنیم و نگه داریم؟

جمع‌آوری صد درصد Traceها در یک سیستم پرترافیک ممکن است پرهزینه باشد. Sampling یعنی فقط بخشی از داده‌ها ذخیره شوند.

• Head-based Sampling: در ابتدای درخواست تصمیم می‌گیریم Trace ذخیره شود یا نه؛ ساده و کم‌هزینه است، اما ممکن است Trace خطادار را از دست بدهد.
• Tail-based Sampling: بعد از مشاهده نتیجه درخواست تصمیم می‌گیریم؛ می‌توان Traceهای خطادار یا بسیار کند را نگه داشت، ولی زیرساخت پیچیده‌تری می‌خواهد.

Retention مدت نگهداری داده است. لازم نیست همه داده‌ها برای همیشه با جزئیات کامل نگهداری شوند. معمولاً متریک‌های تجمیع‌شده مدت بیشتری، Traceهای کامل مدت کمتر و لاگ‌های حساس براساس نیاز عملیاتی و الزامات قانونی نگهداری می‌شوند.

۱۶. RED و USE؛ دو روش سریع برای طراحی داشبورد

برای مانیتورینگ سرویس‌ها می‌توانید از روش RED استفاده کنید:

• Rate: نرخ درخواست‌ها
• Errors: نرخ خطاها
• Duration: مدت پاسخ، ترجیحاً با Percentileها

برای منابع زیرساخت، روش USE مناسب است:

• Utilization: میزان استفاده از منبع
• Saturation: میزان کار منتظر به‌دلیل کمبود ظرفیت
• Errors: خطاهای منبع

RED از دید درخواست و کاربر به سرویس نگاه می‌کند؛ USE از دید ظرفیت منبع. ترکیب این دو کمک می‌کند هم اثر مشکل را ببینید و هم علت زیرساختی احتمالی آن را پیدا کنید.

۱۷. Correlation ID؛ اتصال Metric، Log و Trace به یکدیگر

فرض کنید p99 بالا رفته است. متریک زمان و شدت مشکل را نشان می‌دهد، اما برای رسیدن به علت باید بتوانید از نمودار به Trace کند و سپس به Log همان درخواست بروید.

شناسه‌هایی مثل Trace ID و Request ID این ارتباط را ایجاد می‌کنند. اگر Trace ID در لاگ ساختاریافته ثبت شود، توسعه‌دهنده می‌تواند مسیر یک درخواست را ببیند و همان لحظه Exception یا Query مرتبط را پیدا کند.

بدون Correlation، تیم مجبور است بین چند ابزار و هزاران رکورد با زمان تقریبی جست‌وجو کند. هدف Observability فقط جمع‌آوری داده بیشتر نیست؛ اتصال داده‌ها برای رسیدن سریع‌تر از نشانه به علت است.

یک داشبورد کاربردی برای API باید چه چیزهایی داشته باشد؟

برای شروع لازم نیست صد نمودار بسازید. یک نمای عملیاتی خوب برای هر سرویس می‌تواند شامل موارد زیر باشد:

• RPS کل و تفکیک‌شده براساس Endpoint اصلی
• Error Rate فنی و نرخ شکست عملیات مهم کسب‌وکار
• Latency در p50، p95 و p99
• وضعیت SLO و Error Budget باقی‌مانده
• Dependencyهای کند یا خطادار مانند دیتابیس و API خارجی
• Saturation منابع محدودکننده مانند Connection Pool و Queue
• آخرین Deployها برای ارتباط تغییرات با مشکل
• دسترسی مستقیم از نمودار به Trace و Log مرتبط

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

نمونه Alertهای ضعیف و بهتر

اشتباهات رایج در مانیتورینگ محیط Production

• تمرکز فقط روی CPU و RAM: سلامت زیرساخت الزاماً به معنی سلامت تجربه کاربر نیست.
• اعتماد کامل به Average: میانگین می‌تواند تجربه کندترین کاربران را پنهان کند.
• Alert روی هر نوسان: هشدار زیاد، واکنش تیم به هشدار مهم را ضعیف می‌کند.
• استفاده از User ID در Label متریک: Cardinality و هزینه را افزایش می‌دهد.
• یک آستانه برای همه Endpointها: انتظار عملکرد از گزارش سنگین و پرداخت یکسان نیست.
• تعریف Success فقط براساس Status Code: خطاهای کسب‌وکار نادیده می‌مانند.
• جمع‌آوری داده بدون Correlation: Metric، Log و Trace جدا از هم ارزش عملی کمتری دارند.
• ساخت داشبورد بدون مالک: نمودارهایی که کسی براساس آن‌ها تصمیم نمی‌گیرد، فقط هزینه ایجاد می‌کنند.

از کجا شروع کنیم؟ یک برنامه عملی برای تیم‌ها

1. مسیرهای حیاتی کاربر را مشخص کنید: ورود، جست‌وجو، پرداخت یا هر عملیاتی که مستقیماً روی کسب‌وکار اثر دارد.
2. برای هر مسیر SLI تعریف کنید: موفقیت، Latency و در دسترس‌بودن را از دید کاربر بسنجید.
3. یک SLO واقع‌بینانه تعیین کنید: ابتدا وضعیت فعلی را اندازه بگیرید و هدفی دست‌یافتنی بسازید.
4. RED را برای سرویس‌ها و USE را برای منابع اجرا کنید: تعداد کمی سیگنال باکیفیت بهتر از صدها متریک بدون هدف است.
5. Log ساختاریافته و Trace ID اضافه کنید: عبور از Alert به علت مشکل باید سریع باشد.
6. Alertها را براساس اثر و قابلیت اقدام تنظیم کنید: هر هشدار باید مالک و قدم بعدی مشخص داشته باشد.
7. بعد از هر Incident بازبینی کنید: آیا زود تشخیص داده شد؟ کدام داده کم بود؟ چه Alert یا Runbookی باید اصلاح شود؟

این مفاهیم در Watchlog چگونه کنار هم قرار می‌گیرند؟

در Watchlog می‌توانید متریک‌های زیرساخت و سرویس، لاگ‌ها، APM و Distributed Trace، مانیتورینگ API، RUM، تست‌های Synthetic و Alertها را در یک پلتفرم مشاهده کنید. هدف این یکپارچگی این است که تیم از یک افزایش p95 به Trace کند، لاگ مرتبط و منبع زیرساختی احتمالی برسد؛ بدون اینکه برای هر مرحله بین چند سیستم جداگانه جست‌وجو کند.

برای شروع لازم نیست تمام اصطلاحات این مقاله را یک‌باره در سیستم پیاده کنید. سه سیگنال RED برای سرویس‌های حیاتی، p95 و p99، نرخ خطای واقعی و چند Alert قابل‌اقدام نقطه شروع بسیار خوبی هستند.

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

p95 بهتر است یا p99؟

هیچ‌کدام همیشه بهتر نیست. p95 برای نمایش تجربه بخش بزرگی از کاربران و p99 برای آشکارکردن Tail Latency مناسب است. در سرویس‌های مهم بهتر است هر دو را ببینید، اما Alert را براساس حجم ترافیک و هدف عملکرد تنظیم کنید.

آیا میانگین زمان پاسخ را کنار بگذاریم؟

خیر. Average برای مشاهده روند و بعضی محاسبات ظرفیت مفید است، اما نباید تنها معیار تجربه کاربر باشد. آن را در کنار p50، p95، p99 و حجم ترافیک بررسی کنید.

فرق SLO و SLA چیست؟

SLO هدف داخلی و قابل‌اندازه‌گیری تیم برای کیفیت سرویس است. SLA تعهد رسمی به مشتری است و ممکن است پیامد قراردادی داشته باشد. SLO معمولاً سخت‌گیرانه‌تر از SLA تعیین می‌شود.

برای یک پروژه کوچک هم Error Budget لازم است؟

لازم نیست از ابتدا فرایند پیچیده SRE بسازید، اما مفهوم Error Budget حتی برای تیم کوچک مفید است؛ چون مشخص می‌کند چه مقدار خطا قابل‌قبول است و چه زمانی باید به‌جای Feature جدید روی پایداری تمرکز کرد.

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

برای هر API از Rate، Error و Duration شروع کنید. سپس Saturation منابع کلیدی مانند دیتابیس، Queue و Worker Pool را اضافه کنید. متریک‌های کسب‌وکار مانند خرید موفق نیز باید کنار شاخص‌های فنی دیده شوند.

چرا p99 ناگهان نوسان می‌کند؟

در ترافیک پایین، تعداد نمونه‌های بخش انتهایی توزیع کم است و p99 می‌تواند ناپایدار باشد. همچنین GC Pause، Query کند، Lock، Retry و سرویس خارجی از علت‌های رایج افزایش Tail Latency هستند. همیشه p99 را همراه با تعداد درخواست و Traceهای کند بررسی کنید.

جمع‌بندی

مانیتورینگ حرفه‌ای یعنی تبدیل حجم زیادی از داده به چند پاسخ روشن: آیا کاربر مشکل دارد؟ شدت مشکل چقدر است؟ کدام بخش سیستم باعث آن شده و تیم چقدر سریع می‌تواند سرویس را بازیابی کند؟

Latency، Traffic، Error و Saturation وضعیت سرویس را نشان می‌دهند. p95 و p99 تجربه‌های کند را آشکار می‌کنند. SLI و SLO کیفیت را قابل‌اندازه‌گیری می‌کنند، Error Budget بین توسعه و پایداری تعادل می‌سازد و MTTD و MTTR کیفیت واکنش تیم را می‌سنجند.

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