پایش پورت

فراتر از HTTP: پایش باقی استک

بیشتر سرویس‌هایی که کسب‌وکار را سرپا نگه می‌دارند، وب سرور نیستند. دیتابیس‌ها بر روی 5432 (Postgres)، 3306 (MySQL)، 27017 (MongoDB)، 6379 (Redis) گوش می‌دهند. ایمیل بر روی 25، 465، 587، 993، 995 منتقل می‌شود. SSH روی 22 است. سرورهای بازی روی پورت‌هایی که ناشر انتخاب کرده اجرا می‌شوند. میکروسرویس‌های داخلی پشت فایروال‌ها - روی هر چیزی که تیم پلتفرم پیکربندی کرده. هیچ‌کدام‌شان با HTTP صحبت نمی‌کنند. هیچ‌کدام را در ابزار آپتایم سایت‌ها نمی‌بینی. و هرکدام، وقتی از گوش دادن بازمی‌ایستد، بخشی از چیزی قابل مشاهده را با خودش می‌برد.

پایش پورت این شکاف را پر می‌کند. میزبان و پورت را به پایش‌گر می‌دهی و در هر چک، یک اتصال TCP باز می‌شود تا بررسی کند سرویس گوش می‌دهد یا نه. اگر اتصال شکست بخورد - چون دیمون از کار افتاده، فایروال تغییر کرده، میزبان خاموش است، یا شبکه بین ما و سرویس قطع شده - هشدار دریافت می‌کنی.

چه چیزهایی را می‌توانی پایش کنی

• دیتابیس‌ها: 5432 (Postgres)، 3306 (MySQL/MariaDB)، 1433 (SQL Server)، 27017 (MongoDB)، 6379 (Redis)، 9042 (Cassandra)، 11211 (Memcached).
• سرورهای ایمیل: 25 (SMTP)، 465 (SMTPS)، 587 (submission)، 110 (POP3)، 143 (IMAP)، 993 (IMAPS)، 995 (POP3S).
• دسترسی از راه دور: 22 (SSH)، 3389 (RDP)، 5900 (VNC).
• انتقال فایل: 21 (FTP)، 990 (FTPS)، 445 (SMB)، 2049 (NFS).
• سفارشی یا داخلی: گیت‌وی‌های GraphQL، gRPC، کیوها (RabbitMQ 5672، Kafka 9092)، جستجو (Elasticsearch 9200، Solr 8983)، سرورهای بازی، دستگاه‌های IoT.

چگونگی عملکرد بررسی

پایش‌گر یک اتصال خام TCP به host:port با تایم‌اوت ۵ ثانیه باز می‌کند. اگر SYN/ACK برگردد - پورت دسترس‌پذیر است و سرویس گوش می‌دهد، چک موفق است. اگر connection refused، timeout یا no route باشد - چک ناموفق است و در نتیجه ارور هسته ("connection refused"، "operation timed out"، "no route to host") ثبت می‌شود که عیب‌یابی را ساده‌تر می‌کند.

پایش‌گر تلاش نمی‌کند با پروتکل برنامه صحبت کند - نه درخواست SQL می‌فرستد و نه SMTP HELO. این باعث می‌شود بررسی سریع و بدون عوارض جانبی باشد؛ نکته‌ای که وقتی ۱۰۰ سرویس را در هر دقیقه پایش می‌کنی اهمیت دارد. اگر نیاز به اعتبارسنجی سطح برنامه داری، پایش پورت را با heartbeat یا پایش‌گر API مخصوص خود ترکیب کن.

ترکیب با HTTP و پینگ

برای هر سرویس عمومی، سه پایش‌گر یک نردبان تشخیصی واضح می‌سازند. پینگ تأیید می‌کند که میزبان در شبکه زنده است. پایش پورت - سرویس گوش می‌دهد. پایش HTTP / API - سرویس به‌درستی پاسخ می‌دهد. اگر مشکلی پیش بیاید، لایه‌ای که سقوط می‌کند، مستقیماً نشان می‌دهد که مشکل کجا است. فقط HTTP از کار می‌افتد - برنامه کرش کرده. پورت هم از کار می‌افتد - دیمون خاموش شده. پینگ هم قطع می‌شود - دستگاه ناپدید شده یا شبکه قطع است.

پیکربندی

ابزار را باز کن، روی «اضافه کردن پایش‌گر» کلیک کن، نوع «پورت TCP» را انتخاب کن، میزبان را بدون پروتکل وارد کن، شماره پورت (۱-۶۵۵۳۵) را بنویس و بازه زمانی را تنظیم کن. ذخیره کن. از سیکل بعدی، پایش‌گر هر دقیقه یک اتصال TCP باز می‌کند، زمان رفت‌وبرگشت را ثبت می‌کند و در لحظه بسته شدن پورت هشدار می‌دهد - از طریق ایمیل، تلگرام، اسلک، دیسکورد یا SMS، با همان قواعد آستانه تایید و حالت سکوت شبانه.

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

• چه پورت‌هایی را می‌توانم پایش کنم؟

  هر پورت TCP از ۱ تا ۶۵۵۳۵. موارد رایج: SMTP (۲۵/۵۸۷/۴۶۵)، POP3 (۱۱۰/۹۹۵)، IMAP (۱۴۳/۹۹۳)، پایش‌گر دیتابیس‌ها (PostgreSQL ۵۴۳۲، MySQL ۳۳۰۶، Redis ۶۳۷۹، MongoDB ۲۷۰۱۷)، SSH (۲۲)، FTP (۲۱)، پورت‌های سفارشی برنامه‌ها.

• آیا پایش‌گر بررسی می‌کند که سرویس سالم است یا فقط در دسترس است؟

  فقط دسترس‌پذیری — پایش‌گر یک اتصال TCP باز می‌کند و چک می‌کند که دیمون آن را قبول می‌کند یا نه. بدون هندشیک در سطح پروتکل. اگر چک‌های آگاه از پروتکل لازم داری (مثلاً بررسی بنر SMTP، پاسخ دیتابیس)، از چک HTTP (برای سرویس‌های HTTP) یا عامل heartbeat خوداستضافه استفاده کن.

• تایم‌اوت چک پورت چقدر است؟

  به طور پیش‌فرض ۱۰ ثانیه است. به ازای هر پایش‌گر قابل تنظیم است. اگر اتصال TCP در بازه تایم‌اوت برقرار نشود، چک با ارور "connection timeout" شکست می‌خورد. برای ارتباطات دور (مثلاً بررسی سرور در آسیا از اروپا)، ممکن است تایم‌اوت بیشتری نیاز باشد.

• آیا می‌توانم پورت‌های UDP را پایش کنم؟

  در حال حاضر خیر. UDP بدون اتصال است - معادل "connection accepted" برای چک کردن وجود ندارد. سرویس‌های مبتنی بر UDP معمولاً به پروب‌های خاص پروتکل نیاز دارند (مثلاً کوئری DNS برای پورت ۵۳، SNMP get برای ۱۶۱). از پایش heartbeat بجای آن استفاده کن.

• آیا پایش پورت، هشدارهای TLS/SSL را هم پوشش می‌دهد؟

  خیر - چک‌های پورت فقط دسترس‌پذیری TCP را بررسی می‌کنند. اگر اعتبارسنجی گواهینامه TLS روی پورت را می‌خواهی، از چک HTTPS با پورت در URL (مثلاً https://api.example.com:8443/) استفاده کن که هم دسترس‌پذیری و هم صحت گواهینامه را بررسی می‌کند.