پیامک، تلگرام یا بله؟ انتخاب کانال هشدار بدون خستگی از هشدار
کدوم هشدارهای قطعی با پیامک برن و کدوم با تلگرام یا بله، چطور بر اساس فوریت مسیریابی کنیم و چطور هشدارهای مهم زیر هشدارهای بیمورد گم نشن.
پینگ قدیمیترین و سادهترین چک سلامت اینترنته: یه بستهی کوچیک بفرست و منتظر پژواکش بمون. به یه سؤال خیلی خوب جواب میده («این میزبان در دسترسه؟») و هیچی دربارهی اینکه سرویسهای روش کار میکنن نمیگه. شناختن هر دو نیمهی این جمله، کلید استفادهی درست از مانیتورینگ پینگه.
noc724 سایت، سرور و APIهای شما رو شبانهروز چک میکنه و همون لحظهای که چیزی خراب شد با پیامک، تلگرام یا بله خبرتون میکنه.
ping یه درخواست echo از نوع ICMP به یه آدرس IP میفرسته. اگه میزبان در دسترس باشه و اجازهی جواب داشته باشه، یه پاسخ echo برمیگردونه. ابزار زمان رفتوبرگشت هر بسته و در آخر تعداد بستههای گمشده رو گزارش میده:
ping -c 4 203.0.113.10
64 bytes from 203.0.113.10: icmp_seq=1 ttl=56 time=18.4 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=56 time=18.9 ms
64 bytes from 203.0.113.10: icmp_seq=3 ttl=56 time=17.8 ms
64 bytes from 203.0.113.10: icmp_seq=4 ttl=56 time=19.2 ms
4 packets transmitted, 4 received, 0% packet lossمانیتور پینگ همین کار رو طبق زمانبندی و از بیرون شبکهی شما انجام میده و وقتی جوابها قطع بشن هشدار میده.
زمانی که یه بسته تا میزبان میره و برمیگرده. مقدارش به فاصله بستگی داره: چند میلیثانیه داخل یه شهر، چند ده میلیثانیه داخل یه کشور و بیشتر بین قارهها. چیزی که برای مانیتورینگ مهمه روند است؛ میزبانی که همیشه در ۲۰ میلیثانیه جواب میده و یهو ۲۰۰ میلیثانیه طول میکشه، داره چیزی بهتون میگه.
درصد درخواستهایی که جوابی نگرفتن. افتهای تکی و گاهبهگاه روی اینترنت عادیه. افت پایدار چند درصدی اتصالهای TCP رو کند میکنه (چون دوباره ارسال میکنن) و افت شدید باعث شکستشون میشه.
نوسان بین زمانهای رفتوبرگشت پشتسرهم. Jitter بالا برای صفحهی وب تقریباً مهم نیست، ولی تماس صوتی و تصویری رو خراب میکنه.
قبل از هشدار دادن برای یه میزبان ساکت، این مظنونهای همیشگی رو کنار بذارید:
اگه ICMP عمداً بسته شده، بهجاش از چک پورت روی پورتی که بازه استفاده کنید.
یه سرور میتونه کاملاً پینگ بشه در حالی که:
500 برمیگردونه،پینگ توی لایهی شبکهی سیستمعامل زندگی میکنه، پس تا وقتی کرنل اجرا میشه جواب میده. برای همین سیگنال خوبی برای در دسترس بودن و سیگنال ضعیفی برای سالم بودن سرویس است. چکها رو لایهلایه بچینید:
| لایه | چک | چی رو پیدا میکنه |
|---|---|---|
| شبکه | پینگ | میزبان یا مسیر در دسترس نیست |
| انتقال | پورت (TCP/UDP) | سرویس گوش نمیده |
| برنامه | HTTP / کلمهی کلیدی / API | سرویس خرابه یا خطا برمیگردونه |
وقتی همهچیز با هم شکست میخوره، پایینترین لایهای که خرابه معمولاً به علت اشاره میکنه.
به فاصله بستگی داره. زیر ۳۰ میلیثانیه داخل یه کشور معمولیه و ۱۰۰ تا ۲۰۰ میلیثانیه بین قارهها. هر میزبان رو با سابقهی خودش مقایسه کنید، نه با یه عدد جهانی.
جهشهای کوتاه عادیه. افتی که چند دقیقه بالای ۱ تا ۲ درصد بمونه معمولاً یعنی شلوغی یا لینک معیوب و ارزش بررسی داره.
نه. پینگ فقط ثابت میکنه میزبان در دسترسه. برای اینکه بدونید سایت واقعاً کار میکنه از چک HTTP یا کلمهی کلیدی استفاده کنید.
نویسنده
تیم noc724
تیم فنی مانیتورینگ آپتایم
ما noc724 رو میسازیم و اداره میکنیم؛ سرویس مانیتورینگ آپتایمی که سایت، سرور و API رو از چند شهر ایران چک میکنه. این راهنماها از مشکلهایی میان که خودمون و کاربرهامون موقع آنلاین نگه داشتن سرویسها باهاشون روبهرو میشیم.
تماس با تیمتخصص:مانیتورینگ
کدوم هشدارهای قطعی با پیامک برن و کدوم با تلگرام یا بله، چطور بر اساس فوریت مسیریابی کنیم و چطور هشدارهای مهم زیر هشدارهای بیمورد گم نشن.
چرا مانیتورهای آپتایم هشدار اشتباه میدن (اختلال شبکه، timeout، محدودیت نرخ، تغییر محتوا) و تنظیماتی که اینها رو حذف میکنه و هشدار واقعی رو سریع نگه میداره.
چطور یه چرخهی آنکال ساده و سیاست ارجاع هشدار بچینیم که هر هشدار حیاتی جواب داده بشه، بدون اینکه یه تیم کوچیک فرسوده بشه.