Zabbix описание на русском

Zabbix

ZABBIX 4.0 запущенный в GNU/Linux
Тип Система мониторинга [d]
Автор
Разработчик Zabbix LLC[d]
Написана на Си , PHP и Java
Операционная система GNU/Linux [d] , Solaris , macOS , HP-UX , NetBSD , FreeBSD , Power Systems и AIX
Первый выпуск 1998[1]
Последняя версия
  • 4.4.0 ( 7 октября2019 ) [2]
Лицензия GNU GPL 2[3]
Сайт zabbix.com​ (англ.)
Медиафайлы на Викискладе

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

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

Zabbix начался в 1998 году как внутренний проект в латвийском банке.

7 апреля 2001 года система была выпущена публично под лицензией GPL [4] , первая стабильная версия — 1.0 от 23 марта 2004 [4] . В апреле 2005 года была создана латвийская компания SIA Zabbix для управления проектом. [5] Практически ежегодно выпускаются новые версии системы, крупные выпуски: 2.0 (2012), 3.0 (2016) и 4.0 (2018).

Архитектура и возможности [ править | править код ]

Zabbix-сервер — ядро системы, которое дистанционно контролирует сетевые сервисы и является хранилищем, в котором содержатся все конфигурационные, статистические и оперативные данные. Он является тем субъектом в программном обеспечении Zabbix, который оповещает администраторов о проблемах с контролируемым оборудованием.

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

Zabbix-агент — программа контроля локальных ресурсов и приложений (таких как накопители, оперативная память, статистика процессора и т. д.) на сетевых системах, эти системы должны работать с запущенным Zabbix-агентом.

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

Веб-интерфейс — часть Zabbix-сервера, и, как правило (но не обязательно), запускается на том же физическом узле, что и Zabbix-сервер. Работает на PHP, требует веб-сервер (например: NGINX, Apache httpd).

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

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

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

Поддерживаемые платформы (сервер и агент): AIX, FreeBSD, HP-UX, Linux, Mac OS, OpenBSD, SCO OpenServer, Solaris, Tru64/OSF; кроме того, реализованы агенты для Novell Netware и операционных систем семейства Windows.

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

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

Основной дашборд

Система состоит из четырёх основных компонентов:

  1. Сервер мониторинга, который собирает и обрабатывает данные от всех агентов.
  2. Прокси сервер, выполняющий те же функции, но с последующей отправкой на центральный сервер.
  3. Веб-интерфейс для мониторинга.
  4. Агент, собирающий данные на физическом сервере.

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

Краткая история

29 выпуск SDCast в августе 2015 немного пролил свет на то, как всё происходило. Zabbix был создан в 1998 для нужд банка Алексеем Владышевым. В те времена он был написан на языке Perl. Позднее проект был сильно переработан, в частности — переписан на C и PHP, изменилась его архитектура. В 2001 году Zabbix открыл исходные коды под свободной лицензией GPL, а стабильная версия 1.0 была выпущена спустя три года, в 2004. В 2005 была создана компания Zabbix SIA, занимающаяся оказанием платных технических услуг, связанных с ПО.

Читайте также:  Блок питания chieftec eco 600w

Возможности Zabbix

В систему мониторинга уже встроен ряд стандартных метрик:

  • нагрузка на процессор, в том числе отдельными процессами;
  • объём свободной оперативной памяти;
  • активность жёсткого диска;
  • объём свободной физической памяти;
  • сетевая активность;
  • пинг.

А также прочие проверки общего назначения и для самых распространённых сервисов, таких как веб-сервер, СУБД, SSH, Telnet, VMware, NTP, POP, SMTP, FTP и других.

Чтобы задать реакцию при отклонении каких-либо метрик от нормы, используются специальные условия — триггеры. Например, если пинг отсутствует пять минут, выводится уведомление администратору и выполняется команда перезапуска сервиса.

Для выхода из нештатной ситуации применяются отдельные условия, поэтому незначительное улучшение метрики не является достаточным для устранения неполадки. Например, если свободного места на жёстком диске осталось меньше 10%, сработает аварийный триггер и чтобы он выключился, значение должно превышать 30%.

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

Проверки

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

  • Zabbix agent — сервер сам опрашивает агента, подключаясь к нему с нужным интервалом.
  • Zabbix agent (active) — агент подключается к серверу и отправляет информацию.
  • Simple check — различные простые проверки (например, пинг).
  • SNMP agent (версии 1-3, trap) — сбор данных по SNMP протоколу.
  • Zabbix Internal — сбор информации с самого сервера Zabbix для проверки его состояния.
  • Zabbix trapper — сбор данных с трапперов, которые являются мостом между некими сервисами и Zabbix (принимают данные по сети из сторонних приложений, чтобы транспортировать их на сервер мониторинга).
  • Zabbix aggregate — проверка, при которой происходит сбор совокупной информации из базы данных.
  • External check — внешняя проверка, при которой запускается исполняемый файл и считывается стандартный вывод.
  • Zabbix database monitor — сбор данных из базы через ODBC.
  • IPMI agent — сбор данных через интерфейс IPMI.
  • SSH agent — Zabbix подключается по SSH и выполняет заданные команды, считывая стандартный вывод.
  • TELNET agent — делает то же самое, что и SSH agent, но по протоколу TELNET.
  • JMX agent — сбор информации через технологию JMX (наблюдение за Java машиной).
  • Calculate — вычисления на основе различных данных (других проверок, их исторических значений).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конфигурационный файл Zabbix-сервера

Хакер #179. Интернет вещей — новый вектор атак

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

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

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

Читайте также:  Как зайти в настройки роутера теле2

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

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

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

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

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

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

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

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

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

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

Проверка работоспособности скриптов ZTC Страница импорта шаблона

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также:  Fallout 4 что делать после прохождения

Шаблоны для маппинга SNMP-трапов Настройка трапов в веб-интерфейсе

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

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

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

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

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

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

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

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

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

Прежде всего нужно найти 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. Полагаю, если ты хороший админ, то эти возможности можешь применить с пользой для себя. Но не стоит забывать, что мониторинг не вещь в себе — его нужно применять в комплексе с организационными мерами.