Zabbix действия сообщение по умолчанию
Обновлено: 08.05.2024
Zabbix — замечательный продукт для администраторов крупных программно-аппаратных комплексов. Он настолько хорош, что может использоваться не только крупным бизнесом, но и средне-малым бизнесом, и даже в pet -проекте. В общем, у меня есть небольшой опыт работы с Zabbix'ом и я смело могу рекомендовать его к использованию.
Правда я не могу сказать, что понимаю "философию Zabbix'а". Несмотря на обширную подробную документацию на русском языке, мне было сложно погружаться в мир Zabbix'а — создавалось ощущение, что мы с разработчиками одни и те же вещи называем разными именами. Возможно потому, что Zabbix создавался админами для админов, а я всё-таки больше разработчик и пользователь.
Тем не менее, для запуска Zabbix'а и для мониторинга основных параметров компьютерных систем (процессор, память и т.п.) навыков обычного linux-пользователя хватает. Есть большое количество плагинов от сторонних разработчиков, расширяющих возможности Zabbix'а. Для моих нужд мне потребовалось настроить мониторинг Redis-сервера. Я немного покопался в коде имеющихся плагинов и на их примере выяснил, что архитектура Zabbix'а позволяет достаточно просто подключать к мониторингу любые параметры информационных систем, которые могут быть выражены в числовом виде.
Под катом — пример Zabbix-плагина с моим пояснением по терминологии Zabbix'а. Кому-то этот пример покажется наивным, ну а кому-то поможет проще освоиться с понятиями. В любом случае, Zabbix достаточно велик для того, чтобы ощупать его с разных сторон.
Кратко о некоторых понятиях, которые используются в Zabbix'е: agents, items, triggers, actions, notifications, templates.
Сервер и агенты
С точки зрения пользователя Zabbix делится на две большие части: сервер и агенты. Сервер располагается на одной машине, которая собирает и хранит статистические данные, а агенты — на тех машинах, данные с которых собираются:
Параметры мониторинга
Любая величина, которая может выражена в числовом или строковом виде, называется в терминологии Zabbix'а — элементом данных (item). Каждый элемент связывается с уникальным ключом (именем). Вот примеры элементов данных:
Значения этих элементов данных (параметров мониторинга) привязываются ко времени, история значений параметров сохраняется в базе сервера.
События
При наступлении некоторого события в Zabbix'е срабатывает триггер. Например,
- >10 — среднее значение параметра за последние 5 минут превысило "10"
- >0 — текущее значение параметра не равно предыдущему значению
По сути, триггеры — это формулы, в которых переменными выступают параметры мониторинга (текущие и сохранённые), и которые на выходе дают true / false .
Действия и Оповещения
Шаблоны
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:
Вычисляемый элемент данных
Для вычисления фрагментации памяти используется отношение used_memory_rss / used_memory и на его базе определяется триггер, срабатывающий при превышении отношением значения 1.5. В Zabbix'е есть вычисляемый тип элементов данных:
Триггеры
Вот пример триггера, срабатывающего при излишней фрагментации памяти:
Ничего необычного, за исключением формата выражений, используемого в формуле изменения состояния триггера. В 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.
Спасибо всем, кто дочитал до конца, а особенно тем, кто нашёл в публикации что-то полезное для себя.
Вы можете указать следующие операции для всех источников:
Zabbix сервер не создает оповещения, если доступ к узлу сети "запрещен" пользователю явным образом, который задан в операции получателем, или, если пользователь вовсе не имеет заданных прав доступа к этому узлу сети.
Для событий обнаружения и авторегистрации, также доступны дополнительные операции:
Настройка операции
Для настройки операции, в диалоге настройки действия перейдите на вкладку Операции и в блоке Операции нажмите на Новая. Измените шаг операции и нажмите Добавить для добавления в список Операции.
Все обязательные поля ввода отмечены красной звёздочкой.
Operation details
| Parameter | Description | |||
|---|---|---|---|---|
| Operation | Select the operation: Send message - send message to user - execute a remote command. Commands are available for execution if previously defined in global scripts with Action operation selected as its scope. More operations are available for discovery and autoregistration based events (see above). | |||
| Steps | Select the step(s) to assign the operation to in an escalation schedule: From - execute starting with this step To - execute until this step (0=infinity, execution will not be limited) | |||
| Step duration | Custom duration for these steps (0=use default step duration). Time suffixes are supported, e.g. 60s, 1m, 2h, 1d, since Zabbix 3.4.0. User macros are supported, since Zabbix 3.4.0. Several operations can be assigned to the same step. If these operations have different step duration defined, the shortest one is taken into account and applied to the step. | |||
| Operation type: send message | ||||
| Send to user groups | Click on Add to select user groups to send the message to. The user group must have at least "read" permissions to the host in order to be notified. | |||
| Send to users | Click on Add to select users to send the message to. The user must have at least "read" permissions to the host in order to be notified. | |||
| Send only to | Send message to all defined media types or a selected one only. | |||
| Custom message | If selected, the custom message can be configured. For notifications about internal events via webhooks, custom message is mandatory. | |||
| Subject | Subject of the custom message. The subject may contain macros. It is limited to 255 characters. | |||
| Message | The custom message. The message may contain macros. It is limited to certain amount of characters depending on the type of database (see Sending message for more information). | |||
| Operation type: remote command | ||||
| Target list | Select targets to execute the command on: Current host - command is executed on the host of the trigger that caused the problem event. This option will not work if there are multiple hosts in the trigger. Host - select host(s) to execute the command on. Host group - select host group(s) to execute the command on. Specifying a parent host group implicitly selects all nested host groups. Thus the remote command will also be executed on hosts from nested groups. A command on a host is executed only once, even if the host matches more than once (e.g. from several host groups; individually and from a host group). The target list is meaningless if a custom script is executed on Zabbix server. Selecting more targets in this case only results in the script being executed on the server more times. Note that for global scripts, the target selection also depends on the Host group setting in global script configuration. Target list option is not available for Service actions because in this case remote commands are always executed on Zabbix server. | |||
| Conditions | Condition for performing the operation: Not ack - only when the event is unacknowledged Ack - only when the event is acknowledged. Conditions option is not available for Service actions. | |||
When done, click on Add to add the operation to the list of Operations.
Except where otherwise noted, Zabbix Documentation is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
Если вы хотите, чтобы некоторые операции выполнялись в результате событий (например, отправка оповещений), вам нужно настроить действия.
Действия можно задать для событий со всех поддерживаемых источников:
- События на триггеры - при изменениях состояния триггеров с ОК на ПРОБЛЕМА и обратно
- События на обнаружения - когда производится сетевое обнаружение
- События на авторегистрацию - при авторегистрации новых активных агентов
- Внутренние события - когда элементы данных становятся неподдерживаемыми и триггеры переходят в неизвестное состояние
Настройка действия
Для настройки действия, сделайте следующее:
- Перейдите в Настройка → Действия
- Из выпадающего меню Источник события выберите требуемый источник
- Нажмите на Создать действие
- Укажите общие атрибуты действия
- Выберите осуществляемую операцию, на вкладке Операции
- Выберите условия при которых эта операция будет происходить, на вкладке Условия
Общие атрибуты действий:
Except where otherwise noted, Zabbix Documentation is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Введение
Косвенно данную тему я затрагивал в статье про повторяющиеся уведомления в zabbix. Основа для настроек одна и та же. Очень подробно этот вопрос освещен в официальной документации, в разделе Эскалации. Рекомендую ознакомиться, там все показано на примерах.
Я же кратко на своем примере покажу, как отложить отправку оповещения на 5 минут. Иногда надоедают какие-то триггеры, приходится их отключать, чтобы не спамили. Но если триггер отключить, то информации по нему не будет вообще никакой. Чаще всего хочется отключить именно уведомление, а не сам триггер. В таком случае, информация о его срабатывании сохранится в истории системы мониторинга.
Одни из вариантов решения этой проблемы - добавление исключения в дефолтное правило оповещений, которое чаще всего остается после настройки. То есть можно сделать вот так:
Оповещения о триггерах с указанными названиями отправляться не будут. Я просто привел пример одного из подходов. Дальше расскажу, как сделать так, чтобы если триггер сработал и завершился в течении 5 минут, оповещение о нем не придет. Если же за 5 минут триггер не выключится, то оповещение будет отправлено.
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:
То же самое на Debian 10, если предпочитаете его:
Отложенное оповещение
Для настройки отложенного оповещения идем в web интерфейс zabbix сервера, в раздел Configuration -> Actions и выбираем правило оповещения, которое будем изменять. Я для примера возьму дефолтное правило Report problems to Zabbix administrators.
Идем во вкладку Operations и меняем Default operation step duration на 5m, если вы хотите отложить отправку оповещения на 5 минут. Далее редактируем шаг исполнения. В разделе Steps ставим значения 2 - 2. Изначально там стоит 1 - 1. То есть мы указываем, выполнить отправление со второго шага, а длину шага ранее установили в 5 минут.
Вот и все. Я показал на простом примере, как отложить отправку оповещения о событии в zabbix.
Проверка отложенных уведомлений
Для проверки отложенного уведомления, достаточно дождаться срабатывания какого-нибудь триггера. Вот мои примеры, когда оповещение не было отправлено вовсе, так как триггер работал менее 5 минут. И рядом же пример отправки уведомления только через 5 минут после срабатывания триггера.
Последнее событие длилось 1 минуту. Во время бэкапа сайта сработал триггер на нехватку места. После завершения бэкапа, скрипт подчистил за собой следы и места стало достаточно. Все случилось в течении 1 минуты, так что оповещения я вообще не получил.
Второе событие длилось 6 минут. Оповещение было отправлено только через 5 минут после срабатывания триггера.
Заключение
Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!
Таким нехитрым способом вы можете контроллировать количество оповещений от системы мониторинга. Чем их меньше, тем лучше. Оставлять нужно только то, что действительно критично и требует внимания. Спам бесполезных оповещений снижает бдительность и приводит к тому, что на оповещения просто перестают реагировать. Это неправильно, не нужно доводить до такого состояния. Калибровка системы мониторинга, чтобы она стала помощником, требует постоянных усилий и внимания. Но без нее никуда.
Онлайн курс по Kubernetes
Онлайн-курс по Kubernetes – для разработчиков, администраторов, технических лидеров, которые хотят изучить современную платформу для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест.
Читайте также: