zabbix выполнение скрипта при срабатывании триггера

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

Заключение

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

Если вы настроили мониторинг бэкапов, который выполняется ночью, то его тоже не обязательно чинить в ту же минуту, можно отложить на вечернее время. Чтобы не забыть, можно настроить уведомления раз в 2 часа. И так далее. Смысл, я думаю, понятен.

Еще раз обращаю внимание на ссылку в самом начале на документацию заббикса. Там описаны более замысловатые, но тем не менее простые в настройке последовательности отправки уведомлений.

Источник

Zabbix. Отправка триггера с комментарием

Приветствую!
Решил поделиться небольшим скрипом (немного модифицированный оригинальный) по отправке уведомлений в Zabbix’е с пользовательскими комментариями.
Суть задачи: на работе используется Zabbix в основном для мониторинга удаленных сетей (доступность, немного качества). При отсутствии связи с удаленной сетью по должностной инструкции мы должны извещать об этом определенные отделы. Настроить обычную отправку почты не составило труда, но при такой отправке неясности у отделов хватало — по какой причине отключилась «сеть», как долго её не будет. Поэтому задался целью вставить в отсылаемое письмо комментарий водимый в дашборде при подтверждении триггера.
По сути, это тот же скрипт, что лежит в официальной документации Zabbix’а с одной небольшой вставкой:

Теперь про настройку действий:




В моем случае, отправка сообщения происходит спустя 30 минут, после возникновения триггера, в связи с тем, что требуется время для уточнения информации о причинах недоступности сети и ее устранения. По истечении 30 минут, если проблема не устранена, происходит уведомление пользователей, находящихся в группе «notification».

Недоработки скрипта:
1) Скрипт не понимает многостроковые комментарии. В этом случае он присылает текст во вложении. Кто знает как исправить — поделитесь мыслью.
2) Т.к. я, можно сказать единственный, кто взаимодействует с фронтэндом заббикса — то не делал вставку автора комментария. Но это в принципе реализуемо:

3) Сделано через стандартный mail, можно переделать через mutt, что бы добавить html и сделать все красиво.

Теперь об особенностях. Местоположение хоста берется из «Инвентарные данные» — «Местоположение»
Разделитель — «;»
Текст прописанный в действии:

В принципе можно менять все что угодно, главное найти соответствующий макрос, который можно посмотреть здесь

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

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

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

Запуск bat файлов на windows из zabbix

Модератор: SLEDopit

Запуск bat файлов на windows из zabbix

Сообщение hurma87 » 06.10.2016 08:58

Добрый день форумчане, занимаюсь настройкой zabbix сервера. Хочу настроить действие запуск bat-ника на удаленной машине на windows, при срабатывании триггера. Пробовал по разному, итог один batник не стартует

в событиях пишется выполнено, но батник не запущен

в событиях пишется выполнено, но батник не запущен

Пробовал через телнет

выходит ошибка prompt login

Может кто- нибудь подскажет, как запустить bat-ник или exe- шник по действию из zabbixа

общий скрин действий

Re: Запуск bat файлов на windows из zabbix

Сообщение yars » 06.10.2016 10:52

Re: Запуск bat файлов на windows из zabbix

Сообщение BSDevil » 06.10.2016 11:34

Re: Запуск bat файлов на windows из zabbix

Сообщение hurma87 » 06.10.2016 12:36

я показал все способы, которые пробовал, в идеале нужна команда которая передастся с сервера zabbix на агента, на нем включено EnableRemoteCommands=1,

и не могу понять куда идти без логов

Re: Запуск bat файлов на windows из zabbix

Сообщение BSDevil » 06.10.2016 17:19

хз, у меня так все работает

Re: Запуск bat файлов на windows из zabbix

Сообщение hurma87 » 07.10.2016 09:37

агент перестает стартовать, можешь показать как у тебя настроен шаблон templates windows desctop

Re: Запуск bat файлов на windows из zabbix

Сообщение Bizdelnick » 07.10.2016 10:08

Re: Запуск bat файлов на windows из zabbix

Сообщение hurma87 » 07.10.2016 11:38

вот мой файл конфиг агента

############ GENERAL PARAMETERS #################
LogFile=1
LogFile=C:\Program Files (x86)\Zabbix Agent\Zabbix_agentd.log
LogFileSize=100
DebugLevel=0
EnableRemoteCommands=1
LogRemoteCommands=1
Server=10.2.143.12
ListenPort=10050
StartAgents=3
ServerActive=10.2.143.12
Hostname=sitex1

вот настройка действия по триггеру

после срабатывания триггера в событиях отображено следующее

но батник не стартует

И спасибо, что тратите время мне на помощь

Re: Запуск bat файлов на windows из zabbix

Сообщение Bizdelnick » 07.10.2016 12:28

Re: Запуск bat файлов на windows из zabbix

Сообщение hurma87 » 07.10.2016 13:00

Источник

Запуск приложения на хосте по триггеру.

Коллеги, всем привет!

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

Если вам не лень, прошу расписать подробно: настройки агента, настройки элемента данных, настройки триггера, и настройки скриптов.

1. На хосте настраиваете bat файл на запуск блокнота.

2. На zabbix server настраиваете шаблон для мониторинга работы приложения notepad с триггером.

3. Создаете действие, которое срабатывает по триггеру. В действии указываете запуск bat файла на хосте.

В принципе, ничего сложного. Думаю, если вам реально надо, разберетесь.

Спасибо, статью давно прочитал, делал по аналогии, но не заработало. Поэтому спросил здесь в надежде на подробный ответ:)

Настройка конфига агента:

Действие (удаленная команда):

Вот, что пишет лог агента:

То есть, лог говорит «выполнение команды. «. Но по факту, ничего не происходит.
Куда копать?

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

Есть группа хостов, на которых запущена группа приложений.

Если хотя бы одно из приложений не работает на хосте, то хост не выполняет свою задачу на 100%.

В данный момент Zabbix мониторит сам факт работы приложений. Аллерты настроены, как надо.

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

Хочу, чтобы Zabbix сам запускал проблемное приложение.

P.S.: Агент запущен от пользователя «СИСТЕМА»

Чтобы это нормально работало, надо приложения запускать как службы, если они это умеют. И управлять уже службами. Если это не возможно, то надо тестировать и пробовать различные варианты запуска, чтобы приложения нормально стартовали.

@jojomsk не получится сделать так как ты написал.

Вот в чем проблема заббикс выполняет скрипт определенное время (смотри что у тебя в конфе прописано). Если скрипт не закрылся за это время то происходит его прерывание.

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

Это были причины почему так не работает. Теперь обсудим что сделать что бы работало.

Для начала создадим задачу в планировщике заданий. В нее вносим наш bat файл. Расписание не устанавливаем. Прописывает от имени кого пользователя ее запускать. Все сохраняем переходим к следующему шагу. Идем в заббикс создаем скрипт в поле команда пишем: «SCHTASKS /Run /TN test»

Где test название задачи из планировщика. Советую использовать en раскладку при именовании задачи что бы не издеваться над собой. Т.к заббикс на стороне сервера все вызывает из cmd.

Переходим на карту сети проверяем на узле работу скрипта, радуемся, переделываем действия в заббикс на такую команду и живем хорошо)

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

И да этот метод работает в проде уже более двух лет.

Источник

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

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

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

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

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

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

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

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

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

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

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

События

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

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

В случае наступления события (срабатывания тригера) сервер может выполнить действие. Например, отправить оповещение по 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 :

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

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

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

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

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

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

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

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

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

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

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

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

По аналогичной схеме описываются остальные зависимые элементы данных (параметры мониторинга), которые передаются в виде JSON’а. Вот пример описания числового параметра redis.info.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 дней и т.д.

Триггеры

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

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

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

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

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

Файл userparameter_XXX.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.

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

Источник