UMGUM.COM (лучше) 

Zabbix Web interface ( Zabbix Web interface. )

30 марта 2010  (обновлено 27 мая 2017)

Эта публикация отнесена в архив. Она неактуальна.

Настраиваем систему мониторинга Zabbix с помощью Web интерфейса.

Прежде всего оградим нашу панель управления от посягательств врагов; выберем систему аутентификации для пользователей и сменим пароль администратора:

"Administration" => "Authentication" => "Internal authentication" = "Enabled"
"Administration" => "Users" => "Admin" => "Change password"

Определим, каким образом система мониторинга сможет извещать нас о происходящих событиях; настроим "Media types".
Для чистоты картины оставим пока только те типы, с которыми мы будем работать в процессе первоначально конфигурации - удалим ненужные; впоследствии можно будет создать и настроить удалённые типы.

Выберем для себя метод уведомления с помощью электронной почты:

"Administration" => "Media types" => "Email":
  "SMTP server": сервер, через который мы направляем сообщения;
  "SMTP helo": сервер, от имени которого мы отправляем сообщения;
  "SMTP email": адрес электронного почтового ящика, от имени которого мы отправляем сообщения.

Переходим к конфигурирования сервиса мониторинга.


Примем за правило создавать укороченные наименования шаблонов в списке: Configuration => Hosts => Templates по принципу "Template_" => "t_" с целью экономии пространства экрана и меньшей путаницы при создании новых шаблонов.

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

Чтобы адекватно настроить zabbix нам придётся понять, какими определениями он оперирует при сборе и анализе данных. Определений не так уж много:

Хосты (hosts) => Объединяются в группы (groups) => К хостам и группам можно и нужно применять шаблоны (templates) показателей;

Здесь задается имя, группа, IP адрес или доменное имя, порт агента, статус и template (грубо говоря – схема сбора данных)

Показатели (items) => Объединяются в шаблоны (templates) => Показатели или шаблоны с показателями привязываются к хостам или группам хостов;

Показателем может быть любой системный параметр, значение которого может вычислить zabbix-агент или zabbix-сервер. Показатель может быть как “встроенным” (например объём свободной памяти, загрузка CPU) так и пользовательским; например, количество транзакций вашего Postgres за последнюю минуту. При создании показателя можно указать достаточно много параметров, важнейшие из которых: тип, интервал обновления, приложение (CPU, Memory, Filesystem) и группа. Интервалы можно задавать весьма гибко.

Триггеры (triggers) => Объединяются в шаблоны (templates) => Триггеры или шаблоны с триггерами привязываются к хостам (hosts), группам хостов (groups) или шаблонам (templates);

Триггер взводится на показатель и срабатывает, если какой-то из параметров показателя перешёл через граничное значение. Например, объём свободной памяти опустился ниже 100 Mb.

Акции (actions) => Привязываются к триггерам (triggers);

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

Графики (graphs или charts) => Привязываются к хостам (hosts), группам хостов (groups) или шаблонам (templates) => Привязываются к экранам (screens) для отображения в сгруппированном виде;

Чтобы увидеть график, надо задать его имя, размеры для отрисовки, и показатель, который мы хотим отобразить. Для показателя задается дополнительно цвет и вид заливки (только линия, залитый регион, etc). На самом деле, на одном графике может быть сведено несколько показателей, но не эффективно добавлять больше двух, так как это не повысит информативность графика. Каждый график можно проматывать во времени, а также менять масштаб временной оси (1 час, 8 часов, сутки, неделя, месяц, год).

Экраны (screens).

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

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

Определимся с требованиями с системе мониторинга.

На перспективу можно запланировать следующее:

1. Каждый узел должен быть доступен по сети и проверятся это должно самым простым и доступным способом, путём посылки пакетов ICMP, иначе говоря ping’ов;
2. Windows, Linux и BSD серверы мониторятся с помощью агента Zabbix по шаблонам для каждой платформе со следующими обобщёнными основными параметрами с триггерами и акциями в случае критических показаний:
2.1. Размер доступного и свободного пространства на дисковых подсистемах (график) (триггеры на малый и критически малый размер);
2.2. Размер доступной и свободной оперативной памяти (график) (триггер на исчерпание доступной в течении некоторого количества времени);
2.3. Развёрнутое имя хоста с подробной характеристикой системы;
2.4. Статус доступности агента Zabbix (триггер на недоступность);
2.5. Версия запущенного на хосте агента Zabbix;
2.6. Время последней загрузки хоста (триггер на перезапуск хоста);
2.7. Время работы хоста с момента последней загрузки;
2.8. Загрузка процессора (график);
2.9. Утилизация процессора (график) (триггер на пиковую утилизацию в течении некоторого количества времени);
2.9. Локальное системное время хоста;
2.10. Объем входящего и исходящего трафика на сетевых интерфейсах (график);
2.11. Количество запущенных на хосте процессов (график);
2.12. Количество отрытых файлов (график);
2.13. Количество и имена пользователей подключённых к системе (триггер на превышение среднестатистического времени подключения пользователя);
2.14. Наличие и факт запуска SSH, VNC или RDP сервера;
2.15. Наличие и факт запуска ключевых производственных сервисов хоста;
2.16. Температура процессоров, материнской платы, блоков питания, носителей дисковой подсистемы (график) (триггеры на превышение определённой температуры и критический уровень превышения).
3. Активное оборудование, такое как коммутаторы и маршрутизаторы, с помощью протокола SNMP.

Прежде всего "усложним" себе начало работы созданием шаблонов.

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

"Configuration" => "Hosts" => "Templates" => "Create Template"

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

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

Переходим в раздел "Configuration" => "Items".
Выбираем созданный нами шаблон и создаем для него параметры мониторинга отталкиваясь от списка поддерживаемых клиентом Zabbix параметров (в случае, если это хост с операционной системой), списка поддерживаемых параметров SNMP протокола (в случае, если это оборудование или ПО с поддержкой SNMP) или списка поддерживаемых сервером Zabbix методов контроля доступности удалённых узлов.

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

Создадим шаблон с именем "t_ping_check" с единственным параметром, триггером и акцией:

Показатель в шаблоне "t_ping_check":

Description: "ping.check"
Type: "Simple check"
Key: "icmpping"
Type of information: "Numeric (integer)"
Use multiplier: "do not use"
Update interval (in sec): "5"
Keep history (in days): "90"
Keep trends (in days): "365"
Store value: "as is"

Триггер в шаблоне "t_ping_check" к показателю "ping.check":

Name: "{HOSTNAME} not available through ICMP"
Expression: "{t_ping_check:icmpping.sum(#5)}=0"
Severity: "High"

Акция в шаблоне "t_ping_check" к триггеру к показателю "ping.check":

Name: "{HOSTNAME} not available through ICMP"
Event source: Triggers
Conditions: No conditions defined
Operation type: Send message
Send message to: User group: admins
Subject: {TRIGGER.NAME}: {STATUS}
Message: {TRIGGER.NAME}: {STATUS}

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

Мы будем прикреплять этот шаблон ко всем хостам, группам хостов или шаблонам подлежащим мониторингу. Каждый хост с прикреплённым к нему заданным шаблоном обретёт описанный выше параметр мониторинга, триггер и акцию. Нам не придётся в дальнейшем беспокоится о конфигурировании мониоринга хостов на предмет доступности их путём использования протокола ICMP.

Конфигурации в Zabbix экспортируются. Воспользуемся этим.

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

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

Имеется нюанс, куда уж без них. Отправка уведомлений на Jabber работает «через раз». Пока не разбирался, почему именно, но зафиксировал следующую зависимость: на почту уведомление прилетает незамедлительно, а вот на Jabber сервер может и не прийти, не смотря на статус в Zabbix сервер об удачной отправке. Учитывая то, что, несмотря на указание двух методов отправки уведомлений, работает только один метод, тот, что указан первым, от применения Jabber до момента стабилизации метода отправки придётся отказаться.

Итак, у нас есть машина в сети с настроенным агентом, которую мы будем мониторить.

"Configuration" => "Hosts".

Создаем запись о хосте, подлежащем мониторингу.
Указываем имя хоста.
Группу (если нас не устраивает наименование имеющихся групп - создаем свою).
Указываем DNS и/или имя или IP адрес удалённого хоста.
Выбираем метод подключения к узлу (с использованием DNS или прямого IP).
Указываем порт подключения (не будем оригинальничать и останемся на рекомендуемом: 10050).
Указываем на то, что этот хост будет активен и подлежит мониторингу.
И (вот оно!) привязываем подключаемый хост к созданным заранее шаблонам.

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

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

Карты. Нужны ли они нам? Не знаю, как Вам, а мне нет. Во всяком случае не в моих конфигурациях, слишком разнесённых по объектам и древовидных. Удаляем все имеющиеся карты и не создаем новых.

Экраны. Крайне удобный функционал Zabbix. Создаем столько экранов, сколько нам нужно. Группируем на них параметры мониторинга с самыми разными целями, как то: общий обзор состояния, детальный обзор сегмента, единицы оборудования, демонстрация особо выгодных показателей руководству и так далее.

Количество ячеек указываем исходя из количества хостов подлежащих мониторингу. Размещаем в ячейках экрана графики мониторинга параметров.

Оптимальный для восприятия и размещения на экране в 1024х768px в три колонки размер ячейки:

Width: 250px
Height: 100px

Создаем экран "CPU Utilization" и размещаем на нем графики мониторинга утилизации процессоров контролируемых хостов.

И так далее.

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

Сервисы. Что это такое? Сам ещё не понял.

Обзор (Discovery) сегмента сети на предмет обнаружения новых объектов мониторинга. Полезно. Особенно там где нет детальнейшей инвентаризации оборудования, чёткого представления о том, что где установлено и субординации между администраторами.

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


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )