Zabbix как настроить триггер

ZABBIX – Как создать триггер

Всем доброго времени суток, печеняги, настраивающие zabbix! Я крайне рад, что вы проявляете интерес к нашим статьям и видосам, поэтому хочу сказать вам огромное спасибо за оказанный интерес, ведь именно Вы мотивируете нас трудиться!

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

ZABBIX – Как создать триггер и что это такое.

Следующим шагом корректного функционирования мониторинга в ZABBIX будет создание триггера. В свою очередь триггер – содержит выражение, которое определяет порог являющийся приемлемым уровнем для данных. Т.е. триггер это инструмент, который в зависимости от ваших настроек определяет нормально ли работает ваш элемент данных, или его значение, например, опустилось ниже, чем нужно для корректной работы системы. Триггер может иметь 2 состояния “ПРОБЛЕМА” и “ОК”.

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

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

Настройка -> Узлы сети

Как вы можете заметить для настройки мониторинга, сочетание “Настройка” и “Узлы сети” используются очень часто.

Далее нам необходимо найти строку с “Узлом сети, который мы добавили в первом ролике”, в моем случае это “vtrsagent” и в четвертом столбце перейти на страницу “Триггеры”.

Как создать триггер – Этап 1

Как создать триггер – Фильтры

Как видите сверху есть 3 строки фильтрации
1. Первая по важности триггера.
2. Вторая – по состоянию триггера.
3. Третья – по активированным и деактивированным триггерам.
Таким образом, вы можете найти определенный триггер, но вы например помните, только то, что он “Чрезвычайный”, соответственно средствами zabbix-a будет не сложно его найти.

На этой же странице, в правом верхнем углу нам необходимо нажать на кнопку “Создать триггер”. На странице создания триггера нам необходимо заполнить всего 2 поля (как я писал в некоторых статьях, мы используем технику “Быстрый старт”, которая предусматривает минимум настроек, для быстрого развертывания мониторинга).

Создание триггера.

• Немного пробежимся по предлагаемым полям:
  Имя – это видимое имя триггера в интерфейса zabbix.
  Важность – только вам решать какую важность назначать каждому триггеру.
• Следующее поле “Выражение” – здесь нам необходимо указать, что, как и почему? Нажимаем кнопку “Добавить”

Как создать триггер – Выражение

Здесь уже необходимо разбираться, какое событие и на какой порог триггеру нужно менять свое состояние.
В нашем случае мы мониторим элементом данных – количество запущенных процессов notepad.exe. Я хочу, чтобы триггер менял свое состояние на “ПРОБЛЕМА”, когда его значение опускается ниже единицы.

Итак, предварительно нам нужно выбрать элемент данных, и для этого нам необходимо нажать соответствующую кнопку.
После нажатия, откроется окно с большим выбором элементов данных, которые уже находятся в системе, чтобы упростить поиск нам нужно выбрать группу, к которой относится наш узел сети, в моем случае это группа PFR, после чего, я выбираю узел сети “vtrsagent” и нахожу нужный мне элемент данных.

Как создать триггер – Выбор элемента данных

Нажимаем на нужный элемент данных.

Далее мне необходимо поставить условие, при котором триггер будет менять свое состояние на “ПРОБЛЕМА”. В поле “Функция” мне необходимо выбрать “Последнее (самое новое) T значение Как создать триггер – Выбор функции

То есть если последняя проверка вернет значение меньше единицы, то триггер должен сменить свое состояние на “ПРОБЛЕМА”.
Так как в элементе данных у нас установлен стандартный интервал опроса в 30 секунд, то нам не нужно указывать количество времени, оно берется из элемента данных. Нам нужно указать только поле N, в котором значение должно быть равно той самой единице, которая будет являться порогом срабатывания.

Как создать триггер – Итоговое окно настройки выражения

После этого нажимаем кнопку “Вставить”.

Как создать триггер – Отображение выражения

Как видите “Выражение” автоматически преобразовалось в текстовое значение, которое так же можно менять по своему желанию, но об этих изменениях я расскажу в следующих роликах.

Остальные поля можно оставить без изменений, т.к. наша задача как можно быстрее развернуть мониторинг, поэтому просто нажимаем “Добавить”
После этого вы попадете на страницу триггеров, привязанным или созданных на нашем узле сети.

Генерация события.

Теперь давайте попробуем сгенерировать событие, которое заставит триггер поменять значение. Кстати его состояние вы можете увидеть нажав на логотип ZABBIX-a, который вас перенесет на главную панель, но удобнее просматривать состояние триггера через вкладку “Мониторинг”, “Триггеры”.

Как создать триггер – Мониторинг состояния

Здесь вам так же необходимо найти триггеры привязанные к вашему узлу сети используя фильтр. Это не сложно, не забудьте выбрать группу и узел сети в правом верхнем углу интерфейса.

Мы нашли наш триггер и как видим его состояние “ОК”, сейчас я зайду на сервер и выключу блокнот, для того, чтобы убедиться в работоспособности моего триггера.

Как создать триггер – Состояние “Проблема”

Блокнот выключен. Теперь мы можем наблюдать состояние триггера “ПРОБЛЕМА”, которое так же отображается на главной странице интерфейса zabbix-a в группе узлов сети PFR.

Как создать триггер – Мониторинг с главной страницы

Включением блокнота состояние триггера возвращается на “ОК”. И на этом создание и настройка триггера – все! 🙂

Поздравляю! Вы только что научились создавать триггер и отслеживать его состояние! Так же не забудьте посмотреть видео на тему “Как создать триггер”.

Обязательно подписывайтесь на наш канал! А еще на забывайте про наши страницы ВКонтакте и в Facebook-е! Желаем удачи в настройке мониторинга!

Поделиться в соц. сетях:

Понравилась статья? Поблагодари автора, накорми печеньками! 🙂

Источник

Zabbix Documentation 5.4

Sidebar

Table of Contents

4 Новый триггер

Обзор

В этом разделе вы узнаете как настроить триггер.

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

Если этот уровень будет превышать пришедшие данные, триггер будет “загораться” или перейдет в состояние ‘Проблема’ — давая понять, что что-то произошло и может потребовать внимания. Если уровень станет снова приемлемым, то триггер вернется в состояние ‘ОK’.

Добавление триггера

Для настройки триггера для нашего элемента данных перейдите в Настройка → Узлы сети, найдите ‘Новый узел сети’ и далее нажмите на Триггеры и затем на Создать триггер. Нам будет отображен диалог добавления триггера.

Все обязательные поля ввода отмечены красной звёздочкой.

Введите здесь необходимую информацию для нашего триггера:

Это выражение триггера. Убедитесь, что выражение введено верно, вплоть до последнего символа. Здесь ключ элемента данных (system.cpu.load) используется для ссылки на элемент данных. По простому данное выражение говорит, что порог проблемы превышается, когда значение средней загрузки CPU в течении 3 минут превышает 2. Вы можете узнать больше о синтаксисе выражений триггеров.

Когда завершите, нажмите на Сохранить. Этот новый триггер должен появиться в списке триггеров.

Просмотр состояния триггера

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

Если загрузка CPU превысит порог, который вы указали в триггере, проблема отобразится в Мониторинг → Проблемы.

Мигание указывает на недавнее изменение состояние триггера, которое имело место за последние 30 минут.

Источник

Zabbix: мониторим всё подряд (на примере Redis’а)

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

Правда я не могу сказать, что понимаю «философию Zabbix’а«. Несмотря на обширную подробную документацию на русском языке, мне было сложно погружаться в мир Zabbix’а — создавалось ощущение, что мы с разработчиками одни и те же вещи называем разными именами. Возможно потому, что Zabbix создавался админами для админов, а я всё-таки больше разработчик и пользователь.

Тем не менее, для запуска Zabbix’а и для мониторинга основных параметров компьютерных систем (процессор, память и т.п.) навыков обычного linux-пользователя хватает. Есть большое количество плагинов от сторонних разработчиков, расширяющих возможности Zabbix’а. Для моих нужд мне потребовалось настроить мониторинг Redis-сервера. Я немного покопался в коде имеющихся плагинов и на их примере выяснил, что архитектура Zabbix’а позволяет достаточно просто подключать к мониторингу любые параметры информационных систем, которые могут быть выражены в числовом виде.

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

Базовые понятия

Кратко о некоторых понятиях, которые используются в Zabbix’е: agents, items, triggers, actions, notifications, templates.

Сервер и агенты

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

Параметры мониторинга

Любая величина, которая может выражена в числовом или строковом виде, называется в терминологии Zabbix’а — элементом данных (item). Каждый элемент связывается с уникальным ключом (именем). Вот примеры элементов данных:

• system.cpu.load[percpu,avg1]: 0.1167
• system.uname: «Linux supru 4.15.0-50-generic #54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64»

Значения этих элементов данных (параметров мониторинга) привязываются ко времени, история значений параметров сохраняется в базе сервера.

События

При наступлении некоторого события в Zabbix’е срабатывает триггер. Например,

• >10 — среднее значение параметра за последние 5 минут превысило «10»
• >0 — текущее значение параметра не равно предыдущему значению

По сути, триггеры — это формулы, в которых переменными выступают параметры мониторинга (текущие и сохранённые), и которые на выходе дают true / false .

Действия и Оповещения

В случае наступления события (срабатывания тригера) сервер может выполнить действие. Например, отправить оповещение по email’у на заданный адрес («Problem: host is unreachable for 5 minutes«). Также действие может быть выполнено в случае возвращения триггера в исходное состояние («Resolved: host is unreachable for 5 minutes«). Все события (переключения триггера) логируются на стороне сервера.

Шаблоны

Zabbix даёт возможность как настроить правила мониторинга для отдельного хоста, так и создать шаблон правил (template), который можно применять к различным хостам:

На примере видно, что шаблон «Template App SSH Service» описывает одно приложение (Applications), один параметр мониторинга (Items), один триггер (Triggers). Также доступны описания для графиков, экранов, правил обнаружения и web-сценариев.

Постановка задачи для плагина

Начальное положение

Сам Zabbix предлагает свой собственный плагин для мониторинга состояния Redis’а, но на моей версии сервера (4.2.8) мне не удалось его задействовать (плагин для версии 4.4 и выше). Также предлагаются решения от третьих лиц (около десятка вариантов под различные версии Zabbix’а, на картинке только первых три):

Каждый из них обладал своими плюсами-минусами, пришлось заглянуть внутрь, чтобы выбрать. Лучшим, на мой взгляд, оказался плагин Shakeeljaveed/zabbix-redis-userparamaters, состоявший из двух файлов:

Немножко пришлось поработать «ручками», но зато на его примере стало чуть понятнее, как данные от агента попадают на сервер. По предложению автора Javeed Shakeel состояние Redis’а каждые 2 минуты сбрасывалось кроном в файл /tmp/redismetric :

А затем каждый параметр мониторинга извлекался агентом из файла /tmp/redismetric при помощи средств самой операционной системы. Инструкции для этого размещались в конфигурации Zabbix-агента /etc/zabbix/zabbix_agent.conf.d/userparameter_redis.conf . Например, вот так выглядят инструкция для извлечения параметра used_memory (использование памяти Redis-сервером):

То есть, в файле /tmp/redismetric с выводом redis-cli INFO по ключу used_memory ищется строка ( grep -w . )

которая затем разбивается на столбцы по разделителю «:» ( cut -d: -f2 ). На выходе агент получает число 7153216 и присваивает его параметру used_memory .

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

Задачей мониторинга состояния любой системы явлется не только сбор статистики, но и предупреждение о возникновении ситуаций, требующих вмешательства человека. Так как с Redis’ом я работаю на уровне очень начинающего пользователя, то пришлось поискать информацию, на какие параметры «здоровья» обращать внимание и что они значат. Наиболее достойной показалась статья «6 Crucial Redis Monitoring Metrics You Need To Watch». Проанализировав её, я пришёл к выводу, что «для полного счастья» мне нужно собирать данные для обнаружения следующих событий:

• Memory fragmentation: used_memory_rss / used_memory > 1.5
• Low cache hit ratio: (keyspace_hits)/ (keyspace_hits + keyspace_misses) 0
• Evicted keys: evicted_keys > 0

Также я хотел собирать статистику по дополнительным параметрам (версия Redis’а, uptime и т.п.). В общем, имея общее представление о том, каким образом данные собираются агентом и передаются на сервер, «хотелки» можно сильно не ограничивать. В итоге получился список параметров для мониторинга из 12 позиций.

Создание собственного плагина

Параметры мониторинга

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

Т.е., для получения данных по 12 параметрам агент должен будет 12 раз выполнить различные наборы команд. А если мне нужно мониторить параметры, которые сложно извлечь цепочкой команд и нужно будет писать отдельный shell-скрипт или полноценную программу? Для таких «хотелок» Zabbix предлагает вариант с зависимыми элементами данных. Суть его в том, что на стороне агента скриптом формируется набор данных (например, в формате JSON), который передаётся на сервер в виде строкового параметра. Затем на стороне сервера происходит разбор полученных данных и вычленение из них отдельных элементарных параметров.

Основной элемент данных

Я описал основной элемент данных redis.info строкового типа с периодом обновления в 1 мин., без сохранения истории изменений:

Предположительно, на стороне агента должен генерироваться такой JSON:

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

Зависимый элемент данных

Тестовый параметр redis.info.version зависит от redis.info и сохраняет свои значения в базе в течение 90 дней. Периодичность мониторинга параметра зависит от базового элемента ( redis.info ):

Значение параметра redis.info.version извлекается из значения redis.info при помощи инструкций JSONPath:

По аналогичной схеме описываются остальные зависимые элементы данных (параметры мониторинга), которые передаются в виде JSON’а. Вот пример описания числового параметра redis.info.used_memory :

Всё достаточно прозрачно, за исключением Units и Trend storage period . Со вторым пунктом я не разбирался, оставил по-умолчанию, а единицы измерения объяснены в документации. В данном случае значение redis.info.used_memory измеряется в байтах и в web-интерфейсе сворачивается до кило/мега/гига/. -байт.

Формула для извлечения значения из JSON’а: JSONPath = $.used_memory

Вычисляемый элемент данных

Для вычисления фрагментации памяти используется отношение used_memory_rss / used_memory и на его базе определяется триггер, срабатывающий при превышении отношением значения 1.5. В Zabbix’е есть вычисляемый тип элементов данных:

Значение для параметра redis.info.used_memory_ratio вычисляется каждую минуту на основании последних значений двух других параметров ( redis.info.used_memory_rss и redis.info.used_memory ), сохраняется в базе в течение 90 дней и т.д.

Триггеры

Вот пример триггера, срабатывающего при излишней фрагментации памяти:

Ничего необычного, за исключением формата выражений, используемого в формуле изменения состояния триггера. В Zabbix’е есть конструктор форм, можно воспользоваться им или обратиться к документации/примерам (список триггеров доступен через web-интерфейс по адресу «Configuration / Templates / $ / Triggers«).

Триггер может базироваться на любых элементах данных (item’ах) вне зависимости от их типа (основной, зависимый, вычисляемый).

Настройка агента

Генерация JSON’а

Для получения значений параметров мониторинга и формирования JSON’а я использую вот такой shell-скрипт:

Этот скрипт я поместил в файл /var/lib/zabbix/user_parameter/redis/get_info.sh на сервере с Redis’ом, на котором уже установлен агент Zabbix’а. Пользователь, под которым запускается Zabbix-агент (обычно zabbix ) должен иметь права на выполнение файла get_info.sh .

Файл userparameter_XXX.conf

На стороне агента дополнительные параметры мониторинга прописываются в файлах userparameter_*.conf в каталоге /etc/zabbix/zabbix_agentd.d . Поэтому для того, чтобы агент узнал о том, каким образом ему нужно собирать данные по параметру redis.info , я создал файл /etc/zabbix/zabbix_agentd.d/userparameter_redis.conf с таким содержимым:

Т.е., для получения данных по параметру redis.info агент должен запустить скрипт /var/lib/zabbix/user_parameter/redis/get_info.sh и передать на сервер результат выполнения.

После рестарта Zabbix-агента ( sudo service zabbix-agent restart ) у него появляется возможность собирать данные для параметра redis.info и отправлять их на сервер.

UPDATE: коллега banzayats обратил внимание, что текстовые данные с хоста можно получить без создания промежуточного скрипта userparameter_*.conf — при помощи параметра » system.run » и проводить постпроцессинг уже на стороне zabbix-сервера.

Резюме

Понимание Zabbix’а ко мне приходило (и всё ещё приходит) достаточно тяжело. Тем не менее я считаю его прекрасным инструментом, особенно после того, как для меня открылась простота добавления собственных параметров мониторинга (элементов данных). По большому счёту, достаточно добавить один файл на сервер с агентом ( userparameter_XXX.conf ) с shell-командой для сбора данных и настроить Zabbix-сервер на получение этих данных через web-интерфейс. И всё — можно накапливать данные, строить графики, анализировать изменения и создавать триггера, реагирующие на эти изменения.

Код шаблона, файла userparameter_redis.conf и скрипта get_info.sh можно посмотреть в проекте flancer32/zabbix_plugin_redis.

Спасибо всем, кто дочитал до конца, а особенно тем, кто нашёл в публикации что-то полезное для себя.

Источник