Настройка snmp zabbix ubuntu

Обновлено: 06.07.2024

Для передачи трапов в Zabbix будем использовать snmptt.

Установим необходимые сервисы:

Отредактируем конфигурационные файлы /etc/default/snmpd.conf или файл /etc/default/snmptrapd.conf

Заменим параметр TRAPDRUN на yes.

Отредактируем конфигурационный файл /etc/snmp/snmptrapd.conf

Укажем имя сообщества для трапов public и укажем обработчик трапов:

authCommunity log,execute,net public

traphandle default snmptthandler

Отредактируем конфигурационный файл /etc/snmp/snmptt.ini

date_time_format = %H:%M:%S %Y/%m/%d

log_enable = 1

log_file = /var/log/snmptt/snmptt.log

В конце файла пропишем путь к конфигурационном файлу с описание трапов UserGate.

Теперь известные трапы будут логироваться в файл /var/log/snmptt/snmptt.log

Неизвестные трапы в файл /var/log/snmptt/snmpttunknown.log

Отредактируем конфигурационный файл /etc/zabbix/zabbix_server.conf

Создадим каталоги (если не были установлены ранее)

Установим стандартные mibs в систему из репозитария (если не было установлено ранее).

Выполним конвертацию из mib в conf

Должны получить результат

Total translations: 19

Successful translations: 19

Failed translations: 0

Отформатируем трапы , чтобы они распознавались ZABBIX' ом . Изменим /usr/local/etc/snmp/UG.conf

Заменяем FORMAT на FORMAT ZBXTRAP $aA

Если в системе используется iptables, то разрешим указанной ниже командой прием udp пакетов на порт 162 и сохраним добавленное правило чтобы оно не сбросилось после перезапуска системы:

Перезапустим службы чтобы применить изменения:

Проверим, что snmptrapd слушает на порту 162

В Веб-консоли UserGate в разделе Диагностика и мониторинг - SNMP создадим SNMP правило


Где 192.168.110.68 IP адрес сервера ZABBIX. Во вкладке События добавим необходимые трапы.

В Веб-интерфейсе ZABBIX создадим для примера элемент данных с типом SNMP trap

Вы возможно захотите использовать 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).

Если выполняется мониторинг устройств по SNMPv3, убедитесь что msgAuthoritativeEngineID (также известное как snmpEngineID или “Engine ID”) никогда не будет общим для двух и более устройств. Согласно RFC 2571 (раздел 3.1.1.1) оно должно быть уникальным для каждого устройства.

Настройка мониторинга по SNMP

Для начала мониторинга устройства по SNMP, должны быть выполнены следующие шаги:

Шаг 1

Создайте узел сети для устройства с SNMP интерфейсом.

Введите IP адрес. Вы можете использовать один из поставляемых шаблонов SNMP (Template SNMP Device и другие), которые автоматически добавят некоторый набор элементов данных. Тем не менее, шаблон может быть не совместим с узлом сети. Нажмите на Добавить для сохранения узла сети.

SNMP проверки не используют Порт агента, он игнорируется.
Шаг 2

Узнайте строку SNMP (или OID) элемента данных, которую вы хотите мониторить.

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

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

Шаг 3

Создайте элемент данных для мониторинга.


Все обязательные поля ввода отмечены красной звёздочкой.

Теперь сохраните элемент данных и перейдите в МониторингПоследние данные, чтобы увидеть ваши данные SNMP!

Обратите внимание на специфичные опции доступные только для SNMPv3 элементов данных:

ПараметрОписание
Имя контекста Введите контекстное имя для определения элемента данных в SNMP подсети.
Имя контекста поддерживается для SNMPv3 элементов данных с Zabbix 2.2.

В случае некорректных учётных данных SNMPv3 (имя безопасности, протокол/фраза-пароль аутентификации, протокол безопасности) Zabbix получит ERROR от net-snmp, за исключением ошибочного Фразы-пароль безопасности, в этом случае Zabbix получит ошибку ВРЕМЕНИОЖИДАНИЯ от net-snmp.

При изменениях в Протокол аутентификации, Фраза-пароль аутентификации, Протокол безопасности или Фраза-пароль безопасности, чтобы эти изменения применились, необходимо перезапустить сервер/прокси.
Пример 1
ПараметрОписание
Community public
OID 1.2.3.45.6.7.8.0 (или .1.2.3.45.6.7.8.0)
Ключ <Уникальная строка, которая используется как ссылка в триггерах>
Например, “my_param”.

Обратите внимание, что OID можно задать в числовом или строковом представлении. Тем не менее, в некоторых случаях, строковый OID должен быть сконвертирован в числовое представление. Для этого можно использовать утилиту snmpget:

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

Пример 2

Мониторинг времени работы:

ПараметрОписание
Community public
Oid MIB::sysUpTime.0
Ключ router.uptime
Тип информации Числовой (с плавающей точкой)
Единица измерения uptime
Множитель 0.01

Обработка массовых 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 пакетов, чем скорее ограничение устройства.

Если, однако, устройство не может обрабатывать массовые запросы корректно и по другим причинам, начиная с Zabbix 2.4 имеется настройка “Использовать массовые запросы” у каждого интерфейса, которая позволяет отключить массовые запросы у этого устройства.

Начнем с назначения протокола SNMPv3, и особенностей его использования. Задачи SNMP – мониторинг сетевых устройств, и элементарное управление, с помощью отправки на них простых команд (например, включение и отключение сетевых интерфейсов, или перезагрузка устройства).

Главное отличие протокола SNMPv3 от его предыдущих версий, это классические функции безопасности 1, а именно:

  • аутентификация (Authentication), определяющая, что запрос получен от доверенного источника;
  • шифрование (Encryption), для предотвращения раскрытия передаваемых данных при их перехвате третьими лицами;
  • целостность (Integrity), то есть гарантия того, что пакет не был подделан при передаче.

SNMPv3 вводит понятие уровней безопасности — допустимых уровней безопасности, определяющих настройку оборудования и поведение SNMP-агента объекта мониторинга. Сочетание модели безопасности и уровня безопасности определяет, какой механизм безопасности используется при обработке пакета SNMP [4].

В таблице описаны комбинации моделей и уровней безопасности SNMPv3 (первые три столбца я решил оставить как в оригинале):


Соответственно, мы будем использовать SNMPv3 в режиме аутентификации с применением шифрования.

Настройка SNMPv3

Мониторинг сетевого оборудования предполагает одинаковую настройку протокола SNMPv3 и на сервере мониторинга, и на наблюдаемом объекте.

Начнем с настройки сетевого устройства Cisco, его минимально необходимая конфигурация выглядит следующим образом (для конфигурирования используем CLI, имена и пароли я упростил во избежание путаницы):


Первая строка snmp-server group – определяет группу SNMPv3-пользователей (snmpv3group), режим чтения (read), и право доступа группы snmpv3group на просмотр определенных веток MIB-дерева объекта мониторинга (snmpv3name далее в конфигурации задает, к каким веткам MIB-дерева группа snmpv3group сможет получить доступ).

Вторая строка snmp-server user – определяет пользователя snmpv3user, его принадлежность к группе snmpv3group, а так же применение аутентификации md5 (пароль для md5 — md5v3v3v3) и шифрования des (пароль для des — des56v3v3v3). Разумеется, вместо des лучше использовать aes, здесь я его привожу просто для примера. Так же при определении пользователя можно добавить список доступа (ACL), регламентирующий IP-адреса серверов мониторинга, имеющих право осуществлять мониторинг данного устройства – это так же best practice, но я не буду усложнять наш пример.

Третья строка snmp-server view определяет кодовое имя, которое задает ветки MIB-дерева snmpv3name, чтобы их могла запрашивать группа пользователей snmpv3group. ISO, вместо строгого определения какой-то одной ветки, позволяет группе пользователей snmpv3group получать доступ ко всем объектам MIB-дерева объекта мониторинга.

Аналогичная настройка оборудования Huawei (так же в CLI) выглядит следующим образом:


После настройки сетевых устройств, необходимо проверить наличие доступа с сервера мониторинга по протоколу SNMPv3, я воспользуюсь snmpwalk:



Более наглядный инструмент для запроса конкретных OID-объектов, с использованием MIB-фалов – snmpget:


Теперь перейдем к настройке типового элемента данных для SNMPv3, в рамках Zabbix-шаблона. Для простоты и независимости от MIB, я использую цифровые OID:


Я использую в ключевых полях пользовательские макросы, поскольку они будут одинаковы для всех элементов данных в шаблоне. Задавать их можно в рамках шаблона, если в Вашей сети у всех сетевых устройств параметры SNMPv3 одинаковы, или в рамках узла сети, если параметры SNMPv3 для разных объектов мониторинга отличаются:


Обратите внимание, система мониторинга располагает только именем пользователя, и паролями для аутентификации и шифрования. Группа пользователей и область MIB-объектов, к которым разрешен доступ, задается на объекте мониторинга.
Теперь перейдем к наполнению шаблона.

Шаблон опроса в Zabbix

Простое правило при создании любых шаблонов опроса – делать их максимально подробными:


Я уделяю большое внимание инвентаризации, чтобы с большой сетью было удобнее работать. Об этом немного позднее, а пока – триггеры:


Для удобства визуализации триггеров в их названия заложены системные макросы , чтобы на дашборде в разделе алёртинга выводились не только имена устройств, но и IP-адреса, хотя это больше вопрос удобства, чем необходимости. Для определения недоступности устройства, помимо обычного echo-запроса, я использую проверку на недоступность узла по протоколу SNMP, когда объект доступен по ICMP, но не отвечает на SNMP-запросы – такая ситуация возможна, например, при дублировании IP-адресов на разных устройствах, из-за некорректно настроенных межсетевых экранов, или неверных настроек SNMP на объектах мониторинга. Если использовать проверку доступности узлов только по ICMP, в момент расследования инцидентов в сети, данных мониторинга может не оказаться, поэтому их поступление нужно контролировать.

Перейдем к обнаружению сетевых интерфейсов – для сетевого оборудования это самая важная функция мониторинга. Поскольку на сетевом устройстве могут быть сотни интерфейсов, необходимо фильтровать ненужные, чтобы не загромождать визуализацию и не захламлять базу данных.

Я использую стандартную функцию обнаружения для SNMP, с большим количеством обнаруживаемых параметров, для более гибкой фильтрации:



При таком обнаружении, можно фильтровать сетевые интерфейсы по их типам, пользовательским описаниям «description», и административным статусам портов. Фильтры и регулярные выражения для фильтрации в моем случае выглядят следующим образом:



При обнаружении будут исключены следующие интерфейсы:

  • выключенные вручную (adminstatus<>1), благодаря IFADMINSTATUS;
  • не имеющие текстового описания, благодаря IFALIAS;
  • имеющие в текстовом описании символ *, благодаря IFALIAS;
  • являющиеся служебными или техническими, благодаря IFDESCR (в моем случае, в регулярных выражениях IFALIAS и IFDESCR проверяются одним регулярным выражением alias).

Итоги мониторинга

Для начала – инвентаризация небольшой сети:


Если подготовить шаблоны для каждой серии сетевых устройств – можно добиться удобной для анализа компоновки сводных данных по актуальному ПО, серийным номерам, и оповещении о приходе в серверную уборщицы (по причине малого Uptime). Выдержка моего списка шаблонов ниже:


А теперь – главная панель мониторинга, с распределенными по уровням важности триггерами:


Благодаря комплексному подходу к шаблонам для каждой модели устройств в сети, можно добиться того, что в рамках одной системы мониторинга будет организован инструмент для прогнозирования неисправностей и аварий (при наличии соответствующих датчиков и метрик). Zabbix хорошо подходит для мониторинга сетевых, серверных, сервисных инфраструктур, и задача обслуживания сетевого оборудования наглядно демонстрирует её возможности.

Хотели бы вы узнать, как контролировать Linux-компьютер с помощью SNMP? В этом уроке мы расскажем вам, как установить SNMP на Ubuntu и как настроить сервер Zabbix для мониторинга Linux-компьютера без необходимости установки агента Zabbix.

Список оборудования:

В следующем разделе представлен список оборудования, используемого для создания этого учебника Zabbix.

Все перечисленные выше аппаратные средства можно найти на веб-сайте Amazon.

Zabbix Playlist:

На этой странице мы предлагаем быстрый доступ к списку видеороликов, связанных с установкой Zabbix.

Не забудьте подписаться на наш канал YouTube, названный FKIT.

Учебное пособие Zabbix:

На этой странице мы предлагаем быстрый доступ к списку руководств, связанных с установкой Zabbix.

Учебник - NTP на Ubuntu Linux

Во-первых, мы собираемся настроить систему на использование правильной даты и времени с использованием NTP.

На консоли Linux используйте следующие команды, чтобы установить правильный часовой пояс.

Установите пакет Ntpdate и установите правильную дату и время сразу.

Команда Ntpdate использовалась для установки правильной даты и времени с использованием сервера: pool.ntp.br

Давайте установим службу NTP.

NTP - это сервис, который будет поддерживать обновление нашего сервера.

Используйте дату команды, чтобы проверить дату и время, настроенные на вашем Ubuntu Linux.

Если система указала правильную дату и время, это означает, что вы выполнили все шаги правильно.

Учебник - Установка SNMP на Ubuntu

Теперь нам нужно установить и настроить службу SNMP на Ubuntu Linux.

На консоли Linux используйте следующие команды для установки необходимых пакетов.

Теперь вы должны найти местоположение файла snmpd.conf в вашей системе.

После обнаружения вам нужно отредактировать файл snmpd.conf.

Вот исходный файл, перед нашей конфигурацией и без комментариев.

Вот новый файл с нашей конфигурацией.

Сообщество GokuBlack имеет разрешение только на чтение на сервере Ubuntu.

Контактное лицо, ответственное за этот Linux, было настроено как Zamasu.

Расположение оборудования было настроено как IT-комната Вселенной 10.

Вы также должны перезапустить SNMP вручную и проверить статус службы.

Ниже приведен пример вывода статуса службы SNMP

Вы успешно установили службу SNMP Ubuntu.

Вы успешно настроили службу SNMP Ubuntu.

Чтобы проверить конфигурацию SNMP, используйте следующие команды.

Вот небольшой пример вывода SNMPWALK.

Поздравляем! вы установили службу SNMP на компьютер под управлением Ubuntu Linux.

Теперь вы можете использовать панель инструментов Zabbix для добавления этого компьютера в службу мониторинга сети.

Учебник - Zabbix Monitor Linux с использованием SNMP

Теперь нам нужно получить доступ к панели мониторинга сервера Zabbix и добавить компьютер Linux в качестве хоста.

Откройте браузер и введите IP-адрес вашего веб-сервера plus / zabbix.

В нашем примере в браузере был введен следующий URL:

На экране входа в систему используйте имя пользователя по умолчанию и пароль по умолчанию.

• Имя пользователя по умолчанию: Admin
• Пароль по умолчанию: zabbix

zabbix login

После успешного входа в систему вы будете отправлены на панель инструментов Zabbix.

zabbix dashboard

На экране панели инструментов откройте меню «Конфигурация» и выберите параметр «Хост».

zabbix add host

В правом верхнем углу экрана нажмите кнопку «Создать хост».

Zabbix Create Host

На экране конфигурации хоста вам нужно будет ввести следующую информацию:

• Имя хоста - введите имя хоста для идентификации сервера Linux.
• Видимое имя хоста - повторите имя хоста.
• Новая группа - введите имя для идентификации группы подобных устройств.
• Интерфейс агента - нажмите кнопку «Удалить».
• Интерфейс агента - введите IP-адрес сервера Linux.

Вот исходное изображение, перед нашей конфигурацией.

zabbix Cisco - Antes

Вот новое изображение с нашей конфигурацией.

Zabbix Linux Host SNMP

Затем нам нужно настроить сообщество SNMP, которое Zabbix будет использовать для подключения на компьютере Linux.

Откройте вкладку «Макросы» в верхней части экрана.

Создайте макрос с именем:

Макрос должен быть сообществом SNMP Linux Computer.

Zabbix SNMP Macro Linux

Затем нам нужно связать хост с определенным шаблоном сетевого монитора.

По умолчанию Zabbix поставляется с большим количеством шаблонов мониторинга.

Откройте вкладку «Шаблоны» в верхней части экрана.

Zabbix Linux Template SNMP

Через несколько минут вы сможете увидеть исходный результат на панели инструментов Zabbix.

Окончательный результат займет не менее одного часа.

По умолчанию Zabbix будет ждать 1 час, чтобы узнать количество интерфейсов, доступных на компьютере Linux.

По умолчанию Zabbix будет ждать 1 час до сбора информации от сетевых интерфейсов.

Чтобы проверить вашу конфигурацию, откройте меню «Мониторинг» и нажмите «Графы».

Подождите 1 час, прежде чем пытаться получить доступ к графику компьютера Linux.

Zabbix graphic

В правом верхнем углу экрана выберите группу с именем ALL.

Выберите имя хоста компьютера Linux.

Выберите граф с именем: CPU UTILIZATION

linux memory utilization

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

Zabbix linux monitor memory

Поздравляем! Вы настроили сервер Zabbix для мониторинга Linux-сервера с использованием SNMP.

  • CentOS Linux release 7.5.1804 (Core)
  • net-snmp, Version : 5.7.2
  • snmptt, Version : 1.4
  • ssmtp, Version : 2.64
  • Zabbix, Version : 3.4.11

Предполагаем, что Zabbix уже установлен и настроен.

Включаем поддержку SNMP TRAP в Zabbix и указываем лог файл из которого Zabbix будет брать данные. Лог файл должен иметь определённый формат, его подготовит snmptt.

/etc/zabbix/zabbix_server.conf

В данном случае это АТС Avaya (Nortel) CS1000E.

Элемент данный Zabbix для получения SNMP TRAP

Элемент данный Zabbix для получения SNMP TRAP

Тип: SNMP Trap
Ключ: snmptrap.fallback
Тип информации: Журнал (лог)
Формат времени в журнале (логе): hh:mm:sszyyyy/MM/dd

Отключаем авторизацию (на ваше усмотрение) и настраиваем обработчик SNMP TRAP событий, в нашем случае snmptt.

/etc/snmp/snmptrapd.conf

Указываем путь к временному файлу, в который snmptt будет писать подготовленные данные для Zabbix. Настраиваем формат даты и времени.

/etc/snmp/snmptt.ini

Незабываем настроить logrotate для zabbix_traps.tmp.

/etc/logrotate.d/snmptt

Настраиваем правила по умолчанию преобразования SNMP TRAP

Полученные от snmptrapd трапы преобразуем в понятный Zabbix формат.

/etc/snmp/snmptt.conf

Правило преобразования по умолчанию.

И так, мы всё настроили. Теперь отправим с нашего оборудования TRAP (в моём случае Avaya CS1000E версии 7.65) и посмотрим в каком формате он придёт и как отобразится в логах и в Zabbix.

Отправился TRAP с информацией об удачном сохранении конфигурации АТС.

Смотрим как TRAP отображается в Zabbix

Zabbix. Смотрим SNMP TRAP

Создадим в snmptt правило преобразования, которое уберёт лишние данные.

Анализируем лог файл для Zabbix подготовленный snmptt.

/var/log/zabbix/zabbix_traps.tmp

Приведём это к более читаемому виду:

Нас интересует:

Создание правил преобразования

Данные из OID записываются в переменные и далее мы уже оперируем переменными.

SNMP OID и переменные

SNMP OID и переменные

/etc/snmp/snmptt.conf

Перезапускам сервис snmptt.

Результаты настройки правил snmptt

Отправляем новый TRAP с оборудования и смотрим на результаты.

/var/log/zabbix/my_zabbix_traps.tmp

Как видно, в логе который анализирует Zabbix, осталась только нужная информация.

А вот как эта информация выглядит в Zabbix.

Zabbix. Смотрим SNMP TRAP’ы в меню «Последние данные»

Zabbix. Смотрим SNMP TRAP’ы в меню «Последние данные»

Каждый раз, когда приходит TRAP, snmptt используя функция EXEC запускает данный скрипт и скрипт, используя утилиту ssmtp отправляет оповещение на E-mail.

Настройка ssmtp

/etc/ssmtp/ssmtp.conf

Скрипт отправки на E-mail

/etc/snmp/trapemail

Присваиваем скрипту права на исполнение.

Результат работы скрипта

TRAP в E-Mail

Похожие записи.

Андрей Торженов

В профессиональной сфере занимаюсь всем, что связанно с IT. Основная специализация - VoIP и сети передачи данных. Стараюсь не заниматься Windows серверами (но иногда приходится) и 1С.

Latest posts by Андрей Торженов (see all)

Запись опубликована 28/07/2018 автором Андрей Торженов в рубрике Софт с метками E-mail, SNMP, Zabbix.

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Вы можете авторизоваться используя Вашу учётную запись из социальных сетей

Оповещение по e-mail о новых комментариях.
Также вы можете не оставляя комментарий подписаться но новые комментарии.

Читайте также: