Бывают случаи когда некий узел в Zabbix надо мониторить в зависимости от времени суток. Например если он регулярно выключается на выходные или на ночь, то и собирать лишние алерты от триггеров нет смысла. Как это можно реализовать?
Я знаю три варианта.
1. Использование функции time в условии триггера.
2. Настроить период обслуживания на ваш узел.
Вам следует указать период обслуживания и выбрать типа обслуживания «без сбора данных». А чтобы узел не маячил на панели после надо отключить отображение обслуживаемых узлов фильтром панели.
3. И вариант с пользовательским интервалом в элементе данных.
Имеется возможность создания пользовательских правил относительно времени, когда элемент данных будет опрашиваться. Для этого есть два способа:
— гибкие интервалы (flexible), который позволяет переопределить интервал обновления по умолчанию,
— по расписанию (scheduling), посредством чего элемент данных может быть опрошен в конкретное время или последовательность времени.
Например если задать для гибкого интервала значение 1m с периодом «1-5,08:00-17:00» то элемент будет опрашиваться с частотой в 1 минуту только в рабочее время.
А если указать значение 0 с периодом «6-7,00:00-24:00» то элемент данных НЕ будет опрашиваться по выходным.
Выбор за вами.
Итак, Заббикс. Система, по меньшей мере, неочевидная — но спустя некоторое время ее логика становится ясна. Самый главный плюс сервера Zabbix — то что все проверки настраиваются через веб-интерфейс. Редактирование файликов — только для агента, да и там мороки немного.
Полноценной литературы к Zabbix’у — только его вики, но разработчики не делают копию статьи если в ней по сравнению с предыдущей версией поменялось немного, предполагая что у желающих найдется время прочесть документацию ко всем выпускам и листы изменений между версиями. Но, конечно, есть и царский путь: пойти учиться. Стоимость обучения какие-то жалкие 1500$.
Теперь — самое важное, что следует о нем знать! Перед тем как что-то делать, нужно распланировать это, в голове или на бумаге. На бумаге будет лучше — спустя некоторое время не придется вспоминать чего там как. Заббикс позволяет мониторить все что угодно, но из-за неочевидности многих моментов люди сталкиваются с множеством проблем: тормозами, несрабатыванием триггеров и приходом пятидесяти сообщений в секунду. Это все решается стандартным инструментарием в сочетании с планированием.
Сразу после установки НЕОБХОДИМО удалить все предоставленные для примеров шаблоны, элементы и триггеры. Если их просто взять и применить к машинам — тормоза гарантированы. Они не просто избыточны, они ИЗБЫТОЧНЫ!!!!!111Так же можно удалить предустановленные группы, все равно придется создавать свои собственные.
Для начала требуется создать группу узлов сети (Настройка — Группы узлов сети). Это важно — без группы нельзя создать ни узел, ни шаблон. Сама по себе группа никаких свойств не имеет и не назначает, это простое объединение. В АЖНО: Шаблоны, находящиеся в группе узлов НЕ ПРИМЕНЯЮТСЯ к узлам находящейся в этой же группе. О привязке шаблонов будет позже.
Теперь создаем узел сети (Настройка — Узлы сети). По пунктам
Имя узла сети — некое внутреннее имя, которым Заббикс будет манипулировать внутри себя. Так же применяется для включения активных проверок в агенте Заббикс (о нем тоже позже). Недопустима кириллица или пробелы.
Видимое имя — применяется только в списках узлов и может применятся в оповещениях.
Группы — в каких группах узел находится. Может находиться сразу в нескольких, если это нужно по соображениям безопасности (в Zabbix пользователям можно настраивать доступ к узлам в зависимости от прав)
Описание — все ясно и так.
Наблюдение через прокси — Для разгрузки сервера можно использовать прокси, которые будут собирать информацию с агентов самостоятельно, а затем передавать ее на сервер. Прокси настраиваются отдельно, и затем их можно выбрать в этом списке.
Активировано — все ясно и так.
Вкладки в этом окне позволяют производить дополнительные настройки, которые я рассматривать не буду.
Нажимаем «Сохранить» и переходим к следующему шагу: созданию элемента данных. Опционально сначала можно создать группу элементов данных, процедура полностью аналогичная группе узлов сети.
Имя — аналогично «имени узла сети».
Интерфейс узла сети — все ясно и так.
Тип информации — Какой тип данных будет храниться в базе. Указывать его обязательно, поскольку в случае неправильного типа элемент данных работать не будет. Узнать об этом получится не сразу, а только спустя некоторое время, которое требуется веб-интерфейсу Zabbix на передачу команд движку, выполнения команды движком и возвращением ошибки веб-интерфейсу. Это может занять изрядное время.
Тип данных — если тип информации «Целое положительное» то предлагает выбрать в какой системе счисления это целое записывать.
Единица измерения — можно оставить пустым, но лучше заполнить. Дело в том, что данные которые Zabbix получает можно посмотреть в разделе Мониторинг-Последние данные, там список из «Имя элемента данных» — «Значение элемента данных». Если указать единицу измерения, она будет отображаться и там. Если измеряется размер, то стоит указывать B (байты), Zabbix сам подставит правильный множитель.
Пользовательский множитель — все ясно и так.
Интервал обновления (в сек) — Частота с которой обновляется содержимое элемента данных. О ЧЕНЬ КОВАРНАЯ ШТУКА! Дело в том, что у ключей простых проверок может быть некая длительность запроса, и если она больше интервала обновления (к примеру, обычный ping в случае с Zabbix посылает пять пакетов, раз в секунду. Это настраивается, надо лишь слегка почитать встроенную документацию) то полученные данные будут непредсказуемыми, поскольку заббикс будет слать серии пингов с нескольких дочерних процессов. Так же имеет смысл не опрашивать слишком часто то, что слишком часто не меняется. Скажем, раз в 30 секунд узнавать размер используемого SWAP, свободного места на диске или состояния SMART не обязательно, а в базу эти значения записываться будут.
Переменные интервалы — здесь задается расписание, по которому будет изменяться интервал, если это необходимо.
Период хранения истории (в днях) — Сколько времени в базе будет храниться история изменения этого элемента. Можно ставить 1 день, но нельзя ставить 0 (в этом случае триггеры работать не будут). Слишком долго историю хранить тоже не стоит, база данных все же не резиновая. Этот параметр, в отличие от следующего, хранит КАЖДОЕ значение, записанное в базу с частотой интервала обновления.
Период хранения динамики изменений (в днях) — Сколько времени в базе будет храниться УСРЕДНЕННОЕ ЗА ДЕНЬ значение элемента. На это требуется гораздо меньше места в базе, а для статистики подходит ничуть не хуже. Впрочем, все зависит от того что мониторится.
Хранение значения — будет ли в базе хранится само значение, или его изменение относительно предыдущего значения. Отображение значения — преобразование значения в другой формат, более приемлемый для чтения человеком. В частности, есть режим отображения как «Zabbix agent ping status». Влияет только на то, как значение будет выглядеть в Мониторинг — Последние данные.
Нажимаем Добавить и переходим к триггерам.
Имя триггера — аналогично «Видимому имени узла сети». Будет отображаться в уведомлении (если настроить) так что стоит делать его информативным.
Многократная генерация событий «ПРОБЛЕМА» — все ясно и так, но я пока ни разу это не использовал.
URL — можно указать адрес с решением этой проблемы в базе знаний.
Важность — В основном нужно для определения какой тип уведомления использовать. Например, Предупреждения слать на e-mail, а Чрезвычайные — как SMS.
Зависимости — та самая вещь, про которую очень многие забывают. Зависимые триггеры не выполняют действий и не шлют оповещений, если триггер от которого они зависят сработал. В итоге вместо 30 писем о недоступности рабочих станций вы получите только одно письмо о том что выключили свет. С зависимостями тем не менее есть один важный момент — зависимые триггеры должны срабатывать МЕДЛЕННЕЕ, чем тот от которого они зависят. Если зависимые триггеры сработают быстрее то толку от зависимостей не будет.
Итак, триггеры есть, теперь самое важное — действия. Действия настраиваются в Настройка — Действия
ОБЯЗАТЕЛЬНО удалите действие по умолчанию. Оно шлет набитое малополезной информацией сообщение всем пользователям-админам, всеми доступными способами. Уведомления должны быть краткими и информативными (хотя бы те, которые будут отправляться СМСкой)
Создаем новое действие. Источник события — Триггеры.
Имя — информативное имя, по которому сходу можно понять за что отвечает действие.
Тема по умолчанию — то, что будет прислано в поле «Тема» электронного письма или первой строкой для Jabber и СМСки. Сообщение по умолчанию: здесь можно писать ВСЕ ЧТО УГОДНО! По умолчанию шлется такое количество технической информации, что не сразу понятно что куда и как.
Сообщение о восстановлении — Если триггер вернулся в нормальный режим, прислать сообщение, указанное в полях ниже (они появятся, если поставить галочку).
Тип вычисления — здесь можно выбрать логическую формулу,по которой будут вычисляться условия.
Условия — Условия, по которым действие будет определять что выполняться должно именно оно. По умолчанию используется «Состояние обслуживания не в обслуживании» и «Значение триггера = ПРОБЛЕМА». Под это условие попадают ВСЕ триггеры, что чаще всего не нужно. Стоит добавить другое условие, для того чтобы конкретизировать условия.
Длительность шага операции по умолчанию — сколько времени будет выполняться между шагами, если это значение в шаге не указано.
Далее добавляется сама операция. Их всего две — «Отправлять сообщение» и «Удаленная команда». В обоих случаях все интуитивно понятно. Разве что при «Отправить сообщение» маленькая строка «Добавить» добавляет шаг операции, а кнопка «Добавить» ниже создает действие.
Вступление
Теперь когда наши сервер и агенты запущены и работают давайте посмотрим как создать наши первые узлы сети и элементы данных.
Узлы сети
Элементы данных
Элементы данных отвечают за сбор данных с узлов сети, давайте посмотрим как они создаются.
Перед созданием элемента можно проверить правильно ли он настроен.
Всё хоршо. Добавляем.
Заключение.
Мы бегло рассмотрели основные настройки при создании узлов сети и элементов данных в Zabbix и как их создавать.
Аverage rating :
Литейный пр., д. 26, Лит. А
+7 (812) 403-06-99
ООО «ИТГЛОБАЛКОМ ЛАБС»
I am on Zabbix 3.2.3 on RHEL 7.x
The update interval for my Item is 1800s i.e., 30 minutes.
When the Item is enabled it runs and executes a bash script which I created as an external check every 10 minutes and not every 30 mins (which I had configured in the Item’s update interval field). I am not able to understand why this is happening. I dont have any custom intervals for this Item.
The bash script runs fine from the zabbix host in the bash shell in external scripts folder and also can be invoked from the zabbix web UI successfuly.
Since the item is listed with an «unsupported» status, could this be the reason ?
BTW I have tested the end-to-end scenario successfully on my local docker with zabbix 3.2.11 and 3.4.0 and everything works perfectly.
Can someone please help me troubleshoot this ?
asked Feb 23, 2019 at 6:08
2 gold badges12 silver badges27 bronze badges
the reason why it is executed is, that the status is unsupported.
When a item is not working correctly, it trys every 10 minutes to retrieve a new value to see if it’s working again. ( Or what you have defined as unsupported retry value)
You have to check why it’s returning unsupported, most of the time you can just hover over the «unsupported» text and it shows you what is causing the problem.
Setting the debug log level in the agent to 3 or 4 helps find the problem
answered Feb 25, 2019 at 8:16
5 gold badges28 silver badges42 bronze badges
Привет. Продолжаем освещать нововведения Zabbix 3.4. Сегодня поговорим об использовании макросов в интервалах обновления и других временных периодах.
Пару слов о макросах
Пользовательские макросы – давно зарекомендовавший себя механизм, используемый в Zabbix повсеместно и дающий системе мониторинга необходимую ей гибкость. По сути это переменные, которые вы можете назначать с глобальным уровнем видимости, шаблона или узла сети. Использование макросов всячески приветствуется и рекомендуется, например в шаблонах, что делает их настраиваемыми в других окружениях и другими пользователями.
Выглядят пользовательские макросы следующим образом, вы их наверняка уже встречали:
Интервалы обновления и хранения истории
Zabbix позволяет гибко настраивать время опроса метрик: у каждой метрики может быть свой собственный интервал.
Обновления каждой метрики также могут быть «гибкими»(см. Пользовательские интервалы), а значит происходить по определенному расписанию («раз в сутки ночью» или «в 9:00 утра в будни»).
Аналогичным образом мы можем определить время хранения истории и трендов для каждого элемента данных отдельно.
Подобная тонкость настройки нужна далеко не всегда, поэтому использование макросов дает пару новых идей по настройке этих параметров.
Варианты использования
Во-первых, интервалы обновления метрик (как обычные, так и пользовательские интервалы), о которых сказано выше, теперь поддерживают пользовательские макросы. Во-вторых, использовать макросы можно и в интервалах хранения истории и трендов. В итоге это выглядит вот так:
Просто задайте значения этих макросов глобально, а потом переназначайте на уровне шаблона или узла сети, если требуется:
В общем, для интервалов обновлений можно создать небольшой глобальный набор макросов, которые затем использовать по умолчанию для всех новых элементов данных, в зависимости от их типа и важности. Например:
Это позволит не тратить каждый раз время на обдумывание «я хочу собирать эту метрику раз в 60 или раз в 61 секунду? или может раз в 5 минут будет достаточно?», а просто использовать принятые на вашем сервере и проекте правила по сбору и хранению элементов данных, зафиксированные в глобальных макросах. Хотя, возможно, такой вариант подойдет не всем 🙂
В низкоуровневом обнаружении
Поддерживается и контекст макросов, что может быть очень полезно, например, при LLD.
Представьте, что мы собираем трафик сетевых интерфейсов на множестве устройств. Чтобы не нагружать Zabbix, мы бы хотели сделать следующим образом:
Затем используем их в прототипе элемента данных интерфейса, но уже с контекстом (в данном случае это будет имя интерфейса ifName):
Уже на уровне узла сети укажем новое значение макроса с контекстом для ключевого интерфейса (для примера возьмем Gi0/0.114):
Теперь посмотрим частоту обновления и время хранения для различных интерфейсов в «Последних данных». Как видно, у нашего очень важного Gi0/0.114 теперь свои правила хранения и сбора:
Если же мы захотим изменить общий интервал или увеличить частоту опроса или времени хранения еще одного интерфейса — нам нужно будет просто переназначить макросы на уровне хоста. Изменять шаблон, прототип и ждать обнаружения не потребуется — все применится сразу. На самом деле, даже доступ на запись к шаблону не требуется.
Где еще?
А еще макросы теперь можно применять в других ситуациях, где нужно было указывать время или период. Например, в действиях:
или указать через макрос время доступности инженера для автоматических уведомлений:
С точным списком мест, в которых возможно применение макросов, можно ознакомиться здесь.
В итоге
Новые возможности макросов в 3.4 открывают парочку неплохих возможностей: с одной стороны — для более тонкой настройки (для LLD), а с другой стороны — для централизации и управления временем опроса и хранения. И кстати, в интервалах времени появилась поддержка суффиксов s,m,h,d,w — мелочь, а удобно 🙂
P. S. Статья также доступна в нашем блоге на английском языке.
