Перейти к публикации
iT4iT.CLUB

Таблица лидеров


Популярные публикации

Отображаются публикации с наибольшей репутацией на 17.05.2019 во всех областях

  1. 1 балл
    Всем привет. Начнем как всегда с предыстории! Цель, сбор данных с различных устройств на очень большой территории промышленного предприятия. Естественно финансирование просто огромное, хватит на большую пачку семечек и пачку индийского чая, возможно даже сдача останется, но не факт. А Вы как думали? В сказку попали? В связи с этим устройства самодельные, на базе популярных микроконтроллеров фирмы 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 брокером. Это дает гибкость в случае замены самого брокера или миграции сервера на другую платформу. Интересующий нас ключ отмечен на рисунке, все остальное на Ваше усмотрение. Все данные показанные ниже идут с тестового стенда, установленного за пределами экстремальных зон! Так выглядят первые элементы данных. Это показания с двух датчиков температуры и данные с внутреннего таймера микроконтроллера. Последние показания нужны для отслеживания зависания устройства. такое и мало вероятно. Но оно и имеет сторожевой таймер, лишняя перестраховка в промышленных масштабах не помешает. Текущие показания. Ну и естественно график, куда без него. Прост и так скудный) Можно организовать скрипт, поддерживающий несколько входных параметров, но это уже вопрос желания и необходимости.
  2. 1 балл
    Маленькое дополнение к последнему посту с мониторингом 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. В итоге, мы получаем взведенный триггер, если данные о времени работе брокера не будут обновлены в течении одной минуты.
  3. 1 балл
    Друзья, в очередной раз приветствую Вас. Сегодня мы доведем до ума нашу идею с дружбой 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: Приятного использования и обязательно делитесь своими наработками и идеями.
  4. 1 балл
    Привет друзья. Обкатка прошла успешно и пришло время расширить функционал и обзавестись дополнительными плюшками. А именно: Добавлять устройства по реальными 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 не сможет получить данные т.к не поддерживает постоянную связь с брокером, а лишь забирает последние данные по установленному интервалу времени.
×
×
  • Создать...