2 סוכן SNMP

סקירה כללית

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

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

בדיקות SNMP מבוצעות באמצעות פרוטוקול UDP בלבד.

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

שרת Zabbix ו-Proxy daemons יומן שורות הדומות ל- if הם מקבלים תגובת SNMP שגויה:

 תגובת SNMP מה-"שער" המארח אינה מכילה את כל הכריכות המשתנות המבוקשות

הם אמנם לא מכסים את כל המקרים הבעייתיים, אבל הם שימושיים עבור זיהוי התקני SNMP בודדים שעבורם צריכות להיות בקשות בכמות גדולה נָכֶה.

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

::: הערה אזהרה אם ניטור התקני SNMPv3, ודא כי msgAuthoritativeEngineID (ידוע גם בשם snmpEngineID או "מזהה מנוע") הוא מעולם לא שותף לשני מכשירים. לפי RFC 2571 (סעיף 3.1.1.1) זה חייב להיות ייחודי לכל מכשיר. :::

::: הערה אזהרה RFC3414 דורש ממכשירי SNMPv3 להתמיד מגפי המנוע שלהם. חלק מהמכשירים לא עושים את זה, מה שגורם להם הודעות SNMP נמחקות כמיושנות לאחר הפעלה מחדש. בכזה במצב, יש לנקות מטמון SNMP באופן ידני בשרת/פרוקסי (על ידי באמצעות -R snmp_cache_reload) או שיש להפעיל מחדש את השרת/פרוקסי. :::

הגדרת ניטור SNMP

כדי להתחיל לנטר מכשיר דרך SNMP, יש לבצע את השלבים הבאים לְהֵעָשׂוֹת:

שלב 1

גלה את מחרוזת ה-SNMP (או OID) של הפריט שברצונך לנטר.

כדי לקבל רשימה של מחרוזות SNMP, השתמש בפקודה snmpwalk (חלק מ תוכנת net-snmp שאמורה להיות לך מותקן כחלק מהתקנת Zabbix) או כלי שווה ערך:

 shell> snmpwalk -v 2c -c public <host IP> .

מכיוון ש'2c' כאן מייצג גרסת SNMP, אתה יכול גם להחליף אותה ב '1', לציון SNMP גרסה 1 במכשיר.

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

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

 IF-MIB::ifHCInOctets.3 = Counter64: 3409739121

כעת תוכל להשתמש בפקודה snmpget כדי לגלות את ה-OID המספרי עבור 'IF-MIB::ifHCInOctets.3':

 shell> snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3

שים לב שהמספר האחרון במחרוזת הוא מספר היציאה שאתה מחפש לפקח. ראה גם: דינמי indexes.

זה אמור לתת לך משהו כמו הבא:

 .1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941

שוב, המספר האחרון ב-OID הוא מספר היציאה.

בדוגמה האחרונה לעיל סוג הערך הוא "Counter64", אשר באופן פנימי מתאים לסוג ASN_COUNTER64. הרשימה המלאה של הסוגים הנתמכים היא ASN_COUNTER, ASN_COUNTER64, ASN_UINTEGER, ASN_UNSIGNED64, ASN_INTEGER, ASN_INTEGER64, ASN_FLOAT, ASN_DOUBLE, ASN_TIMETICKS, ASN_GAUGE, ASN_IPADDRESS, ASN_OCTET_STR ו-ASN_OBJECT_ID. סוגים אלה תואמים בערך ל-"Counter32", "Counter64", "UIinteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" ב פלט snmpget, אך עשוי להיות מוצג גם בתור "STRING", "Hex-STRING", "OID" ואחרים, בהתאם לנוכחות של רמז לתצוגה.

שלב 2

צור מארח המתאים למכשיר.

הוסף ממשק SNMP עבור המארח:

• הזן את כתובת ה-IP/שם ה-DNS ומספר היציאה
• בחר את גרסת SNMP מהתפריט הנפתח
• הוסף אישורי ממשק בהתאם לגרסת ה-SNMP שנבחרה:
  • SNMPv1, v2 דורשים רק את הקהילה (בדרך כלל 'ציבורי')
  • SNMPv3 דורש אפשרויות ספציפיות יותר (ראה להלן)
• השאר את תיבת הסימון השתמש בבקשות בכמות גדולה מסומנת כדי לאפשר כמות גדולה עיבוד בקשות SNMP

במקרה של אישורי SNMPv3 שגויים (שם אבטחה, אימות פרוטוקול/ביטוי סיסמה, פרוטוקול פרטיות):

• Zabbix מקבל שגיאה מ-net-snmp, למעט משפט סיסמה שגוי ובמקרה זה Zabbix מקבל שגיאת TIMEOUT מ-net-snmp;
• (מאז Zabbix 6.0.13) זמינות ממשק SNMP תעבור לאדום (לא זמין).

::: הערה אזהרה שינויים בפרוטוקול אימות, משפט סיסמה לאימות, פרוטוקול פרטיות או משפט סיסמה, שנעשה ללא שינוי שם האבטחה, ייכנס לתוקף רק לאחר המטמון בשרת/פרוקסי מנוקה ידנית (על ידי שימוש ב--R snmp_cache_reload) או שרת/פרוקסי מופעל מחדש. במקרים שבהם שם אבטחה מופיע גם שונה, כל הפרמטרים יעודכנו באופן מיידי. :::

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

שלב 3

צור פריט לניטור.

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

• הזן את שם הפריט
• שנה את השדה 'סוג' ל'סוכן SNMP'
• הזן את 'המפתח' כמשהו בעל משמעות
• ודא שבשדה 'ממשק מארח' יש את המתג/נתב שלך
• הזן את ה-OID הטקסטואלי או המספרי שאחזרת קודם לכן לתוך שדה 'SNMP OID', לדוגמה: .1.3.6.1.2.1.31.1.1.1.6.3
• הגדר את 'סוג המידע' ל-מספרי (לא חתום)
• הזן תקופת 'מרווח עדכונים' ו'אחסון היסטוריה' אם תרצה שהם יהיו שונים מברירת המחדל
• בלשונית עיבוד מוקדם, הוסף שלב שינוי בשנייה (חשוב, אחרת תקבל ערכים מצטברים מה-SNMP מכשיר במקום השינוי האחרון). בחר מכפיל מותאם אישית אם אתה רוצה אחד.

כל שדות הקלט החובה מסומנים בכוכבית אדומה.

כעת שמור את הפריט ועבור אל ניטור ← נתונים אחרונים עבור ה-SNMP שלך נתונים!

דוגמה 1

דוגמה כללית:

שימו לב שניתן לתת OID בצורה מספרית או מחרוזת. עם זאת, ב במקרים מסוימים, יש להמיר מחרוזת OID לייצוג מספרי. ניתן להשתמש ב- Utility snmpget למטרה זו:

 shell> snmpget -על localhost public enterprises.ucdavis.memory.memTotalSwap.0

דוגמה 2

ניטור זמן פעולה:

עבודה פנימית של עיבוד בכמות גדולה

שרת Zabbix ו-proxy מבקשים התקני SNMP עבור מספר ערכים בבקשה אחת. זה משפיע על כמה סוגים של SNMP פריטים:

• פריטי SNMP רגילים
• פריטי SNMP עם דינמי אינדקסים
• SNMP גילוי ברמה נמוכה כללים

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

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

עבור "קבל", נעשה שימוש ב-GetRequest-PDU עם 128 משתנים לכל היותר כריכות. עבור "הליכה", נעשה שימוש ב-GetNextRequest-PDU עבור SNMPv1 ו נעשה שימוש עבור GetBulkRequest עם שדה "מקסימום חזרות" של 128 לכל היותר SNMPv2 ו-SNMPv3.

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

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

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

על מנת למצוא מספר אופטימלי של אובייקטים לשאילתה עבור נתון מכשיר, Zabbix משתמש באסטרטגיה הבאה. זה מתחיל בזהירות עם שאילתה של ערך אחד בבקשה. אם זה מצליח, זה שואל את 2 ערכים בבקשה. אם זה יצליח שוב, הוא יבקש 3 ערכים פנימה בקשה וממשיך באופן דומה על ידי הכפלת מספר השאילתות אובייקטים ב-1.5, וכתוצאה מכך הרצף הבא של גדלי בקשות: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

עם זאת, ברגע שמכשיר מסרב לתת מענה ראוי (לדוגמה, עבור 42 משתנים), Zabbix עושה שני דברים.

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

הדבר השני ש- Zabbix עושה עבור אצוות פריטים עוקבות הוא שהוא מתחיל עם המספר המוצלח האחרון של משתנים (28 בדוגמה שלנו) ו ממשיך להגדיל את גדלי הבקשות ב-1 עד למגבלה. ל לדוגמה, בהנחה שגודל התגובה הגדול ביותר הוא 32 משתנים, ה הבקשות הבאות יהיו בגדלים 29, 30, 31, 32 ו-33. הבקשה תיכשל ו- Zabbix לעולם לא תוציא בקשה בגודל 33 שוב. מנקודה זו ואילך, Zabbix ישאל לכל היותר 32 משתנים עבור המכשיר הזה.

אם שאילתות גדולות נכשלות עם מספר זה של משתנים, זה יכול להיות אחד מהם שני דברים. הקריטריונים המדויקים שבהם משתמש מכשיר להגבלת התגובה לא ניתן לדעת את הגודל, אך אנו מנסים להעריך זאת באמצעות המספר של משתנים. אז האפשרות הראשונה היא שמספר המשתנים הזה הוא סביב מגבלת גודל התגובה בפועל של המכשיר במקרה הכללי: לפעמים התגובה קטנה מהגבול, לפעמים היא גדולה יותר זֶה. האפשרות השנייה היא חבילת UDP לכל כיוון פשוט הלך לאיבוד. מסיבות אלו, אם Zabbix מקבל שאילתה נכשלה, זה מפחית את המספר המרבי של משתנים כדי לנסות להעמיק לתוך טווח נוח של המכשיר, אבל (החל מ-2.2.8) רק עד שניים פִּי.

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

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