2 SNMP агент Zabbix Documentation 3
User Tools
Site Tools
Table of Contents
2 SNMP агент
Ви, можливо, захочете використовувати SNMP моніторинг пристроїв таких як принтери, мережеві комутатори, маршрутизатори або ДБЖ, як правило, які зазвичай підтримують SNMP і для яких було б непрактично намагатися налаштовувати комплексні системи управління або Zabbix агенти.
Щоб була можливість отримувати дані передані SNMP агентами з цих пристроїв, сервер Zabbix повинен бути спочатку налаштований з підтримкою SNMP.
SNMP перевірки виконуються лише через протокол UDP.
Починаючи з версії 2.2.3 демони Zabbix сервера та проксі опитують пристрої SNMP множинними значеннями за один запит. Ця поведінка вплине на всі види SNMP елементів даних (прості SNMP елементи даних, елементи даних з динамічними індексами та низькорівневі SNMP виявлення) і обробка SNMP елементів даних зараз має бути більш ефективною. Будь ласка, зверніть увагу на розділ з технічними подробицями нижче, що описує, як працює зсередини цей функціонал. Починаючи з Zabbix 2.4, у кожного інтерфейсу також є налаштування "Використовувати масові запити", яка дозволяє відключати масові запити у пристроїв, які не здатні обробити їх належним чином.
Починаючи з Zabbix 2.2.7 та Zabbix 2.4.2 процеси сервера та проксі будуть журналювати рядки схожі на наступні у разі отримання неправильної/спотвореної SNMP відповіді: Поки вони не покривають усі можливі проблемні випадки, але вони є зручним зручним ідентифікатором окремих SNMP пристроїв на яких необхідно вимкнути масові запити.
Починаючи з версії Zabbix 2.2, демони сервера та проксі коректно обробляють параметр конфігурації Timeout при виконанні SNMP.перевірок. Додатково демони не виконують повторних запитів після одного неуспішного (за перевищенням часу очікування/невірні налаштування облікових даних) запиту SNMP. Раніше насправді використовувалися стандартні для бібліотеки SNMP значення часу очікування та кількості повторів (1 секунда та 5 повторів відповідно).
Починаючи з версії Zabbix 2.2.8 та Zabbix 2.4.2 демони сервера та проксі завжди виконують один повторний запит: або через механізм бібліотеки SNMP, або через внутрішній механізм збору безлічі значень за один запит (bulk).
Налаштування моніторингу за SNMP
Для початку моніторингу пристрою за SNMP повинні бути виконані наступні кроки:
Створіть вузол мережі для пристрою з інтерфейсом SNMP.
Дізнайтеся рядок SNMP (або OID) елемента даних, який ви хочете моніторити.
Для отримання списку рядків SNMP, використовуйте командуsnmpwalk (частину програмного забезпечення net-snmp, яке ви повинні були встановити як частину інсталяції Zabbix) або еквівалентну утиліту:
'2c' тут означає версію SNMP, ви також можете замінити його на '1', щоб використовувати одну версію SNMP на пристрої.
Ця команда повинна показати вам список SNMP рядків та їх останні значення. Якщо це не станеться, то можливо, що SNMP 'community' відрізняється від стандартного 'public', у цьому випадку вам необхідний дізнатися це ім'я.
Ви можете пройтись по списку доки не знайдете рядок який ви хочете моніторити, наприклад, якщо ви хочете моніторити вхідну кількість байт на комутаторі на 3 порту ви могли б використовувати IF-MIB::ifInOctets.3 з цього рядка:
Зараз ви можете скористатися командоюsnmpget для того, щоб визначити цифровий OID для 'IF-MIB::ifInOctets.3':
Зверніть увагу, щоостаннє число у рядку це номер порту, який ви шукаєте для моніторингу. Дивіться також Динамічні індекси.
Висновок команди покаже вам щось на кшталт цього:
Знову ж таки, останнє число в OID є номером порту.
В останньому прикладі вище тип значення 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_IPADIDESS, ASN_IPADIDESS, ASN_IPADIDESS 2.4.3). Наведені типи грубо відповідають “Counter32”, “Counter64”, “UInteger32”, “INTEGER”, “Float”, “Double”, “Timeticks”, “Gauge32”, “IpAddress”, “OCTET STRING”, “OBJECT IDENTIFIER” у виводіsnmpget утиліти, але можуть також відображатися як “STRING”, “Hex-STRING”, “OID” та інші, залежно від наявності отриманої підказки.
Створіть елемент для моніторингу.
Отже, поверніться назад у 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 пристрою замість останньої зміни).
Тепер збережіть елемент даних і перейдіть в Моніторинг → Останні дані, щоб побачити дані SNMP!
Зверніть увагу на специфічні опції доступні лише для елементів SNMPv3 даних:
Введіть контекстне ім'я, щоб визначити елемент даних у SNMP підмережі. Ім'я контексту підтримується для SNMPv3 елементів даних із Zabbix 2.2.
У цьому полі розкриваються користувацькі макроси.
Зверніть увагу, що OID можна встановити в числовому або рядковому поданні. Тим не менш, в деяких випадках, рядковий OID повинен бути сконвертований у числове подання. Для цього можна використовувати утиліту snmpget:
Моніторинг параметрів SNMP можливий, якщо вказаний прапор --with-net-snmp при конфігуруванні вихідних кодів Zabbix.
Моніторинг часу роботи:
Обробка масових запитів SNMP
Починаючи з 2.2.3 сервер Zabbix і проксі одним опитуванням запитують безліч SNMP елементів даних. Така поведінка стосується таких типів SNMP елементів даних:
Усі елементи даних SNMP з одного інтерфейсу заплановані на опитування одночасно. Перші два типи елементів даних збираються полерами порціями не більше ніж 128 елементів даних, в той часяк правила низькорівневого виявлення обробляються індивідуально, як і раніше.
На низькому рівні, є два види операцій виконуваних під час опитування значень: отримання кількох заданих об'єктів і проходження дерева OID-ов.
Для "отримання" використовується GetRequest-PDU з не більше 128 прив'язаних змінних. Для “проходження”, використовується GetNextRequest-PDU для SNMPv1 та GetBulkRequest з полем “max-repetitions” з найбільшою кількістю 128 отриманих значень використовується для SNMPv2 та SNMPv3.
Таким чином, переваги масової обробки для кожного типу SNMP елемента даних описані нижче:
Тим не менш, є технічна проблема, що не всі пристрої здатні повернути 128 значень за один запит. Деякі завжди повертають коректну відповідь, але інші або відповідають помилково “tooBig(1)”, або не відповідають взагалі, коли потенційний запит перевищує певний ліміт.
Для обчислення оптимальної кількості об'єктів, що запитуються з пристрою, Zabbix використовує наступну стратегію. Починається з обережного запиту на одне значення. Це запит виконано успішно, вимагають 2 значення за один запит. Якщо запит знову виконано успішно, запитується 3 значення за запит і продовжується аналогічно множенням кількості значень, що запитуються на 1.5, в результаті виходить наступна послідовність розміру запитів: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63 , 94, 128.
Однак якщо пристрій відмовляється від відповіді на певний запит (наприклад, 42 змінних), Zabbix робить дві речі.
Перше, для поточної серії елементів даних 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 пакети, ніж швидше обмеження пристрою.
Якщо, однак, пристрій не може обробляти масові запити коректно і з інших причин, починаючи з Zabbix 2.4 є налаштування "Використовувати масові запити" кожного інтерфейсу, яка дозволяє відключити масові запити цього пристрою.