ניטור פינג

למה צריך פינג אם כבר אני מנטר HTTP

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

ניטור פינג הוא גם הכלי הנכון עבור שרתים שלא מריצים HTTP: שרתי מסדי נתונים, שרתי דואר, שרתי אפליקציות אחרי load balancer, שערי VPN, שירותים פנימיים – בכל מקום שבו אתה רק צריך לדעת אם "הקופסה חיה ונגישה".

מדוע פינג מבוסס TCP

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

DiagnoSEO Uptime Monitoring משתמש בפינג מבוסס TCP: הבדיקה פותחת חיבור TCP בפורט מוכר (קודם 80, ואם צריך 443) עם timeout של 5 שניות. אם חוזר SYN/ACK – השרת נגיש. אם לא – תקבל שגיאה אמיתית עם קוד שגיאה מהקרנל (connection refused, timeout, no route to host), מה שמאיץ את התהליך של גילוי התקלה.

מה נשמר

כל פינג שומר את התוצאה (up / down) ואת זמן RTT במילישניות. זה עובר לאותו פייפליין היסטורי כמו מוניטורי HTTP – תקבל sparkline של הבדיקות האחרונות, אחוזי זמינות 24h ו-30d ומפת חום של זמינות מה-30 ימים האחרונים. אם השרת נופל, נפתח אירוע ונשלחות הודעות לערוצים מופעלים.

טיפים למוניטורי פינג

• בחר אינטרוול קצר: פינג זול, כדאי להגדיר 1-5 דקות אם התכנית מאפשרת. זיהוי מהיר בעלות נמוכה.
• שלב עם ניטור פורטים: אם יש לך מסד ב-5432 או מייל ב-25, הוסף גם ניטור פורט. פינג אומר "הקופסה חיה", פורט אומר "השירות מאזין".
• שים לב ל-RTT: זמן התגובה נרשם בכל בדיקה. קפיצות פתאומיות ב-RTT לעיתים מקדימות תקלות שלמות – הגדר סף וזיהוי מוקדם לפני שהופך לאירוע.
• נצל את סף האישוש: רשתות קופצות. 2 בדיקות שגויות כבררת מחדל מגינות מפני false positive.

איך זה משתלב בדשבורד

מוניטורי פינג מופיעים לצד מוניטורי HTTP, פורט, מילות מפתח, API ו-heartbeat באותה רשימה. אפשר לתייג אותם ("תשתית", "פנימי"), לסנן לפי סטטוס, למיין לפי RTT ולהשהות/להמשיך כמו כל מוניטור אחר. התראות הולכות באותם ערוצים (Email, Telegram, Slack, Discord, SMS) עם אותן כללי "שקט בלילה" וסף אישוש.

הגדרה

פתח את הכלי, לחץ על "הוסף מוניטור", בחר בסוג "פינג (TCP)", הדבק את ה-host (למשל db.internal.firma.com), הגדר את האינטרוול ושמור. מהמחזור הבא, המוניטור יפתח חיבור TCP כל דקה, ישמור את ה-RTT ויתריע כשאין תגובה מהשרת.

שאלות נפוצות

• למה משמש ניטור פינג?

  בודק זמינות ברשת (Layer 3) – האם השרת מגיב ל-ICMP echo. שימושי לראוטרים, מתגים, מכשירי IoT, תשתית פנימית וכל מה שלא עובד ב-HTTP אבל צריך להיות נגיש.

• למה השרת שלי ב-AWS/ענן לא עובר בדיקות פינג?

  רוב ספקי הענן חוסמים כברירת מחדל את ICMP ב-security group או פיירוול. השרת בפני עצמו תקין, אבל לא עונה לפינג. עבור עומסים בענן, העדף בדיקות HTTP או פורטים של TCP. תוכל לאפשר ICMP ב-security groups במפורש אם באמת צריך פינג.

• מה ההבדל בין פינג לבדיקה של פורט TCP?

  פינג משתמש ב-ICMP (בלי פורט – זמינות רמת רשת Layer 3). פורט TCP פותח חיבור TCP בפורט מסוים – מאשר קישוריות ברמת Layer 4. שרת יכול לעבור פינג אבל להיכשל ב-TCP (פיירוול חוסם את הפורט) או הפוך (ICMP חסום, הפורט פתוח).

• האם אתם מודדים Round-Trip Time של פינג?

  כן – זמן התגובה (Round-Trip) נרשם בכל בדיקה ונמדד לאורך זמן. שימושי לאיתור בעיות רשת: אותו שרת אבל RTT עולה לאט מ-20ms ל-200ms מעיד על בעיה ב-nat או עומס ברשת.

• האם אפשר לפינג פנימי?

  רק אם ה-IP זמין מהשרתים שלנו – כלומר IP ציבורי. טווחי RFC1918 פרטיים (192.168.x.x, 10.x.x.x, 172.16-31.x.x) לא יעבדו בניטור חיצוני. עבור תשתית פנימית, הפעל self-hosted heartbeat agent ברשת הפנימית שיבצע את הפינג אלינו.