Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Процесс функционирования система Zabbix

Zabbix - распределённая система мониторинга, которая позволяет мониторить любые измеримые параметры деятельности сети и серверов (сервисов), отслеживать нарушение предопределённых границ значений параметров и извещать заинтересованных лиц. Хорошо проработанные средства построения графиков и отчётов. Данные могут получать как с помощью запросов от сервера агентам, устанавливаемым на контролируемые узлы, так и получением сообщений от активных агентов. В качестве агента можно использовать имеющийся SNMP сервер (v1 и v2, запрос и trap), IPMI интерфейс. Позволяет определить SLA (через группу триггеров и выражение) и отслеживать их выполнение. Возможно автообнаружение (ICMP ping) и авторегистрация агентов.

Конфигурация и данные хранятся в СУБД (MySQL/InnoDB для тяжёлой нагрузки, PostgreSQL, Oracle, SQLite). Возможен экспорт и импорт конфигурации (части конфигурации) в XML.

На рисунке 2.3.1 представлена БД системы Zabbix на MySQL.

Рис 2.3.1 БД системы Zabbix на MySQL

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

· сервер Zabbix регулярно опрашивает пассивных агентов (Zabbix, SNMP) и принимает данные от активных агентов, при необходимости извещает кого попало; потоки (все выглядят как zabbix_server):

o Poller - извлекает данные от агентов SNMP и Zabbix

o Pinger - ICMP ping; используется внешняя утилита fping, которая включает опцию RECORD_ROUTE, к которой многие устройства относятся плохо

o Node Watcher - отслеживает межузловые коммуникации

o процесс очистки от старых записей

o Trapper - приёмник данных от активных агентов, журналов и Sender

o Timer - обрабатывает триггерные выражения, зависящие от времени (?)

· агент Zabbix работает на сервере, который необходимо мониторить; выполняется в режиме демона или inetd/xinetd (не рекомендуется); может работать в активном режиме (запрашивает список требуемых параметров и посылает их сам) и пассивном режиме (ждёт запросов от сервера); возможна авторегистрация агента на сервере, обеспечивается аутентификация.

· zabbix_sender - утилита, посылающая данные на сервер (используется в долгоиграющих скриптах для периодической посылки значений параметров)

· прокси собирает и принимает данные с нескольких агентов для сервера Zabbix; удобен для установки в удалённом филиале;

· СУБД для хранения собранных данных, конфигурации, событий и пр.

· HTTP сервер (Apache и PHP), обеспечивающий интерфейс пользователя

· zabbix_get - утилита для опроса агентов (используется при отладке)

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

Контролируемые объекты называются узлами или хостами. Их можно группировать. Узел может входить в несколько групп. Профиль (profile) узла - набор сведений для инвентаризации о типе оборудования, модели, расположении, серийном номере и прочие. Заполняется вручную. Каждый контролируемый параметр узла называется элементом данных (ЭД). Текущее значение элементов данных опрашивается в дискретные моменты времени с заданным интервалом. Система позволяет посмотреть очередь невыполненных запросов (меню администратора).

Если нам понадобиться мониторить с нескольких узлов один и тот же параметр, то удобнее их группировать (Рис 2.3.2).

Рис 2.3.2 Схема группировки элементов данных

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

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

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

· описание, может содержать макросы: $N - N-ый параметр элемента данных

· имя (тип, key), под которым он будет собираться, храниться и извлекаться

· тип данных

o целое 64 бита без знака (u)

o плавающее число (d)

o строка до 255 байт (s, Latin1?)

o текст неограниченной длины (t)

o журнал (m) - специальная модификация текста для хранения журналов

· основание счисления для целых чисел (десятичное, восьмеричное или шестнадцатеричное)

· единица измерения (для числовых данных) - строка будет выводиться сразу за значением, числа преобразовываться к кило, мега и гига; встроенные единицы измерения:

o b или bps

o unixtime (секунды абсолютные, выводится в формате yyyy.mm.dd hh:mm:ss)

o uptime (секунды относительные, выводится в формате N days, hh:mm:dd)

o s (секунды относительные, выводится в формате YYyMMmDDdHHhMMm)

· на сколько надо умножать входные данные

· интервал опроса (в секундах)

· гибкий интервал позволяет задать различные интервалы опроса в разное время суток

· время хранения данных (в сутках)

· время хранения суммированных данных (трендов, ежечасные max, min и avg)

· активировать или нет (может быть переведён в состояние неподдерживаемого)

· что хранить (полученные данные, изменения между измерениями, изменения за секунду)

· данных

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

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

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

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

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

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

· tcp|ftp|http|imap|nntp|pop|smtp|ssh,ip-адрес,порт (0 - соединение не принято, 1 - соединение принято, 2 - время ожидания истекло)

· ftp_perf|http_perf|imap_perf|nntp_perf|pop_perf|smtp_perf|ssh_perf,ip-адрес,порт (0 - сервер недоступен, иначе число милисекунд, потраченных на соединение)

· icmpping (0 - неудача, 1 - успех)

· icmppingsec (время оборота)

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

· описание

· тип агента (SNMPv1, SNMPv2 или SNMPv3)

· SNMP комьюнити для чтения

· OID (рекомендуется в числовом виде); возможен динамический поиск OID в формате (от такого поиска некоторые устройства со слабым CPU могут умереть):

· базовая-часть-OID["index","базовая часть OID, в которой будет вестись поиск","строка поиска"]

· ifInOctets["index","ifDescr","GigabitEthernet0/1"]

· порт (по умолчанию 161)

· тип (key), под которым этот OID будет известен (можно сам OID)

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

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

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

· zabbix[boottime] (время в формате UNIX)

· zabbix[items] (количество элементов данных в БД)

· zabbix[items_unsupported]

· zabbix[queue] (необработанных заданий в очереди)

· zabbix[triggers] (количество триггеров в БД)

· zabbix[uptime] (время жизни процесса zabbix_server)

Триггеры

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

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

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

· /

· *

· -

· +

· <

· >

· # (приближённо не равно)

· = (приближённо равно)

· &

· |

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

· abschange (абсолютная разница между последним и предпоследним значением; для строк: 0 - значения равны, 1 - не равны)

· avg (среднее значение за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'))

· delta (разность между максимумом и минимумом за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'))

· change (разница между последним и предпоследним значением; для строк: 0 - значения равны, 1 - не равны)

· date (дата в формате YYYYMMDD)

· dayofweek (1 - понедельник, 7 - воскресенье)

· diff (0 - последнее и предпоследнее значения равны; 1 - различаются)

· fuzzytime (1 - временной штамп элемента данных различается от времени сервера не более указанного числа секунд)

· max (максимум за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'))

· min (минимум за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'))

· nodata (1 - если за указанное число секунд не было полученно данных; нельзя указывать менее 30 секунд)

· now (время в формате UNIX)

· prev (предпоследнее значение; last (#2))

· regexp (1 - указанное в качестве первого параметра регулярное выражение соответствует значению элемента данных за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'); с учётом регистра символов)

· sum (сумма значений за указанный интервал в секундах или за указанное количество отсчётов (число предваряется символом '#'))

· time (текущее время в формате HHMMSS)

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

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

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

· Not classified (серый)

· Information (зелёный)

· Warning (жёлтый)

· Average (тёмнокрасный)

· High (красный)

· Disaster (алый)

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

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

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

Действие (action)

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

Рис 2.3.3. Структура действии

 

Атрибуты:

· Name - имя действия

· Event Source - источник событий: Triggers (изменение состояния триггера) или Discovery (модуль автоматического обнаружения контролируемых объектов)

· Enable escalations - разрешить дальнейшую эскалацию событий

· Period - период времени для шага эскалации в секундах

· Defult subject - кого извещать по умолчанию (можно использовать макросы)

· Default message - текст сообщения по умолчанию (можно использовать макросы)

· Recovery message - текст сообщения о решении проблемы (можно использовать макросы)

· Recovery subject - кого извещать о решении проблемы (можно использовать макросы)

· Status - статус действия: активно или запрещено

· набор условий инициации действия (фильтр), каждое условие задаётся типом, оператором сравнения и строкой для сравнения, условия одного типа OR-ятся, разных типов - AND-ятся

o типы условий для событий, порождаемых переключением триггера

§ Application (операторы: =, like, not like) - триггер является частью указанного приложения

§ Host group (операторы: =, <>) - изменился триггер для хоста из указанной группы

§ Host template (операторы: =, <>) - изменился триггер, определённый в указанном шаблоне, использованном при создании хоста

§ Host (операторы: =, <>) - изменился триггер для указанного хоста

§ Trigger (операторы: =, <>) - изменился указанный триггер

§ Trigger description (операторы: like, not like) - указанная строка встречается в описании - имени? - изменившегося триггера)

§ Trigger severity (операторы: =, <>, >=, <=) - изменился триггер указанной важности

§ Trigger value (операторы: =) - изменился триггер с указанным значением (OK или PROBLEM)

§ Time period (операторы: in) - время события попадает в указанный интервал (шаблоны: dd-dd, hh:mm-hh:mm и др.)

o типы условий для событий, порождаемых модулем автообнаружения

§ Host IP (операторы: =, <>) - входит ли адрес обнаруженного хоста в указанный интервал

§ Service type (операторы: =, <>) - обнаруженный сервис совпадает с указанным

§ Service port (операторы: =, <>) - TCP порт обнаруженного сервиса входит в указанный интервал

§ Discovery status (операторы: =) - Up или Down

§ Uptime (>=, <=) - в секундах

§ Downtime (>=, <=) - в секундах

§ Received value (операторы: like, not like, =, <>, >=, <=) - сравнение указанной строки со значением, полученным от агента или SNMP

· операция (operation) или набор операций; для событий автообнаружения можно также добавить или удалить хост, добавить хост в группу или удалить из группы, связать хост с шаблоном или отвязать; параметры операции:

o Step - при эскалации событий (позволяет организовать повторное извещенеие, извещение других пользователей, дополнительные действия при неустранении проблемы за указанное время) устанавливается начальный шаг (From), конечный шаг (To) и интервал времени (в секундах) для перехода на следующий шаг

o Operation type - что делать на этом шаге: Send message или Execute command

o Event Source (?)

o Send message to - персональное сообщение (Single user) или групповое (User group)

o Default message - использовать текст сообщения по умолчанию

o Subject - кого извещать (можно использовать макросы); для получения сообщения пользователь должен иметь права на чтение к триггеру на хосте, который породил сообщение

o Message - текст сообщения (можно использовать макросы)

o Remote command - текст команды для удалённого выполнения (д.б. разрешено в настройках агента); каждая строка должна содержать имя хоста, двоеточие и текст команды (можно использовать макросы) или имя группы хостов, '#' и текст команды (можно использовать макросы); пользователь zabbix должен иметь права на выполнение (рекомендуется настроить sudo); команда выполняется в фоновом режиме без проверки результата; в качестве текста команды можно использовать

o IPMI {reset|power} [on | off | число]

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

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

На рисунке 2.3.4 представлена типы оповещении.

Рис 2.3.4. Типы оповещении

o e-mail (необходимо указать имя SMTP сервера, обратный адрес и HELO)

o Jabber (При отправке оповещений, Zabbix попытается найти первую запись SRV Jabber, и если не удалось найти, тогда будет использоваться адрес записи этого домена. Среди записей SRV Jabber, будет выбрана одна с наивысшим приоритетом и с максимальным весом. Если не удалось найти такую запись, другие записи проверяться не будут.)

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

o Ez Texting

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

· время доступности среды передачи

· уровень серьёзности сообщений для передачи по этой среде

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

Шаблоны

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

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

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

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

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

· SSH (можно указать порт, интервал портов, список портов)

· LDAP (можно указать порт, интервал портов, список портов)

· SMTP (можно указать порт, интервал портов, список портов)

· FTP (можно указать порт, интервал портов, список портов)

· HTTP (можно указать порт, интервал портов, список портов)

· POP (можно указать порт, интервал портов, список портов)

· NNTP (можно указать порт, интервал портов, список портов)

· IMAP (можно указать порт, интервал портов, список портов)

· TCP (можно указать порт, интервал портов, список портов)

· Zabbix агент (можно указать порт)

· SNMPv1 (можно указать порт, комьюнити, OID)

· SNMPv2 (можно указать порт, комьюнити, OID)

· ICMP ping (fping)

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

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

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

Интерфейс

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

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

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

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

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

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

· тип элемента карты

o иконка изображает состояние всех триггеров хоста (Host, узел сети)

o иконка изображает состояние всех элементов карты (нет такого?)

o иконка изображает состояние триггера

o иконка изображает состояние всех триггеров всех хостов группы

o ни с чем не связанная иконка

· подпись к иконке (см. общие настройки карты)

· расположение подписи, если не по умолчанию

· хост, группа или триггер в зависимости от типа элемента карты

· имя иконки для объекта в нормальном состоянии, при наличии проблемы, при неопределённом состоянии, при отключённом объекте

· URL, который будет связан с иконкой (иначе будет доступ к скриптам и триггерам хоста)

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

· элементы карты, которое оно соединяет

· тип и цвет линии для нормального состояния

· набор триггеров, позволяющих изменить тип линии и цвет соединения

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

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

· часы

· обзор данных о группах хостов

· встроенные графики

· определённые пользователем графики

· информацию о хостах

· историю событий

· историю действий

· вложенные экраны

· вложенные произвольные страницы (URL)

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

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

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

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

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

Имеется управление пользователями и правами доступа. Типы пользователей: ZABBIX User (доступ к меню мониторинга, по умолчанию не имеет доступа ни к каким узлам и группам, необходимо предоставлять доступ явно), ZABBIX Admin (доступ к меню мониторинга и конфигурации, по умолчанию не имеет доступа ни к каким узлам и группам, необходимо предоставлять доступ явно), ZABBIX Super Admin (доступ к меню мониторинга, конфигурации и администрирования; имеет неотзывный доступ на чтение и запись ко всем узлам и группам). Для пользователя также задаются: входное имя, имя собственное, фамилия, список групп, среда передачи сообщений, язык, тема оформления, использование куки для автоматического входа, выход по неактивности, начальный URL, интервал обновления экрана. Здесь же можно посмотреть права доступа, определяемые членством в группах. Пользователь может самостоятельно настроить: пароль, язык, тему оформления, использование куки для автоматического входа, начальный URL, интервал обновления экрана. По умолчанию создаются пользователи Admin (максимальные права) и Guest. На рисунке 2.3.5 представлена типы пользователей в системе Zabbix.

Рис 2.3.5 Типы пользователей системы Zabbix

Можно создавать свои группы пользователей и имеются группы пользователей "из коробки":

· Zabbix administrators (члены этой группы получают извещения о проблемах с СУБД)

· UNIX administrators

· WEB administrators

· Network administrators

· Disabled (сюда надо помещать временно заблокированных пользователей вместо их удаления)

· Database administrators

Выводы по второй главе

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


Последнее изменение этой страницы: 2016-08-28

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...