مشکل از اپلیکیشن استیا از لایهٔ زیرش؟
سه نوع مانیتور که عمداً از منطق اپلیکیشن جدا شدهاند: پینگ برای دسترسی و کیفیت مسیر، TCP برای باز بودن پورت، و DNS برای پاسخ درست رکورد. وقتی سایت بالا نمیآید، همین سه تا میگویند از کجا شروع کنید.
پلن رایگان: ۳ مانیتور و یک نقطهٔ سنجش · ۱۴ روز بستهٔ حرفهای رایگان
سه نوع مانیتور، سه سؤال متفاوت
پینگ
میزبان اصلاً جواب میدهد؟ میانگین رفتوبرگشت چقدر است و کیفیت مسیر چطور است.
پورت TCP
سرویسی که روی آن پورت گوش میدهد بالا هست و اتصال در زمان معقول برقرار میشود؟
رکورد DNS
نام دامنه همان مقداری را برمیگرداند که انتظار دارید و پاسخ در چه زمانی میرسد.
شرطهای اختصاصی پینگ
دسترسی داشتن کافی نیست؛ کیفیت مسیر هم قابل سنجش است.
درصد بستههای ازدسترفته
آستانهای بگذارید که بالاتر از آن خطا حساب شود. خالیگذاشتن یعنی غیرفعال، و صفر یعنی هر اتلافی خطاست.
jitter
پراکندگی زمان پاسخ بستهها؛ برای سرویسهای حساس به تأخیر مثل صوت و ویدئو.
بیشترین زمان رفتوبرگشت
جدا از میانگین، بدترین بستهٔ همان بررسی هم میتواند شرط داشته باشد.
میانگین رفتوبرگشت
سقف کلی برای زمان پاسخ، مثل بقیهٔ نوعهای مانیتور.
نقاط سنجش و resolver
دید داخل و خارج
همان میزبان از نقاط سنجش مختلف بررسی میشود؛ تفاوت نتیجه یعنی مشکل مسیر است نه سرویس.
resolver دلخواه
میتوانید DNS server مشخصی را برای بررسی تعیین کنید تا رفتار یک resolver خاص را بسنجید.
دلیل خطای دقیق
پیدا نشدن دامنه، نرسیدن پاسخ DNS، رد شدن اتصال یا نرسیدن بستهها هرکدام دلیل جداگانهٔ خودشان را دارند.
مرزهای این قابلیت
ICMP همیشه اجازه ندارد
بعضی شبکهها پینگ را میبندند؛ در آن حالت نتیجهٔ پینگ دربارهٔ سلامت سرویس چیزی ثابت نمیکند و بهتر است سراغ TCP بروید.
بدون اجرای فرمان دلخواه
مانیتور فقط همین بررسیهای تعریفشده را انجام میدهد؛ برای بررسی عمیقتر مسیر، ابزار عیبیابی جداگانه هست.
از بیرون میبینیم
اینها وضعیت را از دید شبکهٔ بیرون گزارش میکنند، نه بار پردازنده یا حافظهٔ خود سرور.
قابلیتهای مرتبط
لایهٔ شبکه را جدا ببینید
برای همان سرویس، کنار مانیتور HTTP یک مانیتور پینگ یا TCP بسازید تا موقع اختلال بدانید کدام لایه خراب است.
ساخت حساب رایگان