2 SNMP агент [Zabbix Documentation 2.2]

1. 2 SNMP агент
2. Налаштування моніторингу по SNMP
3. Крок 1
4. крок 2
5. крок 3
6. приклад 1
7. приклад 2
8. Обробка масових SNMP запитів

2 SNMP агент

огляд

Ви можливо захочете використовувати SNMP моніторинг пристроїв таких як принтери, мережеві комутатори, маршрутизатори або ІБП, як правило, які як правило підтримують SNMP і для яких було б непрактично намагатися налаштовувати комплексні системи управління або Zabbix агенти.

SNMP перевірки виконуються тільки через UDP протокол.

Якщо виконується моніторинг пристроїв по SNMPv3, переконайтеся що msgAuthoritativeEngineID (також відоме як snmpEngineID або "Engine ID") ніколи не буде спільним для двох і більше пристроїв. Воно повинно бути унікальним для кожного пристрою.

Якщо раніше підтримувалися тільки протоколи MD5 і DES для безпеки і аутентифікації по SNMPv3, починаючи з Zabbix 2.2 також підтримуються протоколи SHA аутентифікації і AES безпеки.

Налаштування моніторингу по SNMP

Для початку моніторингу пристрої по SNMP, повинні бути виконані наступні кроки:

Крок 1

Створіть вузол мережі для пристрою з SNMP інтерфейсом.

Введіть IP адресу. Вкажіть стан вузла мережі в БЕЗ СПОСТЕРЕЖЕННЯ. Ви можете використовувати один з поставляються шаблонів SNMP (Template SNMP Device і інші), які автоматично додадуть деякий набір елементів даних. Проте, шаблон може бути несумісний з вузлом мережі.

SNMP перевірки не використовують Порт агента, він ігнорується.

крок 2

Дізнайтеся рядок SNMP (або OID) елемента даних, яку ви хочете моніторити.

Для отримання списку рядків SNMP, використовуйте команду snmpwalk (частина програмного забезпечення net-snmp , Яке ви повинні були встановити як частина інсталяції Zabbix) або еквівалентну утиліту:

'2c' тут означає версію SNMP, ви також можете замінити його на "1", щоб використовувати 1 версію SNMP на пристрої.

Ця команда повинна показати вам список SNMP рядків і їх останні значення. Якщо цього не станеться, то можливо що SNMP 'community' відрізняється від стандартного 'public', в цьому випадку вам необхідний дізнатися це ім'я.

Ви можете пройтися по списку поки не знайдете рядок яку ви хочете моніторити, наприклад, якщо ви хочете моніторити входить кількість байт на вашому комутаторі на 3 порту ви могли б використовувати IF-MIB :: ifInOctets.3 з цього рядка:

Зараз ви можете скористатися командою snmpget для того щоб визначити цифровий OID для 'IF-MIB :: ifInOctets.3':

Зверніть увагу, що останнє число в рядку це номер порту, який ви шукайте для моніторингу. Дивіться також: динамічні індекси .

Висновок команди покаже вам щось на зразок цього:

Знову ж, останнє число в OID є номером порту.

3COM здається використовує номера портів сотнями, наприклад 1 порт = 101 порт, 3 порт = 103 порт, але в Cisco використовуються звичайні номери, наприклад, 3 порт = 3.

В останньому прикладі вище тип значення "Counter32" (32-бітний лічильник), що внутрішньо відповідає типу ASN_COUNTER. Повний список підтримуваних типів 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 (з 2.2.8). Наведені типи грубо відповідають "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" в виведення snmpget утиліти, але можуть також відображатися як "STRING", "Hex-STRING", "OID" та інші, в залежності від наявності отриманої підказки.

крок 3

Створіть елемент даних для моніторингу.

Отже, поверніться назад в Zabbix і натисніть на Елементи даних, виберіть створений раніше вузол мережі SNMP. Залежно від того чи використовували ви шаблон при створенні вузла мережі чи ні, ви повинні будете побачити список елементів даних SNMP, пов'язаних з вашим вузлом мережі або просто вікно нового елемента даних. Ми будемо виходити з припущення, що ви збираєтеся створити елемент даних самостійно, за допомогою інформації, яку ви тільки що зібрали використовуючи snmpwalk або snmpget, так що введіть простий опис російською мовою (або англійською) в поле 'Опис' в діалозі нового елемента даних . Переконайтеся, що в полі 'Вузол мережі' знаходиться ваш комутатор / роутер і змініть поле 'Тип' в значення "SNMPv * агент". Введіть community (зазвичай public) і вкажіть текстовий або числовий OID, який ви отримали раніше, в поле 'SNMP OID', наприклад: .1.3.6.1.2.1.2.2.1.10.3

Введіть 'Порт SNMP' - 161 і 'Ключ' - щось осмислене, наприклад, SNMP-InOctets-Bps. Виберіть Множник, якщо бажаєте, і вкажіть 'інтервал поновлення', і 'зберігання історії', якщо ви хочете щоб значення параметрів відрізнялися від замовчувань. Встановіть 'Стан' в Спостерігається, 'Тип інформації' в значення рівне Числовий (з плаваючою точкою) і 'Зберігання значення' як Дельта (швидкість в секунду) (важливо, в іншому випадку ви будете отримувати накопичені значення з SNMP пристрої замість останньої зміни) .

Тепер збережіть елемент даних і поверніться в область вузлів мережі Zabbix. Від сюди змініть стан SNMP пристрою в 'Спостерігається' і перевірте в Останніх даних ваші дані SNMP!

Зверніть увагу на специфічні опції доступні тільки для SNMPv3 елементів даних:

Починаючи з Zabbix 2.2, протоколи SHA and AES підтримуються для аутентифікації і шифрування SNMPv3, в доповненні до підтримуваним MD5 і DES протоколам раніше.

приклад 1

Загальний приклад:

Зверніть увагу, що OID можна задати в числовому або строковому поданні. Проте, в деяких випадках, строковий OID повинен бути сконвертовані в числове уявлення. Для цього можна використовувати утиліту snmpget:

Моніторинг SNMP параметрів можливий, якщо вказано прапор --with-net-snmp при конфігуруванні вихідних кодів Zabbix.

приклад 2

Моніторинг часу роботи:

Обробка масових SNMP запитів

Починаючи з 2.2.3 Zabbix сервер і проксі одним опитуванням запитують безліч SNMP елементів даних. Така поведінка зачіпає такі типи SNMP елементів даних:

Всі елементи даних SNMP з одного інтерфейсу заплановані на опитування в один час. Перші два типи елементів даних збираються Поллер порціями не більше ніж по 128 елементів даних, в той час як правила низкоуровневого виявлення обробляються індивідуально як і раніше.

На низькому рівні, є два види операцій виконуваних при опитуванні значень: отримання декількох заданих об'єктів і проходження дерева OID-ів.

Для "отримання" використовується GetRequest-PDU c не більше ніж 128 прив'язаних змінних. Для "проходження", використовується GetNextRequest-PDU для SNMPv1 і GetBulkRequest з полем "max-repetitions" з найбільшою кількістю в 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 робить 2 речі.

Перше, для поточної серії елементів даних Zabbix ділить навпіл кількість елементів даних за один запит і запитує 21 змінних. Якщо пристрій є, далі запити повинні працювати в більшості випадків, тому що відомо що 28 змінних забиралося, а 21 значно менше. Проте якщо проблема із запитами триває, Zabbix зменшує кількість запитів послідовно згідно з цим алгоритмом. Якщо і далі проблеми з запитами все ще актуальні, значить пристрій безумовно не відповідає і кількість запитів це не корінь проблеми.

Друга справа, що робить Zabbix для подальших порцій елементів даних - це, починаючи з останнього вдалого кількості змінних (28 в нашому випадку), продовжує збільшувати кількість змінних за запит на 1 до досягнення ліміту. Наприклад, припустимо що максимально можлива кількість запитів для даного пристрою це 32, наступні запити будуть наступними 29,30,31,32 і 33. Останній запит буде невдалим і Zabbix ніколи паче не запросить 33 значення за один запит. З цього моменту, Zabbix завжди буде запитувати 32 значення для цього пристрою.

Якщо великі запити невдало завершуються з певним кількістю змінних, це може означати одне з двох. Точний критерій за яким пристрій може обмежувати запити невідомий, але ми можемо приблизно розрахувати кількість змінних. Перша ймовірність - що кількість значень приблизно дорівнює дійсному ліміту розміру для даного пристрою в загальному випадку: іноді запитів або менше ніж ліміт, іноді більше. Друга ймовірність, що UDP пакет був втрачений. В цьому випадку, якщо Zabbix стикається з невдалим запитом, він зменшує максимальну кількість запитуваних значення за запит для спроби отримання з пристрою коректного діапазону, але (починаючи з 2.2.8) тільки до 2 разів.

В наведеному вище прикладі, якщо запит з 32 змінними буде невдалий, Zabbix зменшить кількість до 31. Якщо невдача статися знову, Zabbix зменшить кількість до 30. Проте, Zabbix не погіршить кількість нижче 30, тому що він припустить, що такі проблеми по причини втрачених UDP пакетів, чим швидше обмеження пристрої.