ניטור נקודות קצה

מהו "נקודת קצה"?

נקודת קצה היא כל דבר שניתן לכתובת באינטרנט ואפשר לשלוח אליו בקשה כדי לאמת זמינות. המקרה הקלאסי הוא URL של אתר — אבל בתשתיות מודרניות הדברים שאתה דואג להם מגוונים הרבה יותר: REST API, נקודות קצה של GraphQL, שרתי דואר, מאזיני מסדי נתונים, תורי הודעות, פורטים של בדיקות חיים של קונטיינרים, פאנלים פנימיים, מקבלי webhook. ניטור זמינות של DiagnoSEO מתייחס לכולם באותו אופן: אתה מגדיר מהו "בריא" עבור אותה נקודת קצה, קובע לוח זמנים של בדיקות, ומקבל התראה במקרה של תקלה.

דף זה מתאר כל סוג של נקודת קצה שהכלי תומך בו, לאילו מטרות מתאים כל סוג ואיזו אינדיקציה מספק הניטור.

נקודות קצה HTTP / HTTPS (אתרי אינטרנט)

המצב ברירת מחדל. אתה מזין https://example.com והניטור מבצע בקשת GET בפרקי זמן נתונים (דקה, 5, 10, 30, או 60 דקות בהתאם לתכנית). בדיקה מוצלחת פירושה: חיבור TCP בוצע, ה-TLS handshake הושלם (ב-HTTPS), התקבלה תשובת HTTP עם קוד סטטוס צפוי (ברירת מחדל: 2xx או 3xx), ואופציונלית keyword שמופיע (או לא מופיע) בגוף התשובה. הבדיקה רושמת Time To First Byte, סה"כ זמן תגובה, גודל התוכן, שרשרת הפניות וכל כותרות התשובה.

נקודות קצה HTTP הן הבחירה הנכונה עבור: דפי שיווק, בלוגים, חנויות e-commerce, לוחות בקרה של SaaS, פורטלים של דוקומנטציה — בכל מקום בו אנשים מבקרים באמצעות דפדפן.

נקודות קצה API (REST / GraphQL / JSON-RPC)

API צריך יותר מ"רק הגיב" — הוא צריך "האם הגיב נכון". אתה מגדיר ניטור עם שיטת HTTP מותאמת (GET, POST, PUT, DELETE, PATCH), כותרות מותאמות (אסימון הזדהות, content-type), גוף הבקשה (payload JSON ל-POST/PUT) ואשרטות JSON על התשובה (data.status חייב להיות "ok", result.count חייב להיות גדול מ-0, errors[] חייב להיות ריק). API שמחזיר HTTP 200 עם payload פגום הוא התקלה הגרועה ביותר — נראה תקין בעיני ניטור פשוט אבל מאכזב כל לקוח. האשרטות מזהות זאת.

עיין במדריך המוקדש לניטור API לפרטי הגדרה וסינטקס של אשרטות.

נקודות קצה של פורטים TCP

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

זה הניטור המתאים לכל שירות מבוסס TCP שחשובה לך זמינותו ואינך זקוק לבדיקה שמבינה את הפרוטוקול. לצורך אימות באנר SMTP או בדיקות שאילתות ברמת מסד הנתונים, השתמש בניטור heartbeat (השירות שלך שולח לנו ping כשהוא בריא, עיין בניטור cron-job / heartbeat).

נקודות קצה ping (ICMP)

בדיקת זמינות בשכבה 3. הניטור שולח בקשת ICMP echo ל-hostname או IP היעד וממתין לתגובה. שימושי עבור נתבים, switches, מכשירי IoT, כל דבר שמגיב ל-ping אך אינו מפעיל HTTP. זכור שרבים מספקי הענן (AWS, GCP, Azure) חוסמים כברירת מחדל ICMP ברמת security-group גם כאשר ה-host בריא — עבור עומסי ענן עדיף לבדוק HTTP או פורטי TCP.

נקודות קצה hostname / DNS

ניטור פתרון DNS. הכלי פותר באופן תקופתי את רשומות A, AAAA, MX, NS, TXT ו-CNAME של הדומיין שלך, מצלם את התוצאות ומתריע כאשר משתנה משהו. מזהה: השתלטות לא מאושרת על DNS, טעויות תצורה אקראיות בהעברת ספק DNS, שירותים חיצוניים שמשנים את נקודות הקצה שלהם מבלי להודיע (כמו כש-CDN שלך מחליף בלוקי IP), רשומות MX שנמחקות בטעות כתוצאה משגיאת כתיב.

ניטור DNS אינו עוסק בזמינות — ספק ה-DNS שלך אמין כמעט תמיד יותר מה-origin. המטרה היא לגלות שינויים. עיין בניטור שינויים ב-DNS לתיאור המלא.

נקודות קצה של תעודות SSL

כל נקודת קצה HTTPS מקבלת ניטור SSL אוטומטי בנוסף לבדיקה הרגילה של זמינות. הכלי קורא את התעודה, מפרש את תוקפה וזהות המנפיק, ומתריע 30, 14, 7, 3 ויום לפני הפקיעה. עיין בניטור תעודות SSL לפרטים נוספים.

נקודות קצה של פקיעת דומיין

עבור כל URL מנוטר הכלי גם מבצע שאילתת WHOIS פעם ביום ועוקב אחרי תאריך פקיעת הדומיין. התראות נשלחות באותם שלבים כמו ב-SSL (30/14/7/3/1 ימים). איחור בתשלום חידוש עלול להיות הרסני — הדומיין נותר ללא בעלים ומישהו אחר עלול לרשום אותו בסיום תקופת הגרייס. עיין בניטור פקיעת דומיין.

בחירת סוג נקודת הקצה המתאים

אם אינך יודע איזה סוג ניטור לבחור, התחל מ-HTTP/HTTPS לכל דבר עם ממשק וובי, פורט TCP לשאר, והוסף בדיקות heartbeat עבור עבודות batch שאינן חושפות שום ממשק רשת. תוכל לנטר אותו יעד בכמה סוגי ניטור — לדוגמה, בדיקת TCP על פורט 443 תזהה "השרת פעיל, אבל TLS handshake נכשל" שאותה גם בדיקת HTTP על אותו URL עשויה לדווח, בעוד ש-heartbeat מה-agent הפנימי שלך ודאי מאשר כי הלוגיקה של האפליקציה שלך אכן פועלת.

שאלות נפוצות

• מהי נקודת קצה?

  כל דבר שאפשר להגיע אליו באינטרנט: URL-ים של HTTP/HTTPS, REST API, פורטים של TCP (SMTP, MySQL, מותאם), hostnames לבדיקה ב-ping, רשומות DNS, תעודות SSL ורישום דומיינים. הגדר ניטור אחד לכל סוג נקודת קצה.

• האם להשתמש בבדיקת HTTP או פורט TCP?

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

• במה שונים ניטורי heartbeat (cron-job)?

  Heartbeat הוא הפוך — במקום שאנו נבדוק את השירות שלך, השירות שלך שולח ping ל-URL ידוע שלנו. אם לא קיבלנו ping במסגרת הזמן, אנו מתריעים. מתאים ל-cron jobs, תהליכי batch וכל מה שפועל לפי לוח זמנים ללא ממשק רשת לבדיקה.

• האם ניתן לנטר אותו URL עם מספר ניטורים?

  כן. תוכל לנטר אותו יעד באמצעות כמה סוגי בדיקות — לדוג' בדיקת HTTP לזמינות מלאה ובדיקת TCP על פורט 443 עבור בעיות TLS-handshake. כל ניטור פועל בנפרד ומתריע בנפרד.

• האם עליי לנטר SSL ודומיין בנפרד?

  לא — כל נקודת קצה HTTPS מקבלת ניטור SSL אוטומטי בנוסף לבדיקה הרגילה, וכל URL מנוטר מקבל מעקב יומי אחרי תוקף הדומיין. שניהם כלולים, ללא צורך בהגדרה נוספת. ניטור דומיין הוא לפי דומיין — מספר ניטורים על אותו דומיין משתפים את אותם נתוני WHOIS.