Visitors have accessed this post 1105 times.

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

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

Visitors have accessed this post 1105 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)
Введено символов из возможных
Не отвечать

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

Преимущества и недостатки DevOps Engineer
array(1) { [0]=> object(WP_Term)#11265 (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(14) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(7) ["category_count"]=> int(14) ["category_description"]=> string(0) "" ["cat_name"]=> string(6) "DevOps" ["category_nicename"]=> string(6) "devops" ["category_parent"]=> int(0) } } DevOps

Как у любой методологии, у DevOps есть свои сторонники, а есть и критики. И как любая методология, DevOps не является чудесной таблеткой или серебряной пулей, которая способна по волшебству решить все ваши проблемы. У нее есть и преимущества, и некоторые недостатки. О них мы и поговорим.
Преимущества DevOps
Как мы помним, методология DevOps...

2
0
28 августа 2020
Программный RAID в Linux. Часть 1
array(1) { [0]=> object(WP_Term)#912 (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(27) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(6) ["category_count"]=> int(27) ["category_description"]=> string(0) "" ["cat_name"]=> string(5) "Linux" ["category_nicename"]=> string(5) "linux" ["category_parent"]=> int(0) } } Linux

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

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

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

6
0
11 декабря 2020
Nmap — 3 часть
array(1) { [0]=> object(WP_Term)#11265 (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(27) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(6) ["category_count"]=> int(27) ["category_description"]=> string(0) "" ["cat_name"]=> string(5) "Linux" ["category_nicename"]=> string(5) "linux" ["category_parent"]=> int(0) } } Linux

Часть 3
Автор — Сергей Попов

1 часть статьи
2 часть статьи
Обход IDS/Firewall and spoofing
«А может, тебе еще ключ от квартиры, где деньги лежат?»
Не существует такой магической опции, которая позволяла бы обнаруживать и обходить брандмауэры и IDS (intrusion detection systems). Для этого необходимы навыки и опыт. Ниже только некоторые...

4
0
18 сентября 2020