Visitors have accessed this post 11463 times.

Упрощаем работу с оповещениями в zabbix — настраиваем теги

2
0
11463
14 августа 2020 15:06
Автор: Rebrain Me
DevOps

Visitors have accessed this post 11463 times.

Автор — Евгений Генеральчик

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

Как же быть? Частично снизить количество уведомлений об инцидентах можно разграничением по группам пользователей.

Но настроить правила обработки действий при возникновении какой-либо проблемы в zabbix весьма непросто. Чтобы получать определенные уведомления, нужно привязываться к хостам, темплейтам, триггерам и, чем больше таких привязок, тем сложнее расчет сопоставлений всех этих параметров. А значит, в нем немудрено заблудиться, что приводит либо к неполучению нужных уведомлений либо к получению уймы ненужных.

Выходом является использование тегов.

В zabbix как к хостам, так и к триггерам можно привязывать теги и формировать правила оповещений уже по ним, что значительно упрощает этот процесс. Причем все теги указываются в виде Name: Value, что, хоть и кажется поначалу неудобным, впоследствии становится весьма полезным.

Давайте рассмотрим пример. Так выглядело одно из правил до использования тегов.

В приведенном примере указывались:

  • совпадение групп хостов (A, B, C)
  • совпадение темплейта (D, E, F, G)
  • совпадение части имени триггера (H, I, J, K, L, M)

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

Разберем простую схему: у нас есть несколько окружений (prod, stage и dev), в каждом из них — несколько типов хостов (k8s-node, database) и несколько машин, которые сложно объединить в какой-то один тип (пусть будут other).

Начнем с добавления тегов для хостов. Каждый хост будет иметь два тега — env и type. env может принимать одно из значений prod, stage или dev. А type — соответственно, k8s-node, database или other. Уже на основе этих тегов можно поделить большую часть уведомлений для разных команд.

Однако даже с машин одного типа получать все уведомления может оказаться лишним. И здесь на помощь приходят теги для триггеров. Особенно это касается хитрых кастомных айтемов/триггеров. Имеет смысл добавить теги, чтобы разделить оповещения по командам и даже для дробления на уровни внутри команды. Для триггеров в этом примере был использован тег source (источник данных для триггера).

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

Aenv:prod, Bsource:pgsql.

И вот так стало выглядеть наше правило с использованием тегов.

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

К сожалению, в официальном мануале от zabbix не указано, как задавать теги, наверное, потому, что делать это еще проще, чем указывать значение макросов.

А вот почитать о том, как настраивать темплейты, можно тут.

А про правила обнаружения — здесь.

Давайте подытожим.

Что нам дает использование тегов:

  • у нас теперь есть простые правила для работы с оповещениями;
  • инфраструктура в системе мониторинга структурирована;
  • обрабатывать уведомления становится проще.

По последнему пункту небольшое пояснение: под обработкой уведомлений я подразумеваю использование сервисов, занимающихся пересылкой, а иногда еще и систематизацией уведомлений (Opsgenie, Amixr, Pagerduty etc.).

От редакции

Если вам интересно посещать бесплатные онлайн-мероприятия по DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN

*Анонсы мероприятий каждую неделю

Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.
Наш Youtube-канал — https://www.youtube.com/channel/UC6uIx64IFKMVmj12gKtSgBQ.

Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.

 

Комментарии (3)
Введено символов из возможных
Не отвечать

Вам также может понравится

Программный RAID в Linux. Часть 1
array(1) { [0]=> object(WP_Term)#11548 (16) { ["term_id"]=> int(6) ["name"]=> string(5) "Linux" ["slug"]=> string(5) "linux" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(6) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(28) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(6) ["category_count"]=> int(28) ["category_description"]=> string(0) "" ["cat_name"]=> string(5) "Linux" ["category_nicename"]=> string(5) "linux" ["category_parent"]=> int(0) } } Linux

Автор — Максим Рязанов

Смотрите также — Wikipedia:RAID.

Избыточный массив независимых дисков (RAID) — это технология хранения, которая объединяет несколько компонентов дисков (как правило, дисководы или их разделы) в логическое устройство. В зависимости от реализации RAID эта логическая единица может быть файловой системой или дополнительным...

9
0
11 декабря 2020
Docker — установка, настройка и первые шаги в системе
array(1) { [0]=> object(WP_Term)#976 (16) { ["term_id"]=> int(8) ["name"]=> string(6) "Docker" ["slug"]=> string(6) "docker" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(8) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(8) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(8) ["category_count"]=> int(8) ["category_description"]=> string(0) "" ["cat_name"]=> string(6) "Docker" ["category_nicename"]=> string(6) "docker" ["category_parent"]=> int(0) } } Docker

Автор - Юрий Власов

Docker – де-факто стандартный движок контейнеризации, который повсеместно используется для запуска приложения как в окружениях для разработки, так и в публичных\высоконагруженных средах. Подробнее о терминологии можно узнать здесь.

В этой статье я расскажу, как поставить и запустить Docker локально и начать знакомство с...

9
0
21 августа 2020
Почему IaaS — это идеальный вариант для стартапов
array(1) { [0]=> object(WP_Term)#11548 (16) { ["term_id"]=> int(7) ["name"]=> string(6) "DevOps" ["slug"]=> string(6) "devops" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(7) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(19) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(7) ["category_count"]=> int(19) ["category_description"]=> string(0) "" ["cat_name"]=> string(6) "DevOps" ["category_nicename"]=> string(6) "devops" ["category_parent"]=> int(0) } } DevOps

Перевод статьи — https://hackernoon.com/why-infrastructure-as-a-service-is-ideal-for-startups-kw963wa1

В то время как облака доминируют во всех аспектах технологий, применяемых пользователями, такие вещи, как предоставление личной электронной почты для управления объектами как в CRM — это все еще чистой воды миф. Поэтому отрасль все больше...

0
0
12 марта 2021