הגדרת ניטור SNMP של שרתים וציוד רשת מקצה לקצה

הרשת גדלה, וחלק מהצמתים יוצאים מהשדה — ואת התקלה אתם מגלים מהמשתמשים, ולא מהמערכת. אנו מגדירים ניטור SNMP של שרתים וציוד רשת מקצה לקצה: אוספים נתונים מכל הצמתים, בונים התראות ומעבירים נהלים מוכנים לצוות שלכם. לא נשארות נקודות עיוורות בתשתית, והזמן עד לגילוי תקלה מתקצר.

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע ניטור SNMP מאבד צמתים כאשר התשתית גדלה

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

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

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

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

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

מה נותן ניטור SNMP: השפעות מדידות עבור התשתית

ההשפעה של ניטור SNMP נמדדת לא בעצם קיומו, אלא בשני מספרים: כמה מוקדם יותר אנו יודעים על תקלה וכמה מהר יותר אנו סוגרים אותה. סקר לפי הפרוטוקול הסטנדרטי נותן את המספרים האלה עבור כל צומת — משרת ועד מתג בפריפריה.

תקלה נראית תוך דקה, לא אחרי שיחה מהמשרד

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

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

כיסוי התשתית והיסטוריית מדידות

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

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

דרכים לאיסוף מטריקות: עם סוכן, בלי סוכן, טלמטריה זורמת

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

אפשרות מתי מתאימה מגבלות
סקר ללא סוכן (SNMP) ציוד רשת, UPS, מדפסות, התקנים ללא מערכת הפעלה משלהם נראות רק קבוצות המונים הסטנדרטיות; אין מטריקות יישומים, רמת הפירוט מוגבלת
התקנת סוכן-אוסף על המארח שרתים, בסיסי נתונים, תורים, שירותי אינטרנט — יש צורך במטריקות של תהליכים ודיסקים יש להתקין את הסוכן, לעדכן אותו ולעקוב אחריו; פורט פתוח מחייב הגבלת גישה
העברת מטריקות בזרימה דרך שער מקומי משימות קצרות-מועד, חישובי אצווה, מקטעים ללא גישה נכנסת אין נקודת סקר קבועה — אובדן המקור נראה רק בהיעדר נתונים, יש צורך במאגר בצד השער

סקר מאובטח

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

את הסקר בונים לפי ענפים מסוימים בעץ, ולא על כולו — זה מפחית באופן מורגש את העומס על מעבדים חלשים של מתגים.

תדירות הדגימה

בסיס — פעם בדקה: ההידרדרות נראית, והסקר אינו הופך לעומס קבוע. עבור פורטים של עמוד השדרה — לעתים קרובות יותר, 10–15 שניות, אחרת זינוקות קצרים ממוצעים ואובדים.

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

שלבי היישום: ממלאי ועד מסירה לתפעול

סדר העבודה זהה עבור מצבת שרתים, מתגים ומערכות כוח — משתנים רק היקף ועומק הסקר. תחילה אנו מתעדים את ההרכב, לאחר מכן מתארים את סכימת הדגימה של המדדים, ורק אחרי כן נוגעים בציוד הייצור: כך אנו מונעים התראות שווא ועומס מיותר על הרשת.

הכנה: מלאי וסכימת סקר

  1. מלאי ציוד — רשימת צמתים עם כתובות, תפקידים ואחראים, אילו קבוצות פרמטרים זמינות מכל אחד. בנפרד אנו מסמנים התקנים ללא סקר ורשומות כפולות.
  2. סכימת סקר — מה נלקח מכל סוג ציוד, באיזה מרווח, זמן המתנה לתשובה ומספר ניסיונות חוזרים, כיצד מפזרים את הזרימות בין צומתי הסקר כדי שהשיא לא ייפול על אחד.
  3. ערכי סף — שתי רמות לפי טמפרטורה, ספק כוח, דיסקים ופורטים, עם התאמה לפיזור הנורמלי של דגם מסוים; אחרת התורן ישקע ברעש.

יישום ומסירה לתפעול

  • הגדרה וחיבור — מפעילים סקר על ההתקנים עצמם, נותנים גישה לקריאה בלבד ובודקים שדגימת המדדים אינה משפיעה על עבודת השירותים.
  • בדיקת התראות — מדמים תקלות אמיתיות: מנתקים כבל, מפסיקים ספק כוח, ממלאים מחיצה. בודקים שההתראה הגיעה לאדם הנכון בזמן הצפוי וללא כפילויות.
  • תיעוד — מפת צמתים, פרמטרים וספים, הוראות לחיבור ציוד חדש ולכיבוי התראות רועשות.
  • מסירה לתפעול — מוסרים גישות ותיעוד למשמרת התורנית, מתעדים נוהל תגובה לתקלות.

מה מוסרים לידיים: תצורות, מפות רשת ונוהלים

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

תצורות ומפת הצמתים הנצפים

  • תבניות תצורה — הכנות לשרתים, מתגים, נתבים ומקורות כוח בלתי מופסקים: סט מטריקות, לוח זמנים לסקר, פסקי זמן וניסיונות חוזרים כבר מוגדרים, עבור התקן חדש משנים כתובת ופרופיל.
  • מפת רשת — רשימת צמתים עם תפקידים, כתובות, נקודות קישור ומה נלקח מכל אחד; לפיה רואים מיד אם כל ההיקף מכוסה בניטור או שנשארו נקודות עיוורות.
  • ספים וכללי התראות — מה נחשב לנורמה, מה לאזהרה, מה לתקלה, למי ולאן נשלחת ההודעה, והיכן מדוכא כפל.
  • סכימת זרימות — כיצד האות מהציוד מגיע לתורן, כולל נתיב גיבוי למקרה שצומת האיסוף הראשי אינו זמין.

גישות וסדרי עבודה

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

מקרה בוחן: קיצרנו את זמן גילוי התקלות ברשת מבוזרת

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

מדידות לפני היישום

השוואה בין המערכת לבסיס הציוד הראתה: תחת סקר קבוע 58% מהצמתים, והשאר מחוץ לניטור. זמן גילוי תקלה ממוצע לפי יומן הפניות — 47 דקות, מהאות הראשון של המשתמש ועד רישום האירוע. במהלך הרבעון 9 תקלות נותחו בדיעבד, כבר לאחר הידרדרות השירות.

מה שינינו ומה השגנו

פרשנו מעגל אחיד על Zabbix: תבניות לכל דגם, סקר ממשקים וחיישני ספק כוח, קבלת הודעות תקלה מההתקנים, ספים נפרדים להידרדרות ולכשל מלא. ספים וכללי התראה נשמרים במאגר לצד התצורה — שינויים עוברים בדיקה, ולא מבוצעים על שרת חי.

כיסוי הצמתים עלה ל-97%, זמן הגילוי הצטמצם ל-2 דקות בממוצע ול-4 דקות באחוזון ה-90. התראות שווא לאחר הגדרת ספים לפי קו בסיס של תעבורה ירדו ב-70%, ותקלות שהוחמצו ברבעון — אפס: כל תקלה נרשמת לפני שהמשתמשים מבחינים בה.

במה שונה סקר תקופתי מהודעות תקלה?

סקר תקופתי והודעות תקלה — שני מנגנונים שונים להעברת נתונים, ואסור לבלבל ביניהם בעת בחירת מצב ניטור. במקרה הראשון הקולקטור עצמו פונה לסוכן SNMP במרווח קבוע ולוקח ערכי מונים ומצב ממשקים. במקרה השני — ההתקן עצמו יוזם הודעה ברגע האירוע: קישור נפל, סף טמפרטורה הופעל, דיסק התנתק.

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

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

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

ספקות טכניים לפני ההתחלה: עונים על שאלות נפוצות

לפני ההתחלה בדרך כלל נשארות כמה שאלות, שבהן תלוי אם מערכת הבקרה תהפוך לעוגן עבור המשמרת התורנית או למקור רעש שמכבים כעבור חודש.

אספנו את אלה ששואלים הכי часто: כיצד הסקר משפיע על הרשת, מה לעשות עם ציוד ללא תמיכה, כיצד לסנן התראות שווא, כיצד לעבור מהמערכת הנוכחית ומי אחראי עליה לאחר המסירה.

האם הסקר יעמיס על הרשת והערוצים בין האתרים?

SNMP מוסר מונים במנות קטנות, והנפח העיקרי אינו תעבורה אלא תדירות. את המרווח בוחרים לפי סוג הצומת: ליבה וקישורי uplink נסקרים לעתים קרובות יותר, פריפריה — לעתים רחוקות יותר, ומשך הסקר מפזרים לפי לוח זמנים כדי שהסקרים לא יחפפו. בערוצים צרים מציבים קולקטור באתר — החוצה יוצאת רק מטריקה מצטברת, ולא נתונים גולמיים מכל הפורטים.

חלק מהציוד אינו תומך ב-SNMP או שהגישה חסומה. מה לעשות איתו?

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

כיצד לסנן התראות שווא?

ספים מחשבים לפי ההתנהגות הנצפית של הצומת, ולא לפי המלצות כלליות: תחילה המערכת אוספת סטטיסטיקה, אחר כך קובעים גבולות לכל ממשק ולכל שירות.

הפעלה מחייבת החזקת סטייה כמה מחזורים ברצף, ולא מדידה אחת; בזמן עבודות מתוכננות הבדיקות מושתקות, וצמתים תלויים מקובצים, כדי שתקלה בליבה לא תוליד מאה התראות.

כיצד לעבור מהמערכת הנוכחית לבקרה בלי נקודה עיוורת?

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

מי אחראי על המערכת לאחר המסירה?

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

נדון במשימה: נבנה סכימת איסוף נתונים עבור הרשת שלכם

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

  • הרכב המצבה: כמה שרתים, מתגים, נתבים ומקורות כוח בלתי מופסקים, אילו יצרנים, האם יש מקטעים שבהם סוכן הסקר אינו פעיל כעת.
  • מצבי עבודה: אילו צמתים קריטיים לעסק, היכן מספיק סקר פעם בכמה דקות, והיכן נדרשת תגובה לאירוע עם התרחשותו.
  • גישה וגרסאות סוכנים: היכן נתמך SNMP v3 עם אימות, והיכן נשאר רק v2c ויידרש אזור סקר נפרד.
  • דרישות להתראות: אילו אירועים להיחשב כתקלה, למי ולאן נשלחת התראה, והאם נדרשת הסלמה אם התורן לא הגיב.
  • מטריקות וספים: טמפרטורה, ספק כוח, עומס ממשקים, מקום פנוי — מה בדיוק נלקח ולפי אילו ערכים בונים התראה.
  • מגבלות גישה: כללי חומות אש, מקטעים מבודדים, סדר תיאום חיבור צומת חדש.
  • יעד הנתונים: היכן לאחסן מטריקות — בשרתים שלכם, בענן או במערכת שכבר פועלת, ומה מזה מותקן כיום.
  • לוחות זמנים ושלביות: עד איזה תאריך נדרש מעגל עובד, האם יש חלונות לשינויים ומי מטעמכם מאשר גישות.

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