на каком протоколе основан протокол обмена данными между zabbix server и zabbix agent

Zabbix + Wirenboard: мониторинг производства

Введение

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

Задача

У нас есть конвейерные линии с сырьем и готовой продукцией, есть печи, автоклавы и другие, полезные в производстве, штуки. Все это потребляет различные ресурсы (газ, вода, электричество) и требует контроля (работает или простаивает). Нужен мониторинг, который позволит нам выявить узкие места на производстве и сделать выводы об эффективности использования ресурсов и оборудования.

Сложности интеграции

Все менять – долго, дорого и сложно, а данные нужно получить уже сейчас, вывод: нужно встраиваться.

Контроллер

Zabbix-mqtt-Wirenboard

Zabbix не работает напрямую c MQTT, но есть возможность использовать внешние модули, вот два варианта, которые я применял.

Это заработало достаточно быстро, но у этого подхода есть проблема – MQTT хранит данные в топике без привязки ко времени. Если датчик умер, и не присылает новые данные, в топике все равно хранится последнее значение и на графике в Zabbix мы получим прямую линию. Можно использовать ключ «retain», который позволяет доставлять данные метрики только активным подписчикам на соответствующий топик, но тогда Zabbix данные не получит вообще, так как он опрашивает последнее значение, а не подписывается на топик. Еще одна неприятность – на каждый топик свой запрос, опрашивать нужно много и часто. Это приводит к расхождению реального состояния на производственной линии и полученных данных, потому что опрос производился в разное время и с интервалами.

Второй способ получения данных стал возможен благодаря переходу на Zabbix 4.2 и интеграции модуля zbx_mqtt. Скрипт опроса устанавливается на Zabbix сервер, с его помощью можно запросить всю ветку топиков устройств, получить данные в формате JSON и затем разобрать их по соответствующим метрикам. Так мы смогли забирать данные одновременно с нескольких датчиков и получить «снимок» состояния всей линии. Проблема с устареванием данных решается через обработку данных в Preprocessing: если данные не менялись – не записывать их.

Мониторинг

Счетчик импульсов

Импульсный выход – самый распространённый интерфейс для подсчета чего-либо. С его помощью можно:

посчитать потребление с расходомеров или сколько продукции прошло через оптические датчики

определять состояние дверей или положение подвижных элементов при помощи герконов

снимать данные с энкодеров двигателей и получить угол поворота или количество оборотов

определять статусы вкл/выкл через реле или аналоговые выводы.

Например, у нас есть счетчик WB-MCM8 c modbus адресом 32, мы его используем для подсчета банок оптическим датчиком на выходе конвейера, он передает данные в топики MQTT на Wirenboard.

Для сбора данных мы создаем в Zabbix элемент MasterItem_WB-MCM8_32 с типом External check. Он будет забирать состояние всех счетчиков.

Пример Master item для MQTT метрик

В поле key мы указываем запрос: mqtt[«-t=/devices/wb-mcm8_32/#»,»—mqtt-host=«] где:

mqtt[] – вызов скрипта для опроса с параметрами

-t=/devices/wb-mcm8_32/# — запросить все данные внутри топика устройства wb-mcm832

В результате такого запроса, в Zabbix возвращаются данные в формате JSON, вот пример фрагмента:

Вторым шагом мы создаем dependent item, который будет забирать конкретную метрику из мастера.

Параметр key тут значения не играет, но в нем я указываю полный путь к топику mqtt для удобства поиска. Выборка данных указывается во вкладке Preprocessing.

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

Счетчик электроэнергии

Мы использовали WB-MAP3H. Для его установки не требуется отключения линий и потребителей, устройство получает данные о расходе через внешние трансформаторы тока, которые крепятся на кабель без его демонтажа. Важно соблюсти соответствие подключаемых фаз (контролируется по фазовым углам) и указать коэффициенты трансформаторов (в новой версии они указаны на корпусе, в старой – делалась калибровка у производителя). Устройство не только измеряет основные характеристики (мощность, энергия, расход), но умеет измерять много дополнительных характеристик вплоть до определения доли гармоники и амплитуд всплесков (полный список измеряемых параметров можно посмотреть тут).

WB-MAP3H

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

Получение данных от Delta по Modbus TCP и RTU

У нас часть промышленных линий управляется контроллерами Delta, на которых есть сетевой интерфейс и реализован протокол Modbus TCP. Переменные на контроллере сохраняются в регистры Modbus и их можно забрать в Zabbix при помощи модуля libzbxmodbus. Модуль оказался очень функциональным и удобным, он умеет работать не только по сети с TCP, но и через com порт с RTU реализацией Modbus. Подробное описание и параметры можно посмотреть на гите разработчика, а я покажу свой пример использования.

На Zabbix создан Master item, он забирает с контроллера 17 регистров по Modbus TCP, в которых хранятся данные от датчиков веса, температуры и уровня продукта в емкости.

master item для опроса контроллера Delta

$MODBUS_ADDRESS – локальная переменная в Zabbix, в ней хранится ip адрес контроллера к которому обращаемся, у меня это «tcp://192.168.0.2»

1 – адрес устройства на шине Modbus. Как правило это «1», разные адреса могут быть при работе с RTU версией протокола, когда несколько устройств работают на одной шине

4110 – адрес начального регистра, который мы читаем первым

3 – функция протокола Modbus. В моем случае указана 3 – функция чтения регистра

17*s – модуль умеет читать несколько регистров подряд, в моем примере он берет 17 регистров и считает, что тип данных в них int16 (s=int16, f=float, b=bit это подробно описано в документации к модулю)

В 5й версии Zabbix появилась возможность сразу тестировать работу запроса и посмотреть возвращаемое значение – кнопка Test, нажав ее мы получим JSON объект со значениями 17 регистров (с 4110 по 4126).

Настройка метрики из регистра контроллера

Интеграция с Siemens

Контроллеры Siemens S7 используют свой протокол profinet / profibus, для работы с ним есть открытая библиотека Snap7. Для интеграции был создан скрипт zbx_s7_get на питоне, который умеет опрашивать контроллеры.

Пример запроса данных

Скрипту s7_get.py передаются параметры:

– встроенная локальная переменная, которая содержит ip адрес узла сети (указан в host interface)

– переменная, в которой указан rack id контроллера

– переменная, в которой указан слот

Bool – тип возвращаемых данных, в моем случае мне нужны именно true / false. Может быть int или float.

—json – формат данных. В моем случае выбран json, так как это master item и на его основе я создаю зависимые элементы с нужными метриками.

При тестировании этого элемента мы получим данные в JSON, которые можно будет разобрать по метрикам (в моем случае это статусы с датчиков на контроллере).

Получение данных с принтеров Linx 5900

Для подключения Zabbix к принтеру я использовал конвертер moxa NPORT 5150. Он позволяет прокинуть через tcp физический порт rs232 с принтера на виртуальный serial порт /dev/ttyr01 linux машины, где установлен Zabbix агент. Само общение с принтером происходит по Linx Remote Communications Interface (RSI). Протокол обмена основан на отправке команды в двоичном виде, вот пример заброса счетчика отпечатков (используется мной для подсчета продукции).

Протокол обмена использует контрольные суммы в запросе и ответе, последовательность подробно описана в инструкции, но мне не удалось с ними разобраться и пришлось эту функцию отключить.

В Zabbix я использовал плагин serial.get. Item key для получения текущего состояния счетчика выглядит так:

Заключение

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

С помощью мониторинга удалось:

выявить и устранить причины потери ресурсов и сократить расход (за счет устранения утечек и отключения лишних потребителей)

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

оптимизировать логику управления производственной линии и поднять ее производительность (за счет перенастройки таймингов насосов и приводов)

предоставить легкий доступ к актуальной информации во время проведения технических советов и совещаний (вместо бумажных отчетов)

При внедрении мониторинга важно понимать, что просто получить данные недостаточно, ими нужно активно пользоваться – анализировать и визуализировать, предоставлять легкий доступ всем заинтересованным. Про визуализацию в Grafana я написал другую статью, прочитать ее можно тут.

В планах:

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

Разработать весовой контроль подаваемого сырья при помощи интеграции с весовыми терминалами CAS

Разработать мониторинг состояния двигателей за счет контроля потребления энергии и вибродиагностики

Расширить покрытие мониторинга по всему заводу

Источник

Система мониторинга Zabbix для начинающих

Содержание:

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

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

Обзор

Систему создал Алексей Владышев на языке Perl. Впоследствии проект подвергся серьезным изменением, которые затронули и архитектуру. Zabbix переписали на C и PHP. Открытый исходный код появился в 2001 г., а уже через три года выпустили первую стабильную версию.

Веб-интерфейс Zabbix написан на PHP. Для хранения данных используются MySQL, Oracle, PostgreSQL, SQLite или IBM DB2.

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

Далее рассмотрим, из чего состоит и как работает технология Zabbix в доступном формате «для чайников».

Архитектура Zabbix

У Zabbix есть 4 основных инструмента, с помощью которых можно мониторить определенную рабочую среду и собирать о ней полный пакет данных для оптимизации работы.

Основные возможности

Функционал включает в себя общие проверки для наиболее распространенных сервисов, в том числе СУБД, SSH, Telnet, VMware, NTP, POP, SMTP, FTP и т.д. Если стандартных настроек системы недостаточно, их можно изменить самостоятельно или же пользоваться дополнением через API.

Стандартные функции системы

Проверки

Для описания системы мониторинга Zabbix существует два ключевых понятия:

Сам Zabbix-агент способен отражать текущее состояние физического сервера, собирая совокупность данных. У него достаточно много метрик. С их помощью можно проверить загруженность ядра (Processor load), время ожидания ресурсов (CPU iowait time), объем системы подкачки (Total swap space) и многое другое.

В Zabbix существует целых 17 способов, дающих возможность собирать информацию. Указанные ниже, входят в число наиболее часто применяемых.

У проверок есть заданные шаблоны (Templates), которые упрощают создание новых. Кроме обычных операций существует возможность регулярно проверять доступность веб-сервера с помощью имитации запросов браузера.

Проверка через пользовательский параметр

Чтобы выполнить проверку через агент, нужно прописать соответствующую команду в конфигурационный файл Zabbix-агента в качестве пользовательского параметра ( UserParameter ). Сделать это можно с помощью выражения следующего вида:

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

Пример

С помощью данной команды можно настроить агент на постоянное возвращение значения « 1 » для элемента данных с ключем « ping ».

Триггеры

У каждого триггера существует уровень серьезности угрозы, который маркируется цветом и передается звуковым оповещением в веб-интерфейсе.

Некоторые функции триггеров

Прогнозирование

Триггеры обладают еще одной важной функцией для мониторинга — прогнозированием. Она предугадывает возможные значения и время их возникновения. Прогноз составляется на основе ранее собранных данных.

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

Функционал прогнозирования добавили с обновлением системы 3.0, вышедшим в феврале 2016 года.

Действие

Действие (Action) представляет собой заданную реакцию на событие (Event). Действие может устанавливаться автоматически или вручную как для одного из событий, так и для целой группы.

Параметры действий

Для событий, вызванных триггером или обнаружением, есть свои типы условий. Например, «Application» с операторами « = », « like » и « not like » значит, что триггер является частью указанного приложения. Или «Service type» с операторами « = », « »и « > » предусматривает, что обнаруженный сервис совпадает с указанным.

Операции

Пользователь может указать для событий операцию или группу операций.

Параметры операций

Низкоуровневое обнаружение

Функция Низкоуровневого обнаружения (LLD) автоматически создает элементы и триггеры, которые позволяют отслеживать системы сервера, находящимся под наблюдением. Включение функции происходит через настройку атрибутов, которую можно сделать, пройдя по пути: «Настройка» → «Шаблоны» → «Обнаружение» (вкладка в строке с шаблоном) → вкладки «Правила обнаружения»/«Фильтры».

Что можно обнаружить

Дополнительные типы

Задать собственные типы низкоуровневого обнаружения возможно с применением формата JSON. Типы проверок, для которых можно указать список портов и интервал для них:

Если хост пропадает или обнаруживается, для события можно привязать любое действие — условия и операцию для них.

Прокси

Функция буферизации через прокси используется в том случае, когда существующая инфраструктура достаточно большая, а выделенный сервер не способен нести такую нагрузку. Прокси выступает промежуточным звеном, которое собирает информацию с агентов в буфер, а после отправляет данные на сервер.

Прокси используется еще в нескольких случаях — если агенты находятся далеко друг от друга или ограничены локальной сетью. Это сказывается на доступности агентов и величине пингов.

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

Особенности веб-интерфейса

Система мониторинга Zabbix располагает удобным веб-интерфейсом, в котором сгруппированы элементы управления. Консоль предусматривает просмотр собранных данных, их настройку. Для безопасности входа и работы осуществляется автоматическое отсоединение через 30 минут пользовательского бездействия.

На главном экране всегда представлена информация о состоянии узлов сети и триггеров.

Пользователю доступны пять функциональных разделов, включая Monitoring («Мониторинг»), Inventory («Инвентарные данные»), Reports («Отчеты»), Configuration («Конфигурация») и Administration («Администрирование»).

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

Управлять шаблонами, доступными администратору, можно в соответствующем подразделе — Templates («Шаблоны»).

Версия 4.4

Узнать версию установленного Zabbix сервера можно во время запуске в файле-протоколе.

Основные нововведения в Zabbix 4.4

Заключение

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

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

Источник

Zabbix + OPC DA

В последних релизах Zabbix «из коробки» стал поддерживать некоторые популярные протоколы промышленного оборудования. Имея поддержку Modbus и MQTT, его использование с системами промышленной автоматизации стало чуточку проще. Но подобный подход к мониторингу такого рода оборудования не всегда возможен.

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

Для чего нам Zabbix

В нашем сценарии использования Zabbix последний не является заменой имеющейся SCADA-системе. Параллельное развертывание системы мониторинга позволит иметь возможность гибкой настройки триггеров и своевременного получения оповещений о нештатных ситуациях на оборудовании. Также мы сможем создавать дополнительные информационные панели с графиками, которые смогут давать быстрое представление о ходе тех. процессов.

Взаимодействие с OPC серверами

Самой сложной задачей, которая стоит перед нами, является организация взаимодействия с OPC-серверами. В ходе поисков готового решения такого взаимодействия стало понятно, что подходящих нам вариантов не так много. Из того, что было найдено, наиболее пригодным к использованию оказался консольный клиент OpenOPC.

Установка OpenOPC

Как было сказано ранее, речь идет о стандарте OPC DA, а значит, о технологии DCOM и, соответственно, ОС Windows. В нашем случае установка OpenOPC производилась на машину с Windows XP, где и находится проприетарный OPC сервер. После завершения установки необходимо добавить путь до opc.exe в системную переменную среды PATH.

Проверим работу утилиты. Для начала выведем в консоль список доступных OPC серверов:

Если что-то пошло не так

Установка Zabbix агента

На ту же машину установим Zabbix агент, который сможет работать под Windows XP, например, zabbix_agent-5.2.0-windows-i386-openssl.msi. Агент будет выполнять активные проверки. Чтобы облегчить дальнейшую конфигурация агента, во время установки заполним следующие поля:

Конфигурирование Zabbix агента

В конфигурационный файл C:\Program Files\Zabbix Agent\zabbix_agentd.conf были внесены некоторые изменения.

Увеличено время выполнения скрипта.

Создан параметр для мониторинга.

Узел сети и элементы данных на сервере Zabbix

Значениями элемента данных будут строки, разделенные запятыми:

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

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

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

Пример визуализации полученных данных:

Заключение

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

Источник

Zabbix Documentation 5.4

Sidebar

Table of Contents

3 Пассивные и активные проверки агента

Обзор

Этот раздел описывает детали пассивных и активных проверок, которые выполняются Zabbix агентом.

Zabbix использует протокол на основе JSON для взаимодействия с Zabbix агентом.

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

Пассивные проверки

Пассивной проверкой является простой запрос данных. Zabbix сервер или прокси запрашивает какие-либо данные (к примеру, Загрузку CPU) и Zabbix агент отправляет обратно результат серверу.

Запрос сервера

Ответ агента

Часть в квадратных скобках выше опциональна и отправляется только по неподдерживаемым элементам данных.

Для неподдерживаемых элементов данных:

Активные проверки

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

Сервера, которые отдают активные проверки, перечислены в параметре “ServerActive” файла конфигурации агента. Частота запросов проверок настраивается параметром ‘RefreshActiveChecks’ в том же файле конфигурации. Однако, если обновление активных проверок завершится с ошибкой, запрос повторится через, жестко задано в коде, 60 секунд.

Затем агент периодически отправляет новые значения на сервер(а).

Получение списка элементов данных

Запрос агента

Ответ сервера

Сервер должен ответить положительно. У каждого полученного элемента данных обязательно должны быть указаны параметры key, delay, lastlogsize и mtime, независимо от того элемент данных является журнальным или нет.

Отправка собранных данных

Отправка агента

Виртуальный ID назначается каждому значению. Значением ID является простой счётчик с инкрементом, уникальный в пределах одной сессии передачи данных (идентифицируется при помощи токена сессии передачи данных). Этот ID используется, чтобы отбрасывать дубликаты значений, которые могут быть отправлены в средах с плохой связью.

Источник