Zabbix מציעה פונקציונליות גילוי רשת אוטומטית כלומר יעיל וגמיש מאוד.
עם הגדרת גילוי רשת כהלכה תוכל:
גילוי רשת Zabbix מבוסס על המידע הבא:
זה לא מספק:
גילוי רשת מורכב בעצם משני שלבים: גילוי ו פעולות.
Zabbix סורקת מעת לעת את טווחי ה-IP המוגדרים ב-גילוי רשת כללים. התדירות של ה בדיקה ניתנת להגדרה עבור כל כלל בנפרד.
שים לב שכלל גילוי אחד תמיד יעובד על ידי יחיד תהליך המגלה. טווח ה-IP לא יחולק בין מרובים תהליכי מגלים.
לכל כלל יש קבוצה של בדיקות שירות שהוגדרו לביצוע עבור ה-IP טווח.
המחאות גילוי מעובדות באופן עצמאי מהאחר המחאות. אם בדיקות כלשהן לא מוצאות שירות (או נכשלות), בדיקות אחרות ימצאו אותן עדיין יעובדו.
כל בדיקה של שירות ומארח (IP) המבוצעת על ידי הרשת מודול גילוי יוצר אירוע גילוי.
אירוע | בדיקת תוצאת השירות |
---|---|
השירות התגלה | השירות 'מעלה' לאחר שהוא 'נפל' או כאשר התגלה בפעם הראשונה. |
שירות למעלה | השירות 'מעלה', לאחר שהוא כבר היה 'מעלה'. |
Service Lost | השירות 'למטה' לאחר שהיה 'מעלה'. |
Service Down | השירות 'down', לאחר שהוא כבר 'down'. |
Host Discovered | לפחות שירות אחד של מארח נמצא ב'מעלה' לאחר שכל השירותים של אותו מארח היו 'נמוכים' או שהתגלה שירות השייך למארח לא רשום. |
Host Up | לפחות שירות אחד של מארח הוא 'up', לאחר שלפחות שירות אחד כבר היה 'up'. |
Host Lost | כל השירותים של מארח נמצאים 'למטה' לאחר שלפחות אחד היה 'מעלה'. |
Host Down | כל השירותים של מארח הם 'down', לאחר שהם כבר היו 'down'. |
אירועי גילוי יכולים להיות הבסיס לרלוונטיים פעולות, כגון:
ניתן להגדיר פעולות אלה ביחס לסוג המכשיר, IP, מצב, זמן פעולה/השבתה וכו'. לפרטים מלאים על הגדרת פעולות לאירועים מבוססי גילוי רשת, ראה פעולה פעולה ו תנאים.
מכיוון שפעולות גילוי הרשת מבוססות על אירועים, הן יעשו זאת יופעל גם כאשר מארח שהתגלה נמצא במצב מקוון וגם כאשר הוא לא מקוון. זה מאוד מומלץ להוסיף פעולה תנאי סטטוס גילוי: למעלה כדי להימנע מפעולות כמו הוסף מארח המופעלות באירועי Service Lost/Service Down. אחרת, אם מארח שהתגלה יוסר באופן ידני, הוא עדיין יפיק אירועי Service Lost/Service Down וייווצר מחדש במהלך מחזור הגילוי הבא.
קישור מארח שהתגלה לתבניות ייכשל ביחד אם לאחת מהתבניות הניתנות לקישור יש ישות ייחודית (למשל. מפתח פריט) שזהה כבר לישות ייחודית (למשל מפתח פריט). קיים במארח או באחד מהאפשרויות הניתנות לקישור תבניות.
מארח נוסף אם נבחרה פעולת הוסף מארח. גם מארח נוסף, גם אם פעולת הוסף מארח חסרה, אם תבחר פעולות הגורמות לפעולות על מארח. פעולות כאלה הן:
מארחים שנוצרו מתווספים לקבוצת מארחים שהתגלו (כברירת מחדל, ניתן להגדרה ב-ניהול ← כללי ← אחר). אם אתה רוצה שמארחים יתווספו לקבוצה אחרת, הוסף הסר מהמארח פעולת קבוצות (ציינת "מארחים שהתגלו") וגם הוסף הוסף פעולת לארח קבוצות (ציון קבוצה מארחת אחרת), כי א המארח חייב להשתייך לקבוצה מארחת.
בעת הוספת מארחים, שם מארח הוא תוצאה של חיפוש DNS הפוך או IP כתובת אם חיפוש הפוך נכשל. חיפוש מתבצע מה-Zabix שרת או פרוקסי Zabbix, תלוי מי מבצע את הגילוי. אם חיפוש נכשל בפרוקסי, הוא לא נוסה שוב בשרת. אם המארח עם שם כזה כבר קיים, המארח הבא יקבל _2 מצורף לשם, ואז _3 וכן הלאה.
אפשר גם לעקוף חיפוש DNS/IP ובמקום זאת להשתמש בפריט ערך עבור שם מארח, לדוגמה:
אם שם המארח הוגדר באמצעות ערך פריט, הוא לא מעודכן במהלך בדיקות הגילוי הבאות. אם לא ניתן להגדיר מארח שם באמצעות ערך פריט, נעשה שימוש בערך ברירת מחדל (שם DNS).
אם כבר קיים מארח עם כתובת ה-IP שהתגלתה, מארח חדש קיים לא נוצר. עם זאת, אם פעולת הגילוי מכילה פעולות (קישור תבנית, הוסף לקבוצה מארח וכו'), הם מבוצעים על הקיים מנחה.
מארחים שהתגלו על ידי כלל גילוי רשת מוסרים באופן אוטומטי מתוך ניטור ← גילוי אם ישות שהתגלתה אינה ב- טווח ה-IP של הכלל עוד יותר. המארחים מוסרים מיד.
כאשר מארחים מתווספים כתוצאה מגילוי רשת, הם מקבלים ממשקים שנוצרו על פי כללים אלה:
המארחים שהתגלו על ידי נציגים שונים זוכים תמיד ליחס מארחים שונים. אמנם זה מאפשר לבצע גילוי ב-IP תואם טווחים המשמשים רשתות משנה שונות, שינוי פרוקסי עבור כבר רשת המשנה המנוטרת מסובכת מכיוון ששינויי ה-proxy חייבים להיות גם מיושם על כל המארחים שהתגלו.
לדוגמה, השלבים להחלפת פרוקסי בכלל גילוי: