ניטור פורטים

מעבר ל-HTTP: ניטור שאר הסטאק

רוב השירותים שמחזיקים את העסק אינם שרתי ווב. בסיסי נתונים מאזינים על 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). דואר עובר דרך 25, 465, 587, 993, 995. SSH על 22. שרתי משחקים על פורטים שנבחרו על ידי המפיץ. מיקרו-שירותים פנימיים מאחורי firewall – על כל פורט שהוגדר על ידי צוות הפלטפורמה. אף אחד מהם לא מדבר HTTP. אף אחד מהם לא יופיע בכלי למעקב זמן פעילות של אתרים. וכל אחד, כשמפסיק להאזין, לוקח איתו משהו נראה לעין.

ניטור פורטים סותם את החור הזה. אתה נותן למוניטור את שם ה-host והפורט, ובכל בדיקה נפתח חיבור TCP שמוודא אם השירות מאזין. אם החיבור נכשל – כי הדמון נפל, ה-firewall השתנה, ה-host למטה, הרשת בינינו לבין השירות לא תקינה – תקבל התראה.

מה אפשר לנטר

• בסיסי נתונים: 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 עם timeout של 5 שניות. אם חוזר SYN/ACK – הפורט נגיש והשירות מאזין, הצ'ק עובר. אם מתקבל connection refused, timeout או no route – הצ'ק נכשל, ונשמרת שגיאה מהליבה ("connection refused", "operation timed out", "no route to host") – מה שמקל על אבחון התקלה.

המערכת לא מנסה לשוחח בפרוטוקול אפליקטיבי – לא שולחת שאילתת SQL ולא SMTP HELO. זה הופך את הבדיקה למהירה וללא תופעות לוואי, וזה קריטי כשבודקים 100 שירותים בדקה. אם דרושה לך בדיקה אפליקטיבית, שילב ניטור פורט עם heartbeat או מערכת API משלך.

שילוב עם HTTP ו-ping

לכל שירות ציבורי שלושה מוניטורים נותנים לך סולם דיאגנוסטי ברור. Ping מאשר שה-host זמין ברשת. ניטור הפורט – השירות מאזין. ניטור HTTP / API – השירות גם מגיב כראוי. כשיש בעיה, השכבה הנופלת מייד מצביעה לאן להסתכל. רק HTTP נופל – האפליקציה קורסת. גם הפורט נופל – הדמון נפל. גם ה-ping לא גובה – המארז נעלם או הרשת קרסה.

הגדרה

פתח את הכלי, לחץ על "הוסף מוניטור", בחר בסוג "TCP port", הדבק את שם ה-host (ללא פרוטוקול), הזן את מספר הפורט (1-65535) וקבע את האינטרוול. שמור. מהמחזור הבא המוניטור פותח חיבור TCP מדי דקה, מודד round-trip, ושולח התראה בשניה שהפורט נסגר – באימייל, Telegram, Slack, Discord או SMS, עם אותם כללי סף אישור ושעות שקט לילה.

שאלות נפוצות

• אילו פורטים אפשר לנטר?

  כל פורט TCP בין 1 ל-65535. דוגמאות נפוצות: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), מאזיני בסיסי נתונים (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), פורטים מותאמים לאפליקציות.

• האם המוניטור בודק אם השירות בריא או רק זמין?

  רק זמינות — המוניטור פותח חיבור TCP ובודק אם הדמון מקבל אותו. בלי handshake בפרוטוקול עצמו. אם אתה צריך בדיקות מבוססות פרוטוקול (למשל בדיקת באנר SMTP, תגובת בסיס נתונים), השתמש בבדיקת HTTP (לשירותי HTTP) או סוכן heartbeat בהתקנה עצמית.

• מה ה-timeout לבדיקות פורטים?

  ברירת מחדל היא 10 שניות. ניתן לקביעת המוניטור. אם חיבור TCP לא נוצר בזמן החלון, הבדיקה נכשלת עם "connection timeout". חיבורים מרוחקים (למשל בדיקה מיבשת אירופה לשרת באסיה) עשויים לדרוש timeout ארוך יותר.

• האם אפשר לנטר פורטים של UDP?

  לא כרגע. UDP הוא ללא חיבור — אין "connection accepted" שאפשר לבדוק. שירותי UDP דורשים בדיקות (probe) מותאמות לפרוטוקול (למשל שאילתת DNS על פורט 53, SNMP get על 161). השתמש בניטור heartbeat במקום זאת.

• האם ניטור פורט סופר גם לשגיאות TLS/SSL?

  לא — בדיקות פורט הן לבדיקת זמינות TCP בלבד. אם אתה רוצה ולידציה של תעודת TLS על פורט, השתמש בבדיקת HTTPS עם הפורט ב-URL (למשל https://api.example.com:8443/) שמבצעת גם זמינות וגם בדיקת תעודה.