1. Проверку требований
2. Задание настроек БД
3. Задание свойств сервера (адрес, порт)
4. Сохранение настроек на сервере

Начало работы c Zabbix

Основные определения

Host - сетевое устройство, которые вы хотите мониторить, с IP/DNS.
Hostgroup - логическая группировка узлов сети; они могут содержать узлы сети и шаблоны. Узлы сети и шаблоны в группе узлов сети никаким образом не связаны с друг другом. Группы узлов сети используются при назначении прав доступа к узлам сети различным группам пользователей.
Item -элемент данных. Конкретная часть данных, которую вы хотите получать от узла сети, метрические данные.
Trigger – триггер. |логическое выражение которое определяет порог проблемы и используется для “вычисления” данных полученных элементами данных. При получении данных превышающих порог, триггеры переходят из состояния "Ок" в состояние "Проблема". При получении данных ниже порога, триггеры остаются в/возвращаются в состояние "Ок".
Event - одиночное возникновение того, что заслуживает внимания, такого как изменение состояния триггера или обнаружение/авто-регистрация агента
Action - предопределенные средства реагирования на событие.Действие состоит из операций (например отправка оповещений) и условий (когда осуществляется операция)
Escalation - пользовательский сценарий для выполнения операций в действии; последовательность отправки оповещений/выполнений удаленных команд
Media - способ доставки оповещений; канал доставки
Remote command - предопределенная команда, которая будет автоматически выполнена на наблюдаемом узле сети при некоторых условиях
Template - набор сущностей (элементы данных, триггеры, графики, комплексные экраны, правила низкоуровневого обнаружения) готовые к присоединению к одному или нескольким узлам сети Задача шаблонов повысить скорость развертывания задач мониторинга узла сети; кроме того делать более простым применение массовых изменений к задачам наблюдения. Шаблоны соединяются напрямую с отдельными узлами сети.
Application - сгрупированные элементы данных в некую логическую группу
Web scenario - один или несколько запросов HTTP для проверки доступности веб сайта

Быстрый старт

Самый простой способ проверить корректность установки и запуска мониторинга – настроить простую проверку характеристик удаленного хоста, например проверку доступности агента (agent.ping ), а также уведомление пользователя в случае недоступности.

Для этого необходимо:

1. Создать пользователя. По умолчанию пользователю не задается предпочтительный способ доставки сообщений, поэтому необходимо его задать, например email для уведомлений по электронной почте. Также пользователю необходимо задать права на чтение для сервера, оповещения о недоступности которого пользователь будет получать. В противном случае Zabbix не сможет отправить оповещение
2. Добавить удаленный хост, указав его имя, адрес, агентский порт и статус. Также его можно включить в одну или несколько групп серверов.
3. Создать элемент данных - можно создать вручную или на основе шаблона. При ручной настройке необходимо указать название, тип, название ключа, тип возвращаемых данных.
4. Добавить триггер – можно вручную задать выражение для проверки элемента данных или использовать триггер из шаблона.
5. Настроить систему оповещений для сервера. Для оповещений по электронной почте необходимо указать параметры почтового сервера и аккаунта, от имени которого будут выполняться уведомления.
6. Создать действие, определив для него операцию оповещения пользователя.

После проделанных шагов достаточно остановить агента на удаленном хосте, после чего мы получим уведомление на адрес электронной почты, также мы увидим запись о произошедшем событии в панели управления Zabbix на вкладке Latest data – Events.

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

Видеоматериал

Небольшой видеообзор системы мониторинга Zabbix:

• Zabbix - официальный сайт
• Zabbix documentation - документация

В любой сети, где есть больше, чем один сервер, очень полезно бывает иметь перед глазами полную картину происходящего. В крупных сетях, где количество хостов переваливает за несколько десятков, следить за каждым в отдельности - непосильная задача для администраторов. Для облегчения задачи наблюдения применяются системы мониторинга, и я расскажу об одной из них, которой на Хабре не посвящено ни одной полноценной статьи.

И так, встречайте: Zabbix . Система состоит из нескольких частей, и при большой нагрузке и наблюдении за очень большим количеством хостов позволяет разнести эти части на несколько раздельных машин.

Zabbix состоит из

• собственно сервера мониторинга, который выполняет периодическое получение данных, обработку, анализ и запуск скриптов оповещения
• базы данных (MySQL, PostgreSQL, SQLite или Oracle)
• веб-интерфейса на PHP
• агента - демона, который запускается на отслеживаемых объектах и предоставляет данные серверу. Агент опционален, мониторинг можно производить не только с помощью него, но и по SNMP (версий 1, 2, 3), запуском внешних скриптов, выдающих данные, и несколько видов предопределенных встроенных проверок, таких как ping, запрос по http, ssh, ftp и другим протоколам, а так же замер времени ответа этих сервисов.

В рамках вводной статьи стоит рассказать о том, какая модель сети используется в Zabbix, чтобы лучше понимать, что к чему и получить представление о возможностях системы.

Основная логическая единица - Узлы сети (host), сервера, находящиеся под наблюдением. Каждому серверу присваивается описание и адрес (dns или ip, можно оба, причем с возможностью выбирать, что использовать для соединения).

Узлы объеднияются в группы , например веб-сервера или сервера баз данных. Группы служат для вывода только определенных серверов при наблюдении.

Каждый узел имеет несколько Элементов данных (items) - параметров, за которыми ведется мониторинг. К примеру, на всех серверах у меня есть параметр ping, (он получается с помощью встроенной проверки), который равняется 1, если ответ на последний ping-запрос был получен, иначе 0. А на одном из серверов у меня есть параметр «количество пользователей онлайн», который собирается самописным скриптом из базы данных сайта. Для каждого элемента данных можно указать свой период обновления, способ хранения(сам параметр или скорость его изменения), множитель, временной интервал сбора (например только в рабочее время).

Создавать элементы данных для каждого из множества серверов - сложно, поэтому можно создать узлы-шаблоны . Эти узлы тоже содержат элементы данных, но они не мониторятся напрямую. Вместо этого реальный хост связывается с одним или несколькими шаблонами, и все параметры шаблона автоматически наследуются хостом. Так, элемент ping у меня хранится именно в шаблоне, и я просто связываю все хосты с шаблоном template_ping.

Человек - не робот, и следить за тысячами параметров и думать, не выходит ли это значение за допустимые границы, просто нереально. Но и тут Zabbix предоставляет гибкие возможности по настройке условий-триггеров , которые включаются при авариях и неполадках, и система начинает моргать лампочками (на самом деле красными квадратиками) и изо всех сил пытается показать администратору, что что-то случилось. Между прочим, при включении триггера веб-интерфейс даже начинает попискивать на манер будильника, наверное, чтобы разбудить заснувших на клавиатуре наблюдателей. :) Так что колонки здесь, наверное не помешают. А в упомянутом выше моем шаблоне template_ping есть и триггер, который реагирует на отсутствие пинга больше, чем на две минуты.

А если администратора нет на месте? Ничего, Zabbix достаточно самостоятелен и сможет отправить уведомление на почту, в jabber или sms с помощью gsm-модема, или даже попытаться самостоятельно поднять упавший сервис, выполнив заранее определенные действия , которые запускаются при срабатывании определенных триггеров.

Скучно сидеть и вглядываться в квадратики и бесконечно бегающие цифры? По данным любого параметра система сможет построить график изменения, причем не за предопределенные и жестко заданные временные интервалы (вспомните mrtg/rrdtool: daily, weekly, monthly, yearly), а за любой промежуток времени с максимальным разрешением. Хотите посмотреть в деталях, как изменялась нагрузка на сервер во время хабраэффекта месяц назад? Пожалуйста, график с разрешением в 30 секунд(именно таков интервал опроса по умолчанию) к вашим услугам. Хотите общую картину? Выберите интервал в месяц и посмотрите на среднюю величину, и разброс колебаний до максимума и минимума. Сравнить? Можно создавать сложные графики, отображающие на одном поле несколько параметров, и вы сразу увидите, что пиковые значения Load Average соответствуют пикам трафика.

Для отображения логической структуры сети можно создавать карты сети , отображающие именно расположение узлов сети и связей между ними. Естественно, состояние узлов (доступен или нет) отображается и на карте.

Кроме того, для более удобного обзора есть комплексные отчеты , которые позволяют на одном экране просматривать сразу несколько сущностей - графики, данные, триггеры…

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

Скриншоты - с официального сайта Zabbix, и остальные можете посмотреть именно там (а их там много) -

Примеры применения

При выборе системы мониторинга ИТ-инфраструктуры предприятия нужно учесть ряд факторов: в первую очередь оценить соответствие функционала системы мониторинга вашим техническим и бизнес-требованиям и рассмотреть особенности развёртывания и сопровождения, чтобы подобрать инструмент, соответствующий вашей инфраструктуре и уровню компетенции ИТ-специалистов.

В этой статье мы рассмотрим особенности, различия и схожие черты двух популярных систем мониторинга Zabbix vs Nagios .

Краткий обзор продуктов

Использование систем мониторинга с оборудованием NetPing

Ранее в нашем блоге мы неоднократно рассматривали возможность использования систем мониторинга Zabbix и Nagios с и компании .

Процесс подключения устройств к системам мониторинга рассматривается в следующих статьях:

Процесс организации мониторинга при помощи интеграции устройств и систем мониторинга Zabbix и Nagios рассматривается в статьях:

Процесс организации отправки пользовательских сообщений о событиях из систем мониторинга Zabbix или Nagios посредством SMS-сообщений с использованием GSM-модема встроенного в устройства рассматривается в статьях:

Также в нашем блоге доступны для более удобного добавления устройств к мониторингу в системе Zabbix и другие статьи о практическом применении интеграции системы мониторинга Zabbix с устройствами :

• Карта пользователя и уведомления от устройств NetPing в Zabbix

Достоинства и недостатки

Zabbix

Nagios

И сетевого оборудования , написанная Алексеем Владышевым.

Для хранения данных используется MySQL , PostgreSQL , SQLite или Oracle . Веб-интерфейс написан на PHP . ZABBIX поддерживает несколько видов мониторинга:

• Simple checks - может проверять доступность и реакцию стандартных сервисов, таких как SMTP или HTTP, без установки какого-либо программного обеспечения на наблюдаемом хосте.
• ZABBIX agent - может быть установлен на UNIX-подобных или Windows -хостах для получения данных о нагрузке процессора , использования сети, дисковом пространстве и т. д.
• External check - выполнение внешних программ. ZABBIX также поддерживает мониторинг через SNMP .

Энциклопедичный YouTube

• 1 / 5

  Zabbix начался в 1998 году как проект внутреннего программного обеспечения. Спустя 3 года, в 2001 году, он был выпущен публично под лицензией GPL . Прошло более трёх лет до выхода первой стабильной версии - 1.0, которая была выпущена в 2004.

  График релизов
  Дата	Релиз
  Zabbix 1.0
  1998	ПО Zabbix началось как внутренний проект в банке Алексеем Владышевым
  7 Апреля 2001	Zabbix 1.0alpha1 был выпущен с лицензией GPL
  23 Марта 2004	Выпущен Zabbix 1.0
  Zabbix 1.1
  6 Февраля 2006	Выпущен Zabbix 1.1
  Zabbix 1.4
  29 Мая 2007	Выпущен Zabbix 1.4
  Zabbix 1.6
  11 Сентября 2008	Выпущен Zabbix 1.6
  Zabbix 1.8
  7 Декабря 2009	Выпущен Zabbix 1.8
  Zabbix 2.0
  21 Мая 2012	Выпущен Zabbix 2.0
  Zabbix 2.2.1
  21 Декабря 2013	Выпущен Zabbix 2.2.1
  Zabbix 2.4.0
  11 Сентября 2014	Выпущен Zabbix 2.4.0
  Zabbix 3.0
  16 Февраля 2016	Выпущен Zabbix 3.0

  Архитектура

  • Zabbix-сервер - это ядро программного обеспечения Zabbix. Сервер может удаленно проверять сетевые сервисы, является хранилищем, в котором хранятся все конфигурационные, статистические и оперативные данные, и он является тем субъектом в программном обеспечении Zabbix, который оповестит администраторов в случае возникновения проблем с любым контролируемым оборудованием.
  • Zabbix-прокси - собирает данные о производительности и доступности от имени Zabbix-сервера. Все собранные данные заносятся в буфер на локальном уровне и передаются Zabbix-серверу, к которому принадлежит прокси-сервер. Zabbix-прокси является идеальным решением для централизованного удаленного мониторинга мест, филиалов, сетей, не имеющих локальных администраторов. Он может быть также использован для распределения нагрузки одного Zabbix-сервера. В этом случае, прокси только собирает данные, тем самым на сервер ложится меньшая нагрузка на ЦПУ и на ввод-вывод диска.
  • Zabbix-агент - контроль локальных ресурсов и приложений (таких как жесткие диски, память, статистика процессора и т. д.) на сетевых системах, эти системы должны работать с запущенным Zabbix-агентом. Zabbix-агенты являются чрезвычайно эффективными из-за использования родных системных вызовов для сбора информации о статистике.
  • Веб-интерфейс - интерфейс является частью Zabbix-сервера, и, как правило (но не обязательно), запущен на том же физическом сервере, что и Zabbix-сервер. Работает на PHP , требует веб сервер (например, Apache).

  Обзор возможностей

  • Распределённый мониторинг вплоть до 1000 узлов. Конфигурация младших узлов полностью контролируется старшими узлами, находящимися на более высоком уровне иерархии.
  • Сценарии на основе мониторинга
  • Автоматическое обнаружение
  • Централизованный мониторинг лог-файлов
  • Веб-интерфейс для администрирования и настройки
  • Отчетность и тенденции
  • SLA мониторинг
  • Поддержка высокопроизводительных агентов (zabbix-agent) практически для всех платформ
  • Комплексная реакция на события
  • Поддержка SNMP v1, 2, 3
  • Поддержка SNMP ловушек
  • Поддержка IPMI
  • Поддержка мониторинга JMX приложений из коробки
  • Поддержка выполнения запросов в различные базы данных без необходимости использования скриптовой обвязки
  • Расширение за счет выполнения внешних скриптов
  • Гибкая система шаблонов и групп
  • Возможность создавать карты сетей

  Автоматическое обнаружение

  • Автоматическое обнаружение по диапазону IP-адресов, доступным сервисам и SNMP проверка
  • Автоматический мониторинг обнаруженных устройств
  • Автоматическое удаление отсутствующих хостов
  • Распределение по группам и шаблонам в зависимости от возвращаемого результата

  Низкоуровневое обнаружение

  Низкоуровневое обнаружение может быть использовано для обнаружения и для начала мониторинга файловых систем, сетевых интерфейсов. Начиная с Zabbix 2.0, поддерживаются три встроенных механизма низкоуровневого обнаружения:

  • обнаружение файловых систем
  • обнаружение сетевых интерфейсов
  • обнаружение нескольких SNMP OID’ов

  Системные требования для установки ZABBIX-сервера

  Поддерживаемые платформы

  Платформа	ZABBIX-сервер	ZABBIX-агент
  AIX	Поддерживается	Поддерживается
  FreeBSD	Поддерживается	Поддерживается
  HP-UX	Поддерживается	Поддерживается
  Linux	Поддерживается	Поддерживается
  Mac OS X	Поддерживается	Поддерживается
  Novell Netware	-	Поддерживается
  OpenBSD	Поддерживается	Поддерживается
  SCO Open Server	Поддерживается	Поддерживается
  Solaris	Поддерживается	Поддерживается
  Tru64/OSF	Поддерживается	Поддерживается
  Windows NT 4.0, Windows 2000, Windows 2003, Windows XP, Windows Vista	-	Поддерживается

  Мониторинг был и остается важнейшей частью системного и сетевого администрирования. Но если для маленькой локальной сети зачастую достаточно время от времени смотреть логи, то в случае крупных систем приходится использовать специализированные средства. Об одном из них - Zabbix и поговорим сегодня.

  Введение

  Начнем с архитектуры. Система мониторинга Zabbix состоит из нескольких подсистем, причем все они могут размещаться на разных машинах:

  • сервер мониторинга, который периодически получает и обрабатывает данные, анализирует их и производит в зависимости от ситуации определенные действия, в основном оповещение администратора;
  • база данных - в качестве таковой могут использоваться SQLite, MySQL, PostgreSQL и Oracle;
  • веб-интерфейс на PHP, который отвечает за управление мониторингом и действиями, а также за визуализацию;
  • агент Zabbix, запускается на той машине/устройстве, с которой необходимо снимать данные. Его наличие хоть и желательно, но, если установить его на устройство невозможно, можно обойтись SNMP;
  • Zabbix proxy - используется в основном в тех случаях, когда необходимо мониторить сотни и тысячи устройств для снижения нагрузки на собственно сервер мониторинга.

  Логическая единица мониторинга - узел. Каждому узлу присваивается описание и адрес - в качестве адреса можно использовать как доменное имя, так и IP. Узлы могут объединяться в группы, к примеру группа роутеров, для удобства наблюдения. Каждому серверу соответствует несколько элементов данных, то есть отслеживаемых параметров. Поскольку для каждого сервера настраивать параметры, за которыми нужно следить, неудобно (особенно это верно для больших сетей), можно создавать узлы-шаблоны и каждому серверу или группе серверов будет соответствовать несколько шаблонов.

  В статье будут рассмотрены интересные сценарии использования Zabbix, но сначала опишем установку этого решения на RHEL-подобные системы с MySQL в качестве БД.

  Установка и первичная настройка

  Перво-наперво надо подключить репозиторий EPEL:

  # yum install http://ftp.yandex.ru/epel/6/i386/epel-release-6-8.noarch.rpm

  Затем поставить нужные пакеты:

  # yum install zabbix20-server zabbix20-agent zabbix20-web-mysql nmap httpd policycoreutils-python net-snmp net-snmp-utils # yum groupinstall "MySQL Database Client" "MySQL Database Server"

  Для чего нужен httpd и утилиты SNMP, полагаю, понятно. А вот Nmap нужен для некоторых проверок, чтобы заполнить элементы данных. Теперь необходимо настроить автозапуск служб и их запустить.

  # chkconfig httpd on # chkconfig mysqld on # chkconfig zabbix-server on # chkconfig zabbix-agent on # service mysqld start

  И конечно же, надо произвести начальную настройку MySQL.

  # mysql_secure_installation

  Затем заходим в консоль MySQL и создаем БД и пользователя:

  Mysql> CREATE DATABASE zabbix CHARACTER SET utf8; mysql> GRANT ALL PRIVILEGES ON zabbix.* TO "zabbix"@"localhost" IDENTIFIED BY "zabbixpassword";

  Теперь импортируем базы данных:

  # mysql -u zabbix -p zabbix < /usr/share/zabbix-mysql/schema.sql # mysql -u zabbix -p zabbix < /usr/share/zabbix-mysql/images.sql # mysql -u zabbix -p zabbix < /usr/share/zabbix-mysql/data.sql

  Редактируем файл конфигурации сервера Zabbix (/etc/zabbix_server.conf):

  # <...> DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=zabbix

  Слегка подкрутим конфигурацию PHP (/etc/php.ini):

  # <...> max_execution_time = 300 max_input_time = 300 post_max_size = 16M date.timezone = Asia/Omsk

  Настраиваем SELinux:

  # semanage port -a -t http_port_t -p tcp 10051 # setsebool -P httpd_can_network_connect on

  Наконец, запускаем оставшиеся службы:

  # service httpd start # service zabbix-server start # service zabbix-agent start

  В браузере подключаемся к http://server_name/zabbix и производим начальную конфигурацию фронтенда Zabbix (то есть имя БД, имя пользователя и пароль). После этого начальную настройку можно считать завершенной.

  
  
  

  Мониторинг nginx и memcache

  Для мониторинга nginx можно, разумеется, использовать самописные скрипты. Но в некоторых случаях, когда времени катастрофически не хватает, хочется найти что-нибудь готовое. В случае с nginx таким готовым решением будет набор питоновских скриптов ZTC. Для их установки сперва нужно установить некоторые пакеты:

  # yum install lm_sensors smartmontools

  Затем используй следующие команды:

  # wget https://bitbucket.org/rvs/ztc/downloads/ztc-12.02.1-1.el6.noarch.rpm # rpm -ivh --nodeps ztc-12.02.1-1.el6.noarch.rpm

  Опция —nodeps нужна по причине того, что пакет требует версию Zabbix 1.8, но ничто не мешает попробовать ZTC и на последних его версиях.

  Теперь добавим еще один конфиг nginx (/etc/nginx/conf.d/nginx_status.conf):

  Server { listen localhost; server_name nginx_status.localhost; location /server-status { stub_status on; access_log off; allow 127.0.0.1; deny all; } }

  И поправим конфиг nginx в ZTC (/etc/ztc/nginx.conf):

  # <...> proto=http host=localhost port=80 resource=/server-status

  Проверим работу скрипта ZTC:

  # /opt/ztc/bin/nginx.py ping # /opt/ztc/bin/nginx.py ping

  Если все нормально, настраиваем Zabbix-agent на нужной машине (/etc/zabbix-agentd.conf):

  # <...> UserParameter=nginx[*],/opt/ztc/bin/nginx.py $1

  Теперь нужно настроить веб-интерфейс. Для этого необходимо импортировать шаблон Template_app_nginx.xml , что лежит в /opt/ztc/templates/ . Замечу, что лежит он именно на том компьютере, где установлен ZTC, так что если у тебя на сервере нет GUI, то файл придется копировать на машину, на которой установлен браузер и с которой собственно и ведется мониторинг.

  Не стоит забывать, что в этом наборе скриптов кроме мониторинга nginx есть еще мониторинг и других приложений, таких, например, как MongoDB. Настраивается он аналогично, поэтому рассматривать его смысла нет.

  А вот для memcache среди этих скриптов нет ничего, так что придется нам его написать самим. Проверим его работо- и дееспособность:

  # echo -e "stats\nquit" | nc -q2 127.0.0.1 11211

  В ответ должны посыпаться статистические данные. Теперь пишем скрипт-однострочник /etc/zabbix/scripts/memcache.sh (при этом не забываем сделать его исполняемым):

  #!/bin/bash echo -e "stats\nquit" | nc 127.0.0.1 11211 | grep "STAT $1 " | awk "{print $3}"

  Как и в случае с nginx, правим конфиг Zabbix-agent (/etc/zabbix-agentd.conf) и не забываем его рестартовать:

  # <...> UserParameter=memcache[*],/etc/zabbix/scripts/memcache.sh $1

  Берем шаблон отсюда и импортируем его в веб-интерфейс.

  
  
  

  INFO

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

  Мониторинг различных устройств с помощью Zabbix

  В основном Zabbix используется для мониторинга серверов, но помимо собственно серверов есть еще множество других устройств, которые также нуждаются в мониторинге. Далее будет описана настройка Zabbix для мониторинга некоторых из них.

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

  • включить поддержку SNMP на устройствах. Не забывай о безопасности - по возможности используй третью версию протокола, устанавливай авторизацию и изменяй имена community;
  • добавить нужные элементы в Zabbix. Одному параметру SNMP соответствует один элемент; также нужно указать OID (идентификатор параметра) версию SNMP и, в зависимости от нее, параметры авторизации;
  • добавить триггеры на нежелательное изменение параметров.

  У каждой железки могут быть десятки отслеживаемых параметров, и вручную их добавлять замучаешься. Но в Сети можно найти множество шаблонов, которые уже содержат в себе все необходимые элементы, триггеры и графики, - остается только их импортировать и подключить нужные хосты. Также существуют стандартные OID, которые описаны в RFC. К таковым относится, например, uptime с OID .1.3.6.1.2.1.1.3.0 или - для коммутаторов - статус порта с OID .1.3.6.1.2.1.2.2.1.8.X, где X - номер порта.

  Существует онлайн-генератор шаблонов , который генерирует их на основе стандартных OID. В основном он предназначен для железа от Cisco, но ничто не мешает его использовать для другого оборудования.

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

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

  SNMP Traps в Zabbix

  Протокол SNMP, помимо пассивного получения данных устройства, поддерживает также и активную их рассылку со стороны устройства. В англоязычной документации это именуется SNMP Trap, в русскоязычной же используется термин SNMP-трап. Трапы удобны, когда нужно срочно уведомить систему мониторинга об изменении какого-либо параметра. Для отлова трапов в Zabbix имеется три способа (во всех трех случаях нужен еще и демон snmptrapd):

  • с помощью SNMPTT (SNMP Trap Translator);
  • используя скрипт на Perl;
  • используя скрипт на bash.

  Далее описан первый вариант. Прежде всего, не забываем разрешить 161-й порт UDP и по необходимости временно отключить SELinux. Затем ставим нужные пакеты (предполагается, что репозиторий EPEL у тебя подключен):

  # yum install net-snmp net-snmp-utils net-snmp-perl snmptt

  Настраиваем snmptrapd (/etc/snmp/snmptrapd.conf):

  DisableAuthorization yes traphandle default snmptthandler

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

  Затем настраиваем snmptt (/etc/snmp/snmptt.ini):

  # <...> net_snmp_perl_enable = 1 mibs_environment = ALL date_time_format = %H:%M:%S %Y/%m/%d

  Теперь нужно настроить шаблоны для маппинга трапов на Zabbix SNMP. Ниже будет приведен пример такого шаблона для двух видов трапов - coldStart и всех остальных (/etc/snmp/snmptt.conf).

  # <...> EVENT general .* "General event" Normal FORMAT ZBXTRAP $aA $1 EVENT coldStart .1.3.6.1.6.3.1.1.5.1.0.33 "Status Events" Normal FORMAT ZBXTRAP $aA Device reinitialized (coldStart)

  Первые две строчки описывают любые трапы, а вторая пара - конкретный трап с OID. Замечу, что для того, чтобы Zabbix ловил эти трапы, они должны быть именно в формате «ZBXTRAP адрес».

  Включаем нужные службы:

  # chkconfig snmptt on # chkconfig snmptrapd on # service snmptt start # service snmptrapd start

  Посылаем тестовые трапы и смотрим логи:

  # snmptrap -v 1 -c public 127.0.0.1 ".1.3.6.1.6.3.1.1.5.1" "0.0.0.0" 6 1 "55" .1.3.6.1.6.3.1.1.5.1 s "teststring000" # snmptrap -v 1 -c public 127.0.0.1 ".1.3.6.1.6.3.1.1.5.1" "0.0.0.0" 6 33 "55" .1.3.6.1.6.3.1.1.5.1 s "teststring000" # tail /var/log/snmptt/snmptt.log

  Если все нормально, переходим к конфигурированию Zabbix. В файле /etc/zabbix_server.conf укажем местонахождение лога и включим встроенный SNMPTrapper:

  # <...> SNMPTrapperFile=/var/log/snmptt/snmptt.log StartSNMPTrapper=1

  После этого нужно зайти в веб-интерфейс Zabbix, по необходимости добавить в узле сети интерфейс SNMP и добавить элемент для трапа. Ставим все необходимые действия, если это нужно, и проверяем, для чего точно так же создаем тестовый трап.

  
  

  INFO

  Масштабирование в Zabbix работает достаточно хорошо - при должной настройке он выдерживает 6000 узлов.
  

  Мониторинг VPN-туннелей на оборудовании Cisco

  Возникла необходимость мониторинга загрузки кучи туннелей VPN на цисках. Все хорошо, SNMP как на циске, так и на Zabbix настроен, но есть одна загвоздка - OID для каждого соединения формируются динамически, как и их списки. Это связано с особенностями протокола IPsec, в которые я вдаваться не буду - скажу лишь, что это связано с процедурой установления соединения. Алгоритм извлечения нужных счетчиков, таким образом, настолько замудрен, что реализовать его встроенными средствами Zabbix не представляется возможным.

  По счастью, имеется скрипт , который это делает сам. Его нужно скачать и закинуть в каталог ExternalScripts (в моем случае это был /var/lib/zabbixsrv/externalscripts). Проверим его работоспособность:

  # /var/lib/zabbixsrv/externalscripts/query_asa_lan2lan.pl ciscocom 192.168.10.1 ASA get RX 94.251.99.1

  Если проверка прошла успешно, применим комбинацию LLD с этим скриптом. Создаем шаблон с правилом обнаружения (OID 1.3.6.1.4.1.9.9.171.1.2.3.1.7) и двумя элементами данных с внешней проверкой и ключами ‘queryasa lan2lan.pl[«{$SNMPCOMMUNITY}», «{HOST.IP}», «ASA», «get, «RX», «{#SNMPVALUE}»]’ и ‘queryasa lan2lan.pl[«{$SNMP COMMUNITY}», «{HOST.IP}», «ASA», «get», «TX», «{#SNMPVALUE}»]’, назвав их соответственно «Incoming traffic in tunnel to {#SNMPVALUE}» и «Outgoing traffic in tunnel to {#SNMPVALUE}». После этого применяем шаблон к нужным узлам и ждем автообнаружения.

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

  Прикручиваем MIB к Zabbix

  Сам по себе Zabbix не поддерживает MIB (Management Information Base), а готовые шаблоны есть отнюдь не для всех устройств. Конечно, все OID можно добавить и вручную (с помощью snmpwalk), но это работает, только если их у тебя не очень много. Однако существует плагин для веб-интерфейса Zabbix под названием SNMP Builder, который позволяет конвертировать MIB-файлы в шаблоны и уже эти шаблоны допиливать под свои нужды. Берем его из Git-репозитория:

  # git clone https://github.com/atimonin/snmpbuilder.git

  Накладываем патч (в твоем случае, разумеется, имена каталогов могут быть другими, и подразумевается, что ты находишься в каталоге, где размещен фронтенд Zabbix - в случае с RHEL-based системами это /usr/share/zabbix):

  # patch -p1 < /home/centos/snmpbuilder/snmpbuilder-2.0.5.patch

  Копируем недостающие файлы и распаковываем картинки:

  # tar xzvf /home/centos/snmpbuilder/snmpbuilder-2.0_imgs.tar.gz # cp -r /home/centos/snmpbuilder/zabbix/* .

  По необходимости редактируем переменную MIBSALL PATH в файле snmp_builder.php . В отдельных случаях может также понадобиться слегка подправить его код, начиная со строки foreach(glob($path.»/*.mib»). Код в этом случае будет выглядеть примерно так:

  # <...> foreach(glob($path."/*.mib") as $filename){ if (preg_match("/^".preg_quote($path,"/")."\/(.+)\.mib$/",$filename,$matches)){ $result=exec("cat ".$filename."| grep -i "DEFINITIONS.*::=.*BEGIN"|awk "{print $1}""); $cmbMibs->addItem($result,$result); } }

  Теперь можно уже использовать.

  Прежде всего нужно найти MIB-файлы для твоего железа. Некоторые производители их скрывают, некоторые - нет. После того как ты их нашел, эти файлы нужно поместить в папку, которую ты указал в вышеуказанной переменной. В отдельных случаях могут возникнуть зависимости - в подобной ситуации нужно найти соответствующий MIB-файл, чтобы их разрешить. Итак, выбери шаблон, MIB-файл и укажи адрес устройства. Если все нормально, ты увидишь список OID, которые нужно затем выбрать для добавления к шаблону. После выбора нужно нажать кнопку «Сохранить». Добавленные элементы появятся в указанном шаблоне.

  В отдельных ситуациях нужно отредактировать новодобавленные элементы, поскольку по дефолту интервал обновления 60 секунд, что в случае, например, с именем хоста не имеет особого смысла - лучше в подобных ситуациях ставить его равным 86 400 секунд (24 часа). Для счетчиков же нужно изменить формат хранения на «Дельта в секунду». Кроме того, с некоторыми элементами нужно настроить еще и преобразование их значений в удобочитаемый вид. Для этого перейди в «Администрирование -> Общие» и в выпадающем меню выбери «Преобразование значений», а там уже добавляй его.

  В общем-то, модуль мы настроили - все остальное ты уже настраивай самостоятельно.
  

  Версии протокола SNMP

  Существует несколько версий SNMP. Первая версия появилась в 1988 году и на данный момент, хоть и считается устаревшей, все еще очень популярна. Версия 2 (фактически сейчас под ней подразумевают версию 2c) появилась в апреле 1993 года. Она была несовместима с первой версией. Основные новшества второй версии протокола заключались в обмене информацией между управляющими компьютерами. Кроме того, появилась команда получения сразу нескольких переменных (GetBulk).

  Во времена разработки первой версии мало кто заботился о безопасности, поэтому о какой-либо защите в SNMPv1 и говорить нечего. Аутентификации как таковой не было - не считать же за нее строку Community, передаваемую в открытом виде? Были, конечно, попытки реализовать безопасность SNMPv1, но успехом они не увенчались. Во второй версии кардинальных изменений тоже не появилось. А вот SNMPv3 уже начала поддерживать как безопасность сообщений (USM), так и контроль доступа (VACM). В USM поддерживаются MD5 и SHA-1 для обеспечения защиты от модификации данных и DES (сейчас уже AES) для шифрования. VACM же вводит как возможность авторизации, так и возможность указывать, какой управляющий компьютер какими атрибутами может манипулировать.

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

  Заключение

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