Меню

Zabbix элементы данных единица измерения



Zabbix Documentation 5.2

Sidebar

Table of Contents

7 Вычисляемые элементы данных

1 Обзор

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

Таким образом, вычисляемые элементы данных являются одним из способов создания виртуальных источников данных. Значения будут периодически вычисляться на основе арифметического выражения. Все вычисления выполняются Zabbix сервером — Zabbix агенты и прокси не участвуют в подсчете вычисляемых элементов данных и не имеют никаких данных для этого.

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

Для использования вычисляемых элементов данных, выберите тип элемента данных Вычисляемое.

2 Настраиваемые поля

Ключ уникальный идентификатор элемента данных (в пределах узла сети). Вы можете создать любое имя ключа использовав поддерживаемые символы.

Формула расчета необходимо ввести в поле Формула. Не существует практически никакой связи между формулой и ключем. В любом случае параметры ключа не используются в формуле.

Корректный синтаксис простой формулы:

АРГУМЕНТ ОПРЕДЕЛЕНИЕ
функция Одна из функций поддерживаемых в выражениях триггеров: last, min, max, avg, count и остальные
ключ Ключ другого элемента данных, данные которого вы хотите использовать. Его можно задать как ключ или узел сети:ключ.
Обратите внимание: Настоятельно рекомендуется заключать весь ключ в двойные кавычки (“…”), во избежании неправильного разбора из-за пробелов или запятых в ключе.
Также если в ключе имеются параметры заключенные в кавычки, то двойные кавычки должны быть экранированы с помощью обратной косой чертой (\). Смотрите ниже Пример 5.
параметр(ы) Параметр(ы) функций, если требуются.

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

В отличии от выражений триггеров, Zabbix обрабатывает вычисляемые элементы данных в соответствии со временем обновления элемента данных, а не при получении нового значения.

Вычисляемый элемент данных может перейти в неподдерживаемое состояние в нескольких случаях:

Источник

Zabbix Documentation 5.2

Sidebar

Table of Contents

16 Зависимые элементы данных

Обзор

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

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

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

Предварительная обработка управляется при помощи менеджер предобработки процесса, который добавлен в Zabbix 3.4, вместе с процессами, которые выполняют шаги предобработки. Все значения (с и без предварительной обработкой) от разных сборщиков данных проходят через менеджер предварительной обработки перед добавлением в кэш истории. Для связи между сборщиками данных (поллерами, трапперами и т.д.) и процессами предобработки используется межпроцессорное взаимодействие (IPC) на основе сокета.

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

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

Ограничения

Настройка элемента данных

Зависимый элемент данных зависит от его основного элемента данных. Поэтому сначала необходимо настроить (или использовать существующий) основной элемент данных:

Все обязательные поля ввода отмечены красной звёздочкой.

Нажмите на Добавить для сохранения основного элемента данных.

Теперь вы можете настроить зависимый элемент данных.

Все обязательные поля ввода отмечены красной звёздочкой.

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

Тип Выберите здесь Зависимый элемент данных.
Ключ Укажите ключ, который будет использоваться для распознавания этого элемента данных.
Основной элемент данных Выберите основной элемент данных. Значение основного элемента данных будет использовано для заполнения значения зависимого элемента данных.
Тип информации Выберите тип информации, который соответствует формату сохраняемых данных.

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

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

Нажмите на Добавить, чтобы сохранить зависимый элемент данных.

В списке элементов данных при помощи быстрого доступа создания зависимого элемента данных можно использовать помощника:

Отображение

В списке элементов данных зависимые элементы данных отображают с префиксом имени основного элемента данных.

Если основной элемент данных удаляется, тогда удаляются и все его зависимые элементы данных.

Источник

Zabbix Documentation 5.2

Sidebar

Table of Contents

8 Символы единиц измерения

Обзор

Возможность использования каких-либо больших чисел, например при ‘86400’, которое означает количество секунд в сутках, бывает затруднительна и чревата ошибками. Именно поэтому вы можете использовать некоторые символы единиц измерения (или суффиксы) для упрощения выражений триггеров и ключей элементов данных в Zabbix.

Вместо ‘86400’ вы можете просто ввести ‘1d’. Функции суффиксов работают как множители.

Суффиксы времени

Для указания времени вы можете использовать:

Суффиксы времени поддерживаются в:

Суффиксы памяти

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

Для размеров памяти вы можете использовать:

Другое использование

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

Эти символы поддерживает как Zabbix сервер, так и веб-интерфейс:

Когда в веб-интерфейсе отображаются значения элементов данных в B, Bps, тогда применяется основа 2 (1K = 1024). В противном случае используется основа 10 (1K = 1000).

Дополнительно веб-интерфейс также поддерживает отображение:

Примеры использования

При использовании некоторых соответствующих суффиксов вы можете написать выражения триггеров, которые легче понять и обслуживать, например, такие выражения:

Источник

Zabbix Documentation 5.2

Sidebar

Table of Contents

1 Создание элемента данных

Обзор

Для создания элемента данных в веб-интерфейсе Zabbix, выполните следующее:

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

Настройка

Вкладка Элемент данных содержит следующие атрибуты элементов данных.

Все обязательные поля ввода отмечены красной звёздочкой.

Параметр Описание
Имя Имя элемента данных.
Поддерживаются следующие макросы, однако, их использование устарело:
$1, $2…$9 — ссылка на первый, второй… девятый параметры ключа элемента данных
Например: Свободно дискового пространства в $1
Если ключ элемента данных “vfs.fs.size[/,free]”, описание автоматически изменится на “Свободно дискового пространства в /”
Тип Тип элемента данных. Смотрите отдельные разделы по типам элементов данных.
Ключ Ключ элемента данных (до 2048 символов).
Поддерживаемые ключи элементов данных описаны в отдельных разделах по типам элементов данных.
Ключ должен быть уникальным в пределах одного узла сети.
Если тип ключа ‘Zabbix агент’, ‘Zabbix агент (активный)’, ‘Простая проверка’ или ‘Zabbix агрегированный’, то значение ключа должно поддерживаться Zabbix агентом или Zabbix сервером.
Смотрите также: корректный формат ключа.
Интерфейс узла сети Выбор интерфейса узла сети. Это поле доступно при изменении элемента данных на уровне узла сети.
Тип информации Этот тип будет обеспечивать точность приблизительно 15 цифр и диапазон от -1,79E + 308 до 1,79E + 308 (за исключением PostgreSQL 11 и более ранних версий).
Получение значений в научной нотации также поддерживается. Например. 1.23E + 7, 1e308, 1.1E-4.
Символ — короткие текстовые данные
Журнал — длинные текстовые данные с необязательными свойствами для журналов (штамп времени, источник, важность, logeventid).
Текст — длинные текстовые данные. Смотрите также ограничения по текстовым данных.
Единица измерения Если указан символ единицы измерения, Zabbix добавит пост обработку полученного значения и отобразит его с заданным постфиксом единицы измерения.
По умолчанию, если исходное значение превышает 1000, оно делится на 1000 и так отображается. Например, если вы задали bps и полученное значение равно 881764, оно будет отображено как 881.76 Kbps.
Для единиц измерения B (байт), Bps (байты в секунду) используется специальная обработка, при которой значение делится на 1024. Таким образом, если единица измерения указана как B или Bps, Zabbix будет отображать:
1 как 1B/1Bps
1024 как 1KB/1KBps
1536 как 1.5KB/1.5KBps
Специальная обработка используется и для следующих единиц измерения связанных со временем:
unixtime — переводится в “гггг.мм.дд чч:мм:сс”. Для корректного перевода, возвращаемое значение должно быть с типом данных Числовой (целое положительное).
uptime — переводится в “чч:мм:сс” или в “N дней, чч:мм:сс”
Например, если вы получили значение равное 881764 (секунд), оно отобразится как “10 дней, 04:56:04”
s — переводится в “ггг ммм ддд ччч ммм ссс мс”; параметр рассматривается как количество секунд.
Например, если вы получили значение равное 881764 (секунд), оно будет отображаться как “10д 4ч 56м”
Отображаются только 3 верхних основы, такие как “1м 15д 5ч” или “2ч 4м 46с”. В случае, если нет дней, то тогда отображаются только два уровня — “1м 5ч” (минуты, секунды или миллисекунды не будут отображаться). Будет переведено в “ ! префиксом, тогда к значениям элементов данных префиксы/обработка единиц измерения применяться не будут. Смотрите чёрный список единиц измерения.
Интервал обновления Получение нового значения по этому элементу данных каждые N секунд. Максимально допустимый интервал обновления — 86400 секунд (1 день).
Функции времени поддерживаются, например, 30s, 1m, 2h, 1d.
Поддерживаются пользовательские макросы (в этом поле может быть использован только один макрос. Комбинации из нескольких макросов или макроса с текстом не поддерживаются).
Обратите внимание: интервал обновления может быть «0», только если заданы нестандартные интервалы с ненулевым значением. Если установлено значение «0» и существует нестандартный интервал (гибкий или запланированный) с ненулевым значением, элемент будет опрашиваться в период, заданный нестандартным интервалом
Обратите внимание, что у существующего пассивного элемента данных можно выполнить опрос значения немедленно, нажав на кнопку Проверить сейчас.
Пользовательские интервалы Вы можете создавать пользовательские правила проверки элемента данных:
Гибкий — создание исключений из Интервала обновления (интервал с другой частотой обновления)
По расписанию — создание пользовательского расписания проверки.
Для получения более подробной информации смотрите Пользовательские интервалы.
Функции времени поддерживаются в поле Интервал, например, 30s, 1m, 2h, 1d.
Поддерживаются пользовательские макросы.
Проверка по расписанию поддерживается начиная с Zabix 3.0.0.
Обратите внимание: Недоступно для активных элементов данных Zabbix агента.
Период хранения истории Количество дней хранения в базе данных детальной истории (от 1 часа до 25 лет). Более старые данные будут удалены с помощью функции автоматической очистки истории базы данных.
Хранится в секундах. Функции времени поддерживаются, например, 2h, 1d.
Поддерживаются пользовательские макросы.
Данное значение можно переопределить глобально в Администрирование → Общие → Очистка истории. Если опция активирована, то вы увидите предупреждение:
Рекомендуется хранить записанные значения как можно меньшее количество дней для уменьшения размера истории в базе данных. Вместо долговременного хранения истории значений, вы можете хранить более долгий срок данные динамики изменений.
Смотрите также История и динамика изменений.
Период хранения динамики изменений Хранение усредненных значений (ежечасные мин, макс, сред, количество) детальной истории N дней в базе данных (от 1 дня до 25 лет). Более старые данные будут удалены с помощью функцией автоматической очистки истории базы данных.
Хранится в секундах. Функции времени поддерживаются, например, 24h, 1d.
Поддерживаются пользовательские макросы.
Данное значение можно переопределить глобально в Администрирование → Общие → Очистка истории. Если опция активирована, то вы увидите предупреждение:
Обратите внимание: Хранение динамики изменений недоступно для не числовых данных — символ, журнал и текст.
Смотрите также История и динамика изменений.
Отображение значений Применение преобразования значений к этому элементу данных. Преобразование значений не меняет полученные значения, оно служит только для отображаемых данных.
Работает только с целыми числовыми элементами данных.
Например, “Windows service states”.
Формат времени журнала Доступен только для элементов данных типа Журнал. Поддерживаемые значения:
* y: Год (1970-2038)
* M: Месяц (01-12)
* d: День (01-31)
* h: Час (00-23)
* m: Минута (00-59)
* s: Секунда (00-59)
Если оставить это поле пустым, то штамп времени не будет обрабатываться.
Например, рассмотрим следующую строку из файла журнала Zabbix агента:
“ 23480:20100328:154718.045 Zabbix agent started. Zabbix 1.8.2 (revision 11211).”
Она начинается с шести символьных позиций PID, далее дата, время и остальная часть строки.
Формат времени журнала для этой строки должен быть “pppppp:yyyyMMdd:hhmmss”.
Обратите внимание, что символы “p” и “:” являются лишь заменителями и могут быть какими угодно, кроме “yMdhms”.
Новая группа элементов данных Введите имя новой группы элементов данных для этого элемента данных.
Группы элементов данных Соединение элемента данных с одним или несколькими существующими группами элементов данных.
Заполнение поля
инвентаря узла сети
Вы можете выбрать поле инвентарных данных, которое будет заполняться значением элемента данных. Функция будет работать, если у узла сети включено автоматическое заполнение инвентарных данных.
Это поле недоступно, если выбран Тип информации ‘Log’.
Описание Введите описание элемента данных.
Активировано Отметьте для активации элемента данных, таким образом он будет обрабатываться.

Предобработка значений элемента данных

Вкладка Предобработка позволяет задать правила преобразования полученных значений.

Тестирование

Можно протестировать элемент данных и, если он настроен правильно, в результате получить реальное значение. Тестирование может проводиться в том числе и до сохранения элемента данных.

Доступно тестирование для элементов данных узлов сети и шаблонов, прототипов элементов данных и низкоуровневых правил обнаружения. Тестирование недоступно для активных элементов данных.

Тестирование доступно для следующих типов пассивных элементов данных:

Источник

Zabbix: мониторим всё подряд (на примере Redis’а)

Zabbix — замечательный продукт для администраторов крупных программно-аппаратных комплексов. Он настолько хорош, что может использоваться не только крупным бизнесом, но и средне-малым бизнесом, и даже в pet -проекте. В общем, у меня есть небольшой опыт работы с Zabbix’ом и я смело могу рекомендовать его к использованию.

Правда я не могу сказать, что понимаю «философию Zabbix’а«. Несмотря на обширную подробную документацию на русском языке, мне было сложно погружаться в мир Zabbix’а — создавалось ощущение, что мы с разработчиками одни и те же вещи называем разными именами. Возможно потому, что Zabbix создавался админами для админов, а я всё-таки больше разработчик и пользователь.

Тем не менее, для запуска Zabbix’а и для мониторинга основных параметров компьютерных систем (процессор, память и т.п.) навыков обычного linux-пользователя хватает. Есть большое количество плагинов от сторонних разработчиков, расширяющих возможности Zabbix’а. Для моих нужд мне потребовалось настроить мониторинг Redis-сервера. Я немного покопался в коде имеющихся плагинов и на их примере выяснил, что архитектура Zabbix’а позволяет достаточно просто подключать к мониторингу любые параметры информационных систем, которые могут быть выражены в числовом виде.

Под катом — пример Zabbix-плагина с моим пояснением по терминологии Zabbix’а. Кому-то этот пример покажется наивным, ну а кому-то поможет проще освоиться с понятиями. В любом случае, Zabbix достаточно велик для того, чтобы ощупать его с разных сторон.

Базовые понятия

Кратко о некоторых понятиях, которые используются в Zabbix’е: agents, items, triggers, actions, notifications, templates.

Сервер и агенты

С точки зрения пользователя Zabbix делится на две большие части: сервер и агенты. Сервер располагается на одной машине, которая собирает и хранит статистические данные, а агенты — на тех машинах, данные с которых собираются:

Параметры мониторинга

Любая величина, которая может выражена в числовом или строковом виде, называется в терминологии Zabbix’а — элементом данных (item). Каждый элемент связывается с уникальным ключом (именем). Вот примеры элементов данных:

  • system.cpu.load[percpu,avg1]: 0.1167
  • system.uname: «Linux supru 4.15.0-50-generic #54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64»

Значения этих элементов данных (параметров мониторинга) привязываются ко времени, история значений параметров сохраняется в базе сервера.

События

При наступлении некоторого события в Zabbix’е срабатывает триггер. Например,

  • >10 — среднее значение параметра за последние 5 минут превысило «10»
  • >0 — текущее значение параметра не равно предыдущему значению

По сути, триггеры — это формулы, в которых переменными выступают параметры мониторинга (текущие и сохранённые), и которые на выходе дают true / false .

Действия и Оповещения

В случае наступления события (срабатывания тригера) сервер может выполнить действие. Например, отправить оповещение по email’у на заданный адрес («Problem: host is unreachable for 5 minutes«). Также действие может быть выполнено в случае возвращения триггера в исходное состояние («Resolved: host is unreachable for 5 minutes«). Все события (переключения триггера) логируются на стороне сервера.

Шаблоны

Zabbix даёт возможность как настроить правила мониторинга для отдельного хоста, так и создать шаблон правил (template), который можно применять к различным хостам:

На примере видно, что шаблон «Template App SSH Service» описывает одно приложение (Applications), один параметр мониторинга (Items), один триггер (Triggers). Также доступны описания для графиков, экранов, правил обнаружения и web-сценариев.

Постановка задачи для плагина

Начальное положение

Сам Zabbix предлагает свой собственный плагин для мониторинга состояния Redis’а, но на моей версии сервера (4.2.8) мне не удалось его задействовать (плагин для версии 4.4 и выше). Также предлагаются решения от третьих лиц (около десятка вариантов под различные версии Zabbix’а, на картинке только первых три):

Каждый из них обладал своими плюсами-минусами, пришлось заглянуть внутрь, чтобы выбрать. Лучшим, на мой взгляд, оказался плагин Shakeeljaveed/zabbix-redis-userparamaters, состоявший из двух файлов:

Немножко пришлось поработать «ручками», но зато на его примере стало чуть понятнее, как данные от агента попадают на сервер. По предложению автора Javeed Shakeel состояние Redis’а каждые 2 минуты сбрасывалось кроном в файл /tmp/redismetric :

А затем каждый параметр мониторинга извлекался агентом из файла /tmp/redismetric при помощи средств самой операционной системы. Инструкции для этого размещались в конфигурации Zabbix-агента /etc/zabbix/zabbix_agent.conf.d/userparameter_redis.conf . Например, вот так выглядят инструкция для извлечения параметра used_memory (использование памяти Redis-сервером):

То есть, в файле /tmp/redismetric с выводом redis-cli INFO по ключу used_memory ищется строка ( grep -w . )

которая затем разбивается на столбцы по разделителю «:» ( cut -d: -f2 ). На выходе агент получает число 7153216 и присваивает его параметру used_memory .

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

Задачей мониторинга состояния любой системы явлется не только сбор статистики, но и предупреждение о возникновении ситуаций, требующих вмешательства человека. Так как с Redis’ом я работаю на уровне очень начинающего пользователя, то пришлось поискать информацию, на какие параметры «здоровья» обращать внимание и что они значат. Наиболее достойной показалась статья «6 Crucial Redis Monitoring Metrics You Need To Watch». Проанализировав её, я пришёл к выводу, что «для полного счастья» мне нужно собирать данные для обнаружения следующих событий:

  • Memory fragmentation: used_memory_rss / used_memory > 1.5
  • Low cache hit ratio: (keyspace_hits)/ (keyspace_hits + keyspace_misses) 0
  • Evicted keys: evicted_keys > 0

Также я хотел собирать статистику по дополнительным параметрам (версия Redis’а, uptime и т.п.). В общем, имея общее представление о том, каким образом данные собираются агентом и передаются на сервер, «хотелки» можно сильно не ограничивать. В итоге получился список параметров для мониторинга из 12 позиций.

Создание собственного плагина

Параметры мониторинга

Плагин, который я анализировал, предполагал выполнение отдельной команды для получения отдельного параметра (элемента данных, item’а):

Т.е., для получения данных по 12 параметрам агент должен будет 12 раз выполнить различные наборы команд. А если мне нужно мониторить параметры, которые сложно извлечь цепочкой команд и нужно будет писать отдельный shell-скрипт или полноценную программу? Для таких «хотелок» Zabbix предлагает вариант с зависимыми элементами данных. Суть его в том, что на стороне агента скриптом формируется набор данных (например, в формате JSON), который передаётся на сервер в виде строкового параметра. Затем на стороне сервера происходит разбор полученных данных и вычленение из них отдельных элементарных параметров.

Основной элемент данных

Я описал основной элемент данных redis.info строкового типа с периодом обновления в 1 мин., без сохранения истории изменений:

Предположительно, на стороне агента должен генерироваться такой JSON:

после чего этот текст должен попадать на сервер в виде элемента данных redis.info , но не сохраняться, а служить базой для других элементов данных (параметров мониторинга).

Зависимый элемент данных

Тестовый параметр redis.info.version зависит от redis.info и сохраняет свои значения в базе в течение 90 дней. Периодичность мониторинга параметра зависит от базового элемента ( redis.info ):

Значение параметра redis.info.version извлекается из значения redis.info при помощи инструкций JSONPath:

По аналогичной схеме описываются остальные зависимые элементы данных (параметры мониторинга), которые передаются в виде JSON’а. Вот пример описания числового параметра redis.info.used_memory :

Всё достаточно прозрачно, за исключением Units и Trend storage period . Со вторым пунктом я не разбирался, оставил по-умолчанию, а единицы измерения объяснены в документации. В данном случае значение redis.info.used_memory измеряется в байтах и в web-интерфейсе сворачивается до кило/мега/гига/. -байт.

Формула для извлечения значения из JSON’а: JSONPath = $.used_memory

Вычисляемый элемент данных

Для вычисления фрагментации памяти используется отношение used_memory_rss / used_memory и на его базе определяется триггер, срабатывающий при превышении отношением значения 1.5. В Zabbix’е есть вычисляемый тип элементов данных:

Значение для параметра redis.info.used_memory_ratio вычисляется каждую минуту на основании последних значений двух других параметров ( redis.info.used_memory_rss и redis.info.used_memory ), сохраняется в базе в течение 90 дней и т.д.

Триггеры

Вот пример триггера, срабатывающего при излишней фрагментации памяти:

Ничего необычного, за исключением формата выражений, используемого в формуле изменения состояния триггера. В Zabbix’е есть конструктор форм, можно воспользоваться им или обратиться к документации/примерам (список триггеров доступен через web-интерфейс по адресу «Configuration / Templates / $ / Triggers«).

Триггер может базироваться на любых элементах данных (item’ах) вне зависимости от их типа (основной, зависимый, вычисляемый).

Настройка агента

Генерация JSON’а

Для получения значений параметров мониторинга и формирования JSON’а я использую вот такой shell-скрипт:

Этот скрипт я поместил в файл /var/lib/zabbix/user_parameter/redis/get_info.sh на сервере с Redis’ом, на котором уже установлен агент Zabbix’а. Пользователь, под которым запускается Zabbix-агент (обычно zabbix ) должен иметь права на выполнение файла get_info.sh .

Файл userparameter_XXX.conf

На стороне агента дополнительные параметры мониторинга прописываются в файлах userparameter_*.conf в каталоге /etc/zabbix/zabbix_agentd.d . Поэтому для того, чтобы агент узнал о том, каким образом ему нужно собирать данные по параметру redis.info , я создал файл /etc/zabbix/zabbix_agentd.d/userparameter_redis.conf с таким содержимым:

Т.е., для получения данных по параметру redis.info агент должен запустить скрипт /var/lib/zabbix/user_parameter/redis/get_info.sh и передать на сервер результат выполнения.

После рестарта Zabbix-агента ( sudo service zabbix-agent restart ) у него появляется возможность собирать данные для параметра redis.info и отправлять их на сервер.

UPDATE: коллега banzayats обратил внимание, что текстовые данные с хоста можно получить без создания промежуточного скрипта userparameter_*.conf — при помощи параметра » system.run » и проводить постпроцессинг уже на стороне zabbix-сервера.

Резюме

Понимание Zabbix’а ко мне приходило (и всё ещё приходит) достаточно тяжело. Тем не менее я считаю его прекрасным инструментом, особенно после того, как для меня открылась простота добавления собственных параметров мониторинга (элементов данных). По большому счёту, достаточно добавить один файл на сервер с агентом ( userparameter_XXX.conf ) с shell-командой для сбора данных и настроить Zabbix-сервер на получение этих данных через web-интерфейс. И всё — можно накапливать данные, строить графики, анализировать изменения и создавать триггера, реагирующие на эти изменения.

Код шаблона, файла userparameter_redis.conf и скрипта get_info.sh можно посмотреть в проекте flancer32/zabbix_plugin_redis.

Спасибо всем, кто дочитал до конца, а особенно тем, кто нашёл в публикации что-то полезное для себя.

Источник

Читайте также:  Способ измерения больших промежутков времени