Jump to content
iT4iT.CLUB

Leaderboard


Popular Content

Showing content with the highest reputation since 04/20/2019 in all areas

  1. 2 points
    Да, удалите в основном файле строку cron.add(cron::time_1m, [&](){ sensors.checkLine(); }, true); Всю инициализацию датчиков проведите самостоятельно без использования соответствующих функций при описании датчиков. Или замените указанную выше строку на разовый вызов метода checkLine sensors.checkLine(); Проверка датчиков на шине проводится через определение доступности адресов датчиков Wire.beginTransmission(sensor->address); /* ... */ sensor->status = (Wire.endTransmission() == 0); Скорее всего вы получаете не все данные при запросе данных для комплексного суточного графика в следствии чего json строка считается поврежденной и график не строится. А корень проблемы в том, что в данном случае контроллер передает данные по всем сенсорам, для которых активно ведение лога. Связано это с тем, что изначально не было графиков по конкретным сенсорам, существовал только комплексный график, соответственно и данные отдавались все и сразу. Получается, что Вы нашли придел для размера передаваемого объекта с данными. Часть кода уже переписана и прекрасно работает, но есть технические нюансы, из-за которых я не могу назвать какие-то конкретные строки. Ну и опять же, все приходится делать только в свободное время.
  2. 1 point
    Всем привет. Начнем как всегда с предыстории! Цель, сбор данных с различных устройств на очень большой территории промышленного предприятия. Естественно финансирование просто огромное, хватит на большую пачку семечек и пачку индийского чая, возможно даже сдача останется, но не факт. А Вы как думали? В сказку попали? В связи с этим устройства самодельные, на базе популярных микроконтроллеров фирмы ATmel с прикрученным Ethernet. И естественно самый простой способ обмена не критической информацией - MQTT протокол. Т.к. предприятие не малое, цеха большие, то IT оборудование раскидано на агрегатах и для защиты от воздействия внешней среды, оно находится в гермозонах. Температура внутри поддерживается кондиционерами, но они, как и все в этом мире, стремятся раствориться в небытии, и с легкостью потянут за собой все оборудование, что трудится в гермозонах на благо предприятия. И так. Для начала Вам понадобится свой брокер c MQTT клиентом. Хотя у Вас он скорее всего уже есть. Его роль может выполнять как сам zabbix сервер, так и отдельная машина. В последнем случае дополнительно потребуется установка zabbix агента. Все инструкции и дистрибутивы имеются на официальном сайте mosquitto.org Я использую в качестве операционной системы Linux Ubuntu и для меня все очень просто. sudo apt-get install mosquitto mosquitto-clients Настройка брокера - это отдельная тема и затрагивать её здесь не будем. Вносим дополнения в конец файла конфигурации zabbix агента на сервере nano /etc/zabbix/zabbix_agentd.conf Добавляем пользовательский параметр MQTT UserParameter=mqtt[*],/usr/bin/mosquitto_sub -h 127.0.0.1 -t $1 -C 1 -N 2>/dev/null Сброс ошибок в /dev/null необходим из-за возможности их появления в случае запуска клиента от пользователя, у которого нет собственного домашнего каталога. В противном случае можно получить в довесок к выводу сопроводительное письмо со следующим текстом. Переходим в панель управления Zabbix. Теперь нам доступна возможность создавать элементы данных содержащих ключи следующего вида. mqtt[адресс необходимого топика] mqtt[/room213/door1/lock/status] mqtt[/garage/smoke/level] mqtt[/room/sensors/temperature1] Каждый ключ соответствует адресу топика с которого нужно взять ту или иную информацию. И сама структура топика просто идеальна для иерархии оборудования или ветвления расположений объектов. Но Вы и так это видите. Создаем узел сети с ip адресом Zabbix сервера или просто 127.0.0.1, тип проверки "Zabbix агент". Указываем интересующий нас топик и слушаем. ВАЖНО: Клиенты рассылающие сообщения должны использовать параметр "-r, --retain" для сохранения сообщения у брокера. Без этого параметра Zabbix не сможет получить данные т.к не поддерживает постоянную связь с брокером, а лишь забирает последние данные по установленному интервалу времени. Команда для отправки тестовой строки "message" в топик "test/string" /usr/bin/mosquitto_pub -h 127.0.0.1 -r -t test/string -m "message" Для начала мне потребовалось снимать показания температуры внутри и снаружи гермозон. Это экстренная необходимость т.к в случае ч.п, в зимнее время, температуры внутри может превышать 30 градусов Цельсия, а в летнее температура пола рядом со зданием в котором находится гермозона может превышать 70-80 градусов Цельсия, а про температуру оборудования я вообще молчу. И да, мы не конфеты делаем, к сожалению... Для меня удобнее создать шаблон, который будет добавлен к серверу с MQTT брокером. Это дает гибкость в случае замены самого брокера или миграции сервера на другую платформу. Интересующий нас ключ отмечен на рисунке, все остальное на Ваше усмотрение. Все данные показанные ниже идут с тестового стенда, установленного за пределами экстремальных зон! Так выглядят первые элементы данных. Это показания с двух датчиков температуры и данные с внутреннего таймера микроконтроллера. Последние показания нужны для отслеживания зависания устройства. такое и мало вероятно. Но оно и имеет сторожевой таймер, лишняя перестраховка в промышленных масштабах не помешает. Текущие показания. Ну и естественно график, куда без него. Прост и так скудный) Можно организовать скрипт, поддерживающий несколько входных параметров, но это уже вопрос желания и необходимости.
  3. 1 point
    Если Вам нужен графический интерфейс, то ставьте Raspbian, но если интерфейс нужен для установки софта или Вы будите пользоваться им очень редко, то ставьте Ubuntu Server. Для установки операционной системы действуйте по мануалу на официальном сайте Малины. Вам понадобится монитор и другая периферия на этом этапе. В процессе первого запуска, скорее всего у Вас спросят какой пароль задать пользователю root, обязательно запомните этот пароль. Возможно на каких-то этапах установки Вам будут предлагать доставить софт или произвести начальную конфигурацию, если не знаете, что от Вас хотят или сомневаетесь, то оставляйте все по умолчанию. После того как все будет готово, Вас должно выбросить в интерфейс операционной системы. Я пойду по более сложному пути и буду думать, что графической оболочки у Вас нет, а, следовательно, Вас встретит черный экран с предложением ввести логин и пароль. Для Raspbian по умолчанию используется логин "pi" пароль "raspbery", для Ubuntu Server логин и пароль "ubuntu", возможно первая буква заглавная. Нам необходимо выяснить какой ip адрес был присвоен малине в домашней сети (если Вы не задали его руками при установке системы). Сделать это можно следующей командой. ifconfig Если в выводе слишком много информации и Вы теряетесь, то можно убрать лишнее и оставить только данные по локальной сети. Для этого ведите следующую команду в которой укажите первые два октета Вашей сети. Скорее всего это 192.168 ifconfig | grep 192.168 Теперь Вы должны явно видеть выделенный малине ip адрес, мы будем использовать его для подключения с других устройств. Но если Вы используете DHCP, то данный ip рано или поздно изменится. Самым лучшим вариантом будет зайти в панель управления домашнего маршрутизатора и в настройках DHCP сервера закрепить за малиной данный адрес. Можно указать статический ip в самой малине, но тогда можно поиметь горя в будущем, в общем, сетью должен управлять Ваш маршрутизатор, а не рядовые хосты. Теперь мы можем подключиться к будущему серверу с домашнего компьютера. Подключаемся по SSH с помощью любого удобного клиента, например Putty. https://www.raspberrypi.org/documentation/remote-access/ssh/windows.md Авторизуемся под встроенным пользователем о котором упоминалось ранее и под которым Вы уже заходили на предыдущем этапе. Повышаем себе привилегии до root sudo su Обновляем информацию об актуальных пакетах apt update Обновляем имеющиеся в системе пакеты apt upgrade Устанавливаем MQTT брокер apt install mosquitto Брокер должен начать работать сразу после установки на начальной конфигурации, для домашнего сервера это вполне достаточно. Проверить статус брокера можно так: /etc/init.d/mosquitto status Теперь пора поднять web сервер, для дома прекрасно подойдет Apache, а заодно сразу поставим PHP и модуль позволяющий добавить в Apache поддержку .php скриптов. apt install apache2 php libapache2-mod-php Перезапустим web сервер /etc/init.d/apache2 restart Для установки MySQL сервера выполните следующую команду apt install mysql-server Во время установки СУБД Вас попросят задать пароль для основного пользователя root, этот пользователь не связан с ОС (просто одинаковые имена) и пароль распространяется только на MySQL. Для удобства можно указать тот же пароль, что используется системным пользователем root, это противоречит политике безопасности, но для теста малины вполне сойдет. Также я очень советую доставить Midnight Commander дабы чувствовать себя человеком при навигации по каталогам системы apt install mc Главное помните, что Midnight Commander обладает правами того пользователя, из-под которого запущен. В связи с этим, если вы захотите редактировать файлы конфигурации или выполнять иные задачи требующие права пользователя root, то всегда запускайте mc через sudo. sudo mc Вас попросят ввести пароль пользователя root и mc запустится от его имени. Для теста можно перейти в домашний каталог web сервера и создать там тестовый php скрипт. Все это сделать можно через Midnight Commander или выполнив следуюoe. командe echo "<?PHP phpinfo();" > /var/www/html/test.php Теперь перейдите в браузере на страницу http://server_ip/test.php чтобы убедиться в работоспособности. Кажется, на этом все, возможно я что-то пропустил, но это уже мелочи. Если будет нужно, то могу в свободно время снять видео как все это развернуть, вроде где-то валялась Raspbery PI 2. В общем пишите если будут вопросы. Если не определитесь какую систему сбора и анализа данных использовать, то можете посмотреть в сторону Zabbix. Тут на форуме есть тема, в которой описано как подружить MQTT и Zabbix. Но в любом случае, для начала посмотрите на другие системы, все-таки Zabbix это серверное решение и очень плотно работает с MySQL, что не очень хорошо для флешки которая используется малиной. Также можно использовать какой ни-ть HDD или SSD формата 2.5 дюйма место SD карты, но это уже отдельная история.
  4. 1 point
    @post125 Менее каменистый путь это брокер на Малине или любой аналогичный вариант. Ставите Ubuntu и одной командой устанавливаете MQTT сервер. В таком случает получаете полноценную систему с возможностью наращивать функционал, в том числе и запись данных куда угодно, хоть в СУБД. Заодно можно систему визуализации добавить, да и вообще, что угодно. А маршрутизатор, как не крути, это чисто транспортный узел со всеми вытекающими ограничениями по железу, а следовательно, и по программной части. Думаю, что вариант с OpenWRT + MQTT больше подойдет для удаленных систем, например, гаража.
  5. 1 point
    Добрый день! Сутки прошли, полёт нормальный, ни одного пропуска данных на обоих контроллерах. Спасибо!
  6. 1 point
    Так получилось, что у меня имеются два провайдера у одного из которых я вижу внутреннюю сеть, а ещё есть Zabbix который начинает ничего мне не сообщать если я не на работе про то, что происходит если провайдер через которого он это делает "уснул". Встретив на просторах интернета интересный скриптик я немного модифицировал его под себя и радуюсь жизни. Сим хочу с вами поделиться. Имеем два шлюза с апи нашей локалки 1.1.1.1 и 1.1.1.2. Имееем айпи 3.3.3.3 из внутренней сети провайдера. Создаём рабочую директорию для скрипта в /usr/local/scripts/bin/status В принципе это всё что нам надо. #!/bin/sh FPING="/usr/local/sbin/fping" WRKDIR='/usr/local/scripts/bin' DATE=`/bin/date` MAININET='3.3.3.3' MAIN='1.1.1.1' BACKUP='1.1.1.2' main_status_old=`/bin/cat $WRKDIR/status/main | /usr/bin/awk '{ print $1 }'` main_try=`/bin/cat $WRKDIR/status/main | /usr/bin/awk '{ print $2 }'` router=`/bin/cat $WRKDIR/status/router` main_status_new=`$FPING $MAININET | /usr/bin/awk '{ print $3 }'` back_status=`$FPING $BACKUP | /usr/bin/awk '{ print $3 }'` if [ $main_status_new != 'alive' ] then { if [ $router = 'main' ] then { if [ $back_status = 'alive' ] then { if [ $main_try != 0 ] then { route change default 1.1.1.2 echo 'backup' > $WRKDIR/status/router } else { main_try=`expr $main_try + 1` echo "$main_status_new $main_try" > $WRKDIR/status/main } . fi } fi } fi . } else { if [ $router = 'backup' ] then { route change default 1.1.1.1 echo 'main' > $WRKDIR/status/router echo "$main_status_new 0" > $WRKDIR/status/main } fi } . fi Делаем статический маршрут до айпи 3.3.3.3 через шлюз 1.1.1.1 route add -net 3.3.3.3 1.1.1.1 Добавляем этот маршрут в rc.conf static_routes="local-prov" route_local-prov="-net 3.3.3.3 1.1.1.1" Добавляем выполнение в крон по желаемому временному интервалу и радуемся тому, что сообщения о состоянии будут приходить если провайдер один отвалится. И тому что провайдер так любезен. Удачи!
  7. 1 point
    Маленькое дополнение к последнему посту с мониторингом MQTT брокера Mosquitto в реальном времени. В шаблоне не было отображено как определить отсутствие данных. В принципе, это не такое серьезное упущение т.к целью было получение самих данных, но все же. Т.к мы использовали тип элемента данных "Zabbix траппер", то самым явным индикатором будет отсутствие входящих данных по одному из элементов в течении некоторого промежутка времени. При этом, мы должны быть уверены, что данные отправляются нам систематически с фиксированным интервалом времени. Для этих целей можно взять, как опорный, топик из раздела $SYS, например, время работы сервера $SYS/broker/uptime По умолчанию раздел $SYS обновляется каждые 10 секунд, но это значение может быть иным или обновления могут быть отключены полностью. Проверьте Ваше значение в конфигурационном файле /etc/mosquitto/mosquitto.conf sys_interval 10 Далее переходим в Zabbix и создаем новый триггер. Сам Zabbix предоставляет функция nodata(), работающую совместно с траппами и возвращающую: 1 - если не было получено данных за указанный промежуток времени в секундах. Период не может быть меньше 30 секунд. 0 - наоборот Таким образом, наша проверка будет выглядеть следующим образом {broker:topic[uptime].nodata(60)}=1 или, если используются полные имена, так {broker:topic[$SYS/broker/uptime].nodata(60)}=1 где broker - имя узла сети в Zabbix. В итоге, мы получаем взведенный триггер, если данные о времени работе брокера не будут обновлены в течении одной минуты.
  8. 1 point
    Друзья, в очередной раз приветствую Вас. Сегодня мы доведем до ума нашу идею с дружбой Zabbix и MQTT (Message Queue Telemetry Transport) протокола. Все описанные ранее варианты также жизнеспособны, но хотелось чего-то большего и в первую очередь, избавиться от задержки, из-за которой клиентам приходилось рассылать сообщения с параметром "-r, --retain". То есть была такая ситуация, что Zabbix сервер получал сообщения не тогда, когда они по факту приходили брокеру, а через какое-то время, равное интервалу между запросами к брокеру через вызов /usr/bin/mosquitto_sub. И именно из-за такой логики работы, клиентам приходилось выставлять флаг "сохранить" при отправке сообщения. Ну и пусть, скажете Вы, подождем, но как всегда есть нюансы: Сервер получает последнее сообщение в топике, а значит, в промежуток между их сбором, данные могут обновиться несколько раз, и мы потеряем часть информации. Это может быть актуально в некоторых случаях, например, если требуется контролировать состояние двери в серверной комнате (открыта/закрыта) ну или в других более серьезных задачах. Если требуется оперативно поднять соответствующий триггер, особенно если на него опирается логика других триггеров. Просто хочется поддержки MQTT протокола в реальном времени. Это действительно важный пункт и если предыдущие можно проигнорировать, то этот ни в коем случае. Долой слоупока, обучаем Zabbix работать с MQTT протоколом в реальном времени! Стоит понимать, что сам по себе Zabbix сервер не способен работать с данным протоколом и именно из-за этого нам требуются различные посредники. Раньше мы обращались к ним самостоятельно через Zabbix агента или внешнюю проверку (скрипт) и сообщали, что и как мы хотим получить. Теперь мы пополним арсенал сервера внешним демоном/сервисом/службой, нужное подчеркнуть. Именно на этот самостоятельный процесс ляжет задача по поддержанию постоянного соединения с MQTT брокером, и при появлении нового сообщения, он будет передавать его серверу через Zabbix траппер. Ну, что же, на словах все просто, как это будет на деле. При написании демона я использовал язык Python в силу его популярности, простоты и доступности некоторого набора готовых библиотек. Но это моя первая в жизни программа на Python и, возможно, Вы захотите её доработать. Также на моем сервере установлена операционная система Linux Ubuntu 18.04 и дальнейшее описание будет именно под неё, но я уверен, что Вам не составит труда установить следующие пакеты под любой ОС: python3 python3-pip библиотека paho-mqtt для python https://pypi.python.org/pypi/paho-mqtt zabbix-sender Получить список установленных пакетов, связанных с python и Zabbix, можно так dpkg -l | grep -E "python|zabbix" Устанавливаем пакеты (уже установленные можно выкинуть из списка) sudo apt install python3 python3-pip zabbix-sender Подгружаем библиотеку pip3 install paho-mqtt Далее нам понадобится сама программа, скачать её можно в конце этого поста Копируем её в любое удобное Вам место, но, чтобы пользователь, от которого будет запускаться программа, имел туда доступ, например, /media/zabbixMqttClient.py и выставляем права ограниченного пользователя, пусть это будет пользователь Zabbix sudo chown zabbix:zabbix /media/zabbixMqttClient.py sudo chmod 0700 /media/zabbixMqttClient.py Далее необходимо добавить программу в автозагрузку. Сделаем это через планировщика задач crontab и опять же от имени пользователя zabbix sudo crontab -u zabbix -e Добавляем следующую запись @reboot /media/zabbixMqttClient.py start Запускаем демона от имени пользователя zabbix sudo -u zabbix /media/zabbixMqttClient.py start Далее переходим к разбору настроек программы Они разбиты на несколько секций """ Настройки MQTT """ mqtt_server = "mqtt.it4it.club" mqtt_port = 1883 mqtt_login = "" mqtt_password = "" mqtt_client_id = "zabbixServer" mqtt_short_names = True Все параметры должны быть интуитивно понятны, кроме mqtt_short_name. Данный параметр заставит программу производить разбор топика с целью поиска в нем имени хоста, на который будут отсылаться сообщения Zabbix серверу. Если параметр будет выставлен в False, то в качестве параметра ключа будет использовано полное имя топика. Мы рассмотрим этот механизм подробнее ниже, при разборе механизма подписки на интересующие нас топики. Также по умолчанию мы используем TCP соединение т.к поддержка webSocket не предусматривалась, но программу можно легко доработать. """ Настройки Zabbix """ zabbix_server = "127.0.0.1" zabbix_port = 10051 zabbix_sender = "/usr/bin/zabbix_sender" #zabbix_sender = "C:\\ZabbixAgent\\bin\\win64\\zabbix_sender.exe" С настройками подключения к Zabbix серверу также все просто. Подключаться мы будем с помощью утилиты zabbix-sender, поэтому необходимо указать полный путь до неё. Скрипт также можно запускать из-под Windows, но только в оконном режиме и с параметром window. При использовании параметра start, получите шлак ошибок т.к она отвечает за запуск программы в качестве демона в Unix подобных системах. """ Настройки общие """ pid_file = "/tmp/zabbixMqttClient.pid" В общих настройках описано только расположении pid файла. Можно оставить без изменений. """ Список топиков для подписки и идентификаторы Zabbix хостов на которые требуется их переслать """ subscribe = { '$SYS/#': 'broker', 'kitsum/espWeatherStation/#': 2, 'log/+/#': 2, } Ну вот мы и добрались до самого главного - оформление подписки на топики. Я долго ломал голову над тем, как угодить всем и организовать переправку любых сообщений на те Zabbix хосты, для которых они предназначены. И сделать это без внесения транспортной информации в само тело сообщение, лично я считаю это плохой практикой, но судя по сообщениям, за которыми я наблюдал на некоторых популярных брокерах, люди считают это хорошей идеей. Просто какое-то безумие... Думаю, что Арлен Ниппер и Станфорд-Кларком, разработчики протокола, это не одобрили, хотя сам протокол не несет никаких ограничений на передаваемую информацию. Но давайте отталкиваться от идеологии протокола. Сам по себе топик представляет: стандартизированный, упорядоченный и интуитивно понятный набор информации, а также является адресом получателя. То есть, если адрес топика будет соответствовать адресу проживания реального человека, то вид его будет похож на что-то подобное <страна>/<штат или область>/<город>/<район или улица>/<дом>/<квартира>/<имя получателя> Думаю, что Вы согласитесь со мной, ведь нет смысла писать только половину адреса, а оставшуюся часть вкладывать в сообщение. Проще, после имени получателя, дописать адрес, но уже в контексте той нагрузки, которую несет сообщение. <имя получателя>/<помещение>/<источник информации> <имя получателя>/<группа>/<подгруппа>/<источник информации> ... building/serverRoom/door/1/state ... building/serverRoom/zone1/smokeDetectors/1 building/serverRoom/zone2/smokeDetectors/1 building/serverRoom/zone3/smokeDetectors/5 ... building/serverRoom/+/smokeDetectors/# Все понятно и даже задумываться не нужно, о чем идет речь. Также стоит обратиться к принципу работы zabbix-sender, той самой утилиты, которая и будет финальной в цепочке передачи. Вот еще немного подробностей про неё. Как видим, кроме параметров подключения мы обязаны передать: Имя узла сети, которому адресовано сообщение Ключ элемента данных Сами данные И если с последним параметром все понятно, то два предыдущих я предлагаю брать из самого топика, а также не брезговать принудительным указанием имени узла сети для конкретного топика. Синтаксис правил следующий 'адрес топика в формате mqtt': 'имя узла сети в zabbix', В таком случае, все сообщения, подпадающие под установленное правило будут адресованы заранее указанному узлу сети. Но что делать, если имя узла неизвестно, и мы ожидаем данные от любых источников с адресом топика подпадающим под установленную маску? В таком случае мы можем указать порядковый номер субтопика, который содержит это самое имя. Указывать его нужно в виде целого числа, как положительного, так и отрицательного. В зависимости от знака, отсчет будет начинаться с начала конца адреса топика. Saint Petersburg/office1/temperature Saint Petersburg/office213/Wi-Fi/signalStrength Эти два топика могут подпадать под правило 'Saint Petersburg/+/#': 2, Таким образом, второй элемент с начала топика выпадает на субтопик "+" и, следовательно, имя узла сети будет соответствовать номеру офиса: office1 и officce213. Тоже самое можно делать и в обратном порядке, то есть с отрицательными значениями номера субтопика, но при этом, Вы должны быть уверены в длине адреса топика, а точнее, в количестве его субтопиков. Moscow/Odintsovo/+/temperature Этот шаблон может подпадать под два разных правила 'Moscow/Odintsovo/+/temperature': 3, 'Moscow/Odintsovo/+/temperature': -2, Что в итоге будут опять ссылаться на субтопик "+" и соответствовать его любому значению. И последнее правило 'NewYorkCity/+/gasSensors/+/#': 4, Которое соответствует второму значению "+" (четвертый субтопик), что совпадет с разными топиками и может не соответствовать нашим ожидания т.к мы получим два разных значения ссылающиеся на один узел сети "sensor 3". NewYorkCity/office16/gasSensors/sensor3/value/current NewYorkCity/office85/gasSensors/sensor3/value/current В таком случае мы должны быть уверены, что нумерация датчиков уникальна для всего набора зданий или на стороне Zabbix сервера мы ожидаем увидеть полный адрес топика, а значит, для второго варианта развития событий переменная mqtt_short_names должна быть выставлена в Flase. Таким образом мы можем кардинально поменять логику работы при построении ключей и выглядеть они будут следующим образом. Но отправлены на один узел - "sensor3" mqtt_short_names = True # отправлено хосту sensor3 (значения перезаписывают друг друга) topic[value/current] topic[value/current] mqtt_short_names = False # отправлено хосту sensor3 (ключи уникальны) topic[NewYorkCity/office16/gasSensors/sensor3/value/current] topic[NewYorkCity/office85/gasSensors/sensor3/value/current] Или исправить правило на следующее 'New York City/+/gas sensors/+/#': 2, И при mqtt_short_names = True, данные будут переданы на разные узлы сети с именами office16 и office85 соответственно, но при этом ключи будут выглядеть одинаково и не будут пересекаться. topic[gasSensors/sensor3/value/current] # отправлено хосту office16 topic[gasSensors/sensor3/value/current] # отправлено хосту office85 Возможно в теории все не так явно, но на практике это очень удобно. И важный момент - все описанные Вами правила будут рассматриваться аналогично правилам любого межсетевого экрана (firewall). Вышестоящее правило в списке имеет приоритет над нижестоящим. И если топик попал под действие одного из шаблонов, то все нижестоящие правила будут проигнорированы. Поэтому будьте внимательны. Вот пример того явной ошибки построения правил. # ошибочная конфигурация правил subscribe = { '#': 'rubbish', '$SYS/#': 'broker', 'log/+/#': 2, } Как мы видим, под первое (жадное) правило будут подпадать абсолютно все топики и данные будет получать только узел с именем rubbidh. Два оставшихся правила никогда не будут выполнены т.к уже имеют более низкий логический приоритет. Чтобы исправить данную ситуацию, опустим самое "жадное" правило в конец списка. # правильная конфигурация правил subscribe = { '$SYS/#': 'broker', 'log/+/#': 2, '#': 'rubbish' } Что мы получим теперь. Правила не пересекаются Все данные с системного топика $SYS (данные по работе брокера) будут переданы Zabbix и адресованы узлу broker Все данные с топика log (условный раздел для логов) будут переданы узлам c именами соответствующими второму субтопику Все остальное (вообще все) будет передано узлу rubbish Также хочу отметить, что если, при использовании коротких имен топиков (mqtt_short_names = True), имя имя узла сети не будет найдено в адресе топика, то в ключе будет использован полный адрес топика, как будто бы короткие имена топика не используются вовсе (mqtt_short_names = False). mqtt_short_name = True subscribe = { 'serverRoom/rack2/zone4/temperature': 'zabbixServer', 'serverRoom/rack3/zone4/temperature': 'rack3', } В первом правиле будет использован полный путь топика т.к имя узла не будет найдено, а вот во втором правиле совпадение найдено будет и имя топика будет преобразовано в его короткий вариант. topic[serverRoom/rack2/zone4/temperature] # отправлено узлу zabbixServer topic[zone4/temperature] # отправлено узлу rack3 Короткие имена очень удобны в том случае, если требуется избавиться от лишних элементов в ключе. Например, если данные явно адресованы и сам узел сети несет информацию, связанную непосредственно только с ним. Это может быть, как сам брокер, так и набор различных сенсоров, определенных на Zabbix сервере как самостоятельные единицы. Рассмотрим это на примере шаблона для мониторинга MQTT брокера Mosquitto. Саму процедуру установки и настройки брокера я рассматривать не буду т.к предполагается, что брокер у Вас уже имеется. Мониторинг MQTT брокера Mosquitto В первую очередь нам понадобится сам шаблон, найти его можно в конце статьи. Импортируем его на Zabbix сервере, создаем узел сети, описывающий наш брокер и подключаем шаблон. Переходим в раздел "Мониторинг -> Последние" данные, выбираем наш узел и смотрим, что прилетает нам. Если Вы все сделали правильно, то увидите все данные по работе брокера. И как мы можем наблюдать, все ключи имеют короткие имена. Чтобы создать собственные элементы данных необходимо: Хость на, который отправляются данные, существовал на Zabbix сервере. Обращение идет по полю "Имя узла сети" Элемент данных был с типом "Zabbix траппер" Адрес обязан быть заключен в ключ topic[], например, topic[bytes/received] На этом все. Файлы проекта PS: Приятного использования и обязательно делитесь своими наработками и идеями.
  9. 1 point
    Привет друзья. Обкатка прошла успешно и пришло время расширить функционал и обзавестись дополнительными плюшками. А именно: Добавлять устройства по реальными ip адресами, а не эмитировать их через петлю сервера 127.0.0.1 Реализовать возможность подключения как к приватному брокеру с системой авторизации, так и оставить поддержку открытых брокеров Перенести весь функционал в шаблон Предусмотреть возможность использования одного шаблона с различными брокерами. А также разделить адрес топика на две части - корневой путь, который можно выстраивать динамически у каждого узла и статическую часть, несущую как смысловую нагрузку, так и сами данные. Вам понадобится mosquitto-clients. У меня сервер под Linux Ubuntu поэтому от этого и будем отталкиваться. Если у Вас что-то иное, то действуйте по аналогии. sudo apt-get install mosquitto-clients Далее создаем дополнительный внешний скрипт для Zabbix. По умолчанию, все используемые сервером скрипты располагаются по адресу /usr/lib/zabbix/externalscripts Быстро узнать какой каталог использует Ваш сервер можно так cat /etc/zabbix/zabbix_server.conf | grep ExternalScripts Добавляем новый скрипт и заодно выставляем на него права. В моем случае, сервер работает от имени пользователя zabbix cd /usr/lib/zabbix/externalscripts touch ./mqtt chown zabbix:zabbix ./mqtt chmod 555 ./mqtt Скрипт станет посредником между Zabbix сервером и брокером. Его основная задача, это прием входных параметров, их подсчет и принятие решения о том чем эти самые параметры являются. А вот и сам скрипт Скрипт способен принимать до 4 входных параметров и от их количества будет зависеть то, какое место займет каждый из перечисленных параметров. Теперь в самом zabbix сервере, при создании нового элемента данных, нам доступна внешняя проверка mqtt принимающая до 4 параметров mqtt[<топик>] mqtt[<адрес сервера>, <топик>] mqtt[<топик>, <имя пользователя>, <пароль>] mqtt[<адрес сервера>, <топик>, <имя пользователя>, <пароль>] А вот и сам тестовый шаблон: mqtt-temperature.zip Очень удобным решением будет использование пользовательских макросов в создаваемых шаблонах и в самих узлах. Создаем новый узел сети, теперь можно указывать его реальный ip адрес, и переходим в раздел "макросы". Макросы узла имеют приоритет над макросами прикрепленного к узлу шаблона. Таким макросом мы можем указать корневой топик для всей веки собираемой информации. Если переключиться на "макросы узла сети и унаследованные", то мы получим весь список доступных макросов. Таким образом мы можем указать основные настройки на уровне шаблона и вносить мелкие корректировки в эти самые настройки уже на уровне самого узла сети. Также Вы можете добавить собственные макросы и предусмотреть для них место в логике скрипта. Например, добавить возможность выбора порта брокера или иного параметра для mosquitto_sub Использовать макросы очень просто, достаточно указать их в качестве параметра или его части. Далее работаем с ними также, как и с обычными параметрами Для проверки работоспособности удобно использовать программу mqtt-spy ЕЩЕ РАЗ НАПОМИНАЮ: Клиенты рассылающие сообщения должны использовать параметр "-r, --retain" для сохранения сообщения у брокера. Без этого параметра Zabbix не сможет получить данные т.к не поддерживает постоянную связь с брокером, а лишь забирает последние данные по установленному интервалу времени.
×
×
  • Create New...