Начиная с Zabbix 5.4, теги элементов полностью заменили приложения. Это конструктивное решение позволило нам реализовать множество новых улучшений в плане удобства использования – от предоставления дополнительной информации и классификации отмеченных тегами объектов до определения условий действий и разрешений безопасности с помощью ссылок на конкретные теги и их значения. Давайте рассмотрим, как определяются теги в официальных шаблонах Zabbix и некоторые потенциальные случаи использования тегов при настройке действий и разрешений доступа.
Table of Contents
Использование тегов в Zabbix 6.0
На смену устаревшим “приложениям”(Application) пришли теги, о которых я хотел бы сегодня рассказать поподробнее.
Основное отличие тегов от приложений в том, что теги задаются с использованием имени и значения, что значительно расширяет их область применения. Сейчас теги используются в элементах данных, триггерах, узлах сети, сервисах, в группах пользователей для настройки прав доступа и много ещё где, и я уверен, что область их применения будет увеличиваться с каждым новым релизом.
Ввиду структурного отличия “приложений” от тегов, пришлось адаптировать инструменты фильтрации. Например в разделе “Последние данные” в Zabbix 6.0 были переработаны суб фильтры для более удобной работы с тегам. Группировка тегов по имени позволила сократить место и сделать работу с суб фильтрами более интуитивной.
И для оптимизации работы с тегами, мы разработали ряд стандартов для разных элементов шаблонов.
Шаблон
Теперь каждый шаблон содержит обязательные теги class и target. Использование этих тегов позволит распределить шаблоны по классам, например application, database, network и т.д и по целям.
Элементы данных
Обязательный тег component который описывает принадлежность элемента данных к конкретной системе или типу. Если метрика принадлежит сразу нескольким типам, необходимо использовать несколько тегов component, чтобы как можно лучше описать её принадлежность.
При этом для элементов данных низкоуровневого обнаружения допускаются пользовательские теги с использованием LLD макросов.
Триггеры
Тег scope назначается триггеру в зависимости от типа проблемы. Основная задача разбить триггеры на 5 групп: доступность, производительность, уведомление. безопасность и вместимость.
Узлы сети
Для узла сети используется тег service, который определяет сервис или сервисы запущенные на данном узле сети
Пример расстановки тегов на шаблоне ClickHouse by HTTP
Начнем с тегов самого шаблона. Ему назначены теги class: database и target: clickhouse. На уровне шаблонов не стоит назначать много тегов, потому что каждый из этих тегов будут наследоваться элементами шаблонами, что может создать избыточность, и как результат – “кашу” из тегов.
Рассмотрим несколько метрик и триггеров из этого шаблона.
Метрике “ClickHouse: Check port availability” назначены теги component: health и component: network, так как она содержит информацию о здоровье сервиса и проверка производится по сети. Проблемы по этой метрики можно будет отображать группе, отвечающей за сеть.
Метрика “ClickHouse: Get dictionaries info” имеет тег component: dictionaries потому что она очевидно относится к словарям и тег component: raw потому, что это мастер метрика, и от нее зависимые метрики получают данные.
Метрики из привила низкоуровневого обнаружения “Replicas” содержат теги component: replication, database: {#DB} и table: {#TABLE}. LLD метрики допускают пользовательские теги, так как они позволяют использовать макросы низкоуровневого обнаружения для гибкости группировки.
Триггер “ClickHouse: Version has changed (new version: {ITEM.VALUE})” с тегом scope: notice подразумевает простое уведомление, которое не содержит критической информации связанное с не доступностью и производительностью системы. При этом триггер “ClickHouse: Port {$CLICKHOUSE.PORT} is unavailable” подразумевает недоступность системы и имеет тег scope: availability
Как использовать теги?
Как я уже писал ранее, теги начинают использоваться в компонентах заббикса все чаще, поэтому они становится функциональным и гибким инструментом для управления мониторингом. Одной из последних таких имплементаций стали Сервисы – теперь им можно тоже назначать теги.
Конечно, одним из самых явных и очевидных применений – это логическая группировка элементов. Это позволяет фильтровать триггеры и метрики по определенным заданным параметрам.
Следующим, но не менее важным применением является расширение функционала управления правами. С помощью тегов возможно более точечно выдать права на просмотр проблем на тот или иной сервис. Например, нам необходимо предоставить доступ к серверам nginx которые находятся в группе Webservers. Для этого достаточно в Правах доступа добавить группу Webservers а в Фильтре тегов выбрать группу Webservers и добавить тег service: nginx. Читайте тут подробнее.
Использование тегов в правах доступа
Давайте рассмотрим использование прав на практическом примере. Предположим, у нас есть 3 группы пользователей:
- Hardware team – команда администраторов, которая отвечает за “железо”
- Network team – команда администраторов, которая отвечает за сеть и сетевое оборудование
- Software team – команда администраторов, которая отвечает за софт
Для каждой группы назначаем следующие права:
- для Hardware team определяем права чтения для группы Hardware и в фильтре тегов ставим scope: availability потому, что хотим что чтобы команда видела только проблемы по доступности.
- для Network team определяем права чтения для групп Database, Hardware, Linux servers, Network но для Database, Hardware и Linux servers в фильтрах тегов ставим component: network, потому что по этим группам необходимо видеть исключительно проблемы связанные с сетью, а для Network поставим “все теги”.
- для Software team определяем права чтения для групп Databases и Linux servers при этом в фильтрах тегов ставим class: software для каждой группы, чтобы видеть события исключительно связанные с софтом.
При таких настройках каждая группа пользователей будет видеть только те проблемы, которые попадают под рамки прав и фильтров тегов.
Для примера возьмем все проблемы, которые есть в заббиксе, и доступны пользователю Admin.
При этом пользователь, из группы Hardware team увидит только проблемы по хостам из группы Hardware и триггерам с тегом scope: availability
Пользователь состоящий в группе Network team все проблемы с тегом component: network и все триггеры по группе хостов Network
А пользователи группы Software team исключительно проблемы с тегом class: software
Использование тегов в действиях
Ну и конечно использование тегов в действиях. Зачастую приходится настраивать достаточно комплексные условия, в которых потом можно легко запутаться и тяжело поддерживать. Теги, как универсальный инструмент, добавляют еще одну сущность, от которой можно отталкиваться при создании действий.
Например, если мы хотим рассылать уведомления о проблемах доступности сети и критичностью выше Warning администраторам сети, мы укажем в условиях действия следующие условия:
- значение тега class равно network
- значение тега scope равно availability
- критичность триггера выше или равно Warning
Вопросы
В: Являются ли теги полнофункциональной заменой “приложениям”, или есть какие-то минусы?
О: Конечно, они не только заменяют функционально “приложения”, но и значительно расширят функциональное использование тегов различных аспектах заббикса.
В: Текущая реализация тегов, – это финальная версия?
О: Нет, мы каждый день работает над улучшением опыта получаемого от использования заббикса, и тегов в частности, поэтому мы будем прислушиваться к мнению комьюнити и адаптировать функционал для лучшего результата. Если у вас есть идеи или замечания, используйте форум и Jira чтобы поделиться ими с нами!
В: Есть ли какой-нибудь документ, описывающий бест практис использования тегов?
О: Да, на сайте документации есть раздел гайдлайнов, содержащий в себе основные пункты использования тегов в заббиксе.