Вероятно, вы уже хорошо знакомы с Zabbix, работаете с ней не первый год и всё такое. Но не весь ее функционал лежит на поверхности. В этой текстовой расшифровке вебинара мы постарались раскрыть некоторые подробности работы с триггерами, тегами и вычисляемыми элементами. В частности, вы узнаете о том, как работать с ними более продуктивно и использовать возможности Zabbix на полную.
Триггеры
Триггеры — это, наверное, то, ради чего Zabbix и задумывался. Они оценивают пришедшие в систему данные и, если, условие триггера становится истинным, генерируют событие. Далее вы уже решаете кого и как в связи с этим событием оповещать.
Выражение, описанное в триггере может быть истинным или ложным. Как только оно становится истинным, Zabbix генерирует событие-проблему. Обратная ситуация приводит к созданию события-восстановления. Это происходит только по мере прихода новых данных в Zabbix. Нет новых данных — триггер будет молчалив и угрюм. Если в вашем триггере помимо обычных функций используются функции времени (например, dayofweek() < 7
), каждые 30 секунд будет дополнительно проводиться оценка. Если выражение станет истинным, появится событие-проблема.
Теперь давайте разберемся с полями триггеров, т.е. теми настройками, которые можно для них задать.
Имя. Обязательное поле, в котором задается название триггера. Называть его лучше максимально доступным языком, чтобы ваши коллеги тоже смогли потом понять. Название узла сети здесь можно не указывать, вы его и так увидите в представлении Проблемы.
Имя события. Необязательное поле. Однако, если его задать, именно его содержимое вы потом увидите в тексте события. Можно указать макросы типа {ITEM.VALUE} — значение элемента данных в момент перехода триггера в проблемный статус.
Оперативные данные. Поле хоть и не обязательное, но настоятельно рекомендуем вам его заполнить. Благодаря ему, в событии вы сможете увидеть текущее значение элемента данных, по которому сработал триггер. Поддерживаются макросы вида {ITEM.LASTVALUE}.
Важность. Критичность, с которой будет создано событие. Отнеситесь к этому серьезно, потому что правильный выбор критичности спасет часы сна вашим дежурным в будущем.
Генерация ОК событий. Это условие, по которому триггер будет переходить в состояние ОК. Рекомендуем этим пользоваться, т.к. наличие ОК-условий, отличных от проблемных позволит снизить количество ненужных переходов триггеров из одного состояние в другое. Чуть позже этому будет посвящен отдельный слайд.
Режим генерации событий ПРОБЛЕМА. Рекомендуемый режим — Одиночная. Это означает, что после возникновении проблемы появится только одно проблемное событие, даже после прихода новых данных, которые также будут отвечать условиям срабатывания триггера. В случае выбора Множественный, при каждом новом обновлении данных будет появляться новое событие. Если в вашем триггере есть функция времени, вы будете получать новое событие каждые 30 секунд. Множественный режим можно выбрать, если триггер основан на приходе SNMP-трапов, логов или других нерегулярных данных.
ОК событие закрывает. С помощью этой настройки можно закрывать только определенные события по условию совпадения тегов, которые сгенерировал этот триггер. Например, в вашем логе имеются события по компонентам приложения. Триггер создал отдельные события по отдельным компонентам, помеченные соответствующими тегами. Чтобы не закрыть случайно события по проблемным компонентам, можно использовать эту настройку.
Разрешить закрывать события вручную. Если разрешите, пользователи с правами Read-Write смогут закрывать события. Вот только они снова откроются, если проблема не устранена.
Имя пункта меню. Настройка позволит создать пункт в контекстном меню при нажатии на событии. Например, по такой ссылке вы сможете перейти в систему инцидент-менеджмента или в любую другую. Ссылка указывается в поле URL пункта меню.
URL пункта меню. Здесь можно указать ссылку для имени из предыдущего поля.
Описание. Человекочитаемое описание триггера для коллег.
Активировано. Выберите, если хотите создать триггер включенным.
События, генерируемые триггерами, могут быть закрыты тремя разными способами, перечисленными на слайде ниже. Мы чуть подробнее остановимся на втором пункте этого списка и расскажем, почему его использование упростит эксплуатацию Zabbix в будущем.
Всё дело во флаппинге. Это явление, при котором из-за колебаний метрики вокруг порогового значения, возникает генерация шумовых событий при переходе триггера из статуса Problem в OK и обратно. Настройки в поле Генерация ОК событий позволят снизить такие колебания. В этом поле вы можете указать, что восстановление триггера произойдет только при стабильных и устойчивых показателях метрики.
Проговорим ещё один важный момент триггеростроения. Для этого посмотрим на две функции расчета триггеров: avg и trendavg.
Начнем с avg. Чтобы ускорить вычисление выражений триггеров, вычисляемых элементов и некоторых макросов, в Zabbix есть опция кэширования значений (value cache). Этот кэш используется для доступа к историческим данным вместо SQL-запросов к БД. Если исторические значения отсутствуют в кэше, недостающие значения запрашиваются из БД, и кэш соответствующим образом обновляется. Очевидно, что если у вас много вычисляемых штук, то и кэш нужно держать большим.
Значения элементов остаются в Value Cache до тех пор, пока:
элемент удаляется (кэшированные значения удаляются после следующей синхронизации конфигурации)
значение элемента находится за пределами диапазона времени или количества, указанного в выражении триггера/вычисляемого элемента (кэшированное значение удаляется при получении нового значения)
диапазон времени или счетчика, указанный в выражении триггера/вычисляемого элемента, изменяется так, что для расчета требуется меньше данных (ненужные кэшированные значения удаляются через 24 часа).
А теперь перейдем к trendavg. Если value vache используется для расчетов по кратковременным периодам, то trend function cache для вычислений за значительно более длительные интервалы времени. С точки зрения накладных расходом вычисления по трендам менее ресурсоемкие, но и менее точные, т.к. для расчетов используются часовые значения вычисленных трендов.
Вывод — использовать уместные функции триггеров.
Есть еще чуть более сложные функции триггеров. Это триггеры, в которых вы можете использовать временные смещения и, например, сравнивать текущие значения метрики с показателями в прошлом.
Можно сравнивать не только часы, а и дни, недели и даже месяцы. Примеры на слайдах выше и ниже.
Следующая тема, которую разберем — операционные данные. Выше мы уже говорили про это поле, когда обсуждали поля настройки триггера. Его заполнение позволит вам увидеть текущие значения элемента данных в рамках проблемного события. Наличие этих данных позволит сотрудникам дежурной смены (или кому-то еще) наблюдать за текущим показанием метрики в режиме реального времени.
В операционных данных можно указать текущие значения элемента данных. Дополнительно, к таким значениям, можно применять функции регулярных выражений.
На слайде ниже, мы показали какие поля триггера можно заполнять операционными данными. Кроме них, там можно указывать макросы выражений.
На этом мы обсудили основные моменты по тонкостям настройки триггеров и переходим к следующей теме — тегам.
Теги
Теги — мощный инструмент в Zabbix, который пронизывает буквально всё. В этом разделе обсудим ключевые кейсы использования тегов и особенности их работы. Теги обычно используются в виде пары ключ-значение, чувствительны к регистру, могут также использоваться только в виде одного ключа.
Теги можно указывать на следующих уровнях в Zabbix: узлы сети, шаблоны, элементы данных и триггеры.
Набор этих тегов наследуется на каждом возникающем событии.
При помощи комбинации таких тегов, вы можете управлять действиями по соответствующим событиям: писать нужные условия, чтобы оповещения получали только релевантные сотрудники.
Далее разберемся с кейсами использования тегов. Первая функция — использование в ролевой модели. Доступ к узлам сети пользователям предоставляется на основе групп и дополнительно можно фильтровать отображаемые пользователям события на основе тегов.
Следующий кейс использования — создание событий на основе тегов. Тот набор тегов, который привязан к событию может быть использован в условиях действий.
Теги можно также использовать в условиях периодов обслуживания при дополнительной (помимо групп узлов сети) фильтрации узлов сети.
А еще в теги можно извлекать значения элементов данных. Дополнительно там могут быть использованы функции регулярных выражений.
При помощи тегов можно также рассчитывать вычисляемые элементы данных при помощи групп функций foreach. Чуть позже мы еще к этому вернемся.
Следующий кейс использования — это скрипты, которые вы можете вызвать из события. Например, для диагностики.
И последнее — теги могут быть использованы для корреляции событий.
При помощи глобальной корреляции событий вы можете закрывать старые или новые события, чтобы минимизировать влияние шумовых событий на сотрудников, которые на них реагируют.
Мы разобрали возможные кейсы использования тегов. Если знаете другие — приходите в комментарии.
Вычисляемые элементы данных
Для начала обсудим свойства вычисляемых элементов. Не будем дублировать — все на слайде ниже:
Остановимся на одной особенности вычисляемых элементов — возможности агрегации данных с разных узлов сети. Для этого есть семейство функций foreach, которые можно использовать как по-отдельности, так и в сочетании с основными функциями, такими как sum, avg и т.д. На слайде ниже перечислены все такие возможные функции.
А теперь давайте посмотрим на примеры использования этих функций. Вы можете работать с данными как на основе тегов, так и на основе названий групп, можно использовать логические выражения и дополнительные функции из арсенала Zabbix. Чуть подробнее мы разбирали эти функции в нашем телеграм-канале в отдельном посте.
Вычисляемые элементы данных — мощный инструмент Zabbix, который позволяет создавать дополнительные разрезы для оценки производительности ваших систем.
Мы постарались рассказать о нашем опыте использования триггеров, тегов и вычисляемых элементов. Если у вас есть чем дополнить — добро пожаловать в комментарии. Ниже полезные ссылки:
Комментарии (3)
Adgh
10.11.2024 10:43Возможно как-то настроить тригер таким образом, чтобы он не срабатывал в период регулярного (планового обслуживания), но при этом чтобы метрике все продолжали записываться?
Abyss777
Насколько я понимаю в 7.0 тоже не добавили возможность использовать Теги в Выражении триггера?
Например чтоб триггер срабатывал только для хостов с определённым тегом...
mischmasch
А обещали?