- PVSM.RU - https://www.pvsm.ru -
Всем привет, ранее мы уже упоминали о возможностях по массовому сбору данных в новой версии опенсорс системы мониторинга Zabbix 3.4. Теперь остановимся на этом функционале поподробнее, и чтобы было нагляднее, расскажем о нем на двух примерах:
Собирать данные через консольные утилиты или вызовы API данные можно было и ранее, но существовали сложности:
В общем, дело было так:
А с появлением зависимых элементов данных [1], стало возможно так:
Как это работает?
Кстати, препроцессинг [3] – тоже нововведение 3.4, он реализован добавлением новых процессов preprocessing_manager и preprocessing_worker на Zabbix-сервере. Поэтому, если вы обновляетесь с 3.2 – не забудьте обновить шаблон для сервера [4], чтобы мониторить их работу.
Переходим к примерам.
Представим, что на нашем проекте, кроме контейнеров, виртуальных машин, приложений, сетевых устройств, баз данных, бизнес показателей и всего прочего требующего контроля, присутствует необходимость мониторить показатели электросети и другой «инженерки», как, например, климатическое оборудование. Используются стандартные для нашей средней полосы устройства: трехфазный счетчик электроэнергии Меркурий 236 АRT-01 PQRS с интерфейсом RS-485, поверх которого общение происходит через проприетарный протокол производителя.
Задача ответственная – сразу собирать показатели напряжения, мощности, тока, потребления, частоты. Подключить такой прибор к серверу с Zabbix агентом – задача посильная – достаточно будет серийного порта с RS-485, например, в форме USB адаптера. Но как прочитать данные? Если бы не github и добрые люди [5], поделившиеся своим решением [6] для умного дома, писать бы нам модуль [7] к Zabbix, который бы мы учили разговаривать на протоколе счетчика и опрашивать показатели.
Утилита простая и удобная (за что автору большое человеческое спасибо) подключается к счетчику на указанный порт, считывает данные и отдает нам в виде текста, CSV или JSON.
Давайте попробуем установить и запустить:
git clone https://github.com/Shden/mercury236.git
cd mercury236
make
./mercury236 /dev/ttyS0 --help
Usage: mercury236 RS485 [OPTIONS] ...
RS485 address of RS485 dongle (e.g. /dev/ttyUSB0), required
--debug to print extra debug info
--testRun dry run to see output sample, no hardware required
Output formatting:
....
--help prints this screen
Запускается! Отлично, подключаем счетчик, опрашиваем, получаем JSON:
./mercury236 /dev/ttyS0 --json
{
"U": {
"p1": 0.35,
"p2": 0.35,
"p3": 226.86
},
"I": {
"p1": 0.00,
"p2": 0.00,
"p3": 0.39
},
"CosF": {
"p1": 0.00,
"p2": 0.00,
"p3": 0.60,
"sum": 0.60
},
"F": 50.00,
"A": {
"p1": 41943.03,
"p2": 41943.03,
"p3": 41943.03
},
"P": {
"p1": 0.00,
"p2": 0.00,
"p3": 53.45,
"sum": 53.45
},
"S": {
"p1": 0.00,
"p2": 0.00,
"p3": 89.83,
"sum": 89.83
},
"PR": {
"ap": 120.51
},
"PR-day": {
"ap": 86.00
},
"PR-night": {
"ap": 34.51
},
"PY": {
"ap": 0.00
},
"PT": {
"ap": 0.04
}
}
В итоге утилита уже сделала всю сложную работу за нас, реализовав протокол общения с счетчиком, вытащив данные, да еще и предложила нам это в виде удобного JSON объекта. Вот только раньше просто так мы ей не смогли бы воспользоваться — пришлось бы писать обвязку в виде скриптов, а самое главное – реализовывать механизм контроля доступа к среде последовательного порта. Ведь если два поллера Zabbix одновременно обратятся к нему – один за током третьей фазы 3, а другой — за током фазы 2, у нас не вернулось бы ничего.
В 3.4 все становится гораздо проще, и мы теперь быстро и легко можем передавать данные сторонних консольных утилит в Zabbix, не прибегая к оберточным скриптам, и не запуская по 10 раз одно и тоже на каждый элемент данных отдельно. Итак,
sudo cp mercury236 /etc/zabbix/scripts
cd /etc/zabbix/scripts
chmod +x mercury236
sudo usermod -G dialout zabbix
Для запуска скрипта, создадим в конфиге Zabbix-агента новый UserParameter [8]:
UserParameter=mercury236[*],/etc/zabbix/scripts/mercury236 $1 $2
Сохраняем файл, не забываем перезапустить наш Zabbix-агент.
Теперь создадим в новом шаблоне родительский элемент данных:
Как видите, в родительском элементе данных нет ничего особенного – просто проверка через UserParameter [8] Zabbix-агента. А это значит, что и нет никаких ограничений на то, какой тип проверки может выступать в роли родительского элемента – здесь могут быть и данные полученные через Zabbix trapper [9] или через Внешние проверки [10]. Единственное, мы выбрали Тип информации – Text и срок хранения истории в 1 день – хранить дольше мы собираемся метрики отдельно в зависимых элементах (можно не хранить данные вообще в родительском элементе, выставив срок хранения 0). Обратите внимание, что препроцессинг в этом элементе данных мы не трогаем.
Для того чтобы начать создавать зависимые элементы данных, можно воспользоваться новым помощником. Ну или просто нажать «Создать элемент данных»:
Создадим элемент данных для напряжения первой фазы, выберем:
Затем во вкладке «Предобработка» добавим наше выражение JSON Path:
Путь JSON: $.U.p1
Кстати, маленький совет. Чтобы не тратить много времени на отладку и ловлю ошибок, перед тем как заполнять JSON Path можно быстро проверить правильность выражения онлайн, например здесь: jsonpath.com [11], скопировав туда JSON, полученный от утилиты.
Аналогичным образом создаем другие интересующие нас метрики. В том числе — для накопленной энергии по дневному тарифу.
Для этого создадим новый элемент данных и выберем:
А вот во вкладке «Предобработка» обратите внимания на два нюанса:
Проделаем аналогично для остальных ключевых метрик счетчика, в итоге получим вот такой список:
Чтобы шаблон был законченным, добавим триггеры, используя макросы [12], делая его максимально гибким. Не забываем про зависимости триггеров [13].
Шаблон готов, данные побежали, посмотрим, что у нас получилось:
Все последние данные, собранные за одно обращение:
Обратите внимание, что время сбора всех метрик абсолютно идентично.
Итоговый шаблон для счетчика доступен на репозитории решений на share.zabbix.com здесь [14].
Подведем итоги:
Давно мы уже писали [8] на хабре, как можно контролировать S.M.A.R.T. жестких дисков, чтобы успеть их вовремя поменять, через использование UserParameters. Такой подход [8] работает, но он не был лишен недостатков:
Постараемся в 3.4 от всего этого избавится.
Случай с smartmontools имеет два отличия от примера со счетчиком выше:
Но ничего страшного! Во-первых, зависимые элементы данных работают и для LLD, а во-вторых у нас среди preprocessing-фильтров есть и PCRE regex. Воспользуемся им, чтобы вытащить нужные показатели из не супер сильно структурированного ответа утилиты. Примерно такого:
Приступим.
Было:
UserParameter=uHDD[*], sudo smartctl -A $1| grep -i "$2"| tail -1| cut -c 88-|cut -f1 -d' '
UserParameter=uHDD.model.[*],sudo smartctl -i $1 |grep -i "Device Model"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.sn.[*],sudo smartctl -i $1 |grep -i "Serial Number"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.health.[*],sudo smartctl -H $1 |grep -i "test"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.errorlog.[*],sudo smartctl -l error $1 |grep -i "ATA Error Count"| cut -f2 -d: |tr -d " "
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl
Стало:
UserParameter=uHDD.A[*],sudo smartctl -A $1
UserParameter=uHDD.i[*],sudo smartctl -i $1
UserParameter=uHDD.health[*],sudo smartctl -H $1
UserParameter=uHDD.discovery,sudo /etc/zabbix/scripts/smartctl-disks-discovery.pl
Аналогично делаем и для Windows, попутно избавляясь от CMD магии с использование for /F и find. Посмотреть можно тут [17].
Для сбора всех атрибутов S.M.A.R.T. создадим прототип мастер-элемента данных:
Как и в предыдущем примере, ничего особенного настраивать не надо. Только Тип информации – Text, а Период хранения — 1 день.
Для сбора результатов тестов и инвентарных данных нам потребуется запускать smartctl с другими ключами. Поэтому аналогично создадим еще два элемента данных:
Создадим зависимый элемент данных для атрибута 5, Reallocated:
И во вкладке «Предобработка» используем регулярное выражение:
И так же как и с JSON Path, чтобы не тратить много времени на отладку и ловлю ошибок, перед тем как заполнять regex, удобно быстро проверить правильность выражения онлайн, например здесь: regex101.com [18] скопировав туда наш вывод smartctl.
В итоге получим такой вот список прототипов:
Для двух HDD:
Для SSD под Windows:
Подведем итоги примера с smartmontools:
Обновленный шаблон (заодно обновили триггеры, добавили элементы данных для SSD) доступен на репозитории решений на share.zabbix.com здесь [19].
Массовой сбор метрик – простой и легкий способ уменьшить нагрузку на сеть и на ресурсы наблюдаемых систем, а также снизить потребность во внешних скриптах. Уверены, что многим пользователям Zabbix он придется по душе.
Автор: wabbit
Источник [20]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/zabbix/264177
Ссылки в тексте:
[1] зависимых элементов данных: https://www.zabbix.com/documentation/3.4/ru/manual/config/items/itemtypes/dependent_items
[2] функций препроцессинга: https://www.zabbix.com/documentation/3.4/ru/manual/config/items/item#%D0%BF%D1%80%D0%B5%D0%B4%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D0%B9_%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
[3] препроцессинг: https://www.zabbix.com/documentation/3.4/manual/introduction/whatsnew340#new_preprocessing_options
[4] шаблон для сервера: https://share.zabbix.com/official-templates/zabbix-components/zabbix-server
[5] добрые люди: https://github.com/Shden
[6] решением: https://github.com/Shden/mercury236
[7] модуль: https://habrahabr.ru/company/zabbix/blog/268119/
[8] UserParameter: https://habrahabr.ru/company/zabbix/blog/196218/
[9] Zabbix trapper: https://www.zabbix.com/documentation/3.4/ru/manual/config/items/itemtypes/trapper
[10] Внешние проверки: https://www.zabbix.com/documentation/3.4/ru/manual/config/items/itemtypes/external
[11] jsonpath.com: http://jsonpath.com/
[12] макросы: https://www.zabbix.com/documentation/3.4/ru/manual/config/macros/usermacros
[13] зависимости триггеров: https://www.zabbix.com/documentation/3.4/ru/manual/config/triggers/dependencies
[14] здесь: https://share.zabbix.com/power-ups/template-pwr-mercury236-236
[15] system.run[]: https://www.zabbix.com/documentation/3.4/ru/manual/config/items/itemtypes/zabbix_agent#%D0%BF%D0%BE%D0%B4%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%B2%D0%B0%D0%B5%D0%BC%D1%8B%D0%B5_%D0%BA%D0%BB%D1%8E%D1%87%D0%B8_%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
[16] низкоуровневое обнаружение: https://www.zabbix.com/documentation/3.4/ru/manual/discovery/low_level_discovery
[17] тут: https://github.com/v-zhuravlev/zbx-smartctl
[18] regex101.com: https://regex101.com/
[19] здесь: https://share.zabbix.com/storage-devices/smart-monitoring-with-smartmontools-lld
[20] Источник: https://habrahabr.ru/post/337856/
Нажмите здесь для печати.