Skip to content

Zabbix автоматическое добавление элементов

Zabbix как сервер мониторинга отслеживает метрики на целевых устройствах. Zabbix поддерживает несколько вариантов сбора метрик. Например, метрики могут собираться zabbix агентом или при подключении по SNMP. В терминологии Zabbix то как собирается метрика называется тип элемента (item type). Одна метрика - один элемент. Мы перечисляем элементы на хосте в веб панели Zabbix, и Zabbix сервер получает задание по получению данных с хоста для этих элементов. Каждый элемент имеет свой уникальный ключ (item key).

Тип элемента (item type)

Полный список поддерживаемых типов элементов доступен в Zabbix документации:

  • Zabbix agent checks
  • SNMP agent checks
  • SNMP traps
  • IPMI checks

  • Simple checks

    • VMware monitoring

  • Log file monitoring

  • Calculated items

    • Aggregate calculations

  • Zabbix internal checks

  • SSH checks
  • Telnet checks
  • External checks
  • Trapper items
  • JMX monitoring
  • ODBC checks
  • Dependent items
  • HTTP checks
  • Prometheus checks
  • Script items

Шаблон (template)

Перед тем как начать пара слов про шаблоны. Это механизм в Zabbix, который позволяет доставлять элементы на хост. Шаблон содержит элементы данных, триггеры и графики для различных объектов на компьютере. Когда мы применяем в Zabbix шаблон на хост, мы добавляем все элементы данных, триггеры и графики из шаблона на хост. Это позволяет не добавлять каждый раз вручную одни и тем же элементы на каждый хост, а вместо этого создать один шаблон, перечислить в нём элементы и потом применить этот шаблон на хосты (так много раз, как может потребоваться).

Макросы (macros)

Ещё одна заметка про макросы. Для данной статьи будет понятнее если относиться к макросам как к переменным в Zabbix. Макрос записывается как {МАКРОС}. При обращении к макросу по имени, он возвращает своё значение. Пользовательский макрос, который записывается как {$МАКРОС}, можно создать на разных уровнях в Zabbix: шаблоне, хосте и т.д.

Правила обнаружения (discovery rules)

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

Но тогда нам бы пришлось вручную добавлять элемент для каждого ядра в процессоре (а ядер может быть например 128). А если мы используем шаблон, то на разных хостах могут быть процессоры с разным количеством ядер, что приведёт к противоречию.

В Zabbix есть возможность автоматического сбора метрик одинакового типа, которая называется обнаружение (discovery rule).

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

Каким образом Zabbix может создать элемент для каждого ядра в процессоре? Используя правило обнаружения.

Правило обнаружения состоит из (1) элемента данных, который осуществляет обнаружение необходимых объектов (например, файловые системы или сетевые интерфейсы) и (2) прототипов элементов данных, триггеров и графиков, которые должны быть созданы на основании полученных значений этого элемента данных.

Мы используем правило обнаружения для создания элементов одного типа. Правило обнаружения состоит из двух частей:

  • Элемента, который осуществляет обнаружение необходимых объектов

  • Прототипа элемента, который создаётся для каждого обнаруженного правилом элемента

Пример из документации про сетевые интерфейсы:

  • Правило обнаружения с ключом net.if.discovery возвращает список сетевых интерфейсов: {#IFNAME} → "lo" и {#IFNAME} → "eth0".

    {#IFNAME} - это такой макрос, который используется в правиле обнаружения и содержит реальные значения имен сетевых интерфейсов. Эти макросы затем используются в именах, ключах и в других полях прототипов, которые являются основой для создания реальных элементов данных, триггеров и графиков каждому обнаруженному объекту. Когда сервер получает значение элемента данных обнаружения, он смотрит на пару макрос → значение и для каждой пары создает реальные элементы данных, триггеров и графиков, основанных на их прототипах. В приведенном выше примере с net.if.discovery, сервер будет создавать один набор элементов данных, триггеров и графиков для локального интерфейса lo и другой набор для интерфейса eth0.

  • Прототип элемента

    В нашем примере правило обнаружило два сетевых интерфейса: lo и eth0. Мы можем создать прототип элемента с ключом net.if.in[{#IFNAME},bytes] для входящего трафика и тогда для каждого интерфейса на хосте мы получим элемент для входящего трафика (если например интерфейсов 10, то будет создано десять элементов, автоматически).

Обнаружение с помощью скрипта (discovery rule with external check)

Теперь приведём пример правила обнаружения с помощью элемента внешней проверки (external check). Внешняя проверка производится Zabbix сервером путём выполнения shell скрипта или бинарного файла. Скрипт находится на сервере Zabbix.

Например, используем Python скрипт для получения размера блобов в Sonatype Nexus.

  • Тип элемента: External check
  • Ключ элемента: zabbix-nexus-blobstores.py["{HOST.HOST}", "{$NEXUS_ADDRESS}", "{$NEXUS_USER}", "{$NEXUS_PASSWORD}"]

Давайте рассмотрим ключ элемента:

  • Zabbix сервер запускает скрипт zabbix-nexus-blobstores.py в папке со скриптами (обычно /usr/lib/zabbix/externalscripts/). Важно не забыть:

    • Дать доступ zabbix пользователю к скрипту chown zabbix:zabbix /usr/lib/zabbix/externalscripts/*
    • Дать право запуска скрипта chmod ug+x /usr/lib/zabbix/externalscripts/zabbix-nexus-blobstores.py

  • Zabbix передаёт параметры скрипту:

    • {HOST.HOST} - макрос, который возвращает имя хоста в Zabbix
    • {$NEXUS_ADDRESS} - макрос, который возвращает адрес Nexus сервера
    • {$NEXUS_USER} - макрос, который возвращает пользователя Nexus, под которым будет подключаться Zabbix
    • {$NEXUS_PASSWORD} - макрос, который возвращает пароля у пользователя Nexus

Прототип элемента с типом траппер (item prototype with trapper)

  • Имя элемента: Nexus: [{#NEXUS_BLOB_NAME}] blob total size
  • Тип элемента: Zabbix trapper
  • Ключ элемента: nexus.blobstore.[{#NEXUS_BLOB_NAME},totalSizeInBytes]

Запуск скрипта (для теста)

./zabbix-nexus-blobstores.py 'monitoredhost.example.com' 'nexus.example.com' 'user' 'password'
[{"{#NEXUS_BLOB_NAME}": "blob-01"}, {"{#NEXUS_BLOB_NAME}": "blob-02"}, ...]

Скрипт (ссылка в конце), возвращает два результата:

  • Список блобов - для правила обнаружения с типом внешней проверки
  • Количество байт в блобе - для прототипа элемента с типом траппер

Список блобов скрипт выводит в stdout, поскольку именно этого ожидает тип внешней проверки.

Количество байт в блобе скрипт отправляет на сервер Zabbix, поскольку именно этого ожидает тип траппер.

Пример вывода JSON

Мы можем запросить вручную Nexus API, чтобы получить список блобов. Для этого нам понадобится:

  • Пользователь и пароль на Nexus

  • Для пользователя на Nexus:

    • priveleages/nx-blobstores-read

    • roles/rolename

      • priveleges: nx-blobstores-read

    • user/username

      • roles: rolename

Подключение к Nexus с базовой аутентификацией HTTP. 

curl -u 'user:password' https://nexus.example.com/service/rest/v1/blobstores

Ответ на запрос в формате JSON

[ {
  "softQuota" : {
    "type" : "spaceUsedQuota",
    "limit" : 1099511627776
  },
  "name" : "blob-01,
  "type" : "File",
  "unavailable" : false,
  "blobCount" : 97,
  "totalSizeInBytes" : 2577389810,
  "availableSpaceInBytes" : 10415921348608
}, {
  "softQuota" : null,
  "name" : "blob-02",
  "type" : "File",
  "unavailable" : false,
  "blobCount" : 18665,
  "totalSizeInBytes" : 2190061609,
  "availableSpaceInBytes" : 10415921348608
}, 
...]

Скрипт на GitHub

Репозиторий