Zabbix — мощный инструмент для мониторинга ИТ-инфраструктуры

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

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

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

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

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

• MySQL;
• Oracle;
• PostgreSQL;
• SQLite;
• IBM DB2.

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

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

Возможности 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 способен собирать различную информацию, отражающую текущее состояние физического сервера. Например:

• CPU idle time — время простоя (когда процессор не выполняет никаких операций).
• CPU interrupt timer — время, затрачиваемое на обработку прерываний от оборудования.
• CPU iowait time — время ожидания запрошенных ресурсов.
• CPU nice time — время, потраченное на обслуживание процессов с изменёнными приоритетами.
• Interrupts per second — количество прерываний от оборудования в секунду.
• Processor load — загруженность ядра процессора.
• Host boot time — время, за которое происходит включение физического сервера.
• Host local time — значение локального времени на сервере.
• System uptime — время непрерывной работы сервера.
• Available memory — объём свободного дискового пространства.
• Free swap space — объём свободного места подкачки.
• Free swap space in % — то же самое, только в процентах.
• Total memory — общий объём дискового пространства.
• Total swap space — общий объём системы подкачки.

И многие другие метрики.

Триггеры

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

Устанавливается реакция на сработавшие условия, её важность, критерии выхода (снятия предупреждения).

Прогнозирование

У триггеров есть довольно полезная возможность — функции предугадывания будущих значений и того, когда они возникнут по времени. Для составления прогноза используются исторические данные, проанализировав которые, триггер может выявить возможные проблемы в будущем, выдав соответствующее уведомление. Таким образом, можно заранее предупреждать возникающие проблемы, например, пики нагрузки на оборудование или заканчивающееся место на жёстком диске. Данная функциональность была добавлена в обновлении 3.0, выпущенным в феврале 2016.

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

Оно предназначается для автоматического создания элементов и триггеров, чтобы отслеживать состояние различных систем наблюдаемого сервера.

Zabbix умеет обнаруживать:

• файловые системы;
• сетевые интерфейсы;
• процессоры и их ядра;
• распространённые OID, используемые SNMP;
• наличие ODBC;
• службы Windows.

Если этого мало, то имеется возможность задать свои типы обнаружения, используя формат JSON.

Прокси Zabbix

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

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

Интерфейс

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

Узлы сети — это серверы, с которых снимается информация. У каждого узла есть элементы — отслеживаемые параметры, на изменение которых, собственно, и реагирует система. Каждому параметру можно задать свой интервал обновления и скорость изменения (например, чтобы сообщение о проблеме выводилось только после N проваленных проверок). Для каждого узла не обязательно выставлять свои параметры. Если они одинаковые, то оптимальным решением является использование шаблонов, которые наследуют все серверы.

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

Управление системой так же осуществляется через веб интерфейс: именно там создаются и настраиваются группы, серверы, сбор параметров, триггеры и прочее. Возможно создание множества аккаунтов с разными уровнями доступа.

Заключение

Мы рассмотрели основные возможности пакета Zabbix. На текущий момент он является многофункциональной системой мониторинга, в которой есть все для полноценного наблюдения за ИТ-инфраструктурой предприятия, включая мониторинг сети, серверов и приложений. Система уже может конкурировать с продуктами таких монстров, как HP, IBM, Microsoft и другими. В одной из следующих статей мы рассмотрим сферы применения и возможности Zabbix по сравнению с Microsoft SCOM.

_____________________

В статье использовались изображения с официального сайта Zabbix.