پایش زمان پاسخ
کند بودن معادل از کار افتادن است. صفحهای که ۸ ثانیه برای بارگذاری زمان میبرد، همانقدر کاربران خود را از دست میدهد که صفحهای که کلاً بارگذاری نمیشود – و تقریباً همیشه افت عملکرد قبل از قطعی رخ میدهد.
هشدارهای زمان پاسخ را فعال کنید →
چرا زمان پاسخگویی شایسته هشدار اختصاصی است
هشدارهای استاندارد آپتایم بر اساس یک سیگنال دودویی عمل میکنند: یا سایت بالا است یا پایین. منطقه خاکستری بین این دو—بالا اما کند—جایی است که بیشتر اختلالات مدرن واقعاً در آن رخ میدهد. یک کوئری پیکربندی شده نادرست به پایگاه داده به جای ۵۰ میلیثانیه، ۴ ثانیه طول میکشد. نشتی حافظه باعث جهشهای جمعآوری زباله میشود. یک API خارجی که بکاند به آن درخواست میفرستد شروع به کندی میکند. هیچکدام از این مسائل سایت را کاملاً از کار نمیاندازند، اما آن را غیرقابل استفاده میکنند—و اینها نشانههای اولیه از یک خرابی بزرگتر هستند که ممکن است یک یا دو ساعت دیگر رخ دهد.
مانیتورینگ زمان پاسخگویی کاهش سرعت را قبل از آنکه به یک اختلال جدی تبدیل شود، شناسایی میکند. شما یک آستانه برای هر مانیتور تعیین میکنید و زمانی که زمان پاسخگویی در چند بررسی متوالی از آن عبور کند، هشدار دریافت میکنید. قبل از اینکه هشدار ارسال شود، هنوز فرصت کافی دارید تا موضوع را بررسی کنید، منابع را افزایش دهید، فراخوانی مشکلساز را محدود کنید یا دیپلوی جدید که باعث مشکل شده را بازگردانید.
آستانهها در DiagnoSEO Uptime Monitoring چگونه کار میکنند
هر مانیتور را میتوانید با دو پارامتر پیکربندی کنید: rt_threshold_ms و rt_threshold_breaches. اولی زمان پاسخ در میلیثانیه است که شما آن را قابل قبول میدانید. دومی تعداد بررسیهای متوالی است که باید از آستانه عبور کنند تا هشدار ارسال شود. به طور پیشفرض، آستانه غیرفعال است و تعداد عبورهای لازم سه عدد است.
طراحی دوپارامتری از هشدارهای مثبت کاذب جلوگیری میکند. نوسان شبکه رخ میدهد. توقفهای جمعآوری زباله طبیعی هستند. یک جهش تکی به ۱ ثانیه وقتی میانگین ۲۰۰ میلیثانیه است، دلیلی برای هشدار ساعت ۳ صبح نیست. اما سه پاسخ متوالی ۱ ثانیهای قابل توجهاند—این یک کندی پایدار است، نه یک لحظه گذرا. آستانه را بر اساس رفتار عادی که مشاهده میکنید و حاشیه امن مناسب تنظیم کنید: اگر p95 معمولاً ۴۰۰ میلیثانیه است، آستانه ۱۰۰۰ میلیثانیه منطقی است. اگر p95، ۵۰ میلیثانیه (API داخلی) است، آستانه ۲۰۰ میلیثانیه مناسب است.
چطور به ابزارهای دیگر متصل میشود
هشدارهای زمان پاسخگویی بهترین عملکرد را وقتی دارند که با سایر سیگنالهای مانیتور ترکیب شوند. تصویر کامل: آستانه زمان پاسخگویی نشان میدهد که سیستم در حال کاهش کیفیت است؛ کد HTTP میگوید چه زمانی واقعاً شکسته شده؛ هشدارهای SSL/دامنه، در مورد اختلالات مرتبط با زمان؛ هشدار تغییرات DNS، در مورد تغییرات پیکربندی. این چهار سیگنال با هم در یک مانیتور اطلاعاتی کامل فراتر از فقط "سایت بالا است یا نه" میدهند.
داشبورد نیز در این زمینه کمک میکند. هر مانیتور نمودار اسپارکلاین زمانهای پاسخ اخیر را نمایش میدهد—یک شاخص بصری سریع از الگوهای کاهش کیفیت. نمای گستردهتر میانگین زمانهای ۲۴ساعته، ۷روزه و ۳۰روزه را نشان میدهد. اگر میانگین به آرامی هفته به هفته افزایش مییابد—این یک هشدار اولیه برای بررسی پیش از عبور از آستانه است.
آستانههای منطقی بر اساس نوع صفحه
- صفحات لندینگ مارکتینگ: ۱۵۰۰ میلیثانیه منطقی است. این صفحات تصاویر و اسکریپتهای ردیابی زیادی دارند؛ پایداری اهمیت بیشتری از سرعت مطلق دارد.
- صفحات محصول/دستهبندی فروشگاه آنلاین: ۸۰۰-۱۲۰۰ میلیثانیه. سایت کند فروش آنلاین را کاهش میدهد؛ آستانههای تنگتر مشکلات را زودتر شناسایی میکنند.
- داشبوردهای اپلیکیشنی: ۵۰۰-۸۰۰ میلیثانیه. کاربران انتظار پاسخ سریع دارند. داشبورد کند، محصول را خراب جلوه میدهد.
- APIهای عمومی: ۲۰۰-۴۰۰ میلیثانیه برای اندپوینتهای ساده، بیشتر برای پردازشهای سنگین. آنها را برپایه میزان نیاز دستهبندی کنید.
- چکهِلث میکروسرویسهای داخلی: ۵۰-۱۰۰ میلیثانیه. باید تقریباً آنی باشد؛ کندی تقریباً همیشه نشانه مشکل واقعی است.
هرچه انتخاب میکنید، یکبار تعیین نکنید و برای همیشه فراموش نکنید. هر سه ماه و بر اساس روندهای واقعی مشاهدهشده بازبینی کنید. اگر مدام هشدار عبور از آستانه میگیرید که مشکل واقعی نیستند—آستانه بیش از حد سخت است. اگر اختلال بدون هشدار قبلی رخ داد—آستانه خیلی گشاد بوده است.
مسیر ارسال هشدارها
هشدارهای عبور از آستانه از همان مسیرهایی ارسال میشوند که هشدارهای خاموشی/بازیابی: ایمیل، تلگرام، اسلک، دیسکورد، پیامک. همه آنها سکوت شبانه مشابهی را رعایت میکنند. همه در همان جدول هشدارها ثبت میشوند. تنها تفاوت نوع رویداد ("threshold" به جای "down") و متن پیام است—پیام زمان پاسخ فعلی و آستانه تنظیمشده را میگوید، پس فوراً میزان عبور را متوجه میشوید.
پیکربندی
هر مانیتور را ویرایش کنید. در فرم "آستانه زمان پاسخ (ms)" را روی عدد دلخواه تنظیم کنید. در صورت لزوم، فیلد "تعداد عبورهای متوالی" را هم تغییر دهید اگر مقدار پیشفرض ۳ برای شما مناسب نیست. ذخیره کنید. از چرخه بعدی، هر بررسی زمان پاسخ را با آستانه مقایسه میکند و پس از تعداد تعیینشده عبور متوالی، هشدار دریافت خواهید کرد.
پرسشهای پرتکرار
-
Time To First Byte (TTFB) — میلیثانیه بین ارسال درخواست تا دریافت اولین بایت پاسخ. بهعلاوه کل زمان دریافت کامل پاسخ. TTFB مفیدترین متریک منفرد برای سلامت سرور است.
-
بستگی به موقعیت و محتوای سایت دارد. برای سایت استاتیک با CDN: زیر ۱۰۰ میلیثانیه عالی است، زیر ۳۰۰ میلیثانیه خوب است. برای اپلیکیشن پویا: زیر ۵۰۰ میلیثانیه خوب است، زیر ۱۰۰۰ میلیثانیه قابل قبول و بالاتر از ۲۰۰۰ میلیثانیه کند به نظر میرسد. به جای اعداد مطلق با دادههای تاریخی خود مقایسه کنید.
-
بله. هر مانیتور آستانه زمان پاسخ اختیاری دارد. اگر ۳ بررسی متوالی از آستانه عبور کردند، هشدار "slow response" دریافت میکنید. الزام به ۳ بررسی از هشدارهای کاذب ناشی از افت موقتی شبکه جلوگیری میکند.
-
از ۱۳ نقطه چک جغرافیایی ما (اروپا، آمریکای شمالی، آسیا، آمریکای جنوبی، اقیانوسیه). برای مانیتور تکمنطقهای، زمانها از نزدیکترین منطقه محسوب میشود. برای چندمنطقهای، هر منطقه جداگانه اندازهگیری میشود—مناسب برای یافتن مشکلات منطقهای CDN.
-
بله—میانگین متحرک ۳۰ روزه، حداقل/حداکثر روزانه و پرسنایلها (p50, p95). برای برنامهریزی ظرفیت مناسب است: اگر p95 از ۸۰۰ms به ۱۵۰۰ms طی یک ماه افزایش یابد، سرورهای شما تحت فشار هستند حتی اگر آپتایم % روی ۱۰۰% باقی بماند.
UptimeRobot · Pingdom · BetterStack · Oh Dear · Site24x7 · StatusCake · Sentry · Uptrends · Cronitor · New Relic
پایش SSL · انقضای دامنه · پایش DNS · پینگ (ICMP) · پورت (TCP) · endpoint · کلمه کلیدی · API · کرون / ضربانسنجی · بکلینک · وابسته به مکان · پایش وبسایت