Пример создания шаблона SNMP для Zabbix

Процесс установки zabbix а так же дополнительных различных вспомогательных программ
Deonis
Гость
Сообщения: 9
Стаж: 4 года 4 месяца
Благодарил (а): 1 раз

Пример создания шаблона SNMP для Zabbix

Сообщение Deonis »

Плохо то что в описании на Zabbix нет централизованного описания макросов низкоуровневого обнаружения, в отличии от системных макросов Есть только их перечисление, и приходится искать поиском по всему описанию, в том числе и по готовым шаблонам.
PS Вообще описание Zabbix прямо скажем по принципу - Есть и слава богу...
количество слов: 3
Аватара пользователя
Артём Мамзиков
Admin
Сообщения: 866
Стаж: 5 лет 9 месяцев
Откуда: Вологодская область
Поблагодарили: 41 раз
Контактная информация:

Пример создания шаблона SNMP для Zabbix

Сообщение Артём Мамзиков »

Deonis, В целом версия от версии появляется новый функционал, так же добавляется документация, на русском стало больше всего для zabbix. Возможно позже появится) Можно прямо им написать чтоб добавили в будущем в мануал.
количество слов: 2
Deonis
Гость
Сообщения: 9
Стаж: 4 года 4 месяца
Благодарил (а): 1 раз

Пример создания шаблона SNMP для Zabbix

Сообщение Deonis »

Пользуясь вашим примером и анализом существующего шаблона NAS создал опрос таблицы по SNMP. Мое понимание такое, создавая Правило обнаружения мы говоря языком программистов инициализируем "объект таблица", а создавая прототипы элемента берем данные из описанного "объекта".
PS Долго тупил почему нет данных, пока в прототипе элемента не обнаружил поле SNMP community со значением public (у нас группа переименована), вроде при создании Правила обнаружения уже указал {$SNMP_COMMUNITY} поэтому не ожидал, что при чтении элемента нужно опять вводить...
количество слов: 8
Аватара пользователя
Артём Мамзиков
Admin
Сообщения: 866
Стаж: 5 лет 9 месяцев
Откуда: Вологодская область
Поблагодарили: 41 раз
Контактная информация:

Пример создания шаблона SNMP для Zabbix

Сообщение Артём Мамзиков »

Deonis, "Правило обнаружения мы говоря языком программистов инициализируем "объект таблица", а создавая прототипы элемента берем данные из описанного "объекта"."
Обнаружение выходит так, мы запрашиваем доступные OID типа как пинга на определеные адреса и где есть ответ создаются элементы подставляется значение. На стороне устройства скажем snmp агент грубо говоря есть файл конфигурации с oid (можно сказать и таблица) при включении определенных настроек и в целом общая инфа активирует нужные OID и для них значения с устройства. Грубо говоря примерно так)
количество слов: 5
Deonis
Гость
Сообщения: 9
Стаж: 4 года 4 месяца
Благодарил (а): 1 раз

Пример создания шаблона SNMP для Zabbix

Сообщение Deonis »

Артем, Добрый день!
Тут решил доработать шаблон для работы с рейдом в котором используются таблицы, и возникла проблема которую не знаю как решить.
Имеется таблица в которой индексы присвоены дискам по мере их появления в рейде и они не соответствуют слотам в которых стоят диски. И если к примеру я создаю триггер то он выводит, что событие произошло с диском с таким то индексом, который не соответствует реальному положению диска. Не могу понять как правильно создать триггер.
Из таблицы я получаю:
slotNumber[{#SNMPINDEX}] - соответствие индекса слоту
pdTemperature[{#SNMPINDEX}] -Температура диска по индексу
Попробовал в описании к триггера (оно отправляется админу в сообщении) вписать "Высокая температура диска в слоте {slotNumber[{#SNMPINDEX}]}" Но получил Высокая температура диска в слоте {slotNumber[8]} Подскажите как поступить чтобы соотнести реальный слот в проблеме?
количество слов: 8
Аватара пользователя
Артём Мамзиков
Admin
Сообщения: 866
Стаж: 5 лет 9 месяцев
Откуда: Вологодская область
Поблагодарили: 41 раз
Контактная информация:

Пример создания шаблона SNMP для Zabbix

Сообщение Артём Мамзиков »

Deonis, Добрый день!
Получаем:
Есть диски с индексами 1 2 3 4 ...
Есть слоты 1 2 3 4 .....
Они не соответствуют друг другу

Не видя, на вскидку такие варианты:

1. Задать элемент (или макрос) для триггера , не по слоту диска , а по индексу диска (макрос диска же у нас так же есть)
обычно для отображения в триггере нужен сам элемент в триггере чтоб вывести макрос в название триггера иначе он не поймет откуда его брать, или может быть если макросы название одинаково а 2 разных элемента сработает первым тот который вызовет ошибку. Это например что связано с макросом {ITEM.VALUE}. По SNMP возможно все будет норм.

2. Сделать преобразование одного индекса в другой (опять же применится для всего шаблона, и если больше 1 сервера то будет совсем все не правильно) Либо делать конкретное преобразование значений на хосте в элементе, или предобработку.

3. Вместо слота показывать индекс диска только в триггер.

4. Добавить еще как то макросов и брать из них значения.

Чисто совместить диск и слот чтоб snmp корректно отдавало их, установить диски по порядку в соответствии слотами, если таким способом формируется таблица на сервере OID (но это как то совсем не вариант)
Возможно есть какое то ПО или интерфейс на сервере где можно переназначить OID в соответствии диска и слота.

А так надо смотреть, вникать, вспоминать так сразу не вспомнишь)
количество слов: 21
Аватара пользователя
Артём Мамзиков
Admin
Сообщения: 866
Стаж: 5 лет 9 месяцев
Откуда: Вологодская область
Поблагодарили: 41 раз
Контактная информация:

Пример создания шаблона SNMP для Zabbix

Сообщение Артём Мамзиков »

Zabbix и проблемы с опросом по SNMPv3 при дублировании EngineID

Источник

Я отловил эту проблему на APC
Руками все запросы работают ответ прилетает моментально, а заббикс кажет кразный значек SNMP причем хаотично по узлам где установлено APC то один узел работает то другой, оказалось что я копировал папку APC и EngineID не менялся версия проверки была V3
В итоге после изменений создания разных EngineID все заработало как нужно.


В прошлой заметке Системы мониторинга, SNMPv3 и engineID я опубликовал перевод статьи Михаэля Шварцкопфа Monitoring Systems, SNMPv3 and the engineID. В этой заметке я поделюсь своим пониманием проблемы, с которой столкнулся автор, а затем расскажу о своём опыте решения подобных проблем с коммутаторами D-Link.


1. Обсуждение статьи
В SNMPv3 у каждого агента имеется свой уникальный идентификатор. При первом обращении к агенту станция управления выполняет так называемую процедуру обнаружения - отправляет ему пустой запрос. Агент отвечает на этот запрос, сообщая свой уникальный идентификатор - EngineID, количество перезагрузок агента - EngineBoots и время, прошедшее с момента последней перезагрузки агента - BootTime. Станция управления запоминает количество перезагрузок агента - EngineBoots и время, прошедшее с момента последней перезагрузки агента - EngineTime, в специальном кэше. В качестве ключа для поиска по этому кэшу используется идентификатор агента - EngineID.

Этот кэш нужен во-первых для того, чтобы уменьшить количество паразитных процедур обнаружения. В следующий раз можно будет взять хранящиеся в кэше значения, посчитать текущее время на агенте и отправить ему запрос. Во-вторых, приходящие ответы будут проверяться на соответствие значениям, хранящимся в кэше. Это позволяет защититься от атак повторного воспроизведения запросов, когда некто может попытаться сохранить запрос от системы управления и отправить агенту этот запрос позже. Было бы неприятно, если бы кто-то смог перехватить, например, команду SNMP SET, которая отключает порт на коммутаторе, и потом мог бы применять её впоследствии в любое время и любое количество раз. Проверка своевременности не позволит такому злоумышленнику развлекаться этой командой дольше 150 секунд.

Что произойдёт, если у нескольких устройств настроены одинаковые EngineID? В кэше будут сохраняться значения EngineBoots и EngineTime от одного устройства, а потом эти же значения будут использоваться для отправки запросов к другому устройству. Другое устройство обнаружит, что значения EngineBoots и EngineTime из полученного им запроса не его, и в соответствии с принципами защиты от атак повторного воспроизведения запросов отправит в ответ OID .1.3.6.1.6.3.15.1.1.2.0 - usmStatsNotInTimeWindows, сообщающий о том, что время из запроса не попало в приемлемое окно времени. Станция управления выполнит процедуру обнаружения и если EngineBoots из ответа второго устройства оказалось больше, то обновит значения в кэше. Если EngineBoots окажется равным хранящемуся в кэше, то сравнит EngineTime из кэша и из ответа - если EngineTime окажется больше, то обновит значение в кэше. Теперь на запросы будет отвечать только то устройство, которое больше раз перезагружалось или, при равных значениях, у которого с момента загрузки прошло больше времени. На всех остальных устройствах будет постоянно срабатывать защита от повторного воспроизведения запросов.

В случае Zabbix ситуация немного усугубляется ещё и тем, что библиотека NET-SNMP - однопоточная и не предусматривает возможность сохранения и восстановления контекста библиотеки. Возможно именно поэтому Zabbix был сделан не многопоточным, а многопроцессным. В результате у каждого процесса Poller, занимающегося пассивными проверками, имеется собственный кэш библиотеки SNMP. Каждый процесс поэтому выполняет собственную процедуру обнаружения, хотя в одном из соседних процессов в кэше уже могут быть нужные актуальные данные.

Поэтому не надо удивляться тому, что утилиты командной строки snmpget и snmpwalk работают без ошибок при каждом запуске, даже если у двух устройств одинаковый EngineID. Эти утилиты при каждом запуске выполняют процедуру обнаружения, наполняют кэш полученными значениями, выполняют запрос и тут же завершаются. При завершении утилиты пропадает и её кэш.

Проблема автора, видимо, заключалась в том, что у него на двух разных устройствах оказался одинаковый EngineID. После указания опции engineIDType 3 на устройствах были установлены EngineID, сгенерированные из MAC-адресов устройств. MAC-адреса должны быть уникальными (хотя на практике иногда случаются исключения), поэтому опция решила проблему. Приведённый же в статье протокол сниффера скорее всего отобразил два разных запроса от двух разных процессов Poller, с разными кэшами библиотеки SNMP. Один процесс имел пустой кэш и отправил запрос обнаружения, а второй процесс уже обладал ранее наполненным кэшем и отправил запрос используя старые значения из кэша. Автор же статьи, скорее всего, просто не разобрался в происходящем. Во всяком случае то, что проблема исправилась после переназначения EngineID свидетельствует именно в пользу версии о двух одинаковых EngineID на разных устройствах.


2. Замена EngineID на коммутаторах D-Link
Лично мне пришлось столкнуться с проблемой одинаковых EngineID на коммутаторах. Дело в том, что идентификатор сохраняется в файле конфигурации коммутатора. Если при настройке нового коммутатора за основу взять файл конфигурации с имеющегося коммутатора, то EngineID продублируется. Для просмотра текущего значения EngineID на коммутаторах D-Link можно воспользоваться такой командой:

Код: Выделить всё

show snmp engineID
Для замены EngineID на коммутаторах D-Link используется такая команда:

Код: Выделить всё

config snmp engineID <snmp_engineID 10-64>
Некоторые модели коммутаторов D-Link поддерживают такую команду:

Код: Выделить всё

config snmp engineID default
Наконец, после замены нужно сохранить изменённый файл конфигурации:

Код: Выделить всё

save config
3. Как сгенерировать EngineID из MAC-адреса
Если посмотреть в RFC5343, 4. IANA Considerations, то можно прочитать, по какому принципу следует формировать EngineID из MAC-адреса. Чтобы сформировать EngineID на основе MAC-адреса, нам потребуется дополнительно IANA-номер, закреплённый за производителем устройств. Определить номер IANA можно запросив у устройства OID SNMPv2-MIB::sysObjectID.0 - 1.3.6.1.2.1.1.2.0 при помощи такой команды:

Код: Выделить всё

snmpget -On -v 2c -c public 192.168.0.2 1.3.6.1.2.1.1.2.0
.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.171.10.101.1
В выводе команды я подсветил IANA-номер, закреплённый за производителем D-Link. Если перевести число 171 в шестнадцатеричную систему счисления, то получим число AB. Первые четыре октета представляют собой именно это число, но с единичным старшим битом:
80 00 00 AB

Дальше следует один октет, в котором закодирован тип остальной части идентификатора. Если EngineID формируется на основе MAC-адреса, то этот октет будет иметь такое значение:
03

Наконец, оставшиеся 6 октетов будут соответствовать октетам MAC-адреса. Например:
28 10 7B 01 2B 7B

Итак, коммутатору D-Link с MAC-адресом 28:10:7B:01:2B:7B будет соответствовать следующий EngineID:
80 00 00 AB 03 28 10 7B 01 2B 7B

4. Диагностика проблем
Для диагностики подобных проблем можно просмотреть ветку 1.3.6.1.6.3.10.2.1:

Код: Выделить всё

snmpwalk -v 2c -c public 127.0.0.1 1.3.6.1.6.3.10.2.1
SNMP-FRAMEWORK-MIB::snmpEngineID.0 = Hex-STRING: 80 00 1F 88 80 F3 F2 FA 22 48 AF 91 54 00 00 00 00
SNMP-FRAMEWORK-MIB::snmpEngineBoots.0 = INTEGER: 72
SNMP-FRAMEWORK-MIB::snmpEngineTime.0 = INTEGER: 6 seconds
SNMP-FRAMEWORK-MIB::snmpEngineMaxMessageSize.0 = INTEGER: 1500

В выводе команды можно увидеть текущие значения EngineID, EngineBoots и EngineTime.
Вот так поменялся EngineID после добавления опции engineIDType 3 в /etc/snmp/snmpd.conf:

Код: Выделить всё

snmpwalk -v 2c -c public 127.0.0.1 1.3.6.1.6.3.10.2.1
SNMP-FRAMEWORK-MIB::snmpEngineID.0 = Hex-STRING: 80 00 1F 88 03 00 1D 60 01 2B 7B
SNMP-FRAMEWORK-MIB::snmpEngineBoots.0 = INTEGER: 1
SNMP-FRAMEWORK-MIB::snmpEngineTime.0 = INTEGER: 3 seconds
SNMP-FRAMEWORK-MIB::snmpEngineMaxMessageSize.0 = INTEGER: 1500
Как можно заметить, количество загрузок агента EngineBoots уменьшилось - это произошло потому что изменился EngineID и отсчёт был начат с начала.

Дополнительно в диагностике может помочь ветка 1.3.6.1.6.3.15.1.1:

Код: Выделить всё

snmpwalk -v 2c -c public 127.0.0.1 1.3.6.1.6.3.15.1.1
SNMP-USER-BASED-SM-MIB::usmStatsUnsupportedSecLevels.0 = Counter32: 0
SNMP-USER-BASED-SM-MIB::usmStatsNotInTimeWindows.0 = Counter32: 0
SNMP-USER-BASED-SM-MIB::usmStatsUnknownUserNames.0 = Counter32: 0
SNMP-USER-BASED-SM-MIB::usmStatsUnknownEngineIDs.0 = Counter32: 0
SNMP-USER-BASED-SM-MIB::usmStatsWrongDigests.0 = Counter32: 0
SNMP-USER-BASED-SM-MIB::usmStatsDecryptionErrors.0 = Counter32: 0

Здесь можно увидеть, сколько раз к агенту обращались с неподдерживаемым уровнем безопасности, в скольких запросах встречалось неприемлемое время, сколько раз обращались с неизвестными именами пользователя или чужими значениями EngineID, сколько раз происходили ошибки аутентификации и сколько раз не удавалось расшифровать данные из запроса.

В следующей заметке я расскажу о более глубоких проблемах, возникших при внедрении SNMPv3.
количество слов: 436
Ответить Вложения 25 Пред. темаСлед. тема

Вернуться в «Установка Заббикс и Дополнений»