@ Карта сайта News Автора!

Bog BOS: Zabbix - распределённая система мониторинга

Последние изменения:
2017.10.24: hard: Таблицы разделов MBR и GPT

Последнее изменение файла: 2017.08.29
Скопировано с www.bog.pp.ru: 2017.12.12

Bog BOS: Zabbix - распределённая система мониторинга

Zabbix - распределённая система мониторинга, которая позволяет мониторить любые измеримые параметры деятельности сети и серверов (сервисов), отслеживать нарушение предопределённых границ значений параметров и извещать заинтересованных лиц (e-mail, SMS, XMPP (jabber), скрипт), средства эскалации и подтверждения извещения. Хорошо проработанные средства построения графиков и отчётов, возможно соотнесение с планом или картой. Можно использовать для проверки доступности и контроля производительности. Данные могут получать как с помощью запросов от сервера агентам, устанавливаемым на контролируемые хосты, так и получением сообщений от активных агентов, возможности агентов могут быть расширены скриптами. В качестве агента можно использовать SNMP сервер (v1 и v2 и v3, запрос и trap, динамические индексы с версии 2.2), IPMI, без агентов можно мониторить доступность определённых сервисов (почта, веб, FTP, LDAP, SSH, telnet, СУБД, сервера приложений Java). Позволяет определить SLA (через группу триггеров и выражение) и отслеживать их выполнение. Возможно автообнаружение (ICMP ping) и авторегистрация агентов. Поддержка JMX (Java Management Extensions) с версии 2.0.

Конфигурация и данные хранятся в СУБД (MySQL/InnoDB для тяжёлой нагрузки, PostgreSQL, Oracle, SQLite - до версии 1.8). Возможен экспорт и импорт конфигурации (части конфигурации) в XML (zabbix_export.xml, экспортируется не всё! комплексные отчёты и карты с версии 1.8). Интерфейс пользователя к данным мониторинга и настройкам - через браузер (сам интерфейс в кодировке UTF-8, но данные - нет!), Apache 1.3.12 или новее, PHP 4.3 или новее (модули php-gd, php-bcmath, php-mysql/php-sqlora8/php-pgsql/php-sqlite3). Возможна привязка аутентификации к LDAP. Настройка облегчается наличием параметризованных шаблонов (template). Требуется синхронизации времени в сети. Возможно закрытие интерфейса с помощью SSL/TLS, коммуникации между компонентами открытые, защита по адресу IP. Имеется интерфейс (API) взаимодействия с другими приложениями (JIRA, Puppet).

Разработка Zabbix LLC (Alexei Vladishev), ранее Латвийской компании Zabbix SIA (2005). Лицензия - GPL2, бесплатен даже для коммерческого использования. Имеется коммерческая поддержка. Версия на момент описания - 1.6.5. Поддержка версии 1.8 уже закончилась, в версии 2.0 исправляются только критические ошибки. Сервер может быть установлен на Linux, Solaris, HP-UX, AIX, FreeBSD, NetBSD, OpenBSD, Mac OS/X. Клиенты (агенты) могут быть также установлены на Windows 2000, Windows Server 2003/2008/2012, Windows XP, Windows Vista, Windows 7, Windows 8. Базовой системой для разработчика является Ubuntu (?). Обещается совместимость всех старых версий агентов с новыми версиями сервера. Обещается совместимость БД внутри версии и скрипты преобразования к новой версии. Документация версии 1.8 и новее только на сайте (обещан конвертор в ODT).

Архитектура системы

Программные компоненты:

Контролируемые объекты называются хостами (host). Их можно группировать. Хост может входить в несколько групп. Профиль (profile) хоста - набор сведений для инвентаризации о типе оборудования, модели, расположении, серийном номере и пр.. Заполняется вручную. Каждый контролируемый параметр хоста называется элементом данных (item). Текущее значение элементов данных опрашивается в дискретные моменты времени с заданным интервалом. Система позволяет посмотреть очередь невыполненных запросов (меню администратора). Триггер (trigger) задаётся с помощью логического выражения от значений элементов данных. Приложение (application) есть множество элементов данных хоста, связанных с одним реальным приложением. Элемент данных может входит в несколько приложений. Используется для группировки в вебинтерфейсе и выражениях триггеров. Событием (event) называется изменение состояния триггера от FALSE к TRUE или от TRUE к FALSE (возможно с промежуточным состоянием UNKNOWN). Действие (action) является реакцией системы на событие. Определяется для события или группы событий.

Реализован распределённый мониторинг. Главный узел конфигурирует подчинённые (proxy) и собирает с них данные. Не осваивал.

Элементы данных

Каждый контролируемый параметр хоста называется элементом данных (item). Данные могут собираться сервером напрямую (простые проверки, SNMP, IPMI), внешними скриптами и с помощью агентов (клиентов zabiix), работающими на контролируемых серверах. Агенты могут собирать данные встроенными средствами и с помощью скриптов. Веб-мониторинг позволяет извлекать данные с HTML страниц (специальный модуль). Имеется некоторое количество внутренних проверок работоспособности самого сервера zabbix и агрегированные проверки. Некоторые типы (key) элементов данных могут иметь параметры, заключаемые в квадратные скобки. Часть параметров является необязательной. Не все типы элементов данных поддерживаются на всех типах ОС (в документации есть таблица для какой-то старой версии). При добавлении элемента данных в общем случае указывается

Специальный тип данных "status", который определяется, если для хоста мониторится хотя бы один параметр (0 - хост доступен, 2 - хост недоступен).

Типы данных, собираемые агентами самостоятельно:

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

UserParameter=уникальное-имя-типа-данных,незакавыченная команда оболочки с параметрами

Команда может иметь позиционные параметры (при использовании указываются в квадратных скобках, так же как и для встроенных типов данных):

UserParameter=уникальное-имя-типа-данных[*],команда оболочки с использованием $1 - $10

Простые проверки производятся сервером удалённо без использования агентов. Типы данных, собираемые простыми проверками:

n

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

Перехват SNMP trap - snmptrap.sh (используется zabbix_sender, настроить по месту) и snmptrapd из net-snmp (добавить в snmptrapd.conf строку "traphandle default /bin/bash .../snmptrap.sh"). После этого настроить элемент данных.

Типы данных, собираемые IPMI - IPMI имя сенсора и ключ (можно использовать имя сенсора без пробелов). Предварительно в настройках узла необходимо указать использование IPMI (IP адрес, порт 623, алгоритм аутентификации, уровень привилегий, имя пользователя и пароль). Дискретные сенсоры не поддерживаются.

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

имя-скрипта[строка параметров]

Внутренние самопроверки сервера:

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

имя-групповой-функции["имя группы хостов","элемент данных","тип предобработки","параметр предобработки"]

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

Групповые функции действуют над предобработанными значениями:

Мониторинг своей СУБД - ?

ZABBIX trapper - значения элемента данных заполняются с помощью zabber_sender. Указывается список хостов, которым разрешается посылать данные.

Дополнительный модуль с отдельной настройкой для мониторинга HTTP/HTTPS серверов позволяет периодически выполнять многошаговые сценарии и сохранять результат в БД: время ответа, скорость загрузки, код возврата, найденная строка. Куки сохраняются в пределах сценария. При настройке необходимо задать

При создании каждого сценария автоматически добавляются элементы данных:

При создании каждого шага сценария автоматически добавляются элементы данных:

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

Некоторые элементы данных могут перейти в разряд "неподдерживаемых", если сервер или агент не могут получить соответствующее значение (смотрите в журналы!), Это можно заметить пробежавшись в настройке элементов данных по всем узлам. Периодически (по умолчанию - 600 секунд) сервер пытается проверить их работоспособность. Получить список неподдерживаемых элементов данных в версии 1.8: "SELECT description,key_,host FROM items LEFT JOIN hosts ON items.hostid = hosts.hostid WHERE items.status = 3; ". Получить список неподдерживаемых элементов данных: Настройка -> Узлы сети; фильтр сбросить; фильтр "состояние не поддерживается" . В версии 2.2 появился специальный тип извещений о переходе элементов в неподдерживаемые.

Триггеры

Триггер (trigger) задаётся с помощью логического выражения от значений единиц данных и может принимать значения FALSE, TRUE и UNKNOWN. Есть традиция определять триггеры так, чтобы значение TRUE указывало на наличие проблемы. Выражение перевычисляется каждый раз при получении очередного значения единицы данных, используемой в выражении. Выражения строятся с использованиемм бинарных операторов и функций над элементами данных, а также констант (числа и числа с двоичными множителями (K, M, G)). В выражении можно использовать единицы данных различных хостов. Для задания приоритета вычислений необходимо использовать круглые скобки. Синтаксис извлечения значения элемента данных:

{имя-хоста:имя-типа-элемента-данных.имя-функции(параметры)}

Операторы (перечислены в порядке убывания приоритета, преобразование типов - ?):

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

Триггер может зависеть от других триггеров, т.е. он не меняет своё состояние в соответствии со значением выражения, а событие не генерируется, если хотя бы один из этих триггеров взведён.

События могут генерироваться только при взведении триггера или каждом изменении взведённого триггера (Multiple TRUE events).

Триггер имеет уровень серьёзности (представляется цветом и звуком в вебинтерфейсе, определяет допустимость средства доставки (Media) сообщения и используется в условных действиях):

Триггер может содержать комментарии, которые могут передаваться в сообщении, и URL, которые будет доступен на странице состояния триггеров.

Действие триггера можно временно отключить.

При написании триггеров можно использовать макро.

Действие (action)

Действие (action) является реакцией системы на событие (event). Определяется для события или группы событий. Атрибуты:

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

Для посылки извещений администратором определяется среда передачи (Media):

В настройках пользователя указывается среда передачи (можно несколько):

События и действия хранятся в БД (время хранения - 365 дней - задаётся в настройках сборки мусора), их можно просмотреть и подтвердить получение или написать комментарий.

Шаблоны

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

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

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

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

Модуль автоматического обнаружения (отдельный пункт настройки) пробегает по указанному диапазону адресов (списку диапазонов адресов) с указанным интервалом времени, пытаясь обнаружить неизвестный ранее хост. Типы проверок:

При обнаружении или пропадании хоста генерируется событие (Service Up, Service Down, Host Up, Host Down, Service Discovered, Service Lost, Host Discovered, Host Lost), к которому можно привязать действие (условия и операции), так же как и к событию, порождённому изменением состояния триггера. Для событий автообнаружения кроме посылки извещений и выполнения скриптов можно также: добавить или удалить хост, добавить хост в группу или удалить из группы, связать хост с шаблоном или отвязать от шаблона. В документации приводится пример, как автоматически включать в мониторинг хосты, которые активны более 1 часа и выключать их после 24 часов неактивности, причём использовать различные шаблоны (на основании значения system.uname, предоставляемого агентом). Одно непонятно - зачем это нужно?

Правил автообнаружения может быть много.

Модуль LLD (Low-level discovery) позволяет автоматически добавлять элементы данных, триггеры и графики для обнаруживаемых файловых систем, сетевых интерфейсов, ЦПУ и SNMP OID. Можно добавить свои правила LLD.

Имеется возможность автоматической регистрации активных клиентов.

Контроль SLA (услуги IT)

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

Интерфейс

Веб-интерфейс консоли управления реализован через обращение PHP скриптов напрямую к СУБД. Поддерживается SSL. Консоль позволяет как просмотр собранных данных, так и настройку. Автоматическое отсоединение после 30 минут бездействия. После 5 неудачных попыток доступ блокируется на 1 минуту, а IP-адрес показывается настоящему администратору.

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

Главная панель (входная страница, dashboard) даёт общий обзор состояния триггеров и сервера zabbix. Настраивается доступ к популярным графикам, отчётам и картам.

Можно выбрать несколько объектов из списка, нажимая Ctrl одновременно с указанием мышью.

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

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

Карта позволяет наглядно показать связь хостов между собой, цветом отображается состояние хоста (узлы) или триггера (соединения). Картинку (общие размеры задаются в пикселах) необходимо рисовать самостоятельно, задавая вручную координаты (в пикселах) иконок хостов на плоскости и какой хост с каким соединён. Новые иконки (встроенные ужасны) загружаются в общих настройках (PNG, 48x48 или 24x24). Там же можно загружать фоновые картинки (масштабирование при визуализации не производится). Рекомендуется предварительно задуматься о прозрачности. Удаления иконок нет. В общих настройках карты указывается тип подписей (указанную при составлении карты подпись и статус, IP адрес и статус, имя хоста и статус, только статус хоста или совсем ничего) к иконкам и где их размещать по умолчанию.

Для каждого элемента карты указываются

Для каждого соединения элементов карты указываются

К узлам карты могут быть приписаны скрипты (Администрирование - Скрипты). При задании команды можно использовать макросы {HOST.CONN}, {HOST.DNS}, {IPADDRESS}. В комплекте идут ping и traceroute (запускаются на сервере, результат в окне браузера). В настройках скриптов можно задать допустимую группу пользователей, группу хостов и наличие прав на чтение или запись.

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

Ячейки можно сливать по горизонтали и вертикали, выравнивать содержимое по горизонтали и вертикали.

Из экранов можно делать слайд-шоу, задав последовательность экранов и интервал демонстрации каждого из них.

Инвентаризация - поиск и просмотр профилей узлов (модель, серийный номер и пр.). Увы - их придётся в начале задать и скорее всего они уже есть в другой системе инвентаризации.

Есть аудит действий системы (action) и действий администратора (вход, выход, добавление, удаление, изменение).

Можно заблокировать доступ к интерфейсу, поменяв conf/maintenance.conf.php.

Тему оформления можно подогнать под свой вкус, отредактировав styles/css_имя-темы.css, и включив в include/forms.inc.php.

Управление пользователями

Имеется управление пользователями и правами доступа. Методы аутентификаци: собственная (имена и пароли, хранятся в БД в зашифрованном виде), от Apache, LDAP. В случае аутентификации Apache и LDAP пользователь в смысле Zabbix тоже должен существовать, но его пароль не используется. При использовании LDAP пользователи из группы, для которой указан метод доступа "Internal", будут аутентифицироваться локально.

Типы пользователей:

Для пользователя также задаются: входное имя, имя собственное, фамилия, список групп, среда передачи сообщений (Media), язык (русский есть), тема оформления, использование куки для автоматического входа, выход по неактивности, начальный URL, интервал обновления экрана. Здесь же можно посмотреть права доступа, определяемые членством в группах. Пользователь может самостоятельно настроить (в профиле): пароль, язык, тему оформления, использование куки для автоматического входа, начальный URL, интервал обновления экрана. По умолчанию создаются пользователи Admin (максимальные права) и Guest (минимальные права, в этом режиме с системой могут работать незарегистрированные пользователи). Управление правами доступа осуществляется с помощью включения пользователя в группы пользователей и задании хостов, к которым пользователи группы могут иметь доступ на чтение и запись (для скриптов?). Для членов группы определяется: список пользователей, доступность вебинтерфейса (включить, выключить, системные умолчания), заблокированность пользователя, права на запись/чтение и чтение к группам хостов, группы, доступ к которым запрещён (?). Можно создавать свои группы пользователей и имеются группы пользователей "из коробки":

Сервер: ключи и настройки

Ключи запуска zabbix_server

Конфигурационный файл имеет текстовый формат. На каждой строке задаётся значение одного параметра в формате "имя=значение". Комментарии начинаются с символа '#'. Параметры:

Самостоятельный агент: ключи и настройки

Ключи запуска zabbix_agentd

Конфигурационный файл имеет текстовый формат. На каждой строке задаётся значение одного параметра в формате "имя=значение". Комментарии начинаются с символа '#'. Параметры:

Утилита zabbix_sender

Утилита zabbix_sender используется в долгоиграющих скриптах для периодической посылки значений параметров на сервер. Ключи:

Утилита zabbix_get

Утилита zabbix_get используется при отладке для опроса агентов. Ключи:

Методика использования

Сконфигурировать Media (email).

Создать пользователей (Zabbix Super Admin, во всех группах, кроме guest и disabled). Разрешить в качестве средства достувка email в любое время и по любому поводу. Английский язык (от прошлой версии осталось неприятное воспоминание). Тему по умолчанию. Автоматический вход. Увеличить интервал перерисовок. URL на dashboard.php. Проверить права (на всякий случай).

Скопировать предопределённые шаблоны и настроить под свои нужды. В частности, из Template_Linux сделать шаблон с набором действительно общих для всех хостов параметров Template_LinuxCore (без сервисов, которые есть не на каждом хосте) и отдельные шаблоны для каждого сервиса и дополнительных аппаратных особенностей (Template_eth1, Template_eth1-eth5 и т.д.).

Шаблон Template_HP_InsightManager содержит только параметры статуса (из 11 тысяч доступных параметров).

При расчёте требуемого места для хранения данных необходимо учесть количество контролируемых параметров, частоту их обновления, время хранения, затраты СУБД на хранение каждого значения (50 байт на число), учесть место под суммарные данные (trend) и записи о событиях.

Кеширование доступа к СУБД уменьшает нагрузку на CPU в несколько раз, но события могут запаздывать на несколько секунд.

Обновление сервера 1.6.9 до 1.8.22 на CentOS 5.10

Подготовительные работы:

Установка сервера и агента Zabbix

Веб-интерфейс

Рассылка новых агентов.

Обновление сервера 1.6.5 до 1.6.9 на CentOS 5.10

Подготовительные работы:

Установка сервера и агента Zabbix

Веб-интерфейс

Рассылка новых агентов.

Установка и настройка сервера 1.6.5 на CentOS 5.3

Подготовительные работы:

Установка сервера и агента Zabbix

Веб-интерфейс

Определение и настройка контролируемых объектов, параметров, триггеров, пользователей и их прав, средств доставки и красивых карт и консолей.

Обновление агента с 1.4 или 1.6 до 1.8.22 под Fedora 10, CentOS 5

zabbix_get не входит в состав пакета zabbix-agent до версии 2.0.

Обновление агента с 1.4 до 1.8.22 под CentOS 4

Установка и настройка самостоятельного агента 1.4 и 1.6

При установке из RPM (пакет zabbix_agentd или zabbix-agent) создаётся пользователь zabbix и создаётся сервис zabbix-agent (незапущенный по умолчанию). При установке в RHEL4 (CentOS4) из EPEL требуются пакеты fping и iksemel.x86_64. Настроить /etc/zabbix/zabbix_agentd.conf (адрес сервера, имя клиентского хоста, локальный порт (10050) и адрес, уменьшить количество агентов (но одного недостаточно), не разрешать удалённые команды, журнал в syslog - local7 - не работает). Создать /var/log/zabbix и /var/run/zabbix с нужными правами. Открыть порт. Запустить сервис. Обеспечить запуск сервиса при загрузке.

Пересборка пакетов из исходных текстов (CentOS4 (подходят к FC3/FC4), CentOS5): скачать и положить в /usr/src/redhat/SOURCES/ (zabbix-1.4.2-cpustats.patch, [zabbix-1.4.2-netsnmp-x86_64.patch], zabbix-agent.init, zabbix-logrotate.in, zabbix-server.init, zabbix-web.conf) и в /usr/src/redhat/SPECS/ (zabbix.spec). Доставить net-snmp-devel, gnutls-devel, curl-devel, iksemel-devel (из FC4/FC6). Сборка пакетов:

rpmbuild -bb --target=x86_64 zabbix.spec

Для работы скриптов с параметрами требуется каталог /var/lib/zabbix (с правами для пользователя zabbix).

Установка и настройка самостоятельного агента 1.6 и 1.8 под Solaris 8

Изменения

Отличия версий:

Ссылки

@ Карта сайта News Автора!

Bog BOS: Zabbix - распределённая система мониторинга

Последние изменения:
2017.10.24: hard: Таблицы разделов MBR и GPT

TopList

Copyright © 1996-2017 Sergey E. Bogomolov; www.bog.pp.ru (КГБ знает все, даже то что у Вас на диске ;)