6 Тегирование

Обзор

Теги состоят из имени тега и значения тега. При назначении тегов сущностям можно использовать только имя или пару имени со значением (например, mysql, jira, target:mysql, service:jira и т. д.).

Теги могут быть определены для различных сущностей:

  • Шаблоны
  • Узлы сети
  • Элементы данных
  • Веб-сценарии
  • Триггеры
  • Сервисы
  • Элементы данных и триггеры шаблонов
  • Прототипы узлов сети, элементов данных и триггеров

В списках Шаблоны, Узлы сети, Элементы данных, Триггеры, Веб-сценарии и их прототипов столбец Теги отображает как обычные, так и унаследованные теги. При наведении указателя мыши на унаследованный тег или при щелчке по нему появляется всплывающая JavaScript-подсказка с текстом «Inherited tag». Если унаследованный тег также существует как обычный тег, отображается другой текст подсказки в зависимости от списка, где он показан (например, «Inherited and template tag» в списке шаблонов или «Inherited and host tag» в списке узлов сети). В других местах веб-интерфейса обычные и унаследованные теги отображаются вместе (дубликаты удаляются), без значков и без дополнительного текста всплывающей подсказки.

Обратитесь к официальным рекомендациям Zabbix с общими рекомендациями по определению тегов, а также со специальными рекомендациями для шаблонов, элементов данных, триггеров и правил низкоуровневого обнаружения.

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

  • при наличии тегов у шаблонов — любая проблема узла сети (созданная триггерами из шаблона) унаследует теги шаблона.
  • при наличии тегов у узлов сети — любая проблема узла сети унаследует теги узла сети.
  • при наличии тегов у элементов данных/веб-сценариев — любая проблема элемента данных/веб-сценария унаследует теги элемента данных/веб-сценария.
  • при наличии тегов у триггеров — любая проблема, созданная триггером, унаследует теги триггера.

Событие проблемы наследует все теги из всей цепочки сущностей — шаблонов, узлов сети, элементов данных/веб-сценариев, триггеров. Идентичные комбинации tag:value (после раскрытия макросов) объединяются в одну, что позволяет избежать дублирования.

События восстановления, созданные при ручном закрытии, также включают раскрытые теги событий, унаследованные от шаблонов, узлов сети, элементов данных/веб-сценариев и триггеров. Эти теги доступны в уведомлениях и через макросы, такие как {EVENT.RECOVERY.TAGS} и {EVENT.RECOVERY.TAGSJSON}.

Пользовательские теги событий обеспечивают большую гибкость. Например:

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

Сущности могут быть помечены одинаковым именем тега, но разными значениями тега (например, component:memory и component:storage). Аналогично, сущность может иметь тег без значения и тот же тег со значением (например, database и database:postgresql). Такие теги не считаются дубликатами.

Варианты использования

Некоторые распространенные варианты использования тегов:

  1. Пометка событий триггеров:

    • Определите тег триггера (например, scope:performance).
    • Проблемы, созданные этим триггером, будут иметь тег триггера.

  2. Пометка проблем, унаследованных от шаблона:

    • Определите тег шаблона (например, target:mysql).
    • Проблемы, созданные триггерами из этого шаблона, будут иметь тег шаблона.

  3. Пометка проблем узла сети:

    • Определите тег узла сети (например, service:jira).
    • Проблемы, созданные триггерами этого узла сети, будут иметь тег узла сети.

  4. Фильтрация связанных элементов данных:

    • Определите тег элемента данных (например, component:cpu).
    • В Monitoring > Latest data элементы данных можно фильтровать по тегу component:cpu.

  5. Использование информации, извлеченной из значения элемента данных, в качестве значения тега:

    • Определите тег с макросом в качестве значения тега (например, tag-name:{{ITEM.VALUE<N>}.regsub()} ).
    • В Monitoring > Problems значение тега у проблем будет преобразовано в данные, извлеченные из значения элемента данных.

  6. Выявление проблем в файле журнала и их раздельное закрытие:

    • Определите тег триггера для триггера элемента данных мониторинга журнала, который будет извлекать значения из значения элемента данных с помощью макроса (например, service:{{ITEM.VALUE<N>}.regsub()} ).
    • В настройке триггера настройте корреляцию событий:
      • установите PROBLEM event generation mode в значение "Multiple";
      • установите OK event closes в значение "All problems if tag values match";
      • задайте тег для сопоставления.
    • Проблемы, созданные триггером элемента данных журнала, будут иметь тег триггера и будут закрываться по отдельности.

  7. Фильтрация уведомлений:

    • Определите теги триггеров (например, scope:security для trigger1 и scope:availability для trigger2).
    • Используйте фильтрацию по тегам в условиях действия, чтобы получать уведомления только о событиях, соответствующих данным тегов.

  8. Идентификация проблем в уведомлениях:

    • Определите теги триггеров.
    • Используйте макрос {EVENT.TAGS} в уведомлении о проблеме.
    • Уведомление о проблеме будет содержать теги триггера, что упростит определение того, к какому приложению/сервису относится уведомление.

  9. Упрощение задач настройки с помощью тегов шаблона:

    • Определите тег триггера шаблона.
    • Триггеры, созданные из этого триггера шаблона, будут иметь его тег.

  10. Создание триггеров с тегами из low-level discovery (LLD):

    • Определите тег прототипа триггера с макросом LLD в имени или значении тега (например, scope:{#FSNAME}).
    • Триггеры, созданные из прототипа триггера, будут иметь его тег.

  11. Сопоставление сервисов с использованием тегов сервиса:

    • Определите теги сервиса.
    • Настройте действия сервиса для сервисов с совпадающими тегами.
    • Дополнительно используйте теги сервиса, чтобы связать сервис с SLA для расчета SLA.

  12. Связывание сервисов с проблемами с помощью тегов проблем сервиса:

    • Определите тег проблемы в настройке сервиса (например, target:mysql).
    • Проблемы с совпадающим тегом будут автоматически коррелироваться с сервисом, а статус сервиса будет изменяться в соответствии с настроенными правилами расчета статуса сервиса.

  13. Подавление проблем, когда узел сети находится в режиме обслуживания:

  14. Предоставление доступа группам пользователей:

Конфигурация

Теги можно задать на отдельной вкладке, например, в настройках триггера:

Поддержка макросов

Встроенные и пользовательские макросы в тегах разрешаются в момент события. До наступления события эти макросы будут отображаться в веб-интерфейсе Zabbix неразрешёнными.

Макросы низкоуровневого обнаружения разрешаются в процессе обнаружения.

Следующие макросы могут использоваться в именах и значениях тегов триггера:

  • встроенные макросы {ITEM.VALUE}, {ITEM.VALUE.AGE}, {ITEM.VALUE.DATE}, {ITEM.VALUE.TIME}, {ITEM.VALUE.TIMESTAMP}, {ITEM.LASTVALUE}, {ITEM.LASTVALUE.AGE}, {ITEM.LASTVALUE.DATE}, {ITEM.LASTVALUE.TIME}, {ITEM.LASTVALUE.TIMESTAMP}, {HOST.HOST}, {HOST.NAME}, {HOST.CONN}, {HOST.DNS}, {HOST.IP}, {HOST.PORT} и {HOST.ID}
  • встроенные макросы {INVENTORY.*} (для ссылки на значения инвентарных данных узла сети из одного или нескольких узлов сети в выражении триггера)
  • пользовательские макросы и пользовательские макросы с контекстом (контекст может включать макросы низкоуровневого обнаружения)
  • макросы низкоуровневого обнаружения (только в тегах прототипа триггера)

Следующие макросы могут использоваться в именах и значениях тегов шаблона, узла сети и элемента данных/веб-сценария:

  • встроенные макросы {HOST.HOST}, {HOST.NAME}, {HOST.CONN}, {HOST.DNS}, {HOST.IP}, {HOST.PORT} и {HOST.ID}
  • встроенные макросы {INVENTORY.*}
  • пользовательские макросы
  • макросы низкоуровневого обнаружения (только в тегах прототипа узла сети и прототипа элемента данных)

Следующие макросы могут использоваться в уведомлениях на основе триггеров:

  • встроенные макросы {EVENT.TAGS} и {EVENT.RECOVERY.TAGS} (эти макросы будут разрешены в список тегов события или тегов события восстановления, разделённых запятыми)
  • встроенные макросы {EVENT.TAGSJSON} и {EVENT.RECOVERY.TAGSJSON} (эти макросы будут разрешены в JSON-массив, содержащий объекты тегов события или объекты тегов события восстановления)
Извлечение подстроки в тегах триггера

Извлечение подстроки поддерживается для заполнения имени тега или значения тега с использованием функции макроса. Функция применяет регулярное выражение к значению, полученному из поддерживаемого макроса. Например:

{{ITEM.VALUE}.regsub(pattern, output)}
{{ITEM.VALUE}.iregsub(pattern, output)}

{{#LLDMACRO}.regsub(pattern, output)}
{{#LLDMACRO}.iregsub(pattern, output)}

Если имя тега или его значение после раскрытия макроса превышает 255 символов, оно будет усечено до 255 символов.

См. также: Использование функций макросов в макросах низкоуровневого обнаружения для тегирования событий.

Просмотр тегов событий

Теги, если они определены, можно просматривать у новых событий в следующих разделах:

Порядок и количество отображаемых тегов определяются параметрами фильтрации Приоритет отображения тегов и Показывать теги в разделе Мониторинг > Проблемы или в виджете панели Проблемы. Обратите внимание, что может отображаться не более трёх тегов; если тегов больше, при наведении курсора на троеточие все теги будут показаны во всплывающем окне.